Prometheus-Monitoring mit dem Redis Exporter richtig aufsetzen

1. Warum INFO allein für systematisches Alerting nicht reicht

Der Befehl INFO liefert dutzende Kennzahlen zu Speicher, Verbindungen, Persistenz, Replikation und internen Statistiken in einem einzigen Textblock, der sich für eine punktuelle manuelle Diagnose gut eignet. Für ein automatisiertes Monitoring über Zeit ist diese Textausgabe jedoch ungeeignet, weil sie weder historisiert noch mit Schwellwerten verknüpft werden kann, ohne dass jemand ein eigenes Parsing-Skript schreibt und dauerhaft pflegt.

Der Redis Exporter übernimmt genau diese Übersetzungsarbeit: Er verbindet sich periodisch mit einer oder mehreren Redis-Instanzen, ruft INFO sowie ergänzende Befehle ab, wandelt die Werte in das Prometheus-Metrikformat um und stellt sie über einen HTTP-Endpunkt zum Abruf bereit. Damit wird aus einer Momentaufnahme eine Zeitreihe, die sich in Grafana visualisieren und mit Alertmanager-Regeln verknüpfen lässt.

2. Setup des Redis Exporter und Scrape-Konfiguration

Der Redis Exporter läuft typischerweise als eigener, schlanker Container neben der eigentlichen Redis-Instanz und benötigt lediglich die Verbindungsdaten zu Redis sowie, falls ACL oder TLS im Einsatz sind, die entsprechenden Zugangsdaten und Zertifikatspfade als Umgebungsvariablen. Er selbst hält keinen eigenen Zustand vor, sondern übersetzt bei jedem Abruf die aktuell gültigen Werte.

Auf Seiten von Prometheus wird der Exporter als zusätzliches Scrape-Target eingetragen, wobei sich ein sinnvolles Scrape-Intervall an der tatsächlichen Änderungsgeschwindigkeit der Metriken orientieren sollte. Für die meisten produktiven Redis-Instanzen reicht ein Intervall von fünfzehn bis dreißig Sekunden aus, um Trends rechtzeitig zu erkennen, ohne die Instanz durch zu häufige INFO-Abrufe unnötig zu belasten.

# docker-compose.yaml: Redis Exporter als eigenständiger Dienst
services:
  redis-exporter:
    image: oliver006/redis_exporter:latest
    environment:
      REDIS_ADDR: "redis://redis:6379"
      REDIS_PASSWORD: "${REDIS_PASSWORD}"
    ports:
      - "9121:9121"

# prometheus.yml: Scrape-Target eintragen
scrape_configs:
  - job_name: "redis"
    scrape_interval: 15s
    static_configs:
      - targets: ["redis-exporter:9121"]

3. Welche Metriken der Exporter aus INFO extrahiert

Zu den wichtigsten vom Exporter bereitgestellten Metriken zählen redis_memory_used_bytes für den tatsächlichen Speicherverbrauch, redis_connected_clients für die aktuelle Anzahl aktiver Verbindungen, redis_commands_processed_total als monoton wachsender Zähler für die Gesamtzahl verarbeiteter Befehle und redis_keyspace_hits_total sowie redis_keyspace_misses_total zur Berechnung der Cache-Trefferquote über die Zeit.

Für Replikationssetups liefert der Exporter zusätzlich redis_master_repl_offset auf dem Primärknoten und redis_slave_repl_offset auf jedem Replikat, aus deren Differenz sich der Replikations-Lag berechnen lässt. Über eigene, konfigurierbare Prüfbefehle lassen sich zudem gezielt Business-relevante Kennzahlen einbinden, etwa die Länge einer bestimmten Warteschlange oder die Anzahl der Einträge in einem bestimmten Hash, ohne dafür eine eigene Metrik-Pipeline programmieren zu müssen.

# Eigene Business-Metrik: Länge einer Warteschlange als Prometheus-Metrik
redis-exporter --check-keys="queue:indexer:*" --check-key-groups="queue"

4. Mehrere Redis-Instanzen mit einem einzigen Exporter überwachen

Statt für jede Redis-Instanz, etwa Primärknoten und mehrere Replikate, einen eigenen Exporter-Container zu betreiben, unterstützt der Redis Exporter das sogenannte Multi-Target-Muster: Ein einzelner Exporter-Prozess nimmt über einen zusätzlichen target-Query-Parameter entgegen, welche Instanz für den jeweiligen Scrape tatsächlich abgefragt werden soll, und Prometheus übergibt diesen Parameter über eine relabel_configs-Konfiguration automatisch bei jedem Scrape-Durchlauf.

Dieses Muster reduziert den Betriebsaufwand spürbar, weil nur ein einziger Exporter-Prozess aktualisiert und überwacht werden muss, während trotzdem für jede einzelne Instanz eigene, klar zuordenbare Metriken entstehen. Für ein Setup mit Primärknoten und mehreren Replikaten lässt sich damit der Replikations-Lag jedes einzelnen Replikats gegenüber dem Primärknoten unmittelbar vergleichen, ohne die Metriken mehrerer getrennter Exporter manuell zusammenführen zu müssen.

# prometheus.yml: mehrere Redis-Instanzen über einen Exporter abfragen
scrape_configs:
  - job_name: "redis-multi"
    static_configs:
      - targets:
          - "redis://primary:6379"
          - "redis://replica-1:6379"
          - "redis://replica-2:6379"
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: redis-exporter:9121

5. Alerting-Regel für Speicherauslastung

Eine der wichtigsten Alerting-Regeln überhaupt betrifft das Verhältnis von redis_memory_used_bytes zu redis_memory_max_bytes, also der konfigurierten maxmemory-Grenze. Nähert sich dieses Verhältnis der Obergrenze, beginnt Redis je nach konfigurierter Eviction-Policy Schlüssel zu verdrängen oder, ohne konfigurierte Eviction-Policy, Schreibbefehle mit einem Fehler abzulehnen, was für eine Anwendung wie Magento zu fehlschlagenden Cache-Schreibvorgängen führt.

Ein sinnvoller Schwellwert liegt bei einer Warnung ab etwa fünfundsiebzig Prozent Auslastung und einem kritischen Alarm ab neunzig Prozent, wobei beide Schwellwerte über ein Zeitfenster von mehreren Minuten gemittelt werden sollten, um kurzzeitige Lastspitzen nicht sofort als Störung zu werten. Eine PromQL-Regel für die Warnschwelle lässt sich direkt aus dem Verhältnis der beiden Metriken ableiten.

# Alertmanager-Regel: Speicherauslastung über 75 Prozent für 5 Minuten
- alert: RedisMemoryHigh
  expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.75
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Redis-Speicherauslastung über 75 Prozent"

6. Alerting-Regel für die Verbindungsanzahl

Die Metrik redis_connected_clients im Verhältnis zur konfigurierten maxclients-Grenze zeigt an, wie nah eine Instanz an ihrem Verbindungslimit operiert. Wird dieses Limit erreicht, lehnt Redis neue Verbindungen konsequent ab, was in einem Magento-Kontext bedeutet, dass PHP-FPM-Worker keine neue Cache- oder Session-Verbindung mehr aufbauen können und Requests mit Fehlern enden.

Ein plötzlicher, unerwarteter Anstieg der Verbindungsanzahl deutet häufig auf ein Problem in der Anwendung hin, etwa fehlende Connection-Pooling-Konfiguration oder nicht sauber geschlossene Verbindungen nach einem Fehlerfall, und sollte deshalb nicht nur bei Erreichen der Obergrenze, sondern bereits bei einem auffälligen Anstieg über die Zeit einen Alarm auslösen, idealerweise über eine Rate-basierte Regel statt eines reinen Schwellwerts.

# Alertmanager-Regel: Verbindungsanzahl nahe dem konfigurierten Limit
- alert: RedisConnectionsNearLimit
  expr: redis_connected_clients / redis_config_maxclients > 0.80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Redis nähert sich dem Verbindungslimit"

7. Alerting-Regel für Replikations-Lag

Der Replikations-Lag berechnet sich aus der Differenz zwischen redis_master_repl_offset auf dem Primärknoten und redis_slave_repl_offset auf dem jeweiligen Replikat. Ein wachsender Lag deutet darauf hin, dass das Replikat mit der Verarbeitung eingehender Schreiboperationen nicht mehr Schritt hält, was bei einem anschließenden Failover zu einem spürbaren Datenverlust der zuletzt geschriebenen, aber noch nicht replizierten Änderungen führen kann.

Für produktive Setups empfiehlt sich ein Alarm, sobald der Offset-Unterschied über einen festen Zeitraum hinweg kontinuierlich wächst statt zu stagnieren oder zu sinken, weil ein einmaliger kurzer Anstieg unter Last normal ist, ein dauerhaft wachsender Trend jedoch auf ein strukturelles Problem wie unzureichende Netzwerkbandbreite oder eine überlastete Replikat-Instanz hindeutet.

# Alertmanager-Regel: Replikations-Lag wächst kontinuierlich
- alert: RedisReplicationLagGrowing
  expr: delta(redis_master_repl_offset[10m]) - delta(redis_slave_repl_offset[10m]) > 0
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "Redis-Replikations-Lag wächst kontinuierlich"

8. Dashboard-Aufbau für den täglichen Betrieb

Ein praxistaugliches Grafana-Dashboard gliedert sich sinnvollerweise in vier Bereiche: eine Übersichtszeile mit den wichtigsten Ampel-Kennzahlen wie Speicherauslastung, Verbindungsanzahl und Replikations-Status auf einen Blick, einen Bereich für Durchsatz mit Befehlen pro Sekunde und Cache-Trefferquote über die Zeit, einen Bereich für Persistenz mit der Dauer des letzten RDB-Snapshots und der AOF-Schreibrate, sowie einen Bereich für Replikation mit dem Lag-Verlauf jedes einzelnen Replikats.

Wichtig für den täglichen Betrieb ist, dass das Dashboard nicht nur den aktuellen Zustand zeigt, sondern über konfigurierbare Zeitfenster auch Trends sichtbar macht, etwa eine langsam, aber stetig steigende Speicherauslastung über mehrere Wochen, die auf ein wachsendes Datenvolumen ohne entsprechend angepasste Eviction-Policy hindeutet und sonst erst beim tatsächlichen Erreichen der Obergrenze auffallen würde.

9. Den Exporter selbst im Betrieb absichern

Der Redis Exporter benötigt für seine Arbeit lediglich Lesezugriff auf die Instanz, weshalb sich in Kombination mit dem ACL-System aus Redis 6 ein eigener, streng auf @read beschränkter Benutzer für den Exporter anlegen lässt, statt ihn mit denselben Zugangsdaten wie die Anwendungsdienste zu betreiben. Damit bleibt der Schaden im Fall einer kompromittierten Monitoring-Komponente auf reine Leserechte begrenzt.

Zusätzlich sollte der HTTP-Metrik-Endpunkt des Exporters selbst nicht öffentlich erreichbar sein, sondern ausschließlich innerhalb desselben Netzwerksegments wie der Prometheus-Server, idealerweise zusätzlich über TLS abgesichert, da über diesen Endpunkt sonst indirekt Informationen über die interne Infrastruktur wie Speicherauslastung und Verbindungsmuster nach außen sichtbar würden.

10. Zusammenfassung

11. FAQ: Redis Exporter: Das Wichtigste auf einen Blick