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

Содержание:

• Начальные сведения
• Что такое Grafana Tempo и чем отличается от других решений
• Как работает Tempo
• Какие нужны компоненты для совершенного трейсинга
• Как использовать Tempo вместе с Grafana, Prometheus и Loki
• Примеры применения
• Достоинства и недостатки
• Конечные замечания

DevOps-команды часто сталкиваются с ситуациями, когда часть запросов в распределенной системе неожиданно замедляется или даже падает. В логах – тишина, мониторинг метрик показывает только общие колебания нагрузки, а понять, что именно явилось причиной, сложно. В таких случаях на помощь приходит трассировка – технология, позволяющая "увидеть" путь запроса через все сервисы.

Grafana Tempo – это система хранения и обработки трейсов, которая интегрируется с инструментами мониторинга и упрощает анализ распределенных систем. Она позволяет построить эффективную Observability-инфраструктуру без больших затрат на хранение. В этой статье мы рассмотрим, как работает Grafana Tempo, чем она отличается от других решений и как ее использовать на практике.

Начальные сведения

Мониторинг любой Distributed tracing системы позволяет решить ряд задач, основными из которых являются:

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

• Выявление «дыр» в безопасности;

• Оценка уровня производительности системы;

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

• Отчетность.

Проведение мониторинга в микросервисных и распределенных архитектурах значительно усложняется, поскольку запросы и данные обычно проходят через большое количество компонентов, служб или хостов, неоднократно изменяя при этом направления движения 

Знание маршрутов движения пакетов данных в сети и последовательность шагов выполнения запроса в распределенном приложении решает указанную проблему и позволяет анализировать распределенную систему так же просто, как и локальную, разбивая сложный маршрут на отдельные участки. Итак, основная задача здесь – выявить маршрут движения данных или путь выполнения запросов во временном измерении и представить результат в удобном для анализа виде. Для этого используется трейсинг запросов – метод мониторинга работы распределенных систем, позволяющий отслеживать и анализировать маршрут движения данных или запросов. 

В DevOps трейсинг реализуется путем инструментирования приложения с помощью одного из протоколов трассировки. 

Инструментация приложения заключается в интеграции дополнительного кода или библиотеки в тело программы для сбора данных о движении запросов. Это обеспечивает фиксацию идентификаторов запросов, а также отметку времени начала и завершения выполнения операций и вызовов. Инструментацию можно производить в ручном режиме или в автоматическом с помощью специальных программных средств, что является более эффективным решением в случае распределенной системы. 

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

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

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

Журналы (logs) являются сообщениями с отметкой времени, генерируемыми компонентами распределенной системы. Обычно они не привязываются к определенной транзакции или запросу, а являются показателем состояния компонента или системы на определенном промежутке времени и используются в составе трейсов.    

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

Диапазон (traces) или интервал является отдельной единицей для операций, выполняемых запросами. Это позволяет отслеживать операции с привязкой ко времени их выполнения. Диапазоны включают имя, сообщения журнала, связанные со временем данные и атрибуты с дополнительной информацией об операциях. Примеры атрибутов: 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. Сравнительная характеристика платформ для трейсинга

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

Характеристика	Jaeger	Grafana Tempo
Модель хранилища (бэкенд)	Индексированные распределенные базы Elasticsearch и Cassandra	Объектные базы без индексации (Azure Blob, S3, GCS)
Масштабирование	Возможности мощные, но стоимостные и с большими операционными сложностями	Значительный потенциал за счет эффективной модели хранилища и простоты настроек
Настройка	Усложненное	Сравнительно простое
Рекомендуемые варианты развертывания	Файл в двоичном формате (для тестирования), Docker Compose, Kubernetes із Jaeger Operator	Файл в двоичном формате, Helm в Kubernetes
Поиск и фильтрация	Мощные возможности для поиска трейсов по разным поисковым параметрам	Посредственные возможности, нужен ID трейса, атрибутный поиск невозможен. Используется TraceQL
Рекомендации по использованию	Для автономных систем трейсинга с мощными возможностями поиска и фильтрации	Для сравнительно «легких» систем, уже использующих возможности Grafana
Интеграция	SDK и конвейеры OpenTelemetry, Prometheus через AlertManager, Zipkin, системы регистрации	SDK OpenTelemetry, протоколи Jaeger и Zipkin, Prometheus, Loki, Mimir, панели Grafana
Расходы на хранилище и инфраструктуру	Значительные	Незначительные

Как работает Tempo

Как уже отмечалось, Tempo является реализацией распределенного бэкенда трейсов системы Grafana Tempo и обеспечивает хранение трейсов и их выдачу по запросу. Кроме того, он имеет независимый генератор метрик, который при необходимости можно подключить к системе. 

Модуль был разработан специально для среды Grafana и поэтому у него нет отдельного интерфейса и визуализатора. Он интегрируется с системой мониторинга Prometheus, системой сбора и обработки логов Loki от Grafana Labs и панелями мониторинга Grafana. 

На Рисунке 3 представлены основные компоненты модуля и их структурное взаимодействие.

Рисунок 3. Компоненты модуля Tempo.

Рассмотрим работу Tempo на уровне его компонентов.

Distributor– обеспечивает прием span-диапазонов в наиболее распространенных форматах –  OpenTelemetry, Jaegeг и Zipkin, и передает их инжестору.

Ingester – упаковывает полученные от дистрибьютора трейсы в отдельные блоки с созданием индексов и фильтров в соответствии со следующим шаблоном:

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

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

Storage–backend-хранилище для трейсов, хранящихся там в виде блоков в одной из объектных баз данных без индексации. 

 Query Frontend – подготавливает пространство blockID для входящих запросов, превращая его в набор отдельных сегментов. 

 Опрашивающий – обеспечивает поиск трейсов в системе по их ID.

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

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

Какие нужны компоненты для совершенного трейсинга

Реализовать эффективную систему трейсинга невозможно, если она будет изолирована от других технологий. Именно поэтому появилась практика построения систем трейсинга в составе общих систем наблюдения или Observability-систем. Только в этом случае можно получить исчерпывающую информацию о характеристиках любой распределенной системы извне, не вмешиваясь в ее работу.

Приведем примерный состав компонентов, необходимых для построения эффективной Observability-системы направления DevOps:

• средства автоматизации инструментирования приложений;

• Система сбора и хранения логов;

• Система сбора и хранения метрик;

• Средства сбора трейсов;

• Распределенный бэкенд трейсинга;

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

• Гибкая система поиска;

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

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

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

Как использовать Tempo вместе с Grafana, Prometheus и Loki

Для начала, определимся с назначением составных элементов нашей Observability-системы. 

Tempo – источник трейсов.

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

Prometheus– источник метрик, собираемых через равные интервалы времени для определенных целей. Предоставляет результаты и активирует сообщение при выполнении указанных условий. Особенность – время хранения метрик ограничено двумя неделями и потому часто используется для «легкого» запуска в контейнерах.

Менеджер оповещений– компонент системы мониторинга Prometheus, отвечающий за оповещение клиентских приложений.

Кора головного мозга – долгосрочное хранилище для удаленной записи результатов работы 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 выбрать элемент приложение и указать название тестируемого приложения (в нашем случае — apptest);

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

4. С помощью мыши развернуть данные любой записи логов и кликнуть по кнопке с названием Tempo;

5. В разделе Tempo пользовательского интерфейса, в блоке Просмотр трассировки, станет доступна информация о трейсах.   

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

Примеры применения

По этому адресу можно ознакомиться с примером реализуемой системы распределенного трейсинга на основе 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