Алертинг без продуманной методологии превращается в шум: 200 уведомлений за ночь, половина из которых «resolved» через 2 минуты. Команда перестаёт реагировать — и именно тогда приходит реальная проблема. На одном из проектов мы получили 150 алертов за час из-за неверно настроенного порога CPU. После внедрения методологии burn rate их стало 5. Цель настройки — алерты только на ситуации, требующие действий человека. Правильно настроенный алертинг — это не просто нотификация, а система, которая позволяет выявить проблемы до того, как они повлияют на пользователей. Мы занимаемся этой задачей более 5 лет и настроили мониторинг для 50+ веб-приложений — от стартапов до enterprise. Ниже — инженерный подход без воды.
Какие метрики нужно мониторить в первую очередь?
Начинайте с четырёх золотых сигналов, описанных в Site Reliability Engineering: latency, traffic, errors, saturation. Для веб-приложения достаточно latency (P95), errors (5xx), traffic (RPS) и saturation (CPU, память). Дополнительно — очередь задач, SSL-сертификат, бизнес-метрики (конверсия, регистрации). SLO (Service Level Objective) — целевой уровень доступности, например 99.9% времени. SLI (Service Level Indicator) — фактическая метрика, которую мы замеряем. Алерты с burn rate позволяют быстро реагировать, когда отклонение от SLO угрожает бюджету.
Принципы эффективного алертинга
Alerting on symptoms, not causes. Алерт на «сайт недоступен для пользователей» важнее, чем «CPU > 80%». Высокий CPU — причина, которая может и не влиять на пользователей. Этот принцип описан в Google SRE Book.
Правило четырёх золотых сигналов: latency, traffic, errors, saturation. Начинайте с первых трёх. Burn rate вместо порогов: «Error rate > 5% на протяжении 5 минут» лучше, чем «1 ошибка за 1 минуту». Burn rate показывает, как быстро вы сжигаете SLO-бюджет ошибок, и позволяет выявить аномалии на ранней стадии.
Почему burn rate лучше пороговых значений?
Пороговые алерты дают много ложных срабатываний. Пример: ошибка на одном из сотни запросов — 1%, но если это длится час, бюджет ошибок (SLO 99.9%) закончится за 4 дня. Burn rate = 10. Алерт с таким значением сработает за 5 минут, а не через час. Это снижает шум в 10 раз.
Как избежать шумных алертов?
Используйте burn rate, группировку и дедупликацию в Alertmanager. Настройте group_wait (30s), group_interval (5m), repeat_interval (4h). Алерты должны быть на симптомы, а не на причины. Если CPU > 80% не влияет на пользователей — это не алерт.
Настройка стека: Prometheus + Alertmanager + Grafana
Пример docker-compose.yml
services:
prometheus:
image: prom/prometheus:v2.51.0
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- ./rules:/etc/prometheus/rules
- prometheus_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d'
ports:
- "9090:9090"
alertmanager:
image: prom/alertmanager:v0.27.0
volumes:
- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
ports:
- "9093:9093"
grafana:
image: grafana/grafana:11.0.0
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
volumes:
- grafana_data:/var/lib/grafana
ports:
- "3000:3000"
volumes:
prometheus_data:
grafana_data:
Метрики из приложения (Laravel) и конфигурация
Для Laravel устанавливаем пакет spatie/laravel-prometheus и регистрируем кастомные метрики:
// app/Providers/AppServiceProvider.php
use Prometheus\CollectorRegistry;
public function boot(): void
{
$registry = app(CollectorRegistry::class);
// Counter — количество HTTP-запросов
$httpRequests = $registry->getOrRegisterCounter(
'app', 'http_requests_total', 'Total HTTP requests', ['method', 'route', 'status']
);
// Histogram — время ответа
$httpDuration = $registry->getOrRegisterHistogram(
'app', 'http_request_duration_seconds', 'HTTP request duration', ['method', 'route'],
[0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0]
);
// Gauge — очередь задач
$queueSize = $registry->getOrRegisterGauge(
'app', 'queue_size', 'Current queue size', ['queue']
);
}
Конфигурация Prometheus:
# prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']
rule_files:
- 'rules/*.yml'
scrape_configs:
- job_name: 'web-app'
static_configs:
- targets: ['app:9000']
metrics_path: /metrics
Пример правил алертинга
# rules/web-app.yml
groups:
- name: web-app
rules:
# Высокий процент ошибок (5xx)
- alert: HighErrorRate
expr: |
sum(rate(app_http_requests_total{status=~"5.."}[5m]))
/
sum(rate(app_http_requests_total[5m])) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Error rate {{ $value | humanizePercentage }}"
description: "5xx rate exceeded 5% for 2 minutes"
# Медленные ответы (P95 > 2 секунды)
- alert: HighLatencyP95
expr: |
histogram_quantile(0.95,
sum by (le) (rate(app_http_request_duration_seconds_bucket[5m]))
) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "P95 latency {{ $value | humanizeDuration }}"
# Отсутствие трафика (аномальное падение)
- alert: TrafficDrop
expr: |
sum(rate(app_http_requests_total[5m])) < 0.1
and sum(rate(app_http_requests_total[1h] offset 1h)) > 1
for: 5m
labels:
severity: critical
annotations:
summary: "Traffic almost zero — possible outage"
# Большая очередь задач
- alert: QueueBacklog
expr: app_queue_size{queue="default"} > 1000
for: 10m
labels:
severity: warning
annotations:
summary: "Queue backlog: {{ $value }} jobs"
# SSL сертификат истекает
- alert: SSLCertExpiringSoon
expr: probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
for: 1h
labels:
severity: warning
annotations:
summary: "SSL cert expires in {{ $value | humanizeDuration }}"
Маршрутизация и дедупликация в Alertmanager
# alertmanager.yml
global:
resolve_timeout: 5m
route:
group_by: ['alertname', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'telegram-critical'
routes:
- match:
severity: critical
receiver: 'telegram-critical'
continue: false
- match:
severity: warning
receiver: 'telegram-warning'
group_interval: 15m
repeat_interval: 12h
receivers:
- name: 'telegram-critical'
telegram_configs:
- bot_token: 'your_bot_token'
chat_id: -1001234567890
message: |
🔴 *{{ .CommonLabels.alertname }}*
{{ range .Alerts }}
{{ .Annotations.summary }}
{{ if .Annotations.description }}{{ .Annotations.description }}{{ end }}
{{ end }}
- name: 'telegram-warning'
telegram_configs:
- bot_token: 'your_bot_token'
chat_id: -1001234567890
message: |
⚠️ *{{ .CommonLabels.alertname }}*
{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname']
Сравнение Prometheus и облачных сервисов
| Критерий | Prometheus + Alertmanager | Облачные сервисы (CloudWatch, Stackdriver) |
|---|---|---|
| Гибкость | Полный контроль, любые метрики | Ограниченные возможности |
| Стоимость | Бесплатно, только железо | Оплата за каждую метрику |
| Привязка к вендору | Нет | Полная |
Prometheus + Alertmanager даёт гибкость и контроль. В отличие от CloudWatch или Stackdriver, вы не привязаны к вендору, и при масштабировании стоимость значительно ниже. На одном из проектов мы снизили затраты на мониторинг в 3 раза, перейдя с Datadog на самописный стек. Такая конфигурация окупается за несколько месяцев за счёт снижения затрат на инфраструктуру.
Процесс работы и ориентировочные сроки
| Этап | Длительность | Результат |
|---|---|---|
| Аналитика | 0.5–1 день | Список золотых сигналов, SLO/SLI |
| Проектирование | 0.5 день | Схема алертов, burn rate, маршруты |
| Реализация | 1–2 дня | Prometheus, Alertmanager, Grafana |
| Тестирование | 0.5–1 день | Симуляция, хаос-тесты |
| Деплой | 0.5 день | Продакшен, обучение команды |
Базовая настройка (8–12 правил) занимает 1–2 рабочих дня. Если нужны кастомные метрики и сложная маршрутизация — до 4 дней.
Что входит в работу
- Аудит текущих метрик приложения (APM, логи, инфраструктура)
- Развёртывание Prometheus + Alertmanager + Grafana
- Написание 8–12 alert rules с burn rate
- Интеграция с Telegram, Slack или email
- Базовые дашборды Grafana (error rate, latency, RPS, queue)
- Документация и обучение команды
- Гарантия на результат и поддержка 1 месяц
Если у вас похожая задача — свяжитесь с нами для консультации. Оценим объём работ за 1 день. Закажите настройку мониторинга, чтобы избавиться от шума и спать спокойно. Получите консультацию по настройке алертинга — это бесплатно.