Алертинг
Тема дорожной карты · Observability
Алертинг — это механизм уведомления инженеров о том, что сигналы наблюдаемости системы указывают на проблему, требующую внимания человека. Эффективный алертинг строится на порогах, основанных на SLO, а не на произвольных статических лимитах: алерты должны срабатывать, когда реальное влияние на пользователей происходит или неизбежно, а не когда внутренняя метрика кратковременно вырастает. Конвейер алертинга обычно начинается с того, что Prometheus вычисляет правила PromQL, определённые в alerting_rules.yml, после чего срабатывающие алерты направляются в Alertmanager для группировки, дедупликации, ингибирования и доставки в дежурные каналы, такие как PagerDuty или Slack. Плохо спроектированный алертинг ведёт к усталости от алертов, когда инженеры начинают игнорировать пейджеры, потому что слишком много алертов низкой серьёзности или самоустраняются; хорошие практики алертинга настаивают на том, что каждый алерт должен быть actionable, задокументирован в runbook и привязан к измеримому SLI. Такие платформы наблюдаемости, как Grafana, также поддерживают алертинг из панелей дашборда, предоставляя командам визуальный контекст вместе с уведомлением.
Как это работает
Алертинг соединяет observability-данные с людьми через on-call ротации. Инструменты: Alertmanager (Prometheus-native), Grafana Alerting (multi-source), PagerDuty / OpsGenie / Squadcast (incident management поверх). Правила оценивают metrics/logs/traces-запросы; срабатывают при for: 5m; роутятся по labels (severity: page vs severity: ticket); идут в каналы (PagerDuty, Slack, Telegram, webhook). SLO burn-rate alerts — современный best practice.
Когда применять
Алертите на симптомы (SLO burn rate, error rate, latency), не на причины (CPU, RAM). Multi-window multi-burn-rate alerts — fast pages для внезапно-плохого, slow tickets для постепенной деградации. Всегда runbook URL в annotations. Тестируйте алерты в staging до production. Аудитьте alert fatigue раз в квартал — убивайте алерты, на которые никто не реагирует.
Типичные ошибки
Ловушки Алертинг: pages на инфра-метриках, не затрагивающих юзеров (CPU > 80% на 12-ядерном боксе в 3:00 на non-user-facing job); flapping-алерты (нет for:); алерты без runbook = хаос в 3:00; все алерты в один Slack-канал (alert fatigue).