Ressourcen · 113

Erfassungsausfall: Logs und fehlende Ereignisse abgleichen

Erzeugte, empfangene und nutzbare Ereignisse trennen, statt Stille als Vorfallsfreiheit zu deuten.

Aktualisiert · 2 min

Wozu dieser Leitfaden beiträgt

  • Beobachtbare Referenz festlegen
  • Kontrollierte Unterbrechung üben
  • IDs vergleichen und Unbekanntes benennen

Kurzcheck

  • Referenzfolge und Abgleichschema.
  • Ausfallchronik und Grenzverhalten.
  • Abweichungsliste und expliziter Abdeckungsstatus.

Schritt-für-Schritt-Anleitung

  1. 1

    Beobachtbare Referenz festlegen

    Erfasse Anwendung, Collector und Speicher mit Verantwortlichen. Bereite eine endliche fiktive Ereignisfolge mit stabilen IDs ohne Geheimnisse oder Kundendaten vor. Behalte Ereignis- und Beobachtungszeit: Verzögerung bedeutet nicht automatisch Verlust.

    Referenzfolge und Abgleichschema.

  2. 2

    Kontrollierte Unterbrechung üben

    Unterbrich im Test das Ziel und stelle es wieder her. Beobachte Warteschlange, Wiederholungen, Ablehnungen und Neustart. Persistente Queues können Verluste begrenzen, bleiben aber begrenzt und speicherabhängig; definiere Verhalten bei voller Queue. Prüfe, dass Erfassung den Dienst nicht still blockiert.

    Ausfallchronik und Grenzverhalten.

  3. 3

    IDs vergleichen und Unbekanntes benennen

    Gleiche Referenz und tatsächlich lesbare Ereignisse am selben Stichtag ab. Zähle Wiederholungen, Verspätungen und Lücken getrennt; Netzbestätigung beweist keine endgültige Nutzbarkeit. Ohne verlässliche Referenz ist Abdeckung unbekannt statt null Verluste oder null Vorfälle.

    Abweichungsliste und expliziter Abdeckungsstatus.

Nachvollziehbarer Abnahmefall

Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.

Falldaten anzeigen
{
    "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"
}

Erwartete Entscheidung

Fiktives Beispiel: Erwartet sind E1, E2 und E3, empfangen werden E1, E1 und E3. Drei Zeilen beweisen keine Vollständigkeit: E1 wiederholt sich, E2 fehlt am Stichtag.

OpenTelemetry — Collector resiliency

Ihr Abnahmeprotokoll

Erfassen Sie Beobachtungen zu den Kriterien dieses Leitfadens. Ein Protokoll ist keine Zertifizierung.

Keine automatische Speicherung. Vor dem Verlassen exportieren.

Managementindikatoren

IndikatorWas es misstErste Aktion
Bekannte fehlende EreignisseErwartete IDs fehlen am ZielGleiche Referenz und Beobachtungsgrenze
Empfangene WiederholungenZeilen − eindeutige IDsMisst keine unbekannten Verluste

Häufige Fallstricke

    Häufig gestellte Fragen

    Beweisen drei empfangene Zeilen drei gespeicherte Ereignisse?

    Nein. Zwei Zeilen können dieselbe ID wiederholen und eine Lücke verdecken. Vergleiche IDs, Beobachtungsfenster und Kettenstufen.

    Offizielle Referenzen

    Die Referenzen unterstützen die Methode. Passen Sie die Prüfungen an Ihren Kontext an; sie stellen keine Zertifizierung dar. Originalreferenztitel und Quelldokumente können in einer anderen Sprache verfasst sein.

    Referenzen geprüft am .