Exporter les métriques d'un hôte avec node_exporter de Prometheus : collecteurs, collecteur textfile et filtrage du port par pare-feu

Objectif

Exposer les métriques de niveau hôte d'un serveur Linux (CPU, mémoire, disque, réseau, etc.) dans un format que Prometheus peut collecter, y compris des valeurs personnalisées calculées par un script local, sans rendre le point de terminaison des métriques accessible au-delà du système de supervision.

Prérequis

Un hôte Linux disposant de wget/curl et de tar ; un serveur Prometheus (ou un outil de collecte compatible) qui effectuera le scraping ; la possibilité d'ajouter une unité systemd et un utilisateur système dédié.

Étapes

1. Télécharger depuis les releases du projet la version correspondant au système d'exploitation et à l'architecture de l'hôte, puis l'extraire, par exemple node_exporter-<version>.linux-amd64.tar.gz, comme le décrit le guide Prometheus consacré au Node Exporter.
2. Créer pour le processus un utilisateur dédié et non privilégié : useradd --system --no-create-home --shell /usr/sbin/nologin node_exporter, puis placer le binaire dans /usr/local/bin/node_exporter, propriété de root avec les droits 0755, afin que le compte de service ne puisse pas remplacer son propre binaire.
3. Créer une unité systemd /etc/systemd/system/node_exporter.service qui exécute le binaire sous cet utilisateur avec User=node_exporter, ExecStart=/usr/local/bin/node_exporter et Restart=on-failure. Aucune option de collecteur n'est nécessaire pour obtenir la configuration par défaut : le README indique que des collecteurs tels que cpu, diskstats, filesystem, meminfo et loadavg sont activés par défaut sous Linux.
4. Pour publier une valeur personnalisée (horodatage de la dernière sauvegarde réussie, nombre de jours avant l'expiration d'un certificat), indiquer au collecteur textfile un répertoire avec --collector.textfile.directory=/var/lib/node_exporter/textfile_collector dans ExecStart (le collecteur reste inactif tant que cette option n'est pas définie), puis faire écrire par une tâche cron ou un script des fichiers *.prom dans ce répertoire, au format texte d'exposition de Prometheus. L'écriture doit être atomique, comme le montre le README : écrire dans name.prom.$$ dans le même répertoire, puis le renommer avec mv en name.prom, afin qu'un scrape ne lise jamais un fichier partiellement écrit.
5. Recharger la configuration et démarrer le service : systemctl daemon-reload && systemctl enable --now node_exporter.
6. Selon le README, node_exporter écoute par défaut sur le port HTTP 9100, et le point de terminaison n'a pas d'authentification intégrée, sauf si un --web.config.file est fourni. Limiter l'accès entrant par une règle de pare-feu de l'hôte qui n'autorise sur le port 9100 que l'adresse du serveur Prometheus, par exemple avec nftables : nft insert rule inet filter input tcp dport 9100 ip saddr != <prometheus-ip> drop (suppose une table inet filter avec une chaîne input ; insert place la règle avant les règles accept existantes ; elle ne couvre que IPv4 et disparaît au redémarrage, sauf si on l'ajoute à /etc/nftables.conf).
7. Vérifier : curl http://localhost:9100/metrics | grep node_ doit lister des familles de métriques préfixées par node_, comme dans l'exemple du guide.

Résultat attendu

L'unité systemd est active et activée au démarrage ; curl sur le port 9100 renvoie des métriques ; le port est inaccessible depuis tout hôte autre que le serveur Prometheus.

Limites et base de vérification

Ce contenu s'appuie sur le README de node_exporter et sur le guide Node Exporter de la documentation Prometheus. Pour annuler la configuration, exécuter systemctl disable --now node_exporter, puis supprimer le fichier d'unité et le binaire. Exécuter le binaire en tant que root est inutile pour les collecteurs par défaut et aggrave l'impact de toute vulnérabilité de l'exporter ; il vaut mieux le garder sous son propre utilisateur système.