+7 (495) 801-60-42

OpenTelemetry и трассировка: как настроить наблюдаемость

В этой статье разберем на практике: opentelemetry что это, как работает распределенная трассировка, как связать логи, метрики и трейсы в единую картину, и что важно при внедрении наблюдаемости в веб‑продукт. Дадим дорожную карту настройки OTEL Collector и сравним популярные хранилища трейсов — Jaeger и Grafana Tempo.

Observability: что это и зачем бизнесу

Observability что это в прикладном смысле? Это способность продукта отвечать на вопрос «почему повело себя так, а не иначе» по данным телеметрии. Три ключевых сигнала — логирование, метрики, трейсы — дают быстрый путь от симптома к причине. Для бизнеса это:

  • сокращение MTTR (времени восстановления);
  • контроль пользовательского опыта (p95/p99 latency, error rate);
  • прогнозирование инцидентов и затрат на инфраструктуру;
  • аргументированная приоритизация задач в бэклоге.

OpenTelemetry: что это и из чего состоит стек

OpenTelemetry — открытый стандарт и набор SDK/агентов для сбора телеметрии. Он унифицирует формат данных (OTLP), экономит время на интеграциях и снижает vendor lock‑in. Базовые элементы:

  • SDK/авто‑инструментация: для языков Java, .NET, Node.js, Python, Go, PHP и др.;
  • OTLP (HTTP/gRPC): единый протокол экспорта телеметрии;
  • Exporter OpenTelemetry: коннекторы для отправки данных в Collector/облако/хранилища;
  • OTEL Collector: отдельный сервис, который принимает, обрабатывает и экспортирует сигналы;
  • Бэкенды визуализации/хранения: Jaeger, Grafana Tempo, Prometheus, Loki, коммерческие APM.

Почему это важно: вы можете менять бэкенды, не переписывая код продукта. Collector — точка консолидации, нормализации и маршрутизации телеметрии, куда добавляются семплинг, атрибуты, маскирование PII и ретраи.

Распределенная трассировка: как связать запрос от фронта до базы

Распределенная трассировка показывает путь запроса через микросервисы, очереди и БД. Полезные практики:

  • контекст трассировки: передавайте traceparent/trace‑id через HTTP/gRPC и фоновые задачи;
  • семплинг: начните с родительского 10–20%, для высоконагруженных путей — динамический семплинг по ошибкам/латентности;
  • атрибуты домена: добавляйте ключи типа user_id (анонимизированный), plan, region, feature_flag;
  • связывайте с фронтом: прокидывайте trace‑id в ответе, логируйте его в браузере и на CDN/edge;
  • ошибки и перформанс backend: помечайте Span Status=Error, добавляйте события stacktrace, размер пейлоада, количество ретраев.

Инструментально: Jaeger удобен для анализа call graph и поиска «самого медленного спана», Grafana Tempo масштабируется дешево на объектное хранилище и хорошо сочетается с Grafana/Loki/Prometheus.

OTEL Collector: настройка конвейера телеметрии

Otel collector настройка строится вокруг трех секций: receivers → processors → exporters. Практические рекомендации:

  • receivers: включите otlp (grpc+http), jaeger, prometheus, loki (если используете логи);
  • processors: batch (снижает накладные расходы), attributes (маскирование PII), resource (общие теги service.name, service.version, environment), probabilistic/sample, memory_limiter, transform (нормализация ключей);
  • exporters: otlp (в сторонние APM), jaeger, tempo, prometheusremotewrite, loki;
  • service: несколько pipelines по типам сигналов (traces, metrics, logs), health_check и zpages для отладки;
  • надежность: очередь (queued_retry), backoff, таймауты и лимиты на размер батча;
  • безопасность: TLS, ограничение входящих источников, маскирование персональных данных по списку атрибутов.

Топологии развертывания:

  • sidecar на pod: минимум сетевой латентности, удобно для Kubernetes;
  • daemonset/агент на ноде: баланс между удобством и стоимостью;
  • централизация (gateway): меньше операций, но будьте внимательны к пропускной способности и отказоустойчивости.

Метрики, логи, трейсы: как связать сигналы и ускорить RCA

Логирование метрики трейсы должны работать вместе:

  • корелляция ID: записывайте trace_id/span_id в логи и метрики (exemplar в Prometheus для p95/p99);
  • единая ресурсная модель: service.name, environment, region одинаковы во всех сигналах;
  • алерты по SLO: алерты ссылаются на дашборд с метрикой и кнопкой «открыть трейс»;
  • семантические конвенции: придерживайтесь OpenTelemetry Semantic Conventions для HTTP, DB, messaging, Cloud, FaaS.

Jaeger Tempo Grafana Tempo в связке с Prometheus и Loki дают быстрый переход «алерт → трейс → лог» без смены инструментов. Это существенно сокращает MTTR и улучшает опыт поддержки.

APM для веб‑приложений: что действительно нужно на старте

APM для веб приложений не обязательно должен быть «монолитным продуктом». Часто достаточно:

  • автоинструментация на бэкенде + ручные спаны вокруг критичных функций;
  • RUM/инструментация фронтенда (web-vitals, long tasks, fetch spans);
  • SLI по основным потокам: TTFB, backend latency, error rate, availability;
  • алерты по бюджетам ошибок и латентности;
  • дашборд продакшн‑версий и feature flags (сегментация перформанса по фичам).

Если нет своей команды SRE, отдайте инфраструктурную часть на аутсорс: сбор, хранение и обновления стека наблюдаемости можно доверить партнерам. В LightsOn мы помогаем продуктовым командам внедрять наблюдаемость в рамках услуг DevOps и инфраструктура и сопровождаем веб‑часть под SLA в услуге Разработка веб-приложений.

SLO, SLI, SLA: примеры и как их связать с телеметрией

SLO SLI SLA примеры для типового веб‑сервиса:

  • SLI: процент успешных запросов (2xx), p95 latency /api/checkout, доля 5xx, аптайм health endpoint;
  • SLO: 99.9% успешных запросов в месяц; p95 < 300 мс для чек‑аута; аптайм 99.95%;
  • ошибка бюджета: 0.1% на месяц (или 43 минуты простоя);
  • SLA: «компенсация/кредиты» при превышении порога (договаривается отдельно).

Как реализовать:

  • собирайте SLI как метрики (counter, histogram), храните в Prometheus/любом TSDB;
  • формализуйте SLO в правилах алертинга (burn rate, многослойные окна 5м/1ч);
  • в карточке инцидента автоматически прикладывайте трейсы из проблемных маршрутов;
  • фиксируйте пост‑мортем с привязкой к изменениям (commit, release, feature flag).

Безопасность, стоимость и масштабирование

Ключевые моменты при росте нагрузки:

  • приватность: маскируйте PII в Collector и на уровне SDK (email, phone, cookies, auth tokens);
  • хранение: храните трейсы короче (например, 7–14 дней), метрики дольше, логи — по критериям аудита;
  • семплинг: используйте tail‑based для захвата аномалий (ошибки/медленные запросы) при сдерживании объема;
  • стоимость: отделите горячее хранилище (последние дни) от холодного (архив S3/объектка);
  • визибилити релизов: тегируйте спаны версией и коммитом, чтобы понимать деградации после релиза.

Практический ориентир: Grafana Tempo масштабируется горизонтально и хранит данные в объектном хранилище, Jaeger проще для старта и локального анализа. Выбор зависит от горизонта масштаба и связки с текущими метриками/логами.

Пошаговое внедрение наблюдаемости с OpenTelemetry

Внедрение наблюдаемости без лишней бюрократии:

  1. Определите цели (SLO на ключевые пользовательские пути) и приоритизируйте сервисы.
  2. Выберите топологию Collector (gateway + агент/sidecar) и стандарты тегов.
  3. Подключите автоинструментацию и добавьте ручные спаны вокруг критичных операций (оплата, поиск, авторизация).
  4. Свяжите сигналы: trace_id в логах и метриках; единая ресурсная модель.
  5. Настройте конвейер Collector: batch, retry, семплинг, маскирование PII, экспортеры (Jaeger/Tempo/облако).
  6. Поднимите базовые дашборды и алерты по SLO, настройте burn-rate правила.
  7. Запустите runbook’и: что делать при деградации latency/ошибках 5xx/спайках таймаутов.
  8. Проведите game day: симулируйте сбои, оцените MTTR, доработайте алерты/дашборды.

Для сетапа Kubernetes и CI/CD пригодится материал «Kubernetes: что это и когда он нужен проекту», а чтобы понимать эксплуатационные аспекты — «Обслуживание серверов для веб‑приложений: что это и зачем бизнесу». Если продукту нужна комплексная оптимизация фронта и бэка, загляните в услугу Аудит и оптимизация сайта.

Частые ошибки при внедрении

  • «Собираем всё»: без семплинга и TTL счета за хранилище быстро растут.
  • Нет единых тегов: аналитика разваливается, дашборды нельзя агрегировать.
  • Логи отдельно от трейсов: теряете скорость RCA и тратите время на кросс‑поиск.
  • Не мониторится сам Collector: пропуски батчей остаются незамеченными.
  • Отсутствие SLO: алертов много, но они не связаны с пользовательским опытом.
  • Нет маскировки PII: риски комплаенса и утечек.

Чек‑лист внедрения OpenTelemetry

  • Определены SLI/SLO на ключевые пользовательские сценарии.
  • Согласована семантика тегов: service.name, environment, version, region.
  • Включена автоинструментация и добавлены ручные спаны на критичных путях.
  • Настроен OTEL Collector: receivers, processors (batch, attributes, sampler, memory_limiter), exporters.
  • Реализован семплинг (head/tail) и ретраи экспорта.
  • Маскирование PII включено на уровне SDK/Collector.
  • Трейсы связаны с логами и метриками по trace_id/exemplar.
  • Дашборды и алерты по SLO с burn‑rate правилами готовы.
  • Тест инцидента (game day) проведен, MTTR замерен, runbook обновлен.
  • План хранения и стоимости (горячее/холодное, TTL) согласован.

Вывод

OpenTelemetry — это практичный способ стандартизировать сбор телеметрии и выстроить наблюдаемость вокруг реальных SLO. Начните с минимального стека: автоинструментация, Collector, Jaeger/Tempo, базовые алерты. Дальше развивайте семплинг, безопасность и аналитические дашборды. Если нужна помощь с архитектурой и эксплуатацией, команда LightsOn возьмет на себя проектирование и поддержку: DevOps и инфраструктура, Разработка веб-приложений и Аудит и оптимизация сайта.

Другие полезные статьи

Делимся экспертизой, разбираем кейсы и рассказываем, как превращать идеи в работающие digital-продукты