Алерты, на которые понятно как реагировать

Начните с пользовательского симптома

Разделите сигналы об ухудшении сервиса и сигналы о возможной будущей проблеме. Рост доли неуспешных запросов и нарушение допустимой задержки ближе к опыту пользователя, чем отдельное значение загрузки сервера.

Ресурсные метрики нужны для диагностики и планирования. Их пороги должны учитывать контекст: короткий всплеск и устойчивое исчерпание ресурса требуют разных действий.

У каждого правила есть владелец и действие

• Условие: что сломалось и как долго это продолжается.
• Контекст: окружение, сервис, ссылки на график и журнал.
• Влияние: какая функция может быть недоступна.
• Первый шаг: короткая проверка или ссылка на runbook.
• Ответственный: кому эскалировать проблему.

Если для сигнала нельзя описать разумное действие, возможно, ему место на дашборде или в периодическом отчёте.

Пример правила с оговорками

Ниже пример для сервиса с метрикой http_requests_total и меткой status. Порог 5% — иллюстрация, его нужно выбрать под требования сервиса. Для редкого трафика добавьте проверку достаточного объёма запросов.

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
> 0.05

В alerting rule можно использовать for, чтобы условие сохранялось заданное время. Но слишком долгая задержка скроет короткий серьёзный отказ.

Регулярно разбирайте шум

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