Résoudre l’échec de pvestatd.service sur Proxmox : Restaurer rapidement graphiques et statistiques

Ce que fait réellement pvestatd (et ce qu’il ne fait pas)

pvestatd est le démon de statistiques de nœud de Proxmox. Sa tâche est de collecter périodiquement des métriques (nœud, VM/CT, stockage, quelques détails orientés cluster) et de stocker les séries temporelles pour que l’interface graphique puisse dessiner des graphiques et montrer des tendances. Ce n’est pas l’interface graphique elle-même et ce n’est pas un « système de monitoring » au sens Prometheus. C’est la plomberie qui permet aux graphiques intégrés de fonctionner.

Sur la plupart des installations, les graphiques sont pris en charge par des fichiers RRD (Round Robin Database) sous /var/lib/rrdcached/db et les mises à jour sont médiées par rrdcached pour éviter des E/S disque constantes. Quand pvestatd ne peut pas écrire les mises à jour — ou ne peut pas parler à rrdcached, ou ne peut pas lire proprement les statistiques système — il échoue ou se bloque. L’interface affiche alors des graphiques périmés ou vides, souvent sans explication utile.

Conclusion pratique : quand les graphiques disparaissent, ne fixez pas le navigateur. Déboguez pvestatd, rrdcached, la santé du stockage, les permissions et la synchronisation temporelle. Dans cet ordre.

Une vérité sèche : si vous fonctionnez sans données temporelles fiables, vous exploitez une production comme un pilote qui considère les altimètres comme des « accessoires optionnels ».

Mode opératoire de diagnostic rapide (premier/deuxième/troisième)

Premier : confirmer le mode d’échec (est-ce vraiment pvestatd ?)

• Vérifiez l’état du service et les logs récents. Vous cherchez une erreur claire : permission refusée, disque plein, socket manquant, RRD corrompu, saut temporel.
• Vérifiez si rrdcached tourne et si son socket existe.
• Vérifiez l’espace libre et la pression d’inodes sur le système de fichiers contenant les RRD.

Deuxième : isoler si c’est le chemin d’écriture ou de lecture

• Chemin d’écriture : peut-on mettre à jour les RRD ? Socket ? Permissions ? Disque ? Corruption ?
• Chemin de lecture : est-ce que pvestatd plante en collectant les statistiques des backends de stockage (ZFS, Ceph, NFS, iSCSI) ? Un stockage cassé unique bloque-t-il tout ?

Troisième : confirmer les implications en cluster

• Dans un cluster, voyez si un nœud est malade ou si tous le sont.
• Vérifiez la synchronisation temporelle et la communication du cluster. Des sauts temporels étranges peuvent faire paraître les RRD « en arrêt » ou manquants même si des mises à jour ont eu lieu.
• Si vous utilisez un stockage partagé pour les RRD (peu courant, mais ça arrive), vérifiez la santé du montage et la latence.

Ne commencez pas par des réinstallations. Ne commencez pas par des suppressions aléatoires. Et s’il vous plaît, ne « corrigez » pas le problème en désactivant la collecte des statistiques. C’est comme guérir une fièvre en cassant le thermomètre.

Faits et contexte intéressants (pourquoi ça casse ainsi)

1. RRD a été conçu à la fin des années 1990 pour stocker des séries temporelles de façon compacte et de taille fixe, échangeant du détail contre de la prévisibilité. Parfait pour des graphiques intégrés ; pas idéal pour l’analyse forensique.
2. rrdcached existe pour réduire l’amplification des écritures : sans lui, des mises à jour RRD fréquentes génèrent beaucoup d’écritures synchrones et usent inutilement les SSD.
3. Proxmox s’est historiquement appuyé sur RRD pour les graphiques intégrés parce que c’est simple, local et ne nécessite pas une pile de monitoring. Cette simplicité explique sa large adoption — et pourquoi les pannes surprennent.
4. Les fichiers RRD sont binaires et pointilleux. Une écriture partielle, un disque plein ou une erreur de système de fichiers peut les rendre illisibles, et les outils rapportent souvent « invalid header » plutôt que « votre disque vous a menti ».
5. Les sauts temporels peuvent briser l’illusion de continuité : RRD consolide les données en buckets ; si l’heure système saute en arrière/en avant, les graphiques peuvent montrer des trous ou des lignes plates sans erreur évidente.
6. Les services de nœud Proxmox sont des unités systemd. Un seul répertoire manquant, une mauvaise propriété ou une dépendance échouée peut pousser pvestatd en boucles de redémarrage qui semblent « en cours d’exécution » à première vue.
7. Le rendu des graphiques n’est pas fait par pvestatd. Le démon ne met à jour que les données ; l’interface les consomme. On chasse souvent le mauvais composant en premier (généralement l’UI).
8. Les backends de stockage peuvent empoisonner la chaîne de statistiques : un montage NFS bloqué, un Ceph dégradé ou une commande ZFS lente peut bloquer la collecte, provoquant des timeouts et des échecs de pvestatd.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des tâches réelles que j’exécuterais sur un nœud dont les graphiques manquent et dont pvestatd échoue. Chacune inclut ce que signifie la sortie et la décision à prendre. Exécutez-les en root ou avec les privilèges appropriés.

Task 1: Confirm service state and last failure reason

cr0x@server:~$ systemctl status pvestatd --no-pager
● pvestatd.service - PVE status daemon
     Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled)
     Active: failed (Result: exit-code) since Tue 2025-12-23 09:11:31 UTC; 2min 10s ago
    Process: 1442 ExecStart=/usr/bin/pvestatd (code=exited, status=1/FAILURE)
Dec 23 09:11:31 server pvestatd[1442]: unable to write rrd: Permission denied
Dec 23 09:11:31 server systemd[1]: pvestatd.service: Failed with result 'exit-code'.

Signification : Vous avez une erreur concrète. Ne devinez pas. « Permission denied » pointe fortement vers la propriété/le mode des répertoires RRD ou du socket rrdcached.

Décision : Passez aux vérifications de permissions (Pression de stockage, permissions) et aux vérifications du socket rrdcached.

Task 2: Read the journal for context (often shows the first real error)

cr0x@server:~$ journalctl -u pvestatd -b --no-pager -n 200
Dec 23 09:11:30 server pvestatd[1442]: starting server
Dec 23 09:11:31 server pvestatd[1442]: rrdcached: connect to /var/run/rrdcached.sock: No such file or directory
Dec 23 09:11:31 server pvestatd[1442]: can't initialize rrd: No such file or directory

Signification : Ce n’est pas un problème de permissions ; le socket est manquant. Soit rrdcached ne tourne pas, soit il est configuré avec un chemin de socket différent, soit le répertoire est manquant.

Décision : Vérifiez le service rrdcached et le chemin du socket.

Task 3: Check rrdcached health and socket existence

cr0x@server:~$ systemctl status rrdcached --no-pager
● rrdcached.service - data caching daemon for rrdtool
     Loaded: loaded (/lib/systemd/system/rrdcached.service; enabled)
     Active: active (running) since Tue 2025-12-23 08:55:02 UTC; 18min ago
   Main PID: 612 (rrdcached)
     Tasks: 1
     Memory: 2.3M
Dec 23 08:55:02 server rrdcached[612]: starting up

cr0x@server:~$ ls -l /var/run/rrdcached.sock
ls: cannot access '/var/run/rrdcached.sock': No such file or directory

Signification : Le service tourne mais le socket n’est pas à ce chemin. Le démon pourrait utiliser un emplacement de socket différent (différences d’empaquetage entre distributions) ou échouer à le créer.

Décision : Trouvez le chemin réel du socket et alignez les attentes de Proxmox ou la configuration du service.

Task 4: Locate the real rrdcached socket and verify it’s a socket

cr0x@server:~$ ss -xlpn | grep rrdcached
u_str LISTEN 0      4096   /run/rrdcached/rrdcached.sock  12345              * 0    users:(("rrdcached",pid=612,fd=4))

Signification : Le socket est en réalité /run/rrdcached/rrdcached.sock. Si pvestatd est codé en dur ou configuré pour utiliser /var/run/rrdcached.sock, il y a un décalage.

Décision : Confirmez comment Proxmox est configuré pour se connecter ; corrigez en modifiant la config ou en créant un lien symbolique avec prudence.

Task 5: Check for the expected symlink (common fix)

cr0x@server:~$ ls -ld /var/run
lrwxrwxrwx 1 root root 4 Dec 23 08:40 /var/run -> /run

cr0x@server:~$ ls -l /run/rrdcached/rrdcached.sock
srwxrwxrwx 1 root root 0 Dec 23 08:55 /run/rrdcached/rrdcached.sock

Signification : /var/run pointe vers /run. Mais le nom attendu du socket diffère. Parfois Proxmox cherche /run/rrdcached.sock tandis que rrdcached utilise un sous-répertoire.

Décision : Reconfigurer rrdcached pour créer le socket où Proxmox l’attend, ou créer un lien symbolique (préférez la config, acceptez le symlink si vous savez ce que vous faites).

Task 6: Inspect rrdcached defaults (socket and base directory)

cr0x@server:~$ grep -E 'SOCK|BASE|OPTS' /etc/default/rrdcached
SOCKGROUP=www-data
BASE_PATH=/var/lib/rrdcached
DAEMON_OPTS="-l unix:/run/rrdcached/rrdcached.sock -g -w 1800 -z 1800 -f 3600 -j /var/lib/rrdcached/journal/"

Signification : Le socket est explicitement configuré. Proxmox doit parler à ce socket. S’il ne le peut pas, il échoue.

Décision : Faites en sorte que Proxmox utilise le socket configuré, ou configurez rrdcached pour fournir celui attendu.

Task 7: Check disk space and inodes where RRD lives (graphs die on “full”)

cr0x@server:~$ df -h /var/lib/rrdcached /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        30G   30G     0 100% /

cr0x@server:~$ df -i /var/lib/rrdcached
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2      196608 196608     0  100% /

Signification : Vous êtes à court d’espace et d’inodes. Ce n’est pas « le monitoring qui a cassé », c’est « le système qui étouffe ». Les mises à jour RRD échouent ; les démons plantent ; d’autres services suivront.

Décision : Libérez immédiatement de l’espace/des inodes, puis réparez les RRD si nécessaire. Ne relancez pas les services sur un FS plein ; vous ne ferez que générer plus de logs et de douleur.

Task 8: Identify what ate your disk (quickly, without drama)

cr0x@server:~$ du -xhd1 /var | sort -h
120M    /var/cache
380M    /var/lib
1.2G    /var/log
28G     /var

Signification : L’utilisation disque est concentrée dans /var. Creusez maintenant dans /var/log et /var/lib.

Décision : Faites la rotation/tronquez les logs qui débordent, purgez les caches, corrigez la cause du flood de logs. Puis redémarrez les services de statistiques.

Task 9: Look for log storms that also cause inode exhaustion

cr0x@server:~$ ls -lh /var/log | tail -n 10
-rw-r----- 1 root adm  12G Dec 23 09:10 syslog
-rw-r----- 1 root adm 8.1G Dec 23 09:09 kern.log
-rw-r----- 1 root adm  55M Dec 23 08:50 pveproxy/access.log

Signification : Syslog et kern.log sont énormes. Quelque chose spamme. Réparer pvestatd sans régler le spam, c’est bacher un bateau sans colmater le trou.

Décision : Stoppez la source du spam ; rotaez ou tronquez les logs en toute sécurité ; récupérez de l’espace. Puis confirmez que pvestatd et rrdcached peuvent écrire.

Task 10: Verify ownership and permissions of RRD directories

cr0x@server:~$ ls -ld /var/lib/rrdcached /var/lib/rrdcached/db
drwxr-xr-x 5 root root 4096 Dec 23 08:55 /var/lib/rrdcached
drwxr-xr-x 6 root root 4096 Dec 23 08:55 /var/lib/rrdcached/db

Signification : Possédé par root, ce qui est souvent incorrect pour le modèle de mise à jour de rrdcached. Selon votre configuration, rrdcached attend une propriété par rrdcached user/group ou des permissions de groupe spécifiques au socket.

Décision : Vérifiez l’utilisateur d’exécution de rrdcached et corrigez la propriété. Évitez les chmod 777 récursifs « pour dépanner ». Vous le regretterez.

Task 11: Confirm rrdcached user and effective permissions

cr0x@server:~$ ps -o user,group,pid,cmd -p $(pidof rrdcached)
USER     GROUP    PID CMD
rrdcached rrdcached 612 rrdcached -l unix:/run/rrdcached/rrdcached.sock -g -w 1800 -z 1800 -f 3600 -j /var/lib/rrdcached/journal/

Signification : Le démon s’exécute en tant que rrdcached. Il a besoin d’un accès en écriture à son journal et à ses répertoires DB.

Décision : Appliquez la bonne propriété rrdcached:rrdcached sur /var/lib/rrdcached (si c’est votre configuration) et assurez-vous que les permissions de groupe correspondent à l’accès au socket si applicable.

Task 12: Fix directory ownership safely (only after confirming config)

cr0x@server:~$ chown -R rrdcached:rrdcached /var/lib/rrdcached
cr0x@server:~$ systemctl restart rrdcached
cr0x@server:~$ systemctl restart pvestatd
cr0x@server:~$ systemctl is-active pvestatd
active

Signification : Les services sont revenus. C’est nécessaire, pas suffisant.

Décision : Confirmez que les graphiques se mettent à jour en vérifiant les timestamps des RRD et les logs de pvestatd.

Task 13: Validate RRD updates (timestamps should move)

cr0x@server:~$ find /var/lib/rrdcached/db -type f -name '*.rrd' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | tail -n 5
2025-12-23 09:14 /var/lib/rrdcached/db/pve2-node/server/cpu.rrd
2025-12-23 09:14 /var/lib/rrdcached/db/pve2-node/server/mem.rrd

Signification : Les fichiers RRD sont remontés. C’est un bon indicateur que les mises à jour ont repris.

Décision : Si les timestamps ne bougent pas, retournez au débogage du socket/du chemin d’écriture.

Task 14: Catch corruption (RRD “invalid header” is your clue)

cr0x@server:~$ rrdtool info /var/lib/rrdcached/db/pve2-node/server/cpu.rrd | head
ERROR: /var/lib/rrdcached/db/pve2-node/server/cpu.rrd: invalid header (bad magic)

Signification : Ce fichier est corrompu. Il ne sera pas affiché. pvestatd peut échouer en tentant de le mettre à jour (selon son traitement).

Décision : Remplacez le RRD corrompu par un fichier neuf (perte de données pour cette série) ou restaurez-le depuis des sauvegardes si vous en disposez.

Task 15: Identify how widespread corruption is

cr0x@server:~$ find /var/lib/rrdcached/db -type f -name '*.rrd' -print0 | xargs -0 -n1 sh -c 'rrdtool info "$0" >/dev/null 2>&1 || echo "BAD $0"' | head
BAD /var/lib/rrdcached/db/pve2-node/server/cpu.rrd
BAD /var/lib/rrdcached/db/pve2-node/server/loadavg.rrd

Signification : Vous pouvez quantifier le rayon d’impact. Si ce n’est que quelques fichiers, remplacez-les. Si ce sont des centaines, envisagez de réinitialiser tout l’arbre RRD après avoir traité le problème de disque.

Décision : Remplacement ciblé pour une petite corruption ; réinitialisation complète pour une pourriture étendue (après vérification de l’intégrité du FS).

Task 16: Check time sync (graphs can “stop” because time is wrong)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-23 09:16:02 UTC
           Universal time: Tue 2025-12-23 09:16:02 UTC
                 RTC time: Tue 2025-12-23 06:12:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Signification : NTP est « active » mais l’horloge n’est pas synchronisée et le RTC dérive. Si l’heure saute, le comportement de RRD devient confus et les graphiques peuvent montrer des trous.

Décision : Réparez la synchronisation horaire avant de conclure que les statistiques sont cassées. Le temps est une dépendance, pas une suggestion.

Task 17: Spot storage backend timeouts that stall stats collection

cr0x@server:~$ journalctl -u pvestatd -b --no-pager | tail -n 20
Dec 23 09:05:11 server pvestatd[1320]: storage 'nfs-archive' status error: timeout waiting for response
Dec 23 09:05:11 server pvestatd[1320]: unable to update storage statistics

Signification : Un seul stockage problématique peut casser ou retarder la boucle de statistiques. Classique : vos graphiques meurent parce qu’un montage NFS est bloqué, pas parce que RRD est cassé.

Décision : Réparez ou désactivez temporairement la définition de stockage fautive ; confirmez que pvestatd se stabilise.

Task 18: Verify Proxmox storage status from the CLI (no UI guesswork)

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
local         dir     active        29454016        10240000        17600000   34.77%
nfs-archive   nfs     inactive              0               0               0    0.00%

Signification : Le stockage est inactif ; pvestatd s’en est plaint. Vous avez maintenant une raison claire.

Décision : S’il est requis, réparez le montage/le réseau. S’il est retire, supprimez-le de la config. Les stockages zombies tuent les statistiques.

RRD et rrdcached : réparation, réinitialisation et quand accepter la perte de données

Comprendre les éléments en jeu

La chaîne ressemble généralement à ceci :

• pvestatd collecte des valeurs périodiquement.
• Il soumet les mises à jour à rrdcached via un socket UNIX.
• rrdcached met en cache les mises à jour et les écrit dans les fichiers RRD.
• L’interface web Proxmox lit les données RRD et génère les graphiques.

Les pannes se regroupent autour de :

• Problèmes de socket : mauvais chemin, permissions, démon arrêté, fichier socket obsolète.
• Permissions de répertoire/fichier : rrdcached ne peut pas écrire son journal/DB, ou pvestatd ne peut pas se connecter.
• Disque plein / inodes saturés : les écritures échouent ; les journaux ne peuvent pas se vider ; les démons plantent.
• Corruption RRD : en-têtes invalides, fichiers tronqués, erreurs de lecture dues au stockage sous-jacent.
• Discontinuités temporelles : les mises à jour semblent « ne pas s’afficher » parce que l’heure système est incorrecte.

Décider : sauver vs réinitialiser

RRD n’est pas une base transactionnelle. Si vous avez de la corruption, vos options sont limitées :

• Petit nombre de fichiers corrompus : supprimez/remplacez ces fichiers et laissez Proxmox les recréer.
• Corruption à grande échelle : réinitialisez l’arbre RRD complet après avoir corrigé le problème de disque/FS. Acceptez la perte d’historique ; retrouvez la cohérence.
• Vous avez des sauvegardes/snapshots de /var/lib/rrdcached : restaurez le répertoire (meilleure option).

Opinion : si l’hôte a connu un incident disque-plein ou des erreurs de système de fichiers, et que vous voyez plusieurs fichiers RRD corrompus, arrêtez d’essayer de les préserver. Vous ne voulez pas d’historiques bâtis sur une pile de corruption silencieuse.

Réparation ciblée : remplacer seulement les séries corrompues

Après avoir arrêté les services, vous pouvez déplacer les RRD corrompus et permettre la régénération. Proxmox recréera les RRD manquants au fil des mises à jour.

cr0x@server:~$ systemctl stop pvestatd
cr0x@server:~$ systemctl stop rrdcached
cr0x@server:~$ mkdir -p /root/rrd-quarantine
cr0x@server:~$ mv /var/lib/rrdcached/db/pve2-node/server/cpu.rrd /root/rrd-quarantine/
cr0x@server:~$ systemctl start rrdcached
cr0x@server:~$ systemctl start pvestatd
cr0x@server:~$ systemctl is-active pvestatd
active

Ce que cela signifie : Vous avez sacrifié une série temporelle pour que les mises à jour reprennent. Le nouveau fichier sera créé ; votre graphique historique CPU est réinitialisé. C’est acceptable — vous vouliez du monitoring, pas de la nostalgie.

Réinitialisation complète : quand tout est pourri

Si la plupart des RRD sont corrompus ou si l’arbre DB est en désordre, réinitialisez-le. Mais seulement après avoir corrigé l’espace disque, l’intégrité du système de fichiers et la synchronisation horaire — sinon vous corromprez à nouveau les nouveaux fichiers.

cr0x@server:~$ systemctl stop pvestatd
cr0x@server:~$ systemctl stop rrdcached
cr0x@server:~$ mv /var/lib/rrdcached/db /var/lib/rrdcached/db.broken.$(date +%s)
cr0x@server:~$ mkdir -p /var/lib/rrdcached/db
cr0x@server:~$ chown -R rrdcached:rrdcached /var/lib/rrdcached
cr0x@server:~$ systemctl start rrdcached
cr0x@server:~$ systemctl start pvestatd

Ce que cela signifie : Vous repartez à zéro. En quelques minutes, les graphiques de l’UI devraient commencer à se remplir. S’ils ne le font pas, le problème n’était pas les vieux fichiers RRD — c’était la chaîne ou ses dépendances.

Vérification rapide : peut-on parler à rrdcached ?

Une vérification rapide consiste à voir si le socket existe et est inscriptible pour le groupe utilisateur du service. On ne peut pas toujours « tester l’écriture » facilement sans connaître les noms RRD, mais on peut confirmer le socket et ses permissions.

cr0x@server:~$ stat /run/rrdcached/rrdcached.sock
  File: /run/rrdcached/rrdcached.sock
  Size: 0         	Blocks: 0          IO Block: 4096   socket
Device: 0,21	Inode: 12345       Links: 1
Access: (0777/srwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-12-23 08:55:02.000000000 +0000
Modify: 2025-12-23 08:55:02.000000000 +0000
Change: 2025-12-23 08:55:02.000000000 +0000

Ce que cela signifie : Le socket existe et est largement inscriptible (peut-être trop). Si pvestatd se plaint toujours de la connexion, il peut utiliser un chemin différent ou un environnement chroot-like (rare), ou le socket est recréé sur reboot ailleurs.

Blague #1 : Quand les graphiques disparaissent, ce n’est pas « juste l’UI ». C’est le système qui vous dit poliment qu’il a perdu patience.

Pièges en cluster et multi-nœuds

Sur un nœud autonome, les problèmes de pvestatd sont généralement locaux : disque, permissions, socket, corruption. Dans un cluster, vous ajoutez deux classes de douleur :

• Symptômes éclatés : un nœud sans graphiques, un autre OK, un troisième qui met à jour de façon intermittente.
• Dépendances croisées : des définitions de stockage cassées ou une dérive horaire sur un nœud peuvent créer un comportement UI confus en naviguant entre les nœuds.

Règle de cluster : confirmez si le problème est par nœud

Exécutez les vérifications de service sur chaque nœud. Ne supposez pas que parce que l’UI est vide partout, c’est « l’UI ». Cela peut être le cache du navigateur, ou tous les nœuds peuvent partager la même cause racine (par exemple, un changement de durcissement appliqué partout).

cr0x@server:~$ for n in pve1 pve2 pve3; do echo "== $n =="; ssh $n systemctl is-active pvestatd; done
== pve1 ==
active
== pve2 ==
failed
== pve3 ==
active

Signification : C’est spécifique à un nœud. Arrêtez de chercher une solution magique cluster-wide. Comparez l’usage disque de pve2, la config rrdcached et les définitions de stockage avec les autres nœuds.

La dérive temporelle en cluster, c’est particulièrement stupide

RRD n’aime pas que l’heure recule. Les services cluster non plus. Si un nœud dérive, ses graphiques auront des trous, et vous diagnostiquerez « stats cassées » alors que c’est « temps cassé ».

cr0x@server:~$ chronyc tracking
Reference ID    : 0A0B0C0D (ntp1)
Stratum         : 3
Last offset     : +0.000842 seconds
RMS offset      : 0.001210 seconds
System time     : 0.000311 seconds fast of NTP time
Leap status     : Normal

Signification : Le temps est stable. Si vous voyez de grands offsets ou « Not synchronised », réglez cela en priorité.

Les définitions de stockage cassées affectent la collecte des statistiques

La collecte de statistiques de Proxmox touche souvent les backends de stockage. Un serveur NFS mort, un chemin iSCSI bloqué ou une commande Ceph qui se fige peut faire bloquer ou échouer pvestatd.

La meilleure démarche : obtenez un pvesm status propre. Si un stockage est mort et non requis, supprimez-le. S’il est requis, réparez le montage/le réseau. « Inactive forever » n’est pas un état sans conséquence ; c’est une invitation aux timeouts.

Pression de stockage, permissions et « pourquoi les graphiques meurent en premier »

Pourquoi les graphiques disparaissent-ils tôt lors de la dégradation d’un hôte ? Parce qu’ils sont écriture-lourds et non essentiels pour maintenir les VM en fonctionnement. Le noyau gardera volontiers vos workloads vivants pendant que des services en arrière-plan cessent discrètement de mettre à jour l’historique.

Incidents disque-plein : la réaction en chaîne

Quand la partition root se remplit :

• rrdcached ne peut pas vider ses journaux ni mettre à jour les fichiers RRD.
• pvestatd échoue à écrire et sort ou retente agressivement.
• La journalisation peut s’amplifier, ce qui consomme encore plus d’espace.
• Finalement, d’autres composants échouent (mises à jour de paquets, caches d’authentification, messagerie de cluster).

Si vous ne retenez qu’une chose : résolvez l’espace/inodes avant toute autre chose. Tout autre correctif dépend de la capacité à écrire quelques kilo-octets.

Permissions : la sabotage silencieux

Les problèmes de permissions apparaissent souvent après :

• Un « nettoyage » manuel par quelqu’un qui a exécuté chown sur /var/lib ou restauré depuis une sauvegarde avec une mauvaise propriété.
• Des scripts de durcissement qui restreignent /run ou changent les umasks par défaut.
• Déplacement de répertoires vers d’autres systèmes de fichiers et perte d’ACL ou d’attributs étendus.

Approche de débogage : traitez /var/lib/rrdcached comme un répertoire de données applicatives : il a besoin d’une propriété stable, de permissions stables et d’un espace libre stable. Si vous le laissez sur la racine avec tout le reste, vous pariez l’historique de votre monitoring sur la perfection de votre rotation de logs. C’est un pari osé.

Intégrité du système de fichiers : si vous avez vu de la corruption, n’ignorez pas le disque

La corruption RRD est souvent un symptôme, pas la maladie. Si vous avez eu un événement d’alimentation, un hoquet de disque ou un crash d’hôte VM et que maintenant les RRD sont corrompus, consultez au moins les logs du noyau pour des erreurs I/O et vérifiez l’état SMART. Sinon vous « réparerez » les graphiques et perdrez ensuite le nœud.

cr0x@server:~$ dmesg -T | egrep -i 'ext4|xfs|btrfs|I/O error|nvme|ata' | tail -n 15
[Mon Dec 23 08:41:12 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Mon Dec 23 08:41:12 2025] Buffer I/O error on device sda2, logical block 1234567

Signification : Votre système de fichiers a eu une mauvaise journée. Attendez-vous à de la corruption RRD. Ne vous contentez pas de supprimer les fichiers RRD et de passer à autre chose ; planifiez une fenêtre de maintenance pour réparer le FS et valider le matériel.

Citation adaptée d’un grand nom de la fiabilité : « L’espoir n’est pas une stratégie ; construisez des systèmes qui partent du principe que la panne est possible. »

Trois mini-récits corporate depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « C’est juste l’UI web »

Contexte : une entreprise de taille moyenne avec un cluster Proxmox alimentant des services internes — runners CI, quelques bases de données et beaucoup de VM « temporaires » devenues permanentes. Un matin, les graphiques ont disparu sur le nœud le plus chargé. L’ingénieur d’astreinte a supposé que c’était un problème de navigateur ou une régression de l’UI après des mises à jour. Il a redémarré pveproxy et pvedaemon parce que ce sont les services connus de tout le monde.

Les graphiques sont restés vides. Ils ont alors ouvert un ticket fournisseur et prévu un reboot progressif des nœuds pour « nettoyer l’état ». Pendant ce temps, le vrai problème était une partition root à 100% parce qu’un job de sauvegarde d’une VM enregistrait des échecs d’authentification toutes les secondes, et la rotation des logs n’absorbait pas.

Quand le premier nœud a redémarré, il est revenu plus lent que d’habitude. Les services ayant besoin d’écrire au démarrage ont coincé. Quelques VM n’ont pas démarré automatiquement. Soudain la portée s’est étendue : ce n’était plus les graphiques, c’était la disponibilité.

Quand quelqu’un a finalement lancé df -h, la solution était évidente : stopper le spam de logs, tronquer les logs soigneusement, récupérer de l’espace, redémarrer rrdcached et pvestatd. Les graphiques sont revenus. Le reboot a été la seule action vraiment dangereuse, et elle a été faite parce que quelqu’un avait supposé que « les graphiques sont une affaire d’UI ».

Leçon : mauvaise hypothèse — les graphiques sont un symptôme de la santé du chemin d’écriture. Quand ils disparaissent, pensez d’abord « est-ce que ce nœud peut encore écrire des données de façon fiable ? » et non « est-ce mon cache navigateur ? »

2) L’optimisation qui s’est retournée contre eux : « Déplaçons rrdcached vers un stockage plus rapide »

Une autre organisation, même état d’esprit : équipe orientée performance, plein de SSD, envie de garder la racine propre. Quelqu’un a déplacé /var/lib/rrdcached vers un dataset ZFS « rapide » avec compression agressive et montage un peu exotique. Ça a marché en test. En production aussi, au début.

Puis le retour de bâton. Le dataset a été inclus dans une routine de snapshot/réplication fréquente. Les fichiers RRD sont petits mais nombreux et très mis à jour. Le surcoût des snapshots n’était pas cataclysmique, mais il a introduit des pics de latence pendant les fenêtres de flush qui ont fait prendre du retard à rrdcached. Des timeouts sont apparus. Les graphiques devenaient stale de façon intermittente — exactement le genre de problème qui fait perdre confiance dans le monitoring.

La « solution » suivante a été d’augmenter les intervalles d’écriture de rrdcached pour réduire la fréquence de flush. Cela a réduit l’I/O, oui. Mais aussi augmenté les données perdues en cas d’arrêt non propre et amplifié l’effet « les graphiques sont en retard ». Les gens ont fini par ne plus consulter les graphiques parce qu’ils n’étaient pas à jour. Le monitoring est devenu décoratif.

La correction a été ennuyeuse : garder /var/lib/rrdcached sur un filesystem local stable à latence prévisible, l’exclure des politiques de snapshot agressives, et admettre que les données RRD ne méritent pas la même réplication que les disques VM.

Leçon : le backend de monitoring doit être stable et terne. Une faible latence aide, mais la prévisibilité vaut mieux que l’ingéniosité.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Séparer /var et appliquer des seuils »

Une troisième équipe avait déjà subi des pannes disque-plein. Ils ont fait deux choses peu glamour : mettre /var sur un filesystem dédié avec de la marge, et imposer des seuils d’alerte à 70% et 85% avec procédure d’escalade. Pas sexy. Pas pour une conférence. Ça marche.

Un jour, un changement réseau a causé des échecs d’auth répétés pour un montage de stockage, générant un flux de logs. L’usage disque a grimpé. L’alerte 70% a sonné et a été traitée. L’astreinte n’a pas « réparer plus tard ». Ils ont enquêté immédiatement parce que le runbook l’imposait et parce qu’ils savaient ce qui arrive après 90%.

La cause racine a été réglée (identifiants et comportement de retry), et les logs ont été archivés. pvestatd n’a jamais échoué. Les graphiques n’ont jamais disparu. Personne n’a eu à deviner ce qui s’est passé ensuite, parce que l’historique est resté intact et ennuyeux.

Leçon : sauver par l’ennui — séparer les zones d’écriture critiques, alerter tôt et traiter la saturation disque comme un incident de fiabilité, pas une corvée de ménage.

Blague #2 : L’espace disque, c’est comme la politique de bureau — on l’ignore jusqu’à ce qu’elle convoque votre PDG.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: GUI shows no graphs; pvestatd “failed”

Cause racine : mismatch de chemin de socket rrdcached ou socket manquant.

Correctif : Confirmer le socket réel avec ss -xlpn, aligner la config dans /etc/default/rrdcached, redémarrer rrdcached puis pvestatd.

2) Symptom: pvestatd logs “Permission denied” writing RRD

Cause racine : mauvaise propriété/mode sur /var/lib/rrdcached ou le répertoire journal ; parfois dû à des restaurations ou modifications manuelles.

Correctif : Confirmez l’utilisateur rrdcached avec ps, appliquez un chown -R correct sur /var/lib/rrdcached, redémarrez les services.

3) Symptom: Graphs stopped after “everything was fine,” but services show “active”

Cause racine : disque plein ou inodes épuisés provoquant des échecs silencieux d’écriture ; ou rrdcached à la traîne avec un journal qui grossit.

Correctif : Vérifiez df -h et df -i. Libérez espace/inodes. Puis vérifiez que les timestamps RRD avancent.

4) Symptom: Errors like “invalid header (bad magic)”

Cause racine : fichiers RRD corrompus, souvent après disque plein ou erreurs de FS.

Correctif : Mettre en quarantaine les RRD corrompus ou réinitialiser l’arbre RRD ; investiguer la santé du disque/FS sous-jacent.

5) Symptom: pvestatd intermittently fails; logs mention storage timeouts

Cause racine : un backend de stockage fautif (NFS bloqué, problèmes iSCSI, Ceph lent) bloque la collecte.

Correctif : pvesm status pour identifier les storages inactifs. Réparez le réseau/montez, ou retirez la config de stockage morte.

6) Symptom: Graphs show gaps or odd “flatlines” across nodes

Cause racine : dérive temporelle ou NTP non synchronisé ; parfois après suspend/reprise d’hôte ou RTC défectueux.

Correctif : Utilisez timedatectl et chronyc tracking. Réparez la sync temporelle ; évitez les sauts manuels importants.

7) Symptom: Restarting pvestatd “fixes” it briefly, then it fails again

Cause racine : boucle de redémarrages masquant un problème persistant en amont (disque, permissions, timeouts de stockage). Les redémarrages sont un antidouleur, pas une chirurgie.

Correctif : Lisez le journal pour l’erreur initiale et résolvez la dépendance. Stoppez le flapping ; stabilisez.

Listes de contrôle / plan étape par étape

Checklist A: Get graphs back within 15 minutes (safe path)

1. Vérifiez systemctl status pvestatd et journalctl -u pvestatd -b pour l’erreur initiale.
2. Vérifiez systemctl status rrdcached et confirmez le socket avec ss -xlpn | grep rrdcached.
3. Vérifiez espace libre et inodes : df -h /, df -i /.
4. Si disque/inodes sont pleins, libérez d’abord de l’espace. Arrêtez la source de spam, puis faites la rotation/tronquez les logs.
5. Confirmez que la propriété de /var/lib/rrdcached correspond à l’utilisateur d’exécution de rrdcached.
6. Redémarrez dans l’ordre : systemctl restart rrdcached puis systemctl restart pvestatd.
7. Confirmez les mises à jour RRD : vérifiez les timestamps des fichiers dans /var/lib/rrdcached/db.
8. Si de la corruption apparaît, mettez en quarantaine les fichiers corrompus. Si beaucoup sont corrompus, réinitialisez l’arbre RRD après avoir assuré la santé du stockage.

Checklist B: Stabilize and prevent recurrence (the grown-up path)

1. Assurez-vous que la synchronisation temporelle est stable : activez et vérifiez chrony/systemd-timesyncd ; corrigez la dérive RTC si chronique.
2. Assurez-vous que /var dispose d’une marge suffisante ; envisagez un filesystem/dataset séparé avec seuils de monitoring.
3. Auditez la rotation des logs. Confirmez qu’on ne peut pas générer des logs de plusieurs Go en quelques heures sans alertes.
4. Revue des définitions de stockage ; retirez les stockages morts de la config. « Inactive » devrait être exceptionnel.
5. Si vous avez vu des erreurs FS, planifiez une maintenance : fsck si nécessaire, tests SMART, remplacement des médias douteux.
6. Documentez le chemin du socket rrdcached et les permissions. Évitez les « symlinks mystères » incompris de tous.

Checklist C: When you must reset RRD data (without making it worse)

1. Corrigez l’espace disque et vérifiez l’intégrité du système de fichiers en premier lieu.
2. Arrêtez pvestatd et rrdcached.
3. Déplacez /var/lib/rrdcached/db à part (ne supprimez pas immédiatement).
4. Créez un nouveau répertoire db avec la propriété correcte.
5. Démarrez rrdcached puis pvestatd.
6. Vérifiez que de nouveaux fichiers RRD apparaissent et que les timestamps avancent.

FAQ

1) Do I need to reboot the Proxmox node to fix pvestatd?

Non. Si un reboot « règle » le problème, vous aviez probablement un problème de montage transitoire ou d’état de service. Diagnostiquez la cause sous-jacente (espace, socket, permissions, timeouts de stockage) pour éviter un retour.

2) Why are my VMs fine but graphs are missing?

Parce que la chaîne de monitoring n’est pas requise pour que la virtualisation fonctionne. C’est un canari pour la santé du chemin d’écriture et des dépendances de service. Traitez-le comme un avertissement précoce, pas une fuite cosmétique.

3) I restarted pveproxy and still no graphs. Why?

Parce que pveproxy rend l’UI mais ne génère pas les séries temporelles. Si pvestatd ne peut pas mettre à jour les RRD, l’UI n’a rien de neuf à afficher.

4) Can a broken NFS storage really break node graphs?

Oui. Si la collecte de stats essaie d’interroger l’état d’un stockage et que cette requête bloque ou timeoute, la boucle peut échouer ou ralentir. Réparez le montage, le réseau ou retirez la définition de stockage morte.

5) Is it safe to delete RRD files?

C’est sûr dans le sens où vous ne casserez pas les VM. Vous perdrez l’historique des graphiques pour les séries supprimées. Si les fichiers sont corrompus, la suppression/quarantaine est souvent la voie la plus rapide pour retrouver un monitoring fonctionnel.

6) Why does time sync matter for graphs?

RRD bucketise les données par temps. Les grands sauts créent des trous ou des artefacts de consolidation. Dans un cluster, la dérive temporelle cause aussi des comportements étranges. Gardez NTP sain.

7) My filesystem isn’t full. What else commonly causes “Permission denied”?

Mauvaise propriété après restaurations, déplacement de répertoires, ou scripts de durcissement changeant umasks ou répertoires runtime. Confirmez l’utilisateur du service et la propriété des répertoires. Ne corrigez pas avec des permissions world-writable.

8) How do I confirm graphs are updating without using the GUI?

Vérifiez les dates de modification des fichiers *.rrd sous /var/lib/rrdcached/db. Si les timestamps avancent toutes les quelques minutes, les mises à jour circulent. Vous pouvez aussi constater que les logs de pvestatd deviennent calmes (dans le bon sens).

9) Why does rrdcached sometimes run but the socket is missing?

Si le répertoire du socket n’existe pas au démarrage, ou si des permissions empêchent la création du socket, rrdcached peut ne pas exposer le point de terminaison attendu. Confirmez le chemin du socket dans la config et vérifiez que le répertoire existe et est inscriptible.

10) Should I move RRD data to shared storage?

Généralement non. RRD est petit et écriture-intensif ; le stockage partagé ajoute de la latence et des modes de panne. Gardez-le local et terne. Si vous devez centraliser les métriques, utilisez une véritable pile de monitoring plutôt que d’essayer de « clusteriser » des fichiers RRD.

Étapes suivantes pour éviter que ça revienne

Restaurer les graphiques est la partie facile. Les garder fiables est le vrai travail.

• Rendre la pression disque visible tôt : alerter sur l’usage d’espace et d’inodes bien avant 95%.
• Garder rrdcached prévisible : chemin de socket stable, propriété correcte, évitez les déplacements malheureux qui ajoutent de la latence.
• Nettoyer les définitions de stockage mortes : ne laissez pas des montages cassés traîner en « inactive » pendant des mois.
• Corriger la synchronisation temporelle définitivement : NTP stable, RTC raisonnable, pas de sauts manuels en production.
• Si vous avez vu de la corruption, investiguez le hardware : ne traitez pas les erreurs RRD comme un simple désagrément logiciel.

Si vous faites tout cela, pvestatd redeviendra ce qu’il devrait être : un bruit de fond dont vous ne pensez jamais. C’est le meilleur type de monitoring.