AIOps: реалізація аналізу логів та інцидентів

AIOps розробка: чому збій помічають за фактом аварії

Логи є в усіх. Збір зазвичай налаштований: застосунок пише у файл, платформа складає записи у сховище, оповіщення за окремими метриками приходять у чат.

Проблема в іншому — події з різних сервісів не пов'язані між собою, і в момент сплеску помилок ніхто не бачить, що це один інцидент, а не п'ять незалежних.

Розрізнений моніторинг влаштований так: у кожного сервісу свій поріг, своя команда, свій канал сповіщень. Помилка в черзі та зростання часу відповіді на вході виглядають як два різних сигнали, хоча друге — майже завжди наслідок першого. Поки їх зіставляють вручну, минає час, а підтвердження приходить уже після аварії.

Кореляція подій — це не «зібрати більше логів», а модель зв'язків: який сервіс кого викликає, яка метрика від якої залежить, який код помилки повторюється з якою періодичністю.

Без цієї моделі інциденти в логах залишаються рядками, які ніхто не читає — за поточного обсягу вручну це фізично неможливо розібрати.

Звідси типовий сценарій: сплеск підтверджують постфактум, розбір займає години, наступний схожий випадок ловлять за фактом падіння. AIOps розробка починається зі зворотного — з опису нормальної поведінки сервісів і правил, за якими відхилення стає сигналом, а не записом в архіві. Далі розбираємо, як це закривається на практиці.

Що змінюється після впровадження розбору логів

До впровадження автоматичного розбору логів черговий дізнавався про аварію або від користувачів, або з графіка, який доводилося вручну зіставляти з логами застосунку, балансувальника та бази.

Час виявлення інциденту вимірювався десятками хвилин, а частка хибних спрацьовувань сягала двох третин — на кожну реальну подію припадало кілька порожніх підйомів зміни. Простій сервісу при цьому фіксували за фактом, а не запобігали.

Після впровадження розбір логів іде потоком: події нормалізуються, зв'язуються за сервісом, вузлом і конкретним запитом, а аномалія перетворюється на один інцидент із уже зібраним контекстом.

Час виявлення скорочується до одиниць хвилин — сплеск помилок видно раніше, ніж його помічають користувачі.

Спостережуваність сервісів перестає бути набором розрізнених панелей у Grafana: метрики, логи й трасування сходяться в одну картину, придатну для рішення, а не для пересилання між командами.

Частка хибних спрацьовувань падає в рази: правила спираються на накопичену історію, а не на пороги, виставлені на око, тому шумові сплески йдуть у придушення і не піднімають зміну.

Заодно закривається цілий клас відмов — деградація зовнішньої залежності, вичерпання пулу з'єднань, тихе накопичення помилок тайм-аутів, — який раніше діагностували вже після падіння.

Навантаження на чергову зміну змінюється якісно: замість ручного зіставлення вивантажень інженер отримує інцидент зі зрізом логів, хронологією та заторкнутими сервісами.

Нічні розбори перестають розтягуватися на години, а після інциденту залишається правило, яке наступного разу спрацює саме.

Режими розбору логів: потоковий, пакетний, гібридний

Режим обробки логів обирають за обсягом потоку подій і допустимою затримкою сигналу. Потоковий аналіз читає події в міру надходження і тримає вікно агрегації в пам'яті, пакетна обробка розбирає накопичений масив цілком, гібридна схема розділяє гарячий і холодний контур.

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

Порівняння режимів обробки логів

Вибір упирається в інфраструктуру. Потоковий контур потребує запасу за одночасними з'єднаннями і передбачуваного відгуку сховища, інакше черга зростає і сигнал запізнюється тоді, коли потрібен. Пакетний упирається в обсяг накопичувача: без політики очищення архів важчий за саму систему.

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

Етапи впровадження: аудит, схема, розробка, перевірка

Починаємо не з моделі, а з даних: поки невідомо, що і як пишуть джерела, будь-яка автоматика дає шум замість сигналу. Етапи йдуть строго за порядком — кожен спирається на артефакти попереднього.

1. Аудит логів. Збираємо перелік джерел, форматів і обсягів запису, відзначаємо дублі, розриви в часі та різні часові пояси. На виході — карта джерел із чергою підключення.
2. Нормалізація подій. Приводимо записи до єдиної схеми — час, вузол, сервіс, критичність, текст — і зшиваємо пов'язані повідомлення з різних систем в один інцидент. Розрізнений потік стискається в рази, а втрати під час розбору зникають.
3. Налаштування правил. Описуємо кореляцію, дедуплікацію, вікна тиші та маршрутизацію за відповідальними. Пороги беремо зі статистики відхилень, а не «на око»: інакше чергова зміна тоне в хибних спрацьовуваннях і перестає реагувати.
4. Перевірка на історії. Прогоняємо правила по накопичених інцидентах і звіряємо з ручними розборами: що підтвердилося, що виявилося шумом, що пропустили. Це знімає основну частину хибних спрацьовувань до запуску.
5. Пробний запуск на вузькому контурі. Один-два сервіси в робочому режимі: дивимося затримку сигналу, повноту групування, читабельність оповіщення. Охоплення розширюємо тільки після стабільного результату.
6. Передача рішення. Віддаємо конфігурації, схеми потоків, документацію правил і регламент їх правки, навчаємо вашу команду. Додавання джерел і розбір нових правил ваші інженери далі ведуть самі.

Що передаємо на руки: конфігурації, правила, регламенти

Передача — це не архів із налаштуваннями, а робоча система, яку ваша команда зможе розвивати без нас. Тому кожен артефакт оформлено так, щоб його можна було прочитати, перевірити й змінити, а не тільки запустити.

• Конфігурації збору і розбору — звідки забираються логи, які формати розбираються, які поля витягуються, а які відкидаються як шум.
• Схеми потоків даних — шлях події від джерела до сховища, точки буферизації та поведінка системи за недоступності джерела.
• Правила кореляції — як розрізнені події складаються в один інцидент: вікна групування, пороги, придушення повторів, пріоритети.
• Політики доступу — розмежування ролей, маскування чутливих полів, терміни зберігання, журнал звернень до даних.
• Регламенти реагування — що закривається автоматично, що йде черговому, кому і коли ескалюється, де фіксується розбір.
• Інструкції з експлуатації — додавання нового джерела, правка порогів, розбір хибних спрацьовувань, типові причини їх появи.
• Перевірки та план відкату — прогін правил на історичних інцидентах, тести на пропуск події, повернення до ручного розбору без втрати накопичених даних.

Окремо віддаємо журнал рішень: чому поріг виставлено саме так і які компроміси за цим стоять. Через півроку це економить більше часу, ніж будь-яка документація зі встановлення.

Кейс: час виявлення інцидентів до і після впровадження

Потік логів із кількох десятків сервісів у Kubernetes збирався в загальне сховище без єдиної схеми, а оповіщення налаштовувалися вручну за кожним сервісом.

Черговий отримував близько двохсот повідомлень на добу, з яких підтверджувалися одиниці: решта — повтори й дублі із сусідніх вузлів.

Інцидент частіше знаходили за скаргою користувача, а не за сигналом системи: медіана виявлення трималася близько двадцяти п'яти хвилин, і весь цей час відмова йшла ланцюгом залежностей.

Що змінили

Зібрали єдиний конвеєр: логи приводилися до структурованого вигляду з обов'язковими полями — сервіс, середовище, версія релізу, ідентифікатор запиту.

Поверх поставили кореляцію в ковзному вікні: однотипні помилки згортаються в один інцидент, а сплеск на сервісі пов'язується зі змінами в залежностях. Пороги рахуються від нормального фону конкретного сервісу, тому нічні поодинокі помилки більше не піднімають чергового.

Вузьким місцем виявилася не модель, а розмітка: частина сервісів писала неструктурований текст, і до нормалізації цих потоків аналітика давала хибні спрацьовування.

Після нормалізації частка шуму оповіщень упала з 80% до 12%, медіана виявлення скоротилася до трьох-чотирьох хвилин, час локалізації вузла відмови — удвічі.

Клас відмов «деградація зовнішньої залежності» став фіксуватися до впливу на користувачів: зростання частки повільних відповідей ловиться як аномалія, а не як факт падіння.

Чергування за оповіщеннями перетворилося на чергування за інцидентами, а історія відмов стала основою правил, що відсікають нові класи збоїв.

Чим AIOps відрізняється від класичного моніторингу логів

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

AIOps не скасовує правило, а добудовує до події контекст: пов'язані сервіси, свіжі зміни конфігурації, поведінку того самого вузла в минулих збоях. Подія перестає бути окремим сигналом і стає ланкою ланцюга — з ознаками, за якими її можна групувати й порівнювати.

Різниця видна на розборі. Пороговий підхід віддає черговому розсип повідомлень про один збій; контекстний аналіз зводить їх в один інцидент, показує ймовірну причину й схожий минулий випадок.

Це працює, коли телеметрія приходить з однаковими атрибутами — сервіс, власник, реліз; єдина схема збору на кшталт OpenTelemetry прибирає ручну нормалізацію.

Межа між підходами проходить не за обсягом логів, а за наявністю моделі нормальної поведінки і зв'язків між сервісами. Поки історії немає, працюють пороги; коли метадані заповнені й накопичені інциденти, вмикається робота з контекстом — це і є предмет AIOps.

Технічні сумніви перед стартом проєкту

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

Майже жодне з них не вимагає, щоб інфраструктура була приведена до ладу заздалегідь: збір логів, доступи й розмітка інцидентів — це частина робіт, а не вхідна умова.

Скільки даних доведеться зберігати?

Стільки, за скільки інциденти встигають повторитися. Гарячі логи тримаємо в пошуковому сховищі, архів — у стисненому вигляді; правило зберігання задаємо за обсягом і цінністю записів, тому реєстр не зростає лінійно.

Які доступи потрібні до наших систем?

Тільки читання логів і метаданих інцидентів, окремий сервісний обліковий запис з обмеженим терміном ключів, маскування персональних даних на вході. Прав на зміну продуктивного середовища не потрібно.

Як це вбудується в наші системи?

На вході — збирач логів і система обліку інцидентів, на виході — події в систему чергувань і заявки в трекер. Усе через відкриті інтерфейси, звичні команді інструменти залишаються на місці.

Скільки займає впровадження?

Перший робочий контур на одному-двох сервісах — тижні, решту ландшафту підключаємо ітераціями. Термін тримають не моделі, а узгодження доступів і розмітка історичних інцидентів.

Обговоримо вашу задачу: що потрібно для оцінки

Розбір задачі починаємо з вихідних даних: чим точніше опишете поточний контур і характер збоїв, тим менше припущень закладаємо в оцінку проєкту. Повні вивантаження надсилати не потрібно — достатньо зразків записів і відповідей на кілька питань.

• Джерела логів: застосунки, балансувальники, оркестратор, СУБД, системи моніторингу — що вже пишеться і куди потрапляє.
• Формати й обсяги: структуровані записи чи текстові файли, добовий обсяг, термін зберігання, чи налаштована ротація.
• Опис інфраструктури: продуктивний і тестовий контури, де розміщуються компоненти, чи є обмеження щодо зовнішніх сервісів.
• Історія інцидентів: за який період є дані, як часто повторюються збої, скільки часу йде на локалізацію.
• Поточний процес: хто чергує, за якими правилами спрацьовують оповіщення і куди приходять повідомлення.
• Інтеграції: система обліку заявок, канали чергової зміни, засоби автоматичного відновлення.
• Доступи й вимоги: у якому контурі допустима робота, чи потрібен закритий периметр, як розмежовуються права.

Цього набору достатньо, щоб повернутися з оцінкою та планом робіт: розбивкою за етапами, складом команди й точками перевірки результату. Якщо частина даних закрита, запропонуємо варіант із поетапним уточненням — опишіть задачу, і ми повернемося з розрахунком.