Миграция с 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:

  1. VM Insights — метрики производительности для всех ВМ
  2. Windows Generic Logs — System, Application, Security события (только уровни 1-3)
  3. Windows Domain Controller Logs — AD, DNS, DFS-репликация (только 6 DC)
  4. Linux Logs — Syslog со всех Linux-серверов
  5. 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% меньше шума.

Это не сокращение. Это редизайн.