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

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