No exame AZ-305, a arquitetura de monitoramento e registro é o domínio que valida diretamente suas habilidades como arquiteto de soluções. A maioria das questões não foca em memorizar nomes de serviços, mas em julgar qual configuração escolher dado um cenário específico. Se você entender como Azure Monitor, Log Analytics, Application Insights, Diagnostic Settings e Alert Rules se conectam, conseguirá responder à grande maioria das questões desse domínio. Este post destila os principais conceitos e critérios de decisão a partir de 25 questões reais do exame.
---
Fluxo de dados no Azure Monitor
O Azure Monitor é a plataforma de monitoramento unificada que supervisiona todo o seu ambiente de nuvem. Ele coleta dados em quatro categorias principais.
Métricas são dados numéricos de séries temporais — utilização de CPU, uso de memória, taxa de transferência de rede e medições similares. A maioria dos recursos do Azure emite métricas automaticamente, e o período de retenção padrão é de 93 dias.
Logs são registros de eventos estruturados que respondem à pergunta "quem fez o quê e quando". Por padrão, os logs permanecem dentro do próprio recurso. Para analisá-los, você precisa roteá-los para um workspace do Log Analytics por meio das Diagnostic Settings.
O Activity Log é um log de plataforma que registra automaticamente cada operação de gerenciamento executada pelo Azure Resource Manager — implantações de recursos, exclusões, alterações de configuração e outros eventos do plano de controle. Não é necessário instalar agente nem configurar Diagnostic Settings; você pode consultá-lo imediatamente, e ele é retido por 90 dias por padrão.
Logs de diagnóstico são dados operacionais gerados dentro de um recurso — SQLInsights para Azure SQL Database, logs do App Service, logs de acesso ao Key Vault e outros. Você precisa configurar Diagnostic Settings para especificar um destino (Log Analytics, Storage Account ou Event Hub) antes que qualquer dado seja coletado.
Armadilha do exame: "Consultar o histórico de gerenciamento imediatamente, sem agente, sem configuração extra" → Activity Log. Analisar logs operacionais dentro de um recurso → Diagnostic Settings precisa vir primeiro.
---
Design do workspace do Log Analytics
O workspace do Log Analytics é o repositório central de logs do Azure Monitor. As questões do exame frequentemente perguntam sobre o número adequado de workspaces e como otimizar os custos.
Único vs. múltiplos workspaces
Network Insights, Application Insights baseado em workspace, Microsoft Sentinel e VM Insights podem ser consolidados em um único workspace do Log Analytics. O número de serviços não é igual ao número de workspaces. Um único workspace é suficiente quando o objetivo é centralização e correlação entre serviços; considere múltiplos workspaces somente quando as equipes exigirem isolamento completo ou soberania de dados. Como um único recurso suporta até cinco Diagnostic Settings, duas equipes que queiram cada uma seu próprio workspace independente podem simplesmente criar duas Diagnostic Settings apontando para dois workspaces diferentes.
Agentes de coleta de dados: AMA e DCR
O Azure Monitor Agent (AMA) substitui o MMA legado e é usado junto com um Data Collection Rule (DCR). Um DCR é um recurso de política que define o que coletar e para onde enviar.
Ao calcular o número de DCRs necessários, o fator determinante não é a quantidade de VMs, mas a diferença no sistema operacional e no tipo de fonte de dados. Se você tem 20 VMs com Windows coletando logs de eventos de segurança e 15 VMs com Linux coletando Syslog, precisa de no mínimo dois DCRs porque os tipos de sistema operacional diferem.
Um Data Collection Endpoint (DCE) é necessário apenas em ambientes com isolamento de rede. Se as máquinas conseguem acessar um endpoint público e não há requisito de isolamento, o número de DCEs é zero. A menos que a questão mencione Private Link ou bloqueio de internet, assuma que um DCE não é necessário.
Retenção de dados e otimização de custos
O período de retenção padrão de um workspace do Log Analytics é de 30 dias. A retenção interativa máxima é de 730 dias (2 anos); com a camada de arquivo, os dados podem ser mantidos por até 4.383 dias (aproximadamente 12 anos). A camada interativa suporta consultas KQL, mas tem custo mais alto; a camada de arquivo restringe consultas, mas tem custo mais baixo.
Para reduzir os custos de ingestão, mude para um plano de preços de Commitment Tier. Você pode economizar mais de 30% em comparação com o pagamento por uso, e a mudança não afeta Alert Rules existentes nem runbooks de automação. Observe que a configuração retention days em uma Diagnostic Settings de Storage Account controla o ciclo de exclusão automática de blobs — é independente do período de retenção consultável no Log Analytics.
---
Application Insights e rastreamento distribuído
O Application Insights é um serviço dedicado de monitoramento de desempenho de aplicações (APM). Ao contrário do Azure Monitor, que se concentra em métricas de infraestrutura, o Application Insights é especializado em análise no nível de transação e análise do comportamento do usuário.
Três capacidades principais
O Application Map visualiza as relações de chamada e as dependências entre microsserviços em um gráfico interativo. Você consegue identificar rapidamente os serviços com altas taxas de erro e os gargalos de latência de resposta.
O rastreamento distribuído (Distributed Tracing) rastreia a linha do tempo completa de ponta a ponta de uma única solicitação enquanto ela percorre múltiplos microsserviços.
A análise de usuários oferece seis tipos de análise — Users, Sessions, Funnels, Retention, User Flows e mais — tudo dentro de um único serviço.
Codeless Attach e testes de disponibilidade
Codeless Attach ativa a instrumentação automática no Azure App Service sem nenhuma alteração de código ou SDK — você o configura apenas pelas configurações do portal. Sempre que uma questão exigir análise de tempos de resposta no nível de transação e chamadas a dependências sem alterações de código, essa funcionalidade é a resposta.
Os testes de disponibilidade (Availability Tests) são monitoramento de transações sintéticas que simulam periodicamente fluxos de usuário sem usuários reais. Três tipos são suportados: testes de URL Ping, testes padrão e testes web de múltiplas etapas. Eles são executados a partir de localizações do Azure em todo o mundo sem necessidade de instalação de agente. Quando uma questão pedir monitoramento sintético sem infraestrutura adicional, escolha os Availability Tests do Application Insights.
---
Design de alertas e resposta automatizada
O sistema de alertas é composto por três elementos: um Alert Rule, um Action Group e um Alert Processing Rule.
Alert Rules e Action Groups
Alertas de métricas são baseados em limites numéricos — utilização de CPU, taxa de erros HTTP 5xx — e podem ser avaliados com frequência de até um minuto. Alertas baseados em consultas de log são disparados com base nos resultados de uma consulta KQL. Um único Action Group pode ser compartilhado entre múltiplos Alert Rules. Se três eventos — reinicialização de VM, desalocação de VM e desligamento de VM — precisam notificar os mesmos destinatários, o design ideal é um Action Group combinado com três Activity Log Alert Rules. Quando os destinatários mudarem, você só precisa atualizar o Action Group. Alert Processing Rules são usados para suprimir notificações durante janelas de manutenção.
Se os logs precisam ser coletados apenas por caminhos privados, sem passagem pela internet, use Azure Monitor Private Link Scope (AMPLS). O AMPLS conecta workspaces do Log Analytics e Application Insights a Private Endpoints dentro da sua VNet.
---
Tabela comparativa de serviços
A tabela abaixo resume os principais tipos de dados coletados pela plataforma Azure Monitor e as características de cada serviço.
| Tipo de dado | Serviço principal | Armazenamento | Coleta automática | Principais casos de uso | |---|---|---|---|---| | Métricas | Azure Monitor Metrics | Banco de dados de métricas (93 dias) | Majoritariamente automática | Monitoramento de desempenho em tempo real, alertas por limite | | Logs | Workspace do Log Analytics | Log Analytics (padrão 30 dias) | Requer Diagnostic Settings | Consultas KQL, análise de correlação, auditoria de longo prazo | | Traces | Application Insights | Vinculado ao Log Analytics (padrão 90 dias) | SDK ou Codeless Attach | Rastreamento distribuído, análise de transações | | Activity Log | Azure Activity Log | Automático pela plataforma (padrão 90 dias) | Totalmente automático | Auditoria de operações de gerenciamento, histórico de implantações |
Perspectiva de tabela: logs de eventos de segurança de VMs com Windows → tabela SecurityEvent; syslog do Linux → tabela Syslog; operações de gerenciamento do Azure → tabela AzureActivity; logs de diagnóstico de recursos → tabela AzureDiagnostics. SecurityEvent e Syslog são diferenciados por sistema operacional.
---
Critérios de decisão que confundem no exame
Cenário 1: Auditoria de operações de gerenciamento
"Consultar o histórico de implantação de recursos imediatamente, sem agente, sem configuração extra" — a resposta é Activity Log. É retido automaticamente por 90 dias. Para agregar Activity Logs de múltiplas assinaturas em um relatório mensal, roteie-os para o Log Analytics e use consultas KQL.
Cenário 2: Análise de desempenho sem alterações de código
"Analisar tempos de resposta no nível de transação e chamadas a dependências sem alterações de código" — Application Insights Codeless Attach é a resposta correta. Os alertas de métricas do Azure Monitor são projetados para alertas em nível agregado e não são adequados para rastreamento granular por transação.
Cenário 3: Múltiplos destinos nas Diagnostic Settings
"Monitoramento em tempo real (Log Analytics) e arquivamento de longo prazo (Storage Accoun