Laboratório de Troubleshooting: Interpret metrics in Azure Monitor
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações de uma empresa recebe uma reclamação: o painel de monitoramento mostra que a métrica Available Memory Bytes de uma VM Windows de produção (vm-prod-app01, Standard D4s v3, região East US 2) simplesmente desapareceu dos gráficos no Metrics Explorer. A métrica estava visível até três dias atrás.
O engenheiro responsável verifica o seguinte:
VM Status : Running
OS : Windows Server 2022
Azure Monitor Agent: Instalado (versão 1.22.0)
Diagnostic Settings: Habilitado (destina para Log Analytics Workspace)
Workspace Region : West US
Last heartbeat : 4 days ago
A equipe menciona que, dois dias atrás, aplicaram uma atualização de política de segurança corporativa que bloqueou comunicação de saída na porta 443 para alguns endpoints. Também informam que a VM passou por um resize de D2s para D4s no mesmo período, operação que reiniciou a máquina.
Qual é a causa raiz do desaparecimento da métrica?
A) O resize da VM de D2s para D4s reiniciou o agente e corrompeu sua configuração local, exigindo reinstalação.
B) A política de segurança bloqueou a comunicação do Azure Monitor Agent com os endpoints de ingestão, interrompendo o envio de métricas de convidado.
C) A métrica Available Memory Bytes é uma métrica de plataforma que foi descontinuada para VMs da série D após a versão de setembro de 2023.
D) A destinação do Log Analytics Workspace em uma região diferente da VM causa latência de replicação superior a 72 horas, fazendo a métrica parecer ausente.
Cenário 2 — Decisão de Ação
A equipe de SRE identificou a causa de um alerta recorrente e falso positivo: uma regra de alerta configurada para a métrica Transactions de um Storage Account usa granularidade de 5 minutos com frequência de avaliação de 1 minuto e agregação Total. As janelas sobrepostas estão inflando os valores avaliados.
O Storage Account é utilizado por uma aplicação financeira crítica que opera 24 horas por dia, 7 dias por semana, sem janela de manutenção programada. A regra de alerta atual está notificando o time via PagerDuty a cada 3 a 5 minutos, gerando fadiga de alertas. O engenheiro tem permissão de Monitoring Contributor no Resource Group.
Qual é a ação correta a tomar neste momento?
A) Excluir a regra de alerta existente e recriar do zero com granularidade e frequência de avaliação alinhadas (ambas em 5 minutos), sem interromper a aplicação.
B) Aumentar o threshold da condição de alerta para um valor alto o suficiente para absorver a inflação causada pelas janelas sobrepostas, mantendo a configuração atual.
C) Desabilitar temporariamente a regra de alerta, aguardar uma janela de manutenção para aplicar as correções necessárias e reabilitar depois.
D) Editar a regra de alerta existente alterando apenas a frequência de avaliação para 5 minutos, alinhando-a com a granularidade, sem excluir nem recriar a regra.
Cenário 3 — Causa Raiz
Um desenvolvedor abre um chamado relatando que criou um alerta no Azure Monitor para monitorar a métrica Http5xxErrors de um Azure App Service, mas o alerta nunca disparou, mesmo com erros 500 visíveis nos logs da aplicação.
O engenheiro de plantão acessa o portal e encontra o seguinte:
Recurso : App Service (app-api-prod)
Métrica : Http5xxErrors
Agregação : Average
Granularidade : 5 minutos
Condição : Average > 0
Frequência : A cada 5 minutos
Status da regra : Enabled
Action Group : ag-oncall (email + webhook)
O engenheiro também observa que o App Service está em um App Service Plan do tier Standard S2 e que o Application Insights está habilitado e conectado. Os logs do Application Insights mostram claramente exceções do tipo HTTP 500 ocorrendo a cada 10 a 15 minutos, com duração inferior a 30 segundos cada.
Qual é a causa raiz do alerta nunca ter disparado?
A) O Application Insights captura os erros antes que a métrica Http5xxErrors seja registrada, impedindo que o Azure Monitor os contabilize.
B) A agregação Average diluiu os erros pontuais dentro da janela de 5 minutos: se apenas 1 ou 2 requests falharam em centenas, a média permanece próxima de zero e não cruza o threshold de > 0.
C) O tier Standard S2 do App Service Plan não suporta a emissão da métrica Http5xxErrors para o Azure Monitor; esse recurso requer o tier Premium.
D) O Action Group ag-oncall está com o webhook configurado incorretamente, e o alerta dispara internamente, mas a notificação nunca é entregue.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "Os alertas de CPU de várias VMs pararam de disparar ao mesmo tempo. As VMs continuam funcionando normalmente."
Abaixo estão os passos de investigação disponíveis, apresentados fora de ordem:
[P] Verificar se as regras de alerta estão habilitadas e sem supressão ativa
[Q] Confirmar se as métricas de CPU estão sendo coletadas e visíveis no Metrics Explorer
[R] Verificar o histórico de disparos do alerta nas últimas 24 horas na aba "Alert history"
[S] Checar se o Action Group associado às regras tem endpoints válidos e sem erros de entrega
[T] Confirmar se houve mudança recente nas regras de alerta ou nos thresholds configurados
Qual é a sequência correta de diagnóstico?
A) T, P, Q, R, S
B) Q, P, T, R, S
C) R, Q, P, T, S
D) P, Q, R, T, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no Last heartbeat: 4 days ago, que coincide exatamente com o momento em que a política de segurança foi aplicada. O Azure Monitor Agent depende de comunicação de saída via HTTPS (porta 443) com endpoints específicos da Microsoft para enviar métricas de convidado, incluindo Available Memory Bytes. O bloqueio dessa comunicação interrompe silenciosamente o fluxo de dados, fazendo a métrica desaparecer sem erros visíveis na VM.
A informação sobre o resize da VM é propositalmente irrelevante: reinicializações não corrompem a configuração do agente, e o fato de a VM estar em estado Running descarta problemas de disponibilidade. A alternativa C é falsa porque Available Memory Bytes continua sendo uma métrica de convidado suportada. A alternativa D descreve um comportamento que não existe: diferenças de região entre VM e workspace causam latência mínima, não ausência de dados.
O distrator mais perigoso é A, pois o resize e a reinicialização são eventos concretos e próximos no tempo, o que induz o engenheiro a atribuir a causa ao evento mais visível, ignorando a política de rede aplicada simultaneamente.
Gabarito — Cenário 2
Resposta: D
A causa já foi identificada (janelas sobrepostas por frequência menor que granularidade) e a correção cirúrgica é alinhar a frequência de avaliação com a granularidade, ambas em 5 minutos. A alternativa D resolve o problema sem excluir a regra, sem interromper o monitoramento e sem exigir janela de manutenção, respeitando todas as restrições do cenário.
A alternativa A também corrigiria o problema tecnicamente, mas excluir e recriar uma regra implica um período de ausência de cobertura, o que é inaceitável para uma aplicação financeira crítica sem janela de manutenção. A alternativa B é uma gambiarra que mascara o problema sem corrigi-lo, comprometendo a sensibilidade do alerta. A alternativa C viola diretamente a restrição de ausência de janela de manutenção.
O engenheiro tem permissão Monitoring Contributor, suficiente para editar regras de alerta, o que torna a alternativa D viável sem escalação de permissões.
Gabarito — Cenário 3
Resposta: B
A agregação Average é o ponto crítico. A métrica Http5xxErrors conta o número de erros em um intervalo. Quando a agregação é Average, o Azure Monitor calcula a média dos pontos coletados dentro da janela de granularidade. Se a aplicação processa centenas de requests com 1 ou 2 falhas, a média de erros por período de coleta resulta em um valor decimal muito próximo de zero, nunca cruzando o threshold > 0 de forma consistente.
A solução correta seria usar a agregação Total ou Count, que acumularia os erros e cruzaria o threshold mesmo para falhas pontuais.
A informação sobre o Application Insights é propositalmente irrelevante: o Application Insights e as métricas de plataforma do App Service são fontes independentes; um não interfere no outro. A alternativa D é o distrator mais perigoso porque direciona a investigação para o Action Group, que é um componente separado do disparo do alerta. Se o alerta nunca disparou (e não "disparou mas não notificou"), o problema está na condição de disparo, não na entrega.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: Q, P, T, R, S.
O raciocínio diagnóstico progressivo deve começar pela camada mais fundamental: verificar se os dados existem (Q). Se as métricas não estiverem visíveis no Metrics Explorer, o problema está na coleta, não nas regras. Em seguida, confirmar se as regras estão ativas e sem supressão (P), depois investigar se houve mudanças recentes nas configurações (T), checar o histórico de disparos para entender se os alertas chegaram a avaliar as condições (R) e, por último, verificar se o problema está na entrega via Action Group (S).
A alternativa A começa por mudanças recentes antes de confirmar se os dados existem, o que pula a camada mais básica. A alternativa C começa pelo histórico de alertas, mas se as métricas não estão sendo coletadas, o histórico estará vazio e a informação será inconclusiva sem o contexto de Q primeiro. A alternativa D começa pelas regras sem confirmar se há dados para avaliar.
O erro mais comum nesse tipo de diagnóstico é ir direto para a configuração das regras sem antes validar que a telemetria está fluindo.
Árvore de Troubleshooting: Interpret metrics in Azure Monitor
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão) |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as ramificações respondendo cada pergunta com base no que você consegue verificar diretamente no portal ou via comando. Cada resposta elimina um conjunto de hipóteses e estreita o caminho até a causa. Nunca pule um nível de verificação para ir direto a uma causa assumida: a árvore é projetada para que a ordem das perguntas filtre os distratos mais comuns antes de chegar à causa real.