Zusammenfassung

  • TraceError kann einen fehlgeschlagenen Versuch dokumentieren, eine Datei für ein aggregiertes qlog zu finden oder zu konvertieren; es beschreibt genau diesen Versuch.
  • Weder das Vorhandensein noch das Fehlen eines solchen Objekts beweist, dass alle erwarteten Quellen, Capture-Fenster und Ereignisse erfasst wurden.
  • Für belastbare Akten braucht der Betrieb ein unabhängiges Soll-Inventar, Zähler über jede Verarbeitungsstufe und eine Trennung zwischen Formatfehler, fehlender Evidenz und Serviceergebnis.

Die aggregierte qlog-Datei enthielt neun Traces und einen TraceError. Der Fehler nannte den Pfad einer Client-Datei, die bei der Zusammenführung nicht gefunden worden war. Der Review lobte die Transparenz und setzte einen grünen Haken hinter „Vollständigkeit“: Ein Eingang sei ausgefallen, alle übrigen seien erfolgreich verarbeitet worden.

Belegt war der ausgefallene Versuch. Nicht belegt war, wie viele Eingänge überhaupt erwartet wurden.

draft-ietf-quic-qlog-main-schema-14 ist ein aktiver Internet-Draft der QUIC Working Group vom Juli 2026, vorgesehen für Proposed Standard und noch kein RFC. Er beschreibt eine gemeinsame Struktur für Protokoll-Logs: Dateien, Traces, Ereignisse, Schemas, Zeitangaben und Erweiterungen. Ein normales QlogFile kann mehrere Traces oder Fehlerobjekte in einem Aggregat enthalten. TraceError verhindert, dass ein bekannter Such- oder Konvertierungsfehler zwangsläufig lautlos verschwindet.

Das ist gute Provenienz. Gerade deshalb muss ihr Geltungsbereich präzise bleiben.

Ein Fehlerobjekt hat einen benannten Auslöser

Der Entwurf definiert TraceError für den Fall, dass versucht wurde, eine Datei zur Aufnahme in ein aggregiertes qlog zu finden oder zu konvertieren, und dabei ein Fehler auftrat. Das Objekt enthält eine Fehlerbeschreibung und kann URI sowie Vantage Point nennen.

Damit lässt sich sagen: „Dieser konkrete Aufnahmeversuch scheiterte und wurde als Fehler vermerkt.“ Das Objekt sagt nicht: „Jede Quelle, die hätte existieren können, wurde zuvor in einer vollständigen Liste erfasst.“ Es sagt auch nicht, dass innerhalb der erfolgreich konvertierten Traces alle Ereignisse erhalten blieben.

Die Unterscheidung entspricht einer einfachen Kontrollfrage: Was ist der Nenner? Ein Fehlerzähler von eins ist nur dann eine Quote, wenn eine unabhängige Soll-Liste zehn erwartete Eingänge ausweist. Wird der Nenner erst aus neun Traces plus einem Fehler rekonstruiert, bestätigt die Ausgabe sich selbst. Eine nie registrierte elfte Quelle bleibt unsichtbar.

Erfolgreiche Konvertierung ist eine andere Kontrolle

Eine Quelldatei kann gefunden und syntaktisch korrekt konvertiert werden, während ihr Inhalt unvollständig ist. Ein fester Ringpuffer kann frühe Verbindungsereignisse durch neuere überschreiben. Ereignisse können aus Datenschutz- oder Größengründen absichtlich fehlen. Selbst Core-Ereignisse müssen nicht in jedem Trace vollständig vorhanden sein.

Auch event_schemas ist keine Inventarliste. Die URI-Liste gibt Werkzeugen Hinweise auf mögliche Namespaces und Typen. Ein Trace darf Typen aus nicht gelisteten Schemas enthalten; umgekehrt garantiert ein gelistetes Schema nicht, dass alle zugehörigen Typen protokolliert wurden. Werkzeuge dürfen beides nicht als Fehler behandeln.

Ein erfolgreicher Import beweist somit die Verarbeitbarkeit der vorhandenen Quelle. Er beweist weder den rechtzeitigen Beginn der Erfassung noch die Vollständigkeit ihres Puffers noch die Gleichheit ihres Capture-Profils mit anderen Quellen.

Die Akte braucht ein Soll außerhalb der Akte

Wer qlog in Incident Response, Audit oder Lieferantenkontrolle verwendet, sollte vor der Erfassung ein Manifest anlegen. Darin stehen die erwarteten Vantage Points, Verbindungen oder Gruppen, Capture-Fenster, Logger- und Schema-Versionen, Dateipfade oder Stream-Identitäten, Datenschutzprofile und erwarteten Übergaben. Jede Verarbeitungsstufe quittiert, was sie erhalten, verworfen, konvertiert und ausgegeben hat.

Dann bekommt TraceError seinen richtigen Platz. Es ist eine Ist-Quittung gegen einen Soll-Eintrag. Fehlt eine erwartete Quelle ohne Trace und ohne Fehler, entsteht eine eigene Abweichung: „nicht bilanziert“. Ist ein Trace vorhanden, aber sein Ringpuffer überlief, lautet der Status: „verarbeitet, historisch begrenzt“. Wurden Rohwerte reduziert, lautet er: „inhaltlich minimiert“.

Dieses Manifest ist Daniel Kades Betriebsempfehlung, keine zusätzliche qlog-Pflicht. Es ergänzt den Standard dort, wo eine Organisation aus interoperablen Logs eine beweisfähige Akte machen möchte.

Zeitfehler passen nicht in ein einziges Importergebnis

Selbst eine vollständig bilanzierte Quellmenge ergibt noch keine globale Chronologie. qlog erlaubt System- und monotone Uhren. Systemzeit kann springen; monotone Zeit besitzt keine bekannte Kalenderepoche. Ein approximativer wall_clock_time darf nicht als sichere Kalenderumrechnung behandelt werden. Ereignisse können relativ zur Epoche oder zum vorigen protokollierten Ereignis notiert sein, sogar mit unterschiedlichen Formaten in einem Trace.

Der Entwurf warnt davor, Zeitstempel verschiedener Traces als konsistent anzunehmen. Vantage Point und Flussrichtung sind ebenfalls entscheidend. Ein Client-, Server- und Netzwerk-Trace können jeweils korrekt und dennoch nicht exakt ausgerichtet sein.

Darum sollte die Aggregation drei Resultate getrennt ausgeben: strukturelle Verarbeitung, Evidenzabdeckung und zeitliche Korrelation. „Import erfolgreich“ darf nicht bedeuten „vollständige und kausal geordnete Episode“.

Auch der Inhalt kann bewusst kleiner sein

RawInfo kann Längen behalten, während rohe Bytes fehlen oder gekürzt sind. Das ist für Datenschutz und Dateigröße nützlich. Die Länge beweist dann eine Länge, nicht den Inhalt. Ein optionaler trigger kann die Ursache eines Ereignisses näher beschreiben; fehlt er, ersetzt zeitliche Nähe keine Ursache.

Diese Unterschiede gehören in den Aktenstatus. Ein Trace kann formal vollständig verarbeitet, aber für die konkrete Frage nicht ausreichend sein. qlog-Werkzeuge sollen klar melden, wenn genügend unterstützte Information für ihre Logik fehlt. Diese Meldung ist professioneller als ein Ergebnis, das seine Unsicherheit verbirgt.

Von grünen Haken zu begrenzten Aussagen

Für den Ausgangsfall wäre die belastbare Zusammenfassung: „Zehn Inputs wurden vom Aggregator bilanziert; neun Traces wurden verarbeitet, ein benannter Suchversuch schlug fehl. Ob weitere Inputs erwartet waren, lässt sich ohne externes Manifest nicht feststellen. Die Ereignisabdeckung der neun Traces wurde separat bewertet.“

Diese Formulierung trennt vier Fragen: Wurde eine Quelle erwartet? Kam sie an? War sie lesbar? Enthielt sie genug Evidenz für die These? Erst danach folgt die fünfte: Bestätigt eine Anwendungsmessung den behaupteten Serviceeffekt?

Ein einziges Häkchen über alle fünf Fragen spart Platz und vernichtet Steuerbarkeit. Wenn später eine Quelle auftaucht, kann niemand sagen, ob das frühere Ergebnis falsch war oder nur einen engeren Geltungsbereich hatte. Getrennte Quittungen lassen die Schlussfolgerung wachsen, ohne ihre Vergangenheit umzuschreiben.

TraceError ist deshalb kein schwaches Instrument. Es ist stark, solange es genau das bezeugt, wofür es definiert wurde. Die Führungsaufgabe besteht darin, den Wunsch nach einer vollständigen Akte nicht in die Semantik eines lokalen Fehlerobjekts hineinzulesen.

Quellen