Recursos · 113

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.

Atualizado · 2 min

O que este guia ajuda a alcançar

  • Definir referência observável
  • Exercitar interrupção controlada
  • Comparar identificadores e declarar desconhecidos

Verificação rápida

  • Sequência de referência e esquema de reconciliação.
  • Cronologia da falha e comportamento nos limites.
  • Lista de diferenças e estado de cobertura.

Método passo a passo

  1. 1

    Definir referência observável

    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.

    Sequência de referência e esquema de reconciliação.

  2. 2

    Exercitar interrupção controlada

    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.

    Cronologia da falha e comportamento nos limites.

  3. 3

    Comparar identificadores e declarar desconhecidos

    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.

    Lista de diferenças e estado de cobertura.

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.

OpenTelemetry — Collector resiliency

O seu caderno de aceitação

Registe observações sobre os critérios deste guia. Um registo não é uma certificação.

O caderno não guarda automaticamente. Exporte antes de sair.

Indicadores de gestão

IndicadorO que medePrimeira ação
Faltas conhecidasIdentificadores esperados ausentes no destinoMesma referência e corte
Repetições recebidasLinhas − identificadores únicosNão mede perdas desconhecidas

Erros comuns

    Perguntas frequentes

    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.

    Referências oficiais

    As referências apoiam o método. Adapte as verificações ao seu contexto; elas não são uma certificação. Os títulos das referências originais e os documentos de origem podem estar em outro idioma.

    Referências consultadas em .