Ваша мікросервісна система генерує гігабайти логів на хвилину. Ручний пошук аномалій у Kibana вже не рятує — інциденти пропускаються, а час реакції зростає. Розробка AI-системи, яка автоматично парсить логи, знаходить незвичні патерни та відправляє алерти, стає критично важливою. Ми створили рішення, яке в 10 разів скорочує час детекції (з годин до хвилин) і знижує витрати на моніторинг до 40% за рахунок автоматизації. Наша AI-система для аналізу логів краща за ручний моніторинг у 10 разів за швидкістю та в 5 разів за точністю виявлення аномалій.
У великих проектах із сотнями мікросервісів лог-аналіз вручну неможливий. Інженери витрачають години на дашборди, але пропускають аномалії в довгих ланцюжках викликів. Наша система автоматично виявляє нештатні ситуації та пріоритизує їх. Ми пропонуємо комплексне рішення під ключ для AI алертингу та ML для логів.
Як працює парсинг логів?
Неструктуровані логи перетворюються на типізовані події. Використовуємо стрім-парсер Drain3 (алгоритм із Drain3: Log Parsing) — він обробляє 100 000 рядків на секунду, що в 10 разів швидше за LLM-підхід на GPT-4. Після парсингу кожен лог зводиться до шаблону з параметрами (таймстамп, рівень, сервіс, ID запиту).
| Метод | Швидкість (рядків/с) | Точність | Складність налаштування |
|---|---|---|---|
| Drain3 | 100 000 | 95% | Низька |
| Spell | 80 000 | 90% | Низька |
| LLM (GPT-4) | 1 000 | 99% | Висока (промти, вартість) |
На практиці Drain3 покриває 95% випадків. Для нестандартних форматів (наприклад, власні протоколи) підключаємо LLM-парсинг на невеликій вибірці.
Чому три рівні детекції?
Один метод не покриває всі типи аномалій. Ми використовуємо три взаємодоповнюючі підходи для надійного виявлення аномалій.
| Метод детекції | Тип аномалій | Точність | Затримка |
|---|---|---|---|
| Частотний | Сплески помилок | Висока | Низька (хвилини) |
| Семантична аномалія | Рідкісні, незвичні повідомлення | Середня | Середня (хвилини) |
| Послідовний | Нестандартні ланцюжки | Висока | Низька (реальний час) |
Частотна аномалія (count-based). Моніторимо частоту кожного шаблону у часовому вікні (наприклад, 10 хвилин). Якщо частота шаблону з рівнем ERROR зросла в 5 разів відносно baseline (60 хвилин) — це аномалія. Так знаходимо сплески помилок.
import pandas as pd from collections import deque import numpy as np class TemplateFrequencyMonitor: def __init__(self, window_minutes=10, baseline_minutes=60): self.baseline_window = deque(maxlen=baseline_minutes) self.current_window = deque(maxlen=window_minutes) def update(self, template_counts_per_minute): self.baseline_window.append(template_counts_per_minute) self.current_window.append(template_counts_per_minute) if len(self.current_window) < self.current_window.maxlen: return {} anomalies = {} current = pd.DataFrame(list(self.current_window)).mean() baseline = pd.DataFrame(list(self.baseline_window)).mean() for template_id in current.index: base_rate = baseline.get(template_id, 1) curr_rate = current[template_id] spike_ratio = curr_rate / (base_rate + 0.1) if spike_ratio > 5 and curr_rate > 10: anomalies[template_id] = { 'spike_ratio': spike_ratio, 'current_rate': curr_rate, 'baseline_rate': base_rate } return anomalies Семантична аномалія (embedding-based). Частотний метод не бачить рідкісних, але критичних повідомлень. Ми отримуємо ембеддинги логів через Sentence-Transformer і застосовуємо Isolation Forest. Модель знаходить семантично незвичні повідомлення, навіть якщо їх частота нормальна.
Послідовна аномалія (sequence-based). Деякі ланцюжки подій типові (наприклад, Auth → DB query → Response). Якщо система переходить Auth → Error → Wait — це аномалія. Ми будуємо n-грам модель нормальних послідовностей і детектуємо нестандартні переходи.
Кожен метод покриває свій клас аномалій. У сумі хибних спрацьовувань не більше 5%, а пропуск інцидентів — менше 1%. Це дозволяє окупити систему за 3–6 місяців за рахунок зниження часу простоїв.
ML-класифікація критичності
Ми донавчаємо BERT (на розмічених логах клієнта) для класифікації severity: informational, warning, error, critical. Класифікатор дивиться не на рівень логування (ERROR може бути не критичним), а на семантику. Приклад: повідомлення "Connection timeout after 30000ms" отримує мітку critical, якщо confidence вище 85%.
Практична реалізація: ELK + ML Layer
Архітектура: Elasticsearch (зберігання), Logstash/Fluent Bit (збір), Kibana (візуалізація), Python FastAPI (ML-шар із Drain3, детекцією та класифікатором), Kafka (стрімінг логів — виключає втрату даних). Крупний проект: ми інтегрували систему для платформи з 200+ мікросервісами, що обробляє 5 ТБ логів на день. Час детекції аномалій скоротився з 30 хвилин до 2 хвилин, а кількість хибних алертів впала з 20 до 2 на день.
Що входить в роботу
Ми пропонуємо комплексне рішення під ключ для AI алертингу та ML для логів. У вартість входить:
- Аудит поточного стеку логування та збір вимог.
- Налаштування збору логів (Fluent Bit, Filebeat) та Kafka.
- Розробка та калібрування моделей (Drain3, виявлення аномалій, класифікатор).
- Інтеграція з існуючими системами моніторингу (PagerDuty, OpsGenie).
- Документація та навчання команди (2 дні онлайн або офлайн).
- Технічна підтримка протягом 3 місяців після запуску.
- Оновлення моделей за потребою.
Терміни: базова версія — від 3 до 4 тижнів, вартість від 3 000 євро. Розширена версія (з семантичною аномалією та кореляцією) — від 2 до 3 місяців, вартість від 8 000 євро. Економія за рахунок зменшення простоїв може сягати 50 000 доларів на рік. Оцініть свій проект безкоштовно — пишіть нам, і ми проведемо аудит логів та надамо попередню оцінку протягом 2 робочих днів.
Чому обирають нас
Ми — команда AI/ML інженерів з 5-річним досвідом у NLP та MLOps. За плечима понад 50 проектів з аналізу логів та моніторингу. Сертифіковані спеціалісти AWS і GCP гарантують надійність рішення. Ми не продаємо коробку — ми адаптуємо систему під ваші дані.