Міграція з legacy-моніторингу — це не про відтворення кожного алерту. Це про питання: які з них реально важливі?
Коли я отримав міграцію моніторингу для 500+ ВМ у гібридному середовищі, перше, що зробив — вивантажив інвентар існуючих алертів. 389 правил. Триста вісімдесят дев'ять. Для інфраструктури, що накопичувала алерти як барахольник копить газетні вирізки.
Половина — дублікати з трохи різними порогами. Чверть — для серверів, яких більше не існує. Деякі алертили на умови, неактуальні з минулого десятиліття.
Ніхто їх не ставив під сумнів. Бо так працює enterprise-моніторинг — додаєш алерти, ніколи не видаляєш, і рано чи пізно чергова команда вчиться ігнорувати шум. Що обнулює весь сенс.
Консолідація
Я не мігрував 389 правил. Я спроектував 31.
Не тому що лінивий (ну, частково). А тому що хороший моніторинг — це не про об'єм. Це про співвідношення сигнал/шум. Кожен алерт має будити людину по справі. Якщо ні — він не повинен існувати.
31 правило покриває все, що реально важливо:
- Інфраструктура (5 правил): Нода впала, критичний syslog, критичні event log — базис, який не обговорюється
- Контролери домену (4 правила): ADDS-сервіс, реплікація AD, синхронізація часу — коли падають DC, падає все
- Сервіси додатків (12 правил): Кожен бізнес-критичний сервіс отримує рівно один алерт. Не п'ять. Один.
- Безпека (2 правила): Блокування акаунтів і сплески невдалих входів — система раннього попередження
- Все інше (8 правил): Мережа, Exchange, спеціалізовані сервіси
92% скорочення. З 389 до 31. І знаєте, що сталося з реагуванням на інциденти? Воно стало швидшим. Бо коли кожен алерт важливий, люди реально реагують.
DCR Split, про який ніхто не питає
Ось тут стає цікаво. Azure Monitor використовує Data Collection Rules (DCR) для визначення, які логи збираються з яких машин. Очевидний підхід: один DCR для Windows, один для Linux — готово.
Очевидний підхід — ще й дорогий.
Я побудував 5 типів DCR:
- VM Insights — метрики продуктивності для всіх ВМ
- Windows Generic Logs — System, Application, Security події (тільки рівні 1-3)
- Windows Domain Controller Logs — AD, DNS, DFS-реплікація (тільки 6 DC)
- Linux Logs — Syslog з усіх Linux-серверів
- SQL Server Custom Logs — парсинг ERRORLOG у кастомні таблиці
Магія — в розділенні між #2 і #3.
До спліту: логи Active Directory, DNS Server і DFS Replication збиралися з кожного Windows-сервера. З усіх 200+. Але тільки 6 з них — контролери домену. Тобто 97% цього збору оплачувало логи, в яких ніколи не буде жодної релевантної події.
Після спліту: DC-специфічні логи приходять з 6 машин. Загальні Windows-логи — з 200+. Те саме покриття. Частка вартості.
Проблема Information-логів
Ось брудний секрет Windows Event Logs: Level 4 — це "Information." А Information-події — найшумніші, найоб'ємніші й найбезкорисніші дані у всьому стеку моніторингу.
Кожен запуск сервісу. Кожне завершення scheduled task. Кожен успішний логін. Все Level 4. Все збирається. Все білиться по гігабайтах.
Я прибрав Level 4 з generic Windows DCR. Тільки рівні 1-3 — Critical, Error, Warning. Те, що ти реально розслідуєш.
Зниження об'єму по 200+ серверах було колосальним. Жоден actionable алерт не загубився. Бо ніхто — буквально ніхто — ніколи не напише KQL-запит, що починається з "покажи мені всі рази, коли сервіс успішно стартував."
Архітектура Action Groups
31 правило алертів має досягати правильних людей. Не всіх. Правильних.
8 Action Groups, організованих за відповідальністю:
- Linux-команда отримує Linux-алерти
- Windows-команда отримує Windows-алерти
- InfoSec отримує алерти безпеки
- Власники додатків отримують алерти своїх додатків
- Загальний catchall для всього іншого
Звучить очевидно? Ви здивуєтесь, скільки enterprise-компаній маршрутизують все в одну розсилку і вважають це моніторингом. А потім дивуються, чому ніхто не реагує.
Валідація в бойових умовах
Теорія — це добре. Прод — це правда.
Однієї ночі DNS Server почав сипати помилками на двох контролерах домену. DC-специфічне правило впіймало це о 2:53 ночі. Правильна команда отримала сповіщення. Проблема авторезолвилась через 48 хвилин.
Жодного false positive. Жодної пропущеної події. Алерт спрацював, команда відреагувала, система відновилася. Ось так виглядає моніторинг, зроблений правильно.
Якби я мігрував усі 389 правил? Цей алерт потонув би в шумі. Ще одне сповіщення в морі сповіщень. Проігнороване, як і всі інші.
Висновок
Більше алертів не означає кращий моніторинг. Менше, але розумніших — означає.
Якщо у твоєму стеку моніторингу більше 50 правил, а в тебе немає 50 різних сценаріїв відмови — у тебе проблема забруднення алертами. Виріши її, поки команда не навчилась ігнорувати все.
389 правил. 31 вижив. Нуль false negatives. На 92% менше шуму.
Це не скорочення. Це редизайн.