Monitoring en temps réel : lire et corréler les métriques serveur pendant un incident

Le monitoring en temps réel consiste à suivre les métriques d'un serveur au fil de leur collecte, plutôt que de consulter un historique après coup. C'est ce qui permet de constater l'effet immédiat d'une action pendant un incident — un service redémarré, un fichier supprimé, une charge qui retombe.

Encore faut-il savoir ce que l'on regarde. Un mur de graphiques qui bougent ne dit rien en soi : ce qui compte, c'est de connaître la fraîcheur réelle des données, les quelques courbes qui orientent le diagnostic et la manière de les croiser.

Ce que « temps réel » veut dire en supervision

Deux intervalles entrent en jeu, et les confondre mène à des attentes irréalistes :

• L'intervalle de collecte : la fréquence à laquelle l'agent mesure une métrique sur le système. Typiquement une valeur par minute pour les métriques système.
• L'intervalle de rafraîchissement : la fréquence à laquelle le tableau de bord réinterroge la base.

Rafraîchir l'affichage toutes les cinq secondes quand l'agent collecte toutes les minutes n'apporte rien : vous affichez douze fois la même valeur, en sollicitant la base à chaque fois. Le « temps réel » utile est donc borné par la collecte, pas par l'affichage.

Collecter plus souvent n'est pas gratuit non plus : chaque relevé supplémentaire occupe l'agent, le réseau et surtout la base de l'historique. Une minute est le bon compromis pour le processeur, la mémoire et le réseau ; l'espace disque, qui évolue lentement, se contente très bien d'un relevé toutes les cinq ou dix minutes.

Quelles métriques lire en direct

Pendant un incident, quatre courbes suffisent à orienter le diagnostic :

La décomposition du processeur est la plus informative : un serveur à 30 % d'utilisation dont 25 % d'attente disque est en souffrance, alors qu'un serveur à 85 % de charge applicative travaille normalement. La courbe totale seule ne permet pas de les distinguer.

Les files d'attente disque complètent utilement cette lecture : une file qui s'allonge alors que le débit reste stable signifie que le stockage ne suit plus, même si l'espace libre est confortable.

Corréler plutôt que regarder une seule courbe

L'intérêt d'une vue temps réel n'est pas de surveiller une métrique, mais de les superposer sur la même fenêtre de temps. Quelques associations qui reviennent souvent :

• Mémoire qui chute + swap qui monte + temps de réponse dégradés : manque de mémoire physique, sans qu'aucun service ne soit arrêté.
• Disque qui se remplit vite + trafic réseau entrant élevé : une copie ou une sauvegarde en cours, souvent non planifiée.
• iowait élevé + débit disque faible : latence de stockage, pas volume de données. Regarder du côté du matériel ou de l'hyperviseur.
• Charge élevée sur tous les systèmes d'un même hôte : le problème est sur l'hyperviseur, pas sur les invités.
• Nombre de processus qui grimpe sans charge processeur : des processus bloqués en attente (verrou, ressource réseau, stockage) qui s'accumulent.

C'est cette lecture croisée qui distingue un tableau de bord utile d'un mur de graphiques. Elle suppose que toutes les courbes partagent la même échelle de temps : zoomer sur un graphique doit recadrer tous les autres, sans quoi la corrélation se fait de mémoire, et mal.

Choisir la bonne fenêtre de temps

Sur une fenêtre longue, les valeurs affichées sont des agrégats : un pic de trente secondes disparaît d'une vue sur trente jours. Le diagnostic d'incident se fait donc toujours sur une fenêtre courte — c'est l'erreur la plus fréquente quand on cherche la cause d'un ralentissement passé.

Les pièges classiques

• Confondre moyenne et maximum. Une utilisation processeur « moyenne sur 5 minutes » à 60 % peut cacher des pointes à 100 % qui suffisent à faire expirer des requêtes. Pour un symptôme bref, cherchez la courbe la plus fine disponible.
• Lire la mémoire libre au lieu de la mémoire disponible. Sous Linux, le cache système occupe volontairement la mémoire inutilisée ; une mémoire « libre » faible est normale. C'est la mémoire disponible et l'activité de swap qui signalent un vrai manque.
• Oublier le contexte de l'hôte. Une machine virtuelle peut afficher une charge faible et des temps de réponse catastrophiques si son hyperviseur est saturé. Quand plusieurs invités souffrent en même temps, remontez d'un niveau.
• Réagir à chaque oscillation. Une courbe en direct bouge toujours. Une valeur n'est préoccupante que si elle s'écarte durablement de son comportement habituel — d'où l'intérêt de comparer avec la même heure la veille ou la semaine précédente.

Temps réel, statistiques et alertes : trois usages différents

La vue temps réel sert à comprendre un incident en cours et à vérifier l'effet d'une intervention. Elle ne remplace ni les alertes, qui préviennent quand personne ne regarde l'écran, ni les statistiques, qui montrent les tendances sur plusieurs semaines. Une organisation saine s'appuie sur les trois : l'alerte déclenche, le temps réel explique, les statistiques permettent d'anticiper la prochaine fois. Pour la partie tendances, voir comment surveiller CPU, RAM et disque avec Grafana et quelles métriques surveiller sur un serveur.

Dans Logiserv

Logiserv fournit ces courbes dans un tableau de bord Grafana déjà configuré, alimenté par les agents Zabbix de votre parc et accessible dès l'offre Pro, sans compte Grafana à créer. La présentation de la vue temps réel résume ce qu'elle apporte ; le mode d'emploi détaille comment l'ouvrir, choisir le système et la période, et que faire si un panneau reste vide.

Pour aller plus loin

• Surveiller CPU, RAM et disque avec Grafana : lire correctement les courbes
• Quelles métriques surveiller sur un serveur et à quels seuils
• Passer d'une supervision réactive à une supervision proactive
• Éviter les faux positifs Zabbix quand une alerte se déclenche sur une simple oscillation