La supervision de Proxmox avec Prometheus et Grafana est, dans de nombreuses organisations informatiques, la solution privilégiée pour rendre les hôtes, les machines virtuelles (VM) et l’état des clusters mesurables, historisés et capables de générer des alertes. Ce dossier s’adresse aux administrateurs, ingénieurs systèmes et opérateurs et explique de manière pragmatique quels exporteurs vous devez utiliser, comment dimensionner Prometheus, operationaliser les alertes et quelles stratégies de contrôle et de repli se sont avérées efficaces en environnements de production réels.
Supervision de Proxmox avec Prometheus et Grafana : brefs prérequis et vérification terminologique
Avant de commencer : Prometheus est une base de données de métriques orientée séries temporelles (TSDB) avec un mécanisme pull ; Grafana est le front-end de visualisation ; Alertmanager gère les notifications, le regroupement et les mises en sourdine. Les exporters sont de petits services qui exposent des métriques au format Prometheus – node_exporter fournit des métriques système, pve_exporter interroge l’API Proxmox. Des horloges synchronisées (NTP/Chrony), des règles de pare-feu et des tokens sécurisés sont obligatoires.
Décisions d’architecture et de dimensionnement
Commencez par une séparation claire entre hot-store (rétention courte, requêtes rapides) et long-term-store (données historiques). Pour de petits environnements, une seule instance Prometheus suffit ; face à une cardinalité croissante et de nombreuses VM, un modèle Edge/Central est recommandé : des instances Prometheus locales scrappent les nœuds, remote_write pousse les données vers une TSDB centrale et scalable telle que VictoriaMetrics, Thanos ou Cortex.
Pourquoi un Edge-Prometheus ?
Un Edge-Prometheus réduit la charge réseau, limite les appels API vers Proxmox et confine les pannes. La fédération ou remote_write n’agrège que ce qui est nécessaire au centre. Cela réduit le risque qu’une requête globale unique charge l’ensemble de votre infrastructure.
Les exporters en détail : exploiter correctement node_exporter et pve_exporter
node_exporter : consignes d’exploitation
node_exporter doit tourner en tant que service systemd, avec des collectors limités (désactiver les modules non nécessaires) et un textfile-collector pour des vérifications locales d’état (p. ex. résultats de sauvegarde). Les permissions des fichiers et le contexte utilisateur (un utilisateur dédié non privilégié) sont importants, car node_exporter lit des métriques depuis le système.
# Extrait d'unité systemd pour node_exporter
[Service]
User=nodeusr
Group=nodeusr
ExecStart=/usr/local/bin/node_exporter
--no-collector.wifi
--no-collector.mdadm
--collector.textfile.directory=/var/lib/node_exporter/textfile_collector
# Droits du répertoire
chown -R nodeusr:nodeusr /var/lib/node_exporter
chmod 750 /var/lib/node_exporterpve_exporter : authentification, cache et limites de débit de l’API
pve_exporter utilise l’API Proxmox-REST et dépend donc de la stabilité de l’API et des droits du token. Configurez une durée de cache (p. ex. 30–60 s) dans l’exporter pour éviter une charge API inutile ; les points d’extrémité de l’API Proxmox peuvent ralentir ou se bloquer temporairement en cas d’appels excessifs.
# Environnement systemd avec fichier de token sécurisé
[Service]
User=pveexport
EnvironmentFile=/etc/pve_exporter/env
ExecStart=/usr/local/bin/pve_exporter --listen-address=127.0.0.1:9273 --cache-duration=60s
# /etc/pve_exporter/env (à définir avec 600)
PROXMOX_API_TOKEN_ID=exporter@pve!id
PROXMOX_API_TOKEN_SECRET=longsecret
Important : créez des tokens avec les droits minimaux et stockez les secrets dans un vault, ou au minimum dans des fichiers aux permissions restrictives (chmod 600). Testez l’accès à l’API séparément avant de connecter Prometheus.
Contrôler la cardinalité : stratégie d’étiquetage et relabeling
La cardinalité désigne le nombre de séries temporelles uniques ; elle explose rapidement si vous reprenez des métadonnées dynamiques en tant que labels (p. ex. des notes libres de VM). Cela augmente l’espace de stockage, l’utilisation CPU et la latence des requêtes. Mesures :
- Définissez une liste de labels autorisés par job.
- Supprimez les labels volatils directement avec relabel_configs.
- Créez des labels service ou role via normalisation par regex plutôt qu’avec les noms complets des VM.
relabel_configs:
- source_labels: [vm_description]
regex: '.*'
action: drop
- source_labels: [vm_name]
regex: '^(web|db|cache)-.*'
target_label: service
replacement: '${1}'Exploitation de Prometheus : rétention, compaction et ressources
Prometheus stocke les données en blocs. Les configurations recommandées sont une rétention chaude de 15–30 jours et remote_write pour le stockage à long terme. Surveillez l’I/O de la TSDB : les latences disque entraînent des durées de scrape accrues et des erreurs.
# Prometheus Startflags (Beispiel)
prometheus --storage.tsdb.path=/var/lib/prometheus
--storage.tsdb.retention.time=30d
--storage.tsdb.no-lockfile
En cas de forte charge, effectuez une mise à l’échelle horizontale avec Thanos ou VictoriaMetrics ; vérifiez aussi la taille des blocs et les paramètres du WAL si vous observez des pics d’écriture fréquents.
Exemples PromQL utiles au quotidien
Requêtes pratiques pour diagnostics et dashboards :
# Aktive VMs pro Node
count by (instance) (pve_vm_info{state="running"})
# Storage-Usage pro Storage-Pool
sum by (storage) (pve_storage_used_bytes) / sum by (storage) (pve_storage_total_bytes)
# Disk-IO-Latenz pro VM (wenn Exporter Metrik liefert)
avg by (vm) (rate(pve_vm_disk_io_time_seconds_total[5m]))Alerting : modèles éprouvés et intégration d’Alertmanager
Utilisez Alertmanager comme point central pour le routage, le regroupement, l’inhibition et les silences. Les alertes doivent être orientées action : un résumé court, une cause précise (si possible) et un runbook lié.
Regroupement, inhibition et exemple
Le regroupement réduit le flux de notifications, l’inhibition évite les doublons d’alertes (p. ex. lorsqu’une panne de stockage provoque une série d’alertes de VM).
# Beispiel: Inhibit-Regel in alertmanager.yml
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['instance']Règle d’alerte : niveau d’occupation du stockage avec délai ‚for‘
- alert: ProxmoxStorageHighUsage
expr: (pve_storage_used_bytes / pve_storage_total_bytes) > 0.9
for: 30m
labels:
severity: warning
team: storage
annotations:
summary: "Storage fast voll auf {{ $labels.storage }}"
runbook: "https://intranet/runbooks/proxmox-storage-full"
Avec un ‚for‘ plus long, vous retardez les alertes pour des pics transitoires (p. ex. snapshots temporaires).
Étapes pratiques de test et de validation
Avant le déploiement en production, vérifiez de façon standardisée :
- Endpoint de l’exporter:
curl -s http://pve-node1:9273/metrics | head - Prometheus /targets : tous les targets pertinents affichent UP et des temps de scrape faibles.
- Panneaux Grafana : valider les évaluations clés (CPU, mémoire, stockage).
- Tests d’alerte : activer une règle de test avec un seuil bas, vérifier la route d’Alertmanager.
- Exercice de playbook : les destinataires exécutent les étapes définies et signalent le point de rétablissement.
Intégration dans les outils de gestion des incidents
Alertmanager prend en charge de nombreuses intégrations (Webhook, PagerDuty, Opsgenie, Microsoft Teams, Slack). Pour Slack/Webhook définissez un receiver avec l’URL correspondante et structurez les labels pour le routage (team, severity).
receivers:
- name: 'slack-main'
slack_configs:
- api_url: 'https://hooks.slack.com/services/XXXXX/XXXXX/XXXXX'
channel: '#infra-alerts'
title: '{{ template "slack.title" . }}'
Évitez de stocker des URL sensibles en clair dans des dépôts ; utilisez une solution de gestion des secrets.
Risques de sécurité et d’exploitation
Des points de terminaison d’exporter insuffisamment protégés représentent une surface d’attaque. Protégez les niveaux suivants :
- Réseau : configurez le pare-feu pour n’autoriser que les communications entre Prometheus et les exporters.
- Transport : TLS ou mTLS via un reverse-proxy si les segments réseau ne sont pas fiables.
- Accès API : tokens avec privilèges minimaux, rotation et utilisation d’un vault.
Remarques sur les mises à niveau et migrations
Les versions des exporters et des API peuvent devenir incompatibles. Procédure :
- Versions-Pinning : testez les nouvelles versions des exporters en staging.
- Smoke-Tests : après la mise à niveau, vérifiez les endpoints des exporters, les targets Prometheus et les tableaux de bord Grafana.
- Rollback : conservez une gestion de versions pour les configurations (Git) et des scripts de revert pour les unités systemd.
Stratégie de repli en cas d’avalanche d’alertes ou de défaillance système
Si les alerts se déclenchent de manière incontrôlée ou si Prometheus cause des problèmes, voici des mesures rapides :
- Configurer un silence via l’API d’Alertmanager pour les groupes d’alertes concernés.
- Identifier les requêtes Prometheus les plus coûteuses et les désactiver temporairement (revert de configuration).
- Réactiver l’instance Prometheus en périphérie (edge) ou séparer la charge de l’instance centrale.
# Silence per API anlegen (Beispiel)
curl -XPOST -H "Content-Type: application/json" http://alertmanager.example.local/api/v2/silences -d '{
"matchers": [{"name":"team","value":"storage"}],
"startsAt":"2026-07-28T10:00:00Z",
"endsAt":"2026-07-28T10:30:00Z",
"createdBy":"ops",
"comment":"Emergency mute while investigating"
}'Grafana : tableaux de bord, structure et reproductibilité
La conception de tableaux de bord va au-delà de jolis graphiques : utilisez des variables pour l’environnement/le nœud, enregistrez les dashboards au format JSON dans Git (export/import) et liez les runbooks directement dans les annotations des panels. Configurez les droits sur les dossiers pour limiter l’édition à une petite équipe.
Checklist pratique pour le déploiement
- Vérifiez les tokens, le pare-feu et la synchronisation temporelle.
- Installez les exporters node et PVE comme services, stockez les secrets en lieu sûr.
- Définissez le relabeling Prometheus, activez le rapport de cardinalité.
- Testez le routage d’Alertmanager, les silences et les règles d’inhibition.
- Fournissez les dashboards Grafana avec variables, liens vers les runbooks et versioning.
Conclusion
Le monitoring de Proxmox avec Prometheus et Grafana offre des insights approfondis si vous introduisez le système de manière itérative : un jeu d’exporters minimal (node_exporter, pve_exporter), une stratégie d’étiquetage RESTrictive pour limiter la cardinalité, des alerts testables avec runbooks et une stratégie de persistance évolutive constituent les éléments clés. Sécurisez les accès API, automatisez les tests et définissez des chemins de repli clairs — ainsi vous exploiterez votre cluster Proxmox de façon stable, traçable et évolutive.
Points de contrôle complémentaires (brefs)
- Vérifier la rotation automatisée des tokens.
- Documenter les backups TSDB et les processus de RESTauration.
- Organiser régulièrement des exercices d’alerte et des processus de postmortem.
Sécurité opérationnelle, reprise après sinistre et « monitoring qui surveille »
Outre la fonctionnalité de base, il est essentiel que votre monitoring soit lui‑même robuste, testable et RESTaurable. Considérez Prometheus, Alertmanager et Grafana non pas comme de simples outils, mais comme des services critiques pour l’exploitation : ils requièrent des SLOs propres, des procédures de sauvegarde, une planification de capacité et une observation capable de détecter tôt les défaillances de la pipeline de monitoring.
Métriques pour surveiller le monitoring
Collectez de manière ciblée des métriques internes de vos instances de monitoring, par exemple la durée des scrapes (scrape_duration_seconds), les scrapes échoués (scrape_samples_post_metric_relabeling), le WAL‑lag et l’utilisation de l’espace de la TSDB. Définissez des alertes lorsque ces indicateurs dépassent des seuils — un WAL‑lag élevé signale souvent des goulots d’étranglement I/O, une augmentation rapide des scrapes manquants indique des problèmes réseau ou d’API.
Recording Rules et agrégations pour l’optimisation des performances
Les Recording Rules stockent des séries temporelles pré‑agrégées en tant que nouvelles métriques et allègent les requêtes PromQL coûteuses et récurrentes. Créez des règles pour les indicateurs fréquemment utilisés (par ex. utilisation moyenne de la mémoire par nœud sur 5m) plutôt que de recalculer les données brutes à chaque requête de tableau de bord.
groups:
- name: recording_rules
rules:
- record: job:node_memory_used_bytes:avg5m
expr: avg_over_time(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes[5m])
Pourquoi cela fonctionne : les requêtes sur des séries déjà calculées sont nettement plus rapides et réduisent la charge CPU sur l’instance Prometheus centrale. Limites : en cas de cardinalité très élevée, il faut limiter et concevoir de manière ciblée les Recording Rules.
Sauvegarde TSDB et RESTauration
Prometheus propose une API de snapshot qui génère un bloc cohérent. Créez des snapshots réguliers et archivez‑les en dehors du stockage primaire (par ex. stockage d’objets). Exemple : générez un snapshot avant de modifier les paramètres de rétention ou de compaction et testez la RESTauration dans un environnement de staging.
# Snapshot per API auslösen und anschließend sichern
curl -s -XPOST http://prometheus.local:9090/api/v1/admin/tsdb/snapshot
| jq -r '.data.name'
| xargs -I{} tar -C /var/lib/prometheus/snapshots -czf /backup/prom_snap_{}.tar.gz {}
Documentez explicitement les étapes de RESTauration (quelle version, quels fichiers de configuration) et testez les RESTaurations au minimum tous les trimestres.
Canary-scrapes et contrôles synthétiques
Déployez un petit ensemble de VM ou services « canary » soumis à des contrôles synthétiques (Blackbox ou HTTP‑Exporter). Ils fournissent des signaux précoces lorsque des changements d’API, des segments réseau ou des problèmes d’authentification affectent des groupes entiers de targets.
Multi-Tenancy, contrôle d’accès et conformité
Si plusieurs équipes utilisent Grafana ou si vous fournissez des métriques Proxmox en tant que service pour des tiers, veillez à un RBAC finement granulaire. Utilisez les organisations Grafana, les Folder-Permissions et des requêtes basées sur des variables pour obtenir l’isolation des données. Vérifiez en outre si les métriques contiennent des données personnelles (par ex. noms d’utilisateur dans VM‑Meta) et supprimez/anonymisez‑les pour éviter les risques de non‑conformité.
Planification des coûts et réduction des coûts d’exploitation
La conservation à long terme de séries à haute cardinalité est coûteuse. Définissez une politique de rétention des données qui équilibre nécessité opérationnelle et coûts : rétention courte dans le Hot-Store, agrégation progressive dans un Long-Term-Store (VictoriaMetrics, Thanos). Utilisez le sampling et le downsampling pour les données historiques.
Automatisation : Provisioning und Config-as-Code
Versionnez le provisioning de Prometheus, Alertmanager et Grafana (Dashboards, Alerts, Datasources) dans Git. Automatisez les rollouts via CI/CD, testez les modifications de configuration contre une instance Prometheus de test (promtool check rules) et assurez-vous que les rollbacks via Git-Revert sont reproductibles.
Voies de repli et d’escalade rapides
Définissez des niveaux d’escalade clairs dans Alertmanager (par ex. Team → On-call → Management) et maintenez des runbooks documentés. Si le monitoring lui‑même tombe : activez des silences temporaires, désactivez les requêtes coûteuses et basculez vers des instances Prometheus en edge pour réduire le temps de rétablissement.
Vérification rapide (opérative) : activer les métriques de monitor, créer des Recording Rules, automatiser les Snapshot-Backups, configurer des Canary-Scrapes, vérifier le RBAC et l’anonymisation des données, versionner Dashboards et Alerts dans Git. Avec ces mesures supplémentaires, vous exploitez votre Proxmox-Monitoring de manière robuste, vérifiable et conforme — conditions préalables pour une exploitation durable et pour les intégrations dans des logiciels d’entreprise sur mesure et des processus opérationnels centraux.
Service Discovery, Laufzeitisolierung und mTLS-Härtung
Deux aspects complémentaires sont pratiques et importants : la Service Discovery automatique pour des pools Proxmox dynamiques et une isolation d’exécution propre de Prometheus. Générez les targets via file_sd depuis votre outil d’inventaire (Ansible/CMDB), au lieu de les maintenir statiquement – cela réduit les erreurs de configuration lors de la mise à l’échelle.
# file_sd example
- targets: ['pve1:9273','pve2:9273']
labels:
cluster: 'prod'
role: 'hypervisor'
Exploitez Prometheus de préférence dans un contexte d’exécution dédié (Container oder VM) avec un block-Storage direct et performant ; vérifiez les cgroup et l’I/O-QoS pour éviter les défaillances du WAL et de la compaction. Pour les Exporter-Endpunkte, le mTLS via Reverse-Proxy (Envoy/Nginx) et une CA interne facilitant la rotation des certificats sont recommandés. Cela protège l’intégrité des données, réduit la surface d’attaque et facilite l’intégration dans des logiciels d’entreprise sur mesure via des webhooks sécurisés.
Sur ce sujet, Proxmox Monitoring et Prometheus Alerting sont également importants. L’article situe ces aspects de manière claire et montre ce qui compte au quotidien.