От логов к метрикам и обратно: как построить наблюдаемость без шума
Не все события одинаково полезны. Как проектировать наблюдаемость систем так, чтобы она давала сигнал, а не создавала дополнительный поток мусора.
Когда система начинает плохо работать, первый вопрос всегда один: что происходит внутри? Хорошая наблюдаемость даёт ответ быстро. Плохая - заставляет команду часами рыться в логах, которые записывают всё подряд, не отвечая ни на один вопрос.
Я заметил, что большинство систем мониторинга строятся по принципу "пишем как можно больше, потом разберёмся". Это создаёт иллюзию контроля и реальный шум.
Разница между логами, метриками и трассировкой
Три понятия часто смешивают, хотя у каждого своя роль.
Лог - это запись о конкретном событии с контекстом: что произошло, когда, с какими параметрами. Логи хороши для расследования инцидентов - когда что-то пошло не так и нужно восстановить последовательность событий. Логи как структурированный источник данных полезны ещё до появления SIEM.
Метрика - это числовое значение, которое меняется со временем: количество запросов в секунду, время отклика, процент ошибок. Метрики хороши для мониторинга нормального состояния системы и обнаружения отклонений.
Трассировка - это путь одного запроса через несколько компонентов системы. Трассировка нужна там, где система распределённая и запрос обрабатывается последовательно разными сервисами.
Проблема в том, что без чёткого понимания что и зачем - все три слоя начинают дублировать друг друга и множить объём данных без пользы.
Откуда берётся шум
Самый распространённый источник шума в мониторинге - это логирование на уровне DEBUG в продакшне. Разработчик добавил подробное логирование при отладке, забыл убрать, и теперь система пишет несколько гигабайт в сутки о событиях, которые никому не нужны в штатном режиме.
Второй источник - алерты на всё подряд. Когда каждое отклонение от нормы порождает уведомление, команда начинает игнорировать уведомления. Это хуже, чем отсутствие мониторинга: есть ложное ощущение, что всё под контролем.
Третий источник - метрики без контекста. Число запросов само по себе ничего не говорит. Важно знать, что является нормой, каков приемлемый диапазон отклонений, и что должно происходить при выходе за этот диапазон.
Как проектировать наблюдаемость
Хорошая наблюдаемость проектируется от вопросов, а не от инструментов. Полезно начать с нескольких прямых вопросов о каждой системе или сервисе.
Что означает "система работает нормально"? Какие числовые показатели это подтверждают? Это и есть основные метрики - их должно быть немного, но они должны быть всегда актуальными.
Что означает "система начинает деградировать" - до того, как это заметил пользователь? Это метрики для раннего предупреждения. Они должны давать сигнал с запасом времени на реакцию.
Что нужно для расследования инцидента? Это определяет, что должно быть в логах: не всё подряд, а те события и контекст, которые позволяют восстановить причину проблемы.
Сигнал, а не объём
Хорошее практическое правило: если никто не смотрит на какие-то данные мониторинга регулярно и не использует их при инцидентах - скорее всего, их не нужно собирать.
Это не призыв к минимализму ради минимализма. Это призыв к тому, чтобы каждый элемент наблюдаемости имел владельца, который понимает зачем это нужно, и сценарий использования.
Системы, в которых это сделано хорошо, обычно выглядят скромно снаружи: несколько ключевых дашбордов, небольшое число алертов с чёткими порогами и чёткой ответственностью. Но именно они позволяют команде отвечать на инциденты быстро, не теряясь в потоке данных.
Вопросы для проверки
Несколько вопросов, которые помогают оценить состояние наблюдаемости в компании:
- Как быстро команда замечает проблему в продакшне - до звонка клиента или после?
- Сколько времени занимает диагностика после обнаружения проблемы?
- Есть ли алерты, которые команда привыкла игнорировать?
- Если уйдёт человек, который "знает как читать логи" - сможет ли другой разобраться?
- Сколько данных мониторинга хранится и сколько из них реально используется?
Если на большинство вопросов нет хорошего ответа - наблюдаемость стоит проектировать заново, а не накапливать поверх существующего.