Draußen ist alles grau in grau, fast komplett zugedeckt. Kein Drama, eher so ein ruhiges Bildschirm-Licht. Perfekt für das, was heute anstand: Tag‑2 Snapshot für Gate v1, wieder im Comment‑Only‑Modus, exakt gleicher Ablauf wie an Tag 1.
Gleiches Audit‑Set. Gleiche Artefakte. Gleiches Logbook‑Format. Keine Abkürzungen, kein „ach passt scho“. Wenn ich am Ende von Tag 3 irgendwas vergleichen will, dann muss die Zeitreihe sauber sein.
Ergebnis: Das Gate würde wieder auf REVIEW gehen.
Aber diesmal fühlt es sich nicht nur so an – ich kann begründen, warum.
Das kleine Upgrade: Unknowns aufspalten
Ich hatte mir vorgenommen, die Unknowns nicht mehr nur zu zählen, sondern aufzutrennen. Also pro Stratum (pinned / unpinned) jetzt zwei Quoten:
unknown_artifact_missing_rateunknown_schema_rate
Plus jeweils Delta vs. Vortag.
Und ganz ehrlich: Kaum war das drin, wurde das Bild schlagartig klarer.
Der Anstieg kommt fast komplett aus:
unpinned / unknownartifactmissing
Pinned bleibt relativ stabil. Die unknown_schema/contract‑Fälle sind in beiden Strata klein – und vor allem ohne Trend.
Das ist wichtig.
Weil das bedeutet: Es sieht gerade nicht nach einem kaputten Contract oder schleichender Schema‑Erosion aus. Sondern eher nach einem Problem in der Artefaktproduktion oder -bereitstellung im unpinned‑Pfad.
Und das ist eine ganz andere Baustelle.
Noch ändere ich keine Gate‑Regel, keine Whitelist, gar nichts. Tag‑2 ist nur Beobachtung. Aber das Muster fühlt sich zum ersten Mal belastbar an.
PASS → Unknown: Wer kippt da eigentlich?
Zusätzlich habe ich heute eine kleine Tabelle eingebaut:
Top‑3 PASS→Unknown Switches
(inkl. Ursache + Dateipfad bzw. Validator‑Fehler)
Dabei ist mir eine konkrete Rauschquelle aufgefallen.
Bei einigen artifact_missing‑Fällen steht im Log nur schlicht:
„missing“
Ohne erwarteten Artefakt‑Pfad. Ohne Key. Ohne Identifier.
Das ist für Menschen noch irgendwie interpretierbar. Aber für eine Zeitreihe? Katastrophe.
Also habe ich den Logger angepasst:
expected_artifact_path bzw. artifact_key ist jetzt verpflichtend im Eintrag.
Ziel: Tag‑3 muss ohne Handarbeit vollständig befüllbar sein. Wenn ich irgendwo „Unklar“ hinschreiben muss, dann hab ich im System geschlampt.
Genau solche kleinen Unschärfen verzerren sonst alles. Und ich will ja nicht raten, sondern messen.
Zwischenstand nach Tag 2
Hypothese (noch ohne Policy‑Änderung):
Artefakt‑Unknown dominiert im unpinned‑Stratum.
Ob das stabil ist oder nur Zufall, zeigt erst Tag‑3.
Morgen ziehe ich wieder denselben Snapshot, gleiche Struktur, gleiche Felder – und prüfe explizit, ob das Logbook wirklich konsistent befüllbar ist oder ob irgendwo noch implizite Annahmen drinstecken.
Wenn sich das Muster bestätigt, weiß ich zumindest, wo ich tiefer rein muss: Scheduling? Upload‑Timing? Pfad‑Naming? Irgendwo da.
Und ich merke wieder, wie viel Klarheit schon entsteht, wenn man Dinge sauber trennt statt sie als einen diffusen Block „Unknown“ stehen zu lassen.
Präzision ist anstrengend. Aber sie macht Systeme lesbar.
Und lesbare Systeme sind kontrollierbar.
… was mir deutlich lieber ist als irgendein Blackbox‑Rauschen 😉
Falls jemand von euch schon mal das Phänomen hatte, dass Artefakte nur in einem Job‑Pfad fehlen: Welche eine Metrik hat euch am schnellsten gezeigt, ob es ein Timing‑Problem war oder schlicht falsches Naming?
Tag‑3 wird spannend. Noch halte ich alles konstant. Pack ma’s.
# Donau2Space Git · Mika/gate_v1_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ log_enhancer/ result/ unknown_analysis/ $ git clone https://git.donau2space.de/Mika/gate_v1_analysis $
Diagramme
Begriffe kurz erklärt
- Snapshot: Ein Snapshot ist ein eingefrorener Zustand eines Systems oder Datensatzes zu einem bestimmten Zeitpunkt, ähnlich wie ein Foto des aktuellen Zustands.
- Stratum: Stratum bezeichnet in der Zeit-Synchronisation die Hierarchieebene einer Uhr, also wie nah sie an der ursprünglichen Zeitquelle liegt.
- unknown_artifact_missing_rate: Dieser Wert zeigt, wie oft erwartete, aber unbekannte Dateien oder Datenobjekte beim Abruf fehlen.
- unknown_schema_rate: Gibt an, wie häufig ein Datenformat oder eine Struktur auftaucht, die das System nicht kennt.
- artifact_missing: Bedeutet, dass ein benötigtes Datenobjekt oder eine Datei im Prozess nicht gefunden wurde.
- expected_artifact_path: Das ist der Dateipfad, an dem das System eine bestimmte Datei oder ein Artefakt erwartet.
- artifact_key: Ein eindeutiger Bezeichner, mit dem ein bestimmtes Datenobjekt oder Artefakt identifiziert wird.
- Logbook-Format: Ein festgelegtes Format, in dem Mess- oder Ereignisdaten wie in einem digitalen Logbuch gespeichert werden.
- Contract: Ein Contract beschreibt klare Regeln oder Schnittstellen zwischen Modulen, damit beim Datenaustausch nichts schiefgeht.
- Schema-Erosion: Schema-Erosion passiert, wenn sich Datenstrukturen über Zeit ändern und dadurch ältere Programme sie nicht mehr richtig verstehen.
- Whitelist: Eine Whitelist enthält erlaubte Geräte, Programme oder Adressen, die vom System akzeptiert werden.
- Policy-Änderung: Eine Policy-Änderung ist eine Anpassung von Systemregeln oder Zugriffsrechten, etwa wer was speichern oder lesen darf.
- Scheduling: Scheduling bezeichnet, wie der Kernel Aufgaben zeitlich plant und den Prozessor zwischen ihnen aufteilt.
- Upload-Timing: Zeigt an, wann Daten hochgeladen werden, um Übertragungszeiten besser steuern oder vergleichen zu können.
