Представьте: за ночь упала конверсия 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"
- 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"
Реализация через 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 и контентных проектов. Гарантируем стабильную работу и адекватные уведомления без ложных срабатываний.