Настройка AIOps для Anomaly Detection в метриках

Прометей собирает тысячи метрик. Алерты настроены. Но ваш дежурный инженер получает 200 уведомлений за ночь — из которых 190 ложноположительные, а реальный инцидент утонул в шуме. Мы, с опытом более 5 лет в DevOps, предлагаем AIOps-подход к anomaly detection, который решает именно эту проблему. Вместо фиксированных порогов — статистические модели, учитывающие сезонность, тренды и корреляции между метриками. Это не просто снижение шума, а гарантия, что вы не пропустите настоящую аварию.

Почему классические порог-алерты не работают?

Типичная ситуация: в prometheus.rules.yml написан rate(http_requests_total[5m]) > 1000. Это работает для MVP. Для продакшена с ночными пакетными задачами, маркетинговыми акциями и сезонными пиками — уже нет. Alert Manager засыпает дежурного в часы пик каждую пятницу, команда глушит предупреждения через inhibit_rules, и в итоге реальный деградирующий сервис остаётся незамеченным на 40 минут.

Второй распространённый кейс — метрики базы данных. pg_stat_activity показывает количество коннектов. Порог поставили 80. Но нормальное количество коннектов в воскресенье ночью — 5, а в пятницу в 18:00 — 200. Один порог не подходит для обоих случаев. AIOps решает это автоматически, строя отдельные dynamic baseline для каждого временного отрезка.

Какие метрики стоит детектировать с помощью AIOps?

• Метрики с выраженной сезонностью: HTTP RPS, количество пользователей онлайн, размер очереди задач.
• Метрики с высоким variance, но предсказуемым поведением: latency по эндпоинтам, error rate.
• Метрики, чувствительные к времени суток: CPU, memory, usage по сервисам.

Не стоит использовать anomaly detection для метрик с линейным трендом (например, disk fill rate) — там эффективнее predict_linear().

Инструменты и подходы

Prometheus + Grafana ML-плагины. Grafana поддерживает функцию predict_linear() прямо в PromQL, но для настоящего anomaly detection этого недостаточно. Серьёзный вариант — Grafana ML (бывший grafana-ml плагин, теперь часть Grafana Cloud), который строит baseline по историческим данным и детектирует отклонения. Для self-hosted — Prophet от Meta через grafana-prophet-datasource или кастомный сервис.

Elastic Anomaly Detection (часть Elastic Stack Platinum/Enterprise). Конфигурируется через PUT _ml/anomaly_detectors/<job_id>:

{
  "description": "HTTP latency anomaly detection",
  "analysis_config": {
    "bucket_span": "5m",
    "detectors": [
      {
        "detector_description": "mean(response_time) by service",
        "function": "mean",
        "field_name": "response_time",
        "partition_field_name": "service"
      }
    ]
  },
  "data_description": {
    "time_field": "@timestamp"
  }
}

Такой детектор учитывает суточный и недельный паттерн автоматически — influencers помогают понять, какой конкретно сервис аномален.

Datadog Anomaly Monitor — самый быстрый в настройке вариант для команд, уже использующих Datadog. Тип алерта anomaly в monitor config поддерживает три алгоритма: basic (скользящие средние), agile (SARIMA для сезонных данных), robust (устойчив к выбросам). На практике для большинства HTTP-метрик хорошо работает agile с seasonality: weekly.

Собственный стек на базе Python + InfluxDB. Если хотите полного контроля — Prophet или statsmodels SARIMAX, скрипт читает из InfluxDB, считает доверительный интервал, пишет результат обратно как отдельную метрику. Alertmanager реагирует на выход за интервал. Это трудоёмко, но даёт максимальную гибкость под специфические метрики.

Anomaly detection и Elastic Anomaly Detection docs подтверждают эти конфигурации.

Как мы внедряем AIOps: наш опыт

Мы провели более 30 внедрений anomaly detection для компаний с разным масштабом. В одном проекте мы сократили количество ложных срабатываний с 200 до 15 в сутки, что позволило команде SRE сосредоточиться на реальных инцидентах. Экономия на инцидентах после внедрения составила до 40% времени дежурного состава. По оценкам, в одном из проектов удалось сократить финансовые потери от простоев на $14k–20k в год. Наши инженеры сертифицированы по Kubernetes, AWS и Prometheus, что гарантирует качество результата.

Процесс работы: этапы и сроки

1. Аудит текущих алертов и метрик — анализ noise-to-signal ratio за 30 дней, выявление кандидатов для anomaly detection.
2. Выбор инструмента и архитектуры — на основе вашего стека и бюджета.
3. Настройка детекторов + baseline — подбор параметров, конфигурация.
4. Период dry-run и калибровка — 2 недели параллельной работы, оценка качества.
5. Документация и обучение команды — runbook, алертинг-стратегия, обучение.

Итого: от 2 до 4 недель в зависимости от количества сервисов и сложности метрик. Стоимость рассчитывается после аудита.

Что входит в работу

• Аудит текущей системы мониторинга и алертов.
• Выбор инструмента anomaly detection под ваш стек.
• Конфигурация детекторов с учётом сезонности и трендов.
• Период dry-run с калибровкой для минимизации false positive.
• Документация: runbook по алертам, описание baseline-периодов, инструкции для дежурных.
• Обучение команды (1-2 дня).
• Последующая поддержка в течение месяца.

Получите консультацию: напишите нам для аудита вашей инфраструктуры. Свяжитесь, и мы оценим проект под ключ.