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

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