Какие правила для настройки алертов в системах мониторинга вы знаете?

При настройке алертов в Prometheus, Grafana или Zabbix я придерживаюсь следующих правил, чтобы они были полезными, а не создавали шум:

1. Измеряй симптомы, а не причины. Алерт должен сигнализировать о проблеме, видимой пользователю (высокая задержка, ошибки 5xx), а не о внутреннем сбое подсистемы (например, полный диск — это причина, а не симптом).
2. Избегай «шумных» алертов. Используй параметр for в Prometheus Rules, чтобы алерт срабатывал только при устойчивом состоянии. Это отсекает кратковременные всплески.
3. Четкие условия и приоритеты. Каждому алерту присваивается уровень серьезности (severity: warning/critical). Условие должно быть однозначным и основанным на SLO/SLA.
4. В аннотациях — готовый runbook. В описании алерта я сразу добавляю ссылку на документацию или краткий план действий для дежурного.
5. Иерархия и группировка. Использую group_by в Alertmanager, чтобы связанные алерты (например, все инстансы одного сервиса) приходили одним уведомлением, а не лавиной.

Пример осмысленного алерта в Prometheus:

groups:
- name: api-slo
  rules:
  - alert: APIHighErrorRate
    expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01
    for: 2m
    labels:
      severity: critical
      service: payment-gateway
    annotations:
      summary: "Высокий процент ошибок в Payment Gateway"
      description: "Доля 5xx ошибок превышает 1% более 2 минут. Текущее значение: {{ $value }}"
      runbook_url: "https://wiki.internal/runbooks/payment-gateway-5xx"