Телеметрия без мистерия: Prometheus, Loki, Tempo и Grafana и защо OpenTelemetry

Понеделник е, девет сутринта, и преводите в една банка се бавят три пъти повече от обичайното. Пристигат оплаквания, отваря се инцидент и в един и същ разговор се събират пет екипа: дигитални канали, основната система, антифрод, мрежи и инфраструктура. Всеки гледа своя екран и всеки стига до едно и също заключение: «от наша страна всичко е наред». Минават два часа, докато някой забележи, че забавянето е било в заявката на една-единствена услуга.

Този сценарий, илюстративен и без клиент зад него, не говори за лош екип. Говори за система, на която никой не може да види целия път на една операция. Телеметрията е отговорът на този проблем: данните, които една система излъчва за себе си, докато работи, за да може да бъде разбрана отвън, без да се отваря и без да се гадае. Тази статия е за онзи, който отговаря за такива системи в банка, финтех, застрахователна компания, търговска верига или регулирана компания, а също и за бизнес директора, който иска да разбере какво му искат, когато техническият екип каже «трябва ни наблюдаемост».

Ще говорим за четири широко използвани отворени инструмента —Prometheus, Loki, Tempo и Grafana— и за един стандарт, OpenTelemetry, който ги свързва. Ще обясним какво отговаря всеки от тях, как се свързват помежду си, защо е удобен общ стандарт, как се разгръщат в контейнери и в Kubernetes, кога е достатъчно да се четат логовете и кога софтуерът трябва да се инструментира отвътре, и какво струва и какви рискове носи всичко това.

Три сигнала за три различни въпроса

Една система в продукция може да разкаже своята история по три начина и всеки отговаря на различен въпрос. Тази статия се концентрира върху трите най-често срещани оперативни сигнала, които OpenTelemetry нарича сигнали [2]: метрики, трасета и логове.

• Метрики: какво се случва и колко? Метриката е измерване, взето, докато системата работи: колко превода в минута, колко време е отнело на 95 % от тях, колко са се провалили. Това е число във времето, евтино за съхранение и отлично за наблюдение на тенденция или за задействане на аларма. Не казва коя операция се е провалила.
• Трасета: през къде е минала тази операция и къде е спряла? Трасето е пълният път на една заявка през всички услуги, които е докоснала, с времето, прекарано във всяка [2]. Това е картата на една-единствена операция. Всеки участък от тази карта се нарича span.
• Логове: какво е казала системата в този момент? Логът е запис на събитие: ред текст или данни с дата, сериозност и съобщение. Това е финият детайл: «изтече времето за изчакване на пула от връзки».

Нито един от трите не стига сам. Метриката предупреждава, но не локализира; трасето локализира, но не обяснява; логът обяснява, но без контекст е игла в купа сено. Добрата практика, и червената нишка на тази статия, е те да се ползват във верига. При добре замислено инструментиране метриката обикновено предупреждава, трасето обикновено ограничава пътя, а логовете могат да дадат детайла; качеството на отговора зависи от това какво е излъчено и запазено.

Какво отговаря всеки инструмент

Всеки сигнал има отворен инструмент, предназначен да го съхранява и да се правят заявки към него. Преди таблицата, едно полезно уточнение за един комитет: нито един от тези инструменти не е взаимозаменяем с друг. Те са специализирани хранилища.

Две уточнения, които спестяват недоразумения. Първото: Prometheus не е касов апарат. Собствената му документация предупреждава, че ако се изисква пълна точност, като при таксуването по заявка, той не е добър избор [9]. Служи за експлоатация —да се знае дали системата е здрава—, не за съгласуване. В банка или финтех тази граница има значение: съгласуването живее в счетоводните регистри, а не в табло за латентност.

Второто: Loki е евтин именно защото не индексира съдържанието на логовете, а само няколко етикета за поток (от коя услуга и от коя среда идва). Данните се компресират на блокове и се съхраняват в хранилище за обекти [15]. Обратната страна е, че търсенето на текст в логовете става в момента на заявката, а не с предварителен индекс, и че етикетите трябва да се избират внимателно. Ще се върнем към това при разходите.

Ролята на Grafana

Grafana е прозорецът. Според нейната документация позволява да се правят заявки, да се визуализират, да се задават аларми и да се изследват метрики, логове и трасета, независимо къде се съхраняват [19]. Всяко хранилище се свързва като източник на данни: Prometheus, Loki и Tempo са три източника, а Grafana може да има и други до тях, като SQL бази данни [20].

Стойността ѝ не е в красивото табло, а в това, че свързва източниците. От едно и също място може да се премине от графика към трасе и от трасе към неговите логове. За един директор това се превежда в нещо конкретно: Grafana може да събере разследването в един изглед, ако са конфигурирани източници, права и връзки, вместо пет екрана и един разговор.

Как се свързва информацията

Това, че трите сигнала съществуват, не значи, че са свързани. Връзката не се появява от инсталирането на Grafana: проектира се още от инструментирането на софтуера и се тества от край до край. Нишката е един идентификатор, trace_id, който пътува с всяка операция. Стандартът за разпространение, който OpenTelemetry ползва по подразбиране, W3C Trace Context, носи този идентификатор в хедър, наречен traceparent, от една услуга към следващата [2].

Представете си trace_id като номера на товарителницата на една пратка. Ако всяка услуга го отпечатва върху онова, което произвежда, после може да се поиска «всичко, което се е случило с товарителница 4F2A…».

От метриката към трасето: exemplars

Exemplar е конкретна проба, закачена към агрегирана метрика. Помислете за графика на латентността: всяка точка обобщава хиляди операции. Exemplar е, в тази точка, примерът за една реална операция —с нейния trace_id—, която е допринесла за това измерване. В Grafana се появява като звезда върху графиката; при щракване се отваря в Tempo трасето на тази операция [20].

За да работи щракването от графиката към трасето, четири части трябва да са включени; ако липсва една, щракването не води наникъде. Документацията на Grafana го обобщава така: метриките дават агрегирания поглед, а трасетата — фината гледна точка на една заявка [20]. Добре е да се знаят условията, преди да се обещава нещо на когото и да било:

1. Приложението трябва да излъчва trace_id заедно с измерването, в рамките на трасе, което се съхранява.
2. Prometheus трябва да съхранява exemplars. Днес тази възможност се включва с флаг, отбелязан като експериментален, и е изключена по подразбиране [12].
3. В Grafana източникът Prometheus трябва да се настрои така, че връзката да сочи към Tempo и да казва кое поле носи trace_id [20].
4. Трасето, към което се препраща, трябва все още да съществува: ако семплирането или съхранението вече са го изхвърлили, щракването не води наникъде.

Алтернативен път е Tempo да изчислява метрики от трасетата —честота на заявките, грешки и продължителност, известната тройка RED (Rate, Errors, Duration), трите стандартни мерки, с които се следи една услуга— и да ги изпраща към база, съвместима с Prometheus, със своите exemplars [17]. Този път трябва да се изпробва спрямо лимитите за активни серии, тема, която се подема при разходите.

От трасето към лога: `trace_id` във всеки ред

От едно трасе в Tempo, Grafana може да отвори логовете на тази услуга в този времеви прозорец, като прави заявка към Loki. Това се настройва в източника на данни на Tempo (trace to logs), а съществува и равностойна връзка към метриките (trace to metrics) [21]. За да свържете лог с трасето, включете trace_id; добавете span_id, когато трябва да ограничите търсенето до span-а, който е излъчил лога. Моделът на данните за логове на OpenTelemetry ги предвижда като собствени полета [40], а за формати, които не са OTLP, препоръчва да се наричат trace_id, span_id и trace_flags [41].

От лога към трасето

Обратният път се настройва в Loki с производни полета (derived fields): правило, което извлича trace_id от реда и го превръща във връзка към Tempo [47]. Нужни са и двете страни: настройването само на Tempo не прави един лог навигируем към неговото трасе.

Едно златно правило на тази връзка: trace_id, и изобщо всеки идентификатор на клиент, поръчка, сметка или полица, не бива да е етикет на Loki. Трябва да пътува в съдържанието на лога или като структурирани метаданни. По-нататък се обяснява защо [14].

Защо OpenTelemetry, а не всяка технология директно

Четирите инструмента по-горе имат свои собствени начини за приемане на данни. Може да се програмира всяко приложение да говори директно с всеки от тях: една библиотека за метрики на Prometheus, друга за логове към Loki и трета за трасета към Tempo. Работи, но свързва кода на всяка услуга с три различни модела, три стратегии за повторение и три пътя за миграция.

OpenTelemetry (съкратено OTel) е проект на CNCF, фондацията, която приютява Kubernetes и Prometheus. Определя се като рамка за генериране, експортиране и събиране на телеметрия; неутрален е спрямо доставчиците и, което е важно, не е backend: нищо не съхранява и нищо не чертае [1]. Предлага четири части:

• API и SDK: библиотеки по език, с които софтуерът излъчва метрики, трасета и логове по общ модел.
• OTLP: общият протокол за пренос на трите сигнала, през gRPC (порт 4317 по подразбиране) или HTTP (4318) [4].
• Семантични конвенции: стандартни имена за онова, което се измерва, така че «услугата» или «подът» да се казват еднакво в трите сигнала [46]. Без това споразумение връзката между инструментите се разпада.
• Collector: междинна програма, която приема телеметрията, обогатява я, филтрира я и я препраща към една или няколко дестинации [6].

Практическото следствие: приложението излъчва веднъж, на стандартен език, а решенията накъде да отиде, какво да се филтрира и какво да се скрие живеят в контролирана конфигурация, а не пръснати в кода на всеки екип. Самите хранилища вече говорят този език: Loki, Tempo и Alloy могат да приемат OTLP, а Prometheus може да приема OTLP метрики, когато изрично е включен --web.enable-otlp-receiver [13][16][18][26].

За един директор аргументът е за преносимост и контрол. Документацията на OpenTelemetry го представя като липса на зависимост от един доставчик и като научаване на един-единствен набор от конвенции [1]. OpenTelemetry намалява зависимостта на кода от дестинацията, макар че една миграция все още може да изисква проверка на конвенции, експортери, семплиране, табла, аларми и съхранение; дестинацията се сменя в Collector.

Две уточнения от честност, защото този вид обещание лесно се раздува:

• Преносимостта не е безплатна. Дори с OpenTelemetry таблата, алармите и заявките, написани на PromQL, LogQL и TraceQL, се пренаписват при смяна на хранилището. Спестява се повторното инструментиране на софтуера, което обикновено е най-скъпата част.
• Зрелостта варира според сигнала и езика. Според спецификацията трасетата, метриките и логовете имат стабилен протокол, но SDK за метрики фигурира като «смесен», а профилите все още са в разработка [3]. По езици Java има и трите сигнала стабилни; Go, Python и JavaScript имат стабилни трасета и метрики, докато логовете са в кандидат за окончателна версия при Go и в разработка при Python и JavaScript [5]. Който програмира на Java, тръгва от по-твърда почва; който програмира на други езици, трябва да провери състоянието на логовете, преди да заложи на тях.

Като ориентир за възприемането, в годишното проучване на CNCF за 2024 г., във въпроса за инкубираните проекти (n=689), 39 % са отчели OpenTelemetry в продукция и 23 % в оценка; това е извадка от общността ѝ, а не пазарен дял [44].

Как се разгръща: контейнери и Kubernetes

Телеметрията се нуждае от три неща по пътя: някой, който да я генерира (софтуерът), някой, който да я събира и обработва (Collector или агент) и някой, който да я съхранява и показва (Prometheus, Loki, Tempo, Grafana). Променя се къде се поставя събирачът според платформата.

В Docker и Docker Compose

Compose декларира няколко услуги, мрежи и томове в един файл и затова се ползва за разработка, интегрирани тестове и малки среди [28]. Типичната схема е: приложенията изпращат OTLP към контейнер с Collector (или Alloy); Collector разпределя трасетата към Tempo, логовете към Loki и метриките към Prometheus; а Grafana прави заявки към трите. Collector се изпълнява като официален образ с монтиран конфигурационен файл; без този файл не стартира [28].

Две подробности за логовете в Docker, които често изненадват:

• Docker улавя по подразбиране стандартния изход и стандартния изход за грешки. Ако приложението пише само във файлове, docker logs няма да покаже тези редове. Затова официалните образи на уеб сървъри пренасочват файловете си към стандартния изход [28].
• Драйверът по подразбиране не ротира логовете. Драйверът json-file няма ограничение на размера по подразбиране, а Docker препоръчва драйвера local, който ротира по подразбиране (според Docker, файлове от 20 MB, до пет) [28]. Диск, пълен с логове, е реален експлоатационен инцидент.

Освен това има значение режимът на предаване: в блокиращ режим, който е по подразбиране, един бавен драйвер може да забави приложението; в неблокиращ режим ползва буфер и, ако се напълни, изхвърля съобщения [28]. А с драйвера на Fluentd в синхронен режим, ако няма връзка, контейнерът спира [29]. Трябва да се избира с намерение между това да не се губят логове и да не се забавя услугата.

В Kubernetes

Kubernetes препоръчва приложенията да пишат на стандартния изход и съхранението на логове да е външно, с жизнен цикъл, отделен от пода; няма собствено съхранение на логове [27]. Ротацията я прави kubelet (стойност по подразбиране на Kubernetes: файлове от 10 MiB и пет на контейнер), а kubectl logs вижда само най-новия файл [27]. Тоест без събирач логовете на под, който се е рестартирал или е ротирал, могат да се загубят.

Документацията на Kubernetes описва три модела за събиране на ниво клъстер: агент на възел, агент във всеки под или приложението да изпраща директно към дестинацията [27]. OpenTelemetry ги превежда в тези схеми на разгръщане:

Четири предпазни мерки, които документацията сочи и които, когато се пренебрегнат, се плащат с преработка по време на внедряването:

1. Всеки лог да се етикетира със своя собственик. Лог, прочетен от файл, не знае от кой под идва. Процесорът k8sattributes залепя пода, пространството от имена, внедряването и възела към всеки запис и е стабилен за трите сигнала [33]. Четенето на файлове (filelog) е в бета за логове [32] и по подразбиране чете само онова, което пристигне след стартирането; без да запазва позицията си, едно рестартиране може да дублира или да загуби редове [32].
2. Една метрика, един автор на запис. Два събирача, които докладват една и съща серия, пораждат данни извън ред в Prometheus [8].
3. Събирачът също се проваля. С конфигурирана опашка за изпращане, повторни опити и постоянно съхранение може да издържи преходни сривове; въпреки това пълен диск, продължителен срив или лимити на повторните опити могат да доведат до загуба [35]. Оразмерява се и се наблюдава като още една услуга.
4. С Operator редът има значение. Автоматичното инструментиране изисква ресурсът му за конфигурация да съществува преди пода, анотацията да е на правилното място и рестартиране; освен това презаписва променливи като JAVA_TOOL_OPTIONS [34].

Предупреждение за Promtail. Това е агентът за логове, който много екипи инсталираха преди години за Loki. Grafana обяви края на живота му на 2 март 2026 г.: вече не получава актуализации нито търговска поддръжка и се препоръчва миграция към Alloy, с инструмент за преобразуване [22]. Който все още го има в продукция, работи без подкрепата на производителя.

Агент, който чете лога, или инструментиране на приложението?

Това е най-практичното решение в цялата тема и се поставя погрешно, когато се представя като «старото срещу модерното». Това са два пътя с различни предимства.

• Агент, който чете, е програма, която взема онова, което софтуерът вече пише —на стандартния изход или във файл— и го отнася до хранилището. Не изисква промяна на софтуера. В замяна изисква интерпретиране (парсване) на редове с различни формати и не може да измисли trace_id, който приложението не е написало [32][40]. OpenTelemetry описва двата пътя —четене на файлове или стандартен изход, или директно изпращане по OTLP— и обобщава компромиса така: първият не изисква промени, но иска стабилен парсинг; вторият избягва сложността на файловете, но изисква конфигурация в приложението [39].
• Инструментиране отвътре е ползването на SDK на OpenTelemetry или на appender —адаптер, който свързва системата за логове, която фреймуъркът вече ползва, като Logback или Log4j в Java, с OpenTelemetry— така че всеки запис да излиза със своя контекст на трасето и със структурирани данни [38]. OpenTelemetry не замества тези библиотеки за логове: свързва се с тях като мост [38]. В замяна трябва да се променя и внедрява код.

Зрелият отговор обикновено е хибриден, с едно условие: да не се дублира. Ако приложението експортира едно събитие през своя appender и, освен това, същото събитие се прочита отново от файла, хранилището получава две копия. Всеки поток се декларира за единия път или за другия.

Бележка за «автоматичното инструментиране». В Java агентът на OpenTelemetry се прикрепя при стартиране (-javaagent) и инжектира код по време на изпълнение, за да улавя телеметрия от обичайните библиотеки: входящите и изходящите HTTP повиквания, базата данни [37]. Дава бърза видимост без промяна на изходния код. Но покрива техническите краища, не бизнес логиката: документацията е изрична, че собственият код на приложението обикновено не се инструментира сам [36]. Решение като «одобрение на кредит» или «разпределяне на наличности» се появява в трасето само ако някой го е отбелязал в кода. Автоматичното инструментиране дава добра отправна точка, не края на работата.

Какво да се следи във всеки отрасъл

Това са илюстративни сценарии, без клиенти и без измерени цифри. Всеки от тях минава по една и съща верига: метрика, която предупреждава, трасе, което ограничава пътя, лог, който дава детайла.

Банки: преводи и авторизации. В метриките се следи времето, за което отговарят 95 % от преводите, и честотата на грешките при авторизация. Когато тези стойности се покачат, exemplar отваря трасето на един бавен превод; трасето показва, че времето е отишло в заявката към основната система, а логът със същия trace_id казва, че е изтекло времето за изчакване в пула от връзки. С тази верига, изградена и изпробвана, да се знае къде и защо спира да зависи от събирането на пет екипа; времето, което ще отнеме, зависи от това дали връзката е настроена както е описано по-горе. Предупреждение: тези метрики служат за експлоатация, не за съгласуване [9].

Финтех: отворени API. Партньор, който ползва Вашите API, съобщава, че «понякога» плащанията се провалят. Без телеметрия това е анекдот. С трасета може да се търсят само неуспешните операции на този маршрут и да се види дали съвпадат със забавянето на външна антифрод заявка. Следят се още честотата на грешките по партньор, отказите заради лимит на заявките и латентността на известията (webhooks). Така «провали се нашата система» се отделя от «влоши се трета страна», с доказателства.

Застраховане: оферта и издаване. Една оферта отнема 40 секунди в пиковия час. Трасето разкрива, че всяка оферта запитва последователно три тарифни системи, а метриката за грешки показва, че една от тях се влошава по обяд. Решава се да се паралелизира или да се сложи кеш, а не да се «купят още сървъри». При издаването се измерва времето от край до край и къде се трупат опашките.

Ритейл: checkout и наличности. При промоция количката «се замисля». Метриките показват насищане на услугата за наличности; трасето разкрива, че всяко разглеждане на продукт я запитва дванадесет пъти. Коригира се причината, не симптомът. И тук се появява конкретен разход: ако метриките се етикетират по продукт или по клиент, кардиналността експлодира (по-долу).

Регулирана компания: фактуриране. Един одитор пита какво е станало във вторник със заявка за фактуриране. С идентификатора на трасето се възстановява пътят през всички системи, а в свързаните логове се вижда какво е направено и кога. С една уговорка: телеметрията помага да се разбере техническото поведение, но не замества формален одитен регистър — пълен, непокътнат и с одобрено съхранение. Трасетата се семплират и се пазят кратко; това се решава с Риск, Поверителност и Правен отдел, а не с техническа конфигурация.

Разходи и рискове: онова, което рядко се казва

В много случаи значимият разход идва от обема, кардиналността, съхранението, изчислението на заявките и експлоатацията; тежестта на всяка позиция зависи от платформата и от договора. Три решения тежат особено.

Кардиналност: всеки нов етикет е фактура

Кардиналността е броят на различните комбинации от етикети. В Prometheus всяка нова комбинация е нова серия, която консумира памет, диск и изчислителна мощ. Ръководството на проекта препоръчва кардиналността на всяка метрика да се държи под 10 и, ако надхвърли около 100 или може да расте без предел, да се търси друго решение; примерът му е ясен: 10 000 възела с десетки файлови системи дават около 100 000 серии, приемливо, но добавянето на квота по потребител води до милиони [10]. Не се ползват етикети и за идентификатори на потребители или имейли [11]. Тези цифри са ръководство за практики на проекта, не твърд технически лимит.

Loki има своя версия: етикети с неограничени стойности налагат изграждането на огромен индекс и хиляди миниатюрни блокове и системата работи много зле. Ръководството на Grafana —цифра на доставчик— предлага да не се надхвърлят 10 до 15 етикета и идентификаторите да се преместят в съдържанието или в структурираните метаданни [14].

Преведено на езика на бизнеса: при промоцията в края на годината от сценария за ритейл, ако всеки клиент е етикет, сметката и забавянето растат точно когато системата е най-нужна.

Лични данни: онова, което не се излъчва, не изтича

Логовете и трасетата имат лошия навик да улавят повече от нужното. Услуга, която по грешка записва пълното име и документа за самоличност на онзи, който качва файл, оставя този текст в хранилището, с неговото съхранение, на разположение на всеки, който има достъп до таблото. OpenTelemetry е категоричен: не може да знае кое е чувствително във Вашия контекст, регулаторната отговорност е на онзи, който внедрява, и да се избегне излъчването на данните е по-добре, отколкото да се поправя после; предупреждава дори, че прилагането на hash върху идентификатор може да не даде анонимност, когато вселената от стойности е малка [42].

Collector предлага процесори за премахване или преобразуване на атрибути, но е добре да се прецени зрелостта им: за логове redaction и filter фигурират в алфа, а transform — в бета [43]. Да се опре цялата защита на алфа компонент е крехко. Разумната практика са две бариери: да не се излъчват данните от приложението и, като втора линия, да се филтрира в Collector. В Мексико действащият Федерален закон за защита на личните данни, държани от частни лица (публикуван в Официалния вестник на 20 март 2025 г., който отмени закона от 2010 г.), има за цел да регулира законосъобразна, контролирана и информирана обработка и задължава отговорното лице да поддържа административни, технически и физически мерки за сигурност [45]; какво се съхранява и за колко време се валидира с Поверителност и Правен отдел.

Съхранение и диск: никой не го решава вместо Вас

Kubernetes не съхранява логове дългосрочно, а Docker по подразбиране може да напълни диска [27][28]. Дългосрочното съхранение е решение на хранилището и на бизнеса и трябва да различава метрики, логове, трасета и регулаторни доказателства. Не включваме цифри за съхранение, нито цени, защото зависят от доставчика и от договора; всяка цитирана без тези данни е предположение.

Кой какво вижда и кой го експлоатира. Таблата на Grafana показват онова, което съдържат логовете и трасетата, затова достъпът се проектира по области: всеки екип вижда таблата и източниците, които му съответстват, а онези, които преглеждат логове с лични данни, са по-тясна група от тези, които гледат графика на латентността. А експлоатацията на този набор от инструменти изисква поне един човек, който разбира заявките (PromQL, LogQL, TraceQL) и Collector; това е човешки разход, не само на инфраструктура, който е добре да се отчете от самото начало.

Към това се добавя семплирането: съхраняването на всички трасета е скъпо, а съхраняването само на някои налага да се реши кои, например всички, които се провалят, и част от здравите. При семплиране, което се прави в gateway, маршрутизирането трябва да изпраща всички span-ове на едно и също трасе към един и същ събирач [8]. И една бележка за доставката при протокола: при преходни сривове една имплементация може да опита изпращането отново; ако не е получила потвърждение, това може да породи дубликати. Затова съхранението и заявките трябва да ги понасят, без да се приема гарантирана доставка [4].

Как да започнете, без да искате да направите всичко

1. Изберете един критичен бизнес поток, не «цялата система». Превод, оферта, checkout, фактура. Ако се провали, боли; затова се инструментира първи.
2. Определете предварително трите или четирите въпроса, на които искате да можете да отговорите, и сигнала, който им отговаря: какво измерва метриката, какво отбелязва трасето, какво трябва да каже логът?
3. Договорете имената от самото начало. Последователно име на услугата и среда във всичките три сигнала струват повече от всяко табло [46].
4. Започнете с онова, което не изисква да се пипа софтуерът. Агент, който чете стандартния изход и, в Java, автоматичното инструментиране дават първи поглед за кратко време [36][37].
5. Инструментирайте отвътре онова, което е важно за бизнеса: стъпките на този поток, с trace_id във всеки ред на лога.
6. Определете правила за кардиналност и за лични данни, преди да отворите крана: списък на разрешените атрибути, кои данни не се излъчват и кой решава съхранението.
7. Изпробвайте връзката от край до край: от щракването върху графиката към трасето и от трасето към лога. Ако някой скок се провали, тогава се научава какво е липсвало, а не при реален инцидент.
8. Оттеглете онова, което вече няма поддръжка. Ако има Promtail, планирайте миграцията [22].

Преди да започнете, добре е да се уговори писмено, за първия поток: кой поток се включва, кой е негов собственик, базовата линия и целта за латентност и грешки, минималното покритие с трасета, забранените атрибути, съхранението, месечният бюджет и тестът за връзка от метриката към трасето и към лога.

Да се знае кой инструмент съществува е лесната част. Трудното е да се знае коя част от Вашата платформа вече излъчва нужното, какво може да се наблюдава, без да се пипа софтуерът, и какво изисква инструментиране, къде днес в логовете се промъкват лични данни и какъв разход носи всяко решение. Това преглеждаме при една диагностика: предаваме Ви карта на сигналите на критичните Ви потоци, таблицата какво се покрива с агент и какво изисква инструментиране, инвентара на личните данни, които днес стигат до логовете, факторите на разхода, които тежат най-много във Вашия случай, и препоръчаната последователност за внедряване, за да решават ИТ, сигурността, рискът и бизнесът с една и съща информация.