Pular para o conteúdo principal

Laboratório Técnico: Interpret metrics in Azure Monitor

Questões

Questão 1 — Múltipla Escolha

Uma equipe de operações precisa identificar se uma máquina virtual está sofrendo pressão de memória ao longo do tempo. Ao acessar o Azure Monitor, o engenheiro navega até a seção de métricas e seleciona o recurso correto.

Qual das seguintes afirmações descreve corretamente o comportamento das métricas de plataforma em relação à memória de máquinas virtuais no Azure Monitor?

A) Métricas de plataforma incluem automaticamente o uso de memória RAM disponível, pois esse dado é coletado pelo hipervisor subjacente sem necessidade de agente.

B) O uso de memória RAM não está disponível como métrica de plataforma para VMs; é necessário instalar o Azure Monitor Agent e configurar uma Data Collection Rule para coletar essa métrica como métrica de convidado.

C) A métrica de memória disponível é coletada automaticamente pelo Azure Monitor e armazenada no Log Analytics Workspace sem qualquer configuração adicional.

D) Para obter métricas de memória, basta habilitar o Diagnostic Settings no nível da assinatura, redirecionando os dados para um Storage Account.


Questão 2 — Cenário Técnico

Um engenheiro está analisando o gráfico abaixo no Azure Monitor para uma VM de produção:

Métrica : Percentage CPU
Intervalo de tempo : Últimas 24 horas
Granularidade : 1 hora
Agregação selecionada : Maximum

O gráfico mostra picos de 95% de CPU em momentos específicos, mas a equipe de desenvolvimento afirma que a aplicação "nunca usa tanta CPU". O engenheiro suspeita que a leitura está incorreta.

Qual é a explicação mais provável para a discrepância?

A) A agregação Maximum exibe o maior valor registrado dentro de cada intervalo de granularidade, o que pode capturar picos momentâneos que a equipe não percebe no uso cotidiano.

B) A granularidade de 1 hora está calculando a média dos valores, suavizando os dados e gerando leituras artificialmente elevadas.

C) A métrica Percentage CPU no Azure Monitor mede o consumo relativo ao limite do vCPU throttling, e não o uso real do processador, o que distorce os valores.

D) O Azure Monitor armazena métricas com atraso de até 1 hora, portanto os picos visualizados correspondem a eventos de outras VMs no mesmo host físico.


Questão 3 — Verdadeiro ou Falso

Afirmação: No Azure Monitor, ao criar um gráfico de métricas no Metrics Explorer, é possível plotar métricas de diferentes recursos do Azure no mesmo gráfico, desde que esses recursos estejam na mesma assinatura.

Verdadeiro ou Falso?


Questão 4 — Cenário Técnico

Uma equipe de SRE configurou o seguinte alerta no Azure Monitor:

Recurso     : Storage Account (prodstg01)
Métrica : Transactions
Agregação : Total
Granularidade: 5 minutos
Condição : Total > 10000
Frequência : A cada 1 minuto

Após a implantação, a equipe observa que o alerta dispara repetidamente mesmo quando o número real de transações está abaixo do esperado. O Storage Account é de alta demanda e processa rajadas curtas de requisições.

Qual é a causa mais provável do comportamento inesperado?

A) A métrica Transactions não suporta a agregação Total; o correto seria usar Average, o que explica a contagem inflada.

B) A combinação de granularidade de 5 minutos com frequência de avaliação de 1 minuto faz com que a janela de agregação acumule transações de múltiplos períodos sobrepostos, elevando artificialmente o valor avaliado.

C) O Azure Monitor está somando transações de todos os Storage Accounts da assinatura porque o escopo do alerta não foi filtrado por Resource Group.

D) A frequência de avaliação de 1 minuto é menor que a granularidade de 5 minutos, o que força o Azure Monitor a preencher os intervalos faltantes com o último valor registrado, duplicando contagens.


Questão 5 — Múltipla Escolha

Um administrador precisa comparar o consumo de CPU entre três VMs diferentes usando o Metrics Explorer do Azure Monitor. Ele quer visualizar as três séries no mesmo gráfico para facilitar a análise comparativa.

Qual abordagem está correta para atingir esse objetivo?

A) Criar três gráficos separados, um por VM, pois o Metrics Explorer não permite adicionar métricas de múltiplos recursos individuais no mesmo gráfico.

B) Usar a funcionalidade Add metric múltiplas vezes, selecionando cada VM como recurso e a mesma métrica, o que resulta em séries distintas no mesmo gráfico.

C) Criar um Log Analytics Workspace e escrever uma query KQL para unir os dados das três VMs, pois métricas de múltiplos recursos só são comparáveis via logs.

D) Agrupar as três VMs em um Resource Group dedicado e selecionar o Resource Group como escopo, aplicando a divisão por recurso (Split by) para exibir cada VM como uma série separada.


Gabarito e Explicações

Gabarito — Questão 1

Resposta: B

Métricas de plataforma para VMs são coletadas pelo fabric do Azure e cobrem aspectos observáveis externamente, como Percentage CPU, Disk Read/Write Bytes e Network In/Out. O uso de memória RAM, no entanto, requer visibilidade dentro do sistema operacional convidado, algo que o hipervisor não expõe nativamente como métrica de plataforma. Para coletar essa informação, é necessário instalar o Azure Monitor Agent na VM e associá-la a uma Data Collection Rule que defina quais métricas de convidado devem ser coletadas.

O principal erro dos distratores é confundir o que o hipervisor consegue observar externamente com o que depende de instrumentação interna do sistema operacional. Escolher a alternativa A levaria o engenheiro a procurar uma métrica que simplesmente não existe no escopo de plataforma, causando lacunas de observabilidade não percebidas.


Gabarito — Questão 2

Resposta: A

A agregação Maximum instrui o Azure Monitor a retornar o maior valor amostrado dentro de cada intervalo de granularidade. Com granularidade de 1 hora, qualquer pico momentâneo ocorrido em qualquer segundo daquele intervalo será representado como o valor do ponto no gráfico. Isso é tecnicamente preciso, mas pode ser interpretado como "uso constante alto" se o observador não compreender a semântica da agregação.

A alternativa B inverte a lógica: a granularidade não "suaviza" dados com a agregação Maximum. A alternativa C descreve um comportamento que não existe: a métrica Percentage CPU mede o uso real do vCPU alocado à VM. A alternativa D confunde latência de ingestão com atribuição incorreta de dados entre recursos. Entender as diferenças entre Average, Maximum, Minimum e Total é fundamental para interpretar gráficos sem distorções analíticas.


Gabarito — Questão 3

Resposta: Falso

O Metrics Explorer permite adicionar métricas de recursos diferentes no mesmo gráfico, mas a restrição não é a assinatura: os recursos precisam estar na mesma região e ser do mesmo tipo de recurso. Além disso, ao usar escopo múltiplo, existem limitações sobre quais combinações são suportadas. A afirmação é falsa porque a condição "mesma assinatura" é insuficiente como único critério: recursos de tipos diferentes ou regiões diferentes não podem ser plotados juntos de forma direta no mesmo gráfico do Metrics Explorer. A compreensão correta desse limite evita erros de projeto ao construir dashboards operacionais.


Gabarito — Questão 4

Resposta: B

Quando a frequência de avaliação é menor que a granularidade da métrica, o Azure Monitor avalia janelas de tempo que se sobrepõem. Com granularidade de 5 minutos e frequência de 1 minuto, cada avaliação considera uma janela de 5 minutos que desliza a cada minuto. Para uma métrica de agregação Total, isso significa que as mesmas transações podem ser contadas em múltiplas janelas consecutivas, inflando o valor avaliado e disparando alertas falsos positivos.

A alternativa A está incorreta porque Total é uma agregação válida para métricas de contagem como Transactions. A alternativa C está incorreta porque o escopo do alerta foi definido diretamente no recurso. A alternativa D descreve um comportamento de preenchimento de lacunas que não se aplica ao problema descrito. A solução prática seria alinhar a granularidade e a frequência, ou aumentar o threshold considerando a janela efetiva de contagem.


Gabarito — Questão 5

Resposta: D

A abordagem mais robusta e nativa do Metrics Explorer para comparar a mesma métrica entre múltiplos recursos do mesmo tipo é selecionar um escopo que os agrupe (como o Resource Group ou uma seleção múltipla de recursos) e usar a funcionalidade Split by resource para que cada recurso apareça como uma série distinta no mesmo gráfico. Isso é mais escalável do que a alternativa B, que também é funcionalmente possível, mas exige adições manuais repetidas e pode se tornar impraticável com muitos recursos.

A alternativa A está incorreta porque o Metrics Explorer suporta múltiplos recursos no mesmo gráfico. A alternativa C é um caminho válido para análises avançadas via KQL, mas desnecessariamente complexo para uma comparação visual simples que o Metrics Explorer resolve nativamente. Reconhecer quando usar Metrics Explorer versus Log Analytics é uma habilidade de julgamento operacional essencial no AZ-104.