APRENDER. PRATICAR. EVOLUIR.Começar pela pergunta operacional
Numa plataforma fictícia de processamento de instruções, o negócio pergunta se existiram falhas entre as 09:10 e as 09:25. A equipa tem um dashboard central, mas isso não define o âmbito observado. Escreve a hipótese, as contas, Regiões, serviços e versões relevantes antes de interpretar resultados. Distingue eventos de erro, pedidos e operações de negócio; várias linhas podem pertencer à mesma operação. Regista também o relógio e o campo temporal usado. Uma pesquisa sem linhas pode significar ausência de correspondência, origem não incluída ou ingestão atrasada. O relatório deve dizer o que foi consultado e que lacunas impedem uma afirmação mais ampla.
Verificar as origens partilhadas
OAM permite observar contas ligadas dentro de uma Região. O sink pertence à conta de monitorização e o link à origem; desenha essa direção no inventário do serviço. Se uma conta acumula os papéis de origem e monitorização, não retransmite automaticamente a telemetria das suas próprias origens. Confirma a ligação e os tipos de dados efetivamente partilhados, em vez de inferir cobertura pela presença de um dashboard. No caso da aula, duas contas aparecem e a terceira ficou fora do onboarding. A equipa pode investigar essa conta por acesso autorizado separado enquanto corrige a configuração. Deve identificar essa exceção no relatório e testar a cobertura depois da mudança.
Controlar a consulta e recolher o resultado
Iniciar uma pesquisa devolve uma identidade que deve acompanhar a investigação. Resultados com estado Running são parciais; espera de forma limitada e distingue conclusão, falha e timeout. Mesmo com Complete, verifica paginação e limites antes de chamar ao primeiro conjunto todas as linhas. Restringe grupos e intervalo à pergunta operacional e alarga-os quando a hipótese o exigir. Cada atualização de um widget pode executar outra pesquisa; define uma cadência útil e cancela explicitamente consultas que deixaram de ser necessárias. Guardar o texto, queryId, parâmetros e resultado observado permite explicar uma conclusão sem depender de uma captura visual isolada. Não confundas economia de pesquisa com omissão de fontes relevantes.
Preservar o significado dos dados
Um índice pode acelerar uma pesquisa de igualdade, mas não corrige o significado do predicado. Usa comparação exata quando procuras um identificador completo; um padrão por substring pode incluir outros pedidos e não beneficiar do mesmo índice. Confirma ainda a conta onde a política de indexação foi criada e o momento a partir do qual os eventos foram indexados. Depois de stats, os campos disponíveis são os produzidos pela agregação; aplica filtros de eventos antes de perder esse detalhe. Dedup não transforma linhas sem identidade em operações únicas conhecidas. Se excluíres IDs ausentes, reporta a exclusão. A otimização só é útil quando preserva a população que se pretendia analisar.
Conservar evidência utilizável e protegida
A equipa precisa de investigar sem divulgar desnecessariamente dados sensíveis. Uma política de máscara atua na ingestão e não resolve por si só exposição em eventos antigos. O acesso sem máscara exige avaliação própria; cifragem em repouso e autorização de consulta não são o mesmo controlo. No handover, considera também a chave de logs históricos: desassociá-la afeta novas escritas, mas não remove a dependência dos dados já cifrados. Testa leitura representativa do histórico antes de aceitar uma desativação. Para distribuição contínua, não assumes que tarefas de exportação satisfazem minutos de latência. Define destino, acesso, retenção e evidência de entrega segundo o objetivo operacional e o intervalo de conservação aprovado.
Exercício: delimitar uma conclusão
O modelo local recebe origens esperadas, origens observadas e páginas fictícias de uma consulta. Recusa uma conclusão quando falta uma origem, a pesquisa ainda corre, existe continuação por recolher ou os parâmetros de cobertura são incompletos. Não executa Logs Insights nem prova que a aplicação emitiu todos os eventos necessários. Executa os casos, acrescenta uma terceira origem e explica por que motivo zero erros deixa de ser suficiente. Depois escreve uma nota de passagem de turno com hipótese, período, origens, resultado e limitação residual. Mesmo um resultado completo deve ser confrontado com sintomas e evidência funcional. A conclusão técnica deve ser suficientemente precisa para orientar a próxima decisão sem prometer ausência absoluta de problemas.
# Original local evidence review, not a Logs Insights client or completeness proof.
def review_evidence(expected, observed, pages, scope_recorded):
if not scope_recorded or not expected:
return "scope incomplete"
if expected - observed:
return "source coverage incomplete"
if not pages or any(p["status"] != "Complete" for p in pages):
return "query not complete"
if pages[-1]["next_token"] is not None:
return "results not fully retrieved"
if any(pages[i]["next_token"] != pages[i+1]["request_token"]
for i in range(len(pages)-1)):
return "page chain incomplete"
if pages[0]["request_token"] is not None:
return "first page missing"
return "recorded scope reviewed; emitter completeness still unproven"
expected = {"account-a/eu-west-1", "account-b/eu-west-1"}
page = {"status": "Complete", "request_token": None, "next_token": None}
assert review_evidence(expected, expected, [page], True).startswith("recorded scope")
assert review_evidence(expected, {"account-a/eu-west-1"}, [page], True).startswith("source coverage")
assert review_evidence(expected, expected, [{**page, "status": "Running"}], True) == "query not complete"
assert review_evidence(expected, expected, [{**page, "next_token": "p2"}], True) == "results not fully retrieved"
pages = [{**page, "next_token": "p2"}, {**page, "request_token": "p2"}]
assert review_evidence(expected, expected, pages, True).startswith("recorded scope")
assert review_evidence(expected, expected, [pages[0], {**page, "request_token": "p3"}], True) == "page chain incomplete"
assert review_evidence(expected, expected, [page], False) == "scope incomplete"
Exemplo fictício: a pesquisa central termina sem erros nas contas A e B, mas o serviço também corre em C. O resultado é válido para A e B; a conclusão sobre todo o serviço fica pendente.
Armadilhas comuns
Erros comuns: assumir partilha transitiva, tratar Running como final, ignorar paginação, contar linhas sem identidade como pedidos únicos e desativar uma chave ainda necessária.
Tópicos relacionados: Workflows de recuperação e pré-condições
Uma conclusão forte liga a pergunta operacional às origens observadas, ao resultado completo e aos limites que ainda subsistem.
Referência: DOP-C02 monitoring and logging objectives · DOP-C02