Log levels и маршрутизация алертов

Slack on-call-инженера завален ERROR-алертами. Половина — повторные попытки, которые прошли успешно. Алерты — шум, реальные ошибки тонут, on-call перестаёт реагировать. Баг не в сервисе — в level, присвоенном log-строке.

Лестница levels

Продакшн-лестница имеет шесть ступеней: TRACE / DEBUG / INFO / WARN / ERROR / FATAL. Каждая ступень — контракт о том, какое действие подразумевает log-строка.

Продакшн-дефолт: INFO и выше

Продакшн-дефолт в 2026 — INFO и выше. DEBUG включается только через dynamic flag во время активного расследования — никогда по умолчанию. TRACE редко встречается вне внутренностей фреймворка.

INFO представляет success-path: смены состояний, позволяющие человеку реконструировать, что делал сервис — request_received, request_completed, kafka_message_processed, transaction_committed. Без INFO-строк нельзя реконструировать нормальное поведение до ошибки.

WARN — для recoverable-проблем: retry успешно прошёл после 3 попыток, взят fallback-путь, deprecation-hit, приближение к rate limit. Система продолжила; возможно, нужно что-то сделать в будущем.

ERROR — для unrecoverable-проблем с недоделанной работой: запрос вернул 5xx, сообщение ушло в dead-letter queue, запись откатилась. Кто-то должен расследовать.

FATAL — для «процесс вот-вот умрёт»: assertion failure, неизбежный OOM. После этого процесс обычно сразу падает или перезапускается.

Маршрутизация алертов следует лестнице levels

Контракт level подразумевает маршрутизацию алертов:

• ERROR + FATAL питают пейджеры и incident-каналы. Пейджер — неявное обещание, что нужно действие.
• WARN питает Slack и capacity-дашборды. Немедленного действия не требует; тренд стоит отслеживать.
• INFO запрашивается во время расследования, никогда не алертится напрямую. Алерт на объём INFO срабатывал бы постоянно на нормальном трафике.
• DEBUG / TRACE полностью фильтруются из продакшн-хранилища.

Почему неправильная классификация вредит

INFO там, где нужен WARN: проблема закапывается в INFO-поток. WARN-маршрутизация не срабатывает. Медленная деградация невидима, пока не станет ERROR.

ERROR там, где нужен WARN: каждый retry, каждый cache miss, каждый ожидаемый таймаут пейджит on-call. On-call перестаёт реагировать. Когда приходит реальный ERROR, он тонет в шуме. Alert fatigue — один из самых опасных observability-провалов, и почти всегда вызывается over-classified levels.

DEBUG, оставленный включённым в продакшне: runaway cost. Сервис, эмитирующий DEBUG на 1000 req/s, логирует внутренние детали на каждый вызов. При throughput pino ~140k msg/sec это ещё выполнимо, но объём — в 100x раз больше INFO-потока — попадает на backend с полной ingest-ценой. Команды получали счета в 10x за один PR, оставивший debug-флаг включённым.