Best practices: как не утонуть в данных наблюдаемости

Проблема: данных много, пользы мало

Большинство команд приходят к одному из двух антипаттернов. Первый — логировать всё подряд, не думая об уровнях и структуре. Через месяц поиск по логам занимает минуты, алерты срабатывают десятки раз в день, и никто уже не реагирует. Второй — не логировать ничего существенного, пока не случится инцидент. Оба приводят к одному результату: платформа наблюдаемости есть, но от неё нет пользы.

Принцип 1: логируйте события, не состояние

Самая частая ошибка — логировать промежуточное состояние вместо значимых событий. Запись «Processing request» каждые 100мс засоряет поиск и не несёт информации. Запись «Payment failed: timeout after 3000ms» — это событие, которое требует внимания.

Принцип 2: используйте уровни логирования как контракт

Уровни — это не просто пометки. Это соглашение между разработчиком и операционной командой о том, на что реагировать.

Когда использовать каждый уровень

Принцип 3: структурированные логи вместо строк

Неструктурированная строка «User 12345 paid 4900 rubles» требует regex для поиска по userId. Структурированный лог с полями userId и amount позволяет фильтровать и агрегировать мгновенно — особенно в Elasticsearch, который индексирует каждое поле.

Что включать в контекст события

• check_circleИдентификаторы: userId, requestId, correlationId, sessionId
• check_circleРезультат: success/failure, статус-код, сообщение ошибки
• check_circleИзмеримые значения: amount, duration, count, size
• check_circleОкружение: environment, version, region — для фильтрации по деплою
• check_circleВременные метки уже добавляет платформа — не дублируйте вручную

Принцип 4: алерт = обязательное действие

Алерт, который можно проигнорировать — это шум. Прежде чем создать алерт, ответьте на вопрос: «Что я сделаю, когда он сработает?» Если ответа нет — алерт не нужен.

Критерии хорошего алерта

• check_circleActionable: есть конкретный следующий шаг при срабатывании
• check_circleRare: срабатывает не чаще нескольких раз в неделю в норме
• check_circleAccurate: низкий уровень ложных срабатываний (false positive < 5%)
• check_circleTimely: срабатывает достаточно быстро, чтобы среагировать до значимого ущерба
• check_circleOwned: есть конкретный человек или команда, ответственные за реакцию

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

• check_circleАлерт на каждый Error-лог — в норме их могут быть сотни в час
• check_circleАлерт без порога — любое единичное событие вызывает шум
• check_circleАлерт-дубликат — несколько алертов на одну и ту же проблему
• check_circleАлерт без owner — все видят, никто не реагирует
• check_circleАлерт на симптом вместо причины — тушите пожар, не источник

Принцип 5: метрики для трендов, логи для диагностики

Распространённая ошибка — пытаться использовать логи как метрики (считать ошибки вручную) или метрики как логи (хранить детальные события в time series). У каждого инструмента своя роль.

Когда логи, когда метрики, когда бизнес-события

Принцип 6: разные настройки для разных окружений

То, что нужно в development, мешает в production. Единая конфигурация логирования на все окружения — один из главных источников шума.

Рекомендуемые настройки по окружениям

• check_circleDevelopment: Debug и выше — детально, но только локально
• check_circleStaging: Information и выше — тестирование с реалистичным уровнем логов
• check_circleProduction: Warning и выше для большинства модулей, Error и выше для некритичных
• check_circleКритичные модули (payments, auth) — Information и выше в production для аудита
• check_circleВременный Debug в production: включайте только через feature flag с автоматическим отключением

Принцип 7: retention — удаляйте то, что не смотрите

Хранить логи за 2 года не имеет смысла, если инциденты разбираются за 72 часа. Избыток хранилища замедляет поиск и увеличивает стоимость. Определите, за какой период данные реально используются, и настройте retention под это.

Типичные горизонты хранения по типу данных

• check_circleDebug логи: 24–48 часов (только для активной отладки)
• check_circleInfo/Warning логи: 7–30 дней
• check_circleError/Critical логи: 30–90 дней
• check_circleМетрики с высоким разрешением (1 мин): 7–14 дней
• check_circleМетрики с низким разрешением (1 час): 6–12 месяцев
• check_circleБизнес-события (Value Tracking): 90–365 дней — нужны для бизнес-аналитики

Чеклист: аудит текущей observability

• check_circleПосчитайте долю Debug-логов в production — если больше 20%, выключите
• check_circleПроверьте алерты за последний месяц: какие срабатывали, какие игнорировались
• check_circleНайдите дублирующие алерты — два алерта на одну и ту же проблему
• check_circleДобавьте correlationId во все запросы, если его ещё нет
• check_circleУбедитесь, что каждый Error-лог содержит userId или requestId для диагностики
• check_circleПроверьте retention — удаляется ли то, что вы не смотрите