Microsoft AZ-204: Мониторинг, диагностика и интеграция с DevOps в Azure — Руководство по подготовке

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Часть Microsoft Azure Developer Associate AZ-204 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Azure Monitor и Application Insights предоставляют единый, ориентированный на разработчиков стек наблюдаемости (observability) для приложений Azure. Application Insights собирает телеметрию приложений, такую как запросы, зависимости, исключения и трассировки, в то время как Azure Monitor агрегирует метрики и журналы со всех ресурсов в рабочую область Log Analytics и управляет оповещениями и интеграциями с DevOps. Глубокое понимание вариантов инструментирования, семантики телеметрии, тестов доступности, Kusto Query Language (KQL), оповещений с использованием групп действий, распределённой трассировки и «инфраструктуры как кода» (Infrastructure as Code) с помощью шаблонов ARM обеспечивает создание надёжных, диагностируемых и автоматизируемых решений.

Инструментирование и телеметрия Application Insights

Ресурсы Application Insights идентифицируются для приёма данных либо с помощью ключа инструментирования (instrumentation key), либо строки подключения (connection string). Ключ инструментирования — это устаревший единый GUID, используемый SDK для маршрутизации телеметрии. Строка подключения — это текущая рекомендация; она включает ключ инструментирования, а также метаданные конечных точек (точек приёма данных и Live Metrics) и позволяет направлять данные в нестандартные конечные точки (например, для суверенных или частных облаков). Используйте строку подключения в новом коде и конфигурациях; это позволит в будущем изменять конечные точки без повторного развёртывания кода. В App Service включение Application Insights на уровне платформы добавит строку подключения в переменные окружения для автоматически определяемых сред выполнения.

Инструментирование можно выполнить с помощью SDK или автоматически (auto-instrumentation). Подход с использованием SDK (например, Microsoft.ApplicationInsights.AspNetCore для .NET, applicationinsights для Node.js и агент Application Insights для Java) предлагает контроль на уровне кода: пользовательские события, метрики и обогащённую телеметрию через TelemetryInitializers и обработчики, включая адаптивную выборку (adaptive sampling). Автоматическое инструментирование (codeless attach) доступно для App Service и некоторых других вычислительных стеков; оно использует расширения сайта/агенты для сбора данных о входящих запросах, зависимостях и исключениях без изменения кода. Используйте инструментирование через SDK, когда вам нужны пользовательские события, бизнес-метрики или явная корреляция в фоновых задачах; используйте codeless attach для быстрого получения данных с минимальными усилиями или для «lift-and-shift» нагрузок. В обоих случаях задавайте имя облачной роли (cloud role name), чтобы различать службы в микросервисной архитектуре, и тщательно настраивайте выборку (sampling) для баланса между точностью данных и затратами.

Application Insights генерирует несколько основных типов телеметрии:

Requests (запросы) фиксируют входящие операции (HTTP-запросы, вызовы функций) с указанием длительности, кода ответа и статуса успешности.
Dependencies (зависимости) фиксируют исходящие вызовы (HTTP, SQL, вызовы Azure SDK, очереди) с указанием цели, типа, длительности и статуса успешности.
Exceptions (исключения) фиксируют возникшие ошибки, трассировки стека и обработанные исключения, если их отслеживание настроено явно.
Traces (трассировки) фиксируют сообщения журналов; SDK интегрируются с популярными фреймворками логирования, чтобы журналы и телеметрия имели общую корреляцию.
Events (события) фиксируют пользовательские события бизнес-уровня через TrackEvent, поддерживая кастомные измерения (custom dimensions) и счётчики.
Metrics (метрики) фиксируют числовые измерения; вы можете отслеживать пользовательские метрики для KPI и анализировать их в Metrics Explorer.

Распределённая трассировка в Application Insights основана на корреляции. Каждая сквозная операция имеет идентификатор операции (operation ID, в терминах W3C — trace ID), который является общим для всей связанной телеметрии; каждый «span» имеет родительско-дочерние отношения, обеспечиваемые через передаваемые заголовки (propagation headers). Современные SDK используют W3C Trace Context (заголовки traceparent, tracestate). Поле Operation_Id в KQL связывает Requests, Dependencies, Exceptions и Traces для одной и той же транзакции. Убедитесь, что исходящие HTTP-клиенты передают эти заголовки; для .NET System.Diagnostics.Activity и SDK Application Insights делают это автоматически. Отслеживание зависимостей инструментирует распространённые клиенты (HTTP, SQL, Service Bus, Storage). Когда службы пересекают границы (например, из App Service в AKS), последовательная передача заголовков позволяет построить единую связанную карту транзакций. Для асинхронных и основанных на сообщениях потоков убедитесь, что SDK фиксируют и передают идентификаторы корреляции в метаданных сообщений; большинство Azure SDK делают это по умолчанию.

Тестирование доступности и синтетический мониторинг

Тесты доступности проверяют внешнюю достижимость и скорость отклика из нескольких географических регионов. Тест «URL ping» отправляет HTTP-запросы с заданной частотой из нескольких точек тестирования и проверяет коды состояния, исправность SSL-сертификата и, опционально, совпадение содержимого ответа. Используйте повторные попытки и несколько местоположений, чтобы уменьшить количество ложных срабатываний, и настройте оповещения на сбои тестов для получения действенных уведомлений.

Многошаговые тесты доступности исторически выполняли записанные последовательности HTTP-запросов с сохранением состояния (stateful cookies) для проверки рабочих процессов. Классические многошаговые веб-тесты были упразднены; для сценариев с несколькими запросами или с аутентификацией реализуйте синтетические тесты, инструментируя собственный клиент или сервис с помощью API TrackAvailability (или экспортёров OpenTelemetry) для отправки AvailabilityTelemetry. Этот подход позволяет реализовать кастомную аутентификацию, передачу данных (payloads) и специфичную для домена проверку, сохраняя при этом централизованную отчётность и систему оповещений.

Пользовательская реализация TrackAvailability даёт вам контроль над:

Именем теста, местоположением запуска и идентификаторами последовательности для анализа тенденций и дедупликации.
Длительностью и семантикой успеха, основанной на ваших собственных проверках, а не только на статусе HTTP.
Информативными сообщениями и пользовательскими измерениями (custom dimensions) для подсказок по первопричине и корреляции с телеметрией бэкенда.

Сочетайте тесты доступности с телеметрией зависимостей и запросов бэкенда, чтобы быстро отличать проблемы доступности конечной точки (сеть, DNS, TLS) от сбоев приложения (исключения, тайм-ауты) и отказов нижестоящих сервисов (SQL, внешние API). Свяжите сбои тестов доступности с группами действий (action groups) для запуска рабочих процессов по управлению инцидентами.

Данные Azure Monitor, KQL и оповещения с помощью групп действий

Azure Monitor принимает два основных типа данных: метрики и журналы. Метрики — это легковесные числовые временные ряды с приемом данных почти в реальном времени и многомерной детализацией (например, по экземпляру, маршруту API). Они лучше всего подходят для быстрого обнаружения проблем (CPU, память, частота запросов, задержка, доступность) и по умолчанию поддерживают хранение до 93 дней. Журналы — это структурированные, доступные для запросов записи, хранящиеся в рабочей области Log Analytics, и включают данные Application Insights, журналы ресурсов платформы и пользовательские журналы с настраиваемым сроком хранения. Используйте параметры диагностики (Diagnostic settings), чтобы направлять метрики платформы и журналы ресурсов в рабочую область, Event Hub или Storage для архивации и аналитики.

Kusto Query Language (KQL) используется для исследовательского анализа, панелей мониторинга и оповещений по журналам. Основные шаблоны включают:

Простые запросы: Table | take 10 для быстрой выборки; для производительности всегда ограничивайте время в начале запроса с помощью where TimeGenerated >= ago(…).
Фильтрация и проекция: Table | where Column == "Value" | project KeyColumns для уменьшения объема данных и фокусировки анализа.
Агрегация: summarize count() by bin(TimeGenerated, 5m), Dimension для вычисления частоты, перцентилей или средних значений; используйте percentile() и make-series для временных диаграмм.
Объединения (Joins): join kind=inner или leftouter on по ключам корреляции, таким как operation_Id, для связи Requests с Dependencies или Exceptions; для межресурсных объединений убедитесь, что оба источника отправляют данные в одну и ту же рабочую область, или включите межресурсные запросы.
Полезные таблицы: requests, dependencies, exceptions, traces, availabilityResults для Application Insights; AzureDiagnostics и AzureActivity для журналов платформы; Perf и Heartbeat для VM insights.
Лучшие практики: проецируйте только необходимые столбцы, фильтруйте данные на раннем этапе, группируйте по разумным интервалам (bin) и избегайте дорогостоящих перекрестных объединений (cross-joins) на больших временных окнах, если в этом нет необходимости.

Оповещения охватывают метрики и журналы. Оповещения по метрикам (Metric alerts) оценивают пороговые значения метрик почти в реальном времени, поддерживают измерения и разделение по измерениям (splitting by dimension), а также могут использовать статические или динамические пороги (на основе ML-базовых линий). Они отслеживают состояние (stateful) и могут срабатывать и автоматически разрешаться в зависимости от результатов оценки, создавая одно уведомление при изменении состояния. Оповещения по журналам (Log alerts или scheduled query alerts) выполняют KQL-запросы по расписанию и срабатывают на основе результатов запроса (количество совпадений или пороговые значения). Используйте оповещения по журналам, когда условия зависят от сложных шаблонов в нескольких таблицах или требуют анализа текста. Интеллектуальное обнаружение (Smart detection) и оповещения об аномалиях в Application Insights могут выявлять регрессии без явных пороговых значений.

Группы действий (Action groups) определяют многократно используемые наборы ответов на оповещения. Типы уведомлений включают email, SMS, голосовые вызовы и push-уведомления в мобильном приложении Azure. Интеграции включают:

Веб-хуки (Webhooks, v1 и v2) с общей схемой оповещений (Common Alert Schema) для согласованной структуры данных; устанавливайте пользовательские заголовки для аутентификации и направляйте в системы управления инцидентами (например, PagerDuty или пользовательские приемники).
Azure Functions, Logic Apps и сценарии Automation (runbooks) для программного исправления и обогащения данных; используйте Logic Apps для гибких преобразований и работы с коннекторами.
Коннекторы ITSM (например, ServiceNow) для создания инцидентов с сопоставлением полей. Используйте группы действий в паре с правилами обработки оповещений (alert processing rules) для подавления во время технического обслуживания, маршрутизации по степени серьезности или применения динамических действий. Для безопасности исходящих веб-хуков ограничьте IP-адреса приемника диапазоном Azure, требуйте подписи/заголовки и проверяйте свойства Common Alert Schema, такие как Essentials.AlertRule и AlertContext.

Шаблоны ARM для обеспечения наблюдаемости и повторяемых развертываний

Шаблоны Azure Resource Manager (ARM) декларативно определяют ресурсы и конфигурацию мониторинга в виде кода. Структура шаблона включает:

$schema и contentVersion для идентификации версии шаблона.
parameters для внешних значений (например, имена рабочих областей, расположения, SKU). Используйте secureString/secureObject для секретов.
variables для вычисляемых значений, чтобы избежать повторений.
resources для декларативного развертывания Application Insights, рабочих областей Log Analytics, правил оповещений, групп действий и параметров диагностики.
outputs для вывода значений, таких как connectionString Application Insights, для последующих этапов развертывания.

Используйте связанные или вложенные шаблоны для создания сложных развертываний. Ресурс развертывания (Microsoft.Resources/deployments) ссылается на дочерний шаблон через templateLink (внешний URI) или встраивает его напрямую. Передавайте объекты параметров через parameters или parametersLink, определяйте порядок с помощью dependsOn и повторно используйте модули в разных средах. Примеры обеспечения наблюдаемости по умолчанию с помощью ARM:

Развертывание рабочей области Log Analytics и установка выходных данных workspaceResourceId, используемых ресурсами Application Insights (режим на основе рабочей области).
Создание Application Insights (на основе рабочей области) и вывод его connectionString; избегайте использования устаревших ключей инструментирования.
Включение параметров диагностики для ресурсов (например, App Service, Key Vault, Storage) для потоковой передачи журналов и метрик в рабочую область и/или Event Hub.
Создание оповещений по метрикам (microsoft.insights/metricAlerts) с критериями и измерениями, а также оповещений по запланированным запросам (microsoft.insights/scheduledQueryRules) с KQL, связывая группы действий по идентификатору ресурса.
Определение групп действий (microsoft.insights/actionGroups) с получателями по email/SMS и через веб-перехватчики; параметризация адресов и конечных точек для маршрутизации в зависимости от среды.

Используйте условия и циклы копирования для масштабируемых развертываний (например, для применения параметров диагностики к набору идентификаторов ресурсов). Используйте функции ARM, такие как resourceId, subscriptionResourceId, reference, concat и guid, для создания динамических ссылок и стабильных имен. Обеспечивайте согласованность конфигурации телеметрии между службами, централизуя соглашения об именах ролей и выборку в настройках приложения, доставляемых через ARM или ресурсы конфигурации App Service.

Практический сценарий

Компании Adobe требуется сквозная наблюдаемость для нового многорегионального конвейера обработки мультимедиа, построенного на API-интерфейсах Azure App Service и микросервисах AKS. Им требуется быстрое обнаружение регрессий задержек, распределенная трассировка между службами, проактивные проверки доступности для общедоступных конечных точек и автоматизированная маршрутизация инцидентов в их систему дежурств с возможностью воспроизведения по принципу «инфраструктура как код».

Инструментирование служб с помощью Application Insights, используя строки подключения

Настройте каждую рабочую нагрузку App Service и AKS на использование строки подключения Application Insights вместо устаревших ключей, обеспечивая правильные конечные точки приема данных и перспективную маршрутизацию. Задайте имена облачных ролей для каждой службы, чтобы обеспечить четкую фильтрацию и визуализацию на картах. Выберите инструментирование на основе SDK в основных API для генерации доменных событий и метрик; включите бескодовое подключение для вспомогательных служб, чтобы ускорить охват. Почему: Строки подключения обеспечивают гибкость конечных точек; SDK предоставляют пользовательскую телеметрию, а бескодовое подключение снижает затраты на внедрение.

Включение распределенной трассировки и отслеживания зависимостей

Убедитесь, что исходящие HTTP-клиенты и Azure SDK распространяют контекст трассировки W3C; проверьте непрерывность operation_Id в KQL. Для фоновых потоков сообщений (Service Bus) убедитесь, что корреляция внедряется и извлекается SDK; дополните с помощью TelemetryInitializers там, где используются пользовательские заголовки. Почему: Последовательное распространение трассировки обеспечивает точное определение сквозных задержек и атрибуцию сбоев в микросервисах.

Внедрение тестов доступности и пользовательских синтетических проверок

Настройте тесты проверки связи по URL для общедоступных API из нескольких географических регионов с проверкой совпадения содержимого на облегченной конечной точке проверки работоспособности. Для потоков с аутентификацией (получение токена и отправка медиа) реализуйте синтетический клиент, который вызывает рабочий процесс и генерирует результаты TrackAvailability с указанием местоположения запуска и подробными сообщениями. Почему: Проверки связи по URL обеспечивают быструю внешнюю верификацию; TrackAvailability поддерживает сложные бизнес-процессы с аутентификацией, выходящие за рамки базовых проверок.

Централизация данных в рабочей области Log Analytics и маршрутизация платформенных журналов

Разверните рабочую область и настройте параметры диагностики в App Services, журналах уровня управления AKS, Key Vault и Storage для потоковой передачи журналов и метрик в эту рабочую область. Убедитесь, что ресурсы Application Insights основаны на рабочей области для унификации запросов. Почему: Единая рабочая область позволяет использовать KQL для запросов между службами, объединяя запросы, зависимости и платформенные журналы для комплексного анализа.

Создание оповещений по метрикам и журналам с группами действий

Определите оповещения по метрикам для процентилей длительности запросов и доступности по местоположению с динамическими пороговыми значениями, с разделением по имени облачной роли. Добавьте оповещения по запланированным запросам, которые обнаруживают всплески ошибок по имени операции и коррелируют их со сбоями зависимостей, используя KQL join по operation_Id. Почему: Оповещения по метрикам обеспечивают обнаружение почти в реальном времени; оповещения по журналам фиксируют сложные закономерности, которые невозможно выразить простыми пороговыми значениями.

Интеграция реагирования на инциденты через группы действий и веб-перехватчики

Настройте группу действий с отправкой email для владельцев служб, SMS для руководителей дежурной смены и безопасный веб-перехватчик на платформу инцидентов Adobe с использованием Common Alert Schema. Добавьте получателя Logic App для обогащения полезных данных последними результатами запросов KQL и метаданными топологии. Почему: Многоканальные уведомления сокращают MTTA; веб-перехватчик и Logic App позволяют автоматизировать создание заявок и формировать инциденты с богатым контекстом.

Кодификация мониторинга с помощью шаблонов ARM

Создайте шаблоны ARM для развертывания рабочей области Log Analytics, Application Insights (на основе рабочей области), параметров диагностики, оповещений по метрикам, оповещений по запланированным запросам и групп действий. Параметризуйте имена сред, регионы и контактные данные; выводите connectionString Application Insights для последующей конфигурации приложений. Используйте связанные шаблоны для модулей, принадлежащих командам (платформа и приложение). Почему: «Инфраструктура как код» обеспечивает согласованную, повторяемую наблюдаемость в средах разработки, тестирования и эксплуатации и поддерживает CI/CD.

Проверка с помощью панелей мониторинга KQL

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

← Кэширование · Все домены

Отработать эти вопросы → · Тесты на время на ExamRoll.io →