Що таке OpenTelemetry і як він може покращити якість серверної частини?

Раніше, коли ми говорили про бекенд, ми зазвичай мали на увазі одну велику програму з єдиною великою базою даних, а для моніторингу було достатньо журналювання. Тепер, завдяки таким технологіям, як Kubernetes , мікросервіси стали стандартом. Додатків стало більше і вони розповсюдженіші, а традиційного журналювання вже недостатньо для налагодження та діагностики проблем у наших додатках.

Відмінним рішенням для організації моніторингу є OpenTelemetry — сучасний інструментарій, який можна використовувати для налагодження та аналізу продуктивності розподілених систем.

Ця стаття призначена для ІТ-фахівців, які прагнуть розширити свої знання з оптимізації серверної частини. Нижче ми детально розповімо, що таке OpenTelemetry, його ключові концепції та проблеми, які він допомагає вирішити. Якщо вам цікаво, як OpenTelemetry може змінити ваш підхід до моніторингу та налагодження серверних систем, підвищивши їх надійність і ефективність — читайте далі.

Коротка історія OpenTelemetry

Великі технологічні компанії вперше зіткнулися з проблемою розподіленого журналювання та трасування наприкінці 2000-х років. У 2010 році Google опублікував статтю, Dapper, інфраструктура відстеження великомасштабних розподілених систем , який заклав основу для інструменту відстеження Twitter, Zipkin, випущеного в 2012 році.

У 2014 році з’явився Kubernetes, який значно спростив розробку мікросервісів та інших розподілених у хмарі систем. Це призвело до того, що багато компаній зіткнулися з проблемами розподіленого журналювання та трасування в мікросервісах. Для стандартизації розподіленого трасування було створено стандарт OpenTracing, прийнятий CNCF, і проект Google OpenCensus.

У 2019 році проекти OpenTracing і OpenCensus оголосили про злиття під назвою OpenTelemetry. Ця платформа поєднує найкращі практики, накопичені протягом багатьох років, що дозволяє бездоганно інтегрувати трасування, журналювання та показники в будь-яку систему, незалежно від її складності.

Сьогодні OpenTelemetry — це не просто проект; це промисловий стандарт для збору та передачі телеметричних даних. Він розроблений і підтримується спільнотою спеціалістів і провідних компаній, таких як Google і Microsoft. Проект продовжує розвиватися, отримуючи нові можливості для спрощення процесу інтеграції та використання.

Що всередині?

OpenTelemetry — це комплексний набір методів і інструментів, які визначають, які сигнали може генерувати програма для взаємодії із зовнішнім світом, а також як ці сигнали можна збирати та візуалізувати для моніторингу стану програм і системи в цілому. Три основні типи сигналів: трасування, журналювання та збір показників .

**Давайте детальніше розглянемо кожен компонент: \

Контексти

OpenTelemetry представляє концепцію контекстів операцій. Контекст насамперед включає такі атрибути, як `trace_id` (ідентифікатор поточної операції) і `span_id` (ідентифікатор підзапиту, причому кожна повторна спроба підзапиту має унікальний `span_id` ).

Крім того, контекст може містити статичну інформацію, таку як ім’я вузла, де розгорнуто додаток, або ім’я середовища (prod/qa). Ці поля, відомі як ресурси в термінології OpenTelemetry, додаються до кожного журналу, метрики або трасування для полегшення пошуку. Контексти також можуть включати динамічні дані, як-от ідентифікатор поточної кінцевої точки ( `http_path: "GET /user/:id/info"` ), які можна вибірково приєднувати до груп журналів, показників або трасувань.

Контексти OpenTelemetry можна передавати між різними програмами за допомогою протоколів розповсюдження контексту. Ці протоколи складаються з наборів заголовків, які додаються до кожного запиту HTTP або gRPC або заголовків повідомлень для черг. Це дозволяє прикладним програмам реконструювати контекст операції з цих заголовків.

Ось кілька прикладів розповсюдження контексту:

1. B3-Propagation Це набір заголовків ( x-b3-* ), спочатку розроблених для системи трасування Zipkin. Він був адаптований до OpenTracing і використовується багатьма інструментами та бібліотеками. B3-Propagation містить trace_id / span_id і позначку, яка вказує, чи потрібна вибірка.

   
   

2. Контекст трасування W3C Цей стандарт, розроблений робочою групою W3C, об’єднує різні підходи до розповсюдження контексту в єдиний стандарт і є типовим у OpenTelemetry. Хорошим прикладом застосування цих стандартів є відстеження виконання запиту, що проходить через мікросервіси, реалізовані за допомогою різних технологій, без шкоди для моніторингу та точності налагодження.

Калькування

Відстеження — це процес запису та подальшої візуалізації часової шкали шляху запиту через кілька мікросервісів.

У візуалізації кожен стовпчик називається "span" і має унікальний "span_id" . Кореневий діапазон називається "trace" і має "trace_id" , який служить ідентифікатором для всього запиту.

Цей вид візуалізації дозволяє:

• Аналізуйте час виконання запитів у різних системах і базах даних, щоб виявити вузькі місця, які потребують оптимізації.
• Виявляти циклічні залежності між службами.
• Знайти повторювані запити. Використовуючи дані відстеження, ви також можете створити додаткову аналітику, наприклад створити карту мікросервісів або розподілити час між різними системами під час обробки операцій. Навіть якщо ви не використовуєте дані трасування для візуалізації часових шкал, OpenTelemetry все одно генерує trace_id і span_id для використання в інших сигналах.

Журнали

Незважаючи на уявну простоту, журналювання залишається одним із найпотужніших інструментів для діагностики проблем. OpenTelemetry покращує традиційне журналювання, додаючи контекстну інформацію. Зокрема, якщо наявна активна трасування, атрибути trace_id і span_id автоматично додаються до журналів, пов’язуючи їх із часовою шкалою трасування. Крім того, атрибути журналу можуть містити статичну інформацію з контексту OpenTelemetry, таку як ідентифікатор вузла, а також динамічну інформацію, як-от поточний ідентифікатор кінцевої точки HTTP (`http_path: "GET /user/:id"`).

Використовуючи `trace_id`, ви можете знайти журнали всіх мікросервісів, пов’язаних із поточним запитом, тоді як `span_id` дозволяє розрізняти підзапити. Наприклад, у разі повторних спроб журнали різних спроб матимуть різні span_id. Використання цих ідентифікаторів дозволяє швидко аналізувати поведінку всієї системи в режимі реального часу, прискорюючи діагностику проблем і підвищуючи стабільність і надійність.

Метрики

Збір показників надає кількісні дані про продуктивність системи, наприклад затримку, частоту помилок, використання ресурсів тощо. Моніторинг метрик в режимі реального часу дозволяє оперативно реагувати на зміни продуктивності, запобігати збоям і виснаженню ресурсів, а також забезпечувати високу доступність і надійність програми для користувачів.

Інтеграція з метричними системами зберігання та візуалізації, такими як Prometheus і Grafana, полегшує візуалізацію цих даних, значно спрощуючи моніторинг.

Метричні колекціонери

Збірники метрик OpenTelemetry сумісні зі стандартами Prometheus і OpenMetrics, що дозволяє легко перейти до рішень OpenTelemetry без значних змін. OpenTelemetry SDK дозволяє експортувати приклади trace_id разом із показниками, що дає змогу співвідносити показники з прикладами журналів і трасуваннями.

Кореляція сигналів

Разом журнали, показники та трасування створюють повне уявлення про стан системи:

• Журнали містять інформацію про системні події, що дозволяє швидко ідентифікувати та виправляти помилки.
• Показники відображають якісні та кількісні показники продуктивності системи, наприклад час відгуку або рівень помилок.
• Трасування доповнює цей погляд, показуючи шлях виконання запиту через різні компоненти системи, допомагаючи зрозуміти їхні взаємозв’язки. Чітка кореляція між журналами, трасуваннями та метриками є відмінною рисою OpenTelemetry. Наприклад, Grafana дозволяє користувачам бачити відповідні показники трасування та запитів під час перегляду журналу, що значно підвищує зручність використання та ефективність платформи.

На додаток до трьох основних компонентів OpenTelemetry включає концепції відбору проб, багажу та управління контекстом операцій.

Відбір проб

У високонавантажених системах обсяг журналів і трасувань стає величезним, що вимагає значних ресурсів для інфраструктури та зберігання даних. Щоб вирішити цю проблему, стандарти OpenTelemetry включають вибірку сигналу — можливість експортувати лише частину трасувань і журналів. Наприклад, ви можете експортувати детальні сигнали з відсотка запитів, тривалих запитів або запитів про помилки. Цей підхід дозволяє отримати достатню вибірку для побудови статистики, заощаджуючи при цьому значні ресурси.

Однак, якщо кожна система самостійно вирішує, які запити відстежувати детально, ми отримуємо фрагментований перегляд кожного запиту. Деякі системи можуть експортувати детальні дані, тоді як інші можуть експортувати лише частково або не експортувати взагалі.

Щоб вирішити цю проблему, механізми розповсюдження контексту OpenTelemetry передають позначку вибірки разом із `trace_id`/`span_id`. Це гарантує, що якщо початкова служба, яка отримує запит користувача, вирішить, що запит слід детально відстежувати, усі інші системи підуть за цим прикладом. В іншому випадку всі системи повинні частково або не експортувати сигнали для збереження ресурсів. Цей підхід називається «Вибірка заголовка» — рішення, яке приймається на початку обробки запиту випадковим чином або на основі деяких вхідних атрибутів.

Крім того, OpenTelemetry підтримує «хвостову вибірку», коли всі програми завжди експортують усі сигнали в деталях, але існує проміжний буфер. Після збору всіх даних цей буфер вирішує, зберігати дані повністю чи лише часткову вибірку. Цей метод дозволяє отримати більш репрезентативну вибірку кожної категорії запитів (успішно/тривало/помилка), але вимагає додаткового налаштування інфраструктури.

Багаж

Механізм багажу дозволяє передавати довільні пари ключ-значення разом із trace_id / span_id , автоматично передаючи між усіма мікросервісами під час обробки запиту. Це корисно для передачі додаткової інформації, необхідної по всьому шляху запиту, наприклад інформації про користувача або параметрів середовища виконання.

Приклад заголовка для передачі багажу за стандартом W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Ось кілька прикладів використання багажу:

• Передача бізнес-контексту Інформацію, таку як userId , productId або deviceId можна передати через усі мікросервіси. Програми можуть автоматично реєструвати цю інформацію, дозволяючи пошук у журналі за контекстом користувача для вихідного запиту.

• Спеціальні налаштування параметрів конфігурації для SDK або інфраструктури.

• Прапори маршрутизації Прапори, які допомагають балансувальникам навантаження приймати рішення щодо маршрутизації. Під час тестування деякі запити може знадобитися скеровувати до фіктивних серверних програм. Оскільки багаж передається автоматично через усі служби, немає потреби створювати додаткові протоколи — просто налаштуйте правило на балансирі навантаження.

  
  

Впровадження інфраструктури

Реалізація OpenTelemetry на рівні інфраструктури передбачає інтеграцію серверних модулів OpenTelemetry в архітектуру програми та налаштування інфраструктури для агрегації даних.

Процес складається з чотирьох етапів:

1. Інтеграція додатків На першому етапі пакети SDK OpenTelemetry безпосередньо інтегруються в додатки для збору показників, журналів і трасування, забезпечуючи безперервний потік даних про продуктивність кожного компонента системи.

   
   

2. Налаштування експортерів. Зібрані дані спрямовуються з додатків через експортери до зовнішніх систем для подальшої обробки, таких як журналювання, моніторинг, трасування або системи аналітики, залежно від ваших потреб.

   
   

3. Агрегація та зберігання Цей етап може включати нормалізацію даних, збагачення їх додатковою інформацією та об’єднання даних із різних джерел для створення єдиного уявлення про стан системи.

   
   

4. Візуалізація даних Нарешті, оброблені дані представлені як інформаційні панелі в таких системах, як Grafana (для показників і трасування) або Kibana (для журналів). Це дозволяє командам швидко оцінювати стан системи, виявляти проблеми та тенденції та налаштовувати сповіщення на основі згенерованих сигналів.

Реалізація програми

Для інтеграції з програмою вам потрібно підключити відповідний OpenTelemetry SDK для використовуваної мови програмування або використовувати бібліотеки та фреймворки, які безпосередньо підтримують OpenTelemetry. OpenTelemetry часто реалізує широко використовувані інтерфейси з відомих бібліотек, дозволяючи вставні заміни. Наприклад, бібліотека Micrometer зазвичай використовується для збору показників в екосистемі Java. OpenTelemetry SDK забезпечує реалізацію інтерфейсів Micrometer, що дозволяє експортувати показники без зміни основного коду програми. Крім того, OpenTelemetry пропонує реалізацію старіших інтерфейсів OpenTracing і OpenCensus, що сприяє плавному переходу на OpenTelemetry.

Висновок

В ІТ-системах OpenTelemetry може стати ключем до майбутнього надійних і ефективних серверних програм. Цей інструмент спрощує налагодження та моніторинг, а також відкриває можливості для глибокого розуміння продуктивності додатків та оптимізації на новому рівні. Приєднуйтеся до спільноти OpenTelemetry, щоб допомогти сформувати майбутнє, у якому розробка бекенда буде простішою та ефективнішою!