Systematic Redis Monitoring with redis-cli and INFO

1. Why systematic monitoring works without extra tools

Many teams reflexively reach for a dedicated monitoring stack as soon as Redis goes to production, even though the server itself already provides a substantial share of the relevant metrics. The INFO command and redis-cli as a diagnostic tool cover memory usage, throughput, replication status, latency, and access patterns, without needing an agent installed, an exporter configuration maintained, or an extra network port opened.

That does not mean external monitoring systems are unnecessary, they are often valuable for long-term trend analysis and automated alerting. But for quickly diagnosing an acute problem, for a first assessment of a newly set up server, or for environments where extra software installation should be avoided, redis-cli combined with INFO is almost always sufficient as a complete monitoring toolkit, provided you approach it systematically instead of looking at isolated values.

2. The INFO sections at a glance

The INFO command organizes its output into clearly separated sections: Server with version and process information, Clients with connected clients and blocking status, Memory with memory usage and fragmentation, Persistence with RDB and AOF status, Stats with cumulative operational counters, Replication with master-replica status, CPU with processor time, and Keyspace with key counts per database. INFO all returns every section, while INFO memory returns only the requested section, keeping the output manageable for scripts.

This structured layout is the actual reason INFO works so well as a monitoring foundation: instead of parsing an unstructured text block, each section can be queried for a specific question. Anyone who only needs to check replication status calls INFO replication instead of processing the full, much longer output. This modularity also makes INFO practical for cron jobs and simple bash scripts, without needing a JSON parser or an external library.

redis-cli INFO server | head -5
# redis_version:7.2.4
# redis_mode:standalone
# os:Linux 5.15.0-1053-aws x86_64
# process_id:1
# uptime_in_seconds:4823917

redis-cli INFO clients
# connected_clients:342
# blocked_clients:2
# tracking_clients:0
# maxclients:10000

3. The Memory section in detail: used_memory and fragmentation

used_memory shows the memory Redis actually uses for data structures, while used_memory_rss shows the physical memory actually allocated by the operating system. The difference between the two, expressed as mem_fragmentation_ratio, reveals memory fragmentation: a value clearly above 1.5 signals that the allocator has reserved considerably more memory from the OS than Redis logically needs, usually caused by many small allocations and deallocations of varying size over time.

A value below 1.0 is equally a warning sign, but in the other direction: it means Redis needs more memory than the operating system has currently allocated, which typically points to swapping and can drastically increase latency. maxmemory and maxmemory_policy from the same section show whether a memory limit is set and which eviction strategy kicks in once that limit is reached, a combination worth reviewing during every capacity planning exercise.

redis-cli INFO memory
# used_memory:2147483648
# used_memory_human:2.00G
# used_memory_rss:3435973836
# used_memory_rss_human:3.20G
# mem_fragmentation_ratio:1.60
# maxmemory:4294967296
# maxmemory_human:4.00G
# maxmemory_policy:allkeys-lru
# mem_allocator:jemalloc-5.3.0

# fragmentation_ratio 1.60 -> allocator holds 60% more RSS than logical usage
# consider MEMORY PURGE (jemalloc) or a controlled restart during low traffic

4. The Stats section: hit rate, evictions, and expirations

The Stats section provides cumulative counters since the last start or CONFIG RESETSTAT, including keyspace_hits and keyspace_misses. From these two values you calculate the hit rate as keyspace_hits / (keyspace_hits + keyspace_misses), one of the most informative single metrics for cache workloads: a hit rate below 80 percent usually points to an undersized cache volume, an unsuitable TTL strategy, or an access pattern poorly suited for caching.

evicted_keys counts how many keys were forcibly removed due to maxmemory, while expired_keys counts keys removed normally through TTL expiration. A sudden rise in evicted_keys is a clear signal that either more memory is needed or the data size per key should be reviewed, while high expired_keys combined with a low hit rate can indicate TTLs that are too short, throwing data out of the cache before it is requested again.

5. redis-cli --stat: the live overview

While INFO gives you a single snapshot, redis-cli --stat shows a continuously updating table of memory usage, client count, hit-rate relevant counters, and operations per second, refreshed every second by default. This view is excellent for watching live how the server behaves under a given load, for example during a load test or right after a deployment, without opening a separate Grafana dashboard.

Combining it with a defined interval via -i is especially useful for tuning the refresh rate to your observation scenario. When investigating an acute latency problem, a one-second interval provides enough detail, while for a longer observation over several minutes, a larger interval keeps the output readable without losing relevant trends.

redis-cli --stat
# ------- data ------ --------------------- load -------------------- - child -
# keys       mem      clients blocked requests            connections
# 284213     2.10G    342     2       184213 (+0)          8481
# 284215     2.10G    342     2       184298 (+85)         8481
# 284215     2.10G    343     2       184391 (+93)         8482

# Custom interval: sample every 5 seconds for a longer observation window
redis-cli --stat -i 5

6. redis-cli --latency and --latency-history

redis-cli --latency continuously measures the round-trip time of a PING command and shows minimum, maximum, average, and sample count in real time, refreshed every second. This measurement captures not only network latency but also how fast the Redis event loop itself responds, making it a reliable early indicator of server-side overload, for example from a long-running blocking command.

redis-cli --latency-history adds time segmentation to this measurement: instead of a single continuous average, the command returns a new measurement block every 15 seconds, configurable via -i. That lets you pinpoint latency spikes in time and correlate them with other events like deployments, backup jobs, or cron runs, without needing an external time series database.

redis-cli --latency
# min: 0, max: 12, avg: 0.42 (5231 samples)

redis-cli --latency-history -i 15
# min: 0, max: 1, avg: 0.31 (1500 samples) -- 15.00 seconds range
# min: 0, max: 8, avg: 0.55 (1500 samples) -- 15.00 seconds range
# min: 2, max: 45, avg: 6.21 (1500 samples) -- 15.00 seconds range  <- spike

# Correlate the spike window with concurrent server-side events
redis-cli LATENCY HISTORY command
redis-cli LATENCY LATEST

7. redis-cli --bigkeys and --memkeys for memory analysis

redis-cli --bigkeys scans the entire keyspace using SCAN, without blocking the server, and identifies the largest key found per data type along with a distribution statistic across all types. It is the fastest way to determine whether a single oversized hash, a huge sorted set, or a sprawling list is responsible for a disproportionate share of memory usage, without inspecting every key individually.

redis-cli --memkeys goes a step further and estimates actual memory usage for a sample of keys using MEMORY USAGE, instead of just looking at element count. A hash with few but very large values might not stand out with --bigkeys, while --memkeys correctly identifies it as a memory hog. Both commands run at low priority in the background and are safe on production servers too, but should preferably run during low-traffic periods due to the scan load.

8. Building a monitoring routine without external tools

A reliable monitoring routine combines a regular cron job that queries INFO, extracts relevant values, and writes them to a simple CSV or log file, with occasional manual deep dives using redis-cli --stat, --latency, and --bigkeys when something looks off. A minimal bash approach uses redis-cli INFO piped into grep and awk to extract individual values and log them with a timestamp, no exporter or agent required.

It is important to consistently timestamp the raw values so trends become visible later, instead of only having isolated snapshots. Even a simple CSV file with hourly values for used_memory, hit rate, and connected_clients is often enough to catch slowly growing problems like a creeping memory leak or a deteriorating hit rate early, well before they turn into an acute incident.

#!/usr/bin/env bash
# monitor.sh , minimal Redis health snapshot, no external tools
set -euo pipefail

TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)
INFO=$(redis-cli INFO all)

USED_MEM=$(echo "$INFO" | grep -oP 'used_memory:\K\d+')
FRAG=$(echo "$INFO" | grep -oP 'mem_fragmentation_ratio:\K[0-9.]+')
HITS=$(echo "$INFO" | grep -oP 'keyspace_hits:\K\d+')
MISSES=$(echo "$INFO" | grep -oP 'keyspace_misses:\K\d+')
CLIENTS=$(echo "$INFO" | grep -oP 'connected_clients:\K\d+')

HIT_RATE=$(awk -v h="$HITS" -v m="$MISSES" 'BEGIN { print (h+m>0) ? h/(h+m)*100 : 0 }')

echo "$TIMESTAMP,$USED_MEM,$FRAG,$HIT_RATE,$CLIENTS" >> /var/log/redis-monitor.csv

9. Setting thresholds and alerting heuristics

Monitoring without defined thresholds remains pure observation, not an early warning system. For mem_fragmentation_ratio, an alert threshold around 1.5 has proven effective, for hit rate an alert below 80 percent, though both values need adjustment per workload: a pure session store with short TTLs behaves structurally differently than a cache for rarely changing reference data with a correspondingly higher expected hit rate.

A second important threshold concerns connected_clients relative to maxclients: an alert at 80 percent utilization gives enough lead time to react before new connections get rejected with ERR max number of clients reached. For latency, a rolling comparison of the current redis-cli --latency average against the historical average for the same time of day works well, since absolute thresholds quickly trigger either too many or too few alerts under strongly fluctuating daily load.

10. Summary

Systematic monitoring with redis-cli and INFO covers nearly every operational scenario without installing an extra tool. The INFO sections deliver structured data on memory, stats, clients, and replication, with mem_fragmentation_ratio and the hit rate derived from keyspace_hits/keyspace_misses among the most informative individual values. redis-cli --stat gives you a live view, --latency and --latency-history measure response times in real time and across time windows.

--bigkeys and --memkeys identify memory hogs without straining the server. A simple cron-based routine that logs INFO values with timestamps makes trends visible before they turn into acute incidents. Anyone who uses these tools systematically rather than sporadically, and defines realistic thresholds for their own workload, has a complete monitoring foundation before even considering an external tool.

11. FAQ: monitoring with redis-cli and INFO