Observability: логи, метрики, трейсы

Инцидент в production: API медленный, пользователи жалуются. Без observability - часы поиска причины наугад. С observability - 5 минут: метрики показывают рост latency, трейс показывает что 90% времени в DB query, лог показывает что query вернул 50,000 строк вместо обычных 10. Причина найдена. Observability - это не роскошь, это необходимость для сложных систем.

• **Netflix**: централизованный Observability platform обрабатывает триллионы spans в день. Distributed tracing позволяет найти причину замедления среди 700+ микросервисов за минуты
• **Honeycomb**: пионер high-cardinality observability. Charity Majors (CTO): 'you need to be able to ask arbitrary questions about your production system' - именно это делает трейсинг
• **OpenTelemetry**: стал CNCF incubating проектом в 2021. Поддержан Google, Microsoft, AWS, Datadog, Honeycomb - de facto стандарт для cloud-native observability

Structured Logs

Observability - способность понять внутреннее состояние системы по её внешним outputs. Три столпа: Logs (события), Metrics (агрегированные числа), Traces (путь запроса через систему). Structured logging - логи в машиночитаемом формате (JSON) вместо plain text строк. Позволяет фильтровать, агрегировать, алертить по конкретным полям без regex парсинга.

Уровни логов: TRACE (детальная отладка), DEBUG (внутренние состояния), INFO (нормальные события), WARN (необычные ситуации), ERROR (ошибки не ломающие систему), FATAL (критические ошибки). В production: INFO и выше. Корреляционный ID (trace_id, request_id): добавляется при получении запроса, передаётся во все downstream сервисы. Позволяет объединить все логи одного запроса из разных сервисов.

Metrics с Prometheus

Metrics - числовые агрегированные измерения состояния системы во времени. Четыре типа в Prometheus: Counter (монотонно возрастающий: количество запросов, ошибок), Gauge (произвольное значение: CPU, memory, активные соединения), Histogram (распределение значений: latency distribution с перцентилями), Summary (похож на histogram но с квантилями на стороне клиента). Prometheus собирает метрики через scraping HTTP endpoint /metrics.

USE Method (Brendan Gregg): для каждого ресурса - Utilization (занятость), Saturation (очередь, задержки), Errors. RED Method (Tom Wilkie): для каждого сервиса - Rate (запросов/сек), Errors (ошибок/сек), Duration (latency). Grafana визуализирует метрики из Prometheus. AlertManager - правила оповещения: если error_rate > 1% за 5 минут - пейджер. Promtheus используют Uber, Soundcloud, Spotify.

Distributed Tracing с Jaeger

Distributed Tracing - отслеживание пути запроса через все сервисы системы. Trace = дерево Spans. Span = единица работы в одном сервисе (обработка запроса, DB query, HTTP call). Каждый span содержит: trace_id (общий для всего trace), span_id, parent_span_id, timestamps, tags (key-value пары), logs. Trace позволяет ответить: где именно тратится время при обработке запроса?

Jaeger (разработан Uber, CNCF проект) и Zipkin - популярные распределённые системы трейсинга. Propagation: trace_id передаётся в HTTP заголовках (X-B3-TraceId, traceparent для W3C стандарта) между сервисами. Sampling: 100% трейсинг слишком дорого для production. Обычно: 1-10% запросов трейсится. Adaptive sampling: 100% для ошибок, 1% для успешных. Tail-based sampling: решение после завершения запроса (трейсить медленные).

OpenTelemetry

OpenTelemetry (OTel) - открытый стандарт и набор инструментов для Logs, Metrics и Traces. Создан слиянием OpenCensus (Google) и OpenTracing (CNCF). Цель: vendor-neutral instrumentation. Код инструментируется один раз через OTel SDK, данные экспортируются в любую backend (Jaeger, Zipkin, Datadog, Honeycomb) через конфигурацию без изменения кода. Поддерживает 11 языков.

Auto-instrumentation: OTel автоматически инструментирует популярные библиотеки (Express, gRPC, Redis, PostgreSQL клиенты) без изменения кода приложения. Java agent: -javaagent:opentelemetry-javaagent.jar добавляет трейсинг ко всем HTTP запросам. Node.js: require('@opentelemetry/auto-instrumentations-node'). Это убирает необходимость ручного добавления spans в каждую функцию. Semantic Conventions: стандартные имена атрибутов (http.method, db.system, net.peer.name) обеспечивают совместимость между инструментами.

Связанные темы

Observability - основа всех reliability и performance практик:

• SRE: Site Reliability Engineering — SLI измеряются через metrics. Observability - инструмент измерения SLO и диагностики инцидентов
• Chaos Engineering — Chaos experiments требуют хорошей observability для наблюдения за поведением системы под fault injection

Вопросы для размышления

• Три столпа observability: Logs, Metrics, Traces. В каких сценариях каждый из них наиболее ценен?
• Sampling трейсов (1-10%) позволяет снизить overhead, но пропускает редкие события. Как решить компромисс между coverage и стоимостью?
• High-cardinality attributes (user_id, trace_id) мощные для отладки, но дорогие для метрических систем. Как правильно разграничить где использовать logs/traces vs metrics?

Связанные уроки

• devops-10