Mode opératoire — Superviser un lab avec Prometheus, et y ajouter une machine en une commande

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée les 19, 20 et 21/10/2026 dans le lab pfSense de l’école (phase 14 du suivi, tâches 14.3 et 14.4). La méthode vaut pour toute infrastructure de quelques dizaines de machines (Linux, Windows, MariaDB, pfSense). Le contexte est dans Documentation-pfSense.md (étapes 45 à 47) ; les règles de pare-feu dans Matrice-de-flux.md (§4.4) ; les scripts et fichiers de configuration dans scripts/supervision/.

Valeurs masquées. Aucun mot de passe n’apparaît ici. Le seul compte créé (MariaDB) n’en a pas.

Dernière mise à jour : 28/10/2026 — ajout du §14 (exporteurs PBS et Proxmox VE par leur API) et du §15 (sondes des accès distants Termix et Pangolin) ; l’écran est décrit dans le MO-17 État au 12/11/2026 : 15 machines supervisées (13 par node_exporter : 12 Linux et pfSense ; 2 Windows), 11 services sondés, exporteurs MariaDB, PBS et Proxmox. Les postes Windows sont déclarés par ajouter-poste-windows.sh (phase 21, étape 74).

Sommaire

1 · Le besoin

Le lab compte une quinzaine de machines réparties dans 5 réseaux (VLAN : WEB, BDD, ADM, USERS, et VISITEURS depuis le 30/10) : serveurs web, cluster de bases de données à 3 nœuds, annuaire Active Directory, bastion, serveur de sauvegarde, poste client, pare-feu. Jusqu’ici, savoir si tout allait bien demandait de se connecter machine par machine.

On veut un seul endroit qui sait, en permanence :

• si chaque machine est en vie, et dans quel état (processeur, mémoire, disques, réseau) ;
• si le cluster de bases est complet et synchronisé ;
• si les services répondent comme pour un utilisateur (site web, DNS, sauvegarde) ;
• et qui garde cet historique quelques semaines, pour comparer et alerter.

C’est le rôle de Prometheus. L’écran (Grafana) et les alertes viendront s’appuyer sur lui.

2 · Théorie : Prometheus, exporteurs, sondes, étiquettes

2.1 Le principe : Prometheus va chercher les mesures

                         toutes les 15 secondes
   ┌──────────────────┐  « donne-moi tes mesures »   ┌──────────────────────────┐
   │   PROMETHEUS     │ ───────────────────────────► │  exporteur (sur chaque   │
   │  (srv-metriques) │ ◄─────────────────────────── │  machine) : port 9100,   │
   │  base de mesures │   texte : cpu=…, ram=…, …    │  9104, 9182…             │
   └──────────────────┘                              └──────────────────────────┘

On dit que Prometheus fonctionne en « pull » (il tire les mesures) : la machine surveillée n’a rien à envoyer, elle attend qu’on la lise. Conséquence pratique : c’est vers les exporteurs qu’il faut ouvrir le pare-feu, depuis Prometheus seulement.

2.2 Deux regards complémentaires

Il faut les deux : une machine peut aller très bien et son service être en panne, et inversement.

2.3 Les étiquettes rendent tout lisible

Sans étiquette, une mesure s’appelle 10.0.20.11:9100. Avec, elle s’appelle srv-mysql-02, zone BDD, système linux. Les tableaux de bord et les alertes s’écrivent ensuite par étiquette : « toutes les machines de la zone BDD », « tous les Windows ».

Principe à retenir — Prometheus lit, il n’administre pas. Le serveur de supervision a le droit de lire les ports des exporteurs, et rien d’autre : pas de SSH vers les machines, pas de compte d’administration. S’il était piraté, il ne donnerait accès à rien.

2.4 Les risques à connaître

3 · L’architecture retenue

Pare-feu pfSense (posé à l’étape 45, une seule règle pour tous les exporteurs) :

Entre machines du même VLAN, pfSense ne voit pas passer le trafic : c’est alors le pare-feu de la machine qui filtre (cas des Windows, §10).

4 · Installer Prometheus

Contexte : VM srv-metriques installée (Debian 13 minimale, réseau fixe, à jour, accès SSH par clé). Objectif : Prometheus en service, qui ne garde que 30 jours et n’écoute que sur l’adresse du serveur.

4.1 Les paquets

sudo apt install -y --no-install-recommends prometheus prometheus-node-exporter curl

--no-install-recommends : sans lui, prometheus-node-exporter installe une trentaine de paquets « recommandés » (smartmontools, ipmitool, nvme-cli…) dont des services inutiles sur une VM. Incident H-25. Si c’est déjà arrivé : sudo apt purge prometheus-node-exporter-collectors puis sudo apt autoremove --purge.

4.2 Conservation et adresse d’écoute

Les options de démarrage sont dans /etc/default/prometheus (ligne ARGS=) :

sudo sed -i 's|^ARGS=.*|ARGS="--storage.tsdb.retention.time=30d --web.listen-address=10.0.30.14:9090"|' /etc/default/prometheus

sudo sed -i 's|^ARGS=.*|ARGS="--web.listen-address=10.0.30.14:9100"|' /etc/default/prometheus-node-exporter

sudo systemctl restart prometheus prometheus-node-exporter

Validation

curl -s http://10.0.30.14:9090/api/v1/status/flags | grep -o '"storage.tsdb.retention.time":"[^"]*"'

"storage.tsdb.retention.time":"30d"

Le paquet Debian n’inclut que l’ancienne interface web : la page des cibles est http://10.0.30.14:9090/classic/targets. Ce n’est pas gênant : l’écran de travail sera Grafana.

5 · La configuration, et comment la modifier sans risque

5.1 Le fichier

/etc/prometheus/prometheus.yml — copie de référence : scripts/supervision/prometheus.yml. Ses 8 jobs :

5.2 Les fiches : une machine = un petit fichier

Les jobs node, mysql et windows utilisent file_sd_configs : Prometheus lit tous les fichiers .yml d’un dossier.

  - job_name: 'node'
    file_sd_configs:
      - files:
          - '/etc/prometheus/cibles/node/*.yml'

Une fiche (/etc/prometheus/cibles/node/srv-web-01.yml) :

- targets: ['10.0.10.10:9100']
  labels:
    host: 'srv-web-01'
    zone: 'WEB'
    os: 'linux'

Principe à retenir — ajouter une fiche ne demande aucun rechargement : Prometheus surveille ses dossiers et prend la nouvelle machine en compte en moins d’une minute. On ne touche à prometheus.yml que pour ajouter un type de machine (un job).

5.3 Modifier prometheus.yml : la méthode sûre

Le fichier est écrit sur le PC, puis transféré — jamais collé dans un terminal web (un long collage arrive corrompu, incident H-24).

1. Depuis le PC (PowerShell)

scp "<dossier>\annexes\scripts\supervision\prometheus.yml" ipfixe@10.0.30.14:/tmp/prometheus.yml

2. Sur srv-metriques : copie de l’ancien, installation, contrôles

sudo cp /etc/prometheus/prometheus.yml /etc/prometheus/prometheus.yml.avant-<motif> && sudo install -m 644 -o root -g root /tmp/prometheus.yml /etc/prometheus/prometheus.yml && grep -c job_name /etc/prometheus/prometheus.yml && promtool check config /etc/prometheus/prometheus.yml

le nombre de jobs attendu (8 aujourd’hui), puis SUCCESS. Un avertissement « file … does not exist » sur un dossier de fiches encore vide est normal.

3. Seulement si SUCCESS

sudo systemctl reload prometheus

Ne jamais recharger sans promtool. Une configuration invalide n’est pas chargée : Prometheus garde l’ancienne en silence, et l’on croit avoir ajouté une surveillance qui n’existe pas. Le comptage des jobs attrape en plus les blocs en double (incident H-22).

Retour arrière : sudo cp /etc/prometheus/prometheus.yml.avant-<motif> /etc/prometheus/prometheus.yml puis systemctl reload prometheus.

6 · Les sondes de service (blackbox exporter)

6.1 Installation

sudo apt install -y --no-install-recommends prometheus-blackbox-exporter

Configuration /etc/prometheus/blackbox.yml (copie de référence : scripts/supervision/blackbox.yml), réduite aux modules utilisés :

Tous en preferred_ip_protocol: "ip4" : le lab n’a pas d’IPv6.

prometheus-blackbox-exporter --config.check --config.file=/etc/prometheus/blackbox.yml

sudo sed -i 's|^ARGS=.*|ARGS="--config.file /etc/prometheus/blackbox.yml --web.listen-address=127.0.0.1:9115 --log.level=warn"|' /etc/default/prometheus-blackbox-exporter

sudo systemctl restart prometheus-blackbox-exporter

L’écoute sur 127.0.0.1 : seul Prometheus, sur la même machine, a besoin de lui parler.

--log.level=warn est indispensable dès que les journaux sont centralisés. Par défaut, le blackbox écrit cinq lignes par sonde réussie (adresse résolue, requête, réponse, temps, succès) : avec 4 sondes toutes les 15 s, plus de 100 000 lignes par jour, qui ont rempli la base des journaux en quelques heures (35 709 lignes le 21/10). Le résultat des sondes est déjà dans Prometheus : les journaux ne gardent que les avertissements et les erreurs.

6.2 Une sonde = un job

Prometheus demande au blackbox « teste telle cible avec tel module ». Les trois lignes de relabel_configs sont toujours les mêmes : elles mettent la cible en paramètre, la gardent comme nom (instance), et envoient la demande au blackbox.

  - job_name: 'sonde_site'
    metrics_path: /probe
    params:
      module: [http_2xx_insecure]
    static_configs:
      - targets: ['https://www.sio.internal/']
        labels:
          host: 'srv-ha'
          service: 'site-web'
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Une sonde ne doit pas laisser de trace sur le service. Une sonde TCP « brute » sur MariaDB a été abandonnée : elle ouvrait une connexion non authentifiée toutes les 15 s, au risque de faire bloquer l’adresse du répartiteur par MariaDB (incident H-23). L’état du cluster est mesuré par mysqld_exporter (§9), qui s’authentifie.

Validation

curl -s http://10.0.30.14:9090/api/v1/query --data-urlencode 'query=probe_success' | grep -o '"service":"[^"]*"\|"value":\[[^]]*\]'

chaque service suivi d’une valeur "1". (Commande de lecture standard de l’API, à confirmer au prochain contrôle : À VÉRIFIER.)

7 · Ajouter une machine : quelle méthode selon la machine

Avant toute chose, deux conditions :

8 · Ajouter une machine Linux depuis le bastion, en une commande

Contexte : une nouvelle VM Debian du lab, joignable en SSH par le compte ipfixe (membre de sudo). Objectif : qu’elle apparaisse dans Prometheus, avec son nom et sa zone, sans rien modifier à la configuration.

8.1 Les deux scripts

Les deux scripts sont sans risque à relancer : une machine déjà équipée est simplement vérifiée, sa fiche réécrite à l’identique.

8.2 Une seule fois : déposer les scripts sur le bastion

Depuis le PC (PowerShell), dans le dossier annexes\scripts\supervision :

ssh ipfixe@10.0.30.12 "mkdir -p ~/supervision"

scp ajouter-machine.sh installer-node-exporter.sh ipfixe@10.0.30.12:~/supervision/

Si PowerShell répond stat local "ajouter-machine.sh": No such file or directory, il n’est pas dans le bon dossier : donne le chemin complet du fichier. Après toute modification d’un script sur le PC, recopie-le : le bastion garde sinon l’ancienne version.

8.3 Ajouter la machine

Sur srv-docker (Termix) :

cd ~/supervision

bash ajouter-machine.sh 10.0.10.11 ipfixe

(ou bash ajouter-machine.sh seul : le script pose les questions.)

Déroulé et réponses :

Attends que l’invite [sudo] soit affichée avant de taper. Tapé trop tôt, le mot de passe s’affiche en clair à l’écran et dans l’historique du terminal (incident H-28). Un mot de passe affiché doit être changé.

Validation

dans l’ordre : OK : node_exporter ecoute sur 10.0.10.11:9100, la liste des fiches (avec srv-web-02.yml), puis OK : srv-web-02 est supervise. Prometheus le prend en compte tout seul (moins d'une minute).

89c-ajouter-machine-srv-mysql-02.png

8.4 Cas de la zone BDD : pas d’Internet

Les nœuds de base n’ont pas d’accès Internet (règle BDD « TEMPORAIRE » décochée). Pour installer, on ouvre une fenêtre courte :

timeout 5 bash -c '</dev/tcp/deb.debian.org/80' && echo ouvert || echo ferme

Ne teste pas avec ping : la règle n’ouvre que TCP 80/443, un ping 8.8.8.8 échoue même règle ouverte. On teste le protocole que la règle vise.

En zone BDD, le script télécharge aussi mysqld_exporter (sans l’installer) : le §9 se fera ensuite sans rouvrir Internet.

89a-pfsense-bdd-fenetre-ouverte.png · 89d-fenetre-bdd-test-ouvert-ferme.webp · 89e-pfsense-bdd-fenetre-refermee.png

8.5 Si ça ne marche pas

9 · Ajouter un nœud de base de données MariaDB

Contexte : le nœud a déjà node_exporter (§8), et le paquet prometheus-mysqld-exporter dans son cache (téléchargé par le script en zone BDD). Objectif : mesurer l’état du serveur et du cluster Galera (nœuds présents, synchronisation, connexions).

9.1 Le compte de lecture — une seule fois pour tout le cluster

Sur un nœud, vérifier d’abord le cluster :

sudo mariadb -e "SELECT VERSION(); SHOW STATUS LIKE 'wsrep_cluster_size'; SHOW STATUS LIKE 'wsrep_local_state_comment';"

version ≥ 10.5, wsrep_cluster_size = nombre de nœuds, Synced. Puis :

sudo mariadb -e "CREATE USER IF NOT EXISTS 'prometheus'@'localhost' IDENTIFIED VIA unix_socket; GRANT PROCESS, REPLICATION CLIENT, SLAVE MONITOR ON *.* TO 'prometheus'@'localhost';"

Galera recopie le compte sur les autres nœuds. sur un autre nœud :

sudo mariadb -e "SHOW GRANTS FOR 'prometheus'@'localhost';"

GRANT PROCESS, BINLOG MONITOR, SLAVE MONITOR ON *.* TO 'prometheus'@'localhost' IDENTIFIED VIA unix_socket (BINLOG MONITOR est le nom actuel de REPLICATION CLIENT).

9.2 L’exporteur — sur chaque nœud

1. Installer et créer le fichier de connexion (sans mot de passe)

sudo apt-get install -y --no-install-recommends prometheus-mysqld-exporter && printf '[client]\nuser=prometheus\nsocket=/run/mysqld/mysqld.sock\n' | sudo tee /etc/mysql/prometheus-exporter.cnf >/dev/null && sudo chown root:prometheus /etc/mysql/prometheus-exporter.cnf && sudo chmod 640 /etc/mysql/prometheus-exporter.cnf && echo FICHIER-OK

2. Régler le service (l’adresse du nœud est détectée) et le démarrer

IP=$(hostname -I | awk '{print $1}'); sudo sed -i "s|^ARGS=\"\"|ARGS=\"--config.my-cnf=/etc/mysql/prometheus-exporter.cnf --web.listen-address=${IP}:9104\"|" /etc/default/prometheus-mysqld-exporter; sudo grep ^ARGS /etc/default/prometheus-mysqld-exporter; sudo systemctl reset-failed prometheus-mysqld-exporter; sudo systemctl restart prometheus-mysqld-exporter; sleep 2; systemctl is-active prometheus-mysqld-exporter

FICHIER-OK, la ligne ARGS= avec l’adresse du nœud, puis active.

Juste après l’installation, le service est en échec (failed) : c’est normal, ses options sont vides (ARGS="") tant qu’on ne lui a pas dit où se connecter. Le fichier d’exemple de Debian parle de DATA_SOURCE_NAME : les versions récentes ne la lisent plus, on utilise le fichier .cnf.

9.3 Déclarer le nœud

Sur srv-metriques (exemple pour un 4ᵉ nœud fictif srv-mysql-04 en 10.0.20.13) :

printf -- "- targets: ['10.0.20.13:9104']\n  labels:\n    host: 'srv-mysql-04'\n    zone: 'BDD'\n    os: 'linux'\n" | sudo tee /etc/prometheus/cibles/mysql/srv-mysql-04.yml

Validation, depuis srv-metriques (le test traverse aussi le pare-feu) :

curl -s http://10.0.20.13:9104/metrics | grep -E '^mysql_up|^mysql_global_status_wsrep_cluster_size|^mysql_global_status_wsrep_local_state '

mysql_up 1 (connexion réussie), wsrep_cluster_size = nombre de nœuds, wsrep_local_state 4 (= Synced).

88a-prometheus-cibles-mysql.png

10 · Ajouter une machine Windows

Contexte : machine Windows avec accès Internet (zones ADM et USERS), session PowerShell administrateur. Objectif : windows_exporter en service, son port ouvert à srv-metriques seul.

Les commandes se lancent dans l’ordre, dans la même fenêtre (chacune réutilise ce que la précédente a gardé). Regroupées dans installer-windows-exporter.ps1.

1. Vérifier les droits

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True. (Ne pas tester IsInRole('Administrators') : sur un Windows en français, le groupe s’appelle « Administrateurs » et le test répond False à tort — incident H-27.)

2. Télécharger la dernière version officielle

[Net.ServicePointManager]::SecurityProtocol='Tls12'; $rel=Invoke-RestMethod https://api.github.com/repos/prometheus-community/windows_exporter/releases/latest; $msi=$rel.assets | Where-Object {$_.name -like '*amd64.msi'} | Select-Object -First 1; $f="$env:TEMP\$($msi.name)"; Invoke-WebRequest $msi.browser_download_url -OutFile $f -UseBasicParsing; $rel.tag_name; Get-Item $f | Select-Object Name,Length

le numéro de version (v0.31.9 le 21/10) et le fichier .msi (~11 Mo).

3. Installer sans question

Start-Process msiexec.exe -ArgumentList "/i `"$f`" /qn" -Wait; Remove-Item $f; Get-Service windows_exporter

Running.

4. Ouvrir le port 9182 à srv-metriques seul

if (-not (Get-NetFirewallRule -DisplayName 'windows_exporter - srv-metriques seul' -ErrorAction SilentlyContinue)) { New-NetFirewallRule -DisplayName 'windows_exporter - srv-metriques seul' -Direction Inbound -Protocol TCP -LocalPort 9182 -RemoteAddress 10.0.30.14 -Action Allow -Profile Any | Out-Null }; Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq '9182'} | Get-NetFirewallRule | Format-Table DisplayName,Enabled -AutoSize

une seule règle. S’il y en a une autre (plus large), la regarder avant de la désactiver. Si la nôtre apparaît deux fois (commande envoyée deux fois, incident H-30) : Remove-NetFirewallRule -DisplayName 'windows_exporter - srv-metriques seul', puis relancer cette étape.

Pourquoi le pare-feu Windows ? srv-metriques et l’annuaire sont dans le même VLAN : leur trafic ne passe pas par pfSense. Seul le pare-feu de la machine peut alors limiter qui lit le port.

5. Déclarer la machine — sur srv-metriques (exemple : poste en 10.0.40.10) :

printf -- "- targets: ['10.0.40.10:9182']\n  labels:\n    host: 'poste-win11'\n    zone: 'USERS'\n    os: 'windows'\n" | sudo tee /etc/prometheus/cibles/windows/poste-win11.yml

Validation — deux tests, dans les deux sens :

curl -s --max-time 5 http://10.0.40.10:9182/metrics | grep -E '^windows_exporter_build_info|^windows_os_info' | cut -c1-200

depuis srv-metriques : la version de l’exporteur et celle de Windows.

curl -s --max-time 5 -o /dev/null http://10.0.30.10:9182/metrics && echo OUVERT || echo BLOQUE

depuis srv-docker (une autre machine) : BLOQUE — preuve que la règle n’ouvre qu’à srv-metriques.

88d-prometheus-cibles-windows.png

11 · Ajouter pfSense

1. System → Package Manager → Available Packages, chercher node_exporter, Install puis Confirm ; attendre Success.
2. Services → node_exporter :

3. Save.

Validation — dans Diagnostics → Command Prompt :

sockstat -4l | grep 9100

une seule ligne, sur 10.0.30.1:9100 (ni *, ni l’adresse WAN).

4. Déclarer pfSense (fiche dans le dossier node, puisque c’est le même exporteur) — sur srv-metriques :

printf -- "- targets: ['10.0.30.1:9100']\n  labels:\n    host: 'fw-01'\n    zone: 'ADM'\n    os: 'freebsd'\n" | sudo tee /etc/prometheus/cibles/node/fw-01.yml

curl -s http://10.0.30.1:9100/metrics | grep ^node_uname_info depuis srv-metriques → sysname="FreeBSD". Aucune règle de pare-feu à ajouter : l’adresse ADM de pfSense fait partie de LAB_NETS.

90a-pfsense-paquet-node-exporter.png · 90b-pfsense-node-exporter-reglages.png

12 · Retirer une machine

Supprimer sa fiche sur srv-metriques (exemple) :

sudo rm /etc/prometheus/cibles/node/srv-web-02.yml

Prometheus cesse de la lire sans rechargement ; son historique reste consultable jusqu’à expiration (30 jours). (Comportement standard de file_sd_configs, non encore testé dans le lab : À VÉRIFIER au premier retrait.) Pour une suppression définitive de la machine, désinstaller aussi l’exporteur (sudo apt purge prometheus-node-exporter) et, sous Windows, la règle de pare-feu.

13 · Contrôler que tout est mesuré

curl -s http://10.0.30.14:9090/api/v1/targets | grep -o '"health":"[a-z]*"' | sort | uniq -c

21 "health":"up" au 21/10 (1 Prometheus + 11 node + 3 mysql + 2 windows + 4 sondes), aucun down.

S’il y a un down, savoir lequel :

curl -s http://10.0.30.14:9090/api/v1/targets | grep -o '"instance":"[^"]*"\|"health":"[a-z]*"' | paste - -

Vue graphique : http://10.0.30.14:9090/classic/targets (bouton Unhealthy pour ne voir que les cibles en panne).

88a à 88d-prometheus-cibles-*.png

14 · Superviser PBS et Proxmox VE par leur API

Contexte : PBS et l’hyperviseur pve-01 ne reçoivent pas d’exporteur « classique » (PBS, si ; mais les mesures utiles — âge des sauvegardes, ressources réglées des VM — ne viennent que de leur API). Un exporteur tourne sur srv-metriques, interroge l’API à distance avec un jeton en lecture seule, et publie des mesures pour Prometheus.

Objectif : savoir, pour chaque VM, depuis quand elle n’a pas été sauvegardée, et ce que Proxmox lui réserve (mémoire, disque) au-delà de ce que la VM voit.

14.1 Le principe commun

Le secret ne s’affiche jamais : il est collé dans une saisie masquée (read -rsp), écrit dans un fichier aux droits restreints, puis la variable est effacée (unset).

14.2 L’exporteur Proxmox VE, pas à pas

1. Un environnement Python isolé (le paquet n’existe pas dans Debian 13 : apt-cache policy prometheus-pve-exporter ne trouve rien) :

sudo apt install -y python3-venv

sudo useradd --system --no-create-home --shell /usr/sbin/nologin pve-exporter

sudo python3 -m venv /opt/pve-exporter && sudo /opt/pve-exporter/bin/pip install prometheus-pve-exporter

/opt/pve-exporter/bin/pip show prometheus-pve-exporter | head -3; /opt/pve-exporter/bin/pve_exporter --help

Version: 3.10.2 ; l’aide liste --config.file et --web.listen-address (les options changent selon les versions : on les lit avant d’écrire la configuration).

2. La configuration, créée vide avec les bons droits, puis le secret en saisie masquée :

sudo install -m 640 -o root -g pve-exporter /dev/null /etc/prometheus/pve.yml

read -rsp "Secret du jeton PVE : " S; echo; printf 'default:\n  user: metriques-axel@pve\n  token_name: exporteur\n  token_value: "%s"\n  verify_ssl: false\n' "$S" | sudo tee /etc/prometheus/pve.yml >/dev/null; unset S

sudo stat -c '%a %U:%G' /etc/prometheus/pve.yml; sudo grep -c token_value /etc/prometheus/pve.yml

640 root:pve-exporter puis 1. Si la commande 2 est lancée avant la 1, le fichier est créé en 644 (lisible par tous) : ne pas relancer la 1 (elle viderait le fichier), corriger avec chown root:pve-exporter et chmod 640.

3. Le service : pve-exporter.service, avec les modules qui exigent un droit sur tout l’hyperviseur coupés (--no-collector.status --no-collector.node --no-collector.cluster --no-collector.qdevice --no-collector.backup-info, voir H-50).

sudo systemctl daemon-reload && sudo systemctl enable --now pve-exporter && systemctl is-active pve-exporter

curl -s -w "\nCODE HTTP : %{http_code}\n" "http://10.0.30.14:9221/pve?target=10.1.0.253&cluster=1&node=0" | grep -E '^pve_memory_size_bytes|^pve_guest_info|CODE HTTP' | head -30

CODE HTTP : 200, une ligne par VM du pool (et la 137), aucune VM d’un autre élève.

4. Le job Prometheus (même mécanisme que les sondes : Prometheus demande à l’exporteur local d’interroger la cible) :

  - job_name: 'pve'
    scrape_interval: 60s
    metrics_path: /pve
    params:
      module: [default]
      cluster: ['1']
      node: ['0']
    static_configs:
      - targets: ['10.1.0.253']
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 10.0.30.14:9221

Méthode sûre du §5.3 (copie, promtool check config, grep -c job_name, reload).

Validation :

curl -s -G http://10.0.30.14:9090/api/v1/query --data-urlencode 'query=up{job="pve"}'

une réponse qui se termine par "1"].

14.3 Les mesures utiles

15 · Sonder les accès distants (Termix, Pangolin)

Le module http_2xx_grafana vérifie le certificat (pas d’insecure_skip_verify) et exige que la réponse contienne "database": "ok" : une page d’erreur de Pangolin ne peut pas passer pour un succès.

  http_2xx_grafana:
    prober: http
    timeout: 10s
    http:
      preferred_ip_protocol: "ip4"
      fail_if_body_not_matches_regexp:
        - '"database": ?"ok"'

prometheus-blackbox-exporter --config.check --config.file=/etc/prometheus/blackbox.yml && sudo systemctl restart prometheus-blackbox-exporter

Prérequis côté Pangolin : une règle d’accès qui laisse passer le seul chemin /api/health (MO-10, §10.9).

Validation :

for c in "http_2xx_insecure&target=http://10.0.30.12:443/" "http_2xx_grafana&target=https://grafana.pangolin.<domaine>/api/health"; do curl -s "http://127.0.0.1:9115/probe?module=$c" | grep -E '^probe_success|^probe_http_status_code'; done

deux fois probe_success 1 et 200. Les nouvelles sondes apparaissent seules dans le tableau de bord (une ligne de disponibilité par valeur de l’étiquette service).

16 · Pièges et checklist

 La machine a une adresse fixe (ou réservée hors de la plage DHCP)
 Linux : bash ajouter-machine.sh <IP> ipfixe depuis srv-docker → « OK : … est supervise »
 Zone BDD : règle Internet ouverte avant, REFERMÉE après, test « ferme »
 Nœud MariaDB : compte prometheus présent (SHOW GRANTS), mysqld_exporter « active », mysql_up 1
 Windows : service Running, UNE règle 9182 limitée à 10.0.30.14, test BLOQUE depuis une autre machine
 pfSense : écoute sur 10.0.30.1:9100 seulement
 prometheus.yml modifié ? copie .avant-…, nombre de jobs, promtool SUCCESS, PUIS reload
 Contrôle final : toutes les cibles « up », aucune « down »

La règle à retenir en une phrase : une machine supervisée = un exporteur qui n’écoute que sur son adresse, un port ouvert à Prometheus seul, et une fiche de quatre lignes — le reste ne change pas.