Monitoring mit redis-cli und INFO systematisch betreiben

1. Warum systematisches Monitoring ohne Zusatztools funktioniert

Viele Teams greifen reflexartig zu einem dedizierten Monitoring-Stack, sobald Redis in Produktion geht, obwohl der Server selbst bereits einen erheblichen Teil der relevanten Metriken liefert. Der INFO-Befehl und redis-cli als Diagnosewerkzeug decken Memory-Verbrauch, Durchsatz, Replikationsstatus, Latenz und Zugriffsmuster ab, ohne dass ein Agent installiert, eine Exporter-Konfiguration gepflegt oder ein zusaetzlicher Netzwerkport geoeffnet werden muss.

Das bedeutet nicht, dass externe Monitoring-Systeme ueberfluessig sind, insbesondere fuer langfristige Trendanalysen und automatisiertes Alerting sind sie oft sinnvoll. Aber fuer die schnelle Diagnose eines akuten Problems, fuer die erste Einschaetzung eines neu aufgesetzten Servers oder fuer Umgebungen, in denen zusaetzliche Software-Installation vermieden werden soll, reicht redis-cli in Kombination mit INFO als vollstaendiges Monitoring-Werkzeug fast immer aus, wenn man systematisch vorgeht statt einzelne Werte isoliert zu betrachten.

2. Die INFO-Sections im Ueberblick

Der Befehl INFO gliedert seine Ausgabe in klar abgegrenzte Sections: Server mit Versions- und Prozessinformationen, Clients mit verbundenen Clients und Blocking-Status, Memory mit Speicherverbrauch und Fragmentierung, Persistence mit RDB- und AOF-Status, Stats mit kumulierten Betriebszahlen, Replication mit Master-Replica-Status, CPU mit Prozessorzeit und Keyspace mit Key-Anzahl pro Datenbank. INFO all liefert saemtliche Sections, waehrend INFO memory gezielt nur die gewuenschte Section ausgibt und damit die Ausgabe fuer Skripte handhabbar haelt.

Diese strukturierte Gliederung ist der eigentliche Grund, warum INFO als Monitoring-Grundlage taugt: Statt einen unstrukturierten Textblock parsen zu muessen, kann jede Section gezielt fuer eine bestimmte Fragestellung abgefragt werden. Wer beispielsweise nur den Replikationsstatus pruefen will, ruft INFO replication auf, statt die vollstaendige, deutlich laengere Ausgabe zu verarbeiten. Diese Modularitaet macht INFO auch fuer Cron-Jobs und einfache Bash-Skripte praktikabel, ohne dass ein JSON-Parser oder eine externe Bibliothek noetig ist.

redis-cli INFO server | head -5
# redis_version:7.2.4
# redis_mode:standalone
# os:Linux 5.15.0-1053-aws x86_64
# process_id:1
# uptime_in_seconds:4823917

redis-cli INFO clients
# connected_clients:342
# blocked_clients:2
# tracking_clients:0
# maxclients:10000

3. Die Memory-Sektion im Detail: used_memory und Fragmentierung

used_memory zeigt den tatsaechlich von Redis fuer Datenstrukturen genutzten Speicher, waehrend used_memory_rss den vom Betriebssystem tatsaechlich zugewiesenen physischen Speicher angibt. Die Differenz zwischen beiden Werten, ausgedrueckt als mem_fragmentation_ratio, zeigt Speicherfragmentierung: Ein Wert deutlich ueber 1.5 signalisiert, dass der Allocator deutlich mehr Speicher vom Betriebssystem reserviert hat, als Redis logisch benoetigt, meist verursacht durch viele kleine Allocations und Deallocations unterschiedlicher Groesse ueber die Zeit.

Ein Wert unter 1.0 ist ebenso ein Warnsignal, aber in die andere Richtung: Er bedeutet, dass Redis mehr Speicher benoetigt, als das Betriebssystem aktuell zugewiesen hat, was typischerweise auf Swapping hindeutet und die Latenz drastisch erhoehen kann. maxmemory und maxmemory_policy aus derselben Section zeigen, ob ein Speicherlimit gesetzt ist und welche Eviction-Strategie bei Erreichen des Limits greift, eine Kombination, die bei jeder Kapazitaetsplanung ueberprueft werden sollte.

redis-cli INFO memory
# used_memory:2147483648
# used_memory_human:2.00G
# used_memory_rss:3435973836
# used_memory_rss_human:3.20G
# mem_fragmentation_ratio:1.60
# maxmemory:4294967296
# maxmemory_human:4.00G
# maxmemory_policy:allkeys-lru
# mem_allocator:jemalloc-5.3.0

# fragmentation_ratio 1.60 -> allocator holds 60% more RSS than logical usage
# consider MEMORY PURGE (jemalloc) or a controlled restart during low traffic

4. Die Stats-Sektion: Hit-Rate, Evictions und Expirations

Die Stats-Section liefert kumulierte Zaehler seit dem letzten Start oder CONFIG RESETSTAT, darunter keyspace_hits und keyspace_misses. Aus diesen beiden Werten berechnet sich die Hit-Rate als keyspace_hits / (keyspace_hits + keyspace_misses), eine der aussagekraeftigsten Kennzahlen fuer Cache-Workloads: Eine Hit-Rate unter 80 Prozent deutet meist auf ein zu klein dimensioniertes Cache-Volumen, eine ungeeignete TTL-Strategie oder ein Zugriffsmuster hin, das sich schlecht fuer Caching eignet.

evicted_keys zaehlt, wie viele Keys aufgrund von maxmemory zwangsweise entfernt wurden, waehrend expired_keys die Anzahl der Keys zaehlt, die regulaer durch Ablauf ihrer TTL entfernt wurden. Ein ploetzlicher Anstieg von evicted_keys ist ein klares Signal, dass entweder mehr Speicher benoetigt wird oder die Datenmenge pro Key ueberprueft werden sollte, waehrend hohe expired_keys-Werte in Kombination mit niedriger Hit-Rate auf zu kurze TTL-Werte hindeuten koennen, die Daten aus dem Cache werfen, bevor sie erneut angefragt werden.

5. redis-cli --stat: der Live-Ueberblick

Waehrend INFO einen Momentaufnahme-Zustand liefert, zeigt redis-cli --stat eine kontinuierlich aktualisierte Tabelle mit Speicherverbrauch, Client-Anzahl, Hit-Rate-relevanten Zaehlern und Operationen pro Sekunde, standardmaessig alle Sekunde aktualisiert. Diese Ansicht eignet sich hervorragend, um live zu beobachten, wie sich der Server unter einer bestimmten Last verhaelt, etwa waehrend eines Lasttests oder direkt nach einem Deployment, ohne ein separates Grafana-Dashboard oeffnen zu muessen.

Besonders nuetzlich ist die Kombination mit einem definierten Interval ueber -i, um die Aktualisierungsfrequenz an die eigene Beobachtungssituation anzupassen. Bei einer akuten Untersuchung eines Latenzproblems liefert eine Sekunde Interval genug Detailgrad, waehrend fuer eine laengere Beobachtung ueber mehrere Minuten ein groesseres Interval die Ausgabe uebersichtlicher haelt, ohne relevante Trends zu verlieren.

redis-cli --stat
# ------- data ------ --------------------- load -------------------- - child -
# keys       mem      clients blocked requests            connections
# 284213     2.10G    342     2       184213 (+0)          8481
# 284215     2.10G    342     2       184298 (+85)         8481
# 284215     2.10G    343     2       184391 (+93)         8482

# Custom interval: sample every 5 seconds for a longer observation window
redis-cli --stat -i 5

6. redis-cli --latency und --latency-history

redis-cli --latency misst kontinuierlich die Round-Trip-Zeit eines PING-Befehls und zeigt Minimum, Maximum, Durchschnitt und Anzahl der Samples in Echtzeit, aktualisiert in jeder Sekunde. Diese Messung erfasst nicht nur Netzwerk-Latenz, sondern auch, wie schnell der Redis-Event-Loop selbst antwortet, was sie zu einem verlaesslichen fruehen Indikator fuer eine Server-seitige Ueberlastung macht, etwa durch einen langlaufenden blockierenden Befehl.

redis-cli --latency-history ergaenzt diese Messung um zeitliche Segmentierung: Statt eines einzigen kontinuierlichen Durchschnitts liefert der Befehl alle 15 Sekunden, konfigurierbar ueber -i, einen neuen Messwertblock. Das erlaubt, Latenzspitzen zeitlich einzugrenzen und mit anderen Ereignissen wie Deployments, Backup-Jobs oder Cron-Ausfuehrungen zu korrelieren, ohne eine externe Zeitreihen-Datenbank zu benoetigen.

redis-cli --latency
# min: 0, max: 12, avg: 0.42 (5231 samples)

redis-cli --latency-history -i 15
# min: 0, max: 1, avg: 0.31 (1500 samples) -- 15.00 seconds range
# min: 0, max: 8, avg: 0.55 (1500 samples) -- 15.00 seconds range
# min: 2, max: 45, avg: 6.21 (1500 samples) -- 15.00 seconds range  <- spike

# Correlate the spike window with concurrent server-side events
redis-cli LATENCY HISTORY command
redis-cli LATENCY LATEST

7. redis-cli --bigkeys und --memkeys fuer Speicheranalyse

redis-cli --bigkeys durchsucht den kompletten Keyspace mittels SCAN, ohne den Server zu blockieren, und identifiziert pro Datentyp den groessten gefundenen Key sowie eine Verteilungsstatistik ueber alle Typen. Das ist der schnellste Weg, um festzustellen, ob ein einzelner ueberdimensionierter Hash, eine riesige Sorted Set oder eine ausufernde Liste fuer einen unverhaeltnismaessigen Teil des Speicherverbrauchs verantwortlich ist, ohne jeden Key einzeln inspizieren zu muessen.

redis-cli --memkeys geht einen Schritt weiter und schaetzt fuer eine Stichprobe von Keys den tatsaechlichen Speicherverbrauch mit MEMORY USAGE, statt nur die Elementanzahl zu betrachten. Ein Hash mit wenigen, aber sehr grossen Werten faellt bei --bigkeys unter Umstaenden nicht auf, waehrend --memkeys ihn korrekt als Speicherfresser identifiziert. Beide Befehle laufen mit niedriger Prioritaet im Hintergrund und eignen sich auch fuer produktive Server, sollten aber wegen der Scan-Last bevorzugt in verkehrsarmen Zeiten ausgefuehrt werden.

8. Eine Monitoring-Routine ohne externe Tools aufbauen

Eine belastbare Monitoring-Routine kombiniert einen regelmaessigen Cron-Job, der INFO abfragt, relevante Werte extrahiert und in eine simple CSV- oder Log-Datei schreibt, mit gelegentlichen manuellen Deep-Dives ueber redis-cli --stat, --latency und --bigkeys bei konkretem Verdacht. Ein minimaler Bash-Ansatz nutzt redis-cli INFO mit anschliessendem grep und awk, um einzelne Werte zu extrahieren und mit Zeitstempel zu protokollieren, ganz ohne Exporter oder Agent.

Wichtig ist dabei, die Rohwerte konsequent mit Zeitstempeln zu versehen, damit spaeter Trends erkennbar werden, statt nur Momentaufnahmen zu haben. Selbst eine simple CSV-Datei mit stuendlichen Werten fuer used_memory, Hit-Rate und connected_clients reicht oft aus, um langsam wachsende Probleme wie eine schleichende Memory-Leckage oder eine sich verschlechternde Hit-Rate frueh zu erkennen, lange bevor sie zu einem akuten Vorfall werden.

#!/usr/bin/env bash
# monitor.sh , minimal Redis health snapshot, no external tools
set -euo pipefail

TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)
INFO=$(redis-cli INFO all)

USED_MEM=$(echo "$INFO" | grep -oP 'used_memory:\K\d+')
FRAG=$(echo "$INFO" | grep -oP 'mem_fragmentation_ratio:\K[0-9.]+')
HITS=$(echo "$INFO" | grep -oP 'keyspace_hits:\K\d+')
MISSES=$(echo "$INFO" | grep -oP 'keyspace_misses:\K\d+')
CLIENTS=$(echo "$INFO" | grep -oP 'connected_clients:\K\d+')

HIT_RATE=$(awk -v h="$HITS" -v m="$MISSES" 'BEGIN { print (h+m>0) ? h/(h+m)*100 : 0 }')

echo "$TIMESTAMP,$USED_MEM,$FRAG,$HIT_RATE,$CLIENTS" >> /var/log/redis-monitor.csv

9. Schwellenwerte und Alerting-Heuristiken festlegen

Monitoring ohne definierte Schwellenwerte bleibt reine Beobachtung, keine Fruehwarnung. Fuer mem_fragmentation_ratio hat sich ein Alarm-Schwellenwert um 1.5 bewaehrt, fuer die Hit-Rate ein Alarm unter 80 Prozent, wobei diese Werte je nach Workload angepasst werden muessen: Ein reiner Session-Store mit kurzen TTLs verhaelt sich strukturell anders als ein Cache fuer selten wechselnde Referenzdaten mit entsprechend hoeherer erwarteter Hit-Rate.

Ein zweiter wichtiger Schwellenwert betrifft connected_clients im Verhaeltnis zu maxclients: Ein Alert bei 80 Prozent Auslastung gibt genug Vorlaufzeit, um zu reagieren, bevor neue Verbindungen mit ERR max number of clients reached abgewiesen werden. Fuer Latenz eignet sich ein rollierender Vergleich des aktuellen redis-cli --latency-Durchschnitts gegen den historischen Durchschnitt derselben Tageszeit, da absolute Schwellenwerte bei stark schwankender Tageslast schnell entweder zu viele oder zu wenige Alerts ausloesen.

10. Zusammenfassung

Systematisches Monitoring mit redis-cli und INFO deckt fast alle Betriebsszenarien ab, ohne dass ein zusaetzliches Tool installiert werden muss. Die INFO-Sections liefern strukturierte Daten zu Memory, Stats, Clients und Replication, wobei mem_fragmentation_ratio und Hit-Rate aus keyspace_hits/keyspace_misses zu den aussagekraeftigsten Einzelwerten gehoeren. redis-cli --stat liefert eine Live-Ansicht, --latency und --latency-history messen Antwortzeiten in Echtzeit und ueber Zeitfenster hinweg.

--bigkeys und --memkeys identifizieren Speicherfresser ohne den Server zu belasten. Eine einfache Cron-basierte Routine, die INFO-Werte mit Zeitstempel protokolliert, macht Trends sichtbar, bevor sie zu akuten Vorfaellen werden. Wer diese Werkzeuge systematisch statt punktuell einsetzt und realistische Schwellenwerte fuer den eigenen Workload definiert, hat ein vollstaendiges Monitoring-Fundament, bevor ueberhaupt ein externes Tool in Betracht gezogen werden muss.

11. FAQ: Monitoring mit redis-cli und INFO