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. Не знают про конкретные серверы или пороги. Для этого есть файлы параметров.

Каждое окружение получает свой файл параметров:

params/monitoring-infrastructure-dev.parameters.json
params/monitoring-infrastructure-prod.parameters.json
params/alert-rules-dev.parameters.json
params/alert-rules-prod.parameters.json

Те же модули. Другие параметры. 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 делается правильно.