Downsampling bezeichnet das Reduzieren der Auflösung von Zeitreihendaten, indem Rohdatenpunkte zu gröberen Intervallen aggregiert werden, etwa von 15-Sekunden-Werten zu Rollups mit 5 Minuten oder 1 Stunde. Dabei bleiben Aggregate wie Minimum, Maximum, Summe und Anzahl erhalten, sodass langfristige Trends abfragbar bleiben, während Speicher- und Abfragekosten sinken.
Was Downsampling ist
Downsampling tauscht Detailtiefe gegen Reichweite. Eine Metrik, die alle 15 Sekunden abgefragt wird, erzeugt pro Zeitreihe 5.760 Punkte am Tag. Für die letzten Stunden ist diese Auflösung unverzichtbar, denn im Incident wollen Sie eine 30-Sekunden-Spitze sehen. Für ein Kapazitäts-Review über das vergangene Jahr braucht sie niemand, und Millionen Rohpunkte pro Zeitreihe machen Dashboards langsam und Speicher teuer. Downsampling ersetzt ältere Rohpunkte durch Rollups mit gröberer Auflösung, typischerweise in Stufen wie roh, 5 Minuten und 1 Stunde.
Die Technik ist in Zeitreihendatenbanken Standard. Das Whisper-Format von Graphite definiert Aufbewahrungsstufen wie 10s:1d,1m:30d,1h:1y. Prometheus selbst führt kein Downsampling durch, Thanos erledigt das im Compactor: Daten älter als 40 Stunden werden zu 5-Minuten-Blöcken, Daten älter als 10 Tage zu 1-Stunden-Blöcken verdichtet.
Downsampling und Sampling im Vergleich
Die Begriffe klingen ähnlich, die Verfahren sind es nicht:
| Downsampling | Sampling | |
|---|---|---|
| Anwendung auf | Zeitreihen (Metriken) | Einzelne Events (Traces, Logs) |
| Verfahren | Fasst viele Punkte zu einem pro Intervall zusammen | Behält eine Teilmenge der Events, verwirft den Rest |
| Was erhalten bleibt | Statistische Zusammenfassung jeder Zeitreihe | Vollständige Details ausgewählter Events |
| Zeitpunkt | Wenn Daten eine Altersgrenze überschreiten | Bei Erfassung oder Ingest |
Eine verdichtete Zeitreihe berücksichtigt in ihren Aggregaten weiterhin jeden ursprünglichen Wert. Sampling, etwa Head- oder Tail-based Sampling von Traces, behält manche Events vollständig und verliert andere ganz. Beide senken das Volumen, und ausgereifte Setups nutzen meist beides.
Wie Rollups die Aussagekraft erhalten
Ein einzelner Mittelwert pro Intervall reicht nicht. Wer nur den Durchschnitt speichert, lässt eine 10-sekündige CPU-Spitze auf 100 % in einem 5-Minuten-Mittel von 30 % verschwinden. Gutes Downsampling speichert mehrere Aggregate pro Intervall, damit unterschiedliche Fragen beantwortbar bleiben:
- Minimum und Maximum, um Spitzen und Täler zu bewahren.
- Summe und Anzahl, damit sich Mittelwerte über Intervalle und Zeitreihen korrekt neu berechnen lassen.
- Counter-taugliche Werte, damit Raten auch über Counter-Resets hinweg stimmen. Thanos speichert dafür ein eigenes Counter-Aggregat.
- Histogramm-Buckets, pro Intervall summiert, damit sich Perzentile später noch schätzen lassen.
Was nicht funktioniert: vorberechnete Perzentile mitteln. Der Durchschnitt von zwölf p99-Werten à 5 Minuten ist nicht das p99 der Stunde. Bewahren Sie stattdessen die Bucket-Zähler auf.
Beispiel: Aufbewahrungsstufen
Eine beispielhafte Staffelung für ein Plattform-Team:
roh (15s) -> 14 Tage Incident-Analyse, Alert-Tuning
5m-Rollup -> 90 Tage Wochen-Reviews, SLO-Reports
1h-Rollup -> 13 Monate Kapazitätsplanung, VorjahresvergleichIn Thanos setzen Sie das über --retention.resolution-raw, --retention.resolution-5m und --retention.resolution-1h. Beachten Sie: Thanos beschreibt Downsampling vor allem als Mittel für schnellere Abfragen über lange Zeiträume. Es erzeugt zusätzliche Blöcke, Speicher sparen Sie also nur, wenn die Aufbewahrung der Rohdaten kürzer ist als die der Rollups.
Downsampling mit Recording Rules
Wo die Speicherschicht kein Downsampling bietet, aggregieren viele Teams mit Recording Rules vor. Eine Regel wie job:http_requests:rate5m = sum by (job) (rate(http_requests_total[5m])) berechnet eine kompakte Zeitreihe ohne Labels pro Instanz und Pfad. Sie senkt damit Auflösung und Kardinalität zugleich, und Dashboards über lange Zeiträume fragen die kleine Zeitreihe ab statt Tausender Rohreihen. Der Preis: Sie müssen vorab entscheiden, welche Fragen wichtig sind, denn Dimensionen, die die Regel entfernt, lassen sich später nicht wiederherstellen. Bewährt hat sich, Rohreihen nur kurz und die aufgezeichneten Aggregate deutlich länger aufzubewahren. Das entspricht im Kern einem klassischen, gestaffelten Downsampling und lässt sich gut mit festen Aufbewahrungsstufen kombinieren.
Best Practices
- Abfrageschritt an die Auflösung anpassen. Ein PromQL-
rate()über eine Minute auf 1-Stunden-Daten liefert nichts Brauchbares. Wählen Sie Fenster über mehrere Auflösungsschritte. - Zuerst die Kardinalität senken. Downsampling verringert die Punkte pro Zeitreihe, nicht die Zahl der Zeitreihen. Hohe Kardinalität bleibt in jeder Auflösung teuer.
- Rohdaten lange genug behalten, um Ihr Fenster für Incident-Analyse und Postmortems abzudecken.
- Stufen dokumentieren, damit Dashboard-Nutzer verstehen, warum ein Jahresgraph glatter wirkt als der der letzten Woche.
Typische Fehler
Häufig werden nur Mittelwerte gespeichert, Alerts laufen auf verdichteten Daten und kurze Spitzen lösen nie aus, oder Downsampling wird mit der Ausdünnung bei der Darstellung verwechselt. Chart-Bibliotheken reduzieren Punkte oft fürs Rendering, etwa mit Algorithmen wie LTTB. Das verändert, was Sie sehen, nicht aber, was gespeichert ist.
Wie Obseria unterstützt
Obseria bewahrt Metrik-Datenpunkte standardmäßig 13 Monate auf, sodass langfristige Trends ohne eigene Compaction-Schicht verfügbar bleiben, und nimmt Prometheus-Metriken neben OTLP an. Obseria Pipeline filtert Daten bereits beim Ingest, gefilterte Daten kosten nur die Ingestion. Das ist oft der größere Hebel, wie unser Beitrag zum Pipeline-first-Ansatz für Observability-Kosten zeigt.
