Ce que je surveille vraiment sur mon homelab (3 métriques utiles, 10 qui ne servent à rien)

Quand j’ai monté Prometheus et Grafana, j’ai fait comme tout le monde : j’ai importé un tableau de bord communautaire. Résultat : 40 panneaux, des courbes qui bougent dans tous les sens, et un sentiment très net de compétence devant mon écran.

Puis Nextcloud est tombé en panne silencieuse pendant 48 heures (disque plein, je l’ai raconté ailleurs). Mon beau tableau de bord affichait bien l’espace disque. Simplement, je ne le regardais pas, et rien ne me prévenait.

Leçon : un tableau de bord impressionnant ne surveille rien tant que personne ne le regarde. Ce qui compte, c’est la poignée de signaux qui, s’ils passent au rouge, te font réagir.

Voici ce que j’ai gardé, et ce que j’ai jeté.

Les 3 métriques qui m’ont vraiment servi

1. L’espace disque restant

C’est la reine des pannes domestiques. Un disque plein, et tout dégénère : bases de données qui refusent d’écrire, sauvegardes qui échouent, services qui plantent de façon étrange.

La requête que j’utilise (avec node_exporter) pour le pourcentage d’espace libre :

node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
  / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} * 100

Et la version « prédictive », que j’aime beaucoup : est-ce que ce disque sera plein dans les 4 prochaines jours si ça continue comme ça ?

predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 4*24*3600) < 0

La différence est énorme : le pourcentage te prévient quand il est déjà tard, la prédiction te prévient quand il est encore temps.

2. « Est-ce que ça répond ? »

Prometheus sait si une cible est joignable grâce à la métrique up :

up == 0

C’est presque trop simple, et pourtant c’est le signal le plus fiable. Une machine éteinte, un service planté, un réseau coupé : up passe à 0.

Pour aller plus loin, une sonde de l’extérieur (un petit contrôle HTTP qui interroge tes services comme le ferait un visiteur) attrape les cas où le service tourne mais ne fonctionne plus vraiment. Je l’héberge sur une machine séparée : si le homelab tombe, la surveillance ne tombe pas avec.

3. La mémoire et le swap

Pas la mémoire « utilisée » (Linux utilise volontiers toute la RAM pour son cache, et c’est normal). Ce qui compte, c’est la mémoire réellement disponible et surtout le swap.

node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

Et pour le swap :

node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes

Un swap qui se remplit durablement, c’est le symptôme d’une machine trop chargée. Chez moi, c’est exactement ce qui m’a alerté d’une allocation de RAM trop gourmande sur mes VM.

Les 10 trucs que j’ai fini par retirer

Je ne dis pas que ces métriques sont inutiles en soi. Elles le sont pour moi, à cette échelle, sans que quelqu’un les regarde en continu :

1. L’utilisation CPU instantanée. Elle monte et descend toute la journée. Un pic n’est pas un problème.
2. Le débit réseau en temps réel. Joli, mais je n’agis jamais dessus.
3. Les I/O disque détaillées par périphérique. Utile pour diagnostiquer, pas pour surveiller.
4. Le nombre de processus. Sans seuil de référence, ça ne veut rien dire.
5. L’uptime. On aime le voir grimper, mais un long uptime n’est pas un objectif (un serveur jamais redémarré n’a pas reçu ses correctifs noyau).
6. Les dizaines de métriques par cœur CPU. Du bruit.
7. Les graphiques de température sans seuil. À moins d’avoir défini ce qui est « trop chaud ».
8. Le détail de chaque conteneur. À regarder au besoin, pas en permanence.
9. Les compteurs d’erreurs réseau cumulés. Ils ne reviennent jamais à zéro, donc ils ne disent rien sans calcul de taux.
10. Le tableau de bord à 40 panneaux lui-même. Il m’a plus servi à me rassurer qu’à me prévenir.

Mon critère de tri est simple : « si ça change, est-ce que je fais quelque chose ? » Si la réponse est non, ça sort de l’écran principal.

La règle qui change tout : une alerte, c’est une décision

Une métrique sans seuil est un décor. Une métrique avec un seuil et une notification devient un outil. Je me suis imposé quatre règles :

1. Peu d’alertes. Trois ou quatre, pas trente. Sinon, on finit par toutes les ignorer.
2. Chaque alerte appelle une action. « Disque à 90 % » = je fais le ménage. « CPU à 80 % pendant 10 secondes » = je ne fais rien, donc ce n’est pas une alerte.
3. Une durée avant de se déclencher. for: 10m évite les fausses alertes sur un pic ponctuel.
4. Un canal que je lis vraiment. Une notification sur mon téléphone, pas un e-mail dans un dossier que j’ouvre une fois par mois. (Voir l’article sur les notifications.)

Un exemple de règle d’alerte :

groups:
  - name: homelab
    rules:
      - alert: DisquePresquePlein
        expr: predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 4*24*3600) < 0
        for: 30m
        annotations:
          summary: "Disque {{ $labels.mountpoint }} sur {{ $labels.instance }} plein d'ici 4 jours"

Mon tableau de bord actuel

Un seul écran, lisible d’un coup d’œil :

• une ligne par machine avec un voyant vert/rouge (up),
• l’espace disque restant par volume,
• la mémoire disponible et le swap.

Tout le reste est dans des tableaux de bord secondaires que j’ouvre quand j’enquête, pas pour surveiller.

Pour conclure

Le piège du monitoring de homelab, c’est de le prendre pour un jeu de décoration. Plus il y a de courbes, plus ça fait sérieux. Mais ce qui sauve vraiment ta soirée, c’est ce petit message qui dit « ton disque sera plein jeudi » quand on est encore lundi.

Alors, ouvre ton tableau de bord, et pour chaque panneau demande-toi : « si ça passe au rouge, qu’est-ce que je fais ? » Si tu n’as pas de réponse, tu peux le supprimer sans regret.