Observability: метрики, логи, трейсинг и ошибки

Пятый урок раздела. Мониторинг отвечает на вопрос “что сломалось”. Observability отвечает на вопрос “почему”, причём на проблемы, которые ты заранее не предусмотрел. Разница принципиальна: мониторинг это заранее заведённые дашборды на известные поломки, observability это возможность задать системе новый вопрос на лету, когда случилось то, чего никто не ждал. В распределённой системе без неё отладка превращается в гадание по разрозненным логам.

Идея: три столпа, три разных вопроса

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

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

Хорошая практика: алерт срабатывает по метрике (что-то не так), трейс показывает, в каком сервисе (где), лог даёт детали (почему). Три столпа работают как воронка от симптома к причине.

Метрики: Prometheus и Grafana

Prometheus периодически опрашивает у сервисов эндпоинт /metrics и копит временные ряды, а Grafana рисует по ним дашборды и шлёт алерты. Четыре базовых сигнала, с которых стоит начинать любой сервис (golden signals):

• Latency: как быстро отвечаем (смотри перцентили p95/p99, не среднее, среднее прячет хвост).
• Traffic: сколько запросов.
• Errors: доля ошибок.
• Saturation: насколько забиты ресурсы.

Совет про перцентили важен на практике: среднее время ответа может быть прекрасным, пока каждый сотый пользователь ждёт пять секунд. Хвост видно только в p99.

Логи: структурированно и централизованно

Логи полезны, когда они структурированы и собраны в одном месте. console.log('user', id) это мусор в проде. Структурированный лог это объект с полями, который можно фильтровать и связывать с трейсом:

logger.info({
  event: 'order.created',
  orderId,
  userId,
  traceId,   // связь с трейсом
  durationMs,
});

Собирают их в централизованное хранилище: ELK или Loki. Ключевое поле в каждом логе это traceId: оно сшивает лог с трейсом и метриками, превращая три столпа в одну связную картину.