Cette page s'adresse à ceux qui veulent de beaux graphiques, et surtout des graphiques utiles : voir une latence de stockage grimper avant que les utilisateurs ne s'en plaignent, superposer la charge d'un noeud et celle des machines qu'il héberge, prévoir le jour où le pool sera plein. Le guide cluster Proxmox VE installe une première version de cette chaîne avec InfluxDB et Telegraf. Ici, nous l'étendons à toute l'infrastructure.
01Pourquoi trois briques
Deux philosophies de collecte coexistent, et chacune a ses terrains.
- Le modèle tiré, celui de Prometheus : chaque cible expose ses métriques sur une URL, et Prometheus vient les lire à intervalle régulier. Une cible qui ne répond plus se voit immédiatement. C'est le standard de fait pour les applications, les conteneurs et les serveurs Linux.
- Le modèle poussé, celui d'InfluxDB : la source envoie elle-même ses mesures. C'est ainsi que Proxmox VE exporte ses métriques de cluster, de noeuds, de machines et de stockages, nativement et sans agent.
Plutôt que de forcer l'un des deux, nous laissons chaque source parler sa langue et confions à Grafana le rôle d'interprète.
| Source | Chemin | Pourquoi |
|---|---|---|
| Proxmox VE (cluster, invités, stockages) | Serveur de métriques natif vers InfluxDB | Aucun agent, toutes les machines virtuelles couvertes d'office |
| Système des noeuds et des serveurs Linux | node_exporter vers Prometheus | Le détail fin : disques, réseau, systemd, températures |
| Ceph | Module prometheus du gestionnaire Ceph | Intégré à Ceph, aucune installation |
| Sites, ports, certificats | blackbox_exporter vers Prometheus | La disponibilité vue de l'extérieur |
| Applications | Leur propre point /metrics | La plupart des logiciels récents l'exposent déjà |
Proxmox VE 9 sait aussi exporter ses métriques en OpenTelemetry, et Prometheus 3 sait les recevoir directement. C'est prometteur pour se passer d'InfluxDB, mais la fonctionnalité est jeune des deux côtés et les noms de métriques ne correspondent à aucun tableau de bord existant. Nous la gardons en observation pour l'instant, et restons sur InfluxDB en production.
02InfluxDB 2 ou 3 : le choix
Depuis le 7 avril 2026, l'image Docker influxdb:latest désigne InfluxDB 3 Core, et
non plus la version 2. Un tutoriel daté suivi à la lettre installe donc la version 3 en croyant
installer la 2, et les commandes influx, les buckets et les jetons ne fonctionnent
plus comme décrit. Épinglez toujours la version majeure : influxdb:2 ou
influxdb:3-core, jamais latest.
Les deux versions sont deux produits différents, pas deux étapes d'un même produit. La 3 a été réécrite sur un moteur à fichiers Parquet ; elle est plus rapide à l'écriture et en requête SQL, mais son édition libre, Core, limite la quantité de données qu'une requête peut parcourir.
| Critère | InfluxDB 2 | InfluxDB 3 Core |
|---|---|---|
| Statut | Maintenue, sans évolution majeure | Version active, publications fréquentes |
| Plage d'une requête | Illimitée | Plafonnée par un nombre de fichiers, environ 72 heures par défaut |
| Tableau de bord sur 30 jours | Sans réglage | Erreur, sauf à relever la limite au prix des performances |
| Rétention et sous-échantillonnage | Buckets avec rétention, tâches | Rétention, sous-échantillonnage par greffons |
| Langages de requête | Flux, InfluxQL | SQL, InfluxQL |
| Compatible serveur de métriques Proxmox | Oui, API v2 native | Par l'API d'écriture compatible v2, à valider sur votre version |
| Port par défaut | 8086 | 8181 |
| Interface d'administration | Intégrée | InfluxDB 3 Explorer, à part |
Notre recommandation
Pour une supervision d'infrastructure, InfluxDB 2. Ce que l'on attend d'une base de supervision, c'est précisément de comparer cette semaine au mois dernier, et c'est ce que Core fait mal. La version 2 n'évolue plus beaucoup, mais elle est stable, connue, et largement suffisante pour quelques milliers de séries.
InfluxDB 3 Core se justifie pour des données à fort débit lues sur des fenêtres courtes : capteurs, télémétrie, alimentation d'un traitement temps réel. Si vous partez sur la 3 pour la supervision, prévoyez dès le départ le sous-échantillonnage, ou acceptez que Grafana ne serve qu'aux trois derniers jours et que les tendances longues vivent ailleurs, dans Prometheus par exemple.
Flux n'évolue plus et n'existe pas dans la version 3. Écrivez vos tableaux de bord en InfluxQL, commun aux deux versions : la migration future se fera sans réécrire chaque panneau. Sur la version 2, InfluxQL nécessite une correspondance entre base et bucket, que la commande influx v1 dbrp crée en une ligne.
03Déployer la pile
Une machine virtuelle dédiée, sur Debian 13, avec Docker. Prévoyez 4 vCPU, 8 Go de mémoire et un disque rapide de 100 Go pour une cinquantaine d'hôtes ; c'est le stockage qui limite, rarement le processeur. Les versions sont regroupées dans un fichier d'environnement, pour qu'une montée de version soit une ligne modifiée et relue.
# relever les versions courantes sur les pages de publication de chaque projet
PROMETHEUS_VERSION=v3.x.y
ALERTMANAGER_VERSION=v0.x.y
GRAFANA_VERSION=12.x.y
BLACKBOX_VERSION=v0.x.y
PVE_EXPORTER_VERSION=3.x.y
INFLUXDB_IMAGE=influxdb:2
services:
prometheus:
image: prom/prometheus:${PROMETHEUS_VERSION}
restart: unless-stopped
command:
- --config.file=/etc/prometheus/prometheus.yml
- --storage.tsdb.path=/prometheus
- --storage.tsdb.retention.time=90d
- --storage.tsdb.retention.size=60GB
- --web.enable-lifecycle
volumes:
- ./prometheus:/etc/prometheus:ro
- prometheus_data:/prometheus
ports:
- "127.0.0.1:9090:9090"
alertmanager:
image: prom/alertmanager:${ALERTMANAGER_VERSION}
restart: unless-stopped
volumes:
- ./alertmanager:/etc/alertmanager:ro
ports:
- "127.0.0.1:9093:9093"
influxdb:
image: ${INFLUXDB_IMAGE}
restart: unless-stopped
volumes:
- influxdb_data:/var/lib/influxdb2
ports:
# expose sur le reseau d'administration : les noeuds Proxmox y ecrivent
- "10.10.0.50:8086:8086"
blackbox:
image: prom/blackbox-exporter:${BLACKBOX_VERSION}
restart: unless-stopped
pve-exporter:
image: prompve/prometheus-pve-exporter:${PVE_EXPORTER_VERSION}
restart: unless-stopped
volumes:
- ./pve-exporter/pve.yml:/etc/prometheus/pve.yml:ro
grafana:
image: grafana/grafana:${GRAFANA_VERSION}
restart: unless-stopped
environment:
GF_SERVER_ROOT_URL: https://grafana.exemple.fr
GF_USERS_ALLOW_SIGN_UP: "false"
GF_ANALYTICS_REPORTING_ENABLED: "false"
volumes:
- ./grafana/provisioning:/etc/grafana/provisioning:ro
- grafana_data:/var/lib/grafana
ports:
- "127.0.0.1:3000:3000"
volumes:
prometheus_data:
influxdb_data:
grafana_data:
docker compose up -d influxdb # organisation, bucket de 400 jours et compte administrateur docker compose exec influxdb influx setup \ --org captain --bucket proxmox --retention 400d \ --username admin --password 'a-changer-tout-de-suite' --force # jeton d'ecriture limite au seul bucket proxmox, pour les noeuds docker compose exec influxdb influx bucket list docker compose exec influxdb influx auth create \ --org captain --write-bucket ID_DU_BUCKET \ --description "ecriture proxmox" # jeton de lecture pour Grafana docker compose exec influxdb influx auth create \ --org captain --read-bucket ID_DU_BUCKET \ --description "lecture grafana" # correspondance InfluxQL, pour les tableaux de bord docker compose exec influxdb influx v1 dbrp create \ --org captain --db proxmox --rp autogen \ --bucket-id ID_DU_BUCKET --default
Si vous choisissez InfluxDB 3 Core
Remplacez l'image par influxdb:3-core, le volume par
/var/lib/influxdb3 et le port par 8181. La commande de démarrage et l'initialisation
diffèrent :
# commande du conteneur, a placer dans le service influxdb influxdb3 serve --node-id supervision01 \ --object-store file --data-dir /var/lib/influxdb3 # jeton administrateur, affiche une seule fois : le conserver au coffre docker compose exec influxdb influxdb3 create token --admin # la base, equivalent du bucket docker compose exec influxdb influxdb3 create database proxmox \ --token "$INFLUXDB3_ADMIN_TOKEN"
04Proxmox vers InfluxDB
Le serveur de métriques se déclare une seule fois, au niveau du centre de données. Tous les noeuds envoient alors leurs mesures toutes les dix secondes, y compris celles de chaque machine virtuelle et de chaque conteneur, sans rien installer dans les invités.
pvesh create /cluster/metrics/server/supervision \
--type influxdb \
--server 10.10.0.50 --port 8086 \
--influxdbproto http \
--organization captain --bucket proxmox \
--token 'JETON_D_ECRITURE'
# la configuration est partagee par tout le cluster
cat /etc/pve/status.cfg
Quelques minutes plus tard, les mesures system, cpustat,
memory, nics et blockstat apparaissent dans le bucket. Vérifiez
depuis le serveur de supervision :
docker compose exec influxdb influx query --org captain \ 'from(bucket:"proxmox") |> range(start:-5m) |> group(columns:["_measurement"]) |> count()'
Sur un cluster de cinq noeuds et deux cents machines, cela représente quelques centaines d'écritures par seconde. InfluxDB 2 l'absorbe sans broncher sur un disque SSD, mais pas sur un disque mécanique partagé. C'est la cause la plus fréquente d'une pile de supervision qui ralentit au bout de six mois.
05Prometheus et ses exporters
node_exporter sur chaque serveur
apt install prometheus-node-exporter
# n'ecouter que sur le reseau d'administration
echo 'ARGS="--web.listen-address=10.10.0.11:9100"' \
> /etc/default/prometheus-node-exporter
systemctl restart prometheus-node-exporter
curl -s http://10.10.0.11:9100/metrics | head
Ceph, déjà prêt
ceph mgr module enable prometheus
# le point de collecte suit le gestionnaire actif, port 9283
ceph mgr services
Les vues propres à Proxmox, si besoin
L'exporteur prometheus-pve-exporter interroge l'API de Proxmox et expose l'état des
invités, des stockages, du quorum et des sauvegardes. Il fait doublon avec InfluxDB pour les
métriques de charge, mais apporte des états que le serveur de métriques n'envoie pas, comme les
invités arrêtés ou la date de la dernière sauvegarde. Créez-lui un jeton d'API en lecture seule,
rôle PVEAuditor.
pveum user add supervision@pve --comment "lecture seule pour la supervision" pveum acl modify / --users supervision@pve --roles PVEAuditor pveum user token add supervision@pve prometheus --privsep 0
default: user: supervision@pve token_name: prometheus token_value: "secret affiche a la creation du jeton" verify_ssl: true
global:
scrape_interval: 30s
evaluation_interval: 30s
alerting:
alertmanagers:
- static_configs:
- targets: ["alertmanager:9093"]
rule_files:
- /etc/prometheus/regles/*.yml
scrape_configs:
- job_name: noeuds
static_configs:
- targets: ["10.10.0.11:9100", "10.10.0.12:9100", "10.10.0.13:9100"]
labels: {role: proxmox}
- targets: ["10.10.0.21:9100", "10.10.0.22:9100"]
labels: {role: web}
- job_name: ceph
honor_labels: true
static_configs:
- targets: ["10.10.0.11:9283", "10.10.0.12:9283", "10.10.0.13:9283"]
- job_name: pve
metrics_path: /pve
params:
module: [default]
cluster: ["1"]
node: ["1"]
static_configs:
- targets: ["10.10.0.11"]
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: pve-exporter:9221
- job_name: sites
metrics_path: /probe
params:
module: [http_2xx]
static_configs:
- targets: ["https://www.exemple.fr", "https://boutique.exemple.fr"]
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: blackbox:9115
Un blackbox_exporter installé sur la même machine que vos sites mesure la santé du serveur web, pas ce que voient vos clients. Placez au moins une sonde ailleurs, ou gardez un Uptime Kuma externe à côté, comme décrit dans la doc Beszel et Uptime Kuma.
06Grafana, les sources et les tableaux
Les sources de données se déclarent par fichier : elles sont versionnées, reproductibles, et une réinstallation de Grafana ne demande aucun clic.
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
uid: prometheus
url: http://prometheus:9090
isDefault: true
jsonData:
timeInterval: 30s
- name: Proxmox
type: influxdb
uid: proxmox
url: http://influxdb:8086
jsonData:
dbName: proxmox
httpMode: POST
httpHeaderName1: Authorization
secureJsonData:
httpHeaderValue1: "Token JETON_DE_LECTURE"
Les tableaux de bord de départ
Inutile de partir d'une page blanche. Le tableau communautaire Node Exporter Full (identifiant 1860 sur grafana.com) couvre très bien les serveurs Linux. Pour Proxmox et Ceph, plusieurs tableaux communautaires existent ; importez-les, puis réduisez-les. Un tableau de quarante panneaux ne se lit pas pendant un incident.
Ce que nous mettons sur le tableau d'accueil d'un cluster, et rien de plus :
- l'état du quorum et de Ceph, en un mot et une couleur ;
- le processeur et la mémoire de chaque noeud, superposés, pour voir le déséquilibre ;
- la latence d'écriture des OSD, l'indicateur précoce par excellence ;
- l'occupation des pools avec leur projection à trente jours ;
- les dix invités les plus gourmands, en processeur et en entrées-sorties.
07Des alertes qui ont du sens
Grafana sait alerter, Prometheus aussi. Choisissez un seul des deux, sans quoi vous recevrez deux fois chaque alerte et n'en réglerez jamais qu'une. Nous confions les alertes à Prometheus et Alertmanager : les règles vivent dans des fichiers relus et versionnés, et elles continuent de fonctionner si Grafana tombe.
groups:
- name: base
rules:
# une cible muette n'est pas une cible en bonne sante
- alert: CibleInjoignable
expr: up == 0
for: 5m
labels: {severity: critique}
annotations:
summary: "{{ $labels.instance }} ne repond plus depuis 5 minutes"
# prevoir plutot que constater : plein dans moins de 4 heures
- alert: DisquePleinSous4h
expr: |
predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 4*3600) < 0
and node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.2
for: 30m
labels: {severity: critique}
annotations:
summary: "{{ $labels.mountpoint }} sur {{ $labels.instance }} sera plein sous 4 h"
- alert: CephDegrade
expr: ceph_health_status > 0
for: 10m
labels: {severity: alerte}
annotations:
summary: "Ceph n'est plus en HEALTH_OK depuis 10 minutes"
- alert: SiteEnPanne
expr: probe_success == 0
for: 2m
labels: {severity: critique}
annotations:
summary: "{{ $labels.instance }} ne repond plus"
- alert: CertificatBientotExpire
expr: probe_ssl_earliest_cert_expiry - time() < 14 * 86400
for: 1h
labels: {severity: alerte}
annotations:
summary: "Le certificat de {{ $labels.instance }} expire dans moins de 14 jours"
route:
receiver: equipe
group_by: [alertname, instance]
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- matchers: [severity="critique"]
receiver: astreinte
repeat_interval: 1h
receivers:
- name: equipe
webhook_configs:
- url: https://chat.exemple.fr/hooks/supervision
- name: astreinte
webhook_configs:
- url: https://chat.exemple.fr/hooks/astreinte
- url: https://ntfy.exemple.net/astreinte
docker compose exec prometheus promtool check config /etc/prometheus/prometheus.yml docker compose exec prometheus promtool check rules /etc/prometheus/regles/base.yml curl -X POST http://127.0.0.1:9090/-/reload
08Rétention et volumétrie
Un échantillon Prometheus occupe un à deux octets une fois compressé. Un serveur supervisé par node_exporter expose environ un millier de séries ; collecté toutes les trente secondes, cela représente de l'ordre de 3 à 6 Mo par jour et par hôte. Mesurez plutôt que d'estimer :
# nombre de series actives curl -s 'http://127.0.0.1:9090/api/v1/query?query=prometheus_tsdb_head_series' # taille sur disque docker compose exec prometheus du -sh /prometheus
| Base | Rétention que nous retenons | Raison |
|---|---|---|
| Prometheus | 90 jours, plafond en taille | Assez pour comparer deux trimestres, le plafond protège le disque |
| InfluxDB 2, données Proxmox | 400 jours | Comparer un mois à celui de l'an passé pour la capacité |
| InfluxDB 3 Core | Selon le sous-échantillonnage | Sans lui, seules les fenêtres courtes restent interrogeables |
Prometheus n'est pas conçu pour l'archivage long. Si vous avez besoin d'un an de métriques détaillées, ajoutez un stockage long terme compatible, comme VictoriaMetrics ou Thanos, en écriture distante. C'est un chantier à part entière, à n'ouvrir que si le besoin est réel.
09Sécuriser l'ensemble
- Aucun port public en dehors de Grafana, derrière un proxy inverse en TLS. Prometheus et Alertmanager n'ont pas d'authentification par défaut : ils restent sur l'interface locale.
- Les exporters sur le réseau d'administration, jamais sur l'interface publique d'un serveur. Un node_exporter exposé sur Internet décrit votre machine à qui le demande.
- Un jeton par usage : écriture pour Proxmox, lecture pour Grafana, administration au coffre. Le jeton administrateur d'InfluxDB n'a rien à faire dans un fichier de configuration.
- Grafana relié à votre annuaire, ou à défaut des comptes nominatifs avec double authentification. Le compte admin partagé est la première chose que nous désactivons en reprenant une plateforme.
Une supervision qui veille pendant que vous dormez
Nous concevons, installons et exploitons des plateformes de supervision pour des PME, des hébergeurs et des collectivités : Zabbix, Prometheus et Grafana, ou plus léger quand le besoin l'est. Reprise d'une supervision existante, réglage des alertes qui sonnent pour rien, astreinte : nous intervenons au forfait comme au long cours.