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

Представьте: за ночь упала конверсия checkout'а на 40%, а технический мониторинг молчит — CPU в норме, latency в норме. Только утром CEO видит цифры в Google Analytics и теряет выручку. Custom alerting rules по бизнес-метрикам решают эту проблему: вы узнаёте о падении заказов или росте ошибок оплаты через 5 минут. Мы настроили такие алерты для десятков e-commerce, SaaS и контентных проектов. Подход прост: инструментируем код прометеевскими метриками, задаём пороги с учётом сезонности и настраиваем маршрутизацию в Slack или PagerDuty. Результат — время реакции на бизнес-критические проблемы сокращается с часов до минут. По данным исследований, час простоя checkout'а обходится крупному e-commerce в среднем в $4.5k–6.5k. В этой статье разберём, какие метрики мониторить, как реализовать алерты на 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 dollars',
    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 и контентных проектов. Гарантируем стабильную работу и адекватные уведомления без ложных срабатываний.