Stündlich ist nicht Echtzeit

Diesen Beitrag anhören (14 Min.)

Sieben Minuten nach der vollen Stunde beginnt der Lauf. Er fragt nicht nach dem aktuellen Zustand, sondern nach der gerade abgeschlossenen Stunde. Was um 14:00

UTC passiert, gehört bereits in das nächste Fenster. Gegen 14

liegt ein unveränderlicher Report vor. Für einen Alarm wäre das viel zu spät. Für eine verlässliche Zusammenfassung ist es genau die gewünschte Verzögerung.

Diese zeitliche Entscheidung trennt das Mission Cockpit von Live-Monitoring. Der Unterschied liegt nicht zuerst in Prometheus, Grafana oder Markdown. Er liegt in der Frage, wie schnell ein neuer Wert eine Reaktion auslösen muss und ob sich die betrachtete Aussage später noch verändern darf.

Der Beitrag „Markdown Reports statt Dashboard-Zwang“ beschreibt bereits den Unterschied zwischen flüchtiger Ansicht und prüfbarem Stand. Hier geht es enger um die Zeitmechanik eines regelmäßigen Produktreports: geschlossene Fenster, verspätete Daten, Wiederholungen und die Grenze zu echter Betriebsbeobachtung.

Was sich seit damals geändert hat

Im älteren Artikel war der feste Report vor allem eine Entscheidung über Nachvollziehbarkeit: Ein Stand bleibt erhalten und lässt sich mit dem nächsten vergleichen. Das Mission Cockpit ergänzt dafür nun einen präzisen Zeitvertrag. Jeder Stundenreport gehört zu einem abgeschlossenen UTC-Fenster, verspätete Daten werden benannt und Wiederholungen konvergieren über denselben Window Key. Tages-, Wochen-, Monats- und Jahresstände sind eigene Verdichtungen. Aus „Report statt flüchtiger Ansicht“ wird damit „Report über einen eindeutig begrenzten Zeitraum“.

Zwei Zeitachsen, zwei Aufgaben

Live-Monitoring arbeitet möglichst nah am Ereignis. Eine Fehlerrate steigt, ein Alarm wird ausgewertet, jemand öffnet Logs und Traces. Neue Daten verändern die Darstellung fortlaufend. Ein Report wartet dagegen, bis sein Zeitraum beendet ist. Er kann dann feststellen, welche Quellen vollständig vorlagen, seine Fakten hashen und denselben Stand später erneut ausliefern.

flowchart LR
    E["Ereignis"] --> M["Live-Metrik<br/>Sekunden bis Minuten"]
    M --> A["Alarm oder Untersuchung"]
    E --> W["geschlossenes Stundenfenster"]
    W --> R["unveränderlicher Report"]
    R --> V["Vergleich und Einordnung"]

Beide Wege dürfen dasselbe Ereignis sehen und trotzdem zu verschiedenen Ergebnissen kommen. Das Monitoring kann um 13

auf fünf Fehler in zwei Minuten reagieren. Der Stundenreport hält später fest, dass im Fenster von 13 bis 14 Uhr fünf Fehler bei 1.200 Ausführungen auftraten, welche Quellen abgedeckt waren und ob die Häufung im Vergleich zu früheren Fenstern auffällt.

Eine künstliche Echtzeitoberfläche für die zweite Aufgabe würde vor allem Unruhe erzeugen. Während des laufenden Fensters sind Zähler unvollständig. Ein Wert von null um 13

sagt fast nichts über die Stunde aus. Ein wachsender Balken lädt dazu ein, Zwischenstände mit abgeschlossenen Stunden zu vergleichen.

Das Fenster ist ein Vertrag

Der Collector verwendet halboffene UTC-Intervalle. Anfang eingeschlossen, Ende ausgeschlossen. Diese Schreibweise verhindert, dass ein Ereignis an der Grenze in zwei Reports landet.

type ClosedWindow = {
  from: string; // inclusive RFC 3339 timestamp
  to: string;   // exclusive RFC 3339 timestamp
  bucket: "hour";
};

const window: ClosedWindow = {
  from: "2026-07-18T13:00:00.000Z",
  to: "2026-07-18T14:00:00.000Z",
  bucket: "hour"
};

UTC vermeidet einen unangenehmen Sonderfall: In Europa hat der Tag der Sommerzeitumstellung nicht immer 24 lokale Stunden. Speicherung und Sammlung bleiben deshalb in UTC. Die Reportseite kann ein Datum später für ihre Leser lokalisieren, ohne die fachliche Grenze zu verändern.

Der Lauf startet bei Minute sieben. Weitere drei Minuten dienen als Fertigstellungsreserve, bevor der PROD-Gate den neuen Stand als fällig betrachtet. Vor Minute zehn prüft er noch das vorherige Fenster. Dadurch führt eine etwas langsamere, aber erfolgreiche Ausführung nicht sofort zu einem falschen Frischefehler.

collection:
  cron: "7 * * * *"
  timezone: UTC
verification_ready_minute: 10
window:
  start: previous_hour
  end: current_hour
  end_inclusive: false

Die drei Minuten sind keine universelle Empfehlung. Sie sind ein gemessenes Budget für diesen Ablauf. Wird die Sammlung umfangreicher, müssen Schedule, Timeout und Prüfgrenze gemeinsam angepasst werden. Eine heimlich verlängerte Reserve würde echte Verzögerungen nur später sichtbar machen.

Verspätung ist nicht dasselbe wie Verlust

Ein HTTP-Aufruf kann vorübergehend fehlschlagen. Ein Workflow kann nach dem Schreiben des Artefakts abbrechen, bevor er seinen Status aktualisiert. Ein Release kann erfolgreich sein, obwohl die Antwort beim Client nicht mehr ankommt. Darum darf ein Retry nicht einfach „noch einmal alles“ bedeuten.

Jeder Lauf hat ein eindeutiges Zeitfenster. Snapshots werden inhaltsadressiert oder an einem eindeutigen Pfad ersetzt. Der Content-Release verwendet einen Deduplizierungsschlüssel aus Reporttyp und Zeitraum. Ein zweiter erfolgreicher Versuch erzeugt dadurch keinen zweiten sichtbaren Stundenreport.

{
  "cadence": "hourly",
  "period_start": "2026-07-18T13:00:00.000Z",
  "period_end": "2026-07-18T14:00:00.000Z",
  "dedupe_key": "hourly:2026-07-18T13:00:00.000Z",
  "source_count": 4
}

Erst nach der vorgesehenen Reserve wird zwischen verspätet und fehlend unterschieden. Ein verspäteter Lauf kann noch erfolgreich abschließen und denselben Report veröffentlichen. Ein fehlender Lauf hinterlässt eine Lücke in der erwarteten Stundenfolge. Der Soak-Test prüft deshalb nicht nur die Anzahl der Ausführungen, sondern 24 aufeinanderfolgende Buckets ohne Doppelung.

Wann Prometheus und Grafana fehlen würden

Prometheus speichert numerische Zeitreihen mit Labels, sammelt typischerweise per HTTP-Pull und stellt mit PromQL eine Abfragesprache bereit. Grafana verbindet zahlreiche Datenquellen, transformiert Abfrageergebnisse und bietet interaktive Panels, Variablen und Drill-downs. Diese Fähigkeiten sind wertvoll, wenn eine Frage während der Untersuchung entsteht und nicht vorher im Reportvertrag feststand.

Das kleine Cockpit kann das nicht. Es kennt keine freie Abfragesprache. Der Zeitraum ist nicht im Browser verschiebbar. Es gibt keine Tooltips über hochaufgelösten Punkten, keine Korrelation beliebiger Labels, keine Alerting-Regeln und keine spontane Logsuche aus einem Panel heraus.

Frage	Stundenreport	Prometheus/Grafana
Was war im abgeschlossenen Fenster?	direkt vorgesehen	per Abfrage möglich
Muss innerhalb von Minuten reagiert werden?	ungeeignet	dafür gebaut
Bleibt der gelesene Stand unverändert?	ja, als Release	nur mit Snapshot oder Export
Kann ich spontan neue Dimensionen untersuchen?	nur nach Vertragsänderung	ja, wenn die Daten vorliegen
Brauche ich eine weitere laufende Plattform?	nein	ja

Die fehlenden Fähigkeiten sind kein Qualitätsmangel, solange sie außerhalb der Aufgabe liegen. Problematisch würde die Einfachheit, sobald jemand das Cockpit für Incident-Analyse verwendet. Dann wären die sieben Minuten Verzögerung, die geringe Auflösung und die feste Faktensicht echte Risiken.

Vier Fragen vor der Werkzeugwahl

„Dashboard oder Report?“ ist zu grob. Für die Entscheidung haben sich vier getrennte Fragen als nützlicher erwiesen.

Die erste betrifft die Reaktionszeit. Muss jemand innerhalb von Sekunden oder wenigen Minuten handeln, gehört die Beobachtung in ein Monitoring- und Alerting-System. Darf ein Team den Stand im nächsten regelmäßigen Arbeitszyklus prüfen, kann ein stündlicher oder täglicher Report reichen.

Die zweite betrifft die Veränderlichkeit. Soll dieselbe URL morgen neue Werte zeigen, ist eine Live-Abfrage passend. Muss später noch genau der Stand vom 18. Juli lesbar sein, braucht es ein unveränderliches Artefakt oder einen ausdrücklich gespeicherten Snapshot.

Die dritte betrifft die Untersuchung. Sind die Fragen vorab bekannt – Anzahl Releases, Fehler, Quellenabdeckung –, kann ein begrenztes Schema sie präzise abbilden. Entstehen die Fragen erst beim Blick auf eine Auffälligkeit, werden Abfragesprache, variable Zeiträume und Drill-down wichtig.

Die vierte betrifft die Auflösung. Ein stündlicher Zähler kann zeigen, dass etwas häufiger fehlschlug. Er kann nicht erklären, welcher einzelne Request langsam war oder welche Logzeile zu einem Trace gehört. Für diese Untersuchung müssen die hochaufgelösten Daten in ihrem Betriebswerkzeug bleiben.

decision:
  reaction_time: next_work_cycle
  immutable_history: required
  questions_known_in_advance: true
  per_request_drilldown: false
result: scheduled_report

Sobald eine Antwort kippt, kann auch das passende Werkzeug wechseln. Ein Report und ein Live-System dürfen denselben Dienst beobachten, solange sie nicht vortäuschen, dieselbe Aufgabe zu erfüllen.

Der Scheduler ist Teil der Aussage

Ein manuell erzeugter Report belegt nur, dass irgendwann jemand einen Knopf gedrückt hat. Ein geplanter Lauf macht zusätzlich sichtbar, ob die erwartete Regelmäßigkeit eingehalten wurde. Deshalb gehören Schedule-ID, Cron-Ausdruck, Zeitzone und Pausenstatus in den PROD-Gate.

Der Test prüft nicht bloß, ob irgendein Workflow um ungefähr sieben Minuten nach der Stunde lief. Er löst den gespeicherten Workflow über die normale API auf, vergleicht den erwarteten Cron-Ausdruck und zählt ausschließlich Scheduler-Ausführungen. Manuelle Shadow-Läufe dürfen eine fehlende geplante Stunde nicht verdecken.

{
  "cron": "7 * * * *",
  "timezone": "UTC",
  "paused": false,
  "request_source": "scheduler",
  "expected_consecutive_buckets": 24
}

Diese Trennung war im Soak-Test wichtig. Während der Einführung gab es erfolgreiche manuelle Läufe kurz vor einem geplanten Fenster. Hätte der Test nur Status und Workflow-ID gezählt, wäre eine ausgefallene Scheduler-Ausführung unbemerkt geblieben. Erst request_source=scheduler macht aus „24 erfolgreiche Läufe“ die stärkere Aussage „24 erwartete Stunden wurden automatisch verarbeitet“.

Auch eine Pause ist kein Fehler, wenn sie während eines Releases ausdrücklich gesetzt wurde. Sie muss jedoch sichtbar und nach dem Rollout bewusst aufgehoben werden. Ein vergessener Pause-Schalter ist kein Datenproblem, sondern eine unterbrochene Zusage über Regelmäßigkeit.

Was ein stündlicher Report gut erklären muss

Eine statische Seite darf sich nicht darauf verlassen, dass ein erfahrener Operator die Darstellung richtig deutet. Sie braucht einen expliziten Kommunikationsvertrag. Der Stundenreport nennt deshalb Zielgruppe, eine Leserfrage, Ziel, These, Schlussfolgerung, nächste Handlung und Grenzen. Die Oberfläche zeigt diese Antwort in abnehmender Wichtigkeit: zuerst Zustand und Ausnahme, dann wenige Signale, danach Evidenz und Provenienz.

Das betrifft besonders Nullen und Datenlücken. Null technische Fehler sind ein beobachtetes Ergebnis. Null Engagement kann ein beobachtetes Ergebnis oder ein noch nicht angeschlossener Datenlieferant sein. Der Report muss diese Zustände aus seinem Faktenvertrag unterscheiden und fehlende Quellen ausdrücklich nennen.

## Data quality

The source window is complete for four product APIs.
External acquisition data is not connected yet and is shown as unavailable.
No value is inferred from missing input.

Auch die Aggregation braucht eine Erklärung. Eine wöchentliche Median-Laufzeit beantwortet eine andere Frage als das Maximum der langsamsten Stunde. Der Report nennt Zeitraum, erwartete und vorhandene Unterfenster sowie die verwendete Verdichtung. Sonst sieht eine präzise Zahl geprüfter aus, als sie ist.

Rollups sind keine größeren Stundenreports

Tages-, Wochen-, Monats- und Jahresreports entstehen aus bereits abgeschlossenen Artefakten. Der tägliche Lauf muss nicht erneut vier Produkt-APIs für jede Stunde abfragen. Er liest die 24 erwarteten Stundenmanifeste, prüft ihre Hashes und berechnet seine Abdeckung.

flowchart TD
    H["24 Stundenartefakte"] --> D["Tagesreport"]
    D --> W["Wochenreport"]
    W --> M["Monatsreport"]
    M --> Y["Jahresreport"]
    H --> Q["Abdeckung und fehlende Fenster"]
    Q --> D

Ein Zeitraum mit coverage=20/24 darf veröffentlicht werden, wenn er sich klar als unvollständig ausweist. Das kann hilfreicher sein als gar kein Report. Er darf aber nicht dieselbe visuelle Sicherheit ausstrahlen wie 24/24. Die Datenqualität gehört neben die Kennzahlen, nicht in eine Fußnote.

Die gröberen Reports dürfen außerdem andere Schwerpunkte setzen. Die Stunde prüft vor allem den Datenfluss und frische technische Signale. Der Tag beantwortet, was heute Aufmerksamkeit braucht. Die Woche vergleicht Tagesverläufe und wiederkehrende Ausnahmen. Der Monat ordnet Aktivitätsmuster, Betriebsrisiken und Messlücken für die nächste Planung ein. Das Jahr verdichtet nur jene Evidenz, die eine strategische Entscheidung tragen kann. Jede Cadence besitzt daher eine eigene Frage und ein eigenes Informationsmuster. Nur den Datumsfilter zu verbreitern wäre formal korrekt und inhaltlich schwach.

Auch Zahlen sind dabei nicht bloß Werte. Der Faktenvertrag unterscheidet Zähler, Bestände, Laufzeiten, Verhältnisse und Datenmengen. Er nennt die Einheit und legt fest, ob ein Rollup Summe, letzten Wert oder Mittelwert bevorzugt. Eine Maschine muss dadurch nicht aus einem Metriknamen raten, wie der Wert über mehrere Intervalle gelesen werden soll.

Einfache Technik braucht eine klare Grenze

Der stündliche Ansatz entfernt mehrere laufende Komponenten: keinen zusätzlichen Scraper-Dienst, keine eigene Metrikdatenbank und keine Dashboard-Engine. Vorhandene HTTP-APIs, ein Scheduler, ein privater Objektspeicher und der Content-Releasepfad genügen. Das ist leichter zu betreiben, zu sichern und wiederherzustellen – und deutlich leichter vollständig lokal zu testen.

Diese Einfachheit bleibt nur erhalten, wenn das System zu seiner Aufgabe steht. Ein Report darf eine fehlende Datenquelle zeigen, statt eine neue Datenerfassung heimlich einzubauen. Er darf auf eine externe Incident-Ansicht verweisen, statt selbst zur Leitstelle zu werden. Und er darf eine Frage unbeantwortet lassen, wenn dafür weder Fakt noch Connector vorhanden ist.

Stündlich bedeutet hier nicht „fast live“. Es bedeutet: regelmäßig, abgeschlossen, wiederholbar und langsam genug, um einen vollständigen Stand zu prüfen. Wer schneller reagieren muss, braucht Monitoring. Wer später nachvollziehen will, was in einem klaren Zeitraum bekannt war, braucht einen Report. Dass beide nebeneinander bestehen, ist kein doppelter Aufwand, sondern eine saubere Trennung zweier Aufgaben.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare