Система трассировки сама нуждается в мониторинге. Плюс у Jaeger есть встроенная способность выжимать из трейсов RED-метрики сервисов — Service Performance Monitoring.
Метрики компонентов Jaeger
Все компоненты (collector/query/v2-дистрибуция) отдают Prometheus-метрики по
/metrics. Ключевые:
| Метрика | Что показывает |
|---|---|
jaeger_collector_spans_received_total | поток входящих спанов — ваш главный объёмный показатель |
jaeger_collector_spans_dropped_total | потери на приёме — всегда 0 |
jaeger_collector_save_latency_* | латентность записи в хранилище |
jaeger_query_* | запросы UI/API и их латентность |
remote_storage/es_bulk_* (по хранилищу) | здоровье записи в ES/Cassandra |
Для OTel Collector в цепочке — его собственные метрики:
otelcol_receiver_accepted_spans, otelcol_exporter_send_failed_spans,
otelcol_exporter_queue_size. Разница между «принято collector'ом» и «принято
Jaeger'ом» = потери в пути — это и есть первый алерт.
Минимальный набор алертов трассировки
- ☑ Потери: dropped/failed spans > 0 за 5 минут;
- ☑ Приток спанов упал к нулю (приложения сломали экспорт или сеть);
- ☑ Латентность записи в хранилище > порога;
- ☑ Возраст новейшего индекса > N часов (очистка/запись сломались, урок 5.3);
- ☑ Свободное место на хранилище < 20%;
- ☑ Очередь экспортёра Collector растёт (хранилище не успевает).
SPM: RED-метрики из трейсов
Service Performance Monitoring — модуль Jaeger (v1.32+), который агрегирует по завершённым трейсам RED-метрики: Request rate, Error rate, Duration (p50/p75/p95/p99) — по сервисам и операциям, на отдельной вкладке UI:
- Не требует никакой дополнительной инструментирования — считается из уже приходящих трейсов;
- Учитывает сэмплирование: rate корректируется на долю выборки, duration — по выборке честный;
- Идеальный «второй столб» для алерта: «p99 операции вырос» → клик → список медленных трейсов той же операции (в том же UI!).
Альтернативный/дополняющий путь — коннектор spanmetrics в OTel Collector:
генерирует метрики из спанов и шлёт их в Prometheus; можно строить свои дашборды и
exemplar-связки «метрика → пример трейса».
Само-трассировка инфраструктуры
Замкнутый круг «а кто следит за наблюдаемостью?» решается стандартно: Collector и Jaeger экспортируют собственные телеметрические метрики в тот же Prometheus; часть команд добавляет и спаны внутренней работы (экспорт в Jaeger). Практический минимум — метрики + алерты выше.
Практика
- Соберите метрики Jaeger и Collector в Prometheus; постройте дашборд: приток спанов, потери, латентность записи, очередь экспорта.
- Сломайте путь (остановите Jaeger под нагрузкой) и посмотрите, какие алерты сработают.
- Включите SPM: откройте вкладку Service Monitoring, найдите свой сервис и его p99 по операциям; сверьте с метриками приложения.
- Настройте spanmetrics-коннектор в Collector и постройте в Grafana свой RED-дашборд по операциям.
Мини-квиз
1. Какая метрика главная для «трейсы теряются»? — Разница принятых у источника и доставленных в хранилище: dropped/failed spans.
2. Откуда SPM берёт данные и учитывает ли сэмплинг? — Из приходящих трейсов; rate экстраполируется на долю сэмплирования, duration — честно по выборке.
3. Зачем spanmetrics-коннектор, если есть SPM? — Метрики в Prometheus: свои дашборды, алерты, exemplars.