InfluxDB metric server¶

Day 2 · ExploiterNiveau 2 · OpérerProcédureRédigé · à valider en lab

Raccordez votre cluster à l'outil de supervision déjà en place chez vous : Zabbix avec le template officiel Proxmox VE by HTTP, Prometheus avec l'exporteur communautaire prometheus-pve-exporter, ou un serveur de métriques InfluxDB ou Graphite alimenté directement par Proxmox VE. Les trois approches lisent les mêmes données ; choisissez celle que votre équipe sait exploiter.

Choisir son approche¶

Critère	Zabbix Proxmox VE by HTTP	Prometheus + `pve-exporter`	Metric Server InfluxDB / Graphite
Sens du flux	Zabbix interroge l'API (port 8006)	Prometheus interroge l'exporteur, qui interroge l'API	PVE pousse les métriques (`pvestatd`)
Ce qu'on installe	Rien sur les nœuds : un template et un jeton API	Un exporteur (VM ou conteneur dédié)	Rien sur les nœuds : une définition dans le Datacenter
Alertes	Déclencheurs fournis (quorum, nœud hors ligne, SMART, certificat…)	À écrire (règles Alertmanager)	Aucune : graphes Grafana, alertes à construire
Point fort	Prêt à l'emploi, découverte des VM, nœuds, stockages	Écosystème Grafana, requêtes PromQL	Historique fin, aucun compte API à gérer
Pour qui	Équipes déjà sur Zabbix	Équipes cloud-native	Tableaux de capacité, analyse de tendance

Dans tous les cas, gardez les notifications natives : la supervision externe ne voit ni les échecs de sauvegarde détaillés ni les alertes ZED.

Avant de toucher la prod

Serveur de supervision joignable depuis/vers les nœuds (TCP 8006 pour Zabbix et l'exporteur ; port InfluxDB ou Graphite pour le Metric Server).
Compte de service dédié en lecture seule, jamais root@pam. Voir Jetons API et comptes de service.
Certificat de l'API approuvé par le serveur de supervision, ou décision explicite de ne pas vérifier TLS.
Contrats N3 : vérifier avec le MSP que sa propre supervision n'utilise pas déjà le même compte.

Étapes¶

1. Créer le compte de service en lecture seule (commun à Zabbix et Prometheus)¶

GUICLI

Datacenter → Permissions → Users → Add : zabbix, realm Proxmox VE authentication server (@pve), sans mot de passe utile.
API Tokens → Add : utilisateur zabbix@pve, Token ID monitoring, Privilege Separation coché. Copier le secret (affiché une seule fois).
Permissions → Add → User Permission : chemin /, utilisateur zabbix@pve, rôle PVEAuditor. Puis API Token Permission : même chemin, jeton zabbix@pve!monitoring, rôle PVEAuditor.

pveum user add zabbix@pve --comment "Supervision lecture seule"
pveum acl modify / --users zabbix@pve --roles PVEAuditor
pveum user token add zabbix@pve monitoring --privsep 1      # noter le secret
pveum acl modify / --tokens 'zabbix@pve!monitoring' --roles PVEAuditor

2a. Zabbix : template Proxmox VE by HTTP¶

Vérifier que le template est présent (Data collection → Templates, rechercher « Proxmox »). Il est livré avec Zabbix ; les versions récentes du template exigent une version récente de Zabbix (7.4 pour la dernière à ce jour) : prenez celui qui correspond à votre serveur.
Créer un hôte cluster-pve (pas un hôte par nœud : le template découvre les nœuds), lui lier le template.

Renseigner les macros de l'hôte :

Macro	Valeur
`{$PVE.URL.HOST}`	IP ou nom d'un nœud, ou adresse virtuelle devant le cluster
`{$PVE.URL.PORT}`	`8006`
`{$PVE.TOKEN.ID}`	`zabbix@pve!monitoring`
`{$PVE.TOKEN.SECRET}`	secret du jeton (macro de type secret)

Ajuster les seuils si besoin ({$PVE.TRIGGER.CPU.WARNING}, {$PVE.TRIGGER.MEMORY.WARNING}, {$PVE.TRIGGER.DISK.WARNING}, 90 % par défaut).

2b. Prometheus : `prometheus-pve-exporter`¶

Sur une VM de supervision (pas sur les nœuds) :

python3 -m venv /opt/pve-exporter
/opt/pve-exporter/bin/pip install prometheus-pve-exporter
cat > /etc/prometheus/pve.yml <<'EOF'
default:
    user: zabbix@pve
    token_name: "monitoring"
    token_value: "<secret>"
    verify_ssl: true
EOF
/opt/pve-exporter/bin/pve_exporter --config.file /etc/prometheus/pve.yml   # écoute sur :9221

Côté Prometheus, une cible par nœud, réécrite vers l'exporteur :

scrape_configs:
  - job_name: 'pve'
    metrics_path: /pve
    params: { module: [default], cluster: ['1'], node: ['1'] }
    static_configs:
      - targets: ['pve01.client.lan', 'pve02.client.lan', 'pve03.client.lan']
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: supervision.client.lan:9221

Ajoutez node_exporter sur les nœuds si vous voulez les métriques système fines (disques, réseau). Le fonctionnement en service systemd est à écrire ; la documentation du projet décrit aussi un déploiement Docker.

2c. Metric Server InfluxDB ou Graphite intégré¶

GUICLI

Datacenter → Metric Server → Add → InfluxDB :

Name influx01, Server influx.client.lan, Port 8086, Protocol HTTPS ;
Organization et Bucket (par défaut proxmox), Token avec droit d'écriture sur le bucket ;
Advanced : Verify Certificate, Timeout, Max. Body Size.

Variante UDP (InfluxDB 1.x, écoute UDP sur 8089 côté InfluxDB) : plus simple, mais sans authentification ni accusé de réception. Graphite : port 2003 par défaut, UDP ou TCP, chemin proxmox. Selon la version 9.x, un type OpenTelemetry est aussi proposé.

La définition est stockée dans /etc/pve/status.cfg, partagé par tout le cluster :

cat /etc/pve/status.cfg
# influxdb: influx01
#         server influx.client.lan
#         port 8086
#         influxdbproto https
#         organization proxmox
#         bucket proxmox

Créez-la de préférence par la GUI : le jeton est stocké à part, sous /etc/pve/priv/.

Importez ensuite un tableau de bord Grafana adapté à la source (InfluxDB 2 en Flux ou InfluxQL selon votre version).

Vérifications

Zabbix : Monitoring → Latest data de l'hôte cluster-pve : nœuds, VM et stockages découverts en moins de 10 minutes, aucun élément Not supported.
Prometheus : curl -s 'http://supervision.client.lan:9221/pve?target=pve01.client.lan&cluster=1&node=1' | grep -m3 pve_up renvoie des valeurs 1.
Metric Server : dans InfluxDB, des mesures (par exemple system, cpustat, memory, nics) arrivent toutes les 10 secondes environ ; journalctl -u pvestatd -n 50 sans erreur d'envoi.

Rollback

Supprimer l'hôte Zabbix ou la cible Prometheus ; Datacenter → Metric Server → décocher Enabled ou Remove. Révoquer le jeton : pveum user token remove zabbix@pve monitoring.

Pièges vus en support

Jeton créé avec Privilege Separation mais sans permission propre : l'API répond, mais vide. Donnez le rôle au jeton et à l'utilisateur.
Zabbix pointé sur un seul nœud : si ce nœud tombe, la supervision perd tout le cluster. Utilisez une adresse virtuelle, ou supervisez aussi chaque nœud par ping et agent.
Metric Server en TCP ou HTTP vers un serveur lent : pvestatd peut prendre du retard et griser les nœuds dans la GUI. Gardez un timeout court.
Seuils de 90 % hérités tels quels : trop tard pour Ceph (nearfull à 85 %) et pour ZFS (80 %). Voir le plan de capacité.
verify_ssl: false laissé en production après un test.

Quand ouvrir un ticket iTop

Déclencheur « quorum » ou « nœud hors ligne » dans Zabbix : suivez d'abord RB-09. Besoin d'intégrer les alertes à la supervision du MSP, ou erreurs d'API persistantes : P3, avec le message d'erreur et pveversion -v.

Ouvrir un ticket iTop