Налаштування алертів на метрики веб-застосунку
Алертинг без обдуманості превращається в шум: 200 сповіщень за ніч, половина вирішена за 2 хвилини. Команди перестають реагувати — саме тоді приходить реальна проблема. Ціль: алерти тільки на ситуації що потребують дії людини.
Принципи перед налаштуванням
Алертувати на симптоми, не причини. Алерт на "сайт недоступний для користувачів" важливіший ніж "CPU > 80%". Високий CPU — причина що може і не впливати на користувачів.
Чотири золоті сигнали (Google SRE Book):
- Latency — час відповіді
- Traffic — rps/rpm
- Errors — відсоток помилок
- Saturation — утилізація ресурсів
Почніть з перших трьох.
Burn rate замість порогів. "Error rate > 5% протягом 5 хвилин" краще ніж "1 помилка за хвилину". Burn rate показує як швидко ви "спалюєте" ваш SLO-бюджет помилок.
Стек: Prometheus + Alertmanager + Grafana
Правила алертів у Prometheus:
groups:
- name: web-app
rules:
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "Error rate {{ $value | humanizePercentage }} for {{ $labels.instance }}"
- alert: SlowResponses
expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
for: 10m
labels:
severity: warning
annotations:
summary: "p95 latency is {{ $value }}s"
- alert: DatabaseConnections
expr: pg_stat_activity_count > 90
for: 5m
labels:
severity: warning
Розклад
Базові алерти для основних метрик: 1 день. Уточнені пороги та кореляція по сервісам: 2-3 дні.