Learning Redis - Monitoring & Observability (Prometheus & Grafana)

#Introduction

Redis might run smoothly today — but production demands evidence, not hope. Episode 18 covers monitoring and observability: how to inspect Redis health in real time, export its metrics to a modern monitoring system, and trigger alerts before a problem becomes an incident.

You'll learn three layers: reading INFO directly from Redis, bridging metrics to Prometheus with redis_exporter, then visualizing and alerting in Grafana. By the end of the episode, you'll have a dashboard template ready for production.

#Monitoring Health with INFO

#Six Key Sections

INFO is the gateway to observability. The command can be narrowed per section:

INFO per section

redis-cli INFO clients
redis-cli INFO stats
redis-cli INFO memory
redis-cli INFO replication

INFO clients shows active connections (connected_clients) and blocked ones. INFO stats gives total_commands_processed, keyspace_hits, and keyspace_misses. INFO memory uses used_memory and maxmemory. INFO replication shows master_link_status and replica lag. The combination of these four sections answers 80% of Redis health questions.

#Hit Ratio

One of the most valuable metrics: the cache hit ratio. It's calculated from two counters:

Cache hit ratio formula

hit_ratio = keyspace_hits / (keyspace_hits + keyspace_misses)

A value above 0.95 is generally healthy; a sharp drop means the cache is rarely used — TTL too short, or the workload doesn't fit a cache pattern. This metric is usually placed at the top of the dashboard.

#MONITOR: Be Careful

MONITOR shows every command passing through live — very useful for debugging, but dangerous in production:

Stream live commands

redis-cli MONITOR

redis-cli MONITOR prints every command in real time. The problem: MONITOR adds heavy overhead on high-traffic servers, and can be a leak of sensitive information. The rule: only for short debugging sessions, never left running in production — it's usually disabled via ACL.

#The Prometheus Ecosystem

#Running redis_exporter

Redis doesn't export metrics in Prometheus format — redis_exporter (the oliver006/redis_exporter project) bridges the two. Run it as a sidecar or service:

Run redis_exporter via Docker

docker run -d --name redis-exporter \
  -p 9121:9121 \
  -e REDIS_ADDR=redis://127.0.0.1:6379 \
  oliver006/redis_exporter:latest

docker run ... oliver006/redis_exporter makes the exporter listen on port 9121 and pull metrics from Redis at REDIS_ADDR. The endpoint http://localhost:9121/metrics now serves all metrics in Prometheus format.

#Scrape Configuration in Prometheus

Tell Prometheus which endpoints to scrape:

prometheus.yml

scrape_configs:
  - job_name: redis
    static_configs:
      - targets: ["redis-exporter:9121"]

targets: ["redis-exporter:9121"] registers the exporter. Prometheus will scrape metrics periodically and store them for querying. For Redis Cluster, register all nodes or use --redis-only-master for compact metrics.

#Important Metrics to Watch

#Top Candidates

A few metrics that most often trigger alarms:

redis_connected_clients: an unusual spike can indicate a connection leak.
redis_memory_used_bytes vs redis_memory_max_bytes: nearing the limit = imminent eviction.
redis_evicted_keys_total: continuously rising = maxmemory set too low.
redis_keyspace_hits_total / redis_keyspace_misses_total: the basis of the hit ratio.
redis_connected_slaves and redis_master_last_io_seconds_ago: replication health.
redis_slowlog_length: the number of queued slow commands.

#Grafana Dashboard

In Grafana, import the official community dashboard (e.g. ID 763) which already arranges all the metrics above into panels: memory, clients, hit ratio, eviction, and replication. The flow:

Redis metric flow

redis ──> redis_exporter :9121 ──> prometheus ──> grafana (query + alert)

You just add a Prometheus data source in Grafana and select the dashboard. For production, a custom dashboard with hit ratio and eviction panels is usually the most viewed.

#Alerting

#Sensible Alert Rules

Data on a dashboard is useless without timely alerts. Examples of common rules:

Alert rules for Redis

groups:
  - name: redis.rules
    rules:
      - alert: RedisMemoryHigh
        expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.85
        for: 10m
        labels:
          severity: warning

expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.85 triggers the RedisMemoryHigh alert when memory usage is above 85% for 10 minutes. A few other recommended rules:

Low hit ratio: keyspace_hits / (hits + misses) < 0.5 for 30 minutes.
High replication lag: master_last_io_seconds_ago > 60.
High eviction: rate(redis_evicted_keys_total[5m]) > 0 consistently.
Server down: up{job="redis"} == 0.

Info

A good alert tells an action, not just a number: "85% memory" is more useful when you already know what to do — choose a more aggressive eviction policy, raise maxmemory, or shorten TTLs. Episode 19 prepares those steps.

#Summary

Episode 18 equipped you with end-to-end observability: reading INFO sections, understanding MONITOR's risks, exporting metrics via redis_exporter to Prometheus, visualizing in Grafana, and building alerting for memory, hit ratio, and replication lag.

Key takeaways:

INFO clients, INFO stats, INFO memory, INFO replication answer 80% of Redis health questions.
Hit ratio = keyspace_hits / (hits + misses); below 0.5 is a problem signal.
MONITOR is only for short debugging — dangerous and disabled in production.
redis_exporter on port 9121 bridges Redis to Prometheus.
Watch connected_clients, memory vs maxmemory, evicted_keys, and replication lag.
The official Grafana dashboard (ID 763) provides ready-to-use visualization.
Alerts should be specific and actionable, e.g. memory > 85% for 10 minutes.

In the next episode, episode 19, we cover Troubleshooting & Operational Maintenance — facing real problems. You'll learn to handle high latency spikes, OOM errors, connection exhaustion, replication disconnects, scheduling BGSAVE/BGREWRITEAOF, rolling upgrades, and disaster recovery procedures. Ready to be on call?