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