Налаштування алертів за метриками веб-додатку

Сповіщення без продуманої методології перетворюються на шум: 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 день. Замовте налаштування моніторингу, щоб позбутися шуму та спати спокійно. Обговоримо налаштування сповіщень — розберемо ваш сценарій.