Microsoft AZ-204: Monitoramento, Diagnóstico e Integração com DevOps do Azure — Guia de estudos

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

Faz parte do Microsoft Azure Developer Associate AZ-204 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Azure Monitor e o Application Insights fornecem uma pilha de observabilidade unificada e focada no desenvolvedor para aplicações Azure. O Application Insights coleta telemetria da aplicação, como requisições, dependências, exceções e rastreamentos, enquanto o Azure Monitor agrega métricas e logs de todos os recursos em um workspace do Log Analytics e impulsiona alertas e integrações de DevOps. Dominar as opções de instrumentação, a semântica da telemetria, os testes de disponibilidade, a Kusto Query Language (KQL), os alertas com grupos de ação, o rastreamento distribuído e a Infraestrutura como Código com modelos ARM garante soluções confiáveis, diagnosticáveis e automatizáveis.

Instrumentação e telemetria do Application Insights

Os recursos do Application Insights são identificados para ingestão por uma chave de instrumentação ou por uma string de conexão. A chave de instrumentação é o GUID único legado usado pelos SDKs para rotear a telemetria. A string de conexão é a recomendação atual; ela inclui a chave de instrumentação mais metadados de endpoint (endpoints de ingestão e do Live Metrics) e permite o roteamento para endpoints não padrão (para nuvens soberanas ou privadas). Use a string de conexão em novos códigos e configurações; ela permite futuras alterações de endpoint sem a necessidade de reimplantar o código. Dentro de um App Service, habilitar o Application Insights no nível da plataforma preencherá a string de conexão nas configurações de ambiente para runtimes detectados automaticamente.

A instrumentação pode ser feita via SDK ou por instrumentação automática. A abordagem via SDK (por exemplo, Microsoft.ApplicationInsights.AspNetCore para .NET, applicationinsights para Node.js e o agente Java do Application Insights) oferece controle no nível do código: eventos personalizados, métricas e telemetria enriquecida por meio de TelemetryInitializers e processadores, incluindo amostragem adaptativa. A instrumentação automática (anexação sem código) está disponível para o App Service e algumas pilhas de computação e usa extensões de site/agentes para coletar requisições de entrada, dependências e exceções sem alterações no código. Use a instrumentação via SDK quando precisar de eventos personalizados, métricas de negócio ou correlação explícita em trabalhos em segundo plano; use a anexação sem código para visibilidade rápida e de baixo esforço ou para cargas de trabalho lift-and-shift. Em ambos os casos, defina o nome da função de nuvem (cloud role name) para distinguir os serviços em uma arquitetura de microsserviços e configure a amostragem cuidadosamente para equilibrar fidelidade e custo.

O Application Insights emite vários tipos principais de telemetria:

Requisições capturam operações de entrada (requisições HTTP, invocações de função), com duração, código de resposta e sucesso.
Dependências capturam chamadas de saída (HTTP, SQL, chamadas de SDK do Azure, filas), com alvo, tipo, duração e sucesso.
Exceções capturam erros lançados, rastreamentos de pilha e exceções tratadas quando rastreadas explicitamente.
Rastreamentos capturam mensagens de log; os SDKs se integram com frameworks de log populares para que os logs e a telemetria compartilhem a correlação.
Eventos capturam ocorrências personalizadas no nível de negócio via TrackEvent, suportando dimensões e contagens personalizadas.
Métricas capturam medições numéricas; você pode rastrear métricas personalizadas para KPIs e inspecioná-las no Metrics Explorer.

O rastreamento distribuído no Application Insights depende da correlação. Cada operação de ponta a ponta tem um ID de operação (trace ID nos termos do W3C) compartilhado entre a telemetria relacionada; cada span tem relações pai-filho aplicadas por cabeçalhos de propagação. Os SDKs modernos usam o W3C Trace Context (traceparent, tracestate). O Operation_Id no KQL vincula Requisições, Dependências, Exceções e Rastreamentos para a mesma transação. Garanta que os clientes HTTP de saída propaguem os cabeçalhos; para .NET, o System.Diagnostics.Activity e o SDK do AI lidam com isso automaticamente. O rastreamento de dependências instrumenta clientes comuns (HTTP, SQL, Service Bus, Storage). Quando os serviços cruzam fronteiras (por exemplo, do App Service para o AKS), a propagação consistente resulta em um único mapa de transação conectado. Para fluxos assíncronos e baseados em mensagens, garanta que os SDKs capturem e fluam os IDs de correlação nos metadados da mensagem; a maioria dos SDKs do Azure faz isso por padrão.

Testes de disponibilidade e monitoramento sintético

Os testes de disponibilidade validam a acessibilidade externa e a capacidade de resposta de várias geografias. O teste de ping de URL emite requisições HTTP em uma frequência configurada a partir de vários locais de teste e valida códigos de status, a saúde do SSL e, opcionalmente, a correspondência de conteúdo. Use novas tentativas e vários locais para reduzir falsos positivos e configure alertas sobre falhas nos testes para receber notificações acionáveis.

Os testes de disponibilidade de várias etapas historicamente executavam sequências gravadas de requisições HTTP com cookies de estado para verificar fluxos de trabalho. Os testes web clássicos de várias etapas foram descontinuados; para cenários com múltiplas requisições ou autenticados, implemente testes sintéticos instrumentando seu próprio cliente ou serviço usando a API TrackAvailability (ou exportadores OpenTelemetry) para emitir AvailabilityTelemetry. Essa abordagem permite autenticação personalizada, payloads e validação específica do domínio, mantendo os relatórios e alertas centralizados.

O TrackAvailability personalizado lhe dá controle sobre:

Nome do teste, local de execução e identificadores de sequência para análise de tendências e desduplicação.
Semântica de duração e sucesso com base em suas validações, não apenas no status HTTP.
Mensagens ricas e dimensões personalizadas para dicas de causa raiz e correlação com a telemetria do backend.

Combine os testes de disponibilidade com a telemetria de dependências e requisições do backend para diferenciar rapidamente problemas de disponibilidade do endpoint (rede, DNS, TLS) de falhas da aplicação (exceções, timeouts) e interrupções downstream (SQL, APIs externas). Vincule as falhas dos testes de disponibilidade a grupos de ação para impulsionar os fluxos de trabalho de incidentes.

Dados do Azure Monitor, KQL e alertas com grupos de ações

O Azure Monitor ingere dois tipos de dados principais: métricas e logs. Métricas são séries temporais numéricas e leves, com ingestão quase em tempo real e segmentação multidimensional (ex: por instância, rota de API). Elas são ideais para detecção rápida (CPU, memória, taxa de requisições, latência, disponibilidade) e suportam retenção de até 93 dias por padrão. Logs são registros estruturados e consultáveis armazenados em um workspace do Log Analytics e incluem dados do Application Insights, logs de recursos da plataforma e logs customizados com retenção configurável. Use as Configurações de Diagnóstico (Diagnostic settings) para rotear métricas da plataforma e logs de recursos para um workspace, Event Hub ou Storage para arquivamento e análise.

A Kusto Query Language (KQL) potencializa a análise exploratória, dashboards e alertas de log. Os padrões principais incluem:

Consultas básicas:

undefined

para amostragem rápida; sempre restrinja o tempo com

undefined

no início da consulta para melhor desempenho.

Filtragem e projeção:

undefined

para reduzir o payload e focar a análise.

Agregação:

undefined

para calcular taxas, percentis ou médias; use

undefined

para gráficos de tempo.

Junções (Joins):

undefined

em chaves de correlação como

undefined

para conectar

undefined

com

undefined

; para junções entre recursos (cross-resource joins), garanta que ambos enviem dados para o mesmo workspace ou habilite consultas entre recursos.

Tabelas úteis:

undefined

para o Application Insights;

undefined

para logs da plataforma;

undefined

para o VM insights.

Melhores práticas: projete apenas as colunas necessárias, filtre no início, agrupe (bin) em intervalos razoáveis e evite cross-joins caros em janelas de tempo grandes, a menos que seja necessário.

Os alertas abrangem métricas e logs. Alertas de métrica avaliam limiares de métricas quase em tempo real, suportam dimensões e divisão por dimensão, e podem usar limiares estáticos ou dinâmicos (linhas de base baseadas em ML). Eles são stateful (mantêm estado) e podem disparar e se resolver automaticamente com base nos resultados da avaliação, produzindo uma notificação quando o estado muda. Alertas de log (consulta agendada) executam KQL em uma cadência e disparam com base nos resultados da consulta (número de correspondências ou limiares de medida). Use alertas de log quando as condições dependerem de padrões complexos entre tabelas ou exigirem análise de texto. A detecção inteligente (Smart detection) e os alertas de anomalia no Application Insights podem destacar regressões sem limiares explícitos.

Grupos de ações (Action groups) definem conjuntos reutilizáveis de respostas para alertas. Os tipos de notificação incluem e-mail, SMS, voz e push para o aplicativo móvel do Azure. As integrações incluem:

Webhooks (v1 e v2) com o Common Alert Schema para payloads consistentes; defina cabeçalhos personalizados para autenticação e roteie para sistemas de incidentes (ex: PagerDuty ou receptores customizados).
Azure Functions, Logic Apps e runbooks do Automation para remediação e enriquecimento programáticos; use Logic Apps para transformações flexíveis e conectores.
Conectores ITSM (ex: ServiceNow) para abrir incidentes com campos mapeados. Combine grupos de ações com regras de processamento de alertas para suprimir alertas durante manutenções, rotear por severidade ou aplicar ações dinâmicas. Para webhooks de saída seguros, restrinja o receptor a IPs do Azure ou exija assinaturas/cabeçalhos e valide as propriedades do Common Alert Schema, como Essentials.AlertRule e AlertContext.

← Cache · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →