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.

Grafana affiche, il ne collecte pas. Comment relier une source de métriques, construire les panneaux CPU, RAM et disque, et lire correctement les courbes lors d'un incident.
Comment surveiller CPU, RAM et disque avec Grafana

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

ComposantRôle
AgentInstallé sur chaque système, mesure les métriques système
CollecteurReçoit, stocke et historise les métriques (Zabbix, Prometheus…)
GrafanaInterroge 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 :

UsageFenêtreRafraîchissement
Diagnostic d'incident en cours1 à 6 heures1 minute
Suivi quotidien24 heures5 minutes
Tendance et capacité30 jours1 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 :

  1. Vue d'ensemble du parc : une ligne par système, état de santé, disque, mémoire, charge. C'est la vue quotidienne.
  2. Vue par système : le détail complet, ouvert uniquement quand un problème est identifié.
  3. 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é

Accessible dans l'interface, sans compte ni installation séparée.

Tableaux de bord
Préconfigurés

Vue parc, vue par système et tendances, disponibles dès le premier agent installé.

Source de données
Zabbix 7.4

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

Partagez ce lien

Protégez votre infrastructure dès aujourd'hui

Démarrez gratuitement, sans carte bancaire requise