Skip to content
Navigation

Type at least two characters. Search covers page titles, headings, tags and database names.

↑ ↓ to navigateEnter to openEsc to close0 pages
Redis and Valkeyintermediate

Redis Monitoring

The INFO fields, latency tools and slow log settings that reveal a Redis problem before clients time out.

2 min readIntermediateUpdated Edit this page

Metrics that matter

used_memory / maxmemory

Source: INFO memory

The ratio that predicts eviction or write failures. Alert well before it reaches 1.

evicted_keys

Source: INFO stats

Keys removed to stay under maxmemory. Any sustained eviction on a store you did not intend to be evictable is a problem. See the eviction playbook.

keyspace_hits / keyspace_misses

Source: INFO stats

Cache hit ratio. A sudden fall usually means TTLs changed, keys were evicted, or the key naming changed in a deploy.

blocked_clients

Source: INFO clients

Clients waiting in blocking commands (BLPOP, XREAD BLOCK). Growth means consumers cannot keep up.

mem_fragmentation_ratio

Source: INFO memory

Above 1.5 suggests real fragmentation; below 1.0 means the process is swapping, which is an incident.

master_link_status

Source: INFO replication

Must be up on every replica. Combine with the offset difference for lag in bytes.

rdb_last_bgsave_status

Source: INFO persistence

A failing background save is silent to clients and breaks your restore path.

instantaneous_ops_per_sec

Source: INFO stats

Command throughput. Read alongside latency: a fall in operations with rising latency means something is blocking the single command thread.

Slow log

slowlog-log-slower-than 10000    # microseconds; 10 ms
slowlog-max-len 512
SLOWLOG GET 10
SLOWLOG RESET

The slow log records execution time only — it excludes time spent waiting for the network or queueing behind another command. An entry here means the command itself was slow, which almost always points at an O(N) operation on a large key.

Latency monitoring

LATENCY RESET
LATENCY HISTORY command
LATENCY LATEST
LATENCY DOCTOR

Redis's latency monitor records spikes by event type — command, fork, expire-cycle, aof-write. This is how you distinguish a slow command from a fork pause during a background save, which look identical from the client's perspective.

# Measure round-trip latency continuously from a client's viewpoint.
redis-cli --latency -h redis.internal
redis-cli --latency-history -h redis.internal

Keyspace and command statistics

INFO commandstats     # calls, total usec and usec per call, per command
INFO latencystats     # latency percentiles per command (Redis 7+)
INFO keyspace         # key count and keys with expiry per database

INFO commandstats is the quickest way to find which command type dominates, and to spot an O(N) command that should not be in the hot path at all.

Alerts worth having

  • Memory usage approaching maxmemory.
  • Eviction rate above zero where eviction is not expected.
  • Cache hit ratio falling below its established baseline.
  • Replica master_link_status not up, or replication offset lag growing.
  • rdb_last_bgsave_status or aof_last_write_status reporting an error.
  • Blocked client count rising.
  • p99 latency above the budget, measured from a client rather than from the server.