Настройка алертов по метрикам веб-приложения

Алертинг без продуманной методологии превращается в шум: 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

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, вы не привязаны к вендору, и при масштабировании стоимость значительно ниже. На одном из проектов мы снизили затраты на мониторинг в 3 раза, перейдя с Datadog на самописный стек. Такая конфигурация окупается за несколько месяцев за счёт снижения затрат на инфраструктуру.

Процесс работы и ориентировочные сроки

Базовая настройка (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 день. Закажите настройку мониторинга, чтобы избавиться от шума и спать спокойно. Получите консультацию по настройке алертинга — это бесплатно.