Redis est rapide, mais la performance en production dépend de la visibilité. Ce guide montre quoi surveiller, des règles d'alerte pratiques, des tableaux de bord qui accélèrent le débogage, et un pilote ciblé que vous pouvez exécuter localement. Vous repartirez avec des exemples prêts à copier-coller et un flux de travail d'incident léger.

## Vue d'ensemble du flux de travail

- Exporter les métriques Redis avec redis_exporter .

- Collecter les métriques avec Prometheus et définir des règles d'alerte.

- Construire un tableau de bord Grafana pour les signaux de santé clés.

- Capturer les journaux et le SLOWLOG pour les valeurs aberrantes et les indices de cause racine.

- Instrumenter votre application (exemple en Node.js) pour la latence de bout en bout.

- Piloter localement avec Docker Compose et une charge synthétique.

- Itérer sur les seuils et les runbooks avant la production.

## Quoi surveiller dans Redis

### Santé de base

- redis_up : disponibilité de base.

- redis_connected_clients , redis_blocked_clients : saturation et opérations bloquantes.

- redis_connections_received_total , redis_rejected_connections_total : pression sur les connexions.

### Performance et efficacité

- redis_commands_processed_total : tendance du débit.

- Succès et échecs du keyspace : redis_keyspace_hits_total , redis_keyspace_misses_total ; taux de succès = 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 par l'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 ; une valeur soutenue > 1,5 peut dégrader les performances.

### Persistance et durabilité

- redis_rdb_last_bgsave_status , redis_aof_last_bgrewrite_status : drapeaux 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 haute disponibilité

- redis_connected_slaves (ou nombre de répliques) : santé de la réplication.

- redis_master_last_io_seconds_ago : fraîcheur de la réplication.

- Temps de fonctionnement et redémarrages : variations de redis_uptime_in_seconds .

### Indices système (via exporteurs conteneur/hôte)

- Saturation CPU, attente I/O 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 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: L'instance Redis est indisponible

 - 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: Taux d'échec du cache élevé (>20%)
 description: Examinez la logique de mise en cache, les TTL des clés et la taille du jeu de données.

 - alert: RedisEvictionsSpike
 expr: rate(redis_evicted_keys_total[5m]) > 10
 for: 10m
 labels:
 severity: warning
 annotations:
 summary: Redis éjecte des clés
 description: Pression mémoire ; vérifiez maxmemory, la politique et les clés chaudes.

 - alert: ConnectionsRejected
 expr: rate(redis_rejected_connections_total[5m]) > 0
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: Des clients sont rejetés
 description: Proche de maxclients ou épuisement des ressources.

 - alert: ClientsBlocked
 expr: redis_blocked_clients > 0
 for: 5m
 labels:
 severity: warning
 annotations:
 summary: Clients bloqués par des commandes Redis
 description: WATCH/MULTI, BLPOP, scripts ou stockage lent.

 - 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: Utilisation mémoire Redis > 90% de maxmemory

 - alert: FragmentationHigh
 expr: redis_mem_fragmentation_ratio > 1.5
 for: 15m
 labels:
 severity: warning
 annotations:
 summary: Fragmentation mémoire élevée

 - alert: PersistenceFailureRDB
 expr: redis_rdb_last_bgsave_status == 0
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: Échec de la sauvegarde RDB en arrière-plan

 - alert: PersistenceFailureAOF
 expr: redis_aof_last_bgrewrite_status == 0
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: Échec de la réécriture AOF

 - alert: ReplicationStale
 expr: redis_master_last_io_seconds_ago > 30
 for: 5m
 labels:
 severity: warning
 annotations:
 summary: La réplique n'a pas reçu de données récemment

 - alert: RestartDetected
 expr: changes(redis_uptime_in_seconds[5m]) > 0
 for: 0m
 labels:
 severity: info
 annotations:
 summary: Redis a redémarré 
 Notes :

- Si maxmemory n'est pas défini, MemoryHeadroomLow sera ignoré. Dans ce cas, surveillez les éjections et la croissance du RSS.

- Pour la latence, privilégiez les histogrammes au niveau application (voir exemple Node.js) et alertez sur p95/p99.

## Journaux et signaux

Les journaux serveur aident à expliquer les anomalies métriques.

### Bases Redis

Activez SLOWLOG et définissez un seuil adapté à 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 
 Inspectez 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 journaux utiles

- Background saving terminated : vérifiez l'espace disque et les IOPS.

- Asynchronous AOF fsync is taking too long : investiguez 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 envoyez-le sous forme d'événements structurés. Corréléz les entrées lentes avec les pics de blocked_clients , de fragmentation et d'éjections.

## Tableaux de bord qui comptent

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

Panneaux suggérés :

- Disponibilité : redis_up , redémarrages dans le temps.

- Trafic : rate(redis_commands_processed_total[5m]) ; types de commandes principales si disponibles.

- Qualité du cache : taux de succès (hits / (hits + misses)).

- Mémoire : utilisée vs max, éjections et expirations, ratio de fragmentation.

- Connexions : connected_clients , rejected_connections , blocked_clients .

- Persistance : drapeaux de succès du dernier RDB/AOF, heure de dernière sauvegarde, changements depuis la dernière sauvegarde.

- Réplication : répliques connectées, master_last_io_seconds_ago .

- Latence applicative : p50/p95/p99 depuis vos métriques de service à côté des graphiques Redis.

## Flux de réponse aux incidents

Triage par symptôme, vérification par liste de contrôle, application des correctifs.

### 1. Latence élevée ou timeouts

- Vérifiez blocked_clients , slowlog, CPU et stockage.

- Recherchez de gros scripts Lua, de grosses valeurs ou SCAN dans les chemins critiques.

- Atténuation : augmenter les timeouts, réduire la taille des payloads, sharder les clés chaudes, déplacer les opérations lourdes hors pointe, ou utiliser le pipelining.

### 2. Taux d'échec élevé

- Validez les noms de clés et les TTL ; confirmez l'alignement SET / GET .

- Atténuation : préchauffer les clés critiques, allonger les TTL, dimensionner le cache pour contenir l'ensemble chaud, ou ajouter une stratégie write-through.

### 3. Éjections et pression mémoire

- Confirmez maxmemory et la politique ( volatile-lru , allkeys-lru , etc.).

- Atténuation : augmenter la mémoire, resserrer les TTL, compresser les valeurs, ou changer la politique pour s'adapter à la charge.

### 4. Saturation des connexions

- Vérifiez rejected_connections et connected_clients .

- Atténuation : augmenter maxclients , réutiliser les connexions (pooling), et ajuster le TCP keepalive.

### 5. Échecs de persistance

- Vérifiez le statut RDB/AOF et l'espace disque/IOPS.

- Atténuation : libérer de l'espace, déplacer AOF/RDB vers un stockage plus rapide, raccourcir les intervalles de sauvegarde avec prudence.

### 6. Lag de réplication ou split

- Vérifiez master_last_io_seconds_ago et le nombre de répliques.

- Atténuation : augmenter le backlog de réplication, garantir la bande passante réseau, et dimensionner correctement les répliques.

Capturez toujours : ce qui a changé, quand cela a commencé, et les métriques d'impact. Après atténuation, ajoutez ou ajustez les alertes et panneaux de tableau de bord pour repérer le problème plus vite la prochaine fois.

## Plan de pilote local

Déployez Redis, l'exporteur, Prometheus et Grafana localement. 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 collecte 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: 'Latence des commandes Redis',
 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 app_redis_cmd_duration_seconds p95/p99 à côté des éjections Redis et de blocked_clients .

### Critères de sortie du pilote

- Vous pouvez casser Redis localement (remplir la mémoire, throttler le disque) et voir des alertes claires.

- Le tableau de bord affiche le taux de succès, la marge mémoire, les éjections, les connexions, la persistance et l'état de réplication.

- Les étapes du runbook résolvent chaque problème simulé.

- Les seuils sont ajustés pour éviter le bruit en charge normale.

## Conclusion

Surveiller Redis efficacement signifie suivre un petit ensemble de métriques à fort signal, les associer à des alertes claires, et valider le tout 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, affinez les seuils et formalisez votre runbook avant le déploiement en production.