Click-ops моніторинг вмирає в момент, коли хтось питає "а можна відтворити в іншому середовищі?" Bicep — відповідь.

Я отримував у спадок моніторинг, зібраний руками. Знаєте такий — хтось прокликав Azure Portal, створив правила алертів по одному, налаштував action groups по пам'яті і задокументував процес як "я знаю, як це працює."

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

Ось чому я написав всю інфраструктуру моніторингу як Bicep-модулі. Кожен DCR. Кожне правило алертів. Кожну action group. Кожну кастомну таблицю. Кожен workspace. Все — код.

Чому Bicep, а не Terraform

Я люблю Terraform. Використовую щодня. Але для Azure-нативних ресурсів моніторингу в Bicep нечесна перевага: він говорить мовою Azure нативно.

Azure-провайдер Terraform — це шар трансляції. Бере твій HCL, конвертує в ARM API виклики і сподівається, що маппінг правильний. Зазвичай — так. Але з ресурсами моніторингу — Data Collection Rules, scheduled query rules, diagnostic settings — є edge cases, де абстракція Terraform протікає.

Bicep компілюється напряму в ARM-шаблони. Без шару трансляції. Без edge cases. Що пишеш — те Azure отримує. А коли Microsoft випускає нову фічу моніторингу, Bicep підтримує її з першого дня. Terraform може чекати місяці.

Для цього проєкту — 31 правило алертів, 5 типів DCR, 8 action groups, кастомні таблиці — Bicep був правильним інструментом.

7 модулів

Я побудував 7 компонованих Bicep-модулів, що разом розгортають повний стек моніторингу:

1. Resource Group — просто, але важливо. Environment-aware найменування. Теги. Локація. Фундамент.

2. Log Analytics Workspace — куди потрапляють усі дані. Політики зберігання. Контроль доступу. Єдине скло, від якого залежить кожен інший модуль.

3. DCR - VM Insights — метрики продуктивності та маппінг залежностей для всіх ВМ. CPU, пам'ять, диск, мережа — базис, що не обговорюється.

4. DCR - Logs — стратегія спліту. Окремі DCR для Windows generic, Windows DC-специфічних, Linux, SQL та application-специфічних логів. Кожен скоупиться рівно на ті сервери, яким потрібен.

5. Custom Log Tables — для SQL Server error logs, application logs і всього, що не влазить у стандартну схему. Визначені як код, версіоновані, відтворювані.

6. Alert Rules — 31 scheduled query rule з KQL-запитами, рівнями severity, частотами оцінки та авто-мітигацією. Кожен алерт параметризований: префікс середовища, пороги, призначення action groups.

7. Action Groups — 8 командних каналів сповіщень. Email-маршрутизація, шляхи ескалації — все визначено як структуровані дані у файлах параметрів.

Двостадійний деплоймент

Ось що більшість Bicep-туторіалів пропускає: порядок залежностей важливий.

Не можна створити правила алертів, що запитують Log Analytics Workspace, який ще не існує. Не можна призначити DCR на ВМ, якщо деплой DCR не завершився. Не можна створити кастомні таблиці до готовності workspace.

Тому деплоймент — двостадійний:

Стадія 1: Інфраструктура. Resource group, workspace, DCR, кастомні таблиці. Фундамент. Запускається першою, має завершитися до всього іншого.

Стадія 2: Алертинг. Правила алертів і action groups. Посилаються на workspace і таблиці зі стадії 1. Деплояться тільки після підтвердження інфраструктури.

Чи міг я використати dependsOn в одному деплойменті? Звісно. Але дві явні стадії дають чітку контрольну точку. Стадія 1 впала? Знаєш — інфраструктура. Стадія 2 впала? Знаєш — логіка алертингу. Без гадання.

Файли параметрів — справжня конфігурація

Bicep-модулі — generic. Вони не знають про DEV чи PROD. Не знають про конкретні сервери чи пороги. Для цього є файли параметрів.

Кожне середовище отримує свій файл параметрів. Ті самі модулі. Інші параметри. DEV отримує розслаблені пороги і тестові email. PROD отримує жорсткі пороги і реальні списки розсилки команд.

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

KQL всередині

Кожне правило алертів містить KQL-запит. А KQL-запити, вкладені в Bicep-параметри — не красиві. Рядки. Довгі, екрановані, іноді багаторядкові рядки, від яких файли параметрів важко читати.

Але вони версіоновані. Рев'юяться. Деплояться консистентно. І коли хтось питає "що реально перевіряє алерт X?" — ти читаєш файл параметрів. Не Azure Portal. Не чийсь Slack-месидж тримісячної давності. Код.

Тест на відтворюваність

Головний тест IaC: чи можна все знести і відновити з нуля?

Так. Стадія 1, стадія 2, готово. Той самий стек моніторингу. Ті самі правила алертів. Ті самі action groups. Ті самі кастомні таблиці. Ідентично тому, що було до цього, бо це той самий код.

Спробуйте це з click-ops моніторингом. Удачі.

Що б я зробив інакше

Якщо починати заново:

  1. Використати модулі з Azure Verified Modules registry для стандартних ресурсів.

  2. Шаблонізувати KQL-запити замість вбудовування рядками. Окрема бібліотека запитів з юніт-тестами ловила б синтаксичні помилки до деплою.

  3. Додати валідацію деплою третьою стадією. Не просто "задеплоїлось?" а "чи реально алерт X спрацьовує за умови Y?"

Але ядро підходу — модульний Bicep, параметризовані середовища, двостадійний деплоймент — це працює. В продакшені місяці. Нуль дрифту. Нуль "хтось поміняв у порталі."

7 модулів. Повний стек моніторингу. Одна команда az deployment.

Ось так Infrastructure as Code робиться правильно.