Трассировки и мониторинг. Траблшутинг

В production-системах неизбежно возникают инциденты: ошибки, деградация производительности, нестабильность сетей и внешних зависимостей. Чтобы быстро находить первопричину и подтверждать гипотезы данными, применяют стек наблюдаемости: трассировки, метрики, логи (часто дополняют профилированием). В этом топике мы последовательно разберём архитектуру наблюдаемости и роль OpenTelemetry, Jaeger, Prometheus и Grafana в траблшутинге.

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

Наблюдаемость состоит из трёх основных потоков данных: трассировки (кто, когда и что вызвал), метрики (числа и временные ряды для трендов и порогов), логи (подробные события и текст для контекста). Эффективный траблшутинг требует корреляции: из алерта по метрике перейти к связанным трейсам и логам той же операции с тем же trace_id.

SLO/SLI/SLA: определите целевые уровни качества (например, P95 latency ≤ 300 мс, ошибки ≤ 1%).
Golden signals: latency, traffic, errors, saturation (перегрузка).
Инструментирование: добавьте SDK/агенты, чтобы сервисы отдавали трейсинг и метрики.
Хранилища: временные ряды (Prometheus), распределённые трейс-хранилища (Jaeger/Tempo и др.), системы логов.
Дашборды и алерты: визуализация (Grafana), правила алертинга (Prometheus Alertmanager или Grafana Alerting).

OpenTelemetry: единый язык данных наблюдаемости

OpenTelemetry (OTel) — открытый стандарт и набор SDK/агентов для сбора трейсов, метрик и логов с едиными семантическими соглашениями. OTel отделяет сбор (SDK, автоподключаемые инструменты, Collector) от доставки (экспортеры) и хранилищ (Jaeger/Tempo, Prometheus/OTLP-метрики, лог-системы).

Ключевые понятия OTel

Span: атомарная операция (RPC, запрос к БД, вызов очереди) со временем начала/окончания, атрибутами, статусом.
Trace: дерево/граф span-ов, отражающее путь запроса через сервисы.
Context propagation: перенос trace_id/span_id через заголовки (W3C traceparent, baggage).
Sampler: политика отбора (always_on/off, parentbased, вероятностная, tail-based через Collector).
OTLP: бинарный протокол/формат доставки (gRPC/HTTP) для трёх типов сигналов (traces/metrics/logs).

OpenTelemetry Collector: централизованный приём, обработка, экспорт

Collector — отдельный сервис, принимающий данные по OTLP, делающий парсинг/фильтрацию/семплинг и отправку в хранилища. Его удобно деплоить как sidecar/agent на узел или как централизованный gateway.

                receivers:
                    otlp:
                        protocols:
                            grpc:
                            http:

                    processors:
                        batch:
                        attributes:
                            actions:
                                - key: http.request.header.authorization
                                  action: delete

                    exporters:
                        otlphttp:
                            endpoint: http://jaeger-collector:4318
                        prometheus:
                            endpoint: 0.0.0.0:9464

                    service:
                        pipelines:
                            traces:
                                receivers: [otlp]
                                processors: [batch, attributes]
                                exporters: [otlphttp]
                            metrics:
                                receivers: [otlp]
                                processors: [batch]
                                exporters: [prometheus]
            

Jaeger: просмотр и анализ распределённых трасс

Jaeger — система хранения и визуализации трейсингов. Позволяет видеть путь запроса через микросервисы, длительность каждого этапа, ошибки и узкие места. Компоненты: agent (приём), collector (агрегация), query и UI. Хранение: Elasticsearch, Cassandra или встроенные варианты для dev.

Поиск по сервису, операции, тегам (атрибутам), временному окну.
Service map и сравнение трейсов (baseline vs regression).
Root cause: быстро выявляйте самый долгий/ошибочный span.

Prometheus: метрики и алертинг

Prometheus — TSDB и движок запросов PromQL c pull-моделью (он опрашивает /metrics у таргетов). Поддерживает Counter, Gauge, Histogram, Summary. Для кастомных сервисов используйте клиентские библиотеки; для системных метрик — экспортеры (например, node_exporter).

Мини-конфиг Prometheus (scrape targets)

                global:
                scrape_interval: 15s

                scrape_configs:
                    - job_name: "app"
                      static_configs:
                          - targets: ["app:9100"]

                    - job_name: "otel-collector"
                      static_configs:
                          - targets: ["otel-collector:9464"]
            

Примеры PromQL для траблшутинга

Ошибки RPS по статусам

sum by (status_code) (rate(http_requests_total[5m]))

P95 латентность (Histogram)

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Доля ошибок 5xx

sum(rate(http_requests_total{status_code="5xx"}[5m])) / sum(rate(http_requests_total[5m]))

Насыщение CPU

avg by (instance) (rate(process_cpu_seconds_total[5m]))

Alerting (Alertmanager) — пример

groups:
    name: errors
rules:
    alert: HighErrorRate
    expr: sum(rate(http_requests_total{status_code="5xx"}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
    for: 10m
    labels:
        severity: critical
    annotations:
        summary: "Ошибка > 5% в течение 10m"
        description: "Проверьте последние развёртывания и внешние зависимости."

Grafana: дашборды, корреляция и алерты

Grafana — платформа визуализации и оповещений. Поддерживает источники данных Prometheus, Loki (логи), Tempo/Jaeger (трейсы) и др. Хорошая практика — строить "runbook-дашборды": от верхнего уровня SLI к деталям (узкие места CPU/IO, внешние API, БД).

Вариабельность: переменные (service, instance, namespace) для быстрой фильтрации.
Аннотации: помечайте релизы и инциденты — коррелируйте скачки метрик с событиями.
Exemplars: показывайте ссылки на конкретные трейсы в точках графика гистограммы.
Unified Alerting: централизуйте правила и маршрутизацию уведомлений.

Корреляция логов, метрик и трейсов на практике

Логи выводите в структурированном виде (JSON) и добавляйте поля trace_id и span_id.
Передавайте заголовки traceparent во все исходящие HTTP/RPC вызовы и в ответы клиентам.
Используйте exemplar-ы в гистограммах, чтобы из точки латентности перейти к трейсу.

            {
            "level": "error",
            "msg": "Payment declined",
            "trace_id": "2f9c8e4b8a3c4d1e",
            "span_id": "7b1e",
            "order_id": "123e4567-e89b-12d3-a456-426614174000"
        }
        

Методики траблшутинга: RED, USE, чек-листы

RED (Rate, Errors, Duration) — для пользовательских сервисов: следите за RPS, ошибками и длительностью.
USE (Utilization, Saturation, Errors) — для ресурсов: CPU, память, диск, сеть.
Чек-лист инцидента: верифицируйте алерт, оцените blast radius, зафиксируйте таймлайн, включите фича-флаги/откаты, соберите трейсы/метрики/логи, оформите postmortem с действиями.

Производительность и стоимость: семплинг, бакеты, ретеншн

Семплинг трейсов: снижает объём, оставляет репрезентативную картину. Tail-based в Collector выбирает интересные трейсы (ошибки, высокую латентность).
Гистограммы: заранее продумайте бакеты (например, 10, 25, 50, 100, 250, 500, 1000 мс). Слишком мелкие бакеты => рост кардинальности.
Ретеншн: разные сроки хранения для "сырых" и агрегированных данных. Используйте recording rules.

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

Санитизируйте атрибуты спанов и поля логов (удаляйте токены, номера карт, персональные данные).
Ограничьте доступ к UI и API наблюдаемости (SSO, RBAC, сетевые политики).
Шифруйте трафик OTLP и хранение, если требуется по политике.

Типовые ошибки и их исправление

Трейсы рвутся: не передаётся traceparent. Проверьте прокси/балансировщики, включите автоинструментирование HTTP-клиентов/серверов.
Пустые дашборды: Prometheus не видит таргеты. Проверьте scrape_configs, сетевые политики, TLS.
Большие счета за хранение: высокая кардинальность метрик/атрибутов. Пересмотрите лейблы, бакеты, ретеншн и семплинг.
Шумные алерты: нет гистерезиса/задержки for:, пороги не привязаны к SLO. Настройте дедупликацию и маршрутизацию алертов.

FAQ и лучшие практики

С чего начать? — Инструментируйте один критичный путь (например, "создание заказа"), подключите OTel и Jaeger, затем добавляйте метрики и алерты.
Как измерять пользовательские SLI? — Введите явные бизнес-метрики (время ответа ключевых операций, доля успешных платежей).
Как связать логи и трейсы? — Добавляйте trace_id в контекст логгера; используйте middleware для авто-обогащения.

Last modified: 01 October 2025