Comment surveiller CPU, RAM et disque avec Grafana
Construire des tableaux de bord Grafana pour surveiller processeur, mémoire et disque : quelle source de données, quels panneaux choisir, quels intervalles de rafraîchissement et quels pièges de lecture éviter.
Protégez votre infrastructure dès aujourd'hui
Démarrez gratuitement, sans carte bancaire requise
Grafana est probablement l'outil de visualisation de métriques le plus répandu. Une confusion revient pourtant systématiquement : Grafana ne collecte rien. C'est une couche d'affichage qui interroge une source de données. Sans un collecteur en amont — Zabbix, Prometheus, InfluxDB — un tableau de bord Grafana reste vide.
Cet article explique comment construire des tableaux de bord CPU, mémoire et disque exploitables, et surtout comment les lire correctement.
L'architecture : trois composants distincts
| Composant | Rôle |
|---|---|
| Agent | Installé sur chaque système, mesure les métriques système |
| Collecteur | Reçoit, stocke et historise les métriques (Zabbix, Prometheus…) |
| Grafana | Interroge le collecteur et affiche les courbes |
Les trois sont nécessaires. C'est le point qui bloque le plus souvent les débutants : ils installent Grafana, cherchent où ajouter leurs serveurs, et ne trouvent pas — parce que ce n'est pas son rôle.
Pour la suite, on suppose une source de données Zabbix, dont le connecteur Grafana est disponible officiellement.
Le panneau processeur
Quelle métrique afficher
Pas une seule courbe, mais une répartition. L'utilisation processeur se décompose en plusieurs états, et cette décomposition est souvent plus informative que le total :
- user : temps passé dans les applications
- system : temps passé dans le noyau
- iowait : temps passé à attendre le disque
- steal : temps volé par l'hyperviseur (machines virtuelles uniquement)
Un panneau Time series en mode empilé, avec une échelle de 0 à 100 %, donne immédiatement la nature de la charge.
Ce que révèle la décomposition
C'est là que le tableau de bord devient utile plutôt que décoratif :
- user élevé : charge applicative normale, dimensionnement à revoir si récurrent
- system élevé : activité noyau intense, souvent du réseau ou des entrées-sorties
- iowait élevé : le processeur attend le disque. Le problème n'est pas le processeur — chercher du côté du stockage
- steal élevé : l'hyperviseur est saturé. Le problème n'est pas sur votre système
Un processeur à 30 % dont 25 % d'iowait est un serveur en souffrance. Un processeur à 85 % de user est un serveur qui travaille. La courbe totale seule ne permet pas de les distinguer.
La charge moyenne, à part
Sur Linux, le load average mérite son propre panneau. Attention à sa lecture : ce n'est pas un pourcentage, mais un nombre de processus en attente. Sa valeur ne se lit que rapportée au nombre de cœurs — une charge de 4 est saine sur 8 cœurs, préoccupante sur 2.
Affichez-la avec une ligne de seuil positionnée au nombre de cœurs du système, sans quoi le panneau est illisible.
Le panneau mémoire
Le piège de la mémoire libre sous Linux
C'est l'erreur de lecture la plus fréquente. Le noyau Linux utilise délibérément toute la mémoire inoccupée comme cache disque. Un système en parfaite santé affiche donc presque toujours très peu de mémoire « libre » — et un tableau de bord qui affiche cette métrique déclenche des inquiétudes injustifiées à répétition.
La métrique à afficher est la mémoire disponible (available), qui tient compte du cache récupérable à tout moment.
Un panneau utile combine :
- mémoire disponible, en pourcentage, avec un seuil visuel à 15 %
- utilisation du swap, sur un axe distinct
Lire la mémoire correctement
Une fuite mémoire se reconnaît à une pente régulière sur plusieurs jours, pas à une valeur instantanée. C'est précisément ce qu'un tableau de bord apporte par rapport à une commande ponctuelle : la forme de la courbe.
Une activité de swap soutenue est un incident, même si tous les services répondent encore : les temps de réponse s'effondrent bien avant qu'un service ne s'arrête.
Le panneau disque
Occupation par volume
Un panneau Bar gauge avec un seuil coloré à 85 % et 95 % donne l'état de tous les volumes en un coup d'œil, ce qu'une courbe temporelle rend moins lisible quand les volumes sont nombreux.
Affichez chaque système de fichiers séparément. Un serveur avec /, /var et un volume de données a trois points de défaillance distincts.
La tendance, plus utile que l'instantané
Un disque à 60 % qui gagne 3 % par jour est plus urgent qu'un disque stable à 88 % depuis six mois. Un panneau Time series sur trente jours révèle cette pente, qu'aucun affichage instantané ne montre.
C'est le panneau le plus rentable d'un tableau de bord disque : il transforme une constatation en anticipation.
Les entrées-sorties
Deux métriques complémentaires du remplissage :
- débit en lecture et écriture, pour repérer une charge inhabituelle
- temps d'attente des requêtes, qui révèle un disque saturé avant que le débit ne plafonne
Un iowait processeur élevé sans débit disque important signale généralement une latence de stockage, pas un volume de données.
Régler l'intervalle de rafraîchissement
Une erreur classique consiste à mettre un rafraîchissement de 5 secondes sur tous les tableaux de bord. C'est inutile et coûteux : si l'agent collecte toutes les minutes, rafraîchir plus souvent affiche la même donnée, en sollicitant la base à chaque fois.
Réglez le rafraîchissement sur l'intervalle de collecte, pas en dessous :
| Usage | Fenêtre | Rafraîchissement |
|---|---|---|
| Diagnostic d'incident en cours | 1 à 6 heures | 1 minute |
| Suivi quotidien | 24 heures | 5 minutes |
| Tendance et capacité | 30 jours | 1 heure ou manuel |
Sur une fenêtre longue, les valeurs affichées sont des agrégats, pas des mesures brutes. Un pic de trente secondes disparaît d'une vue sur trente jours : c'est normal, et c'est pourquoi le diagnostic d'incident se fait toujours sur une fenêtre courte.
Organiser plutôt qu'accumuler
Un tableau de bord de quarante panneaux n'est consulté par personne. Une organisation qui fonctionne :
- Vue d'ensemble du parc : une ligne par système, état de santé, disque, mémoire, charge. C'est la vue quotidienne.
- Vue par système : le détail complet, ouvert uniquement quand un problème est identifié.
- Vue de capacité : tendances sur trente à quatre-vingt-dix jours, consultée mensuellement.
Trois tableaux de bord ciblés valent mieux qu'un seul exhaustif.
Le coût réel de cette approche
Construire tout cela demande d'installer et maintenir un collecteur, une base de données, Grafana, puis de créer les tableaux de bord et de les faire évoluer. Ce n'est pas difficile — c'est simplement récurrent, et ce travail retombe généralement sur une seule personne.
C'est le point traité dans combien coûte vraiment une stack Zabbix + Grafana à maintenir.
Avec Logiserv
Grafana est intégré et les tableaux de bord sont déjà construits : vue d'ensemble du parc, détail par système, historique et tendances. Il n'y a ni source de données à connecter, ni panneau à créer, ni instance Grafana à héberger.
- Visualisation
- Grafana intégré
- Tableaux de bord
- Préconfigurés
- Source de données
- Zabbix 7.4
Accessible dans l'interface, sans compte ni installation séparée.
Vue parc, vue par système et tendances, disponibles dès le premier agent installé.
Connexion déjà établie : aucune configuration de source à réaliser.
Le fonctionnement est décrit dans le monitoring en temps réel, et les tableaux de bord livrés dans dashboards Grafana préconfigurés.
Pour aller plus loin
- Quelles métriques surveiller sur un serveur — que mettre dans les panneaux
- Surveiller l'espace disque d'un serveur — seuils et prévision de saturation
- Dashboards Grafana préconfigurés — gagner du temps sur la construction
- Monitoring en temps réel — lecture des métriques pendant un incident
- Définition d'un dashboard Grafana
Protégez votre infrastructure dès aujourd'hui
Démarrez gratuitement, sans carte bancaire requise
Les autres services
Quelles métriques surveiller sur un serveur ? Le plan essentiel
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Monitoring en temps réel : lire et corréler les métriques serveur pendant un incident
Ce que « temps réel » veut dire en supervision, les quatre courbes à lire pendant un incident, les corrélations qui orientent le diagnostic et les fenêtres de temps à choisir.
Dashboards Grafana préconfigurés : gagner du temps sur la supervision
Pourquoi les dashboards Grafana préconfigurés accélèrent l'adoption du monitoring et aident les équipes IT à lire plus vite l'état de leur parc.