Integration · Redis

Redis monitoring: hit rate, memory and command latency

See cache hit ratio, memory, evictions, command latency and replication for every Redis instance, and which service depends on it when the cache misbehaves.
Try for freeRequest a demo
Obseria apps and capabilities: observability, APM, infrastructure and integrations
Obseria home dashboard with service health, open problems, SLO compliance and ingestion
Obseria trace explorer with span list and span attributes
Overview

Why monitor Redis with Obseria

Cache effectiveness in one number

Keyspace hits and misses become a hit ratio per instance, so you notice when the cache stops shielding your database.

Memory before it hurts

Used memory against maxmemory, fragmentation and evictions show memory pressure before latency rises or keys disappear.

Latency with a cause

Command latency next to fork times, blocked clients and the calling services' spans explains why a millisecond cache got slow.

Coverage

Redis components Obseria monitors

  • Keyspace. Keys and keys with expiry per database, average TTL, hits, misses, expired and evicted keys.
  • Memory. Used, RSS, peak and Lua memory, fragmentation ratio and the configured maxmemory.
  • Clients and connections. Connected and blocked clients, received and rejected connections, client buffer sizes.
  • Commands. Commands processed, operations per second, and calls and latency per command type.
  • Persistence and replication. Changes since last RDB save, latest fork duration, replication offset and connected replicas.
  • Redis Cluster and Sentinel. Cluster state, slot assignment and known nodes, plus Sentinel masters and tilt events.
At a glance

The Redis signals that matter

Obseria collects these values automatically and shows them in ready-made dashboards and alerts.

Cache effectiveness

Shows how often requested data is found in the cache, which directly decides how fast your application feels.

  • redis.keyspace.hits
  • redis.keyspace.misses

Memory usage

Tells you how full the cache is, whether data is being pushed out and how efficiently memory is used.

  • redis.memory.used
  • redis.maxmemory
  • redis.keys.evicted
  • redis.memory.fragmentation_ratio

Client connections

Reveals how many applications are connected and whether new connections are being turned away during busy times.

  • redis.clients.connected
  • redis.connections.rejected

Response time

Highlights slow commands and short pauses during background saves that can cause noticeable delays for your users.

  • redis.cmd.latency
  • redis.latest_fork
Show all 10 metrics in detail
MetricUnitWhat it tells you
redis.keyspace.hits{hit}Successful key lookups; together with misses it yields the cache hit ratio.
redis.keyspace.misses{miss}Failed key lookups that usually fall through to the backing database.
redis.memory.usedByMemory allocated by Redis for data and overhead.
redis.maxmemoryByConfigured memory limit; used memory close to it triggers evictions.
redis.keys.evicted{key}Keys removed because maxmemory was reached.
redis.memory.fragmentation_ratio1RSS divided by used memory; high values waste RAM, values below 1 mean swapping.
redis.clients.connected{client}Client connections, excluding replicas.
redis.connections.rejected{connection}Connections refused because maxclients was reached.
redis.cmd.latencysLatency per command type, to find slow commands such as KEYS or large range reads.
redis.latest_forkusDuration of the last fork for RDB or AOF rewrite; long forks block the event loop.
Setup

Set up Redis monitoring in minutes

  1. Step 1

    Prepare access

    Create an ACL user that may run INFO, or use the existing password, and store it in an environment variable.

  2. Step 2

    Configure the redis receiver

    Add the redis receiver to the OpenTelemetry Collector or Obseria Agent and enable optional metrics such as maxmemory and command latency.

  3. Step 3

    Connect the callers

    Instrument the services that use Redis with OpenTelemetry, so cache spans show up in traces next to database calls.

Example configuration · YAML
receivers:
  redis:
    endpoint: redis-primary:6379
    password: ${env:REDIS_PASSWORD}
    collection_interval: 10s
    tls:
      insecure: false
      ca_file: /etc/otel/redis-ca.pem
    metrics:
      redis.maxmemory:
        enabled: true
      redis.cmd.latency:
        enabled: true
      redis.role:
        enabled: true
exporters:
  otlphttp:
    endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
    headers:
      Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
  pipelines:
    metrics:
      receivers: [redis]
      exporters: [otlphttp]

Out of the box

Dashboards, alerts and SLOs that are ready the moment data arrives.

  • Redis overview: hit ratio, ops per second, clients
  • Memory, fragmentation and evictions
  • Command latency by command type
  • Alert: used memory above 90% of maxmemory
  • Alert: hit ratio below baseline or rejected connections
Guide

Redis monitoring: what matters

Why Redis monitoring matters

Redis is usually the fastest component in a request path: a cache in front of a database, a session store, a rate limiter or a queue. Because it is fast and reliable, teams often notice problems only indirectly, as higher database load or slower APIs. When Redis runs out of memory, evicts hot keys or blocks on a slow command, every service that relies on it suffers at once. Redis monitoring makes these situations visible early.

Obseria collects metrics with the redis receiver of the OpenTelemetry Collector, which reads the output of the INFO command. Spans from OpenTelemetry instrumentation of Redis clients add the view from the calling services.

The Redis metrics that matter

Cache hit ratio

The hit ratio is redis.keyspace.hits / (redis.keyspace.hits + redis.keyspace.misses). For a cache, this is the most important number. A falling ratio means more requests reach the database. Causes include TTLs that are too short, keys evicted under memory pressure, or a new access pattern after a deployment.

Memory and evictions

Redis keeps everything in memory. Compare redis.memory.used with redis.maxmemory. When the limit is reached, the eviction policy removes keys and redis.keys.evicted rises. For a pure cache with an LRU policy, a steady eviction rate can be acceptable; for a session store, any eviction is data loss. redis.memory.fragmentation_ratio well above 1 wastes RAM, while a value below 1 means the operating system is swapping Redis memory.

Latency and blocking

Redis executes commands on a single main thread. One slow command blocks all others. redis.cmd.latency per command type reveals expensive calls such as KEYS, large SMEMBERS or LRANGE reads. redis.latest_fork shows how long the last fork for persistence took; on large instances this can pause the server noticeably.

Clients and replication

redis.clients.connected, redis.clients.blocked and redis.connections.rejected reveal connection leaks and limits. redis.replication.offset on primary and replicas shows replication progress.

Common problems and how to detect them

  • Memory exhaustion: used memory approaches maxmemory, evictions rise, hit ratio drops. Alert at 90% and review TTLs and large keys.
  • Slow commands: latency spikes for all commands at once usually trace back to one expensive command type. Check per-command latency and the slow log.
  • Persistence stalls: long forks during RDB snapshots or AOF rewrites, often on instances without enough free memory for copy-on-write.
  • Connection leaks: connected clients grow steadily after each deployment until maxclients rejects new ones.
  • Cache stampede: many keys expire at once and the database receives a burst of misses. Correlate misses with database load.

Best practices for Redis monitoring

  1. Always set maxmemory and an eviction policy that matches the use case.
  2. Monitor hit ratio per instance and per use case; a session store and a page cache need different thresholds.
  3. Add jitter to TTLs to avoid synchronized expiry.
  4. Disable or rename dangerous commands such as KEYS in production and watch per-command latency.
  5. Collect metrics every 10 seconds; Redis problems develop quickly.

How Obseria helps with Redis monitoring

Obseria brings Redis metrics, host metrics and the Redis spans of your services together in Obseria Lake. TopoGraph shows which services depend on which Redis instance, so a memory or latency alert lists the affected applications. Obseria Intelligence correlates a dropping hit ratio with deployments, rising database load and evictions, and lays out the likely root cause with a chain of evidence. For managed offerings such as Amazon ElastiCache, Azure Cache for Redis or Google Cloud Memorystore, the agentless cloud integrations add provider metrics. Dashboards, alerts and SLOs are included, and you can query everything with OQL, PromQL or SQL.

A useful pattern is to put the Redis hit ratio and the query rate of the backing database on the same dashboard. When the hit ratio drops and database load rises at the same moment, you know the cache is the cause, and the traces of affected requests show which keys and endpoints are involved.

Related integrations

PostgreSQLPostgreSQL MonitoringMongoDBMongoDB MonitoringNGINXNGINX Monitoring
All integrations

Related capabilities

Database Monitoring

Find the slow query behind a slow endpoint. Obseria links database metrics, query performance and logs to the traces and services that call them.

Learn more

Distributed Tracing

Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.

Learn more

Anomaly Detection

Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.

Learn more
Part of Infrastructure Observability

Learn more

The four golden signals: latency, traffic, errors and saturation

The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.

What is an SLO (service level objective)?

What is an SLO? Learn how SLIs, SLOs, SLAs and error budgets work, how to calculate them, set targets and alert on burn rate, with examples.

Redis monitoring FAQ

Divide redis.keyspace.hits by the sum of redis.keyspace.hits and redis.keyspace.misses over the same interval. Obseria shows this ratio per instance out of the box.

Yes. The redis receiver offers optional cluster metrics such as cluster state and slot assignment, and Sentinel metrics such as monitored masters and tilt events.

Yes. Use the agentless cloud integrations for provider metrics and, where network access allows, the redis receiver for INFO-based metrics.

Used memory above 90% of maxmemory, a hit ratio below its usual baseline, rejected connections above 0 and command latency above your SLO.

The receiver runs the INFO command at the configured interval. This is lightweight and safe to run every 10 seconds on production instances.

Start monitoring Redis today

Connect Redis in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.

Try for freeContact Sales