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

Представьте: за ночь упала конверсия 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" - 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 

Почему бизнес-алерты дают ложные срабатывания? Как это исправить

Ложные срабатывания — главная головная боль мониторинга. Они заставляют игнорировать предупреждения. Несколько правил:

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