Чек-лист «Jaeger в проде»

Сводный чек-лист модуля: пробегите по нему перед выводом трассировки в продакшен и возвращайтесь при каждом крупном изменении.

Инструментирование

• ☑ service.name у всех сервисов — уникальные, стабильные имена.
• ☑ Автоинструментирование HTTP/SQL/кеша/очередей + ручные спаны бизнес-операций.
• ☑ Имена спанов низкой карточности; идентификаторы — в атрибуты.
• ☑ parentbased_* сэмплеры; политики по профилю трафика.
• ☑ trace_id/span_id в логах; баггаж без секретов.
• ☑ PII не попадает в атрибуты (проверка + фильтры на Collector).

Доставка

• ☑ OTLP как протокол; endpoint — OTel Collector (agent→gateway), не напрямую в Jaeger.
• ☑ batch + memory_limiter настроены; очереди экспортёра с ретраями.
• ☑ Фильтрация шума (healthchecks) до экспорта.
• ☑ Если гарантия доставки нужна — Kafka-буфер (урок 3.4).

Сэмплирование и объём

• ☑ Бюджет в трейсов/сек определён; объём в ГБ/сутки посчитан и подтверждён замером.
• ☑ Tail-сэмплирование (если нужно): num_traces/decision_wait рассчитаны, LB по trace ID.
• ☑ Двойного сэмплирования нет.

Хранилище

• ☑ Не in-memory; выбранное хранилище соответствует объёму и типу поиска.
• ☑ Retention настроен и мониторится (алерт на возраст индекса и место).
• ☑ Rollover/шардинг по объёму; шард 20–50 ГБ.
• ☑ Высококардинарные теги не индексируются.

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

• ☑ Дашборд: приток/потери/латентность записи/очереди.
• ☑ Алерты из урока 5.4 проверены тестом отказа.
• ☑ SPM/spanmetrics дают RED-картину по операциям.

Процессы

• ☑ Playbook инцидента: «трейсы пропали», «хранилище переполнено», «UI тормозит».
• ☑ Новые сервисы подключаются по инструкции (env + sidecar), а не «как получилось».
• ☑ Раз в квартал пересмотр бюджета: рост трафика vs объём.
• ☑ Трассировка объявлена необязательной к бизнесу: её отказ не роняет сервисы (проверено дизастер-тестом).

Анти-паттерны продакшена (напоследок)