Распределённая трассировка становится обязательной, когда критический путь запроса уже нельзя восстановить ни по памяти, ни по разрозненным логам.
Глава разбирает Jaeger, Tempo, путь записи, путь чтения и выборку, показывая, как наблюдаемость микросервисов упирается в баланс между глубиной данных, задержкой и стоимостью хранения.
На интервью этот материал помогает чётко объяснить, когда трассировки лучше метрик или логов, как искать участки повышенной задержки и почему полная запись трассировок без выборки не всегда оправдана.
Практическая польза главы
Практика проектирования
Проектируйте путь спана от сервиса до хранилища и обратно к расследованию: инструментирование, коллектор, выборка, хранение и поиск.
Качество решений
Оценивайте стек через скорость поиска трассировки, стоимость хранения, кардинальность меток и полноту критического пути запроса.
Аргументация на интервью
Показывайте, когда трассировка полезнее метрик и логов, как она локализует задержку и почему выборка должна быть осознанной.
Формулировка компромиссов
Явно обсуждайте цену полной записи трассировок, глубину атрибутов, срок хранения и скорость работы интерфейса расследования.
Контекст
Наблюдаемость и проектирование мониторинга
Здесь мы спускаемся на уровень ниже базовой наблюдаемости: как трассировка ведёт запрос через сервисы и где она экономит время на расследовании.
Когда запрос проходит через десяток сервисов, очередей и зависимостей, вопрос «где именно тормозит» перестаёт решаться по логам одного сервиса. Распределённая трассировка в микросервисах восстанавливает весь путь запроса по связанным спанам, поэтому задержку или ошибку находят по фактам, а не по догадкам. В этой главе мы разбираем , , , , выборку, и хранение трассировок в Jaeger и Tempo. Материал продолжает Наблюдаемость и проектирование мониторинга и фокусируется на операционных решениях, которые ускоряют расследование инцидентов.
Инструменты: Jaeger и Tempo
Jaeger
Когда трассировку только заводят, важнее всего быстро увидеть первый результат. Jaeger — это классическая с открытым исходным кодом и понятным интерфейсом, на которой команда добирается до без долгой настройки.
Сильные стороны
- Даёт : каскадная диаграмма запроса и критический путь видны уже на первом поэтапном запуске.
- Хорошо интегрируется с OpenTelemetry.
- Удобен как интерфейс для дежурных инженеров и .
Компромиссы
- При росте объёма трассировок чувствительными становятся и размер индексов.
- Нужны аккуратная и контроль .
Tempo
Серверная часть системы трассировки от Grafana Labs. Делает ставку на дешёвое хранение в , поэтому держит большой поток спанов там, где у других растёт счёт за хранилище.
Сильные стороны
- Экономичен на масштабе благодаря объектному хранилищу и блочному формату данных.
- Метрики и трассировки лежат рядом в Grafana Explore, поэтому от всплеска задержки до конкретного спана дежурный доходит без переключения инструментов.
- Подходит для платформ с большим потоком трассировок и длинными .
Компромиссы
- Качество диагностики зависит от атрибутов спанов и корректной .
- Нужен продуманный , иначе становится медленным.
Схема распределённой трассировки
Схема распределённой трассировки в микросервисах
Одна платформа телеметрии обслуживает два разных пути: запись спанов и диагностический поиск.
Как спаны попадают в хранилище
Этапы выстроены сверху вниз: источник, обработка, хранилище и результат расследования.
Инструментированные микросервисы
SDK создают спаны и передают контекст трассировки между HTTP, gRPC и Kafka.
OpenTelemetry Collector
Коллектор обогащает, фильтрует, выбирает и маршрутизирует телеметрию.
Серверная часть приёма
Поток экспортируется в Jaeger Collector и/или Tempo Distributor.
Хранилище трассировок
Jaeger пишет индексы и спаны в хранилище, Tempo складывает блоки в объектное хранилище.
Путь записи: как спаны доходят до хранилищ
- SDK в сервисах создают спаны и передают traceparent между HTTP, gRPC и Kafka.
- OpenTelemetry Collector обогащает телеметрию полями service, env, tenant и применяет политику выборки.
- Коллектор экспортирует поток в Jaeger Collector и/или Tempo Distributor.
- Jaeger пишет индексы и спаны в хранилище, Tempo формирует блоки в объектном хранилище.
Операционные акценты
- Jaeger удобен для быстрого старта и знакомого UX расследований.
- Tempo снижает стоимость за счёт объектного хранилища и отказа от тяжёлого индексирования всех спанов.
- Для сценариев с высокой кардинальностью критичны выборка по результату запроса и уровни хранения.
Решения для пути записи и пути чтения
Путь записи
- теряется на любой границе, где его забыли пробросить, — поэтому он должен идти через всё: протокол HTTP, удалённый вызов процедур gRPC, и . Один пропущенный хоп — и трассировка рвётся ровно там, где идёт расследование.
- Коллектор телеметрии OpenTelemetry работает как точка применения правил: , фильтрация, и .
- Для высоконагруженных систем задавайте отдельные квоты на приём трассировок, чтобы они не съедали бюджет логов и метрик.
- Хранение — не настройка по умолчанию, а продуктовое требование: уровни хранения, время жизни данных и целевая решаются заранее, иначе бюджет утечёт незаметно, а старых трассировок не окажется на руках в нужный момент.
Путь чтения
- Поиск трассировки идёт не с любого запроса, а с сигналов влияния на пользователя: имя сервиса, статус ошибки status=ERROR и окно высокой задержки по перцентилям p95/p99. Так расследование начинается с того, что реально болит, а не со случайной выборки.
- Jaeger UI и Grafana Explore должны использовать единые правила именования сервисов и .
- Держите к интерфейсу трассировки под отдельным целевым показателем уровня сервиса (SLI): во время инцидента инженер должен получить трассировку за секунды, иначе медленный поиск сам становится частью простоя.
- обязательна: без неё расследование становится ручным и медленным.
Практический чек-лист внедрения
Согласовать обязательные : service.name, deployment.environment, tenant, error.type.
Ввести отдельные для критичных API, фоновых задач и шумных точек входа.
Проверить нагрузку коллектора телеметрии и хранилища трассировок на синтетическом и похожем на промышленный трафике.
Встроить в операционные инструкции и шаблоны реагирования на инциденты для дежурной команды.
Частые антипаттерны
Включать стопроцентную выборку без оценки стоимости хранения и запросов и без профилей по критичности трафика — счёт за хранилище растёт быстрее, чем польза от лишних трассировок.
Ограничиваться только и терять внутренние .
Смешивать именование спанов и меток между командами без общего контракта .
Жить с трассировкой как с отдельным инструментом «на всякий случай», а не как с частью процесса : тогда ей пользуются от случая к случаю, и в острый момент она оказывается пустой.
Источники
Связанные главы
- Наблюдаемость и проектирование мониторинга - Базовый контур наблюдаемости: метрики говорят, что стало хуже, логи — что случилось в одном сервисе, а трассировка связывает это в путь запроса для быстрого первичного разбора инцидента.
- Inter-Service Communication Patterns - Разбирает протокол HTTP, удалённый вызов процедур gRPC и асинхронные границы — те самые места, где контекст трассировки легче всего потерять, если о нём не подумать заранее.
- Архитектура сервисной сетки (service mesh) - Показывает телеметрию сервисной сетки и управление трассировкой на уровне контура обработки в микросервисах.
- Prometheus: история и архитектура - Связывает трассировки с метриками для корреляции задержек, спанов и деградаций.
- Performance Engineering - Добавляет методы анализа задержек и поиска узких мест, где распределённая трассировка даёт первичную диагностику.
- Интервью по диагностике инцидентов - Практика первичного разбора и поиска корневой причины, где трассировки сокращают время расследования.