Surveillance et alertes Proxmox : guide pratique d'implémentation avec exemples

Introduction

Proxmox alimente des machines virtuelles, du stockage et des réseaux critiques. En cas de défaillance, les clients le ressentent immédiatement. Ce guide montre exactement quoi surveiller, comment construire des tableaux de bord utiles, quelles règles d'alerte adopter au départ, et comment réagir quand quelque chose tourne mal. Il s'adresse aux développeurs, consultants DevOps et équipes de startups qui ont besoin d'opérations fiables sans une grande équipe plateforme.

L'approche est concrète : métriques précises, règles d'alerte copiables-collables, et runbooks courts que vous pouvez tester localement.

Aperçu du flux de travail

Un flux de surveillance clair réduit le bruit et augmente l'action :

1. Définir les objectifs et les priorités

• Identifiez vos principaux risques : perte de données, indisponibilité, voisins bruyants, sauvegardes échouées.
• Fixez des cibles simples : ex. pas plus de 0,1 % de perte de paquets, sauvegardes réussies chaque jour, Ceph en bonne santé.

1. Instrumenter et collecter

• Métriques : activez les métriques standards du nœud Linux et exportez les états des services Proxmox. Si vous utilisez Ceph, exportez un 1 ou 0 pour la santé.
• Logs : transférez journald/syslog. Analysez les lignes vzdump et Ceph health.

1. Conception des alertes

• Commencez avec un petit ensemble d'alertes à fort signal. Liez chacune à un runbook et un responsable.
• Utilisez des seuils multi-fenêtres et des durées for: pour éviter le flapping.

1. Tableaux de bord

• Construisez des vues de triage rapides pour la santé du nœud, du stockage, des VM et du cluster.

1. Forer et itérer

• Simulez la pression CPU, le remplissage disque, et les sauvegardes échouées en labo. Ajustez jusqu'à ce que les alertes soient opportunes et actionnables.

Un plan par étapes réduit la reprise et accélère l'adoption.

Quoi surveiller

Couvrez les couches que Proxmox coordonne. Priorisez les signaux prédictifs et actionnables.

• Santé du nœud (Linux)
• CPU : saturation et temps volé (signal de voisin bruyant)
• Mémoire : disponible, activité d'échange, défauts de page
• Charge moyenne vs nombre de CPU (soutenue > 1,0 par cœur dégrade souvent les VM)
• Temps de fonctionnement et raisons de redémarrage

• Stockage
• Remplissage des systèmes de fichiers et épuisement des inodes sur les images VM et volumes
• Latence E/S et profondeur de file d'attente, par périphérique (exclure loop, ram, périphériques temporaires)
• État des pools ZFS et resilvers, utilisation du pool de données LVM-thin
• Avertissements SMART et réallocations
• Ceph : santé, quorum MON, comptes OSD up/in, états PG, récupération, latence

• Réseau
• Erreurs et pertes sur les ponts et agrégats
• Perte de paquets et incompatibilité MTU sur les uplinks
• Accessibilité VRRP ou passerelle pour les chemins nord HA

• Services Proxmox et cluster
• États corosync et pve-ha, quorum du cluster
• Disponibilité pveproxy/pvedaemon
• Taux de succès et durées des migrations en direct

• Charges de travail (VM et conteneurs)
• Vol CPU VM, symptômes type CPU ready sous contention
• Débit disque et réseau par VM
• Statut de l'agent invité QEMU pour une meilleure visibilité

• Sauvegarde et restauration
• Taux de succès, durée et tendances de taille de vzdump
• Tests de restauration planifiés (test de fumée au moins hebdomadaire)

• Signaux de sécurité et de changement
• Échecs de connexion, anomalies sudo, redémarrages inattendus
• Mises à jour de paquets en attente sur les hyperviseurs

Métriques et requêtes utiles

Voici des métriques actionnables et des requêtes d'exemple qui fonctionnent bien sur des hôtes Proxmox exécutant des exportateurs Linux standards. Ajustez les filtres de labels pour votre environnement.

Saturation CPU par nœud

# Pourcentage CPU occupé sur 5 minutes
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

CPU steal (souscription excessive ou voisin bruyant)

avg by (instance) (rate(node_cpu_seconds_total{mode="steal"}[5m]) * 100)

Pression mémoire

(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.10

Activité d'échange

rate(node_vmstat_pswpin[5m]) + rate(node_vmstat_pswpout[5m])

Saturation système de fichiers (ext4/xfs/zfs)

(node_filesystem_avail_bytes{fstype=~"ext4|xfs|zfs",mountpoint!~
  /run|/var/lib/docker|/snap"}
 /
 node_filesystem_size_bytes{fstype=~"ext4|xfs|zfs",mountpoint!~
  /run|/var/lib/docker|/snap"}) < 0.15

Approximation de la latence disque (lecture et écriture moyennes)

# Latence moyenne de lecture en secondes par opération
(rate(node_disk_read_time_seconds_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m])
 /
 clamp_min(rate(node_disk_reads_completed_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m]), 1))

# Latence moyenne d'écriture en secondes par opération
(rate(node_disk_write_time_seconds_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m])
 /
 clamp_min(rate(node_disk_writes_completed_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m]), 1))

Erreurs réseau

(rate(node_network_receive_errs_total{device!~"^(lo|veth).*"}[5m]) > 0)
or
(rate(node_network_transmit_errs_total{device!~"^(lo|veth).*"}[5m]) > 0)

Santé du service systemd (exemple corosync)

node_systemd_unit_state{name="corosync.service",state="active"} != 1

Résultats de sauvegarde via collecteur textfile

Créez /usr/local/bin/vzdump_metrics.sh :

#!/bin/sh
ok=$(grep -c "Finished Backup" /var/log/vzdump/* 2>/dev/null || true)
err=$(grep -c "ERROR" /var/log/vzdump/* 2>/dev/null || true)
echo "pve_vzdump_jobs_ok $ok"
echo "pve_vzdump_jobs_error $err"

Exécutez via cron et déposez la sortie dans le répertoire textfile de node_exporter :

* * * * * root /usr/local/bin/vzdump_metrics.sh > /var/lib/node_exporter/textfile_collector/pve.prom

Requête utile :

increase(pve_vzdump_jobs_error[24h]) > 0

Santé Ceph comme métrique simple

Créez /usr/local/bin/ceph_health_metric.sh :

#!/bin/sh
h=$(ceph health | awk '{print $1}')
if [ "$h" = "HEALTH_OK" ]; then echo "ceph_health 1\); else echo "ceph_health 0\); fi

Règle de métrique :

ceph_health == 0

Logs et signaux

Centralisez journald/syslog de tous les nœuds Proxmox et analysez les motifs à haute valeur.

Sources de logs et motifs clés :

• Cluster et HA
• corosync : quorum perdu, timeouts de jeton
• pve-ha-crm : isolé, basculement de service, récupération terminée
• Stockage
• kernel : erreur E/S, erreur EXT4-fs, pool ZFS dégradé, resilver rpool
• smartd : pré-faillite, secteur réalloué
• Ceph : mon down, osd out, dégradé, requêtes lentes
• Cycle de vie VM
• qm : migration échouée, erreur de tâche
• Sauvegardes
• vzdump : ERROR, code de sortie, échecs tar ou zstd
• Sécurité
• sshd : mot de passe échoué, utilisateur invalide

Filtres ad-hoc utiles pendant le triage :

journalctl -u corosync --since "-1h"
journalctl -t pve-ha-crm --since "-1h" | egrep -i 'fail|fence|quorum'
journalctl -k --since "-1h" | egrep -i 'error|i/o|ext4|zfs|nvme|sda'
grep -i 'ERROR' /var/log/vzdump/* | tail -n 50

Tableaux de bord

Concevez des tableaux de bord qui répondent aux trois premières questions de l'ingénieur d'astreinte : quoi a cassé, où, et quelle est la gravité.

• Vue d'ensemble du nœud (une ligne par nœud)
• CPU occupé et volé, mémoire disponible, activité d'échange
• Utilisation des systèmes de fichiers pour images VM et cibles de sauvegarde
• Périphériques avec latence disque élevée, erreurs réseau par interface
• État corosync.service et signaux pve-ha

• Santé du cluster
• État du quorum, disponibilité des nœuds
• Nombre et durée médiane des migrations en direct
• Succès vs échecs des sauvegardes dans le temps

• Détail du stockage
• Capacité des pools ZFS et activité de resilver, disques lents
• Ceph : indicateur de santé, OSD up/in, états PG, latence lecture/écriture

• Vue VM et locataire
• Par VM : CPU, mémoire, E/S, réseau
• Liste des voisins bruyants pour repérer la contention

Conseils de conception :

• Placez les métriques rouges en haut à gauche. Mettez les dérivées et taux à côté des valeurs brutes.
• Ajoutez des liens depuis les panneaux vers les runbooks et les consoles d'hôte.
• Utilisez des couleurs et unités cohérentes entre tableaux de bord.

Règles d'alerte

Commencez avec un ensemble compact et actionnable. Exemples de règles style Prometheus ci-dessous.

- alert: NodeHighCPU
  expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: CPU élevé sur {{ $labels.instance }}
    description: CPU > 85% pendant 10min. Vérifiez les top VMs et processus.

- alert: NodeHighCPU_Steal
  expr: avg by (instance) (rate(node_cpu_seconds_total{mode="steal"}[5m]) * 100) > 5
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: CPU steal sur {{ $labels.instance }}
    description: Contention CPU hôte. Investiguez les VMs bruyantes et l'ordonnancement.

- alert: NodeLowMemory
  expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.10
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: Mémoire faible sur {{ $labels.instance }}
    description: Moins de 10% de mémoire disponible.

- alert: FilesystemNearlyFull
  expr: (node_filesystem_avail_bytes{fstype=~"ext4|xfs|zfs",mountpoint!~
    /run|/var/lib/docker|/snap"}
    / node_filesystem_size_bytes{fstype=~"ext4|xfs|zfs",mountpoint!~
    /run|/var/lib/docker|/snap"}) < 0.15
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: Espace disque faible sur {{ $labels.instance }} {{ $labels.mountpoint }}
    description: Moins de 15% libre. Nettoyez ou augmentez la capacité.

- alert: DiskLatencyHigh
  expr: (rate(node_disk_read_time_seconds_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m])
    / clamp_min(rate(node_disk_reads_completed_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m]),1)) > 0.02
    or
    (rate(node_disk_write_time_seconds_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m])
    / clamp_min(rate(node_disk_writes_completed_total{device!~"^(ram|loop|fd|sr|dm).*"}[5m]),1)) > 0.02
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: Latence disque élevée sur {{ $labels.instance }} {{ $labels.device }}
    description: Latence moyenne > 20ms pendant 5min. Vérifiez la santé du périphérique et la charge.

- alert: NetworkErrors
  expr: rate(node_network_receive_errs_total{device!~"^(lo|veth).*"}[5m]) > 0
    or rate(node_network_transmit_errs_total{device!~"^(lo|veth).*"}[5m]) > 0
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: Erreurs réseau sur {{ $labels.instance }} {{ $labels.device }}
    description: L'interface signale des erreurs. Vérifiez câblage, drivers et MTU.

- alert: CorosyncDown
  expr: node_systemd_unit_state{name="corosync.service",state="active"} != 1
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: Corosync inactif sur {{ $labels.instance }}
    description: Communication cluster en panne. Risque de perte de quorum.

- alert: BackupFailures
  expr: increase(pve_vzdump_jobs_error[24h]) > 0
  for: 0m
  labels:
    severity: critical
  annotations:
    summary: Échecs de sauvegarde sur {{ $labels.instance }}
    description: Une ou plusieurs sauvegardes ont échoué dans les dernières 24h. Investiguez les logs.

- alert: CephUnhealthy
  expr: ceph_health == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: Santé Ceph non OK
    description: Vérifiez le quorum MON, les états OSD et les PG.

Suggestion de映射 de gravité :

• page : CorosyncDown, FilesystemNearlyFull sur stockage VM, CephUnhealthy
• ticket : NodeHighCPU, NodeLowMemory, DiskLatencyHigh, NetworkErrors
• notification : BackupFailures (si quotidien) passe en page si 2 jours consécutifs

Réponse aux incidents

Gardez les runbooks courts et liés aux noms d'alertes.

FilesystemNearlyFull

1. Identifiez les gros consommateurs : du -xhd1 /var/lib/vz; zfs list -o name,used,avail
2. Supprimez d'anciennes sauvegardes ou déplacez-les vers un stockage externe
3. Si LVM-thin est plein, ajoutez de l'espace ou migrez les VMs
4. Pour ZFS, envisagez zfs set compression=lz4 sur les jeux de données volumineux

CorosyncDown

1. Vérifiez les liaisons réseau sur le nœud (bond/bridge) et l'état du switch
2. Validez la synchronisation horaire et l'accessibilité multicast ou UDP
3. Consultez journalctl -u corosync ; redémarrez seulement si sûr et que les pairs sont sains
4. Si plusieurs nœuds impactés, priorisez la restauration du quorum

CephUnhealthy

1. ceph -s pour identifier les états PG et les OSD manquants
2. Remettez les OSD en service ; vérifiez disques et alimentation
3. Repoussez les rééquilibrages non essentiels aux heures de pointe

NodeHighCPU et steal

1. Identifiez les VMs bavardes : qm list, métriques par VM
2. Migrez ou bridez les contrevenants ; ajustez les parts CPU
3. Revoyez les ratios de consolidation

BackupFailures

1. Inspectez /var/log/vzdump et la capacité du stockage cible
2. Réessayez une sauvegarde d'une petite VM pour isoler réseau vs stockage
3. Validez les identifiants et les politiques de rétention

Flux général pour toute alerte :

• Confirmez la portée, stabilisez la plateforme, restaurez l'impact client, puis réparez la cause racine.
• Annotez les tableaux de bord avec les actions correctives et les suivis.

Plan pilote local

Un petit pilote vérifiable attrape la plupart des problèmes tôt et maintient le risque faible.

Périmètre

• 1 nœud Proxmox, 1 VM chargée, 1 pool de stockage (ZFS ou LVM), et sauvegardes existantes

Métriques et logs

• Activez les métriques du nœud Linux
• Ajoutez les scripts textfile vzdump et ceph si applicable
• Transférez journald/syslog

Alertes à activer jour 1

• NodeHighCPU, NodeLowMemory, FilesystemNearlyFull, NetworkErrors, BackupFailures

Tableau de bord

• Vue nœud sur une page avec CPU, mémoire, système de fichiers, latence E/S, erreurs réseau, et états des services

Chronologie de vérification (1 jour)

• CPU : stress-ng --cpu 4 --timeout 600s pour pousser CPU > 85% pendant 10min
• Mémoire : mount -t tmpfs -o size=8G tmpfs /mnt/test pour franchir le seuil des 10% disponibles
• Système de fichiers : fallocate -l 50G /var/lib/vz/testfile jusqu'à 85% d'usage, puis rm /var/lib/vz/testfile
• Réseau : tc qdisc add dev eth0 root netem loss 10% (retirer avec tc qdisc del dev eth0 root)
• Sauvegarde : vzdump 100 --mode snapshot --storage local ; confirmez que métriques et logs se mettent à jour

Critères de sortie

• Les 5 alertes se déclenchent sous test, notifient le bon canal, et se résolvent quand les conditions s'effacent
• Le tableau de bord montre des pics corrélés avec unités lisibles et légendes
• Les runbooks sont mis à jour avec ce qui a fonctionné

Ce pilote étroit et mesurable est facile à inspecter localement avant de le déployer sur le cluster.

Conclusion

Vous disposez maintenant d'un plan pratique pour surveiller Proxmox : quoi observer, règles d'alerte prêtes à l'emploi, motifs de logs qui comptent, et tableaux de bord qui accélèrent le triage. Commencez par le pilote local, validez de bout en bout, puis étendez la couverture à Ceph, plus de nœuds, et plus de VMs. Gardez peu d'alertes et actionnables, liez-les à des runbooks courts, et itérez d'après les vrais incidents.