Supervision et métriques

Grafana, Prometheus et InfluxDB

Proxmox pousse vers InfluxDB, Prometheus collecte tout le reste, Grafana réunit les deux. Et un piège à éviter dès l'installation : la version d'InfluxDB.

Niveau intermédiaire  ·  Lecture 16 min  ·  Base Prometheus 3, InfluxDB 2 et 3

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.

SourceCheminPourquoi
Proxmox VE (cluster, invités, stockages)Serveur de métriques natif vers InfluxDBAucun agent, toutes les machines virtuelles couvertes d'office
Système des noeuds et des serveurs Linuxnode_exporter vers PrometheusLe détail fin : disques, réseau, systemd, températures
CephModule prometheus du gestionnaire CephIntégré à Ceph, aucune installation
Sites, ports, certificatsblackbox_exporter vers PrometheusLa disponibilité vue de l'extérieur
ApplicationsLeur propre point /metricsLa plupart des logiciels récents l'exposent déjà
Et OpenTelemetry ?

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

Le piège du tag latest

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èreInfluxDB 2InfluxDB 3 Core
StatutMaintenue, sans évolution majeureVersion active, publications fréquentes
Plage d'une requêteIllimitéePlafonnée par un nombre de fichiers, environ 72 heures par défaut
Tableau de bord sur 30 joursSans réglageErreur, sauf à relever la limite au prix des performances
Rétention et sous-échantillonnageBuckets avec rétention, tâchesRétention, sous-échantillonnage par greffons
Langages de requêteFlux, InfluxQLSQL, InfluxQL
Compatible serveur de métriques ProxmoxOui, API v2 nativePar l'API d'écriture compatible v2, à valider sur votre version
Port par défaut80868181
Interface d'administrationIntégréeInfluxDB 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.

Quel langage de requête choisir

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.

Fichier .env
# 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
Fichier docker-compose.yml
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:
Initialiser InfluxDB 2
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 :

Démarrer et initialiser InfluxDB 3 Core
# 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.

Déclarer InfluxDB 2 depuis n'importe quel noeud
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 :

Les données arrivent-elles ?
docker compose exec influxdb influx query --org captain \
  'from(bucket:"proxmox") |> range(start:-5m) |> group(columns:["_measurement"]) |> count()'
Une mesure toutes les dix secondes, pour chaque invité

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

Installation sur Debian, noeuds Proxmox compris
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

Activer le module du gestionnaire Ceph
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.

Le jeton en lecture seule, depuis un noeud
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
Fichier pve-exporter/pve.yml
default:
  user: supervision@pve
  token_name: prometheus
  token_value: "secret affiche a la creation du jeton"
  verify_ssl: true
Fichier prometheus/prometheus.yml
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
Sondez depuis l'extérieur, pas seulement depuis l'intérieur

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.

Fichier grafana/provisioning/datasources/sources.yml
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.

Fichier prometheus/regles/base.yml
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"
Fichier alertmanager/alertmanager.yml
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
Vérifier avant de recharger
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 :

Ce que consomme réellement Prometheus
# 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
BaseRétention que nous retenonsRaison
Prometheus90 jours, plafond en tailleAssez pour comparer deux trimestres, le plafond protège le disque
InfluxDB 2, données Proxmox400 joursComparer un mois à celui de l'an passé pour la capacité
InfluxDB 3 CoreSelon le sous-échantillonnageSans lui, seules les fenêtres courtes restent interrogeables
Au-delà de quelques mois de Prometheus

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.