Setting Up Redis Monitoring with Prometheus (redis_exporter)
We often encounter situations where Redis runs without monitoring — until eviction starts or the database throws LOADING Redis is loading the dataset in memory. By that time, the application begins receiving errors, and Redis has been running in degraded mode for minutes or hours. Eviction can silently delete data, and under the noeviction policy, write requests fail with OOM command not allowed. Without monitoring, you learn about the problem only from users. Our experience shows that proper Redis monitoring via Prometheus and redis_exporter can detect issues 5–10 minutes before they impact production. Over 5 years of work, we have completed more than 50 infrastructure monitoring projects and guarantee that your systems will be under constant surveillance. Monitoring setup saves up to 10 hours of work per month and cuts incident costs in half.
Why Redis monitoring is critical for production?
Redis is an in-memory database, and its state dramatically affects application performance. Even a brief outage can lead to data loss or degraded response times. Key metrics such as memory usage, connection count, and replication status must be continuously tracked. Without this, you risk sudden downtime. For comparison, redis_exporter consumes half the resources of custom monitoring scripts while providing three times more metrics. Prometheus official documentation recommends this exporter for Redis.
Deploying oliver006/redis_exporter
---
services:
redis-exporter:
image: oliver006/redis_exporter:v1.61.0
environment:
REDIS_ADDR: "redis:6379"
REDIS_PASSWORD: "your_redis_password"
ports:
- "9121:9121"
For Redis Sentinel:
REDIS_ADDR: "redis://sentinel1:26379,sentinel2:26379,sentinel3:26379" REDIS_MASTER_NAME: "mymaster" For Redis Cluster — the exporter connects to one node, gathers topology information via CLUSTER INFO and CLUSTER NODES, and collects aggregated cluster metrics. Full documentation is available on GitHub redis_exporter.
Which Redis metrics should you track?
Memory. redis_memory_used_bytes vs redis_config_maxmemory. When used memory approaches maxmemory, Redis activates the eviction policy. If the policy is noeviction — errors OOM command not allowed occur. If allkeys-lru or volatile-lru — data is silently deleted.
redis_memory_used_bytes / redis_config_maxmemory > 0.9 Alerting at 90% is standard practice. But redis_mem_fragmentation_ratio is also important: a value above 1.5 means Redis has allocated 1.5 times more memory from the OS than it actually uses — a typical aftermath of mass key deletion. Memory is fragmented and not returned to the OS.
Eviction and keyspace. redis_evicted_keys_total is a monotonic counter. rate(redis_evicted_keys_total[5m]) > 0 indicates active key eviction right now. For a cache this is acceptable, for session storage or queues — a disaster.
Connections. redis_connected_clients vs redis_config_maxclients (default 10000). An unexpected increase in connected clients under stable load signals a connection leak in the application. Applications without a connection pool open new connections and do not close old ones.
Replication. redis_connected_slaves — number of connected replicas. redis_master_repl_offset and redis_slave_repl_offset on replicas — the difference gives replication lag in bytes. The metric redis_repl_backlog_size determines how long a replica can lag before a full resync.
Comparison of eviction policies
| Policy | Behavior | When to use |
|---|---|---|
| noeviction | OOM error when exceeding maxmemory | When data loss is unacceptable |
| allkeys-lru | Evicts least recently used keys | Large cache |
| volatile-lru | Evicts keys with TTL | Cache with TTL keys |
| allkeys-random | Random eviction | Uniform load |
| volatile-ttl | Evicts keys with nearest TTL | Outdated data should go first |
Step-by-step Redis monitoring setup process
- Assess current infrastructure — determine deployment type (standalone, Sentinel, Cluster) and Redis version.
- Install redis_exporter — deploy the container on the Redis node or a separate server, configure environment variables.
- Add Prometheus configuration — define a target with labels for the exporter.
- Create alert rules — describe alerts based on critical thresholds.
- Import Grafana dashboard — use standard ID
763and customize as needed. - Test and launch — verify metric collection, adjust alert thresholds.
Alerts
groups:
- name: redis
rules:
- alert: RedisDown
expr: redis_up == 0
for: 1m
labels:
severity: critical
- alert: RedisHighMemoryUsage
expr: redis_memory_used_bytes / redis_config_maxmemory > 0.9
for: 5m
labels:
severity: warning
- alert: RedisEviction
expr: increase(redis_evicted_keys_total[5m]) > 0
for: 0m
labels:
severity: warning
annotations:
summary: "Redis evicts keys on {{ $labels.instance }}"
- alert: RedisReplicaMissing
expr: redis_connected_slaves < 1
for: 5m
labels:
severity: critical Grafana dashboard
Dashboard ID 763 (Redis Dashboard for Prometheus Redis Exporter) is the standard. It shows memory, hits/misses ratio, commands per second, keyspace, replication status.
Hit ratio is calculated from redis_keyspace_hits_total and redis_keyspace_misses_total. For a proper cache it should be above 95%. A drop in hit ratio under stable traffic usually indicates eviction or a too-short TTL.
Cluster specifics
In Redis Cluster, the exporter connects to each node separately, or uses the --redis.addr flag with a list of nodes. Metrics redis_cluster_enabled, redis_cluster_slots_ok, redis_cluster_state are available automatically. An alert on redis_cluster_slots_fail > 0 is mandatory for production clusters.
What our service includes
- Analysis of current Redis configuration — identify bottlenecks.
- Deployment of redis_exporter tailored to your environment (Sentinel, Cluster).
- Configuration of alerts on critical metrics (memory, eviction, replication).
- Installation and setup of Grafana dashboard — visualization of all metrics.
- Documentation — description of all settings and instructions for adding new metrics.
- Training for your team — how to interpret metrics and respond to alerts.
Timeline and pricing
Estimated time: 4 to 8 hours, depending on configuration complexity. Price is calculated individually. Contact us for a project assessment.
About the company
We are a team of DevOps engineers with over 5 years of experience. We have completed more than 50 infrastructure monitoring projects. We use only proven solutions and provide a warranty on all work.
Order Redis monitoring setup today and get a consultation on performance optimization. Get a consultation — write to us.







