Escolher o sinal conforme a pergunta
OpenTelemetry distingue métricas, registos e traces, entre outros sinais. Complementam-se sem garantir cobertura completa. Documente período, instrumentação e exclusões; uma média pode esconder pedidos lentos.
| Pergunta | Sinal útil | Limite |
|---|---|---|
| Quantos pedidos falham? | Métricas agregadas | Definir falhas, âmbito e período. |
| Onde se gastou tempo? | Trace e duração das etapas | Amostragem e dependências sem instrumentação. |
| Que evento ocorreu? | Registo estruturado | Sem segredos nem dados excessivos. |
| O percurso funciona? | Sonda funcional | Um cenário não cobre todos os usos. |
Tornar o diagnóstico acionável
- Meça tráfego, erros e distribuição de durações por operação normalizada. Evite identificadores de utilizadores e URL variáveis como etiquetas de métricas.
- Ligue eventos a identificador de correlação e versão do serviço. Verifique propagação de contexto e amostragem antes de procurar um trace ausente.
- Associe a cada alerta impacto, responsável e primeira ação. Use contas próprias para sondas e evite operações irreversíveis.
Proteger dados e verificar resultados
Exclua palavras-passe, tokens e corpos sensíveis dos registos; limite acesso e conservação. Um sucesso HTTP pode conter um resultado funcional errado. Verifique invariantes e permissões num ambiente controlado.
Fontes primárias
Conecte a telemetria a uma tarefa do usuário
Métricas, logs e rastreamentos respondem a perguntas diferentes. Um alto tempo de atividade pode ocultar uma falha no processo de finalização da compra ou login. Defina o resultado que os usuários esperam e, em seguida, monitore as chamadas que o entregam.
- Escolha um indicador de jornada para sucesso, latência e falha visível ao usuário.
- Propague a correlação entre os serviços, limitando os dados confidenciais nos rastreamentos.
- Simule uma falha de dependência para verificar se os alertas levam a ações e a um modo degradado compreensível.
Fonte primária: OpenTelemetry — Observability primer. Método relacionado: consultar o guia prático.
Falha de recolha: reconciliar registos e eventos em falta
Distinguir eventos produzidos, recebidos e utilizáveis sem interpretar silêncio como ausência de incidentes.
- Mapeie aplicação, coletor e armazenamento com responsáveis. Prepare sequência finita de eventos fictícios com identificadores estáveis, sem segredos nem dados de clientes. Guarde tempos de evento e observação: atraso não significa automaticamente perda.
- Em teste interrompa o destino e restabeleça-o. Observe fila, tentativas, rejeições e reinício. Uma fila persistente pode limitar perdas, mas é limitada e depende do armazenamento; defina o comportamento quando cheia. Verifique que a recolha não bloqueia silenciosamente o serviço.
- Reconcilie a referência com eventos legíveis no mesmo instante de corte. Conte repetições, atrasos e ausências separadamente; confirmação de rede não prova utilização final. Sem referência fiável, declare cobertura desconhecida, não zero perdas ou incidentes.
Caso de aceitação reproduzível
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Ver dados do caso
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}Decisão esperada
Exemplo fictício: esperam-se E1, E2 e E3, mas chegam E1, E1 e E3. Três linhas não provam completude: E1 repete-se e E2 falta no corte.
Três linhas recebidas provam três eventos guardados?
Não. Duas linhas podem repetir o identificador e ocultar uma ausência. Compare identificadores, janela observada e etapas da cadeia.
Fonte primária: OpenTelemetry — Collector resiliency. Método relacionado: consultar o guia prático.
Subdomínios abandonados: retirar um CNAME com controlo
Associar nomes DNS a recursos controlados e encerrar dependências antes de libertar o serviço.
- Registe nome, cadeia CNAME, recurso do fornecedor e responsável. Compare DNS com o inventário da conta autorizada. Erros HTTP, NXDOMAIN ou recursos ausentes exigem análise, mas não provam possibilidade de apropriação; as proteções variam.
- Remova o apontamento ou use um destino controlado antes de libertar o recurso. Considere TTL anteriores e caches; verifique DNS autoritativo e vários resolvedores. Preserve validações de propriedade necessárias em vez de apagar todos os TXT.
- Reveja ligações, redirecionamentos, callbacks OAuth, webhooks e domínios de cookies. Se o recurso já foi libertado, corrija DNS e investigue exposição pelo processo de incidentes. Reconcilie DNS e recursos após cada remoção.
Caso de aceitação reproduzível
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Ver dados do caso
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Decisão esperada
Exemplo fictício: portal.example aponta para um recurso eliminado. Remova o CNAME ou use um destino controlado; a ausência não prova apropriação por terceiros.
Fonte primária: Microsoft — Prevent dangling DNS entries. Método relacionado: consultar o guia prático.
Tentativas API: contar o orçamento completo de tempo
Separe chamadas, esperas e percurso completo.
Caso pedagógico fictício: os números não representam a CIE nem clientes.
Modelo fictício: quatro chamadas até 250 ms e esperas de 100, 200 e 400 ms. Exclui jitter, ligação, filas e validação local.
- Tentativas totais
- 41 + 3
- Esperas acumuladas (ms)
- 700100 + 200 + 400
- Orçamento modelado (ms)
- 17004 × 250 + 700
| Passo | Chamada máxima (ms) | Espera seguinte (ms) |
|---|---|---|
| Tentativa 1 | 250 | 100 |
| Tentativa 2 | 250 | 200 |
| Tentativa 3 | 250 | 400 |
| Tentativa 4 | 250 | 0 |
| Total | 1000 | 700 |
- Tempo das chamadas1.000
- Esperas acumuladas700
- Prazo global (ms)1.500
Verificações antes de concluir
- 1.000 + 700 = 1.700 ms excede o prazo de 1.500 ms.
- Propague o prazo global e evite efeitos duplicados; timeout não prova cancelamento remoto.
Experimentar um orçamento de tentativas
n × T + W × (2^(n−1) − 1)
Método relacionado: consultar o guia prático.
Referências: dados, usos e limites
Documentação consultada em .
As notas detalhadas desta edição estão disponíveis em inglês.
| Fonte e finalidade | Dado ou referência verificada | Como utilizar | Limite a preservar |
|---|---|---|---|
| NIST · SP 800-61 Rev. 3 Prepare incident response within cybersecurity risk management. |
Revision 3 was published in April 2025 and supersedes Revision 2. It is a CSF 2.0 Community Profile. | Rehearse containment decisions, evidence preservation, communication and recovery. Compare planned actions with evidence produced during the exercise. | Reading the guide does not validate a local plan. Contacts, emergency access and dependencies need local testing. |
| Google · Core Web Vitals Distinguish loading, responsiveness and visual stability. |
Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. | Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes. | These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience. |
API: descontinuação e retirada
As notas detalhadas desta edição estão disponíveis em inglês.
Announced retirement and continuity to verify
A Sunset field signals intent; it establishes neither actual shutdown nor guaranteed continuity until then. Prepare dependencies, data and access to move.
- Identify the announcement’s exact scope and owner.
- Keep dates and updates with receipt evidence.
- Test exit, in-flight operations and removal of obsolete access.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23