APRENDER. PRATICAR. EVOLUIR.1. Partir da decisão operacional
Um dashboard só ajuda se os seus sinais responderem à pergunta operacional. Num serviço fictício de fundos, APS precisa de distinguir saturação da infraestrutura, falha de uma dependência e atraso na própria telemetria. Define que componentes devem emitir dados, com que frequência e para que destino. Para cada gráfico ou alerta, regista a unidade, agregação, dimensões, intervalo temporal e responsável. Um valor antigo de CPU não demonstra estabilidade durante um incidente novo. Uma média do conjunto também não prova que todas as instâncias estão saudáveis. Começa o handover com estas condições observáveis e planeia um ensaio controlado. A existência de dashboards com os nomes certos é um inventário de configuração; a aceitação operacional exige demonstrar que dados atuais chegam e que alguém consegue interpretá-los.
2. Confirmar a cadeia de recolha nas máquinas
Em monitorização de máquinas com Azure Monitor Agent, distingue instalação, regra e associação. A DCR define fontes e destinos; a associação liga essa regra à máquina. Uma regra correta que nunca foi associada não demonstra recolha. Depois de uma migração, confirma o identificador do recurso, a configuração efetiva e o workspace usado pela consulta. A documentação atual distingue métricas OpenTelemetry e a experiência clássica baseada em logs, pelo que não deves assumir uma tabela única para qualquer caminho de monitorização. Uma hipótese no caso da aula é que o dashboard ainda consulte o destino antigo e mostre dados anteriores. A investigação verifica essa hipótese em vez de declarar imediatamente uma falha da aplicação ou do agente. Mantém em paralelo a resposta ao incidente, usando sinais independentes quando forem atuais e adequados.
3. Alinhar streams e âmbito em Kubernetes
Em AKS, diferentes dados têm diferentes caminhos de recolha. Quando passas para high scale em ContainerLogV2, revê a configuração do modo e dos streams. Manter simultaneamente o stream normal e o de high scale pode duplicar registos. Isso afeta custo e interpretação, não apenas apresentação. Não resolvas o problema dividindo todas as contagens por dois: confirma primeiro quais conjuntos foram duplicados, durante que período e com que configurações. Da mesma forma, filtros por namespace não têm efeito uniforme sobre qualquer tabela ou métrica; um nó não é um objeto limitado a um namespace. Entrega à equipa de suporte a lista de fontes e exclusões que realmente se aplica. Uma ausência esperada por filtragem e uma ausência inesperada por falha de recolha exigem respostas diferentes.
4. Avaliar o que se perde ao filtrar
Reduzir volume pode ser uma decisão legítima de custo, mas deve partir do valor operacional dos eventos. Uma transformação de ingestão atua antes do armazenamento no workspace. Se elimina uma classe de eventos, aumentar mais tarde a retenção não recupera os que nunca foram conservados, salvo se existir uma fonte ou cópia recuperável. No exercício, a fonte já rodou os registos e não há outra cópia; a investigação tem de reconhecer essa lacuna. Antes de alterar filtros, experimenta-os com uma amostra representativa e identifica perguntas de diagnóstico que deixariam de ser respondidas. Regista data, responsável, âmbito e expectativa de custo da mudança. Mantém a decisão ligada ao risco: eliminar ruído repetitivo não é automaticamente equivalente a eliminar eventos necessários para reconstruir um incidente.
5. Distinguir tempo do evento e tempo da observação
Uma amostra pode chegar tarde sem ter sido gerada tarde. TimeGenerated representa o instante de criação indicado na origem, enquanto receção e ingestão descrevem etapas posteriores. No exemplo, 10:00, 10:07 e 10:08 permitem separar sete minutos até receção e mais um até ingestão. Não chames a estes oito minutos duração da transação da aplicação: faltam os timestamps da transação. Confirma também se houve ajuste do timestamp e que coluna filtra a consulta. Se o dashboard usa o tempo do evento, dados recém-ingeridos podem aparecer numa janela anterior. Ao investigar atrasos, conserva o contexto do relógio, o recurso e o intervalo analisado. Uma diferença temporal indica onde procurar; não prova por si só que rede, agente ou processamento seja a causa única. Em equipas com fusos horários diferentes, regista a referência temporal acordada na cronologia do incidente, para que todas as comparações usem os mesmos instantes.
6. Consultar histórico segundo o plano e a retenção
Retenção analítica e retenção total não são períodos que se somam. Numa tabela Analytics com 30 dias analíticos e 180 totais, registos retidos de há 90 dias podem exigir recuperação por search job em vez da consulta habitual. Confirma primeiro que foram ingeridos e continuam retidos, bem como o plano e a configuração da tabela. Não generalizes o mesmo mecanismo a todos os planos. Esta distinção é importante numa investigação posterior à migração: não encontrar uma linha numa vista não demonstra que foi eliminada, mas também não permite prometer que existe noutro local. Define antecipadamente o tempo aceitável para recuperar histórico e o custo operacional dessa recuperação. O requisito de auditoria ou diagnóstico deve ser traduzido num procedimento ensaiado e num responsável, não apenas num número de dias.
7. Preservar identidade e população das métricas
Application map usa cloud role name para identificar componentes. Duas aplicações com o mesmo valor podem aparecer agrupadas; isso não prova que sejam o mesmo processo nem que uma seja redundante. Mantém identidade estável por componente e usa informação de instância para investigar diferenças entre réplicas. Preserva também a população dos cálculos. Com valores 80, NULL e NULL, só existe uma medição válida: a média é 80, com cobertura incompleta. Substituir ausência por zero fabricaria duas medições e produziria cerca de 26,7. Não interpretes essa descida artificial como melhoria. Em relatórios para gestão, mostra a atualidade e a cobertura juntamente com o valor, sobretudo quando a decisão envolve capacidade, migração ou encerramento de incidente. A qualidade da observação faz parte da interpretação do resultado.
8. Ensaiar o handover com dados explícitos
Os dados abaixo são um exercício original, não uma extração de Azure. Calcula os intervalos e a média, identifica o dashboard desatualizado e propõe a próxima verificação. A solução deve separar o estado conhecido daquilo que ainda é hipótese. A DCR alterada pode explicar a perda de visibilidade, mas não está demonstrado que cause os erros do serviço. Depois, planeia um alerta controlado e acompanha a notificação até ao responsável e ao procedimento de diagnóstico. Regista origem, destino, dimensões, frequência, consultas e limites. Se faltarem sinais críticos, mantém a aceitação pendente ou usa uma alternativa explicitamente validada. O resumo para RUN deve explicar o que fazer quando chegam dados antigos, quando faltam dados e quando os dados atuais mostram uma falha real.
{
"fictional": true,
"record": {
"TimeGenerated": "2026-10-05T10:00:00Z",
"TimeReceived": "2026-10-05T10:07:00Z",
"IngestionTime": "2026-10-05T10:08:00Z",
"timestampAdjusted": false
},
"metricPositions": [
80,
null,
null
],
"dashboard": {
"lastSample": "2026-10-05T10:00:00Z",
"now": "2026-10-05T10:20:00Z",
"expectedFreshnessMinutes": 5
}
}Após migração, o gráfico conserva uma amostra de há vinte minutos enquanto o serviço reporta erros. O caso exige recuperar visibilidade e continuar a investigação do incidente.
Armadilhas comuns
Confundir agente instalado com recolha completa; duplicar streams; tentar recuperar dados descartados só com retenção; usar média com zeros inventados; confundir mapa com arquitetura comprovada.
Tópicos relacionados: DCR e gestão de configuração · Diagnóstico de incidentes e frescura de dados · Retenção e recuperação de histórico · Alertas e passagem para operação
Verifica identidade, cobertura e tempo antes de interpretar um valor. Um sinal operacional útil chega ao destino certo, representa o instante relevante e permite uma resposta demonstrável.
Referência: Enable VM monitoring in Azure Monitor · AZ-400 objectives 2026-07-27