←Все статьи

Логи, метрики, трейсы: что такое observability и почему трёх хватает

Инфраструктура5 мин чтения
  • #observability
  • #metrics
  • #logs
  • #traces
  • #opentelemetry

Observability — модное слово, за которым стоит простой принцип: вы должны уметь ответить на любой вопрос о поведении системы, не отправляя программиста дебажить прямо на проде. В отличие от monitoring (который показывает то, что вы заранее догадались измерять), observability позволяет разобраться в том, чего вы не предвидели. Три источника данных покрывают 95% задач, и главное — понимать, какой когда нужен.

Метрики (metrics) — «что и сколько»

Метрики — это числа во времени. Системные (CPU, память, диск, сеть), бизнес- (число заказов за минуту, конверсия), технические (RPS, latency, счётчик ошибок). Хранятся как временные ряды: timestamp → значение.

Сильные стороны. Дёшевы в хранении (одно число на точку), агрегируются (среднее, перцентили, сумма за интервал), идеальны для дашбордов и алертов. Можно держать месяцы данных без раздутия хранилища.

Стек. Prometheus (сбор и хранение, pull-модель) + Grafana (визуализация). Это де-факто стандарт в cloud-native мире. Для прикладных метрик часто добавляют statsd, для Java — Micrometer.

На что отвечают. «CPU у сервиса X на 95%», «число 500-х ошибок выросло втрое за последний час», «медианная latency поднялась со 100 мс до 500 мс». Метрики — основа алертов: если число пересекло порог — зовём дежурного.

Логи (logs) — «что именно произошло»

Логи — дискретные события с контекстом. Каждая запись: «в 12:03:14 пользователь user_42 попытался оформить заказ order_1337, метод processPayment упал с timeout connecting to payment-gateway:8080».

Сильные стороны. Полный контекст конкретного события — stack trace, значения переменных, идентификаторы пользователя и запроса. Незаменимы при разборе конкретного инцидента: «что пошло не так у этого пользователя в этот момент».

Слабые стороны. Дорогие в хранении и поиске. В отличие от метрик, лог — это текст (или структурированный JSON), и каждый байт стоит денег. Поиск по логам за месяц — тяжёлая операция. Поэтому логи обычно хранят короткое время (дни–недели), метрики — долго (месяцы–годы).

Стек. Loki (от авторов Grafana, интегрирован с Prometheus-метками), ELK (Elasticsearch + Logstash + Kibana), Datadog. Структурированный лог (JSON) предпочтительнее текстового — по нему можно фильтровать и агрегировать.

На что отвечают. «Почему у пользователя user_42 упал заказ?» — метрики скажут, что ошибок стало больше, но кто именно ошибся и с каким сообщением — только логи.

Трейсы (traces) — «где тормозит и почему»

Трейс — путь одного запроса через все сервисы и компоненты со временем на каждом шаге. В микросервисах один HTTP-запрос пользователя может пройти через gateway, auth-сервис, основной сервис, две базы данных, очередь сообщений и сторонний API. Трейс показывает всю эту цепочку: каждый span (шаг), сколько он занял, где задержка.

Сильные стороны. Незаменимы для распределённых систем. Без трейсов понять, почему запрос идёт 2 секунды, когда он проходит через 8 сервисов, — почти невозможно. Трейс сразу покажет: 1.5 секунды из 2 — это SQL-запрос в billing-service, конкретно в методе getInvoice.

Слабые стороны. Тяжелее настраивать (надо инструментировать код, пробрасывать trace context между сервисами). В отличие от метрик, трейсится не каждый запрос — обычно сэмплирование (1–10%), иначе объём данных взорвётся.

Стек. OpenTelemetry (стандартный API/SDK для генерации трейсов, метрик и логов), Jaeger, Grafana Tempo, Datadog APM.

На что отвечают. «Где именно в этом вызове тормозит?» — показываетspan с максимальной длительностью, вплоть до SQL-запроса.

Правило трёх — как они дополняют друг друга

Сигналы не конкурируют, а работают в связке. Классический цикл расследования инцидента:

  1. Метрика показывает, что есть проблема: «ошибки 500 выросли с 0.1% до 5% за последние 15 минут».
  2. Трейс ведёт, где в системе она возникла: «ошибки исходят из payment-service, конкретно в charge-вызове к стороннему API, который начал таймаутить».
  3. Лог раскрывает детали конкретного события: «payment-gateway вернул 503 с телом {"error": "rate limit exceeded"}».

Без метрик вы не узнаете о проблеме вовремя. Без трейсов — не поймёте, в каком из N сервисов она возникла. Без логов — не увидите, что именно произошло. Поэтому три сигнала вместе, а не один вместо всех.

OpenTelemetry — стандарт, снимающий vendor lock-in

Исторически каждый вендор (Datadog, New Relic, Dynatrace) имел свой SDK для инструментации кода. Сменить вендора — значит переписать инструментацию. OpenTelemetry (OTel) — открытый стандарт, единый API для сбора всех трёх сигналов. Вы пишете инструментацию один раз, а бэкенд (Jaeger, Tempo, Datadog, Honeycomb) меняете конфигурацией. Сейчас это индустриальный стандарт, его поддерживают все крупные вендоры.

Антипаттерны

Логировать всё подряд «на всякий случай». Превращает логи в шум: полезное сообщение тонет в тысячах отладочных. Логи должны быть структурированы, с уровнями (DEBUG/INFO/WARN/ERROR), и в production обычно включают INFO и выше. Дебаг-уровень — точечно при расследовании.

Делать алерты на логи. Если вы парсите строки логов для алертов — это сигнал, что должна быть метрика. Парсинг текста хрупок: поменяли формулировку сообщения — алерт сломался. Числа должны идти метриками.

Микросервис без trace context. Если каждый сервис логирует сам по себе, без общего correlation ID — связать события одного запроса невозможно. OpenTelemetry решает это автоматически, проставляя trace context в заголовках между вызовами.

Один дашборд на всё. Дашборд из 30 графиков, на который никто не смотрит, пока не сломается. Эффективнее несколько маленьких: один на сервис, с ключевыми SLO (latency p50/p95/p99, error rate, throughput). Остальное — по запросу.

Короткое summary

Observability держится на трёх источниках: метрики (числа во времени — для алертов и дашбордов, дёшевы, долго хранятся), логи (дискретные события с контекстом — для разбора конкретных инцидентов, дороги), трейсы (путь одного запроса через сервисы со временем на каждом шаге — для распределённой отладки производительности). Они работают в связке: метрика показывает проблему, трейс — где она возникла, лог — что именно произошло. OpenTelemetry — индустриальный стандарт, объединяющий сбор всех трёх сигналов через единый API и снимающий vendor lock-in. Главный антипаттерн — логировать всё подряд и парсить логи для алертов (числа должны быть метриками).

Что почитать