Downsampling und Aufbewahrungsstufen für Zeitreihendaten

Ziel

Langfristige Fragen (ein Jahr an Latenz, drei Jahre an Zählerständen) zu einem Bruchteil der Speicher- und Scan-Kosten von Rohdaten beantworten, während die Rohauflösung für den Zeitraum erhalten bleibt, in dem sie tatsächlich betrachtet wird.

Voraussetzungen

Eine nach Zeit partitionierte Tabelle oder ein entsprechender Speicher sowie eine Entscheidung darüber, was jede Stufe beantworten können muss. Die Speicherdokumentation von Prometheus (zitiert) zeigt die einfachste Richtlinie: eine Aufbewahrungsdauer für Samples (--storage.tsdb.retention.time, standardmässig 15 Tage, wenn weder diese noch eine Grössenbegrenzung gesetzt ist) oder eine Grössenbegrenzung, die zuerst die ältesten Blöcke entfernt. Thanos (zitiert) beschreibt Downsampling als das Umschreiben von Serien, um die Auflösung zu reduzieren, ohne über längere Zeiträume an Genauigkeit zu verlieren, wobei pro heruntergesampeltem Chunk Count, Sum, Min, Max und eine Counter-Serie gespeichert werden, sodass die gröberen Daten weiterhin aggregiert werden können. Die date_bin-Funktion von PostgreSQL (zitiert) bündelt einen Zeitstempel in ein Intervall, das an einem angegebenen Ursprung ausgerichtet ist – die Grundoperation, die ein SQL-Rollup benötigt.

Schritte

1. Die Stufen als (Auflösung, Aufbewahrungsdauer, Zweck) festhalten: zum Beispiel Rohdaten für 14 Tage für die Vorfallanalyse, 5-Minuten-Bins für 13 Monate für Kapazitätstrends, Stunden-Bins für 5 Jahre für Reporting. Aufbewahrungsfristen sind eine zu dokumentierende Entscheidung, keine von anderswo übernommene Zahl.
2. Für jeden Bin nur erneut aggregierbare Kennzahlen speichern: Count, Sum, Min, Max sowie bei Countern den Zuwachs. Durchschnittswerte zur Abfragezeit als Sum geteilt durch Count ableiten; keine Durchschnittswerte oder Perzentile speichern, da sie sich nicht zu einem gröberen Bin kombinieren lassen. Werden Perzentile benötigt, ein Histogramm mit festen Bucket-Grenzen speichern.
3. Bins mit date_bin(stride, ts, origin) unter Verwendung eines einzigen festen Ursprungs ausrichten (die Unix-Epoche oder Mitternacht UTC), damit Bins aus verschiedenen Läufen und Tabellen übereinstimmen.
4. Das Rollup für einen Bin erst planen, nachdem das Fenster für verspätete Daten dieses Bins abgelaufen ist, und es den Bin ersetzen statt ihm etwas hinzuzufügen lassen, damit ein erneuter Lauf gefahrlos ist.
5. Eine Stufe durch das Verwerfen ganzer Partitionen oder Blöcke ablaufen lassen, niemals durch zeilenweises Löschen; das Rollup einer Partition (Zeilenanzahl, Summe eines Messwerts) verifiziert halten, bevor deren Rohpartition verworfen wird.
6. Die Stufen über eine einzige View oder Abfrageschicht bereitstellen, die die feinste Stufe wählt, die den angefragten Bereich abdeckt.

Erwartetes Ergebnis

Langfristige Abfragen durchsuchen die grobe Stufe und liefern in begrenzter Zeit ein Ergebnis; der Speicherbedarf wächst nur mit den groben Stufen; Rohdaten bleiben für den Zeitraum erhalten, in dem sie genutzt werden.

Grenzen und Prüfbasis

Heruntergesampelte Daten können keine Fragen zu Spitzen innerhalb eines Bins beantworten. Überschreitet eine Abfrage eine Stufengrenze, liefert sie zwei Auflösungen in einem Ergebnis und muss entsprechend gekennzeichnet werden. Das Vorgehen leitet sich aus der zitierten Dokumentation ab; es wird kein Messergebnis behauptet.