Redis Exporter

Last reviewed Sep 13, 2026 · 778 words

Redis Exporter is a 64 MB Go sidecar that turns INFO output into a few hundred Prometheus series, and the only ones you will ever page on are memory used against maxmemory, evicted keys per second, and rejected connections. Everything else on the companion Grafana dashboard is context. Wire those three into alerts and you have caught roughly every Redis incident I have seen on a homelab or a small production box: the cache that silently became a database, the app that leaked connections, and the host that ran out of RAM under it.

One exporter can scrape every Redis you own

The default mode is one exporter per Redis: point REDIS_ADDR at it and scrape port 9121. That is fine for a single instance. Once you have 3 or more (a cache for Nextcloud, a queue for Paperless-ngx, a session store for something else), switch to multi-target mode instead. The exporter exposes a /scrape?target=redis://host:6379 endpoint, so Prometheus can treat it the way it treats the blackbox exporter and pass each target in through relabelling:

scrape_configs:
  - job_name: redis
    metrics_path: /scrape
    static_configs:
      - targets:
          - redis://cache.lan:6379
          - redis://queue.lan:6379
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: redis-exporter:9121

One container, one image to update, N instances monitored. Passwords go in REDIS_PASSWORD for the single-target case or in a REDIS_PASSWORD_FILE JSON map keyed by address for multi-target, which keeps them out of the Prometheus config entirely.

The metrics that predict trouble

redis_memory_used_bytes / redis_memory_max_bytes is the one to graph first. If maxmemory is 0 the ratio is meaningless, and that itself is a finding: Redis with no memory cap will eventually take the whole machine, and the OOM killer does not pick politely. rate(redis_evicted_keys_total[5m]) above 0 on a cache is normal; above 0 on a queue or session store means you have lost data and should read the eviction policy again. redis_rejected_connections_total climbing means maxclients is exhausted, almost always by an application not closing connections. For replication, redis_master_repl_offset minus the replica's own offset gives lag in bytes, and redis_connected_slaves dropping to 0 is worth a page. Hit ratio, redis_keyspace_hits_total against redis_keyspace_misses_total, is nice to know and rarely actionable.

Per-key tracking is a trap at scale

The --check-keys and --check-single-keys flags let you export the length or value of specific keys, which is genuinely useful for a queue depth (--check-single-keys=queue:default). The glob form runs SCAN on every scrape, and on a database with millions of keys that is a measurable CPU hit every 15 seconds. Keep it to exact key names, keep the list short, and never enable a wildcard pattern on anything you care about. The same caution applies to --export-client-list, which emits one series per connected client and can multiply your cardinality by a few hundred overnight.

Cluster and Sentinel need a little help

Redis Cluster works if you set --is-cluster so the exporter follows the topology, but each node still needs its own scrape, which multi-target mode handles cleanly. Sentinel is simpler: point the exporter at the Sentinel port and you get redis_sentinel_* series describing masters, quorum and failovers. What you do not get from either is a picture of the cluster as one thing; that is a Grafana job, and the dashboard the project links (Grafana ID 763) does it well enough that I have never built my own.

It does nothing without the rest of the stack

The two listed cons are the same con: this is a metrics source, not a monitoring product. You need Prometheus to store the series, Grafana to look at them, and Alertmanager to be told about them. If that stack is not already running for node-exporter, Redis is a strange place to start; the host metrics matter more. If you want a Redis GUI to browse keys and run commands, this is not it either. The comparison with RedisInsight is misleading: one is a workbench, the other is a probe.

What I'd do

Run one oliver006/redis_exporter container in multi-target mode next to Prometheus, add every Redis you own as a redis:// target, import dashboard 763, and write exactly three alerts: memory above 90 percent of maxmemory for 10 minutes, any evictions on a non-cache instance, and redis_up == 0 for 2 minutes. Leave per-key checks off until you have a specific queue to watch. That is a 20-minute job that pays for itself the first time an app leaks connections at 3 a.m.