APRENDER. PRATICAR. EVOLUIR.1. Começar pela pergunta que o suporte precisa de responder
Numa aplicação fictícia de fundos, saber quem alterou uma configuração é diferente de saber porque falhou uma leitura de dados. O Activity Log regista operações de gestão; os resource logs e a telemetria da aplicação dão outras perspetivas. Não peças ao suporte que encontre todas as falhas num único tipo de registo. Define perguntas concretas: a alteração foi aplicada, que dependência recusou acesso, que operação de negócio ficou pendente? Associa cada pergunta a uma origem, identificador de correlação e destino. Uma entrada de deployment bem-sucedido não demonstra que a aplicação processou a primeira instrução. No desenho, inclui o que não fica registado por defeito e como será gerado um evento representativo para validar a recolha antes do handover.
2. Distinguir recursos criados de recolha em funcionamento
Um workspace criado e um agente instalado não provam que os registos necessários estão a chegar. Diagnostic settings escolhem categorias e destinos de logs de recursos. Para recolha pelo Azure Monitor Agent, as data collection rules e as associações relevantes definem o que deve ser recolhido e para onde segue. No exemplo fictício, o host envia métricas de plataforma, mas nenhum evento do sistema operativo aparece: verifica o percurso do agente, regra, associação e destino, sem concluir que a VM está saudável por falta de erros visíveis. Algumas tabelas só aparecem depois da primeira ingestão. O critério de aceitação deve incluir o evento gerado, o registo observado e o atraso medido. Um dashboard vazio pode representar ausência de atividade, atraso ou falha de recolha.
3. Transformar dados sem perder a evidência necessária
Uma transformação de ingestão pode filtrar ou remodelar dados nos percursos e tabelas suportados. É útil para retirar campos desnecessários, mas um filtro que remove todos os sucessos também pode retirar o denominador de uma taxa de falha. Se a equipa calcula dez erros sobre cem operações, precisa de conservar uma forma fiável de conhecer o total, mesmo que reduza detalhe dos sucessos. Não trates uma query do dashboard como equivalente a remover dados antes de armazenamento: são pontos diferentes do percurso. Prepara amostras com sucesso, erro, campos ausentes e identificadores fictícios. Compara o resultado antes e depois da transformação, confirma a utilidade para diagnóstico e verifica que não se perdeu a ligação necessária entre componentes. A transformação não deve ser aprovada apenas pela redução de volume.
4. Escolher plano e retenção a partir do uso
O plano de uma tabela afeta as capacidades disponíveis e o custo de ingestão e consulta. Dados usados continuamente por alertas não têm o mesmo perfil que registos volumosos consultados apenas numa investigação ocasional. Antes de mudar de Analytics para um plano mais económico, inventaria queries, alertas, summary rules e utilizadores. A documentação atual identifica limitações específicas, incluindo alertas que deixam de funcionar numa mudança para Auxiliary ou Lake. A mudança também não deve ser tratada como eliminação automática de dados anteriores: confirma como se acede a cada período e a retenção aplicada. Num projeto internacional, separa a decisão de residência de dados da organização de dashboards. Um dashboard por país não muda a localização de armazenamento de um workspace comum.
5. Separar deteção, notificação e resposta
Uma alert rule deteta uma condição; uma alert processing rule pode alterar as ações aplicadas a alertas já disparados. Durante manutenção, pode ser adequado suprimir notificações num âmbito e horário limitados, mantendo evidência das condições observadas. Desativar a regra de deteção tem outro efeito e pode esconder falhas em recursos fora da manutenção se partilharem a mesma regra. Define o owner da janela, o fuso horário, o conjunto de recursos e a forma de confirmar o regresso das notificações. A receção de um email também não prova que alguém assumiu o incidente. O handover deve ligar sinal, severidade, destino de notificação, responsabilidade e procedimento de resposta. O modelo local distingue ausência de dados, ausência de tráfego, condição detetada e notificação suprimida.
6. Evitar poupanças que criam períodos sem observação
O daily cap pode travar ingestão elegível depois de atingir um limiar, mas não é um limite de faturação exato nem um filtro de rotina sem consequências. A paragem pode retirar dados aos alertas e ao diagnóstico precisamente durante um pico de incidentes. O modelo de custo deve considerar tabelas e planos abrangidos, possíveis excessos, retomada e monitorização do próprio limite. No caso fictício, a equipa reduz o cap e o dashboard passa a mostrar zero erros à tarde. Antes de comunicar melhoria de disponibilidade, confirma se houve recolha e volume de operações. Planeia redução seletiva de detalhe com amostras e validação, acompanhada de avisos antes de atingir o limite. O resultado pretendido é controlar custo mantendo as decisões operacionais e a evidência acordadas.
def assess(total, errors, complete, notify):
if total < 0 or errors < 0 or errors > total:
raise ValueError("invalid fictional counts")
if not complete:
return ("unknown", False)
if total == 0:
return ("no-traffic", False)
fired = errors / total >= 0.05 # fictional threshold, not an Azure rule
return ("fired" if fired else "clear", fired and notify)
assert assess(0, 0, False, True) == ("unknown", False)
assert assess(0, 0, True, True) == ("no-traffic", False)
assert assess(100, 10, True, True) == ("fired", True)
assert assess(100, 10, True, False) == ("fired", False)
assert assess(100, 1, True, True) == ("clear", False)
assert assess(100, 10, False, True) == ("unknown", False)
print("six fictional signal checks passed; no Azure alert evaluated")
Caso fictício: depois de reduzir ingestão, desaparecem os sucessos e a taxa de erro torna-se enganadora. O owner mantém contagens agregadas fiáveis, reduz detalhe selecionado e testa novamente o alerta e a notificação.
Armadilhas comuns
Confundir workspace com recolha; interpretar silêncio como saúde; remover denominadores de métricas; confundir supressão de notificações com ausência de alertas.
Tópicos relacionados: SLA e indicadores operacionais · FinOps e retenção · Transição para RUN
Observabilidade exige dados utilizáveis, deteção correta e uma resposta com owner, inclusive durante mudanças de custo e manutenção.
Referência: Diagnostic settings in Azure Monitor · AZ-305 objectives 2026-04-17