Налаштування AIOps для Log Analysis: автоматичний аналіз логів

Налаштування AIOps для Log Analysis (автоматичний аналіз логів)

Elastic повідомляє про 100 GB логів на добу, Alertmanager мовчить — порогів немає. Черговий інженер переглядає Kibana раз на дві години «на око». Інцидент помічають через 40 хвилин після того, як користувачі вже написали в підтримку. Це класична ситуація: логів багато, сигналу мало, люди втомлюються. Наші сертифіковані спеціалісти з DevOps та SRE впроваджують AIOps-рішення під ключ, щоб ви отримували лише ті алерти, які дійсно потребують реакції. Оцінимо ваш проект за 1 день.

AIOps для аналізу логів — це не про заміну людей. Це про фільтрацію шуму: з 10 000 подій на хвилину автоматика виділяє 3, на які варто дивитися прямо зараз. Ми гарантуємо зниження MTTR на 40% вже в перший місяць після впровадження.

Що реально робить ML в логах — і де йому не варто довіряти

Сучасні підходи до автоматичного аналізу логів поділяються на два класи: template-based (парсинг патернів, drain-алгоритм) та embedding-based (векторизація через LLM або BERT-подібні моделі). Обидва працюють, але в різних сценаріях.

Drain3 — це Python-бібліотека, що реалізує алгоритм дерева парсингу логів. Вона приймає сирий рядок логу та видає шаблон: Connection to <IP>:<PORT> failed after <NUM> retries. Це корисно для групування: тисяча рядків про різні IP перетворюються на один шаблон з лічильником. Аномалія — коли лічильник конкретного шаблону різко зростає або з'являється новий шаблон, якого раніше не було.

from drain3 import TemplateMiner
from drain3.template_miner_config import TemplateMinerConfig

config = TemplateMinerConfig()
config.load("drain3.ini")
template_miner = TemplateMiner(config=config)

with open("app.log") as f:
    for line in f:
        result = template_miner.add_log_message(line.strip())
        if result["change_type"] == "cluster_created":
            print(f"NEW PATTERN: {result['template_mined']}")

# drain3.ini [DRAIN] sim_th = 0.4 depth = 4 max_children = 100 max_clusters = 1024 

Новий патерн в логах production-сервісу — це сигнал. Не завжди інцидент, але завжди привід подивитися.

Embedding-підхід потрібен там, де текст логів семантично різноманітний і шаблони погано працюють. Наприклад, Python traceback або вільний текст помилки від стороннього API. Тут використовують sentence-transformers для векторизації та FAISS або pgvector для пошуку аномалій за косинусною відстанню від відомих «нормальних» логів.

Але embedding-моделі потребують GPU або значних CPU-ресурсів, і їх рідше деплоять у production-grade setup. Для більшості завдань Drain3 + статистичні методи достатньо.

Як Drain3 допомагає в аналізі логів?

Drain3 парсить логи, групує їх у кластери за шаблонами та відстежує появу нових. Якщо раніше кластер з помилкою з'єднання виникав раз на годину, а тепер десять разів на хвилину — це аномалія. Ми налаштовуємо автоматичний алерт на основі такої зміни. Для production використовуємо Drain3 у зв'язці з Prometheus та Alertmanager.

Чому варто довіряти embedding-підходам?

Embedding-підходи (BERT, OpenAI Ada) краще справляються з неструктурованим текстом, наприклад, з трейсбеками. Вони перетворюють рядки у вектори, і аномалія — це викид у векторному просторі. Однак вони потребують більше ресурсів та часу на fine-tuning. Для більшості логів з чітким патерном (Nginx, PostgreSQL) Drain3 ефективніший — він швидший і не потребує GPU. Порівняння в таблиці нижче.

Drain3 vs embedding: коли що вибирати

Стек для production-впровадження

Loki + LogQL + Grafana Alerting

Якщо вже використовується Loki, перший крок до «розумних» алертів — це метрики з логів через log_range_queries. Наприклад, рахуємо швидкість появи ERROR-логів:

sum(rate({app="payment-service"} |= "level=error" [5m])) by (app) 

Алерт на різке зростання — це вже перший рівень AIOps без ML. Аномалія через Z-score:

( sum(rate({app="payment-service"} |= "error" [5m])) - avg_over_time(sum(rate({app="payment-service"} |= "error" [5m]))[1h:5m]) ) / stddev_over_time(sum(rate({app="payment-service"} |= "error" [5m]))[1h:5m]) > 3 

Це рахує Z-score на льоту: якщо поточний rate помилок відхиляється від середнього за годину більше ніж на 3 стандартних відхилення — алерт.

OpenSearch + Anomaly Detection

OpenSearch (колишній Open Distro for Elasticsearch) має вбудований плагін Anomaly Detection на основі Random Cut Forest (RCF). Налаштування через API:

PUT _plugins/_anomaly_detection/detectors
{
  "name": "error_rate_detector",
  "description": "Detects anomalies in error log rate",
  "time_field": "@timestamp",
  "indices": ["app-logs-*"],
  "feature_attributes": [
    {
      "feature_name": "error_count",
      "feature_enabled": true,
      "aggregation_query": {
        "error_count": {
          "filter": {
            "term": {
              "level": "error"
            }
          }
        }
      }
    }
  ],
  "detection_interval": {
    "period": {
      "interval": 5,
      "unit": "Minutes"
    }
  },
  "window_delay": {
    "period": {
      "interval": 1,
      "unit": "Minutes"
    }
  }
}

RCF добре працює на часових рядах з вираженою сезонністю (ніч/день, будні/вихідні) — він автоматично адаптується до патерну, не вимагаючи ручного налаштування порогів.

Wazuh для security log analysis

Для security-подій (syslog, Windows Event Log, auditd) Wazuh використовує комбінацію сигнатурних правил та ML-моделі для поведінкового аналізу. Після встановлення агента він автоматично парсить /var/log/auth.log, /var/log/syslog та системні журнали Windows, корелює події та створює алерти з рівнем severity.

Інтеграція з Alertmanager та on-call

ML-детекція марна без правильного роутингу алертів. Типова помилка: всі аномалії падають в один Slack-канал, через тиждень команда їх ігнорує. Налаштовуємо Alertmanager з routing tree:

---
# alertmanager.yml
route:
  group_by: ['alertname', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-default'
  routes:
    - match:
        severity: critical
        category: security
      receiver: 'pagerduty-security'
    - match:
        severity: critical
      receiver: 'pagerduty-oncall'
    - match:
        anomaly_type: new_log_pattern
      receiver: 'slack-dev-alerts'
      continue: true
receivers:
  - name: 'pagerduty-oncall'
    pagerduty_configs:
      - routing_key: '${PAGERDUTY_KEY}'
        description: '{{ .CommonAnnotations.summary }}'

Нові патерни логів йдуть у dev-канал (можливо, просто нова фіча), критичні аномалії в метриках — у PagerDuty.

Процес впровадження та терміни

Починаємо з аудиту: скільки логів на добу, які системи їх генерують, чи є вже Elasticsearch/OpenSearch або Loki. Від цього залежить вибір інструменту — не варто тягнути Wazuh, якщо вже стоїть ELK.

Мінімальний життєздатний варіант — Z-score алертинг поверх існуючого Loki за 2-3 дні. Повноцінний детектор аномалій на OpenSearch з налаштованим RCF та інтеграцією в PagerDuty — 2 тижні. Впровадження embedding-моделі для семантичного аналізу трейсбеків з fine-tuning під конкретний стек — 4-6 тижнів, це вже проект з ML-інженером.

Важливий момент: перші 2-4 тижні після запуску детектора буде багато false positive — алерти на «нормальні» аномалії на кшталт деплоїв або планового maintenance. Потрібен час на налаштування suppress rules та навчання моделі на історичному трафіку. Це нормально, не вимикайте систему в перший тиждень.

Що входить в роботу

Замовте впровадження AIOps для логів під ключ: ми підберемо оптимальний стек, налаштуємо детекцію аномалій та інтеграцію з вашою системою оповіщення. Пишіть на пошту або в месенджери — оцінимо проект за 1 робочий день. Гарантія якості на всі роботи.