How to Monitor Redis with OpenTelemetry

What to observe in Redis

Redis usually sits on the hot path, so its signals are latency-sensitive: commands per second and command latency, memory usage against maxmemory, eviction and expiration rates, the cache hit ratio, connected clients, and replication and persistence health. A falling hit ratio or rising evictions feed straight through to the latency of every service that depends on the cache.

The single most important reading is memory against maxmemory together with the eviction rate, because once Redis reaches maxmemory it starts evicting keys, and evictions are the usual precursor to a cache-driven latency and error spike.

How OpenTelemetry collects it

The Collector's redis receiver connects to Redis and reads the INFO output, emitting memory, command, keyspace-hit-and-miss, client and replication metrics over OTLP. Application spans that wrap Redis calls tie cache behaviour to request latency, so a slow request that is really a slow or missed cache lookup is visible.

The access detail is authentication: if Redis requires a password, the receiver needs it, and on a cluster you point it at the nodes you want to observe.

Key metrics to watch

The signals that explain most Redis incidents:

What to put on a dashboard

A Redis dashboard should keep memory and hit ratio front and centre. Row one: memory used against maxmemory and the eviction rate (the two that predict trouble). Row two: cache hit ratio computed from hits and misses, and command latency. Row three: connected clients and replication health.

# memory headroom (near maxmemory = evictions imminent)
redis.memory.used / redis_maxmemory

# cache hit ratio (a falling ratio hurts every dependent service)
redis.keyspace.hits / (redis.keyspace.hits + redis.keyspace.misses)

# eviction rate: keys pushed out because memory is full
rate(redis_evicted_keys[5m])

Reading the signals: common failure modes

Memory pressure and evictions

Latency and misses rise across dependent services because Redis reached maxmemory and is evicting keys to make room. Memory at maxmemory with a rising eviction rate is the signature. Size memory to the working set, tune the eviction policy, or shard; simply restarting clears it only temporarily.

Cache hit ratio dropping

Downstream services slow down because a larger share of lookups miss and fall through to the database. The hit ratio computed from hits and misses falls. Causes include evictions, too-short TTLs, or a cold cache after a restart or deploy.

Blocked or slow Redis

Command throughput drops and latency spikes because a slow command (a large KEYS scan, a big operation) or persistence activity is blocking the single-threaded server. Find the slow command; avoid O(n) commands on large keyspaces on the hot path.

Example alert conditions

Starting thresholds to tune:

From monitoring to autonomous resolution

Ops Singularity's TelemetryOps ingests Redis telemetry over OpenTelemetry, and Sentinel AI resolves cache incidents, memory pressure, evictions, replication issues, through governed Action Tickets. Explore TelemetryOps.