Setting Up Prometheus Monitoring With the Redis Exporter

1. Why INFO alone is not enough for systematic alerting

The INFO command delivers dozens of metrics about memory, connections, persistence, replication, and internal statistics in a single text block, which works well for a one-off manual diagnosis. For automated monitoring over time, though, this text output is unsuitable, since it can be neither historized nor linked to thresholds without someone writing and permanently maintaining a custom parsing script.

The Redis Exporter takes over exactly this translation work: it connects periodically to one or more Redis instances, calls INFO along with supplementary commands, converts the values into the Prometheus metric format, and exposes them via an HTTP endpoint for scraping. That turns a snapshot into a time series that can be visualized in Grafana and linked to Alertmanager rules.

2. Setting up the Redis Exporter and scrape configuration

The Redis Exporter typically runs as its own lightweight container next to the actual Redis instance and needs only the connection details for Redis, plus, if ACL or TLS is in use, the corresponding credentials and certificate paths as environment variables. It holds no state of its own, translating the currently valid values on every scrape.

On the Prometheus side, the exporter is registered as an additional scrape target, and a sensible scrape interval should be based on how quickly the metrics actually change. For most production Redis instances, an interval of fifteen to thirty seconds is enough to catch trends in time without putting unnecessary extra load on the instance through overly frequent INFO calls.

# docker-compose.yaml: Redis Exporter as a standalone service
services:
  redis-exporter:
    image: oliver006/redis_exporter:latest
    environment:
      REDIS_ADDR: "redis://redis:6379"
      REDIS_PASSWORD: "${REDIS_PASSWORD}"
    ports:
      - "9121:9121"

# prometheus.yml: register the scrape target
scrape_configs:
  - job_name: "redis"
    scrape_interval: 15s
    static_configs:
      - targets: ["redis-exporter:9121"]

3. Which metrics the exporter extracts from INFO

Among the most important metrics the exporter provides are redis_memory_used_bytes for actual memory consumption, redis_connected_clients for the current number of active connections, redis_commands_processed_total as a monotonically increasing counter for the total number of processed commands, and redis_keyspace_hits_total together with redis_keyspace_misses_total for computing the cache hit ratio over time.

For replication setups, the exporter additionally provides redis_master_repl_offset on the primary node and redis_slave_repl_offset on each replica, from whose difference the replication lag can be computed. Custom, configurable check commands can also pull in business-relevant figures, such as the length of a specific queue or the number of entries in a specific hash, without having to build a separate metrics pipeline for it.

# Custom business metric: queue length exposed as a Prometheus metric
redis-exporter --check-keys="queue:indexer:*" --check-key-groups="queue"

4. Monitoring multiple Redis instances with a single exporter

Instead of running a dedicated exporter container for every Redis instance, for example a primary node and several replicas, the Redis Exporter supports the so-called multi-target pattern: a single exporter process accepts, via an additional target query parameter, which instance should actually be queried for a given scrape, and Prometheus automatically supplies this parameter on every scrape through a relabel_configs setup.

This pattern noticeably reduces operational overhead, since only a single exporter process needs to be updated and monitored, while still producing distinct, clearly attributable metrics for every individual instance. For a setup with a primary node and several replicas, this makes it possible to directly compare the replication lag of every single replica against the primary node, without having to manually merge the metrics from several separate exporters.

# prometheus.yml: query several Redis instances through one exporter
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 rule for memory usage

One of the most important alerting rules overall concerns the ratio of redis_memory_used_bytes to redis_memory_max_bytes, meaning the configured maxmemory limit. As this ratio approaches the ceiling, Redis starts evicting keys depending on the configured eviction policy, or, without a configured eviction policy, rejects write commands with an error, which for an application like Magento leads to failing cache write operations.

A sensible threshold is a warning starting around seventy five percent utilization and a critical alert starting at ninety percent, with both thresholds averaged over a window of several minutes so a brief load spike is not immediately treated as an incident. A PromQL rule for the warning threshold can be derived directly from the ratio of the two metrics.

# Alertmanager rule: memory usage above 75 percent for 5 minutes
- alert: RedisMemoryHigh
  expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.75
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Redis memory usage above 75 percent"

6. Alerting rule for connection count

The redis_connected_clients metric relative to the configured maxclients limit shows how close an instance is operating to its connection ceiling. Once that limit is reached, Redis consistently refuses new connections, which in a Magento context means PHP-FPM workers can no longer open a new cache or session connection and requests fail.

A sudden, unexpected rise in connection count often points to a problem in the application, such as missing connection pooling configuration or connections not being closed cleanly after an error case, and should therefore trigger an alert not only once the ceiling is reached, but already on a noticeable rise over time, ideally through a rate-based rule instead of a plain threshold.

# Alertmanager rule: connection count close to the configured limit
- alert: RedisConnectionsNearLimit
  expr: redis_connected_clients / redis_config_maxclients > 0.80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Redis approaching its connection limit"

7. Alerting rule for replication lag

Replication lag is computed from the difference between redis_master_repl_offset on the primary node and redis_slave_repl_offset on the respective replica. A growing lag indicates the replica is no longer keeping up with processing incoming write operations, which can lead to a noticeable loss of the most recently written but not yet replicated changes during a subsequent failover.

For production setups, an alert is recommended once the offset difference grows continuously over a fixed time window instead of stagnating or shrinking, since a single brief rise under load is normal, while a persistently growing trend points to a structural problem such as insufficient network bandwidth or an overloaded replica instance.

# Alertmanager rule: replication lag growing continuously
- alert: RedisReplicationLagGrowing
  expr: delta(redis_master_repl_offset[10m]) - delta(redis_slave_repl_offset[10m]) > 0
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "Redis replication lag is growing continuously"

8. Dashboard layout for daily operations

A practical Grafana dashboard is usefully organized into four areas: an overview row with the most important traffic-light figures like memory usage, connection count, and replication status at a glance, a throughput area with commands per second and cache hit ratio over time, a persistence area with the duration of the last RDB snapshot and the AOF write rate, and a replication area with the lag history of every single replica.

What matters for daily operations is that the dashboard shows not only the current state but also makes trends visible over configurable time windows, such as a slow but steady rise in memory usage over several weeks, which points to growing data volume without a correspondingly adjusted eviction policy and would otherwise only be noticed once the ceiling was actually reached.

9. Securing the exporter itself in operation

The Redis Exporter only needs read access to the instance for its work, which is why, combined with the ACL system from Redis 6, a dedicated user strictly limited to @read can be created for the exporter, instead of running it with the same credentials as the application services. That keeps the damage in case of a compromised monitoring component limited to plain read rights.

In addition, the exporter's HTTP metrics endpoint itself should not be publicly reachable, but restricted to the same network segment as the Prometheus server, ideally further secured via TLS, since this endpoint would otherwise indirectly expose information about the internal infrastructure such as memory usage and connection patterns to the outside.

10. Summary

11. FAQ: Redis Exporter: Key Takeaways