Пользователь сообщает о тормозах, а стандартные метрики на VPS не показывают отклонений? Рассказываем, как с помощью Grafana Tempo отследить каждый запрос, выявить задержки и точно определить узкие места в приложении.
Введение
Представьте такую картину: пользователь жалуется, что ваш сервис тормозит, а обычные метрики никак не выдают виновника. CPU в порядке, память тоже, а страница всё равно загружается вечность. Как разобраться, на каком этапе запрос притормозил? Здесь на помощь приходит распределённая трассировка. С её помощью можно проследить путь каждого запроса через все сервисы и выяснить, где он замедляется.
В статье рассказали, как внедрить трассировку в своё приложение с помощью Grafana Tempo. Объяснили, как установить Tempo, подключить его к Grafana и научиться отслеживать путешествия запросов, чтобы прокачать производительность приложения.
Что такое Grafana Tempo и зачем он нужен

Grafana Tempo — это бэкенд для распределённой трассировки. Он показывает, как запросы проходят через сервисы, где тормозят и сколько времени тратят на каждом шаге. Такая картина дополняет логи и метрики, добавляя третий ракурс наблюдения. Метрики сигнализируют о проблеме, логи рассказывают, где что случилось, а трассы объясняют, почему всё пошло не так.
Tempo собирает полный маршрут запроса от фронтенда до базы и внешних API. Он не требует сложных баз для индексов — трейсы сохраняются в объектном хранилище или даже на локальном диске. Запускается быстро, работает стабильно, собирает 100 % трассировок без пропусков. Нужный трейс потом легко найти по traceID.
В Grafana Labs Tempo переваривает до 170 тысяч спанов в секунду и хранит данные за две недели. Никаких Cassandra или Elasticsearch, только хранилище и простой доступ к трассам без сложной инфраструктуры.
Индексов в Tempo нет, но поиск остался удобным. TraceID можно вытащить из логов или метрик. Tempo тесно интегрирован с остальными инструментами Grafana. В Loki traceID кликается прямо из строки лога. В Prometheus можно включить экземпляры, они добавляют к графикам ссылку на конкретный запрос.
Так Tempo связывает воедино логи, метрики и трассы. Получается живая и цельная картина — от симптома до причины без скачек между системами.
Краткий обзор возможностей и преимуществ Grafana Tempo для трассировки запросов
Характеристика | Описание |
---|---|
Назначение | Распределённая трассировка запросов. |
Тип хранилища | Объектное хранилище или локальный диск. |
Индексы | Не используются (поиск по traceID через логи/метрики). |
Скорость обработки | До 170 000 спанов в секунду. |
Срок хранения данных | По умолчанию — 2 недели. |
Интеграции | Loki (из логов), Prometheus (из графиков), Grafana. |
Преимущества | Простота запуска, надёжность, полное покрытие трассировок. |
Установка Grafana Tempo
Для установки Grafana Tempo понадобится сервер с Docker, например, виртуальный от AdminVPS, или тестовая машина для запуска сервиса. Tempo работает как отдельный элемент инфраструктуры. Установить его можно через Docker, как бинарник или с помощью Helm-чарта в Kubernetes. Быстрее всего запустить Tempo в Docker-контейнере. Подходит для экспериментов и продакшена: достаточно вынести хранение данных за пределы контейнера.
Подготовка конфигурации
Tempo умеет принимать трассы по протоколам Jaeger, Zipkin, OpenTelemetry и сохранять их в объектное хранилище, например, S3, или на диск. Для простоты настройте локальное хранилище. Создайте файл tempo.yaml с минимальной конфигурацией:
server:
http_listen_port: 3200
# distributor:
# receivers:
# otlp:
# protocols:
# grpc:
# http:
compactor:
compaction:
block_retention: 24h
storage:
trace:
backend: local
local:
path: /var/tempo/traces
wal:
path: /var/tempo/wal
В конфиге задан порт 3200 для Grafana, локальное хранение данных и сутки на удержание трасс. Папки /var/tempo/traces и /var/tempo/wal будут использоваться внутри контейнера, их нужно примонтировать.
Запуск в Docker
Убедитесь, что Docker установлен. Выполните команду:
docker run -d --name tempo \
-v /opt/tempo/config.yaml:/etc/tempo/config.yaml \
-v /opt/tempo/data:/var/tempo \
-p 3200:3200 -p 4317:4317 -p 4318:4318 \
grafana/tempo:latest \
-config.file=/etc/tempo/config.yaml
Файл config.yaml монтируется внутрь контейнера. Директория /opt/tempo/data используется для хранения трасс и журнала записей. При перезапуске контейнера данные сохраняются. Порт 3200 открыт для Grafana, 4317 и 4318 — для получения трасс по OTLP (gRPC и HTTP). Указан актуальный образ Tempo и путь до конфигурационного файла.
После запуска Docker скачает образ и запустит контейнер. Убедитесь, что всё работает. Для этого выполните docker ps и найдите контейнер со статусом Up. Tempo готов принимать данные, хотя пока трасс в нём нет.
Подключение Tempo в Grafana
Откройте веб-интерфейс Grafana и добавьте источник данных. Перейдите в меню Administration → Data Sources, нажмите Add data source, выберите Tempo. В поле URL введите http://localhost:3200, если Grafana работает на той же машине. Если серверы разные, укажите IP-адрес или доменное имя сервера с Tempo и порт 3200. Остальные поля можно оставить по умолчанию. Нажмите Save & Test.
При успешной настройке Grafana подключится к Tempo и покажет зелёное сообщение. Источник трасс теперь доступен. Откройте вкладку Explore, выберите Tempo и попробуйте выполнить запрос. Пока трасс нет, в следующем шаге потребуется настроить отправку данных.
Инструментирование приложения и сбор трасс
Пора отправить реальные данные в систему трассировки. Tempo работает пассивно и ждёт поступления трасс от приложений или агентов. Для этого подключите в код библиотеки OpenTelemetry, настройте экспорт трасс в Tempo и добавьте создание спанов вокруг ключевых операций.
Используйте стандарт OpenTelemetry — набор библиотек и API для сбора трасс, метрик и логов. Воспользуйтесь готовыми инструментами под ваш стек:
- Java или Spring Boot. Подключите OpenTelemetry Java Agent. Добавьте JVM-опцию при запуске, агент начнёт автоматически собирать трассы (HTTP, база данных и др.). В Spring Boot используйте Micrometer Tracing — пара зависимостей, и микросервис начнёт отправлять спаны.
- Python. Установите opentelemetry-sdk и opentelemetry-instrumentation. С помощью пары строк кода инициализируйте трассировку. Flask и Django можно проинструментировать автоматически. Также доступна CLI-утилита opentelemetry-instrument — она запускает приложение с нужными интеграциями.
- Node.js. Используйте @opentelemetry/sdk-node. Он перехватывает запросы, работу с базами и отправляет спаны по адресу OTLP.
- Go. Подключите go.opentelemetry.io/otel и экспортёр. Несколько строк, и служба начнёт отправлять трассы.
- Для других языков (C#, C++, Ruby и т. д.) доступны аналогичные SDK. Tempo поддерживает протоколы Jaeger, Zipkin и OTLP, поэтому можно просто переадресовать уже существующие трассы в Tempo.
Пример: есть веб-сервис, требуется отследить путь HTTP-запроса. Выберите библиотеку OpenTelemetry, настройте экспортёр OTLP, укажите адрес Tempo, например, tempo.yourdomain.local:4317 для gRPC. После этого приложение начнёт формировать trace_id, спаны и отправлять их на нужный порт.
Проверьте результат: выполните несколько запросов. Если настройка корректна, трассы появятся в Tempo. Файлы с трассами можно найти в /opt/tempo/data, но вручную проверять их необязательно.
Анализ производительности по трассам
Теперь самое интересное. Tempo развёрнут, Grafana подключена, приложение отправляет трассы. Откройте в Grafana раздел Explore, выберите источник данных Tempo. В версии 9+ доступен удобный поиск трасс. Перейдите на вкладку Search и задайте фильтры: имя сервиса, название операции, статус, длительность, время. В поле Service name выберите имя приложения, обычно оно задаётся в OpenTelemetry. Запустите запрос без фильтров, чтобы увидеть последние трассы. Если данные поступали, отобразится список traceID с метаданными: время, длительность, имя сервиса.
Найдите самую долгую трассу или с ошибкой — они обычно выделены цветом. Кликните по ней, чтобы открыть детальную диаграмму трассировки. Увидите корневой спан, например, HTTP-запрос, и дочерние спаны — функции, запросы к базе, обращения к сервисам. Длина полосок отражает время выполнения каждого участка.
Так вы определите, на что ушло время. Например, запрос длился 1.2 секунды, из них 800 мс — запрос к базе, остальное — мелкие операции. Значит, узкое место — медленный SQL-запрос. Или сервис оплаты вызывает внешний API, который тормозит. После этого оптимизируйте базу, кешируйте или используйте асинхронную обработку. Без трассировки таких деталей не получить, пришлось бы гадать.
Кроме длительности трассы показывают ошибки. Проблемные спаны подсвечиваются красным. Если выпало исключение или HTTP 5xx, это видно на диаграмме. В распределённой системе из множества сервисов легко найти не только место ошибки, но и контекст, какой именно вызов виноват.
Tempo с версии 2.x поддерживает поиск по условиям с языком TraceQL и встроенным генератором метрик. Задайте запрос вроде «все трассы сервиса X длительностью более 500 мс с ошибками» и получите список для анализа. Включите в конфиге опцию search_enabled, чтобы индексировать трассы по тегам и искать без traceID. Даже без этого базовый поиск по traceID даёт ценную информацию.
Как находить узкие места и ошибки в приложении с помощью трассировки в Grafana Tempo
Что делаем | Что даёт |
---|---|
Выбираем Tempo в Grafana Explore | Подключение к данным трасс |
Открываем вкладку Search | Доступ к последним трассам с фильтрами |
Фильтруем по сервису, операции, длительности | Быстрый поиск нужных запросов |
Находим длинные или ошибочные трассы | Выявление узких мест и сбоев |
Открываем трассу, смотрим диаграмму | Визуализация цепочки вызовов и времени выполнения |
Ищем медленные спаны (долгие полоски) | Диагностика проблемных участков — БД, API, функции |
Используем TraceQL (в Tempo 2.x и выше) | Поиск трасс по условиям (ошибки, длительность, сервис) |
Включаем search_enabled в конфиге | Расширенный поиск по тегам без traceID |
Анализируем ошибки (5xx, исключения) | Видно, где и почему всё сломалось |
Заключение
Теперь ваш взгляд на приложение, словно рентген, который показывает, где именно возникают задержки и ошибки. Трассировка открывает глаза на внутреннюю жизнь сложных систем, помогая быстро находить и устранять узкие места, чтобы сервисы работали плавно и быстро. Конечно, освоение этой технологии требует времени и усилий, но оно того стоит: вы больше не будете блуждать в темноте, а будете точно знать, что происходит под капотом в режиме реального времени. Пусть ваши приложения летают, а вы спокойно наблюдаете за процессом, уверенные, что проблемы выявляются и решаются ещё до того, как это заметят пользователи.
Читайте в блоге:
- Мониторинг VPS на Linux с Prometheus и Grafana: пошаговая настройка
- Мониторинг состояния сервера: установка Grafana и интеграция с Prometheus
- Как защитить сайт от хакеров: простыми словами о реальных мерах безопасности