Passer au contenu 
Je vais expliquer en deux phrases comment j'utilise la sortie de Informations sur Redis lire et interpréter correctement afin de surveiller de manière ciblée les indicateurs professionnels relatifs à la disponibilité, à la capacité et à la latence. Cela me permet de détecter rapidement les signaux d'alerte, de définir des seuils appropriés et de mettre en œuvre des mesures concrètes pour les environnements de production Observabilité à partir de
Points centraux
La brève liste suivante présente les points clés que je développe dans cet article de manière rigoureuse sur le plan technique et orientée vers la pratique :
- Structure Comprendre le contenu de la sortie INFO et consulter des sections de manière ciblée.
- Indicateurs clés lire de manière fiable des indicateurs tels que « used_memory », « ops/sec » et « Hits/Misses ».
- Alarmes et définir des seuils pertinents pour le fonctionnement et les astreintes.
- Réplication et surveiller les latences afin de garantir l'actualité des données.
- Automatisation Mettre en place correctement via les tableaux de bord et les scripts.
Comprendre la sortie INFO : structure et sections
Je considère la sortie INFO comme un ensemble de paires clé-valeur, regroupées en sections logiquement distinctes Sections tels que serveur, clients, mémoire, statistiques, réplication, CPU, modules, cluster et espace de clés. Chaque ligne me fournit un aperçu clair de l'état du système, que j'utilise pour établir des valeurs de référence et définir des alertes, sans avoir à agréger de données supplémentaires. Dans les situations liées à un incident, je commence par les sections standard via INFO, puis je passe progressivement à des sections plus ciblées afin de limiter le volume de résultats. Pour les vérifications récurrentes, je définis un ordre : d’abord les serveurs et les clients, puis la mémoire et les statistiques, suivis de la réplication, du processeur et de l’espace de clés. Je conserve ainsi un ordre fixe Guide et ne perds pas le nord même sous la pression du temps.
Recherches ciblées : « default », « all », « everything » et sections spécifiques
J'utilise la commande INFO en fonction du contexte : INFO pour la norme, INFO all pour les sections complètes de la norme et INFO everything lorsque des modules sont actifs et que je souhaite analyser leurs champs sans avoir à les recharger manuellement. J'utilise certaines sections, telles que INFO memory ou INFO stats, dans des scripts afin de simplifier l'analyse et de limiter la charge réseau, notamment en cas de nombreuses instances. Pour les requêtes par lots dans les pipelines, je combine des sections et j'effectue l'analyse ligne par ligne, afin d'obtenir par la suite des Étiquettes que je reçois dans le système de surveillance. Dans les environnements de production, je réduis la fréquence d'interrogation des résultats volumineux et je récupère les blocs volumineux moins souvent, tandis que je récupère les indicateurs de petite taille plus fréquemment. C'est ainsi que j'équilibre la profondeur des données et Fréquence et évite une charge inutile sur les E/S.
Serveurs et clients : bilans de santé rapides
Je vérifie d'abord sur le serveur la valeur de `redis_version` et celle de `uptime_in_seconds` afin d'évaluer rapidement la compatibilité, les bogues connus et les éventuelles boucles de redémarrage avant d'approfondir mon analyse. Une chute brutale de la durée de fonctionnement m'indique des plantages potentiels, des redémarrages progressifs ou des modifications de configuration, que je peux recouper avec les déploiements dans le temps. Côté clients, je surveille `connected_clients` pour la gestion des connexions et `blocked_clients` pour les commandes en attente telles que `BLPOP`, qui, en cas d’anomalies, indiquent une contre-pression. Des valeurs élevées de `connected_clients` sans `ops/sec` correspondantes m’indiquent une utilisation inefficace des connexions ou un pooling défaillant. Je dispose ainsi en quelques secondes d’une vue d’ensemble fiable état de santé de l'instance et surveille les modèles critiques.
Analyse de la mémoire : used_memory et fragmentation
Je surveille la mémoire utilisée (used_memory) comme indicateur principal des tendances de croissance et je prévois des réserves avant que des évictions ou des problèmes de mémoire insuffisante ne menacent ; une augmentation constante sans suppressions est mon premier signal d'alarme. J'interprète la valeur « mem_fragmentation_ratio » comme le rapport entre la mémoire occupée et la mémoire réservée ; des valeurs nettement supérieures à 1,3 indiquent une fragmentation, que je résous en ajustant la configuration ou en effectuant un redémarrage planifié. Pour approfondir la pratique, j'utilise des guides complémentaires tels que Bien interpréter la fragmentation de la mémoire, afin de prendre des décisions éclairées en matière d'optimisation et de capacité. J'adopte une approche prudente en matière de stratégies Maxmemory : je fixe des limites adaptées à la mémoire vive physique et je choisis une politique d'éviction qui correspond à mon profil d'accès. Je maintiens ainsi la consommation de mémoire, la fragmentation et les performances dans un équilibre viable Équilibre.
Consulter les statistiques : taux de réussite, expulsions, opérations par seconde
Je combine les valeurs « keyspace_hits » et « keyspace_misses » pour calculer le taux de réussite, ce qui me permet d'évaluer l'efficacité de mon cache et de déterminer si les TTL ou la phase de préchauffage sont insuffisants. La valeur « evicted_keys » m’indique clairement que la limite de mémoire est atteinte et que des données précieuses disparaissent de la mémoire ; je résous ce problème en augmentant la mémoire vive (RAM), en allégeant les types de données ou en ajustant les TTL. La valeur « instantaneous_ops_per_sec » reflète ma charge de travail actuelle ; je mets en corrélation les fortes variations avec les mises en production, les pics de trafic ou les backends afin d’identifier les causes et les effets. Si expired_keys augmente fortement, je vérifie si les TTL agressifs sont voulus ou si les applications laissent les clés expirer par inadvertance. Grâce à ces indicateurs, je construis une Point de vue de la performance et je prends des décisions fondées sur des données.
Réplication : rôle, latences et état des liaisons
Je vérifie le rôle (master ou réplica) et je recoupe les données de `connected_slaves` avec l'état des connexions afin de m'assurer que les chaînes de basculement ne génèrent pas de décalage dans les données. Une valeur de `master_link_down_since` supérieure à quelques secondes indique pour moi qu’il faut intervenir, car les répliques peuvent devenir obsolètes et les charges de lecture peuvent fournir des résultats incohérents. Grâce à `master_last_io_seconds_ago`, je détecte les goulots d’étranglement réseau, les chemins d’E/S perturbés ou les nœuds surchargés, que je soulage de manière ciblée. En cas de problèmes de réplication, je réduis temporairement la charge d’écriture, je sauvegarde les données critiques et j’analyse les chemins réseau avant de déclencher une reconstruction. Je garantis ainsi l’actualité des données et Consistance à portée de vue, sans compromettre les services de lecture.
Processeur et modèles d'instructions : attribuer correctement la charge
Je consulte les indicateurs « used_cpu_sys » et « used_cpu_user » pour distinguer les parts système et utilisateur, et mieux comprendre l'origine des opérations intensives. En combinaison avec les indicateurs ops/sec et SLOWLOG, j’identifie les commandes inefficaces ou les modèles de données inappropriés, que j’optimise de manière ciblée. En cas de charge CPU constamment élevée, je vérifie le comportement des traitements par lots, les scripts Lua, les clés volumineuses et les clés « chaudes » qui provoquent des pics. J’affine ensuite les structures de données, je réduis les allers-retours et je mets les résultats en cache afin de lisser les pics de charge. Je garantis ainsi une Temps de réponse et empêcher que les saturations du processeur ne se propagent latéralement.
Espaces de clés et TTL : gérer la croissance
J'analyse l'espace de clés par base de données et je surveille les clés, les dates d'expiration et l'avg_ttl afin d'identifier la croissance et de gérer les cycles de vie. Un grand nombre de clés sans date d'expiration indique une croissance à long terme, que j'atténue à l'aide des TTL, de la compression ou d'autres types de données. Une valeur avg_ttl plausible m’indique si les données sont actives ou si des entrées obsolètes occupent de l’espace. Pour les bases de données très sollicitées, je répartis la charge sur plusieurs instances ou j’active le cluster lorsque le sharding s’avère pertinent. Je préviens ainsi les surprises Augmentation de la capacité de stockage et maintiens les indicateurs dans les limites prévues.
Analyse automatisée et tableaux de bord
J'analyse les données INFO de manière automatisée et je transmets les métriques à des bases de données de séries chronologiques afin de mettre en évidence les tendances, la saisonnalité et les valeurs aberrantes. Pour les environnements de production, je m'appuie sur des tableaux de bord centralisés et j'intègre des règles d'alerte avec des procédures d'escalade. Si vous souhaitez vous lancer, vous pouvez commencer par Prometheus et Grafana créer très rapidement des tableaux de bord et des notifications. Je veille à l'uniformité des libellés, à la cohérence des intervalles de mesure et à la clarté des unités, afin que tous les graphiques restent fiables. On obtient ainsi un tableau de bord clair Suivi, que j'utilise au quotidien sans aucun problème.
Tableau : aperçu rapide des principaux indicateurs INFO
J'utilise le guide de référence rapide ci-dessous pour comparer de manière concise les symptômes, les valeurs d'exemple et les premières mesures à prendre, afin d'accélérer la prise de décision ; ce tableau est mon outil de référence rapide Antisèche dans l'incident.
| Métriques | Symptôme typique | Seuil d'alarme (exemple) | mesure immédiate |
|---|---|---|---|
| used_memory | Augmentation de la consommation de mémoire vive (RAM) | > 85% RAM permanente | Augmenter la mémoire, vérifier les TTL, choisir des types de données plus légers |
| mem_fragmentation_ratio | Occupation inutile | > 1,3 stable | Vérifier la configuration, redémarrage planifié, analyser la fragmentation |
| keyspace_hits/misses | Faible taux de réussite | Taux de réussite < 80% | Ajuster les TTL, effectuer un « warmup », revoir la stratégie de mise en cache |
| evicted_keys | Données refoulées | > 0 pendant une longue période | Augmenter la mémoire vive (RAM), ajuster maxmemory/policy, réduire le volume de données |
| opérations instantanées par seconde | Pics de charge | +200% par rapport à la valeur de référence | Identifier les pics, atténuer les touches de raccourci, limiter le débit |
| master_link_down_since | Réplique obsolète | > 5 à 10 s | Vérifier le réseau, réduire la charge, stabiliser la réplication |
| used_cpu_sys/user | Temps CPU élevé | > 80% Noyau(x) en minutes | Vérifier les commandes, adapter le modèle de données, lisser les lots |
Meilleures pratiques : seuils, historique, contexte
Je définis les seuils à partir de références, et non pas en me fiant à mon intuition, et je les adapte en fonction de l'heure de la journée et de la saison de trafic. Je considère les séries historiques comme une base décisionnelle solide, car les tendances signalent très tôt les changements. Le contexte reste important : un grand nombre de clés expirées (expired_keys) peut être souhaitable, tandis que les clés évincées (evicted_keys) indiquent généralement une réelle pression. Je consigne les modifications apportées aux TTL, aux politiques et aux limites afin de pouvoir attribuer clairement les effets observés dans les séries chronologiques. Ainsi, les alertes pertinent et reflètent des risques réels plutôt que du bruit.
Processus de dépannage avec INFO
Je lance des parcours de diagnostic avec les commandes INFO stats et memory, puis je vérifie les champs liés à la réplication et je passe au SLOWLOG lorsque les latences augmentent. En cas d'anomalies de mémoire, je compare « used_memory », le taux de fragmentation et les évictions avant de vérifier la taille des dumps et les paramètres de persistance. Pour m'aider, j'utilise des guides pratiques tels que le Guide Redis Insight, afin d'identifier rapidement les raccourcis clavier, les valeurs élevées et les commandes inefficaces. Je limite chaque modification au strict minimum, j'évalue immédiatement les effets et je reviens en arrière si les indicateurs s'enveniment. Ce processus me fait gagner Temps et évite les réactions irréfléchies lors d'un incident.
Persistance et durabilité : RDB/AOF sans surprises
Je note cette section persévérance afin d'éviter les latences d'écriture, les coûts liés à la création de branches et les risques de perte de données. Des champs tels que rdb_bgsave_in_progress, rdb_last_bgsave_status et changes_since_last_save m’indiquent si des instantanés sont en cours d’exécution, s’ils ont été effectués avec succès la dernière fois et quelle quantité de données non sauvegardées se trouve actuellement en mémoire. Si la valeur de changes_since_last_save augmente rapidement, je planifie un moment de sauvegarde contrôlé ou j’augmente la fréquence, à condition que les coûts liés aux forks et aux E/S restent acceptables. Avec AOF, je surveille les champs aof_enabled, aof_last_write_status, aof_rewrite_in_progress et aof_current_rewrite_time_sec ; des erreurs répétées ou des temps de réécriture extrêmement longs sont pour moi des signaux clairs qu’il faut vérifier les performances du disque et les paramètres AOF. J’évalue la stratégie fsync (par exemple « everysec » vs « always ») en fonction du contexte : pour les charges de travail sensibles à la latence, je maintiens la stabilité avec « everysec », vraiment cohérent Lorsque les exigences imposent des paramètres plus stricts, je prévois délibérément la latence supplémentaire dans mon budget. La commande `lazyfree_pending_objects` me permet de détecter si les libérations asynchrones génèrent un engorgement ; dans ces phases, je planifie les modifications avec prudence et j'évite ainsi de nouvelles vagues de mémoire.
Commandstats et diagnostic de la latence : identifier les véritables facteurs de coûts
Je jette un œil à commandstats sur les appels et usec_per_call, afin d’identifier les instructions qui consomment du temps – non seulement en valeur absolue, mais aussi proportionnellement à l’utilisation. Les instructions fréquentes mais coûteuses (par exemple SORT, SINTER, HGETALL de grande taille) constituent mes premières cibles d’optimisation : je les remplace, dans la mesure du possible, par des accès ciblés, une pré-agrégation ou des types de données alternatifs. En combinaison avec SLOWLOG, je distingue les pics des problèmes chroniques ; un usec_per_call élevé associé à un faible volume de SLOWLOG indique souvent large Je me concentre sur la latence plutôt que sur des valeurs aberrantes isolées. Pour un objectif de production, je définis une latence p99 par catégorie (lecture, écriture, multi/script) et je l'associe à des SLI pouvant déclencher des alertes : Si la p99 reste stable, le service fonctionne correctement ; si les valeurs p95 et p99 augmentent, je déclenche une escalade précoce avant que les délais d'attente n'affectent les utilisateurs.
Réseau et E/S : débit, mémoire tampon et contre-pression
J'utilise les indicateurs « instantaneous_input_kbps » et « instantaneous_output_kbps » pour analyser la charge du réseau à court terme, et je les compare au nombre d'opérations par seconde (ops/sec) : si ce rapport s'écarte soudainement, j'examine la taille des charges utiles ou les transferts binaires (par exemple, les valeurs élevées). Les champs tels que total_net_input_bytes et total_net_output_bytes me sont utiles pour analyser les tendances à long terme et planifier la capacité. Si des « rejected_connections » apparaissent, cela signifie que le serveur ne réagit pas assez vite ou que la gestion des connexions n’est pas correctement dimensionnée ; je vérifie alors les écouteurs, le backlog et le pooling des clients. J’interprète les métriques client_recent_max_output_buffer, client_biggest_input_buf et client_longest_output_list comme des indicateurs de pression : si elles augmentent, je recherche des consommateurs lents, des clients « bavards » ou des erreurs de pipeline. En matière de réplication, j’ajoute les métriques `sync_partial_ok/err`, ainsi que `repl_backlog_size` et `repl_backlog_histlen`, afin de détecter les resynchronisations partielles et la saturation du backlog ; en cas de goulots d’étranglement, j’augmente temporairement la taille du backlog ou je lisse les pics d’écriture.
Analyser la mémoire plus en détail : ensemble de données, surcoût et défragmentation
Je sépare ensemble de données de mémoire utilisée à partir de surcoût_mémoire_utilisée, afin de comprendre quelle part de mémoire est réellement consacrée aux données utiles et quelle part est affectée aux métadonnées, à l'allocateur et aux tâches administratives internes. Si la part de surcharge augmente de manière disproportionnée, la présence de nombreuses petites clés ou des mises à jour fréquentes alourdissent la charge administrative ; je réagis en adoptant des structures compactes (par exemple, des hachages/listes sous forme compressée), des TTL plus pertinents et des modèles d’écriture par lots. Grâce à used_memory_rss et allocator_frag_ratio, je détecte si le processus conserve plus de pages physiques que nécessaire ; si active_defrag_running est à 1, j’observe de manière ciblée l’effet sur le RSS et la latence. Je n’augmente pas la défragmentation „ à l’aveugle “, mais lors de fenêtres de maintenance ou en cas de pression calculée – l’objectif est la stabilité sans coûts indésirables incontrôlés. Grâce à la métrique maxmemory_policy, je m’assure que la règle d’éviction correspond à ma charge de travail ; j’accompagne toute modification de cette règle d’une télémétrie rigoureuse, car elle modifie fondamentalement les chemins d’accès.
Clusters, sharding et Sentinel : garantir la lisibilité des états
Dans les configurations en cluster, j'utilise INFO cluster (par exemple, cluster_state, cluster_slots_ok/fail, cluster_known_nodes), afin de vérifier le routage et l'état des slots. Si le nombre de slots défaillants augmente, cela risque d'entraîner des tempêtes de redirection et une augmentation des latences ; je suspends alors les activités de migration et rétablis l'équilibre des slots. Les compteurs cluster_stats_messages_sent/received m’indiquent si le Gossip/State-Exchange s’intensifie ; des pics soudains indiquent un flapping ou des liaisons instables. Dans les scénarios Sentinel, je veille à ce que les quorums soient stables et que les temps de basculement soient conformes à mes SLO ; je simule régulièrement des pannes pour vérifier que les délais de réplication et les temps de promotion restent dans les limites attendues. En matière de sharding, je planifie la capacité par groupe de slots, je surveille les slots « chauds » (indirectement via commandstats et les points chauds de clés) et je tiens à disposition des runbooks pour le rééquilibrage et les migrations de slots.
SLI, SLO et conception des alertes : des indicateurs à la fiabilité
Je dirige SLIs directement à partir d'INFO et je les complète si nécessaire avec des points de mesure d'application : Je mesure la disponibilité à partir du taux de commandes réussies et de la proportion de requêtes rejetées/retardées ; je formule les objectifs de latence avec les valeurs p95/p99 par chemin ; j’évalue la cohérence dans les configurations répliquées à partir du retard de réplication. À partir de ces indicateurs de performance clés (SLI), je définis SLOs (par exemple, p99 < 5 ms pour les lectures, Replag < 200 ms, Evictions = 0 en fonctionnement normal) et je les associe à des règles d'escalade. Je configure les alertes selon plusieurs niveaux : des alertes précoces en cas d’écarts de tendance par rapport aux valeurs de référence, et des alertes plus strictes lorsque les valeurs absolues atteignent les seuils limites. Je préviens la lassitude face aux alarmes grâce à l’atténuation, à l’hystérésis et aux fenêtres de maintenance ; parallèlement, j’enregistre les causes des alarmes de manière structurée afin de pouvoir évaluer rétrospectivement les décisions de réglage. C’est ainsi que les indicateurs clés se transforment en données fiables Objectifs de service, au lieu de ne produire que du bruit.
Guides d'intervention, tests et pratiques opérationnelles : la routine plutôt que la précipitation
Je considère que les Runbooks Prêt : que faire en cas d'évictions, d'engorgement de la réplication, d'augmentation de la fragmentation ou de pics de latence ? Chaque runbook décrit les étapes de mesure (quelles sections INFO, quelle période), les mesures correctives (par exemple, lisser la charge, activer la défragmentation, découpler la réplication), les critères de réussite et la restauration. Je teste régulièrement ces procédures en environnement de préproduction avec une charge synthétique et des ensembles de données réalistes, afin que l’équipe d’astreinte n’ait pas à apprendre sur le tas en cas d’urgence. Dans les environnements de conteneurs et de machines virtuelles, je veille à ce que les limites cgroup, les réservations et les risques de swapping soient adaptés à la configuration Redis ; je répercute les limites dans maxmemory et surveille de près used_memory_rss afin d’éviter les effets de l’OOM Killer. Je documente de manière transparente les limites d’exploitation (QPS maximal, volume de données, tolérance au replag) ; ainsi, les décisions relatives à l’augmentation des capacités restent objectives et compréhensibles.
Mise en œuvre concrète dans le quotidien de l'hébergement
Je planifie les capacités de manière anticipée : de la mémoire vive pour la croissance, de la puissance CPU pour les pics de charge, des chemins réseau pour la réplication et, le cas échéant, le partitionnement en clusters. Je répartis les différentes instances de manière à ce que les chemins critiques ne convergent pas vers un seul nœud, tout en veillant à ce que les chaînes de basculement restent clairement documentées. Pour les projets à forte charge, je choisis des fournisseurs proposant une allocation transparente des ressources et une qualité de réseau fiable ; l'expérience montre que des fournisseurs tels que webhoster.de se révèlent très convaincants à cet égard. Cela me permet de tirer pleinement parti des informations issues de la surveillance et de résoudre durablement les goulots d'étranglement. Cela se répercute directement sur Disponibilité et l'expérience utilisateur.
En bref : INFO, le centre de contrôle
Je considère « redis info » comme un rapport système concis qui me permet de cerner l’état, les performances et la configuration en quelques secondes. En consultant des sections de manière ciblée, en interprétant les métriques dans leur contexte et en définissant des alertes pertinentes, je minimise les risques et assure la fiabilité des services. Les tableaux de bord, les automatismes et des guides d’intervention clairs transforment les résultats textuels en décisions concrètes. Qu’il s’agisse du cache, du stockage des sessions ou de la messagerie : grâce à un analyse syntaxique rigoureux, à des valeurs de référence fiables et à des étapes d’optimisation rigoureuses, j’obtiens des résultats prévisibles. Ainsi, l’exploitation reste contrôlable et réagit de manière maîtrisée, même sous pression.
