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

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.

---