Redis monitoring et alertes : exemples pratiques

Intro

Cette version française explique Redis monitoring and alerts with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Redis est rapide, mais les performances en production dépendent de la visibilité. Ce guide explique quoi surveiller, propose des règles d'alerte concrètes, des dashboards qui accélèrent le débogage, et un pilote local simple à exécuter. Vous repartirez avec des exemples à copier-coller et un workflow d'incident léger. Nous couvrons Redis monitoring, Redis alerts, Redis metrics, la conception d'un Redis dashboard et un processus de Redis incident response.

Vue d'ensemble du workflow

Exporter les métriques Redis avec redis_exporter.
Scraper les métriques avec Prometheus et définir des règles d'alerte.
Construire un dashboard Grafana pour les signaux de santé clés.
Capturer les logs et le SLOWLOG pour les outliers et indices de cause racine.
Instrumenter l'application (exemple en Node.js) pour la latence de bout en bout.
Piloter en local avec Docker Compose et une charge synthétique.
Itérer sur les seuils et les runbooks avant la production.

Que surveiller dans Redis

Santé de base :

redis_up : disponibilité.
redis_connected_clients, redis_blocked_clients : saturation et opérations bloquantes.
redis_connections_received_total, redis_rejected_connections_total : pression de connexion.

Performance et efficacité :

redis_commands_processed_total : tendance de débit.
Hits et misses du keyspace : redis_keyspace_hits_total, redis_keyspace_misses_total ; ratio de hit = hits/(hits+misses).
redis_evicted_keys_total et redis_expired_keys_total : pression mémoire vs expiration normale.
Opérations lentes : SLOWLOG et latence observée côté application.

Mémoire et fragmentation :

redis_memory_used_bytes vs redis_memory_max_bytes : marge de capacité.
redis_mem_fragmentation_ratio : généralement proche de 1,0 ; > 1,5 soutenu peut nuire.

Persistance et durabilité :

redis_rdb_last_bgsave_status, redis_aof_last_bgrewrite_status : indicateurs de succès.
redis_rdb_changes_since_last_save : fenêtre de risque de perte de données en cas de crash.

Réplication et HA :

redis_connected_slaves (ou nombre de réplicas) : santé de la réplication.
redis_master_last_io_seconds_ago : fraîcheur de réplication.
Uptime et redémarrages : variations de redis_uptime_in_seconds.

Indicateurs système (via exporters hôte/conteneur) :

Saturation CPU, latence IO disque, pertes réseau pour contextualiser les métriques Redis.

Règles d'alerte avec exemples

Utilisez Prometheus avec redis_exporter. Ajustez les durées et les seuils à votre profil de trafic.

Exemple de fichier de règles :

# 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 :

Si vous ne définissez pas maxmemory, l'alerte MemoryHeadroomLow est ignorée. Dans ce cas, surveillez les évictions et la croissance du RSS.
Pour la latence, préférez les histogrammes côté application (voir l'exemple Node.js) et alertez sur p95/p99.

Logs et signaux

Les logs serveur aident à expliquer les anomalies de métriques.

Bases Redis :

Activer SLOWLOG et définir un seuil conforme à votre 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

Inspecter l'état d'exécution sans redémarrer :

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

Motifs de logs utiles :

"Background saving terminated" : vérifiez l'espace disque et les IOPS.
"Asynchronous AOF fsync is taking too long" : enquêtez sur le stockage.
"Failed opening .rdb or .aof" : problèmes de permissions ou de chemin.
"Client closed connection / timeout" : réseau ou serveur lent.

Automatisez la collecte du slowlog et expédiez-le en événements structurés. Corrélez les entrées lentes avec les pics de blocked_clients, la fragmentation et les évictions.

Dashboards efficaces

Construisez une page unique qui répond : Redis est-il up, rapide et dans sa capacité ?

Panneaux suggérés :

Disponibilité : redis_up, redémarrages dans le temps.
Trafic : rate(redis_commands_processed_total[5m]) ; top des types de commandes si disponible.
Qualité du cache : ratio de hit (hits/(hits+misses)).
Mémoire : used vs max, évictions et expirations, ratio de fragmentation.
Connexions : connected_clients, rejected_connections, blocked_clients.
Persistance : derniers succès RDB/AOF, dernière sauvegarde, changements depuis la dernière sauvegarde.
Réplication : réplicas connectés, master_last_io_seconds_ago.
Latence appli : p50/p95/p99 de votre service à côté des graphes Redis.

Workflow d'incident

Faites un triage par symptôme, vérifiez via une checklist et appliquez les correctifs.

Latence élevée ou timeouts

Vérifiez blocked_clients, slowlog, CPU et stockage.
Cherchez de gros scripts Lua, des valeurs volumineuses ou des SCAN dans les chemins chauds.
Mitigation : augmenter temporairement les timeouts, réduire la taille des charges, sharder les clés chaudes, déplacer les opérations lourdes hors des pics, ou utiliser le pipelining.

Taux de miss élevé

Validez les noms de clés et les TTL ; confirmez l'alignement set/get.
Mitigation : préchauffer les clés critiques, étendre les TTL, dimensionner le cache pour tenir le hot set, ou adopter une stratégie write-through.

Évictions et pression mémoire

Confirmez maxmemory et la politique (volatile-lru, allkeys-lru, etc.).
Mitigation : augmenter la mémoire, resserrer les TTL, compresser les valeurs, ou adapter la politique au workload.

Saturation des connexions

Surveillez rejected_connections et connected_clients.
Mitigation : augmenter maxclients, réutiliser les connexions (pool), et ajuster TCP keepalive.

Échecs de persistance

Vérifiez l'état RDB/AOF et l'espace/IOPS disque.
Mitigation : libérer de l'espace, déplacer AOF/RDB vers un stockage plus rapide, raccourcir prudemment les intervalles de sauvegarde.

Lag ou divergence de réplication

Surveillez master_last_io_seconds_ago et le nombre de réplicas.
Mitigation : augmenter le backlog de réplication, assurer la bande passante réseau et dimensionner correctement les réplicas.

Capturez toujours : ce qui a changé, quand cela a commencé et les métriques d'impact. Après mitigation, ajoutez/ajustez les alertes et les panneaux pour détecter plus vite la prochaine occurrence.

Pilote local

Montez Redis, l'exporter, Prometheus et Grafana en local. Générez de la charge, examinez les signaux et validez les alertes avant un déploiement plus large.

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

Configuration de scrape Prometheus (prometheus.yml) :

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

Instrumentation de latence Node.js (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);

Ajoutez un panneau Grafana pour les p95/p99 de app_redis_cmd_duration_seconds à côté des évictions Redis et de blocked_clients.

Critères de sortie du pilote :

Vous pouvez « casser » Redis localement (mémoire pleine, disque ralenti) et voir des alertes claires.
Le dashboard montre le ratio de hit, la marge mémoire, les évictions, les connexions, la persistance et l'état de réplication.
Les étapes du runbook résolvent chaque incident simulé.
Les seuils sont ajustés pour éviter le bruit en charge normale.

Conclusion

Bien surveiller Redis, c'est suivre un petit ensemble de métriques à fort signal, les associer à des alertes claires et tout valider dans un pilote sûr. Commencez par la disponibilité, la qualité du cache, la mémoire, les connexions, la persistance et la réplication. Ajoutez la latence applicative à côté des métriques Redis pour voir cause et effet. Exécutez le pilote local, ajustez les seuils et formalisez votre runbook avant le passage en production.