Wie LATENCY HISTORY und LATENCY DOCTOR Latenzspitzen klassifizieren und im Zusammenspiel mit dem Slowlog Ursachen aufdecken
Sporadische Latenzspitzen gehören zu den unangenehmsten Performance-Problemen in einer Redis-Instanz, weil sie sich weder mit einem einzelnen Befehl reproduzieren noch mit einer einfachen Lastmessung erklären lassen. Der eingebaute Latency Monitor wurde genau für diesen Fall entwickelt: Er protokolliert intern verschiedene Ereignisklassen, von langsamen Befehlen über Fork-Vorgänge bis hin zu Ablaufzyklen abgelaufener Schlüssel, und macht sie über die Befehle LATENCY HISTORY, LATENCY LATEST und LATENCY DOCTOR zugänglich. Dieser Artikel zeigt, wie diese Ereignisklassen im Detail funktionieren, wie sich der Latency Monitor sinnvoll mit dem klassischen Slowlog kombinieren lässt und wie ein systematischer Diagnose-Workflow aussieht, wenn Latenzprobleme nur gelegentlich und scheinbar willkürlich auftreten.
Inhaltsverzeichnis
- 1. Wann der Slowlog für die Diagnose nicht ausreicht
- 2. Aktivierung über latency-monitor-threshold
- 3. LATENCY HISTORY und die wichtigsten Ereignisklassen
- 4. LATENCY LATEST für den schnellen Gesamtüberblick
- 5. LATENCY DOCTOR als automatisierte Analyse
- 6. Das Zusammenspiel mit dem Slowlog
- 7. Praktischer Diagnose-Workflow bei sporadischen Latenzspitzen
- 8. Typische Ursachen hinter häufigen Ereignisklassen
- 9. LATENCY RESET und Integration in das Monitoring
- 10. Zusammenfassung
- 11. FAQ
1. Wann der Slowlog für die Diagnose nicht ausreicht
Der klassische Slowlog protokolliert ausschließlich einzelne Befehle, deren Ausführungszeit einen konfigurierten Schwellwert überschreitet, und ist damit ideal, um konkrete, langsame Kommandos zu identifizieren. Viele Latenzprobleme in Redis entstehen jedoch gar nicht innerhalb der Befehlsausführung selbst, sondern durch interne Vorgänge wie einen Fork-Prozess für einen RDB-Snapshot, das Löschen einer großen temporären Datei oder einen aufwändigen Ablaufzyklus für Schlüssel mit gesetzter TTL, die im Slowlog überhaupt nicht auftauchen.
Der Latency Monitor schließt genau diese Lücke, indem er nicht nur Befehle, sondern verschiedene interne Ereignisklassen mit ihrer jeweiligen Dauer protokolliert. Damit lässt sich eine Latenzspitze, die im Slowlog spurlos bleibt, weil kein einzelner Befehl ungewöhnlich lange dauerte, dennoch einer konkreten internen Ursache zuordnen, was gerade bei sporadischen, schwer reproduzierbaren Problemen den entscheidenden Unterschied macht.
2. Aktivierung über latency-monitor-threshold
Der Latency Monitor wird über die Konfigurationsdirektive latency-monitor-threshold aktiviert, die in Millisekunden angibt, ab welcher Dauer ein Ereignis überhaupt aufgezeichnet wird. Ein Wert von null deaktiviert die Aufzeichnung vollständig, während ein niedriger Wert wie einhundert Millisekunden bereits moderate Ausreißer erfasst, ohne die Instanz durch übermäßig viele protokollierte Ereignisse zu belasten.
Anders als bei manchen anderen Diagnose-Werkzeugen ist die Aktivierung des Latency Monitor selbst mit vernachlässigbarem Performance-Overhead verbunden, da lediglich bereits ohnehin gemessene interne Zeitstempel mit dem Schwellwert verglichen werden. Für produktive Umgebungen empfiehlt sich deshalb, den Monitor dauerhaft aktiv zu lassen, statt ihn nur bei einem akuten Problem punktuell einzuschalten, weil sich sporadische Ereignisse sonst gerade dann nicht erfassen lassen, wenn sie tatsächlich auftreten.
# Latency Monitor mit 100ms-Schwellwert dauerhaft aktivieren
redis-cli CONFIG SET latency-monitor-threshold 100
redis-cli CONFIG REWRITE
3. LATENCY HISTORY und die wichtigsten Ereignisklassen
Der Befehl LATENCY HISTORY gefolgt von einem Ereignisnamen liefert eine Liste vergangener Vorfälle dieser Klasse mit jeweiligem Zeitstempel und gemessener Dauer. Zu den wichtigsten Ereignisklassen zählen command für Befehle, die zwar unterhalb der Slowlog-Schwelle liegen können, aber dennoch relevant sind, fork für die Dauer eines Fork-Vorgangs bei RDB- oder AOF-Persistenz, expire-cycle für den periodischen Hintergrundprozess zum Entfernen abgelaufener Schlüssel und rdb-unlink-temp-file für das Löschen einer temporären Snapshot-Datei.
Diese Aufschlüsselung nach Ereignisklasse erlaubt eine gezielte Untersuchung: Häufen sich lange fork-Ereignisse, deutet das auf ein zu groß gewordenes Dataset für die konfigurierte Persistenzstrategie hin, während wiederkehrende expire-cycle-Ausreißer eher auf eine sehr große Anzahl gleichzeitig ablaufender Schlüssel hindeuten, ein Muster, das sich beispielsweise ergibt, wenn viele Cache-Einträge mit identischer TTL zur exakt gleichen Zeit erzeugt wurden.
# Verlauf der Fork-Ereignisse der letzten Zeit einsehen
redis-cli LATENCY HISTORY fork
redis-cli LATENCY HISTORY expire-cycle
4. LATENCY LATEST für den schnellen Gesamtüberblick
Während LATENCY HISTORY auf eine einzelne Ereignisklasse fokussiert, liefert LATENCY LATEST einen kompakten Überblick über alle Ereignisklassen, bei denen seit dem letzten Zurücksetzen mindestens ein Vorfall aufgetreten ist, jeweils mit Zeitpunkt des letzten Vorfalls, dessen Dauer und der bisher gemessenen Maximaldauer dieser Klasse.
Dieser Befehl eignet sich hervorragend als erster Einstiegspunkt bei einer akuten Latenzuntersuchung, weil er in einer einzigen Abfrage zeigt, welche Ereignisklassen überhaupt relevant sind, bevor mit LATENCY HISTORY gezielt in eine bestimmte Klasse tiefer eingestiegen wird. Ein leeres Ergebnis von LATENCY LATEST bei gleichzeitig beobachteten Anwendungs-seitigen Latenzproblemen ist zudem selbst eine wichtige diagnostische Information, weil sie nahelegt, dass die Ursache außerhalb von Redis liegt, etwa im Netzwerk oder in der Anwendung selbst.
5. LATENCY DOCTOR als automatisierte Analyse
LATENCY DOCTOR fasst die aufgezeichneten Ereignisse in einer für Menschen lesbaren Textform zusammen und ordnet auffällige Muster automatisch bekannten Ursachen zu, etwa einem zu groß dimensionierten Dataset für Fork-basierte Persistenz oder einer ungewöhnlich hohen Anzahl gleichzeitig ablaufender Schlüssel. Die Ausgabe enthält dabei nicht nur die reine Beobachtung, sondern auch konkrete Handlungsempfehlungen, formuliert in normaler Sprache statt als reine Zahlenkolonne.
Wichtig ist dabei, LATENCY DOCTOR als Startpunkt und nicht als abschließende Antwort zu verstehen: Die automatisierte Analyse erkennt bekannte, häufige Muster zuverlässig, kann aber ungewöhnliche oder mehrfach überlagerte Ursachen nicht immer korrekt trennen. Bei komplexeren Fällen bleibt der manuelle Blick in LATENCY HISTORY der einzelnen Ereignisklassen unverzichtbar, um die von LATENCY DOCTOR vorgeschlagene Erklärung tatsächlich zu bestätigen.
redis-cli LATENCY DOCTOR
6. Das Zusammenspiel mit dem Slowlog
Latency Monitor und Slowlog ergänzen sich, weil sie unterschiedliche Ausschnitte derselben Realität abbilden: Der Slowlog beantwortet die Frage, welcher konkrete Befehl ungewöhnlich lange gebraucht hat, während der Latency Monitor die breitere Frage beantwortet, wann und wodurch die Instanz insgesamt spürbar verzögert wurde, unabhängig davon, ob ein einzelner Befehl oder ein interner Hintergrundprozess dafür verantwortlich war.
In der Praxis lohnt sich deshalb ein kombinierter Blick: Zeigt LATENCY LATEST eine Häufung von command-Ereignissen zu einem bestimmten Zeitpunkt, liefert ein anschließender Blick in SLOWLOG GET für denselben Zeitraum die konkreten Befehle, die dafür verantwortlich waren, inklusive der vollständigen Argumente. Ohne diesen kombinierten Blick bliebe entweder unklar, welcher Befehl schuld war, oder ob überhaupt ein Befehl und nicht ein interner Prozess die Ursache war.
redis-cli LATENCY LATEST
redis-cli SLOWLOG GET 20
7. Praktischer Diagnose-Workflow bei sporadischen Latenzspitzen
Ein bewährter Ablauf beginnt mit der Sicherstellung, dass latency-monitor-threshold dauerhaft aktiv ist, damit Ereignisse tatsächlich erfasst werden, sobald sie auftreten, statt erst nach dem Beschweren der Anwendungsseite mühsam reproduziert werden zu müssen. Sobald ein sporadisches Problem gemeldet wird, liefert LATENCY LATEST als erster Schritt einen schnellen Überblick, welche Ereignisklassen überhaupt betroffen sind.
Im zweiten Schritt liefert LATENCY HISTORY für die auffälligste Klasse die zeitliche Verteilung der Vorfälle, die sich mit externen Ereignissen wie Deployment-Zeitpunkten, Cron-Jobs oder Backup-Fenstern abgleichen lässt. Erst im dritten Schritt kommt LATENCY DOCTOR als zusammenfassende Interpretation hinzu, gefolgt von einem Abgleich mit dem Slowlog für denselben Zeitraum, um festzustellen, ob konkrete Anwendungsbefehle oder interne Redis-Prozesse die eigentliche Ursache waren.
8. Typische Ursachen hinter häufigen Ereignisklassen
Häufige fork-Ereignisse mit steigender Dauer korrelieren meist direkt mit der Größe des Datasets, weil der Fork-Vorgang bei größeren Datenmengen mehr Seitentabellen-Einträge kopieren muss, was sich durch DEBUG OBJECT oder MEMORY USAGE für einzelne verdächtig große Schlüssel weiter eingrenzen lässt. Häufige expire-cycle-Ereignisse deuten dagegen meist auf eine unglückliche Verteilung von TTL-Werten hin, bei der sehr viele Schlüssel gleichzeitig ablaufen, statt gleichmäßig über die Zeit verteilt zu sein.
Command-Ereignisse ohne erkennbares Muster im Slowlog, die aber dennoch im Latency Monitor auftauchen, deuten häufig auf Betriebssystem-seitige Ursachen hin, etwa Swapping durch unzureichenden Arbeitsspeicher oder eine CPU-Drosselung in einer Container-Umgebung mit zu engen Ressourcengrenzen, Ursachen, die weder der Slowlog noch der Latency Monitor direkt benennt, aber durch das plötzliche, unmotivierte Auftreten nahelegt.
9. LATENCY RESET und Integration in das Monitoring
Der Befehl LATENCY RESET löscht die intern gespeicherte Historie einer oder aller Ereignisklassen und eignet sich vor allem dafür, nach einer gezielten Optimierungsmaßnahme, etwa der Anpassung von TTL-Verteilungen oder einer Umstellung der Persistenzstrategie, mit einem sauberen Ausgangszustand erneut zu messen, ob die Maßnahme tatsächlich gewirkt hat.
Für eine dauerhafte Historisierung über einen reinen Momentaufnahme-Befehl hinaus lohnt sich ein regelmäßiger, etwa minütlicher Cronjob, der LATENCY LATEST abfragt und die Ergebnisse in ein externes Monitoring-System wie Prometheus überführt, statt sich ausschließlich auf die begrenzte, intern gespeicherte Ereignisanzahl von Redis selbst zu verlassen, die bei sehr vielen Vorfällen älteste Einträge automatisch verwirft.
# Historie einer bestimmten Ereignisklasse zurücksetzen
redis-cli LATENCY RESET fork
redis-cli LATENCY RESET
| Latenz-Ereignis | Typische Ursache | Diagnosewerkzeug | Gegenmaßnahme |
|---|---|---|---|
| command | einzelner langsamer Befehl im Anwendungscode | LATENCY HISTORY plus SLOWLOG GET | Befehl optimieren oder durch nicht-blockierende Variante ersetzen |
| fork | großes Dataset bei RDB- oder AOF-Persistenz | LATENCY HISTORY fork, MEMORY USAGE | Persistenzstrategie anpassen oder Dataset-Größe reduzieren |
| expire-cycle | sehr viele Schlüssel mit identischer TTL laufen gleichzeitig ab | LATENCY HISTORY expire-cycle | TTL-Werte mit Jitter versehen, um Ablaufzeitpunkte zu streuen |
| rdb-unlink-temp-file | Löschen einer großen temporären Snapshot-Datei | LATENCY HISTORY rdb-unlink-temp-file | schnelleres Storage-Medium oder kleinere Snapshot-Intervalle prüfen |
| aof-write | langsame Schreibgeschwindigkeit des zugrundeliegenden Storage | LATENCY HISTORY aof-write | AOF-Fsync-Policy anpassen oder schnelleres Storage einsetzen |
Mironsoft
Cache-Layer-Setup und Magento-Redis-Integration
Magento-Cache, der nicht richtig greift oder falsch konfiguriert ist?
Wir richten Redis als Cache- und Session-Backend für Magento sauber ein, tunen Speicherverbrauch und Eviction-Strategien und sorgen dafür, dass Full Page Cache und Session-Storage zuverlässig zusammenspielen.
Redis-Setup
Cache-, Session- und FPC-Backend produktionsreif für Magento konfigurieren.
Memory-Tuning
Speicherverbrauch und Eviction-Policies auf die tatsächliche Shop-Last abstimmen.
High-Availability-Setup
Redis Sentinel oder Cluster für ausfallsichere Magento-Umgebungen einrichten.
10. Zusammenfassung
Latency Monitor in Redis: Das Wichtigste auf einen Blick
Ergänzt den Slowlog gezielt
Der Latency Monitor erfasst interne Vorgänge wie Fork und Ablaufzyklen, die im Slowlog nicht sichtbar sind.
Ereignisklassen als Diagnose-Achse
command, fork, expire-cycle und weitere Klassen grenzen die Ursache einer Latenzspitze systematisch ein.
LATENCY DOCTOR als Startpunkt
Die automatisierte Analyse erkennt bekannte Muster, ersetzt aber nicht den manuellen Blick in die Details.
Kombination mit Slowlog entscheidend
Erst der gemeinsame Blick auf beide Werkzeuge klärt, ob ein Befehl oder ein interner Prozess die Ursache war.