Jaeger живёт не один: рядом Prometheus и Grafana, а в роли конкурента — Grafana Tempo. Урок про то, как собрать из этого работающий «три столпа» и когда выбирать Tempo.
Сборка: Grafana + Jaeger + Prometheus
# datasource в Grafana → Jaeger (адрес query-API)
apiVersion: 1
datasources:
- name: Jaeger
type: jaeger
url: http://jaeger:16686
- name: Prometheus
type: prometheus
url: http://prometheus:9090
- Клик из метрики в трейс: в панели Grafana по экземпляру на графике «Explore → трейсы» — переход в поиск Jaeger с тем же сервисом/операцией и окном времени;
- Exemplars: Prometheus-метрика с примерами trace_id (spanmetrics-коннектор умеет их отдавать) — точки-«звёздочки» на графике кликабельны прямо в трейс;
- Логи ↔ трейсы: поля trace_id в Loki (урок 2.4) + derived fields в datasource Loki дают кнопку-переход в Jaeger прямо из строки лога.
Так собирается полный цикл наблюдаемости: алерт (Prometheus) → дашборд (Grafana) → трейс (Jaeger) → логи (Loki/ELK) — и все переходы в 1–2 клика.
Service graph и зависимостям сервисов
Из спанов клиент-серверных вызовов можно построить граф сервисов (кто кого вызывает, с какими RPS/ошибками/латентностью):
- spanmetrics + метки
peer.service/ client-server атрибуты → рёбра графа; - в Grafana — модуль Service Graph (из data hub /collector metrics);
- Практическая ценность: реальная карта зависимостей (вместо устаревших диаграмм) и мгновенное видение «горячих рёбер».
Jaeger vs Tempo — честное сравнение
| Jaeger | Grafana Tempo | |
|---|---|---|
| Хранение | Cassandra/ES/ClickHouse/Badger | объектное (S3/GCS): очень дёшево |
| Поиск | богатый: теги, длительность, время | сначала нужен Trace ID / селектор через метрики (TraceQL развивается) |
| UI | собственный, зрелый | UI Jaeger внутри Grafana (переиспользован) |
| Связь с метриками | SPM + spanmetrics | нативная интеграция с Grafana/Exemplars |
| Эксплуатация | требует БД-кластер | проще: S3 + небольшой кластер |
| Когда выбирать | нужен мощный тег-поиск, уже есть ES/Cassandra, Jaeger как отдельный продукт | уже в Grafana-экосистеме, огромные объёмы, дешёвое хранение важнее тег-поиска |
💡 Важно: обе системы едят один и тот же OTLP. Переезд — это смена endpoint'а у Collector'а, а не переделка приложений. Хорошая новость всего курса: навыки инструментирования переносятся на любой бэкенд.
Менеджед-варианты
- Grafana Cloud (Tempo), Grafana Cloud + Jaeger-совместимость;
- Облачные APM: AWS X-Ray, Google Cloud Trace, Datadog — свои форматы, но OTel-приём всё больше совпадает;
- Критерий выбора тот же: объём, поиск, цена, экспертиза команды.
Практика
- Соберите связку Grafana + Prometheus + Jaeger в docker-compose; настройте datasource'ы.
- Подключите spanmetrics + exemplars: кликните из графика latency в конкретный трейс.
- Постройте service graph вашей тестовой системы из трёх сервисов; найдите самое нагруженное ребро.
- Разверните Tempo рядом с Jaeger, отправьте трейсы в оба (маршрутизация Collector'а): сравните поиск и стоимость хранения.
Мини-квиз
1. Что такое exemplars и чем полезны? — trace_id-примеры в метриках Prometheus: из точки графика — сразу в трейс.
2. Главный плюс Tempo? — Дешёвое объектное хранение при огромных объёмах.
3. Почему выбор бэкенда — необратимого решения? — Нет: OTLP сверху делает бэкенд заменяемым.