Как внедрять алерты в системе мониторинга?

Я внедряю алертинг на основе стека Prometheus + Alertmanager + Grafana, следуя принципу "меньше, но качественнее". Вот мой подход:

1. Архитектура алертинга:

# prometheus.yml
rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - alertmanager:9093

# alertmanager.yml
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-notifications'
  routes:
  - match:
      severity: critical
    receiver: 'pagerduty'
    repeat_interval: 30m

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'
    send_resolved: true
- name: 'pagerduty'
  pagerduty_configs:
  - service_key: <pd_key>

2. Создание meaningful алертов (примеры из практики):

# rules/application.yml
groups:
- name: application
  rules:
  - alert: HighErrorRate
    expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100 > 5
    for: 2m
    labels:
      severity: critical
      team: backend
    annotations:
      summary: "High error rate on {{ $labels.service }}"
      description: "Error rate is {{ $value }}% for service {{ $labels.service }}"
      runbook: "https://wiki.company.com/runbooks/high-error-rate"

  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} is crash looping"

  - alert: HighMemoryUsage
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "High memory usage on {{ $labels.instance }}"

3. Принципы, которые я применяю:

• Трехуровневая система: warning → critical → page (для on-call)
• Избегание alert fatigue: Использую for для подавления флуктуаций, группирую связанные алерты
• Runbooks: Для каждого алерта создаю документацию по устранению
• Тестирование алертов: Провожу fire drills и chaos experiments для проверки срабатывания

4. Интеграции, которые настроил на последнем проекте:

1. Slack — для всех warning алертов
2. PagerDuty — для critical алертов в рабочее время, всегда — для production инцидентов
3. JIRA — автоматическое создание тикетов для recurring алертов
4. Grafana — визуализация состояния алертов на дашбордах

5. Мониторинг самих алертов:

- alert: PrometheusJobMissing
  expr: up == 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Prometheus job {{ $labels.job }} missing"

- alert: AlertmanagerNotConnected
  expr: alertmanager_alerts < 1
  for: 10m
  labels:
    severity: critical

6. Практический пример: На Kubernetes кластере из 50+ нод я настроил 25 алертов, сгруппированных по:

• Инфраструктура (ноды, сеть, диски)
• Приложения (error rate, latency, throughput)
• Бизнес-метрики (количество транзакций, успешность платежей)

В результате количество ложных срабатываний снизилось с 30 в день до 2-3, а MTTR (mean time to resolve) для critical инцидентов уменьшился с 45 до 15 минут.