Налаштування 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% часу чергового персоналу. Наші інженери сертифіковані за 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 дні).
• Подальша підтримка протягом місяця.

Отримайте консультацію: напишіть нам для аудиту вашої інфраструктури. Зв'яжіться, і ми оцінимо проєкт під ключ.