Comment superviser un serveur Proxmox VE
Superviser un hôte Proxmox VE : métriques Debian sous-jacentes, stockage ZFS et LVM-thin, état du cluster et quorum, supervision des machines virtuelles et conteneurs LXC.
Protégez votre infrastructure dès aujourd'hui
Démarrez gratuitement, sans carte bancaire requise
Proxmox VE est un hyperviseur bâti sur Debian. C'est le point de départ le plus utile pour sa supervision : l'essentiel de ce qu'il faut mesurer sur un hôte Proxmox se mesure exactement comme sur n'importe quel serveur Debian, avec un agent standard.
Restent quelques spécificités — le stockage, le cluster — qui méritent un traitement particulier.
L'hôte et les invités : deux périmètres distincts
Comme sur tout hyperviseur, superviser l'hôte Proxmox ne supervise pas les machines virtuelles ni les conteneurs qu'il héberge.
Depuis l'hôte, vous savez qu'une VM est démarrée et ce qu'elle consomme. Vous ne savez pas si son disque système est plein ni si son service applicatif répond. La règle reste la même : un agent sur l'hôte, un agent dans chaque invité dont le service compte.
Les conteneurs LXC font exception partielle : partageant le noyau de l'hôte, ils peuvent être supervisés depuis l'hôte pour certaines métriques, mais un agent installé dans le conteneur reste plus fiable pour l'état applicatif.
Ce qui se supervise comme un Debian standard
L'agent Zabbix installé sur l'hôte remonte nativement :
- l'espace disque et les inodes de chaque système de fichiers
- la mémoire disponible et l'usage du swap
- la charge processeur, avec sa décomposition
- l'état des services systemd
- le trafic par interface réseau
- le temps de fonctionnement, pour détecter les redémarrages inattendus
La procédure d'installation est celle de Debian — Proxmox VE 8 repose sur Debian 12, Proxmox VE 9 sur Debian 13.
Cela couvre déjà la majorité des incidents réels. Les points suivants complètent.
Le stockage : la vraie spécificité
C'est là que Proxmox demande une attention particulière, car ses modes de stockage se comportent différemment d'un système de fichiers classique.
ZFS et le piège du remplissage
Si vous utilisez ZFS, deux règles importent :
Les performances s'effondrent au-delà de 80 % d'occupation du pool. Ce n'est pas un seuil de sécurité arbitraire : c'est le comportement documenté du système de fichiers, dont l'allocation devient nettement moins efficace quand l'espace libre se raréfie. Un seuil d'alerte à 80 % sur un pool ZFS est donc justifié, là où 85 % suffirait ailleurs.
L'espace libre affiché par df est trompeur en présence d'instantanés et de clones. Un instantané conserve les blocs de données même après suppression des fichiers d'origine.
zpool list
zfs list -o space
zpool status # état de santé et éventuelle dégradationL'état du pool mérite une surveillance à part : un disque défaillant dans un miroir ZFS n'interrompt rien immédiatement, mais le second disque devient un point de défaillance unique. La détection précoce est ici ce qui distingue une intervention planifiée d'une perte de données.
LVM-thin et le surengagement
Avec un stockage LVM-thin, la somme des disques virtuels alloués peut dépasser la capacité réelle du volume. Tant que les invités ne remplissent pas leurs disques, tout fonctionne.
Le jour où le pool thin sature, les machines virtuelles passent en lecture seule ou s'arrêtent — plusieurs à la fois, sans que leurs disques respectifs soient pleins de leur point de vue.
lvs -o lv_name,data_percent,metadata_percentSurveillez data_percent et metadata_percent. La saturation des métadonnées est particulièrement vicieuse : elle bloque le pool alors que l'espace de données semble disponible.
Le volume racine
Sur une installation par défaut, / est souvent dimensionné modestement. Les journaux, les sauvegardes locales et les images ISO téléchargées le remplissent progressivement. Un /var/log saturé sur un hyperviseur empêche le diagnostic au moment où on en a le plus besoin.
Le cluster : le quorum avant tout
Sur une installation en cluster, une métrique domine toutes les autres : le quorum.
Un cluster Proxmox qui perd le quorum bascule en lecture seule. Les machines virtuelles continuent de tourner, mais plus aucune opération de gestion n'est possible — pas de démarrage, pas de migration, pas de modification. C'est une situation déroutante, car tout semble fonctionner jusqu'à la première action.
pvecm status
pvecm nodesSurveillez le nombre de nœuds vus par le cluster et l'état du quorum. Un cluster à deux nœuds sans dispositif d'arbitrage perd le quorum dès qu'un nœud tombe : c'est une configuration fragile, à connaître avant l'incident.
Le service corosync, qui porte la communication du cluster, mérite également une surveillance directe.
Les sauvegardes
Proxmox intègre un mécanisme de sauvegarde des machines virtuelles. Une sauvegarde qui échoue silencieusement plusieurs semaines est un scénario classique.
Trois points : le service de sauvegarde s'exécute, la dernière exécution est récente et réussie, et le stockage de destination a de l'espace disponible. Une sauvegarde qui échoue par manque d'espace sur la destination est la cause la plus banale, et la plus facile à anticiper.
Comment collecter les métriques spécifiques
L'agent Zabbix ne fournit pas de collecte native pour ZFS, LVM-thin ou l'état du cluster Proxmox. Ces métriques s'obtiennent par des éléments personnalisés appelant les commandes ci-dessus, ou via l'API Proxmox qui expose l'état des nœuds, du stockage et des invités.
Proxmox sait aussi pousser ses métriques vers un serveur externe (InfluxDB, Graphite) via ses « serveurs de métriques » intégrés. C'est une voie alternative pour la partie hyperviseur, complémentaire d'un agent pour la partie système.
Dans la pratique, la supervision Debian standard de l'hôte plus un agent dans chaque invité couvre déjà les incidents les plus fréquents — dont la saturation disque, qui reste la première cause de panne.
Avec Logiserv
L'hôte Proxmox est supervisé comme un serveur Debian : disque, inodes, mémoire, charge, services, réseau — avec découverte automatique des systèmes de fichiers. La détection d'un rôle d'hyperviseur via libvirtd rattache le système à un groupe dont les seuils réseau sont assouplis.
Les métriques ZFS, LVM-thin et cluster ne sont pas couvertes nativement : elles relèvent d'éléments personnalisés à définir selon votre installation.
- Base système
- Debian, supervisé nativement
- Découverte des volumes
- Automatique
- Métriques ZFS et cluster
- Non couvertes nativement
Proxmox VE 8 repose sur Debian 12, PVE 9 sur Debian 13.
Chaque système de fichiers monté est détecté et surveillé séparément.
État du pool, LVM-thin et quorum demandent des éléments personnalisés.
Pour aller plus loin
- Installer Zabbix Agent sur Debian — la procédure applicable à l'hôte Proxmox
- Pourquoi superviser un serveur Linux — les signaux qui précèdent la panne
- Surveiller l'espace disque d'un serveur — la métrique la plus critique sur un hyperviseur
- Quelles métriques surveiller sur un serveur — le plan général
- Supervision serveur Windows et Linux : le guide — la démarche complète
Protégez votre infrastructure dès aujourd'hui
Démarrez gratuitement, sans carte bancaire requise
Les autres services
Pourquoi superviser un serveur Linux ? Les pannes évitables
Ce que la supervision d'un serveur Linux détecte avant l'incident : saturation disque, fuite mémoire, processus zombie, échec de sauvegarde, certificat expiré. Avec les commandes de diagnostic.
Installer Zabbix Agent 2 sur Debian 11, 12 et 13 en 10 min
Installer Zabbix Agent 2 sur Debian Bullseye, Bookworm et Trixie : dépôt officiel, apt, configuration de zabbix_agent2.conf, chiffrement PSK, nftables et vérification systemd.
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é.