Настройка Azure Monitor и Log Analytics: полное руководство

Azure Monitor: где ломается наблюдаемость на проде

Большинство внедрений Azure Monitor ломается не из-за отсутствия инструмента, а из-за того, как он собран. Агенты стоят на части машин, диагностические настройки включены выборочно по сервисам, часть метрик идёт платформенными счётчиками, часть — собственным сборщиком. На вопрос «что происходило в ночь на среду» единого ответа нет: данные разложены по нескольким рабочим областям Log Analytics с разной глубиной хранения и разными правами доступа.

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

Третье — алерты. Порог ставят по среднему за длинное окно, правило агрегации съедает короткий пик, уведомление уходит в канал, по которому никто не дежурит. Срабатывание приходит уже после того, как клиенты заметили сбой: наблюдаемость формально есть, а обнаружение инцидентов не работает.

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

Что меняется после настройки сквозного сбора метрик

Раньше картина складывалась из разрозненных сигналов: метрики машин в одном месте, логи приложения в другом, ошибки на входе — только в журнале балансировщика. Проблема проявлялась тогда, когда её замечал пользователь, а разбор начинался с вопроса «что вообще сломалось». Это самый дорогой сценарий: пока собираешь данные по частям, окно отказа растёт.

Единый контур наблюдения убирает эту развилку. Метрики, логи и трассировки попадают в общее хранилище и связываются по одним измерениям — идентификатору запроса, имени сервиса, версии сборки, экземпляру узла. Azure Monitor работает здесь точкой сборки: источники подключаются согласованно, а не набором отдельных агентов.

Время обнаружения меняется первым. Пороги ставятся не на загрузку процессора, а на признаки деградации сервиса — долю ошибок, время ответа на значимых маршрутах, длину очереди. Сигнал приходит раньше, чем отказ замечает пользователь, и класс «узнали от пользователя» перестаёт быть основным источником заявок.

Разбор инцидента ускоряется по той же причине. Сквозная трассировка показывает путь запроса через сервисы: вместо последовательного просмотра пяти панелей инженер видит участок, где выросли время или ошибки. Корневые причины подтверждаются данными — сравнение метрик до и после выката отделяет регресс релиза от сетевого сбоя или отказа зависимости.

Есть и накопительный эффект: единая ретенция метрик и логов оставляет разборы прошлых инцидентов воспроизводимыми. Повторяющиеся отказы закрываются правилами мониторинга, а не заново найденными причинами.

Режимы сбора данных и агенты: сравнение вариантов

Azure Monitor забирает телеметрию несколькими независимыми путями, и выбранный путь определяет не только набор полей, но и схему таблиц в рабочей области. Ошибиться здесь дорого: часть данных потом не дособрать задним числом, а смена способа сбора на работающем парке машин требует переразвёртывания на каждом узле.

Решение сводится к трём развилкам: нужен ли доступ изнутри гостевой системы, разрешён ли прямой исходящий трафик в облако и есть ли собственные источники событий. Ниже — варианты, между которыми реально выбирают.

Варианты не взаимоисключающие: на одном контуре обычно работают два-три сразу. Перед раскаткой мы проверяем на пилотном узле, какие поля приходят и с какой задержкой.

Этапы внедрения: от аудита источников до передачи

Работы идут строго по порядку: сначала описываем то, что уже есть, затем проектируем маршруты данных и только после этого включаем оповещения. Обратный порядок даёт шум в журналах, ложные срабатывания и панели, которыми никто не пользуется.

1. Аудит инфраструктуры и источников. Обходим подписки, виртуальные машины, кластеры, базы и прикладные сервисы; отмечаем, кто уже отдаёт метрики и журналы, кто молчит, где данные дублируются.
2. Схема потоков данных. Для каждого источника определяем рабочую область, срок хранения, разделение по средам и командам, оцениваем суточный объём поступления — реестр не должен расти бесконтрольно.
3. Настройка сбора. Подключаем агенты и диагностические настройки, задаём единые правила именования таблиц и тегов, чтобы запросы одинаково работали в тестовом и рабочем контурах.
4. Правила оповещений. Пороги считаем от фактической базовой линии, а не на глаз: настраиваем важность, маршрутизацию дежурным и подавление дублей на время плановых работ.
5. Проверка на учебном инциденте. В тестовом контуре намеренно роняем сервис и смотрим весь путь: сработало ли условие, за сколько минут пришёл сигнал, попал ли он к нужному дежурному.
6. Передача в эксплуатацию. Панели, сохранённые запросы, регламент ревизии порогов и инструкция по подключению новых источников; обучаем смену и остаёмся на связи в период сопровождения.

Комплект поставки: конфигурации, схемы, регламенты

Комплект поставки — это не папка с файлами, а набор артефактов, по которым контур Azure Monitor можно передать другой команде или воспроизвести в новом окружении. Каждый документ привязан к конкретному действию: развернуть, проверить, откатить, разобрать инцидент.

Ниже — что именно остаётся у вас на руках после ввода в эксплуатацию.

• Файлы конфигурации — декларативные описания рабочих пространств, правил сбора и сроков хранения телеметрии; повторное развёртывание в новом окружении идёт без ручной настройки.
• Схема потоков телеметрии — какие источники что отдают, по каким маршрутам идут данные, где фильтруются, где хранятся и сколько живёт каждый класс записей.
• Политики доступа — кому и на каком уровне видны журналы, кто вправе менять правила и удалять данные; закреплено ролями, а не устными договорённостями.
• Роли инженеров — матрица «роль / зона ответственности / необходимые права», по которой новый человек вводится в контур за день, а не за месяц.
• Описание правил оповещения — условия, пороги, адресаты и уровни важности; отдельно перечислено, какие уведомления намеренно не отправляются, чтобы дежурного не будил шум.
• Регламент дежурства — график, порядок эскалации, время реакции по уровням критичности и обязательные действия перед передачей смены.
• Документация — инструкции по типовым операциям: подключить новый сервис, изменить правило, разобрать инцидент, откатить конфигурацию к предыдущей.

Кейс: как сократили время обнаружения отказов

Клиент пришёл с разрозненным контуром наблюдения: показатели виртуальных машин — в одной панели, журналы приложений — в отдельном хранилище, события очередей и балансировщика — в почте дежурного. При отказе инженер вручную сверял три источника, и до понимания, что именно деградировало, проходило 40-60 минут.

Что изменили

Мы свели всё в единый контур на Azure Monitor и Log Analytics: одно рабочее пространство для журналов, сбор показателей с узлов, приложений и сетевых сервисов, правила оповещения, привязанные к симптомам, а не к отдельным счётчикам. Пороги выставили по отклонению от базовой линии — ночные оповещения перестали будить команду из-за штатных пиков нагрузки.

Добавили рабочие книги с готовыми срезами по типам отказов и маршрутизацию дежурств: сообщение приходит тому, кто владеет сервисом, вместе со ссылкой на нужный срез. Разбор инцидента вместо сборки данных с нуля превратился в проверку готовой хронологии — от первого отклонения до восстановления.

Результат: среднее время обнаружения сократилось с 45 минут до 5-7, ручной разбор занимает около 20 минут вместо двух часов, доля повторных сбоев упала примерно втрое — каждый разбор заканчивался правилом, которое ловит тот же класс отказа заранее.

Чем отличается Azure Monitor от Log Analytics?

Azure Monitor — платформа телеметрии: собирает данные со всех ресурсов подписки, хранит, обрабатывает и рассылает сигналы. Log Analytics — её часть: рабочая область, в которой лежат журналы событий и выполняются запросы по логам. Граница проходит не по инструментам, а по типу данных: числовые метрики и текст событий хранятся раздельно, с разным сроком жизни и разной скоростью отклика.

Метрики — числовые ряды с фиксированным шагом: загрузка узла, число соединений, глубина очереди. Их пишет сама платформа, отдаются они за секунды и служат основой для правил оповещения и графиков. Журналы событий — записи о том, что произошло, с произвольной схемой; их нужно явно направлять в рабочую область через категории диагностики.

Частая ошибка — выгружать метрики в рабочую область «на всякий случай» и параллельно писать в журналы то, что там уже есть. Объём приёма растёт вдвое, а оповещения по метрикам всё равно остаются быстрее и надёжнее. Правило простое: счётчики — в метрики, контекст и текст — в журналы.

Зоны ответственности на стыке делятся так: за метрику отвечает сам ресурс, за её сбор — настройки диагностики, за журналы — рабочая область с её сроком хранения, доступами и составом категорий. Когда это разделение зафиксировано в документации, дежурный знает, где смотреть цифру, а где — причину.

Технические сомнения и ограничения

Возражения к внедрению мониторинга в Azure обычно одни и те же: придётся ли пересобирать уже работающие хранилища логов, как удержать рост объёма и хватит ли прав у команды. Ниже — прямые ответы, с которых начинаем разбор задачи.

Как ограничить объём хранения логов?

Срок хранения задаётся по каждой таблице отдельно: диагностические журналы держим недолго, журналы безопасности — дольше. Правила выборки на стороне источника отсекают шум до записи, поэтому растёт не объём, а доля полезных событий.

Нужно ли менять код приложения?

Для базовых метрик — нет, они снимаются с платформы. Свои счётчики добавляются штатной библиотекой, без переписывания логики и остановки сервисов — выкатываем вместе с ближайшим релизом.

Как разграничить доступ по ролям?

Права выдаём на уровне подписки, группы ресурсов и конкретной рабочей области: разработчик видит журналы своего сервиса, дежурный — только оповещения, аудит не читает данные приложений. Учётные записи заводим через существующий каталог.

Обсудим задачу и вернёмся с планом

Разговор о мониторинге идёт предметно, когда перед ним видно текущее состояние инфраструктуры. Готовить отчёт не нужно — достаточно того, что уже есть под рукой: схемы, списки, история сбоев. Соберите это до обсуждения задачи, и мы вернёмся не с уточняющими вопросами, а с планом работ и оценкой сроков.

• Перечень сервисов: что работает, кто владелец каждого ресурса, какие компоненты уже отдают метрики в Azure Monitor, а какие остаются «чёрным ящиком».
• Критичные сценарии: какие цепочки (база, приложение, внешний интерфейс) ломаются первыми, что считается недопустимым простоем, а что может подождать до утра.
• Текущие способы оповещения: куда приходят уведомления, кто их читает, по каким порогам они срабатывают и как часто оказываются ложными.
• Карта зависимостей между сервисами и известные точки отказа — подойдёт даже список связей, нарисованный от руки.
• История прошлых сбоев: как заметили проблему, сколько заняло восстановление, чего не хватило для быстрой диагностики.
• Ограничения: требования к хранению данных, роли доступа, что нельзя менять без согласования и в какие окна допустимы работы.

С этим набором мы определим, какие метрики и журналы собирать, как развести пороги по критичности, куда маршрутизировать уведомления и сколько хранить историю. Опишите задачу — вернёмся с планом работ, оценкой сроков и понятной зоной ответственности на каждом этапе.