Наблюдаемость и место трассировки

Прежде чем трогать Jaeger, надо честно ответить: какую проблему решает трассировка и чем она не является. Этот урок — про «почему», а не про «как».

Три вопроса мониторинга и их пределы

Классическая триада наблюдаемости отвечает на три разных вопроса:

Метрика http_request_duration_p99 > 2s говорит «время растёт», но не говорит, где: в вашем коде, в БД, в чужом сервисе, в сети? Логи покажут ошибки, но не покажут, что «этот медленный ответ был потому, что сервис B ждал сервис C». Трассировка соединяет события одного запроса сквозь все сервисы в один связный объект — трейс.

Проблема, для которой придумали трассировку

В монолите латентность видна в профайлере: один процесс, один стек. В микросервисах один пользовательский запрос порождает каскад из 10–30 вызовов: HTTP, gRPC, очереди, кеши, БД. Симптом «p99 вырос вдвое» без трассировки расследуется так: открыть логи пяти сервисов, угадать таймстемпы, сопоставить руками. С трассировкой — открыть один трейс и увидеть waterfall: какой сегмент съел время.

💡 Трассировка — это «профайлер распределённой системы». Точнее всего это описал термин из статьи Google Dapper (2010), на которой выросли все современные системы, включая Jaeger.

Что трассировка НЕ даёт

• Это не алертинг. Алерты — метрики. Трейсы — инструмент расследования, куда вы приходите с гипотезой «посмотри на запросы этого сервиса за последние 15 минут»;
• Это не полные логи. Спан несёт метаданные и короткие события, а не килобайты текста;
• Это не бесплатная история всего. Каждый спан хранится и стоит денег → нужен сэмплирование и retention (модуль 5);
• Это не магия для плохо написанного кода: трейс покажет «где», но не «почему» — «почему» вы читаете в коде, куда вас привёл спан.

Кратко о Jaeger

Jaeger (произносится «Ягер», нем. «охотник») — распределённая система трассировки, рождённая в Uber, с 2019 года — выпускной проект CNCF. Роль Jaeger в стеке:

• принимать трейсы от приложений (по протоколу OTLP и наследию Jaeger/Zipkin);
• хранить их в масштабируемом хранилище (Cassandra, Elasticsearch/OpenSearch, ClickHouse…);
• предоставлять поиск и визуализацию (веб-UI и API).

Важно понимать контекст 2024+: сама «телеметрия» — это OpenTelemetry (SDK в приложениях), а Jaeger — это бэкенд: приём, хранение, UI. Функции агентства и экспорта делегированы OTel SDK и OTel Collector. Эту схему разберём в уроке 1.3.

Где вы это примените уже завтра

• Инцидент «медленные ответы у всех» → waterfall-трейс укажет сегмент-виновник;
• «У пользователя падает, у нас нет» → найти трейс по user id в tag'ах;
• Ревью архитектуры: реальный граф вызовов (кто кого зовёт, N+1 запросы в БД);
• Оценка бюджетов латентности: сколько мс съедает каждая нога цепочки.

Практика

1. Поднимите Jaeger: docker run -d --name jaeger -p 16686:16686 -p 4317:4317 -p 4318:4318 jaegertracing/all-in-one:latest и откройте UI на http://localhost:16686. Пока он пуст — это нормально.
2. В выпадающем списке Service найдите сервис jaeger-query — Jaeger трассирует сам себя (self-instrumented): поищите его трейсы и пролистайте.
3. Выпишите 5 последних инцидентов «что-то медленно/упало» из вашей практики и для каждого решите: это вопрос метрик, логов или трейсов? Это тренирует выбор инструмента.