Стаття також доступна російською (перейти до перегляду).

Зміст:

• Початкові відомост
• Що таке Grafana Tempo та чим відрізняється від інших рішень
• Як працює Tempo
• Які потрібні компоненти для довершеного трейсінгу
• Як використовувати Tempo разом із Grafana, Prometheus та Loki
• Приклади застосування
• Переваги та недоліки
• Кінцеві зауваження

DevOps-команди часто стикаються з ситуаціями, коли частина запитів в розподіленій системі несподівано сповільнюється або навіть “падає”. В логах — тиша, моніторинг метрик показує лише загальні коливання навантаження, а зрозуміти, що саме стало причиною, складно. У таких випадках на допомогу приходить трасування — технологія, що дозволяє “побачити” шлях запиту крізь усі сервіси.

Grafana Tempo — це система зберігання і обробки трейсов, яка інтегрується з інструментами моніторингу і спрощує аналіз розподілених систем. Вона дає змогу побудувати ефективну Observability-інфраструктуру без великих витрат на зберігання. У цій статті ми розглянемо, як працює Grafana Tempo, чим вона відрізняється від інших рішень і як її використовувати на практиці.

Початкові відомост

Моніторинг будь-якої Distributed tracing системи дозволяє вирішити ряд завдань, основними з яких є:

• Аналіз трендів;

• Виявлення «дірок» в безпеці;

• Оцінювання рівня продуктивності системи;

• Виявлення причин виникаючих проблем у роботі;

• Звітність.

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

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

В DevOps трейсінг реалізується шляхом інструментування додатку за допомогою одного з протоколів трасування. 

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

Для інструментації краще використовувати протоколи, котрі не залежать від середовища виконання додатку, інфраструктури та мови програмування. Найбільш розповсюдженими протоколами для трейсінгу є OpenTelemetry,  Jaeger та Zipkin. 

«На виході» інструментованого додатку можуть з’являтися три типи даних – трейси, метрики та журнали.  

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

Журнали (logs) є повідомленнями із відміткою часу, котрі генеруються компонентами розподіленої системи. Зазвичай вони не прив’язуються до визначеної транзакції чи запиту, а є показником станів компоненту чи системи на визначеному проміжку часу та використовуються у складі трейсів.    

Трейси (traces) забезпечують «прозорість» виконання запитів, котрі розповсюджуються у межах розподіленої системи. Включають один або кілька діапазонів із посиланнями на журнали. Зберігаються у так званих розподілених бекендах трейсів. 

Діапазон (span) або інтервал є окремою одиницею для операцій, котрі виконуються запитами. Це дозволяє відслідковувати операції із прив’язкою до часу їх виконання. Діапазони включають ім’я, повідомлення журналу, пов’язані із часом дані та атрибути із додатковою інформацією про операції. Приклади атрибутів: client.address, url.scheme, server.address, server.port. 

Нижче наведений приклад отриманих результатів виконання запиту до інструментованого додатку по слову greetings, представлених у форматі JSON:

greetings span:
{
  "name": "greetings",
  "context": {
    "trace_id": "3b9ab1a5d8c671n6561ch97508s57dc3",
    "span_id": "031691vf3kc37m16"
  },
  "parent_id": null,
  "start_time": "2025-06-10T09:47:35.125307Z",
  "end_time": "2025-06-10T09:47:35.125716Z",
  "attributes": {
    "http.route": "some_route3"
  },
  "events": [
    {
      "name": "Greetings to you!",
      "timestamp": "2025-06-10T09:47:35.125507Z",
      "attributes": {
        "event_attributes": 1
      }
    }
  ]
}

Тут поле trace_id визначає ідентифікатор трейсу для кореневого проміжку маршруту виконання запиту. Ознакою цього є нульове значення поля parent_id для батьківського рівня. Поле span_id зберігає ідентифікатор діапазону. 

Фіксація взаємовідносин між ділянками коду або вузлів кластеру дозволяє у подальшому візуалізувати їх за допомогою каскадних діаграм, приклад якої наведений на Малюнку 1. 

Малюнок 1. Приклад каскадної діаграми візуалізації трейсів.  

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

Що таке Grafana Tempo та чим відрізняється від інших рішень

Grafana Tempo це програмна платформа, котра включає повний набір компонентів для реалізації «життєвого циклу» трейсінгу для локальних та розподілених систем. Наведемо основні компоненти платформи:

• Засоби інструментації додатку;

• Конвеєр трейсів;

• Розподілений бекенд для вибірки та зберігання трейсів;

• Засоби візуалізації трейсів.  

На Малюнку 2 представлена взаємодія між вказаними компонентами. 

Малюнок 2. Схема взаємодії між компонентами Grafana Tempo. 

У блоці № 1 здійснюється інструментація клієнтського додатку шляхом додавання точок інструментації для створення та розвантаження span-діапазонів. 

Блок № 2 забезпечує вивантаження span-діапазонів із додатку, їх буферизацію та пересилання у бекенд на зберігання. Блок є необов’язковим, оскільки більшість клієнтів можуть самостійно пересилати дані на бекенд.   

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

Блок № 4 забезпечує процес візуалізації трейсів, переданих із блоку № 3. Виділимо деякі з можливостей платформи стосовно візуалізації результатів трейсінгу:

• Перегляд трейсів разом із логами та метриками у межах однієї панелі моніторингу;

• Здійснення миттєвого переходу від метрик до трейсів співвідносно до часової шкали;

• Створення додаткових панелей моніторингу для роботи із різними типами даних без зміни інструментарію.

У порівнянні із багатьма своїми аналогами Grafana Tempo має більш ефективну модель бекенду за рахунок відсутності індексації даних трейсінгу та компактності їх зберігання, що зменшує вартість обслуговування системи. 

Найближчий аналог платформи – відома система трейсінгу Jaeger. Кожна з платформ має свої особливості та рекомендації до застосування. Їх порівняльна характеристика за основними параметрами представлена у Таблиці 1. 

Таблиця 1. Порівняльна характеристика платформ для трейсінгу

Як працює Tempo

Як вже зазначалося, Tempo є реалізацією розподіленого бекенду трейсів системи Grafana Tempo та забезпечує зберігання трейсів та їх видачу за запитом. Окрім того, він має незалежний генератор метрик, котрий за потреби можна підключити до системи. 

Модуль був розроблений спеціально для середовища Grafana і тому він не має окремого інтерфейсу та візуалізатора. Він інтегрується із системою моніторингу Prometheus, системою збору та обробки логів Loki від Grafana Labs та панелями моніторингу Grafana. 

На Малюнку 3 представлені основні компоненти модулю та їх структурна взаємодія.

Малюнок 3. Компоненти модулю Tempo.

Розглянемо роботу Tempo на рівні його компонентів.

Distributor – забезпечує прийом span-діапазонів у найбільш розповсюджених форматах –  OpenTelemetry, Jaeger та Zipkin, та передає їх до інжестору.

Ingester – упаковує отримані від дистриб’ютору трейси у окремі блоки зі створенням індексів та фільтрів відповідно до наступного шаблону:

<blockID> /<meta.json>
          /<index>
          /<data>
          /<bloom_0>
          /<bloom_1>
          /<bloom_2>
           .....
          /<bloom_M>

Після цього підготовлені дані передаються до backend-сховища. 

Storage – backend-сховище для трейсів, котрі зберігаються там у вигляді блоків у одній із об’єктних баз даних без індексації. 

Query Frontend – підготовлює простір blockID для вхідних запитів, перетворюючи його на набір окремих сегментів. 

Querier – забезпечує пошук трейсів у системі за їх ID.

Compactors – регулює кількість блоків у системі за рахунок використання серверного сховища.   

Metrics generator – автономний генератор метрик із отриманих системою трейсів, котрі потім пересилаються на Metrics backend на зберігання. Під’єднується за потреби.  

Які потрібні компоненти для довершеного трейсінгу

Реалізувати ефективну систему трейсінгу неможливо, якщо вона буде ізольованою від інших технологій. Саме тому з’явилася практика побудови систем трейсінгу у складі загальних систем спостереження або Observability-систем. Лише в цьому випадку можна отримати вичерпну інформацію про характеристики будь-якої розподіленої системи ззовні, не втручаючись у її роботу.

Наведемо приблизний склад компонентів, необхідних для побудови ефективної Observability-системи напрямку DevOps:

• Засоби автоматизації інструментування додатків;

• Система збору та збереження логів;

• Система збору та збереження метрик;

• Засоби збору трейсів;

• Розподілений бекенд трейсінгу;

• Незалежний засіб генерування та передачі повідомлень клієнтам;

• Гнучка система пошуку;

• Корелятор frontend та backend частин системи;

• Аналізатор та візуалізатор отриманих даних – логів, метрик та трейсів.

Нижче буде розглянуто приклад Observability-системи, котра у своєму складі має основні з вказаних компонентів.

Як використовувати Tempo разом із Grafana, Prometheus та Loki

Для початку, визначимося із призначенням складових елементів нашої Observability-системи. 

Tempo – джерело трейсів.

Loki – джерело логів. Включає сервер для їх зберігання і обробки, а також агент для збору та передачі логів іншим компонентам. У якості агента зазвичай використовується засіб Promtail. Його основні завдання – виявлення локальних логів; призначення лейблів потокам логів та їх передача в інстанс Grafana Loki.  

Prometheus – джерело метрик, котрі збираються через рівні інтервали часу для визначених цілей. Надає результати та активує повідомлення при виконанні зазначених умов. Особливість – час зберігання метрик обмежений двома тижнями і тому часто використовується для «легкого» запуску в контейнерах.

Alertmanager – компонент системи моніторингу Prometheus, котрий відповідає за оповіщення клієнтських додатків.

Cortex – довгострокове сховище для віддаленого запису результатів роботи Prometheus.

Grafana – аналізатор та візуалізатор для логів, метрик та трейсів. Надає інтерфейс для формування запитів на доставку даних у потрібному форматі та розрізі в незалежності від місця їх розміщення. 

Для можливості сумісного використання вказаних технологій необхідно виконати ряд підготовчих етапів:

1. Створити кластер Kubernetes та підготувати консольну утиліту Kubectl і засіб упакування Helm;

2. Створити окремий простір імен Kubernetes для вказаної конфігурації;

3. Клонувати Helm-чарти Grafana на свою локальну машину;

4. Розгорнути Loki за допомогою Helm-чартів;

5. Розгорнути Tempo за допомогою Helm-чартів;

6. Розгорнути стек Grafana+Prometheus шляхом  встановлення у створеному кластері репозиторію Kube-Prometheus; 

7. Під’єднати сховище Cortex;

8. Авторизуватися в Prometheus за адресою http://localhost:9090/; 

9. Авторизуватися в Alertmanager за адресою http://localhost:9093/ та створити оповіщення;

10. Авторизуватися в Grafanaза адресою http://localhost:3000/ та додати джерела даних.

Якщо все виконано вірно, ви повинні отримати список під’єднаних джерел даних у вікні конфігурації панелі Grafana, як показано нижче.

Перегляд трейсів

Для перегляду трейсів засобами Grafana сконфігурованої системи необхідно створити додаток та розгорнути його, наприклад, за допомогою yaml-файлу. 

Після того, як додаток буде розгорнуто, до нього треба отримати доступ. Це можна зробити через взаємозаміну портів, виконану у консолі kubectl за допомогою наступної команди: 

kubectl port-forward service/apptest -n observability 3001:8080

Тут apptest – назва нашого додатку.

У цьому випадку результат роботи додатку можна продивитися за адресою: http://127.0.0.1:3001/ .

Виконавши кілька кліків на сторінці додатку, ми, таким чином, запустимо процес генерування запитів / трейсів, котрі можна одразу ж переглянути у панелі Grafana. 

Для цього у вікні вказаної панелі слід виконати наступні дії:

1. Натиснути кнопку Explore та у списку, що з’явиться обрати джерело даних із ім’ям Loki;

2. У блоці із ім’ям Labels обрати елемент app та назву додатку, котрий тестується (у нашому випадку – apptest);

3. Натиснути кнопку Run Query, розташовану у верхній частині вікна, після чого у його нижній частині отримати список логів;

4. За допомогою миші розгорнути дані будь-якого із записів логів та клікнути по кнопці із назвою Tempo;

5. У розділі Tempo UI блоку Trace View стане доступною інформація про трейси.   

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

Приклади застосування

За цією адресою можна ознайомитися з прикладом реалізованої системи розподіленого трейсінгу на основі OpenTelemetry, побудованої на базі технологій Tempo, Grafana, Prometheus, Loki та Python Flask.

Переваги та недоліки

Виділимо позитивні сторони використання системи трейсінгу, побудованої на базі компонентів Grafana + Tempo:

• «Все в одному» – компоненти входять до єдиного стеку технологій від Grafana Labs, що полегшує їх сумісне використання та підвищує можливості системи;

• Спрощена інфраструктура, котра орієнтована на легке масштабування;

• Простота розгортання та налаштувань;

• Ефективна модель сховища;

• Економія ресурсів та низькі витрати на забезпечення роботи.  

Також вкажемо на декотрі недоліки системи:

• Неможливість виконання пошуку за тегами та атрибутами;

• Необхідність знання ID трейсів при виконанні пошуку;

• Часткове обмеження інтеграції із технологією OpenTelemetry.

Кінцеві зауваження

При виборі стеку технологій для побудови системи трейсінгу для власного проекту слід керуватися, насамперед, потребами проекту в залежності від мети його створення та технічних вимог. Наприклад, у випадку більш «стаціонарних» потужних проектів без необхідності виконання частих масштабувань, може підійти система на основі Jaeger. 

Для порівняно «легких» та «економічних» продакшн-проектів із перспективою подальшого їх розширення доцільно застосування системи Distributed tracing на основі Grafana Tempo. Це дозволить спростити її масштабування та уникнути зайвих витрат на забезпечення зберігання даних.  

У себе в проектах для збору трейсів ми використовуємо OpenTelemetry — відкритий стандарт, що підтримує інструментацію для великої кількості мов програмування, включно з Go, Java, Python, PHP, .NET, JavaScript та іншими. OpenTelemetry має гнучкий SDK і добре інтегрується з Tempo, що дозволяє швидко налаштувати повний цикл трасування — від клієнта до бази даних.

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

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

Дата: 18.06.2025 Автор: Олександр Ровник #devops#docker#grafana

Голосування 1 2 3 4 5