Три столпа observability: логи, метрики, трейсы

↑ 7.2 Observability: логи, метрики, трейсинг, OpenTelemetry · → Следующая

Желательно~3 мин чтенияУровень: senior

Зачем это на собесе

«Как вы понимаете, что происходит в проде?» — стартовый вопрос по эксплуатации.

Объяснение

Мониторинг отвечает на заранее известные вопросы («жив ли сервис»). Observability позволяет исследовать неизвестные проблемы по данным, которые система отдаёт.

СтолпЧтоПлюсМинус
Логисобытия с контекстомдетали конкретного случаяобъём, дорого искать без структуры
Метрикичисловые ряды во временидёшевы, агрегируются, алертынет деталей отдельного запроса
Трейсыпуть одного запроса через сервисывидно, где потеряно времянужны инструментация и выборка
Профили (4-й столп)где тратятся CPU/памятьпричина на уровне кодаотдельная инфраструктура

Как они работают вместе: алерт по метрике (рост ошибок) → трейс проблемного запроса (какой сервис медленный) → логи этого запроса по trace_id → профиль (какой метод).

flowchart LR
  A[Метрика: ошибки 5xx растут] --> B[Трейс: медленный вызов в billing]
  B --> C[Лог: timeout при обращении к БД]
  C --> D[Профиль/дамп: пул соединений]

Ключ ко всему — корреляция: единый trace_id в логах, метриках (exemplars) и трейсах.

Нюансы и подводные камни

  • Высокая кардинальность меток (userId в метке метрики) убивает хранилище метрик.
  • Логи без структуры нельзя агрегировать.
  • Трейсы всех запросов стоят дорого: применяйте выборку (sampling).
  • Данные наблюдаемости — тоже данные: не пишите в них секреты и персональную информацию.
  • Инструмент не заменяет процесс: алерты должны быть о симптомах для пользователя.

Практика

  1. Пройдите путь «алерт → метрика → трейс → лог» на тестовой поломке.
  2. Добавьте trace_id во все логи.
  3. Найдите метрику с высокой кардинальностью и исправьте.

Вопросы с ответами

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