Redis monitoring and alerts with practical examples: practical implementation guide

Redis is fast, but production performance depends on visibility. This guide shows what to monitor, practical alert rules, dashboards that speed up debugging, and a focused pilot you can run locally. You will leave with copy paste examples and a lightweight incident workflow.

Workflow Overview

• Export Redis metrics with redis_exporter.
• Scrape metrics with Prometheus and define alert rules.
• Build a Grafana dashboard for key health signals.
• Capture logs and SLOWLOG for outliers and root cause hints.
• Instrument your app (example in Node.js) for end to end latency.
• Pilot locally with Docker Compose and synthetic load.
• Iterate on thresholds and runbooks before production.

What to monitor in Redis

Core health:

• redis_up: basic availability.
• redis_connected_clients, redis_blocked_clients: saturation and blocking operations.
• redis_connections_received_total, redis_rejected_connections_total: connection pressure.

Performance and efficiency:

• redis_commands_processed_total: throughput trend.
• Keyspace hits and misses: redis_keyspace_hits_total, redis_keyspace_misses_total; hit ratio = hits/(hits+misses).
• redis_evicted_keys_total and redis_expired_keys_total: memory pressure vs normal expiry.
• Slow operations: SLOWLOG and application observed latency.

Memory and fragmentation:

• redis_memory_used_bytes vs redis_memory_max_bytes: capacity headroom.
• redis_mem_fragmentation_ratio: typically near 1.0; sustained > 1.5 can hurt.

Persistence and durability:

• redis_rdb_last_bgsave_status, redis_aof_last_bgrewrite_status: success flags.
• redis_rdb_changes_since_last_save: risk window for data loss on crash.

Replication and HA:

• redis_connected_slaves (or replica count): replication health.
• redis_master_last_io_seconds_ago: replication freshness.
• Uptime and restarts: redis_uptime_in_seconds changes.

System hints (via container/host exporters):

• CPU saturation, disk IO wait, network drops to contextualize Redis metrics.

Alert rules with examples

Use Prometheus with redis_exporter. Tune durations and thresholds to your traffic profile.

Example rule file:

# redis-alerts.yml
groups:
- name: redis.rules
  rules:
  - alert: RedisDown
    expr: redis_up == 0
    for: 1m
    labels: { severity: critical }
    annotations:
      summary: Redis instance is down

  - alert: HighKeyspaceMissRatio
    expr: (
      increase(redis_keyspace_misses_total[5m])
      /
      (increase(redis_keyspace_hits_total[5m]) + increase(redis_keyspace_misses_total[5m]))
    ) > 0.2
    for: 10m
    labels: { severity: warning }
    annotations:
      summary: High cache miss ratio (>20%)
      description: Investigate caching logic, key TTLs, and dataset size.

  - alert: RedisEvictionsSpike
    expr: rate(redis_evicted_keys_total[5m]) > 10
    for: 10m
    labels: { severity: warning }
    annotations:
      summary: Redis is evicting keys
      description: Memory pressure; check maxmemory, policy, and hot keys.

  - alert: ConnectionsRejected
    expr: rate(redis_rejected_connections_total[5m]) > 0
    for: 5m
    labels: { severity: critical }
    annotations:
      summary: Clients are being rejected
      description: Near maxclients or resource exhaustion.

  - alert: ClientsBlocked
    expr: redis_blocked_clients > 0
    for: 5m
    labels: { severity: warning }
    annotations:
      summary: Clients blocked by Redis commands
      description: WATCH/MULTI, BLPOP, scripts, or slow storage.

  - alert: MemoryHeadroomLow
    expr: redis_memory_max_bytes > 0 and (redis_memory_used_bytes / redis_memory_max_bytes) > 0.9
    for: 10m
    labels: { severity: warning }
    annotations:
      summary: Redis memory usage > 90% of maxmemory

  - alert: FragmentationHigh
    expr: redis_mem_fragmentation_ratio > 1.5
    for: 15m
    labels: { severity: warning }
    annotations:
      summary: High memory fragmentation

  - alert: PersistenceFailureRDB
    expr: redis_rdb_last_bgsave_status == 0
    for: 5m
    labels: { severity: critical }
    annotations:
      summary: RDB background save failed

  - alert: PersistenceFailureAOF
    expr: redis_aof_last_bgrewrite_status == 0
    for: 5m
    labels: { severity: critical }
    annotations:
      summary: AOF rewrite failed

  - alert: ReplicationStale
    expr: redis_master_last_io_seconds_ago > 30
    for: 5m
    labels: { severity: warning }
    annotations:
      summary: Replica has not received data recently

  - alert: RestartDetected
    expr: changes(redis_uptime_in_seconds[5m]) > 0
    for: 0m
    labels: { severity: info }
    annotations:
      summary: Redis restarted

Notes:

• If you do not set maxmemory, MemoryHeadroomLow will be skipped. In that case, watch evictions and RSS growth.
• For latency, prefer app level histograms (see Node.js example) and alert on p95/p99.

Logs and signals

Server logs help explain metric anomalies.

Redis basics:

• Enable SLOWLOG and set a threshold appropriate to your SLA:

redis-cli CONFIG SET slowlog-log-slower-than 10000  # 10ms
redis-cli CONFIG SET slowlog-max-len 2048
redis-cli SLOWLOG LEN
redis-cli SLOWLOG GET 10

• Inspect runtime state without restarting:

redis-cli INFO server
redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO keyspace
redis-cli LATENCY DOCTOR

Useful log patterns:

• Background saving terminated: check disk space and IOPS.
• Asynchronous AOF fsync is taking too long: investigate storage.
• Failed opening .rdb or .aof: permissions or path issues.
• Client closed connection / timeout: network or slow server.

Automate slowlog scraping and ship as structured events. Correlate slow entries with spikes in blocked_clients, fragmentation, and evictions.

Dashboards that matter

Build a single page that answers: Is Redis up, fast, and within capacity?

Suggested panels:

• Availability: redis_up, restarts over time.
• Traffic: rate(redis_commands_processed_total[5m]); top command types if available.
• Cache quality: hit ratio (hits/(hits+misses)).
• Memory: used vs max, evictions and expirations, fragmentation ratio.
• Connections: connected_clients, rejected_connections, blocked_clients.
• Persistence: last RDB/AOF success flags, last save time, changes since last save.
• Replication: connected replicas, master_last_io_seconds_ago.
• App latency: p50/p95/p99 from your service metrics next to Redis graphs.

Incident response workflow

Triage by symptom, verify with a checklist, and apply fixes.

1. High latency or timeouts

• Check blocked_clients, slowlog, CPU, and storage.
• Look for large Lua scripts, big values, or SCAN in hot paths.
• Mitigate: raise timeouts, reduce payload size, shard hot keys, move heavy ops off peak, or use pipelining.

1. High miss ratio

• Validate key names and TTLs; confirm set and get alignment.
• Mitigate: warm critical keys, extend TTLs, size cache to fit hot set, or add a write through strategy.

1. Evictions and memory pressure

• Confirm maxmemory and policy (volatile-lru, allkeys-lru, etc.).
• Mitigate: increase memory, tighten TTLs, compress values, or change policy to fit workload.

1. Connection saturation

• Check rejected_connections and connected_clients.
• Mitigate: raise maxclients, reuse connections (pooling), and tune TCP keepalive.

1. Persistence failures

• Check RDB/AOF status and disk space/IOPS.
• Mitigate: free space, move AOF/RDB to faster storage, shorten save intervals cautiously.

1. Replication lag or split

• Check master_last_io_seconds_ago and replica count.
• Mitigate: increase repl backlog, ensure network bandwidth, and right size replicas.

Always capture: what changed, when it started, and impact metrics. After mitigation, add or adjust alerts and dashboard panels so the issue is faster to spot next time.

Local Pilot Plan

Stand up Redis, exporter, Prometheus, and Grafana locally. Generate load, review signals, and validate alerts before wider rollout.

Docker Compose:

version: '3.8'
services:
  redis:
    image: redis:7
    command: ["redis-server", "--appendonly", "yes"]
    ports:
      - 6379:6379
  redis_exporter:
    image: oliver006/redis_exporter: v1.58.0
    command: ["--redis.addr=redis://redis:6379"]
    ports:
      - 9121:9121
    depends_on:
      - redis
  prometheus:
    image: prom/prometheus: v2.52.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml: ro
    ports:
      - 9090:9090
  grafana:
    image: grafana/grafana:10.4.5
    ports:
      - 3000:3000
    depends_on:
      - prometheus

Prometheus scrape config (prometheus.yml):

scrape_configs:
- job_name: redis_exporter
  static_configs:
  - targets: ['redis_exporter:9121']
rule_files:
- /etc/prometheus/redis-alerts.yml

Node.js latency instrumentation (ioredis + prom-client):

// npm i ioredis prom-client
const { Histogram, collectDefaultMetrics, register } = require('prom-client');
const Redis = require('ioredis');
const http = require('http');

collectDefaultMetrics();
const h = new Histogram({
  name: 'app_redis_cmd_duration_seconds',
  help: 'Redis command latency',
  labelNames: ['cmd'],
  buckets: [0.001,0.005,0.01,0.025,0.05,0.1,0.25,0.5,1]
});

const r = new Redis(process.env.REDIS_URL || 'redis://localhost:6379');
async function timed(cmd, fn) {
  const end = h.startTimer({ cmd });
  try { return await fn(); } finally { end(); }
}

async function tick() {
  await timed('SET', () => r.set('k', 'v', 'EX', 60));
  await timed('GET', () => r.get('k'));
}
setInterval(tick, 50);

http.createServer((req, res) => {
  if (req.url === '/metrics') {
    res.writeHead(200, { 'Content-Type': register.contentType });
    register.metrics().then(m => res.end(m));
  } else {
    res.writeHead(200); res.end('ok');
  }
}).listen(9100);

Add a Grafana panel for app_redis_cmd_duration_seconds p95/p99 next to Redis evictions and blocked_clients.

Pilot exit criteria:

• You can break Redis locally (fill memory, throttle disk) and see clear alerts.
• Dashboard shows hit ratio, memory headroom, evictions, connections, persistence, and replication state.
• Runbook steps resolve each simulated issue.
• Thresholds are tuned to avoid noise during normal load.

Conclusion

Monitoring Redis well means tracking a small set of high signal metrics, pairing them with clear alerts, and validating everything in a safe pilot. Start with availability, cache quality, memory, connections, persistence, and replication. Add application latency next to Redis metrics so you can see cause and effect. Run the local pilot, tune thresholds, and codify your runbook before production rollout.