Алертинг по логам

Чтобы не сидеть и не смотреть в дашборд вечно, настраивают правила, которые сами зовут вас при проблеме.

Алерт (правило) в Kibana — условие на данные логов, которое периодически проверяется, и при срабатывании отправляет оповещение в заданный канал (email, Slack, PagerDuty).

Зачем алертинг, если есть дашборды

Дашборд показывает проблему, только если на него кто-то смотрит. В три часа ночи никто не смотрит. Алертинг переворачивает модель с «человек следит за данными» на «данные зовут человека»: правило само ищет в логах признак беды и поднимает дежурного. Это разница между «узнали об инциденте из логов через 20 минут» и «узнали от разъярённых пользователей через два часа».

Типичные правила по логам

• Всплеск ошибок. «Число событий level: ERROR за последние 5 минут больше 100» — резкий рост сбоев.
• Появление критического паттерна. «Есть хоть одно событие с message: "OutOfMemoryError"» — то, что недопустимо в принципе.
• Рост доли 5xx. «Доля status >= 500 среди запросов превысила 5%».
• Тишина. «От сервиса payments ноль логов за 10 минут» — сервис, возможно, умер (это сложнее: отсутствие данных как сигнал).

Как устроено правило

Правило в Kibana (Stack Management → Rules) состоит из частей: тип (например, «Elasticsearch query» или «Log threshold»), условие (KQL-запрос + порог + окно времени), расписание (как часто проверять, например раз в минуту) и коннектор (куда слать). Схематично:

  каждую минуту:
    запрос: level: "ERROR" за последние 5 мин
    если count > 100:
        --> коннектор Slack: "Всплеск ошибок!"
        --> коннектор PagerDuty: разбудить дежурного

Как работает под капотом

Движок правил Kibana (Alerting) по расписанию выполняет в Elasticsearch агрегирующий запрос (тот самый count с фильтром и диапазоном), сравнивает результат с порогом и при срабатывании создаёт alert instance, который дёргает коннекторы. Важная деталь — состояние: правило помнит, что алерт уже активен, и не шлёт одно и то же оповещение каждую минуту, пока проблема длится (это называется flapping/throttling). Когда условие перестаёт выполняться, многие настройки шлют «recovered».

Логи vs метрики в алертинге

На метриках алерты ставят на тренды («CPU > 90%»). На логах — на события и их частоту («появился стектрейс X», «ошибок стало >N»). Логовый алертинг ловит то, что метрика не видит: конкретный текст исключения, ошибку у конкретного пользователя, новый тип сбоя. Зрелая система использует оба: метрика-алерт сообщает «плохо», а логовый — «вот именно что плохо».

Культура алертов, а не только техника

Технически настроить правило несложно; гораздо труднее построить здоровую культуру алертов. Главный враг — усталость от оповещений (alert fatigue): когда алертов слишком много или они шумные, команда перестаёт на них реагировать, и в потоке ложных срабатываний тонет настоящий инцидент. Поэтому к каждому алерту применяют простой тест: требует ли это срабатывание немедленного действия человека? Если нет — это не алерт, а в лучшем случае запись для дашборда или отчёта. Алерт, на который правильная реакция «посмотрел и закрыл, ничего не делая», нужно либо ужесточить, либо удалить. Несколько точных, всегда значимых алертов ценнее сотни шумных.

Второй столп культуры — runbook у каждого алерта: короткая инструкция «что это значит и что делать первым делом». Алерт «всплеск 5xx в billing» без runbook будит дежурного, который в полусне гадает, с чего начать. Тот же алерт со ссылкой на инструкцию (проверь дашборд, посмотри логи по trace_id, проверь статус платёжного шлюза) превращает панику в процедуру. Хороший алерт — это не просто условие, а условие плюс понятный следующий шаг.

Частые ошибки

• Слишком чувствительные пороги. Алерт, орущий по каждой единичной ошибке, быстро превращается в шум, который перестают читать (alert fatigue). Пороги должны отражать реальную аномалию.
• Нет дедупликации. Без throttling один инцидент засыпет канал сотней одинаковых сообщений. Полагайтесь на состояние правила.
• Алерт без действия. Правило, на которое никто не реагирует и нет инструкции «что делать», бесполезно. У каждого алерта должен быть runbook.

Итоги

• Алертинг превращает «человек следит за логами» в «логи зовут человека» — критично для ночей и выходных.
• Правило = условие (KQL + порог + окно) + расписание + коннектор доставки.
• Движок помнит состояние алерта и не дублирует оповещения, пока инцидент длится.
• Логовые алерты ловят конкретные события и паттерны, дополняя трендовые алерты по метрикам.