RedisTimeSeries: Metriken und Monitoring-Daten effizient speichern

1. Warum Zeitreihendaten ein eigenes Datenmodell brauchen

Metriken wie Requests pro Sekunde oder Antwortzeiten unterscheiden sich fundamental von klassischen Redis-Anwendungsfällen: Es geht nicht um den aktuellen Wert eines einzelnen Keys, sondern um eine fortlaufende Folge von Zeitstempel-Wert-Paaren, die über Stunden, Tage oder Monate wächst. Ohne ein spezialisiertes Datenmodell müsste jede einzelne Messung als eigener Sorted-Set-Eintrag oder eigener Key abgelegt werden, was bei hoher Messfrequenz schnell zu Millionen von Einträgen führt.

RedisTimeSeries löst dieses Problem, indem es einen eigenen Datentyp für Zeitreihen einführt, der intern für sequenzielle Zeitstempel optimiert ist und Funktionen wie Downsampling, Retention und Aggregation direkt im Server anbietet, ohne dass die Anwendung diese Logik selbst implementieren muss.

2. Das Datenmodell: TS.CREATE und TS.ADD

Eine Zeitreihe wird mit TS.CREATE angelegt und optional mit Labels versehen, die spätere Abfragen über mehrere Zeitreihen hinweg ermöglichen, ähnlich den Labels in Prometheus. Neue Messpunkte werden per TS.ADD mit Zeitstempel und Wert hinzugefügt, wobei der Zeitstempel entweder explizit angegeben oder mit dem Platzhalter Stern automatisch auf die aktuelle Serverzeit gesetzt werden kann.

Für hochfrequente Metriken, etwa Requests pro Sekunde aus mehreren Anwendungsservern, empfiehlt sich TS.MADD, das mehrere Messpunkte über verschiedene Zeitreihen hinweg in einem einzigen Befehl schreibt und damit den Overhead vieler einzelner Netzwerk-Roundtrips vermeidet.

redis-cli TS.CREATE metrik:requests:webserver1 LABELS service webserver1 typ requests

redis-cli TS.ADD metrik:requests:webserver1 '*' 142

redis-cli TS.MADD metrik:requests:webserver1 '*' 150 metrik:requests:webserver2 '*' 98

3. Downsampling-Regeln: Aggregierte Zeitreihen automatisch pflegen

Rohdaten in Sekundenauflösung sind für Echtzeit-Dashboards wichtig, für Langzeitanalysen über Monate hinweg aber unnötig detailliert und speicherintensiv. RedisTimeSeries löst das mit Downsampling-Regeln über TS.CREATERULE: Eine Quell-Zeitreihe wird mit einer Ziel-Zeitreihe verknüpft, die automatisch aggregierte Werte in einem größeren Zeitfenster erhält, etwa den Minutendurchschnitt oder das Stundenmaximum.

Diese Regeln laufen serverseitig und vollautomatisch: Sobald ein neuer Wert in die Quell-Zeitreihe geschrieben wird, aktualisiert Redis die verknüpfte aggregierte Zielreihe im Hintergrund. Die Anwendung muss weder einen eigenen Cronjob für die Aggregation betreiben noch nachträglich über historische Rohdaten iterieren.

redis-cli TS.CREATE metrik:requests:1min AGGREGATION avg 60000

redis-cli TS.CREATERULE metrik:requests:webserver1 metrik:requests:1min AGGREGATION avg 60000

4. Retention-Policies: Alte Rohdaten automatisch verwerfen

Ohne Aufräummechanismus würden Rohdaten mit Sekundenauflösung unbegrenzt wachsen und den Arbeitsspeicher irgendwann sprengen. RedisTimeSeries löst das über die RETENTION-Option bei TS.CREATE, die angibt, wie lange Datenpunkte in Millisekunden aufbewahrt werden, bevor sie automatisch aus der Zeitreihe entfernt werden.

In der Praxis kombiniert man kurze Retention für hochauflösende Rohdaten mit langer oder unbegrenzter Retention für die downgesampelten Zielreihen: Sekundengenaue Werte bleiben nur wenige Stunden erhalten, Minutenaggregate mehrere Wochen, Stundenaggregate potenziell dauerhaft. So bleibt der Speicherverbrauch kontrollierbar, ohne auf historische Trends verzichten zu müssen.

redis-cli TS.CREATE metrik:requests:webserver1 RETENTION 21600000 LABELS service webserver1

redis-cli TS.CREATE metrik:requests:1min RETENTION 5184000000 LABELS service webserver1 aufloesung 1min

5. Vergleich zu Prometheus und InfluxDB

Prometheus verfolgt ein Pull-Modell: Der Server scraped Metriken periodisch von den überwachten Diensten und speichert sie in einer eigenen, für Zeitreihen optimierten Speicher-Engine. RedisTimeSeries dagegen arbeitet im Push-Modell, Anwendungen schreiben Werte aktiv per TS.ADD, was sich besonders für ereignisgetriebene Metriken eignet, die nicht in ein festes Scrape-Intervall passen, etwa einzelne Warenkorb-Events.

InfluxDB bietet mit seiner eigenen Abfragesprache und ausgereiften Continuous-Queries funktional mehr Möglichkeiten für komplexe Zeitreihenanalysen und ist für sehr große, langfristige Metrikmengen meist die wirtschaftlichere Wahl, da es für Festplattenpersistenz statt In-Memory-Haltung ausgelegt ist. RedisTimeSeries punktet dafür mit der niedrigen Latenz von Redis und der Möglichkeit, Metriken direkt neben ohnehin schon vorhandenen Redis-Daten wie Sessions oder Caches zu betreiben, ohne ein zusätzliches System aufzusetzen.

6. Praxisbeispiel: Requests pro Sekunde und Warenkorb-Events

In einem Magento-Shop lassen sich zwei unterschiedliche Metrik-Arten gut mit RedisTimeSeries abbilden: technische Metriken wie Requests pro Sekunde je Webserver, die in regelmäßigen Intervallen aus einem Middleware-Hook geschrieben werden, und Business-Events wie abgeschlossene Warenkorb-Vorgänge, die unregelmäßig, aber mit hoher Priorität für Echtzeit-Dashboards eintreffen.

Beide Metrik-Arten profitieren von automatischem Downsampling: Requests pro Sekunde werden für ein Live-Dashboard in Sekundenauflösung gehalten, aber zusätzlich zu stündlichen Durchschnittswerten für die Kapazitätsplanung aggregiert. Warenkorb-Events lassen sich als einfache Zählerreihe mit TS.INCRBY fortschreiben, wodurch sich Trends wie ein Anstieg der Abbruchrate während eines Checkout-Deployments unmittelbar erkennen lassen.

redis-cli TS.INCRBY metrik:warenkorb:abgebrochen 1

redis-cli TS.RANGE metrik:requests:1min - + AGGREGATION avg 3600000

7. Aggregationsabfragen über TS.RANGE und TS.MRANGE

Für Auswertungen bietet TS.RANGE eine gefilterte Abfrage über einen Zeitraum, optional mit eigener Aggregationsfunktion, die vom fest hinterlegten Downsampling unabhängig zur Abfragezeit berechnet wird. TS.MRANGE erweitert das auf mehrere Zeitreihen gleichzeitig, gefiltert über Labels, was besonders bei vielen einzelnen Webserver-Instanzen praktisch ist, um etwa alle Requests-Metriken eines bestimmten Service in einer einzigen Abfrage zusammenzufassen.

Diese flexible Abfrageebene erlaubt es, dieselben Rohdaten sowohl für granulare Einzelserver-Ansichten als auch für aggregierte Service-Übersichten zu nutzen, ohne für jeden Anwendungsfall eine eigene Downsampling-Regel anlegen zu müssen. Für dauerhaft benötigte Standardaggregationen bleiben feste Regeln über TS.CREATERULE trotzdem sinnvoll, weil sie den Rechenaufwand vom Abfragezeitpunkt in den Schreibzeitpunkt verlagern.

redis-cli TS.MRANGE - + FILTER service=webserver1 AGGREGATION avg 60000

8. Integration mit Alerting und Monitoring-Stacks

RedisTimeSeries ersetzt in den meisten Setups keinen vollständigen Monitoring-Stack, ergänzt ihn aber gut als schnelle, ohnehin vorhandene Datenquelle für ereignisgetriebene Business-Metriken. Über einen Prometheus-Exporter oder eigene Abfrage-Skripte lassen sich RedisTimeSeries-Werte periodisch in bestehende Alerting-Systeme einspeisen, ohne die eigentliche Metrikerhebung doppelt zu implementieren.

Für einfache Schwellenwert-Alarme reicht mitunter schon ein Cronjob, der über TS.RANGE die letzten Minuten abfragt und bei Überschreitung eines Grenzwerts eine Benachrichtigung auslöst. Für komplexere Alerting-Regeln mit mehrstufigen Bedingungen und Eskalationspfaden bleibt jedoch ein dediziertes Alerting-Tool wie Alertmanager die robustere Grundlage.

9. Betriebliche Grenzen im produktiven Einsatz

Der In-Memory-Charakter von Redis gilt auch für RedisTimeSeries: Ohne konsequente Retention-Policies wächst der Speicherbedarf unkontrolliert, und ein vollgelaufener Redis-Server beeinträchtigt neben den Metriken auch alle anderen Anwendungsfälle wie Cache oder Session-Storage, die eventuell dieselbe Instanz nutzen. Für produktive Setups empfiehlt sich deshalb eine dedizierte RedisTimeSeries-Instanz, getrennt vom Cache-Backend, damit ein plötzlicher Anstieg der Metrik-Schreiblast niemals den Full-Page-Cache oder die Session-Daten eines Shops in Mitleidenschaft zieht.

Auch bei der Ausfallsicherheit lohnt sich ein genauer Blick: Metrikdaten sind naturgemäß weniger kritisch als etwa Sessiondaten, ein kurzer Datenverlust bei einem Failover ist meist verschmerzbar. Wer jedoch langfristige, unveränderliche Historiendaten für Compliance-Zwecke benötigt, sollte RedisTimeSeries eher als schnellen operativen Zwischenspeicher betrachten und die langfristige Archivierung einer klassischen Time-Series-Datenbank oder einem Data Warehouse überlassen. Für ein Shop-Betriebsteam bedeutet das in der Praxis meist ein zweistufiges Setup: RedisTimeSeries für die letzten Tage mit voller Auflösung und schneller Abfragezeit, und ein nachgelagertes System für alles, was darüber hinaus dauerhaft aufbewahrt werden muss.

10. Zusammenfassung

11. FAQ: RedisTimeSeries: Das Wichtigste auf einen Blick