Supervision Proxmox et alertes avec exemples pratiques : guide d'implémentation

Introduction

Proxmox alimente des machines virtuelles critiques, du stockage et des réseaux. Quand la plate-forme vacille, les utilisateurs le ressentent immédiatement. Ce guide pratique explique exactement quoi surveiller, comment bâtir des tableaux de bord utiles, quelles règles d'alerte activer en premier et comment réagir quand quelque chose se dégrade. Il s'adresse aux développeurs, consultants DevOps et équipes de startups qui recherchent une exploitation fiable sans équipe plate-forme pléthorique. L'approche est pragmatique: métriques concrètes, règles d'alerte copiables-collables et runbooks courts testables en local. Pour garder la découvrabilité, nous utilisons parfois des termes courants comme Proxmox monitoring, Proxmox alerts, Proxmox metrics, Proxmox dashboard et Proxmox incident response.

Vue d'ensemble du workflow

Un workflow de supervision clair maintient le bruit au minimum et l'action au maximum:

Définir objectifs et priorités

Énoncer vos risques majeurs: perte de données, indisponibilité, noisy neighbors, sauvegardes en échec.
Fixer des cibles simples: par exemple, perte de paquets ≤ 0,1 %, sauvegardes quotidiennes réussies, Ceph en état sain.

Instrumenter et collecter

Métriques: activer les métriques Linux standard des nœuds et exposer les états des services Proxmox. Si vous utilisez Ceph, exportez un booléen 1/0 pour la santé.
Logs: centraliser journald/syslog. Parser les lignes vzdump et les états de santé Ceph.

Conception des alertes

Démarrer avec un petit ensemble d'alertes à fort signal. Associer chaque alerte à un runbook et un owner.
Utiliser des seuils multi-fenêtres et des durées for: pour éviter le flap.

Tableaux de bord

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

Exercer et itérer

Simuler pression CPU, remplissage disque et sauvegardes en échec en labo. Accorder les seuils jusqu'à obtenir des alertes opportunes et actionnables.

Quoi surveiller

Couvrir les couches coordonnées par Proxmox. Prioriser les signaux prédictifs et actionnables.

Santé des nœuds (Linux)
CPU: saturation et steal time (signal de noisy neighbor)
Mémoire: disponible, activité swap, fautes de pages
Load average vs nombre de cœurs (charge soutenue > cœurs dégrade souvent les VM)
Uptime et raisons de redémarrage

Stockage
Remplissage des systèmes de fichiers et épuisement des inodes sur les images et volumes de VM
Latence IO et profondeur de file, par périphérique (exclure loop, ram, temp)
État des pools ZFS et resilvers, utilisation LVM-thin
Alertes SMART et réallocations
Ceph: santé, quorum MON, OSD up/in, états PG, récupération, latence

Réseau
Erreurs et drops sur ponts et bonds
Perte de paquets et incohérences MTU sur les uplinks
Atteignabilité VRRP ou passerelle pour les chemins HA nord

Services Proxmox et cluster
États corosync et pve-ha, quorum cluster
Disponibilité pveproxy/pvedaemon
Taux de succès et durée des migrations live

Workloads (VM et conteneurs)
Steal CPU côté VM, symptômes de CPU ready en contention
Débit disque et réseau par VM
État de l'agent QEMU guest pour une meilleure visibilité

Sauvegarde et restauration
Taux de succès vzdump, durée et tendance des tailles
Tests de restauration planifiés (smoke test au moins hebdo)

Sécurité et changements
Échecs de login, anomalies sudo, redémarrages inattendus
Paquets en attente de mise à jour sur les hyperviseurs

Métriques et requêtes utiles

Exemples de métriques et requêtes qui fonctionnent bien avec des hôtes Proxmox exposant des exporters Linux standards (Prometheus). Adaptez les labels à votre contexte.

Saturation CPU par nœud

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

CPU steal (surabonnement ou noisy neighbor)

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é swap

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

Saturation filesystem (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 (moyenne lecture/écriture)

# Latence moyenne de lecture (secondes/op)
(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 (secondes/op)
(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é systemd (exemple corosync)

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

Exporter des compteurs quotidiens depuis les logs vzdump:

Résultats de sauvegarde via textfile collector

# /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"

Cron pour publier vers 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 en métrique simple

# /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 simple:

ceph_health == 0

Logs et signaux

Centraliser journald/syslog de tous les nœuds Proxmox et parser les motifs à forte valeur.

Cluster et HA
corosync: perte de quorum, timeouts de jeton
pve-ha-crm: fence, bascule de service, fin de récupération
Stockage
kernel: erreur I/O, EXT4-fs error, ZFS pool degraded, resilver rpool
smartd: Pre-fail, secteurs réalloués
Ceph: mon down, osd out, degraded, slow requests
Cycle de vie des VM
qm: migration échouée, task error
Sauvegardes
vzdump: ERROR, code de sortie, erreurs tar ou zstd
Sécurité
sshd: Failed password, invalid user

Filtres ad hoc pour 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

Concevoir des dashboards qui répondent aux trois premières questions de l'astreinte: qu'est-ce qui a cassé, où, et à quel point.

Vue nœud (une ligne par nœud)
CPU busy et steal, mémoire disponible, activité swap
Utilisation des systèmes de fichiers pour images VM et cibles de sauvegarde
Périphériques à plus forte latence, erreurs réseau par interface
État corosync.service et signaux pve-ha

Santé cluster
État du quorum, disponibilité des nœuds
Compte des migrations live et durée médiane
Succès vs échecs de sauvegarde dans le temps

Détail stockage
Capacité et resilver ZFS, disques lents
Ceph: drapeau de santé, OSD up/in, états PG, latence R/W

Vue VM et tenant
CPU, mémoire, IO et réseau par VM
Liste des voisins bruyants pour détecter la contention

Conseils de design:

Placer les métriques en rouge en haut à gauche. Mettre dérivées et taux à côté des valeurs brutes.
Ajouter des liens vers les runbooks et les consoles d'hôtes.
Utiliser des couleurs et unités cohérentes entre dashboards.

Règles d'alerte

Commencer avec un ensemble compact et actionnable. Exemples au format Prometheus:

CPU nœud élevé

- alert: NodeHighCPU
  expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: High CPU on {{ $labels.instance }}
    description: CPU > 85% for 10m. Check top VMs and processes.

CPU steal (contention)

- 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 on {{ $labels.instance }}
    description: Host CPU contention. Investigate noisy VMs and scheduling.

Mémoire disponible basse

- alert: NodeLowMemory
  expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.10
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: Low memory on {{ $labels.instance }}
    description: Less than 10% memory available.

Filesystem presque plein (exclure éphémères)

- 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: Filesystem low free space on {{ $labels.instance }} {{ $labels.mountpoint }}
    description: Less than 15% free. Clean up or expand capacity.

Latence disque élevée

- 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: High disk latency on {{ $labels.instance }} {{ $labels.device }}
    description: Avg latency > 20ms for 5m. Check device health and workload.

Erreurs réseau présentes

- 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: Network errors on {{ $labels.instance }} {{ $labels.device }}
    description: Interface is reporting errors. Check cabling, drivers, and MTU.

Corosync inactif

- alert: CorosyncDown
  expr: node_systemd_unit_state{name="corosync.service",state="active"} != 1
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: Corosync inactive on {{ $labels.instance }}
    description: Cluster communication down. Risk of losing quorum.

Échecs de sauvegarde détectés

- alert: BackupFailures
  expr: increase(pve_vzdump_jobs_error[24h]) > 0
  for: 0m
  labels:
    severity: critical
  annotations:
    summary: Backup failures on {{ $labels.instance }}
    description: One or more backups failed in the last 24h. Investigate logs.

Santé Ceph non OK

- alert: CephUnhealthy
  expr: ceph_health == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: Ceph health is not OK
    description: Check MON quorum, OSD states, and PGs.

Mappage de sévérité (exemple):

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

Réponse aux incidents

Garder des runbooks courts et alignés sur les alertes.

FilesystemNearlyFull

Identifier les plus gros consommateurs: du -xhd1 /var/lib/vz; zfs list -o name, used, avail
Purger d'anciennes sauvegardes ou les déplacer vers un stockage externe
Si LVM-thin est plein, ajouter de l'espace ou migrer des VM
Pour ZFS, envisager zfs set compression=lz4 sur les datasets volumineux

CorosyncDown

Vérifier les liens réseau du nœud (bond/bridge) et l'état du switch
Valider la synchro temps et la portée multicast/UDP
Consulter journalctl -u corosync; redémarrer seulement si c'est sûr et que les pairs sont sains
Si plusieurs nœuds touchés, prioriser le rétablissement du quorum

CephUnhealthy

ceph -s pour identifier les états PG et OSD manquants
Ramener les OSD up/in; vérifier disques et alimentation
Différer les rebalances non essentiels en heures de pointe

NodeHighCPU et steal

Identifier les VM bavardes: qm list, métriques par VM
Migrer ou brider les fautifs; ajuster les shares CPU
Revoir les ratios de consolidation

BackupFailures

Inspecter /var/log/vzdump et la capacité du stockage cible
Retenter une petite VM pour isoler réseau vs stockage
Valider identifiants et politiques de rétention

Flux général pour toute alerte:

Confirmer le périmètre, stabiliser la plate-forme, restaurer l'impact client, puis réparer la cause racine. Annoter les dashboards avec la remédiation et les suivis.

Plan pilote local

Un petit pilote vérifiable capture l'essentiel tôt et limite le risque.

Périmètre
1 nœud Proxmox, 1 VM chargée, 1 pool (ZFS ou LVM) et sauvegardes existantes

Métriques et logs
Activer les métriques Linux
Ajouter les scripts textfile vzdump et ceph si applicables
Forward journald/syslog

Alertes jour 1
NodeHighCPU, NodeLowMemory, FilesystemNearlyFull, NetworkErrors, BackupFailures

Tableau de bord
Page unique: CPU, mémoire, filesystem, latence IO, erreurs réseau, états de services

Vérification (1 jour)
CPU: stress-ng ou compilation pour pousser > 85 % pendant 10 min
Mémoire: monter un gros tmpfs pour franchir le seuil 10 %
Filesystem: créer un gros fichier jusqu'à 85 % d'usage, puis supprimer
Réseau: flapper un lien de labo ou utiliser tc pour injecter des erreurs
Sauvegarde: lancer un vzdump manuel; confirmer que métriques et logs se mettent à jour

Critères de sortie
Les 5 alertes se déclenchent en test, notifient le bon canal et se résorbent quand la condition disparaît
Le dashboard montre des pics corrélés avec unités et légendes lisibles
Les runbooks sont mis à jour avec ce qui a fonctionné

Ce pilote étroit et mesurable est simple à inspecter localement avant déploiement sur le cluster.

Conclusion

Vous disposez maintenant d'un plan pratique pour le Proxmox monitoring: quoi observer, des règles d'alerte prêtes à l'emploi, des motifs de logs utiles et des tableaux de bord qui accélèrent le triage. Commencez par le pilote local, validez de bout en bout, puis élargissez à Ceph, à plus de nœuds et de VM. Gardez les Proxmox alerts peu nombreuses et actionnables, reliez-les à des runbooks courts, et itérez d'après les incidents réels afin d'améliorer durablement vos Proxmox metrics, votre Proxmox dashboard et votre Proxmox incident response.