Redis Monitoring: Hit Rate, Speicher und Command-Latenz
Sehen Sie Cache Hit Ratio, Speicher, Evictions, Command-Latenz und Replikation jeder Redis-Instanz und welcher Service betroffen ist, wenn der Cache aus dem Takt gerät.
Warum Redis mit Obseria überwachen
Cache-Wirkung in einer Zahl
Keyspace Hits und Misses ergeben eine Hit Ratio pro Instanz. Sie merken, wann der Cache Ihre Datenbank nicht mehr entlastet.
Speicher, bevor es wehtut
Belegter Speicher gegenüber maxmemory, Fragmentierung und Evictions zeigen Speicherdruck, bevor die Latenz steigt oder Keys verschwinden.
Latenz mit Ursache
Command-Latenz neben Fork-Zeiten, blockierten Clients und den Spans der aufrufenden Services erklärt, warum ein Millisekunden-Cache langsam wurde.
Redis-Komponenten, die Obseria überwacht
- Keyspace. Keys und Keys mit Ablaufzeit pro Datenbank, durchschnittliche TTL, Hits, Misses, abgelaufene und verdrängte Keys.
- Speicher. Belegter, RSS-, Spitzen- und Lua-Speicher, Fragmentierungsgrad und konfiguriertes maxmemory.
- Clients und Verbindungen. Verbundene und blockierte Clients, angenommene und abgewiesene Verbindungen, Client-Puffergrößen.
- Commands. Verarbeitete Commands, Operationen pro Sekunde sowie Aufrufe und Latenz pro Command-Typ.
- Persistenz und Replikation. Änderungen seit dem letzten RDB-Save, Dauer des letzten Forks, Replikations-Offset und verbundene Replikas.
- Redis Cluster und Sentinel. Cluster-Zustand, Slot-Zuweisung und bekannte Nodes sowie Sentinel-Master und Tilt-Ereignisse.
Die Redis-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Wirksamkeit des Caches
Zeigt, wie oft angefragte Daten im Cache gefunden werden, was direkt bestimmt, wie schnell sich Ihre Anwendung anfühlt.
Nutzung des Speichers
Zeigt, wie voll der Cache ist, ob Daten verdrängt werden und wie effizient der Arbeitsspeicher genutzt wird.
Verbindungen der Anwendungen
Macht sichtbar, wie viele Anwendungen verbunden sind und ob neue Verbindungen in Spitzenzeiten abgewiesen werden.
Schnelle Antwortzeiten
Hebt langsame Befehle und kurze Pausen beim Sichern im Hintergrund hervor, die für Ihre Nutzer spürbare Verzögerungen verursachen.
Alle 10 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
redis.keyspace.hits | {hit} | Erfolgreiche Key-Lookups; zusammen mit Misses ergibt sich die Cache Hit Ratio. |
redis.keyspace.misses | {miss} | Fehlgeschlagene Lookups, die meist bei der Datenbank dahinter landen. |
redis.memory.used | By | Von Redis für Daten und Overhead belegter Speicher. |
redis.maxmemory | By | Konfiguriertes Speicherlimit; nahe daran beginnen Evictions. |
redis.keys.evicted | {key} | Keys, die wegen Erreichen von maxmemory entfernt wurden. |
redis.memory.fragmentation_ratio | 1 | RSS geteilt durch belegten Speicher; hohe Werte verschwenden RAM, Werte unter 1 bedeuten Swapping. |
redis.clients.connected | {client} | Client-Verbindungen ohne Replikas. |
redis.connections.rejected | {connection} | Wegen Erreichen von maxclients abgewiesene Verbindungen. |
redis.cmd.latency | s | Latenz pro Command-Typ, um langsame Commands wie KEYS oder große Range-Reads zu finden. |
redis.latest_fork | us | Dauer des letzten Forks für RDB oder AOF-Rewrite; lange Forks blockieren die Event Loop. |
Redis-Monitoring in wenigen Minuten einrichten
- Schritt 1
Zugriff vorbereiten
Legen Sie einen ACL-User an, der INFO ausführen darf, oder nutzen Sie das bestehende Passwort, und hinterlegen Sie es als Umgebungsvariable.
- Schritt 2
redis-Receiver konfigurieren
Ergänzen Sie den redis-Receiver im OpenTelemetry Collector oder Obseria Agent und aktivieren Sie optionale Metriken wie maxmemory und Command-Latenz.
- Schritt 3
Aufrufer verbinden
Instrumentieren Sie die Services, die Redis nutzen, mit OpenTelemetry, damit Cache-Spans in Traces neben Datenbankaufrufen erscheinen.
receivers:
redis:
endpoint: redis-primary:6379
password: ${env:REDIS_PASSWORD}
collection_interval: 10s
tls:
insecure: false
ca_file: /etc/otel/redis-ca.pem
metrics:
redis.maxmemory:
enabled: true
redis.cmd.latency:
enabled: true
redis.role:
enabled: true
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [redis]
exporters: [otlphttp]
Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Redis-Übersicht: Hit Ratio, Ops pro Sekunde, Clients
- Speicher, Fragmentierung und Evictions
- Command-Latenz nach Command-Typ
- Alert: Speicher über 90 % von maxmemory
- Alert: Hit Ratio unter Baseline oder abgewiesene Verbindungen
Redis-Monitoring: Darauf kommt es an
Warum Redis Monitoring wichtig ist
Redis ist meist die schnellste Komponente im Request-Pfad: Cache vor einer Datenbank, Session Store, Rate Limiter oder Queue. Weil Redis schnell und zuverlässig ist, bemerken Teams Probleme oft nur indirekt, als höhere Datenbanklast oder langsamere APIs. Läuft Redis der Speicher aus, verdrängt es häufig genutzte Keys oder blockiert es an einem langsamen Command, leiden alle abhängigen Services gleichzeitig. Redis Monitoring macht solche Situationen früh sichtbar.
Obseria erfasst Metriken mit dem redis-Receiver des OpenTelemetry Collectors, der die Ausgabe des Commands INFO liest. Spans aus der OpenTelemetry-Instrumentierung der Redis-Clients ergänzen die Sicht der aufrufenden Services.
Die Redis-Metriken, auf die es ankommt
Cache Hit Ratio
Die Hit Ratio ist redis.keyspace.hits / (redis.keyspace.hits + redis.keyspace.misses). Für einen Cache ist das die wichtigste Zahl. Sinkt sie, erreichen mehr Requests die Datenbank. Ursachen sind zu kurze TTLs, unter Speicherdruck verdrängte Keys oder ein neues Zugriffsmuster nach einem Deployment.
Speicher und Evictions
Redis hält alles im Arbeitsspeicher. Vergleichen Sie redis.memory.used mit redis.maxmemory. Ist das Limit erreicht, entfernt die Eviction Policy Keys, und redis.keys.evicted steigt. Für einen reinen Cache mit LRU-Policy kann eine stetige Eviction-Rate akzeptabel sein; für einen Session Store ist jede Eviction Datenverlust. Ein redis.memory.fragmentation_ratio deutlich über 1 verschwendet RAM, ein Wert unter 1 bedeutet, dass das Betriebssystem Redis-Speicher auslagert.
Latenz und Blockierung
Redis führt Commands auf einem einzigen Haupt-Thread aus. Ein langsamer Command blockiert alle anderen. redis.cmd.latency pro Command-Typ zeigt teure Aufrufe wie KEYS, große SMEMBERS- oder LRANGE-Reads. redis.latest_fork zeigt, wie lange der letzte Fork für die Persistenz dauerte; bei großen Instanzen kann das den Server spürbar anhalten.
Clients und Replikation
redis.clients.connected, redis.clients.blocked und redis.connections.rejected zeigen Verbindungslecks und Limits. redis.replication.offset auf Primary und Replikas zeigt den Fortschritt der Replikation.
Typische Probleme und wie Sie sie erkennen
- Speicher erschöpft: Der belegte Speicher nähert sich maxmemory, Evictions steigen, die Hit Ratio fällt. Alarmieren Sie bei 90 % und prüfen Sie TTLs und große Keys.
- Langsame Commands: Latenzspitzen bei allen Commands gleichzeitig gehen meist auf einen teuren Command-Typ zurück. Prüfen Sie die Latenz pro Command und das Slow Log.
- Persistenz-Stillstand: Lange Forks bei RDB-Snapshots oder AOF-Rewrites, oft auf Instanzen ohne genügend freien Speicher für Copy-on-Write.
- Verbindungslecks: Die verbundenen Clients wachsen nach jedem Deployment, bis
maxclientsneue abweist. - Cache Stampede: Viele Keys laufen gleichzeitig ab, und die Datenbank erhält eine Welle von Misses. Korrelieren Sie Misses mit der Datenbanklast.
Best Practices für Redis Monitoring
- Setzen Sie immer
maxmemoryund eine Eviction Policy, die zum Anwendungsfall passt. - Überwachen Sie die Hit Ratio pro Instanz und Anwendungsfall; Session Store und Seiten-Cache brauchen unterschiedliche Schwellwerte.
- Versehen Sie TTLs mit Jitter, um gleichzeitiges Ablaufen zu vermeiden.
- Deaktivieren oder benennen Sie gefährliche Commands wie
KEYSin Produktion um und beobachten Sie die Latenz pro Command. - Erfassen Sie Metriken alle 10 Sekunden; Redis-Probleme entwickeln sich schnell.
So unterstützt Obseria Ihr Redis Monitoring
Obseria führt Redis-Metriken, Host-Metriken und die Redis-Spans Ihrer Services in Obseria Lake zusammen. TopoGraph zeigt, welche Services von welcher Redis-Instanz abhängen, sodass ein Speicher- oder Latenz-Alert die betroffenen Anwendungen nennt. Obseria Intelligence korreliert eine sinkende Hit Ratio mit Deployments, steigender Datenbanklast und Evictions und legt die wahrscheinliche Ursache mit einer Beweiskette dar. Für Managed-Angebote wie Amazon ElastiCache, Azure Cache for Redis oder Google Cloud Memorystore ergänzen die agentenlosen Cloud-Integrationen die Metriken des Anbieters. Dashboards, Alerts und SLOs sind enthalten, und Sie fragen alles mit OQL, PromQL oder SQL ab.
Ein hilfreiches Muster: Stellen Sie die Redis Hit Ratio und die Query-Rate der Datenbank dahinter auf dasselbe Dashboard. Sinkt die Hit Ratio im selben Moment, in dem die Datenbanklast steigt, ist der Cache die Ursache, und die Traces der betroffenen Requests zeigen, welche Keys und Endpunkte beteiligt sind.
Verwandte Integrationen
Passende Funktionen
Datenbank-Monitoring
Finden Sie die langsame Query hinter dem langsamen Endpunkt. Obseria verknüpft Datenbankmetriken, Query-Performance und Logs mit den Traces und Services, die sie aufrufen.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Was ist ein SLO (Service Level Objective)?
Was ist ein SLO? So funktionieren SLIs, SLOs, SLAs und Error Budgets: Berechnung, sinnvolle Zielwerte und Burn-Rate-Alerting mit Beispielen.
Häufige Fragen zum Redis-Monitoring
Teilen Sie redis.keyspace.hits durch die Summe aus redis.keyspace.hits und redis.keyspace.misses im selben Intervall. Obseria zeigt diese Ratio pro Instanz direkt an.
Ja. Der redis-Receiver bietet optionale Cluster-Metriken wie Cluster-Zustand und Slot-Zuweisung sowie Sentinel-Metriken wie überwachte Master und Tilt-Ereignisse.
Ja. Nutzen Sie die agentenlosen Cloud-Integrationen für die Metriken des Anbieters und, wo der Netzwerkzugriff es erlaubt, den redis-Receiver für INFO-basierte Metriken.
Speicher über 90 % von maxmemory, eine Hit Ratio unter der üblichen Baseline, abgewiesene Verbindungen über 0 und Command-Latenz über Ihrem SLO.
Der Receiver führt den Command INFO im eingestellten Intervall aus. Das ist leichtgewichtig und auch alle 10 Sekunden auf Produktionsinstanzen unbedenklich.
Starten Sie heute mit dem Redis-Monitoring
Binden Sie Redis in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.