Laboratório de Troubleshooting: Configure log settings in Azure Monitor
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de segurança reporta que os logs de auditoria de um Azure Key Vault não aparecem no Log Analytics Workspace configurado como destino. O ambiente foi configurado há três semanas e funcionava normalmente até dois dias atrás.
O administrador verifica o Diagnostic Setting do Key Vault e encontra o seguinte estado:
{
"name": "diag-keyvault-prod",
"properties": {
"workspaceId": "/subscriptions/a1b2c3/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-prod",
"logs": [
{ "category": "AuditEvent", "enabled": true },
{ "category": "AzurePolicyEvaluationDetails", "enabled": true }
],
"metrics": [
{ "category": "AllMetrics", "enabled": true }
]
}
}
O administrador também verifica que:
- O Key Vault está na região East US
- O Log Analytics Workspace está na região West Europe
- O Workspace tem 47 GB ingeridos nos últimos 30 dias e o plano é Pay-As-You-Go
- O Key Vault possui 3 políticas do Azure atribuídas, nenhuma relacionada a diagnóstico
- A conta de serviço usada para consultas KQL tem a role Log Analytics Reader
Ao executar a query abaixo no Workspace, o retorno é vazio:
AzureDiagnostics
| where ResourceType == "VAULTS"
| where TimeGenerated > ago(48h)
| limit 10
Qual é a causa raiz da ausência de logs no Workspace?
A) A diferença de região entre o Key Vault e o Log Analytics Workspace impede a ingestão de logs de diagnóstico entre regiões distintas.
B) O Log Analytics Workspace foi desconectado do Diagnostic Setting quando atingiu um volume elevado de ingestão, exigindo reconexão manual.
C) O Workspace foi deletado e recriado, gerando um novo Resource ID que não corresponde mais ao configurado no Diagnostic Setting.
D) A role Log Analytics Reader atribuída à conta de serviço não permite visualizar dados da tabela AzureDiagnostics, que exige permissões elevadas.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que o Diagnostic Setting de uma Azure SQL Database de produção foi configurado incorretamente: todos os logs de diagnóstico estão sendo enviados para uma Storage Account localizada em uma subscription diferente, quando o requisito era enviá-los para o Log Analytics Workspace da subscription de produção.
A causa está confirmada. O contexto atual é:
- A Storage Account está em outra subscription e os dados já armazenados lá pertencem a outra equipe
- O banco de dados de produção atende 2.400 usuários simultâneos neste momento
- Não há janela de manutenção até sexta-feira (em 4 dias)
- A equipe de auditoria precisa consultar logs das últimas 6 horas para uma investigação em andamento
- Alterar ou deletar o Diagnostic Setting existente não causa downtime no banco de dados
Qual é a ação correta a tomar neste momento?
A) Deletar o Diagnostic Setting atual e criar um novo apontando para o Log Analytics Workspace correto, aproveitando que a operação não afeta a disponibilidade do banco de dados.
B) Aguardar a janela de manutenção de sexta-feira para realizar qualquer alteração no Diagnostic Setting, evitando riscos em produção.
C) Adicionar o Log Analytics Workspace como destino adicional no Diagnostic Setting existente sem remover a Storage Account, garantindo que os logs das próximas horas sejam capturados para a investigação em andamento.
D) Solicitar à equipe da outra subscription acesso temporário à Storage Account para que a equipe de auditoria consulte os logs diretamente de lá, resolvendo a necessidade imediata sem alterar configurações.
Cenário 3 — Causa Raiz
Um administrador configura um Diagnostic Setting em uma Virtual Network para enviar logs para um Log Analytics Workspace. Após 2 horas, ele executa a query abaixo e obtém resultados normalmente:
AzureDiagnostics
| where Category == "VMProtectionAlerts"
| limit 5
No dia seguinte, o mesmo administrador tenta configurar um segundo Diagnostic Setting na mesma Virtual Network, com destino a um Event Hub diferente, para alimentar um pipeline de SIEM. A operação é concluída sem erros no portal. Porém, 6 horas depois, o SIEM reporta que nenhum evento foi recebido do Event Hub.
Informações adicionais coletadas:
- O Event Hub foi criado há 8 meses e está ativo com outros produtores de dados
- O namespace do Event Hub está na mesma região da Virtual Network
- O administrador tem a role Owner na subscription
- A Virtual Network tem 12 subnets configuradas e 340 recursos associados
- O Diagnostic Setting criado para o Event Hub aparece listado no portal com status ativo
O administrador verifica os logs do Event Hub:
Event Hub: evh-siem-prod
Namespace: evhns-corp-eastus
Incoming Messages (last 6h): 0
Active Connections: 14
Outgoing Messages (last 6h): 892
Qual é a causa raiz do problema?
A) O Event Hub tem 14 conexões ativas de outros produtores, atingindo o limite de conexões simultâneas e bloqueando novos dados do Diagnostic Setting.
B) O segundo Diagnostic Setting foi criado com as categorias de log desabilitadas por padrão, e nenhuma categoria foi explicitamente habilitada durante a configuração.
C) O Diagnostic Setting para Event Hub exige que o administrador configure manualmente uma Authorization Rule com permissão de Send no namespace, e essa etapa foi omitida.
D) A Virtual Network já possui um Diagnostic Setting ativo, e o Azure Monitor não permite mais de um Diagnostic Setting por recurso para o mesmo tipo de destino.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta informando que logs de diagnóstico de um App Service pararam de ser ingeridos no Log Analytics Workspace. O App Service está em produção e não pode ser reiniciado.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se o Diagnostic Setting do App Service está habilitado e com as categorias corretas ativadas
- Executar uma query KQL no Workspace para confirmar a ausência de dados e identificar o último registro ingerido
- Verificar o status de saúde do Log Analytics Workspace e confirmar se há alertas de ingestão no Azure Monitor
- Confirmar se o App Service está gerando tráfego e produzindo logs no nível da aplicação
- Verificar se houve alterações recentes no Diagnostic Setting ou no Workspace usando o Activity Log da subscription
Qual é a sequência correta de investigação?
A) 2, 1, 5, 3, 4
B) 4, 2, 1, 5, 3
C) 1, 3, 2, 5, 4
D) 2, 5, 1, 3, 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista crítica está no enunciado: o Diagnostic Setting funcionava normalmente até dois dias atrás e parou subitamente, sem nenhuma alteração declarada na configuração visível. O workspaceId no JSON aponta para um Resource ID fixo. Se o Log Analytics Workspace foi deletado e recriado, mesmo com o mesmo nome, ele recebe um novo Resource ID. O Diagnostic Setting continua apontando para o ID anterior, que não existe mais, e a ingestão silenciosamente falha.
A informação irrelevante no cenário é o volume de 47 GB ingeridos no Workspace. Esse dado foi incluído para induzir a hipótese de throttling ou limite de ingestão, o que não existe como mecanismo automático de desconexão no Azure Monitor.
- A alternativa A é falsa: o Azure Monitor suporta plenamente o envio de logs entre regiões distintas; a diferença geográfica entre recurso e Workspace não impede a ingestão.
- A alternativa B descreve um comportamento que não existe: o Azure Monitor não desconecta Diagnostic Settings automaticamente por volume.
- A alternativa D confunde visibilidade com ingestão: a role Log Analytics Reader permite consultar dados já ingeridos. O problema é que os dados não chegam ao Workspace, não que estejam inacessíveis para a conta.
O distrator mais perigoso é A, pois a diferença de região é informação real e visível, e muitos administradores assumem restrições geográficas que não existem no Azure Monitor.
Gabarito — Cenário 2
Resposta: C
A restrição mais crítica do cenário é que a equipe de auditoria precisa de logs das próximas horas para uma investigação em andamento. Deletar o Diagnostic Setting atual (alternativa A) e criar um novo leva tempo de propagação e deixa uma janela sem coleta. Durante esse intervalo, os logs gerados pelo banco de dados não seriam capturados em lugar nenhum, comprometendo a investigação.
Adicionar o Log Analytics Workspace como destino adicional sem remover a Storage Account garante cobertura imediata e contínua. Um único Diagnostic Setting pode ter múltiplos destinos simultâneos, e essa alteração não causa downtime.
- A alternativa B está errada porque aguardar a janela de manutenção é desnecessário: alterações em Diagnostic Settings não afetam a disponibilidade do recurso monitorado.
- A alternativa D resolve o problema imediato da auditoria, mas não corrige a configuração incorreta, deixando o ambiente em estado não conforme por mais 4 dias.
- O distrator mais perigoso é A: tecnicamente correta em outro contexto, mas ignora a janela de ausência de coleta durante a recriação, que é exatamente o que a investigação em andamento não pode tolerar.
Gabarito — Cenário 3
Resposta: B
A causa raiz é que o segundo Diagnostic Setting foi criado sem habilitar nenhuma categoria de log. No portal do Azure, ao criar um novo Diagnostic Setting, as categorias de log individuais não são habilitadas automaticamente: o administrador deve selecionar explicitamente cada categoria desejada. O Diagnostic Setting aparece como "ativo" porque foi salvo com sucesso, mas com zero categorias habilitadas.
A pista confirmatória está nos métricas do Event Hub: Incoming Messages (last 6h): 0 com Active Connections: 14 e Outgoing Messages: 892. O Event Hub está funcionando normalmente para outros produtores. O problema está na origem, não no destino.
A informação irrelevante é o número de subnets e recursos associados à Virtual Network. Esses dados foram incluídos para sugerir complexidade e induzir hipóteses sobre limites de escala.
- A alternativa A é falsa: o limite de conexões do Event Hub não bloqueia produtores; o dado de 14 conexões ativas é irrelevante para o diagnóstico.
- A alternativa C descreve uma restrição real em outros contextos, mas o enunciado informa que o administrador tem role Owner na subscription, o que inclui permissões sobre namespaces de Event Hub.
- A alternativa D é falsa: o Azure Monitor permite múltiplos Diagnostic Settings por recurso, desde que apontem para destinos diferentes. Dois Diagnostic Settings no mesmo recurso com destinos distintos é um padrão suportado e comum.
O distrator mais perigoso é D, pois a limitação de "um destino por tipo" soa como uma restrição técnica plausível e muitos administradores não testam esse cenário na prática.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 2, 1, 5, 3, 4.
O raciocínio diagnóstico correto parte do ponto de observação mais próximo do sintoma reportado e avança em direção às causas possíveis:
Passo 2 confirma o sintoma com precisão: a query KQL determina exatamente quando a ingestão parou, transformando um alerta genérico em um dado objetivo com timestamp.
Passo 1 verifica a configuração do Diagnostic Setting: se as categorias estão desabilitadas ou o destino foi alterado, a causa está aqui e os passos seguintes são desnecessários.
Passo 5 investiga se houve uma mudança recente que explique a interrupção: o Activity Log registra alterações em Diagnostic Settings e no Workspace, revelando ações humanas ou automatizadas que coincidam com o timestamp identificado no passo 2.
Passo 3 verifica a saúde do Workspace: problemas de ingestão no lado do destino (throttling, estado degradado) só fazem sentido investigar após descartar problemas na origem.
Passo 4 é o último porque verificar se o App Service está gerando logs só é relevante se todos os outros componentes estiverem funcionando corretamente. Além disso, o enunciado já indica que o App Service está em produção ativa, tornando esse passo o menos urgente.
A alternativa B começa pelo App Service, ignorando que o sintoma já foi confirmado externamente por um alerta. A alternativa C começa pela configuração sem antes confirmar a extensão do problema. A alternativa D replica a sequência correta mas inverte os passos 1 e 5, investigando alterações antes de confirmar o estado atual da configuração.
Árvore de Troubleshooting: Configure log settings in Azure Monitor
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão sim/não) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| 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 siga as perguntas diagnósticas respondendo sim ou não com base no que você pode verificar diretamente no portal ou via query KQL. Cada caminho termina em uma causa nomeada seguida de uma ação específica e de um passo de validação que confirma se a correção foi efetiva. O objetivo é evitar ações corretivas antes de confirmar o diagnóstico: só avance para a ação após identificar com precisão o nó de causa correspondente.