Кастомні алерти на бізнес-метрики: замовлення, конверсія, помилки сайту

Уявіть: за ніч впала конверсія 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 годин вказують на баг у формі

Як ми реалізуємо алерти на бізнес-метрики

Ми використовуємо два основні підходи: 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 

Чому бізнес-алерти дають хибні спрацьовування? Як це виправити

Хибні спрацьовування — головний біль моніторингу. Вони змушують ігнорувати попередження. Декілька правил:

• Використовуйте anomaly detection замість фіксованих порогів для метрик із сезонністю.
• Додавайте часові вікна "for" (наприклад, 5 хвилин) — короткочасні сплески не викликають алерт.
• Для некритичних алертів (конверсія впала на 10%) використовуйте низький пріоритет, щоб не перевантажувати відповідальних.
• Регулярно рев'юйте алерти за історичними даними та відключайте марні.

Що входить в роботу

• Інструментування коду метриками (2–4 дні)
• Налаштування alerting rules та маршрутизації (1–2 дні)
• Anomaly Detection для сезонних метрик (1 день)
• Бізнес-дашборд у Grafana (1–2 дні)
• Документація за метриками та алертами
• Навчання команди роботі з бізнес-алертами
• Пост-деплой підтримка: 30 днів супроводу

Процес роботи

1. Аналітика — визначаємо бізнес-метрики та їх baseline, обираємо інструмент (Prometheus, CloudWatch або інше)
2. Інструментування — додаємо метрики в код, налаштовуємо експорт
3. Alerting rules — пишемо правила з урахуванням сезонності та бізнес-пріоритетів
4. Маршрутизація — налаштовуємо сповіщення для різних команд та часу доби
5. Дашборд — створюємо бізнес-дашборд у Grafana з read-only доступом для CEO
6. Тест і деплой — тестуємо алерти на історичних даних, деплоїмо в production

Строки реалізації

Зв'яжіться з нами для консультації. Замовте реалізацію custom alerting під ключ. Ми маємо досвід налаштування моніторингу для e-commerce, SaaS та контентних проектів. Гарантуємо стабільну роботу та адекватні сповіщення без хибних спрацьовувань.