Laboratório de Troubleshooting: Set up alert rules, action groups, and alert processing rules in Azure Monitor
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que uma regra de alerta configurada para monitorar a métrica Percentage CPU de uma máquina virtual nunca disparou, mesmo durante um evento de alta carga documentado pelo time de aplicação. O evento ocorreu na última sexta-feira às 14:30 UTC e durou aproximadamente 20 minutos, com CPU sustentada acima de 95% segundo o painel de métricas do portal Azure.
A regra de alerta foi criada há três semanas e está listada como Enabled no portal. O action group associado foi testado manualmente na mesma semana da criação e enviou e-mail corretamente. A assinatura não possui nenhuma política de Azure Policy bloqueando criação de alertas. A máquina virtual está em uma região diferente da região padrão da equipe, mas ainda dentro da mesma assinatura.
A configuração atual da regra é a seguinte:
Recurso: /subscriptions/xxx/resourceGroups/rg-prod/providers/
Microsoft.Compute/virtualMachines/vm-prod-app01
Métrica: Percentage CPU
Operador: Greater than
Threshold: 80
Aggregation type: Average
Aggregation period: 5 minutes
Evaluation frequency: 15 minutes
Severidade: Sev 2
Action Group: ag-ops-standard
Após investigação inicial, a equipe observa no histórico de avaliações da regra que ela foi avaliada normalmente durante o período do incidente e que nenhuma condição de violação foi registrada, apesar dos valores visíveis no painel de métricas.
Qual é a causa raiz do problema?
A. O action group ag-ops-standard perdeu a associação com a regra após uma atualização de permissões na assinatura.
B. A métrica exibida no painel usa granularidade de 1 minuto, enquanto a regra agrega os dados em janelas de 5 minutos, e a média calculada nessa janela não ultrapassou o threshold de 80%.
C. A frequência de avaliação de 15 minutos fez com que a janela do incidente fosse ignorada por completo.
D. A máquina virtual estar em uma região diferente da padrão causou atraso na coleta das métricas, impedindo a avaliação correta.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: uma alert processing rule do tipo Suppress notifications está ativa no escopo da assinatura inteira, sem agendamento recorrente, e foi criada há seis meses por um engenheiro que já saiu da empresa. Não há documentação sobre a finalidade original dessa regra.
O ambiente é de produção ativa, com SLA contratual de resposta a incidentes em vigor. O time de segurança informou que há uma auditoria de configurações de monitoramento agendada para amanhã às 09:00 UTC. O gestor de operações autorizou qualquer ação necessária para restaurar as notificações imediatamente.
Qual é a ação correta a tomar neste momento?
A. Excluir imediatamente a alert processing rule para restaurar o comportamento padrão de notificações em toda a assinatura.
B. Desabilitar a alert processing rule, validar que as notificações voltaram a funcionar corretamente e, somente após confirmação, decidir entre excluí-la ou documentá-la e reescrevê-la com escopo e agendamento adequados.
C. Criar uma nova alert processing rule do tipo Apply action groups no mesmo escopo para sobrepor a regra de supressão existente.
D. Aguardar a auditoria de amanhã para que a decisão sobre a regra seja tomada com revisão formal, evitando mudanças não documentadas às vésperas do processo.
Cenário 3 — Causa Raiz
Um desenvolvedor criou uma regra de alerta baseada em Log Analytics para detectar erros críticos em uma aplicação web. A regra foi configurada para consultar o workspace law-prod-eastus e enviar notificação ao action group ag-dev-alerts sempre que o número de eventos com severity = critical ultrapassasse 5 em uma janela de 10 minutos.
Na última semana, a aplicação gerou 47 erros críticos confirmados nos logs da aplicação, mas nenhum alerta foi disparado. O time verificou:
- O action group
ag-dev-alertsestá ativo e o e-mail de destino está correto. - A regra de alerta está habilitada e sem alert processing rules aplicadas ao seu escopo.
- O workspace
law-prod-eastusestá recebendo dados normalmente, conforme confirmado por outras queries executadas manualmente.
A query configurada na regra de alerta é:
AppEvents
| where Properties.severity == "critical"
| summarize count() by bin(TimeGenerated, 10m)
| where count_ > 5
Ao executar essa query manualmente no Log Analytics durante o período do incidente, o resultado retornou 0 linhas.
Uma consulta alternativa executada pelo time retornou os 47 erros esperados:
AppExceptions
| where outerMessage contains "critical"
| summarize count() by bin(TimeGenerated, 10m)
Qual é a causa raiz do problema?
A. A regra de alerta está consultando a tabela errada; os eventos de erro da aplicação estão sendo ingeridos na tabela AppExceptions, não na tabela AppEvents.
B. A função bin(TimeGenerated, 10m) não é compatível com regras de alerta baseadas em log no Azure Monitor.
C. O action group ag-dev-alerts não suporta notificações originadas de alertas baseados em log; esse tipo de alerta requer um action group dedicado.
D. O workspace law-prod-eastus está em uma região diferente da regra de alerta, o que introduz latência de ingestão superior à janela de avaliação configurada.
Cenário 4 — Sequência de Diagnóstico
Uma regra de alerta de métrica foi disparada corretamente e o estado no portal Azure Monitor mostra Fired. No entanto, nenhum membro da equipe de plantão recebeu notificação por e-mail. O action group associado à regra contém uma ação do tipo Email/SMS/Push/Voice com três endereços de e-mail cadastrados.
Os passos de investigação disponíveis são:
- Verificar o histórico de disparos da regra de alerta no portal para confirmar que o estado Fired foi registrado com timestamp correto.
- Verificar se existe alguma alert processing rule ativa com escopo que abranja a regra de alerta ou o resource group, do tipo Suppress notifications.
- Acessar o action group no portal e usar a funcionalidade Test action group para disparar uma notificação de teste para os e-mails cadastrados.
- Confirmar junto aos destinatários se o e-mail foi recebido na pasta de spam ou bloqueado por filtro corporativo.
- Verificar no portal se o action group está associado corretamente à regra de alerta e se não foi desassociado após uma edição recente da regra.
Qual é a sequência de investigação correta?
A. 3 -> 4 -> 5 -> 2 -> 1
B. 1 -> 5 -> 2 -> 3 -> 4
C. 2 -> 1 -> 3 -> 5 -> 4
D. 5 -> 3 -> 1 -> 2 -> 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no histórico de avaliações da regra: ela foi avaliada normalmente e nenhuma violação foi registrada. Isso elimina imediatamente qualquer hipótese relacionada a falha de disparo, problema de action group ou atraso de região, pois o motor de avaliação funcionou e concluiu que a condição não foi satisfeita.
O painel de métricas do portal Azure exibe, por padrão, pontos com granularidade de 1 minuto. Picos de CPU que aparecem visualmente altos nessa visualização podem ser suavizados quando agregados em janelas de 5 minutos pela função Average. Se a média calculada sobre os 5 minutos não ultrapassou 80%, a regra se comportou corretamente ao não disparar.
A informação sobre a região diferente é propositalmente irrelevante: o Azure Monitor coleta métricas de recursos em qualquer região dentro da mesma assinatura sem restrição de avaliação. Focar nesse detalhe é o erro de diagnóstico mais comum nesse tipo de cenário.
O distrator mais perigoso é a alternativa C. A frequência de avaliação de 15 minutos não faz a regra "pular" janelas de incidente; ela define de quanto em quanto tempo a janela de 5 minutos é reavaliada. Durante um incidente de 20 minutos, a regra teria sido avaliada pelo menos uma vez. O risco de agir com base nessa alternativa seria alterar a frequência sem resolver a causa real, que é a agregação pelo valor médio.
Gabarito — Cenário 2
Resposta: B
O cenário apresenta uma causa identificada e restrições concretas: produção ativa, SLA de resposta em vigor e auditoria no dia seguinte. A ação correta deve restaurar as notificações imediatamente sem introduzir risco adicional.
Desabilitar a regra é preferível a excluí-la imediatamente porque preserva a configuração original para análise posterior, o que é relevante especialmente antes de uma auditoria. A exclusão imediata (alternativa A) resolve o problema operacional mas elimina evidência que pode ser relevante para o processo de auditoria de amanhã.
A alternativa C é tecnicamente incorreta: uma alert processing rule do tipo Apply action groups não sobrepõe nem cancela uma regra de supressão; as duas coexistem e a supressão prevalece porque remove as notificações antes que as ações sejam executadas.
A alternativa D ignora a restrição mais crítica do cenário: o SLA de resposta a incidentes em vigor. Aguardar a auditoria com as notificações suprimidas em produção é uma decisão que viola o compromisso contratual e representa o distrator mais perigoso.
Gabarito — Cenário 3
Resposta: A
A confirmação da causa raiz está na evidência direta fornecida no enunciado: a query da regra retornou 0 linhas quando executada manualmente, enquanto uma query alternativa sobre a tabela AppExceptions retornou os 47 erros esperados. Isso indica que os dados nunca estiveram na tabela AppEvents consultada pela regra.
O workspace está funcionando, o action group está correto, a regra está habilitada e nenhuma supressão está ativa. Todos esses elementos foram verificados explicitamente no enunciado, eliminando as alternativas B, C e D como causas possíveis.
A alternativa D é o distrator que explora a informação sobre região, presente no cenário anterior como elemento irrelevante e reutilizada aqui para testar se o leitor já aprendeu a desconsiderá-la automaticamente.
O distrator mais perigoso é a alternativa B: acreditar que a função bin() é incompatível com alertas de log levaria o time a reescrever a query sem corrigir a tabela, e o alerta continuaria sem disparar pelos mesmos 47 próximos eventos.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 1 -> 5 -> 2 -> 3 -> 4, que segue a lógica de diagnóstico progressivo: confirmar que o problema realmente ocorreu, verificar a configuração do Azure Monitor antes de testar componentes externos, e só então envolver fatores fora do controle da plataforma.
O passo 1 confirma que o disparo foi registrado com timestamp correto, estabelecendo a base do diagnóstico. O passo 5 verifica se o action group ainda está associado à regra, pois edições recentes podem desfazer essa ligação silenciosamente. O passo 2 investiga se uma alert processing rule está suprimindo a notificação após o disparo. O passo 3 testa o action group de forma isolada para confirmar se ele funciona independentemente da regra. O passo 4, por fim, envolve os destinatários e fatores externos como spam e filtros corporativos, que devem ser verificados somente após confirmar que a plataforma enviou corretamente.
A alternativa A comete o erro clássico de testar o action group antes de confirmar que o problema está nele, o que pode levar a um diagnóstico incorreto se o action group funcionar no teste mas a supressão estiver bloqueando apenas os disparos reais. A alternativa C inverte a lógica ao priorizar a busca por supressão antes de confirmar que o disparo ocorreu de fato.
Árvore de Troubleshooting: Set up alert rules, action groups, and alert processing rules in Azure Monitor
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada ou ação corretiva |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta de diagnóstico com base no que você consegue verificar diretamente no portal Azure ou via CLI. Siga o caminho correspondente à resposta obtida em cada nó até alcançar um nó vermelho, que nomeia a causa e a ação corretiva indicada. Quando o caminho passar por um nó laranja, execute a validação descrita antes de avançar, pois ela protege contra diagnósticos prematuros que levam a ações incorretas.