Meine 7-Tage-Kachel zeigte 89,7 GB — gemessen hatte ich 34 Stunden

Was ich gebaut habe: eine Traffic-Seite fürs Control Center. Die Netzwerkkarte beantwortet, was sich gerade bewegt — nirgends beantwortet wurde, wie viel über einen Zeitraum floss und wer es verursacht hat. Die Zähler dafür lagen längst im Zeitreihen-Speicher, es fehlte nur die Zeitachse darüber.

Die Kachel, die mich stutzig gemacht hat. Volumen rechnet man in PromQL mit increase() über ein Fenster — increase(...[7d]) heißt „so viele Bytes in sieben Tagen". Meine Messkette lief zu dem Zeitpunkt seit 34 Stunden; der Speicher war zwei Tage vorher überhaupt erst angelegt worden. Die 7-Tage-Kachel zeigte trotzdem eine Zahl: 89,7 GB.

increase() extrapoliert. Das ist kein Fehler, sondern dokumentiertes Verhalten — bei Prometheus wie bei VictoriaMetrics: Deckt die Zeitreihe das angefragte Fenster nicht ab, wird der gemessene Abschnitt auf die volle Fensterbreite hochgerechnet. Das Tückische ist nicht die Rechnung, sondern wie das Ergebnis aussieht. Eine 30-Tage-Kachel hätte mir eine Monatssumme angezeigt, die nie gemessen wurde, und nichts daran hätte falsch gewirkt.

Mein erster Verdacht war auch falsch. Bevor ich verstanden hatte, was passiert, verdächtigte ich den Speicher: Daten weg, Retention verstellt, Volume kaputt. Das Anlagedatum des Volumes hat das in einer Minute erledigt — es hat nie mehr Historie gegeben. Eine junge Messkette ist kein Datenverlust, sie ist nur jung.

Die Lösung: Jedes Volumenfenster wird jetzt gegen den frühesten vorhandenen Messpunkt geprüft und auf den tatsächlich abgedeckten Abschnitt gekürzt. Die Schnittstelle gibt mit aus, wie viele Sekunden wirklich gemessen wurden, und die Kachel schreibt es hin: „nur 34 h gemessen". Reicht die Historie nicht einmal für eine Viertelstunde, bleibt die Kachel stehen — ohne Wert. Eine sichtbare Lücke ist mir lieber als eine unsichtbare Hochrechnung.

Gleicher Tag, zweite Kleinigkeit mit derselben Wurzel. Die Tabelle schrieb zunächst „gemessen am geräteseitigen Ende". Für die interne Richtungslogik ist das korrekt — am Internet-Link ist das internetfernere Ende aber ausgerechnet das WAN-Interface des Routers. Als Ortsangabe gelesen ist das schlicht irreführend. Jetzt stehen dort Interface und Gerät. Interne Semantik taugt nicht automatisch als Oberflächentext.

Und für einzelne Maschinen habe ich dieselben Bausteine ein zweites Mal benutzt, aber bewusst nicht dieselbe Richtungsumrechnung. Für eine Leitung ist sie richtig, weil man eine Leitung an beiden Enden messen kann (warum das am LAN-Port alles umdreht); eine Maschine misst nur an ihrem eigenen Ende. Auf der Host-Seite bleibt „empfangen" deshalb „empfangen". Die Regel zum Kürzen der Volumenfenster dagegen ist beim zweiten Aufrufer in eine gemeinsame Funktion gewandert, statt als zweite, anfangs identische Kopie zu existieren.

Was ich mitnehme: Wer Volumen über einen Zeitraum anzeigt, muss die Abdeckung mit anzeigen. Das ist kein Randfall — jede frisch aufgesetzte Messkette durchläuft ihn wochenlang, und die falsche Zahl sieht dabei nie falsch aus.