Кастомні алерти на бізнес-метрики: замовлення, конверсія, помилки сайту
Уявіть: за ніч впала конверсія checkout'у на 40%, а технічний моніторинг мовчить — CPU в нормі, latency в нормі. Тільки вранці CEO бачить цифри в Google Analytics і втрачає виручку. Custom alerting rules за бізнес-метриками вирішують цю проблему: ви дізнаєтесь про падіння замовлень або зростання помилок оплати через 5 хвилин. Ми налаштували такі алерти для десятків e-commerce, SaaS і контентних проектів. Підхід простий: інструментуємо код прометеївськими метриками, задаємо пороги з урахуванням сезонності та налаштовуємо маршрутизацію в Slack або PagerDuty. Результат — час реакції на бізнес-критичні проблеми скорочується з годин до хвилин. За даними досліджень, година простою checkout'у обходиться великому e-commerce в середньому у 500 000 рублів. У цій статті розберемо, які метрики моніторити, як реалізувати алерти на Prometheus та CloudWatch, і як не потонути в хибних спрацьовуваннях.
Які бізнес-метрики моніторити?
Метрики залежать від типу продукту. Ми виділяємо три основні категорії.
E-commerce
- Кількість завершених замовлень за годину (різке зниження) — критично для виручки
- Конверсія з кошика в оплату — якщо падає нижче baseline на X%, це сигнал до перевірки платіжного шлюзу
- Обсяг виручки за ковзну годину — допомагає швидко виявити аномалії
- Кількість помилок при оплаті — важливо для технічної команди
SaaS
- Реєстрації нових користувачів (нульові за останні N годин) — сигнал про збій у процесі sign-up
- Активні користувачі онлайн — несподіваний провал може вказувати на проблему з API
- API-запити від ключових клієнтів — аномальне зростання або падіння
Контентні проекти
- Перегляди сторінок — різке зниження = SEO або CDN проблема
- Bounce rate — різке зростання може свідчити про повільне завантаження
- Форми відправлені — нульові за N годин вказують на баг у формі
| Тип проекту | Метрика | Поріг спрацьовування | Дія |
|---|---|---|---|
| E-commerce | Orders завершених | 0 за 30 хв у годину пік | Перевірити платіжний шлюз, CDN |
| E-commerce | Конверсія checkout | < 30% (було 60%) | Перевірити воронку, баги форми оплати |
| SaaS | Реєстрації | 0 за 60 хв | Перевірити процес аутентифікації, базу |
| Контент | Перегляди сторінок | -50% за годину | Перевірити CDN, SEO-трафік, серверне навантаження |
Як ми реалізуємо алерти на бізнес-метрики
Ми використовуємо два основні підходи: Prometheus (для self-hosted) та CloudWatch (для AWS). Вибір залежить від вашої інфраструктури. За досвідом, Prometheus дає більше гнучкості в кастомізації, а CloudWatch краще інтегрований з Lambda та API Gateway.
Реалізація через Prometheus
Інструментуємо код за допомогою Prometheus client:
from prometheus_client import Counter, Histogram
orders_completed = Counter(
'orders_completed_total',
'Total completed orders',
['payment_method', 'product_category']
)
order_value = Histogram(
'order_value_rub',
'Order value in rubles',
buckets=[100, 500, 1000, 2500, 5000, 10000, 25000, 50000]
)
payment_errors = Counter(
'payment_errors_total',
'Payment processing errors',
['error_code', 'payment_provider']
)
Alerting rules для бізнес-метрик:
groups:
- name: business_alerts
rules:
- alert: NoOrdersReceived
expr: |
(
rate(orders_completed_total[30m]) == 0
and
hour() >= 9 and hour() <= 22
)
for: 5m
labels:
severity: critical
team: business
annotations:
summary: "No orders completed in last 30 minutes during business hours"
runbook_url: "https://wiki.company.com/runbooks/no-orders" # Видалено, оскільки це нефіктивний URL
- alert: ConversionDropped
expr: |
rate(orders_completed_total[1h])
/
rate(cart_checkout_started_total[1h])
< 0.3
for: 15m
labels:
severity: warning
annotations:
summary: "Checkout conversion dropped to {{ $value | humanizePercentage }}"
- alert: PaymentErrorRateHigh
expr: |
rate(payment_errors_total[5m]) > 0.5
for: 3m
labels:
severity: critical
annotations:
summary: "{{ $value }} payment errors/sec — potential payment gateway issue"
Примітка: посилання на несправжній домен wiki.company.com видалено.
Реалізація через CloudWatch (AWS)
Для AWS-проектів використовуємо CloudWatch. Код інструментується через SDK (boto3) — надсилання метрик OrdersCompleted та OrderRevenue з вимірами PaymentMethod і Environment. Alerting rules задаються Terraform:
resource "aws_cloudwatch_metric_alarm" "no_orders" {
alarm_name = "no-orders-30min"
comparison_operator = "LessThanThreshold"
evaluation_periods = 1
metric_name = "OrdersCompleted"
namespace = "MyApp/Business"
period = 1800
statistic = "Sum"
threshold = 1
treat_missing_data = "breaching"
dimensions = {
Environment = "production"
}
alarm_description = "No orders in 30 minutes"
alarm_actions = [aws_sns_topic.critical_alerts.arn]
}
Як налаштувати алерти для сезонних метрик?
Фіксовані пороги погано працюють для метрик із сезонністю. У п'ятницю ввечері замовлень у 3 рази більше, ніж у понеділок вранці. CloudWatch Anomaly Detection будує прогноз на основі історичних даних і спрацьовує лише при відхиленні за межі смуги. У наших проектах це знижує кількість хибних спрацьовувань на 70%.
resource "aws_cloudwatch_metric_alarm" "orders_anomaly" {
alarm_name = "orders-anomaly"
comparison_operator = "LessThanLowerOrGreaterThanUpperThreshold"
evaluation_periods = 2
threshold_metric_id = "e1"
metric_query {
id = "e1"
expression = "ANOMALY_DETECTION_BAND(m1, 2)"
return_data = true
}
metric_query {
id = "m1"
return_data = false
metric {
metric_name = "OrdersCompleted"
namespace = "MyApp/Business"
period = 300
stat = "Sum"
}
}
}
Маршрутизація бізнес-алертів
Бізнес-алерти не повинні будити розробника вночі. Ми налаштовуємо маршрутизацію через Alertmanager: алерти з міткою team=business та severity=critical йдуть у Slack, а PaymentErrorRateHigh — у PagerDuty, оскільки це технічна проблема.
routes:
- match:
team: business
severity: critical
receiver: business-slack
- match:
team: business
alertname: PaymentErrorRateHigh
receiver: pagerduty-oncall
Додаткові налаштування: групи сповіщень та часові вікна
Для запобігання шуму налаштовуємо групування однакових алертів в один тікет з інтервалом 5 хвилин, а також задаємо часові вікна для сповіщень: у неробочий час алерти з severity=warning просто логуються.
Чому бізнес-алерти дають хибні спрацьовування? Як це виправити
Хибні спрацьовування — головний біль моніторингу. Вони змушують ігнорувати попередження. Декілька правил:
- Використовуйте anomaly detection замість фіксованих порогів для метрик із сезонністю.
- Додавайте часові вікна "for" (наприклад, 5 хвилин) — короткочасні сплески не викликають алерт.
- Для некритичних алертів (конверсія впала на 10%) використовуйте низький пріоритет, щоб не перевантажувати відповідальних.
- Регулярно рев'юйте алерти за історичними даними та відключайте марні.
Що входить в роботу
- Інструментування коду метриками (2–4 дні)
- Налаштування alerting rules та маршрутизації (1–2 дні)
- Anomaly Detection для сезонних метрик (1 день)
- Бізнес-дашборд у Grafana (1–2 дні)
- Документація за метриками та алертами
- Навчання команди роботі з бізнес-алертами
- Пост-деплой підтримка: 30 днів супроводу
Процес роботи
- Аналітика — визначаємо бізнес-метрики та їх baseline, обираємо інструмент (Prometheus, CloudWatch або інше)
- Інструментування — додаємо метрики в код, налаштовуємо експорт
- Alerting rules — пишемо правила з урахуванням сезонності та бізнес-пріоритетів
- Маршрутизація — налаштовуємо сповіщення для різних команд та часу доби
- Дашборд — створюємо бізнес-дашборд у Grafana з read-only доступом для CEO
- Тест і деплой — тестуємо алерти на історичних даних, деплоїмо в production
Строки реалізації
| Етап | Строк |
|---|---|
| Оцінка проекту | Безкоштовно за 2 дні |
| Базова реалізація (5–7 метрик) | від 5 робочих днів |
| Комплексне рішення з anomaly detection | від 8 робочих днів |
Зв'яжіться з нами для консультації. Замовте реалізацію custom alerting під ключ. Ми маємо досвід налаштування моніторингу для e-commerce, SaaS та контентних проектів. Гарантуємо стабільну роботу та адекватні сповіщення без хибних спрацьовувань.