P-11 — Monitoring and Observability

Who this module is for: You have a Redis instance in production but no visibility into what it is doing — what commands are slow, whether memory is healthy, how close you are to hitting limits. This module covers the full observability surface: INFO sections, SLOWLOG, LATENCY, MONITOR, and the 10 metrics every Redis dashboard must include.

The INFO Command

INFO is the primary observability tool. It returns a structured plaintext report across multiple sections. You can request all sections or a specific one:

INFO server

uptime_in_seconds matters for fragmentation analysis — fragmentation grows over time and a very long uptime with high key churn warrants active defragmentation.

INFO clients

Watch connected_clients approaching maxclients. Watch client_recent_max_output_buffer — a large output buffer means slow clients accumulating data faster than they read.

INFO stats — The Most Important Section

Cache hit rate = keyspace_hits / (keyspace_hits + keyspace_misses)

For the example above: 921847392 / (921847392 + 26426449) = 97.2% — healthy.

Below 90%: investigate why. Causes: TTLs too short, maxmemory too small, cache warming not working, wrong key patterns.

evicted_keys > 0: Your cache is under memory pressure. Redis is actively deleting data to make room. Increase maxmemory or reduce your dataset.

rejected_connections > 0: You have hit maxclients. Increase the limit or fix connection leaks.

INFO replication

lag = replication lag in seconds for each replica. A non-zero lag means the replica is behind.

repl_backlog_size — if a replica disconnects and reconnects with an offset that is no longer in the backlog, it requires a full resync (expensive). Increase repl-backlog-size if replicas frequently reconnect: CONFIG SET repl-backlog-size 64mb.

INFO keyspace

expires vs keys ratio — if expires << keys, most of your keys have no TTL. For a cache, this is a problem: memory fills up without natural eviction.

avg_ttl — average remaining TTL in milliseconds. If this is very short (< 60,000 = 60 seconds), keys are expiring rapidly and you may have high expiry overhead.

INFO commandstats

usec_per_call — microseconds per command call. High values for specific commands reveal which commands are slow. In the example, HGETALL at 100µs vs GET at 5µs — these HGETALL calls are expensive (likely large Hashes).

INFO latencystats (Redis 7.0+)

Per-command latency percentiles. p99.9 for HGETALL at 2,140µs (2ms) is a signal that some HGETALL calls are very expensive — likely on large Hashes that crossed the listpack→hashtable threshold.

SLOWLOG

SLOWLOG records commands that exceed a configurable latency threshold.

Common slow command findings:

• KEYS * — scans all keys, blocks Redis. Replace with SCAN.
• HGETALL large_hash — Hash in hashtable encoding with thousands of fields.
• SMEMBERS large_set — returns all Set members at once. Use SSCAN.
• SORT — sorts a List or Set; O(N+M log M). Computationally expensive.
• LRANGE key 0 -1 — returns entire List. Cache long lists with pagination.

Set slowlog-log-slower-than 1000 (1ms) in development to catch all slow commands during development and testing. In production, use 10,000–20,000µs to avoid log noise.

LATENCY Monitoring

Redis has a built-in latency monitoring system that tracks event-level latency — not per-command, but per internal event type (fork, AOF flush, RDB save, etc.).

Event names to watch:

• fork — BGSAVE/BGREWRITEAOF fork latency (high = large dataset or memory pressure)
• aof-stat — AOF write latency (high = disk I/O bottleneck)
• rdb-* — RDB save events
• command — command execution latency (aggregate)

MONITOR: Live Command Stream

MONITOR streams every command executed by every client in real time. It is invaluable for debugging unexpected behaviour ("what is sending KEYS * in production?") but adds 50%+ CPU overhead. Never leave MONITOR running in production.

Format: {unix_timestamp} [{db} {client_ip:port}] {command} {args...}

Use it briefly to identify which clients are issuing which commands, then disconnect immediately.

CLIENT LIST and CLIENT INFO

Key fields:

• cmd — last command issued by this client
• age — seconds since connection was established
• sub — number of channels subscribed
• omem — output buffer memory (large = slow client)
• flags — b = blocked (BLPOP), S = subscriber

Identify stuck clients: CLIENT LIST + filter for cmd=blpop with high age values.

The 10 Metrics Every Redis Dashboard Must Include

Export these metrics from INFO every 15–60 seconds to your monitoring system (Prometheus via redis_exporter, Datadog, CloudWatch, etc.).

redis-cli Monitoring Shortcuts

redis-cli --bigkeys scans the entire keyspace using SCAN and samples key sizes — it reports the largest key per type. Safe to run on production (uses cursor-based scan, not blocking KEYS *).

Summary

• INFO is the starting point — use INFO stats for throughput and hit rate, INFO memory for memory health, INFO replication for lag, INFO keyspace for key distribution
• Cache hit rate (keyspace_hits / total) should be > 90% — below this, investigate TTLs, eviction, and cache warming
• evicted_keys > 0 means memory pressure — increase maxmemory or reduce dataset
• SLOWLOG GET reveals expensive commands — the most common findings: KEYS *, HGETALL on large hashes, SORT
• LATENCY LATEST / LATENCY HISTORY tracks internal event latency (fork, AOF flush, RDB save)
• MONITOR streams live commands — invaluable for debugging, catastrophic if left running in production
• CLIENT LIST identifies slow/stuck clients by output buffer size and command age
• Export INFO metrics every 15–60 seconds to your monitoring system; build dashboards around the 10 core metrics

Next: P-12 — Security: ACLs, TLS, and Network Hardening — per-user command restrictions, TLS for in-transit encryption, bind address configuration, and the most common Redis security misconfigurations.