Passer au contenu 
Surveillance de Redis Grâce à Prometheus et Grafana, je dispose de métriques fiables sur la mémoire, la latence, le taux de commandes, la réplication et l'efficacité du cache, ce qui me permet de garantir dès le début les performances et la stabilité d'une instance. Pour cela, j'utilise un exportateur que Prometheus interroge régulièrement, et j'analyse les données dans des tableaux de bord Grafana afin d'identifier rapidement les tendances, les seuils et les anomalies.
Points centraux
Je résume ici les principaux éléments clés pour que tu puisses planifier la mise en place en toute confiance. Un exportateur fournit les données Redis au format Prometheus. Prometheus les collecte à intervalles réguliers. Grafana génère à partir de ces données des graphiques clairs et compréhensibles. J'ajoute un système d'alerte pour que les problèmes ne passent pas inaperçus.
- Exporter: Fournir les métriques Redis au format Prometheus
- Prometheus: Sélectionner les intervalles de scraping, vérifier les cibles
- Grafana: Importer des tableaux de bord, définir des couleurs et des seuils
- Métriques: Surveiller la mémoire, la latence, le débit d'instructions et le taux de réussite du cache
- Alerting: Analyser les tendances, éviter le bruit
Présentation de la configuration : configuration d'Exporter, Prometheus et Grafana
Je commence par le Exporter, car il fournit les métriques que Prometheus comprend. Ensuite, j'ajoute la cible dans Prometheus et je choisis un intervalle de collecte adapté. Pour finir, j'importe dans Grafana un tableau de bord Redis bien connu et j'adapte les panneaux à mon environnement. Pour démarrer rapidement, je m'aide d'un Pile Grafana-Prometheus, qui intègre d'emblée des fonctionnalités d'intégration et de visualisation de base. Je peux ainsi disposer rapidement d'un système de surveillance cohérent, sans pour autant renoncer à des détails importants.
Installation de Redis Exporter
Je rédige un document indépendant redis_exporter à côté de l'instance et je vérifie d'abord localement si les métriques sont accessibles. Pour les instances protégées, je définis un nom d'utilisateur et un mot de passe afin que l'exportateur puisse se connecter correctement. Ensuite, je vérifie si redis_up renvoie la valeur 1 et si redis_uptime_in_seconds est plausible. Je veille à ce que l’exportateur ne dispose que des autorisations nécessaires. Je m’assure ainsi que les données de mesure sont disponibles de manière fiable et sécurisée.
Options d'exportation et estimation de la charge
Je pèse délibérément le pour et le contre de ce qui Options de collecte J'active les métriques Commandstats, Keyspace et Replication par défaut. J'active de manière sélective les vérifications supplémentaires, telles que les analyses de clés ou les contrôles basés sur des modèles, afin qu'elles ne génèrent pas de charge inutile en production. Lors des tests de charge, je mesure les coûts liés à l’exportateur : CPU et mémoire de l’exportateur lui-même, charge réseau supplémentaire due aux scrapes et charge CPU supplémentaire sur Redis due aux requêtes INFO. À titre indicatif, je prévois, pour des scrapes de 15 à 30 secondes et des ensembles de collecteurs courants, < 1–2% de surcharge sur une instance de production. Si la surcharge augmente, je réduis la profondeur du collecteur ou j'allonge les intervalles.
Je veille également à Cardinalité des étiquettes: Je dimensionne délibérément les fonctionnalités qui génèrent de nombreuses séries chronologiques par base de données, par commande ou par rôle. Avec des centaines d'instances, les séries chronologiques se multiplient rapidement. Je fixe des limites strictes : pas d’étiquettes dynamiques (par exemple, les identifiants client), pas de métriques par clé dans Prometheus. Pour les analyses ponctuelles de clés, j’utilise mes propres mesures ponctuelles ou des outils qui ne s’exécutent pas dans la boucle principale de Prometheus.
Configuration de Prometheus : intervalles de collecte et étiquettes
Je choisis le Intervalle de manière à ce que la charge et le niveau de détail soient adaptés. Pour de nombreuses charges de travail, 30 secondes suffisent ; pour les systèmes très dynamiques, je règle ce délai à 15 secondes. J'attribue des étiquettes uniques à chaque instance, telles que « cluster », « role » ou « env », afin que les requêtes et les alertes puissent être clairement identifiées. Je surveille les cibles via leur statut dans Prometheus, car c’est là que je repère immédiatement les pannes. J’utilise systématiquement les fonctions de calcul de taux pour transformer les compteurs par seconde en métriques pertinentes.
Règles d'enregistrement, durée de conservation et tendances à long terme
Je définis Règles d'enregistrement pour les dérivées fréquemment utilisées, afin que les tableaux de bord et les alertes fonctionnent rapidement et de manière stable. Citons par exemple le taux de commande, le débit réseau, le taux de fragmentation et le taux de réussite du cache. Cela me permet de réduire les requêtes coûteuses en temps d'exécution et de garantir la réactivité des tableaux de bord. En termes de capacité, je prévois une quantité suffisante Rétention: À court terme (par exemple, 15 à 30 jours), je conserve les données en haute résolution ; à long terme, j'exporte des indicateurs agrégés ou j'utilise le sous-échantillonnage. Les tendances sur plusieurs trimestres m'aident à évaluer de manière fiable les effets de croissance et de saisonnalité.
Je consigne mes Conventions de nommage et d'étiquetage et j'ajoute des étiquettes externes pour chaque instance de Prometheus. Cela me permet d'attribuer correctement les métriques, même après un déplacement ou dans le cadre de configurations fédérées. Pour les environnements particulièrement instables, j'utilise la découverte de services avec des étiquettes stables et j'accède aux cibles via des objets de service plutôt que par les adresses IP des pods.
Tableaux de bord Grafana : panneaux, couleurs, variables
Je conçois des tableaux de bord de manière à ce que Tendances sont visibles au premier coup d’œil. Je mets clairement en évidence les couleurs et les seuils d’alerte, notamment pour la mémoire, la latence et le taux d’instructions. Les variables relatives aux clusters, aux rôles et aux espaces de noms me permettent de basculer plus facilement d’une instance à l’autre. Des annotations identifient les déploiements ou les retours en arrière, ce qui me permet d’évaluer les pics de métriques dans leur contexte temporel. Chaque tuile répond à une question concrète, au lieu de se contenter d’afficher des chiffres.
Tableaux de bord pour les SLO et analyses opérationnelles détaillées
Je fais volontairement la distinction entre Aperçu - et Tableaux de bord avec fonctionnalité d'exploration. La synthèse couvre les indicateurs liés au SLO : taux de commandes, latence p95/p99 (si mesurable), taux de réussite du cache, évictions, état de la réplication et erreurs. Pour l’analyse, j’utilise des explorations approfondies avec les statistiques de commandes, le débit réseau, les clients bloqués, les parts de CPU et la structure de l’espace de clés de la base de données (clés, clés avec TTL, avg_ttl). Les variables pour env, cluster, role, instance et db me permettent de changer de contexte sans dupliquer les tableaux de bord. Je définis des codes couleur uniformes (par exemple, vert = tout va bien, jaune = attention, rouge = critique) afin que les équipes comprennent d’emblée, sans explication, ce qui nécessite une intervention.
Comprendre les indicateurs clés et les replacer dans leur contexte
Je me concentre sur la Chiffres clés, qui mettent en évidence les causes. Les valeurs de mémoire me montrent à quel point je travaille près de la limite. Les taux de requêtes et la latence indiquent une surcharge ou des schémas inefficaces. Les connexions et la réplication révèlent si des clients sont bloqués ou si des nœuds sont désynchronisés. Le taux de réussite du cache m’indique si celui-ci est suffisamment grand et si la durée de vie des données est adaptée.
| Métriques | Exemple PromQL | Signification | Valeur indicative/signal |
|---|---|---|---|
| redis_up | redis_up == 1 | L'exportateur se connecte à Redis | 0 indique une défaillance |
| redis_memory_used_bytes | moyenne(redis_memory_used_bytes) par (instance) | Besoins réels en mémoire dynamique | > 80% : seuil critique |
| redis_memory_used_rss_bytes | (rss / utilisé) > 1,5 | fragmentation de la mémoire | Quotient élevé de manière persistante = nécessité d'agir |
| redis_commands_total | rate(redis_commands_total[5m]) | Commandes par seconde | Forte augmentation + latence = goulot d'étranglement |
| redis_connected_clients | max(redis_connected_clients) par (instance) | Connexions simultanées | Dangereux lorsque l'on approche de la limite maxclients |
| Réussites/Échecs | sum(rate(redis_keyspace_hits_total[5m])) / (sum(rate(redis_keyspace_hits_total[5m])) + sum(rate(redis_keyspace_misses_total[5m]))) | Efficacité du cache | < 0,9 indique une erreur de configuration |
J'ajoute des indicateurs si nécessaire à Réplication, par exemple pour savoir si l'esclave est bloqué en synchronisation ou si l'état de la liaison change. Pour les configurations en cluster, j'analyse séparément chaque rôle afin de comparer les chemins de lecture et d'écriture. Je vérifie toujours les anomalies dans le contexte des déploiements et des pics de trafic. Seules les tendances me fournissent des conclusions fiables, les pics isolés étant plutôt rares. Je prends ainsi des décisions rationnelles plutôt que de me fier à mon intuition.
Persistance, expulsions et réseau : les points à surveiller
Je surveille Persistance (RDB/AOF) séparément : état de la dernière sauvegarde en arrière-plan, durée de la dernière exécution, modifications depuis le dernier instantané et activation ou non de l'AOF. Des cycles de persistance fréquents ou longs indiquent des goulots d'étranglement au niveau des E/S ou des ressources insuffisantes. Si la latence augmente en parallèle, je vérifie la saturation des E/S, la compression et l'espace de stockage.
À l'adresse suivante : Evictions Je ne déclenche pas d'alerte uniquement lorsque les chiffres absolus sont élevés, mais dès qu'un taux, associé à une baisse du taux de réussite ou à une augmentation de la latence, indique un manque de mémoire. J'évalue également Clés expirées Extrait de : Un nombre élevé d'expirations n'est pas nécessairement un mauvais signe, mais des pics soudains indiquent des lots TTL incorrects ou des schémas de suppression irréguliers.
Pour le Réseau J'utilise le nombre d'octets d'entrée et de sortie par seconde pour évaluer les besoins en bande passante et l'évolutivité. Une forte augmentation du volume de sortie alors que le taux de commandes reste constant indique des réponses plus volumineuses (par exemple, HSCAN/SMEMBERS) ou des charges utiles non compressées. De plus, je surveille les connexions refusées et les clients bloqués : ces deux éléments sont un signe évident que soit les threads, soit les chemins d'E/S sont saturés.
Mesurer correctement la réplication et la haute disponibilité
Je mesure Lag soit sous forme de différence entre les décalages de réplication, soit en fonction du temps écoulé depuis le dernier contact d'E/S réussi avec le maître. Un écart élevé et persistant indique que les esclaves sont en retard et que les lectures qu'ils effectuent peuvent être obsolètes. Le État du lien Je vérifie les synchronisations complètes et partielles en cours à l'aide de mes propres tableaux de bord et seuils d'alerte. Pour les configurations en cluster ou de type Sentinel, je surveille les changements de rôle, le nombre de répliques connectées et la taille des retards. Les indicateurs importants sont l'augmentation des resynchronisations partielles (liaisons instables) et les resynchronisations complètes répétées (problèmes d'E/S ou de réseau).
Stratégie d'alerte avec PromQL
Je configure les alarmes de manière à ce qu'elles Tendances et ne pas se contenter de signaler les pics. Une mémoire supérieure à 80% pendant 10 minutes se déclenche plus facilement qu'un pic de 30 secondes. Un taux de réussite du cache inférieur à 90% sur 15 minutes indique des TTL incorrects ou une mémoire insuffisante. Je considère les erreurs de connexion et l'augmentation de la latence comme des signes de surcharge. Je réduis le bruit récurrent à l'aide de durées « for », de lissage et de seuils pertinents.
Conception des alertes : exemples pratiques et corrélation
- Disponibilité: redis_up == 0 (immédiatement), complété par les erreurs d'exportation et de collecte de données, afin que je puisse distinguer les problèmes réseau des pannes de Redis.
- Mémoire: si used_bytes/maxmemory > 0,8 pendant 10 minutes et que le taux d'éviction augmente en parallèle : privilégier la mise à l'échelle et l'ajustement du TTL.
- Réplication: Si la valeur a dépassé le seuil pendant 5 à 10 m ou s'il y a eu des resynchronisations complètes répétées dans les 30 m : vérifiez le réseau et la taille de la file d'attente.
- Clients: Pourcentage de clients bloqués > X% par rapport au nombre total de clients sur 5 minutes : recherchez les opérations BLPOP/BLOCK volumineuses ou les scripts Lua lents.
- Persistance: échec du dernier BGSAVE/AOF ou durée supérieure à la valeur normale + 50% pendant 10 m : vérifier le sous-système d'E/S.
Je mets en corrélation les alertes à l'aide d'étiquettes communes (cluster, role, env) et j'ajoute Liens vers les runbooks dans les messages d'alerte. L'équipe sait ainsi immédiatement quelles vérifications et quelles commandes effectuer ensuite. Pour les environnements de staging/Canary, je définis des priorités plus faibles afin que la charge de travail des personnes d'astreinte reste gérable.
Planification des capacités et optimisation dans la pratique
Je planifie les capacités en Tendances en évaluant conjointement la mémoire, les commandes et la latence. Si le volume de données augmente de manière constante alors que le taux de réussite reste stable, j’augmente la mémoire ou j’ajuste les TTL. En cas de fragmentation, je réduis la surcharge grâce à des allocateurs restrictifs ou à une réécriture ciblée. Je choisis la politique d'éviction et la valeur maxmemory en fonction de la charge de travail, par exemple « allkeys-lfu » pour les clés fréquemment utilisées. Pour la planification à long terme, une analyse approfondie m'aide à Suivi des performances, qui met en évidence le profil de charge de travail.
Guides d'intervention, tests et exercices de simulation de situations de chaos
Je documente Runbooks Concernant les alertes les plus importantes : quels journaux et quelles commandes dois-je vérifier ? Quels indicateurs dois-je évaluer en priorité ? Qui doit signaler le problème et à quel moment ? Je m'entraîne régulièrement aux scénarios de basculement et de réparation. Dans le cadre de tests contrôlés, je simule des fluctuations du réseau, un ralentissement des E/S, un manque de mémoire et des connexions refusées. Je vérifie que les alertes se déclenchent, que les tableaux de bord mettent en évidence les tendances et que l'équipe est en mesure de réagir dans les délais prévus.
Je considère en outre que Valeurs de référence définis pour chaque environnement : taux de commandes typique, mémoire moyenne, durée de persistance habituelle, délai de réplication normal. Cela me permet de détecter plus rapidement les écarts par rapport à la fourchette de référence et de hiérarchiser de manière éclairée les mesures d'optimisation.
Intégrer de manière transparente les environnements Kubernetes et cloud
J'utilise l'outil d'exportation en tant que side-car ou sous forme de déploiement autonome, et je définis les cibles via ServiceMonitor. Je définis de manière cohérente les étiquettes telles que « cluster » et « role » afin que les tableaux de bord effectuent correctement le filtrage. Pour les points de terminaison des clusters, je choisis une cible de collecte centralisée afin d’éviter les doublons dans les mesures. La découverte automatique me facilite la gestion des pods dynamiques. Les volumes persistants et les requêtes adaptées permettent d’éviter les pénuries de stockage au mauvais moment.
Cardinalité, découverte des services et capacité à prendre en charge plusieurs clients
Je conçois les règles de découverte de manière à ce que seules critères d'évaluation pertinents sont collectées. J'utilise des sélecteurs de balises pour filtrer et j'utilise des espaces de noms dédiés pour les composants d'infrastructure. Pour les configurations multi-locataires, je veille à une séparation claire des étiquettes env, team et service. Je maîtrise la cardinalité en limitant le nombre de valeurs d’étiquettes dynamiques et en n’activant les appels à forte variance (par exemple, par base de données et par instance) que là où ils sont réellement nécessaires.
Je prévois Ressources Pour Exporter et Prometheus, une approche prudente : des requêtes et des limites adaptées au volume de scraping de pointe, des PDB pour une haute disponibilité et l'affinité des nœuds pour les chemins de données sensibles à la latence. Si nécessaire, je fais évoluer Prometheus horizontalement (sharding) et je réduis la charge grâce à des règles d'enregistrement et à des intervalles de collecte plus longs pour les métriques peu dynamiques.
Sécurité et accès aux indicateurs
Je sauvegarde Redis via TLS et l'authentification, afin d'empêcher tout tiers d'accéder aux métriques ou aux données. L’exportateur ne dispose que des droits nécessaires et n’a pas accès aux commandes sensibles. Des politiques réseau limitent l’accès à Prometheus et au port de l’exportateur. Je stocke les secrets séparément et les renouvelle régulièrement. Ainsi, l’infrastructure de mesure reste fiable et les surfaces d’attaque sont réduites au minimum.
Conformité et hygiène des données dans les indicateurs
Je veille à ce qu'il n'y ait pas de données personnelles ou que des contenus sensibles ne se retrouvent pas dans des étiquettes ou des métriques. Les tableaux de bord et les variables ne contiennent que des identifiants techniques. Pour les données de débogage qui sont temporairement plus sensibles, je définis une durée de conservation courte et des droits d'accès strictement limités. J'utilise les droits d'accès aux dossiers et aux équipes dans Grafana afin que seules les personnes autorisées puissent consulter les tableaux de bord opérationnels.
Erreurs fréquentes et dépannage
Je vérifie d'abord redis_up, lorsque des valeurs manquent dans le tableau de bord. Si la valeur reste à 0, cela signifie souvent que la chaîne de connexion ou le pare-feu ne fonctionne pas correctement. Si la valeur « rss » s'écarte fortement de « used », cela peut indiquer une fragmentation ou un effet secondaire du système d'exploitation. En cas de faible taux de réussite, je vérifie les TTL, la taille des clés et les modèles d'accès. Pour une analyse rapide des causes, je m'aide du Guide RedisInsight, qui affiche les requêtes et les raccourcis clavier.
Se manifestent blocages persistants (clients bloqués), je recherche des scripts trop longs, des transactions Multi/Exec volumineuses ou des appels SCAN/SMEMBERS surdimensionnés. Dans le cas de connexions refusées je vérifie le nombre maximal de clients, les limites réseau et si trop de connexions de longue durée mobilisent des ressources. Dans le cas de Problèmes de réplication J'analyse les « link-flaps », la taille du backlog, les pertes de paquets et les E/S disque. Les erreurs de persistance indiquent souvent un espace de stockage saturé, un étranglement des E/S ou des forks qui échouent.
Remarques spécifiques à la version et optimisation
Je prends en compte Versions de Redis En ce qui concerne l'interprétation : les versions récentes proposent des chemins d'E/S optimisés, des politiques par défaut modifiées et des métriques supplémentaires. Après les mises à niveau, je vérifie si les tableaux de bord continuent de recevoir toutes les données et si les valeurs de référence (par exemple, l'utilisation du processeur) ont changé. Lorsque le protocole TLS est activé, je prévois un peu plus de ressources processeur et je surveille si la latence et le débit restent stables. Lorsque la part de Lua/scripts est importante, je tiens compte du fait que les opérations longues en monothread peuvent provoquer des pics de métriques – reconnaissables à une augmentation des blocages et de la latence survenant à proximité temporelle de l’exécution des scripts.
Étape par étape : de la première métrique au tableau de bord
Je configure l'exportateur et je teste la Point de terminaison-Réponse locale. Ensuite, j'ajoute la cible dans Prometheus et je vérifie son état. Puis, j'importe un tableau de bord et je vérifie si les commandes, la mémoire et les clients semblent corrects. Après cela, je configure des alertes pour la mémoire, le taux de réussite du cache, la latence et la réplication. Pour finir, je documente les seuils et les runbooks afin que l’équipe puisse réagir rapidement en cas d’incident.
Résumé
Je construis Surveillance de Redis grâce à Exporter, Prometheus et Grafana, de manière à identifier les causes plutôt que les symptômes. Les métriques relatives à la mémoire, au taux de commandes, aux connexions, à la réplication et au taux de réussite du cache me fournissent des indications décisives. Des tableaux de bord clairs et des alertes bien pensées permettent de détecter les pics de charge, les erreurs de configuration et les goulots d’étranglement avant même que les utilisateurs ne s’en rendent compte. Des étiquettes claires, des intervalles pertinents et des accès sécurisés garantissent la fiabilité du fonctionnement. En suivant ces étapes, vous bénéficiez d’une visibilité permanente sur les performances et la stabilité de vos instances Redis et prenez de meilleures décisions en matière d’architecture et de capacité.
