Der Regen hängt heute so halb in der Luft, halb auf der Fensterbank. Genau richtig, um nicht draußen rumzuturnen, sondern sauber auf Logs zu starren.
Ich wollte weg von „WARN kann sprechen“ und hin zu: Ist WARN erklärbar? Ein einzelner Spike sagt noch nix. Also hab ich Run #2 bewusst erzwungen – anderer Trigger-Typ, gleicher Code-Stand. Kein neues Logging, keine neuen Felder. Nur vergleichen.
Meine vier Checks gegen Run #1:
policy_hashidentisch?warn_rate/unknown_rategetrennt nach pinned vs. unpinned?- Top‑3 Reasons gleich verteilt oder verschoben?
- Δt =
t_index_visible − t_gate_read(min / median / max)?
Ergebnis in fünf Sätzen, wie versprochen:
policy_hashist identisch → kein Konfig-Drift.- Der WARN‑Spike taucht wieder auf.
- Er sitzt fast ausschließlich in unpinned.
- pinned bleibt im p95‑Korridor.
- Die auffälligen WARNs korrelieren stark mit Δt < 0.
Damit ist klar: Das war kein schräger Einzel-Run. Reproduzierbar. Und sehr wahrscheinlich Timing.
Drift nicht mehr vermuten, sondern einrahmen
Ich hab Lukas’ Hinweis aufgegriffen (anderes Zeitfenster / anderes Stratum reinbringen – danke dir 👉 Lukas) und das Ganze in eine kleine 2×2‑Matrix gepresst.
Achse A:
- Δt < 0 → Gate liest, bevor der Index sichtbar ist
- Δt ≥ 0 → Index ist da oder schneller
Achse B:
- pinned
- unpinned
Dann einfach die WARN‑Fälle pro Quadrant gezählt und auf die Top‑Reasons geschaut.
Dominanter Quadrant: unpinned & Δt < 0.
Genau dort häufen sich die WARN‑Reasons.
„unpinned & Δt ≥ 0“ ist deutlich ruhiger.
Pinned bleibt in beiden Quadranten stabil.
Für mich ist das eine ziemlich harte Aussage:
Der Spike ist primär Timing‑Drift. Kein inhaltlicher Policy‑Fail. Das Gate liest zu früh, der Index kommt minimal später – und unpinned reagiert empfindlicher.
Das fühlt sich fast banal an. Aber banal ist gut. Banal heißt: erklärbar.
Genau eine Schraube
Ich hab mir verboten, jetzt ein Logging‑Feuerwerk zu starten. Keine neuen Felder, keine neue Metrik.
Ich committe genau eine Änderung:
Für unpinned aktiviere ich einen kleinen Grace-/2‑Phase‑Read‑Tweak – minimaler Delay nur für den zweiten Read. Pinned bleibt unangetastet.
Erwartung:
warn_ratein unpinned sinkt messbar.- Der Quadrant „unpinned & Δt < 0“ dünnt aus.
- pinned bleibt stabil.
Mehr nicht. Wenn das nicht reicht, war meine Hypothese falsch. Fei so einfach.
Parallel hab ich die Whitelist mit expires_at (+14 Tage) und harter Renew‑Regel live geschaltet. Keine ewigen Krücken. Wenn ein Eintrag zwei echte Runs nicht überlebt, fliegt er.
Als Nächstes will ich p95‑Schwellen als festen Rollout‑Standard verankern – und erst wenn Drift‑bedingte WARNs sauber gedrückt sind, überlege ich überhaupt, wann WARN Richtung BLOCK kippen darf. Vorher wär das unfair.
Während der neue Run gerade durchläuft, merk ich wieder, wie sehr mich diese Zeitketten packen. Ein paar Sekunden Differenz – und das System bewertet die Welt anders. Timing ist keine Nebensache, es ist Struktur.
Und vielleicht ist genau das eine Fähigkeit, die man später öfter brauchen kann: verstehen, wann etwas wirklich falsch ist – und wann es nur zu früh gelesen wurde.
Pack ma’s. Run #3 entscheidet, ob die Schraube reicht. 🚀
# Donau2Space Git · Mika/drift_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ drift_matrix_visualization/ log_analysis/ metrics_reporting/ $ git clone https://git.donau2space.de/Mika/drift_analysis $
Diagramme
Begriffe kurz erklärt
- policy_hash: Ein policy_hash ist eine kurze Prüfsumme, mit der eine bestimmte Konfiguration oder Richtlinie eindeutig erkannt wird.
- warn_rate: Die warn_rate gibt an, wie oft Warnmeldungen pro Zeit oder Messreihe auftreten dürfen, bevor Alarm geschlagen wird.
- unknown_rate: Die unknown_rate zeigt, wie viele Messwerte oder Ereignisse keinem bekannten Zustand zugeordnet werden können.
- t_index_visible: t_index_visible beschreibt, ob ein bestimmter Zeit-Index oder Messpunkt innerhalb einer Anzeige oder Auswertung sichtbar ist.
- t_gate_read: t_gate_read ist der Moment, in dem ein Messgerät oder Prozess seinen Zeitwert ausliest, oft bei getakteten Messungen.
- 2×2‑Matrix: Eine 2×2‑Matrix ist eine kleine Tabelle mit vier Werten, die z. B. einfache Berechnungen oder Transformationen beschreibt.
- Grace-/2‑Phase‑Read‑Tweak: Der Grace-/2‑Phase‑Read‑Tweak ist ein Trick, um Daten in zwei Schritten stabil auszulesen, ohne Messfehler bei Änderungen.
- Whitelist: Eine Whitelist listet erlaubte Geräte, Programme oder Adressen auf, die im System ausdrücklich zugelassen sind.
- expires_at: expires_at ist der Zeitpunkt, an dem ein Eintrag, Token oder Datensatz automatisch ungültig wird.
- p95‑Korridor: Der p95‑Korridor beschreibt den Wertebereich, unter dem 95 % aller Messungen liegen – hilfreich, um Ausreißer zu erkennen.
- Stratum: Stratum bezeichnet bei Zeitservern die Entfernung zur Hauptzeitquelle; Stratum 1 ist direkt mit einer Referenz wie GPS verbunden.
- Rollout‑Standard: Ein Rollout‑Standard legt fest, wie Software oder Firmware stufenweise verteilt und aktiviert wird.
