node-exporter expose les métriques système d’un VPS Linux (CPU, RAM, disque, réseau) au format Prometheus. Tutoriel d’installation et integration en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer).
Voir notre guide observabilité.
Étape 1 — Installer node-exporter
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-1.x.linux-amd64.tar.gz
tar xzf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/
sudo chmod +x /usr/local/bin/node_exporter
# User dédié
sudo useradd -rs /bin/false node_exporterÉtape 2 — Service systemd
# /etc/systemd/system/node-exporter.service
[Unit]
Description=Node Exporter
After=network.target
[Service]
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter --web.listen-address=127.0.0.1:9100
Restart=always
[Install]
WantedBy=multi-user.target
systemctl enable --now node-exporter
curl http://127.0.0.1:9100/metrics | head -20Étape 3 — Exposer via Tailscale
Important : --web.listen-address=127.0.0.1:9100 ne expose pas publiquement. Pour que Prometheus central puisse scraper, exposer via Tailscale ou réseau privé.
# Ou bind sur tailscale0
ip a show tailscale0 # ex 100.10.20.30
ExecStart=/usr/local/bin/node_exporter --web.listen-address=100.10.20.30:9100Étape 4 — Configurer Prometheus pour scraper
# prometheus.yml côté serveur Prometheus
scrape_configs:
- job_name: node
static_configs:
- targets:
- "100.10.20.30:9100" # web-prod-01 (via tailscale)
- "100.10.20.31:9100" # db-prod-01
- "100.10.20.32:9100" # api-prod-01
labels:
env: productionÉtape 5 — Dashboard Grafana
- Grafana → Dashboards → Import
- Dashboard ID : 1860 (Node Exporter Full)
- Data source : Prometheus
- Import
Vous obtenez un dashboard riche avec CPU, RAM, disque, réseau, par instance.
cAdvisor pour Docker
Pour métriques par container Docker :
docker run -d --name cadvisor \
--restart always \
-p 127.0.0.1:8080:8080 \
-v /:/rootfs:ro \
-v /var/run:/var/run:ro \
-v /sys:/sys:ro \
-v /var/lib/docker/:/var/lib/docker:ro \
gcr.io/cadvisor/cadvisor:latestSur le même thème
À lire aussi : VictoriaMetrics : alternative haute performance à Prometheus.
Solution d’hébergement pour ce tutoriel
Hostinger accueille un site WordPress, un VPS Linux ou une boutique en ligne sans configuration complexe.
Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.
Pourquoi Prometheus node-exporter sur un VPS ouest-africain en 2026
Prometheus est un systeme de monitoring open-source incube par la CNCF, qui collecte des metriques temporelles via scraping HTTP. Node-exporter est l agent officiel pour exposer les metriques systeme Linux (CPU, RAM, disque, reseau, fichiers ouverts, processus). Pour un freelance qui gere 3 a 10 VPS chez Hostinger, Contabo ou OVH a Dakar, Abidjan ou Lome, Prometheus + node-exporter forment la base d une supervision robuste, gratuite et auto-hebergeable.
Le contraste avec les solutions commerciales est net : Datadog facture environ 23 USD par hote par mois (environ 15 100 FCFA), New Relic 25 USD par hote (environ 16 400 FCFA). Sur 10 VPS, c est 230 USD mensuels (151 000 FCFA), 2 760 USD annuels (1 810 000 FCFA). Prometheus self-hosted coute le prix du VPS qui l heberge, soit environ 6 EUR par mois (3 935 FCFA) pour un setup confortable.
Etape 1 : installer node-exporter sur chaque VPS surveille
Telechargez la derniere version binaire depuis github.com/prometheus/node_exporter/releases. La version courante en 2026 est la 1.8.x. Le binaire est statique, sans dependance, et tourne en utilisateur non privilegie.
cd /tmp
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xzf node_exporter-1.8.2.linux-amd64.tar.gz
sudo mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
sudo useradd -rs /bin/false node_exporterSortie attendue : la commande /usr/local/bin/node_exporter –version retourne node_exporter, version 1.8.2 (…). Si elle retourne not found, le PATH n est pas mis a jour. Corrigez avec hash -r ou verifiez le mv.
Etape 2 : creer l unite systemd pour le lancement persistant
Le binaire doit tourner en service supervise. Creez /etc/systemd/system/node_exporter.service :
[Unit]
Description=Prometheus Node Exporter
After=network-online.target
Wants=network-online.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter \
--collector.systemd \
--collector.processes \
--web.listen-address=:9100
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targetActivez avec systemctl daemon-reload puis systemctl enable –now node_exporter. Vous devriez obtenir : systemctl status node_exporter affiche active (running) et journalctl -u node_exporter montre une ligne msg=Listening on address=:9100. Si le port 9100 est deja pris, le service crash en boucle (Restart on-failure declenche). Changez le port via –web.listen-address=:9200.
Etape 3 : tester l exposition des metriques en local
Avant d ouvrir le port au reseau, validez la sortie en local. curl -s http://localhost:9100/metrics retourne un texte format Prometheus : des lignes commencant par # HELP et # TYPE puis des metriques de la forme node_cpu_seconds_total{cpu= 0 ,mode= idle } 12345.67. La sortie complete fait environ 100 KB et plusieurs centaines de metriques.
Sortie attendue : la commande retourne du texte ASCII en quelques milliseconds. Si elle hang ou retourne 502, le service n a pas demarre proprement. Inspectez journalctl -u node_exporter -n 50.
Etape 4 : securiser l acces au port 9100
Ne jamais ouvrir le 9100 sur Internet directement. Restreignez via UFW : ufw allow from IP-DU-PROMETHEUS to any port 9100. Alternative plus elegante : binder node-exporter sur 127.0.0.1 et acceder via SSH tunnel ou WireGuard. Pour un setup multi-VPS, WireGuard mesh entre serveurs est la solution la plus propre.
Ce que vous devez voir : un nmap -p 9100 votre-ip-publique depuis Internet retourne filtered ou closed, jamais open. Si open, votre firewall n est pas applique. Verifiez avec ufw status verbose.
Etape 5 : installer Prometheus sur le VPS de monitoring
Sur un VPS dedie au monitoring (different de ceux supervises pour eviter le SPoF), installez Prometheus. Telechargement depuis github.com/prometheus/prometheus/releases, version 3.x en 2026.
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v3.0.0/prometheus-3.0.0.linux-amd64.tar.gz
tar xzf prometheus-3.0.0.linux-amd64.tar.gz
sudo mv prometheus-3.0.0.linux-amd64 /opt/prometheus
sudo useradd -rs /bin/false prometheus
sudo chown -R prometheus:prometheus /opt/prometheusSortie attendue : /opt/prometheus/prometheus –version retourne prometheus, version 3.0.0. Le repertoire contient le binaire, les exemples de config et les consoles HTML.
Etape 6 : configurer Prometheus pour scraper les VPS cibles
Editez /opt/prometheus/prometheus.yml :
global:
scrape_interval: 30s
evaluation_interval: 30s
scrape_configs:
- job_name: node
static_configs:
- targets:
- vps-dakar.internal:9100
- vps-abidjan.internal:9100
- vps-lome.internal:9100
labels:
env: productionCes targets supposent un DNS interne via WireGuard ou un fichier /etc/hosts. Pour un setup plus dynamique, file_sd_configs lit un JSON regenere par Ansible. Résultat type : apres redemarrage Prometheus, ouvrez http://votre-monitoring:9090/targets et toutes les targets doivent etre UP avec un last scrape succesful.
Etape 7 : creer l unite systemd Prometheus et demarrer
Creez /etc/systemd/system/prometheus.service avec ExecStart=/opt/prometheus/prometheus –config.file=/opt/prometheus/prometheus.yml –storage.tsdb.path=/var/lib/prometheus –storage.tsdb.retention.time=90d. Activez avec daemon-reload puis enable –now prometheus. La retention 90 jours suffit pour la plupart des analyses de tendance.
Sortie attendue : la WebUI sur le port 9090 affiche le menu Status, Targets, Rules. Tapez node_cpu_seconds_total dans le champ Expression et cliquez Execute pour voir les premieres metriques arriver. Si le champ retourne empty, le scrape n a pas encore eu lieu (attendre 30 secondes).
Etape 8 : visualiser avec Grafana et alertes
Installez Grafana sur le meme VPS de monitoring. Ajoutez Prometheus comme datasource (URL http://localhost:9090). Importez le dashboard officiel Node Exporter Full (ID 1860) qui couvre 90 pourcents des besoins : CPU, RAM, disque, reseau, IO, charge moyenne, fichiers ouverts.
Pour l alerting, declarez des regles dans /opt/prometheus/alert_rules.yml avec un Alertmanager qui pousse vers WhatsApp via Twilio, Telegram ou ntfy. Une regle classique : alert: HighCPULoad sur expr: 100 – (avg by(instance) (rate(node_cpu_seconds_total{mode= idle }[5m])) * 100) > 85, for: 10m. Cette alerte declenche apres 10 minutes de CPU au-dessus de 85 pourcents, evitant les pics ponctuels.
Etape 9 : aller plus loin et conclusion
Une fois la base en place, etendez avec : blackbox-exporter pour les sondes HTTP/TCP externes, postgres-exporter ou mysqld-exporter pour les bases de donnees, et cAdvisor pour les conteneurs Docker. La stack reste coherente, tout est scrapable par Prometheus.
Pour completer la chaine de supervision, voyez notre guide systemd timers Linux 2026 pour planifier des sauvegardes du repertoire /var/lib/prometheus, et notre comparatif Uptime Kuma vs Healthchecks vs Statping vs Gatus pour ajouter une couche de monitoring black-box vers vos sites publics.
Etape 10 : metriques cles a surveiller sur un VPS
Tous les indicateurs ne se valent pas. Pour un VPS qui sert un site WordPress ou une API Node.js, concentrez-vous sur 7 metriques essentielles. Premier groupe CPU : node_cpu_seconds_total avec mode idle inverse pour calculer l utilisation reelle. Deuxieme groupe memoire : node_memory_MemAvailable_bytes divise par node_memory_MemTotal_bytes pour le pourcentage libre. Troisieme groupe disque : node_filesystem_avail_bytes pour l espace libre par partition.
Quatrieme groupe IO disque : rate(node_disk_io_time_seconds_total[5m]) qui mesure le temps passe en IO sur 5 minutes. Cinquieme groupe reseau : rate(node_network_receive_bytes_total[5m]) et rate(node_network_transmit_bytes_total[5m]). Sixieme groupe charge : node_load1, node_load5, node_load15. Septieme groupe processus : node_processes_running pour detecter les fork bombs ou les pics anormaux.
Etape 11 : seuils d alerte realistes pour un VPS 2 GB
Sur un VPS Hostinger 2 vCPU 2 GB, les seuils suivants donnent un bon equilibre entre detection precoce et evitement du spam d alertes. CPU sustained > 80 pourcents pendant 15 minutes : warning. CPU > 95 pourcents pendant 5 minutes : critical. RAM disponible < 15 pourcents pendant 10 minutes : warning. Disque < 20 pourcents libre : warning, < 10 pourcents : critical.
Charge moyenne 5 min > nombre de vCPU multiplie par 2 : warning. Disponibilite reseau (rate de bytes a 0 alors qu attendu > 0) : critical. Processus zombies > 10 : warning. Ces seuils evitent les faux positifs lors des sauvegardes nocturnes ou des deploiements ponctuels qui peuvent saturer brievement le serveur.
Etape 12 : exporters complementaires utiles
Au-dela de node-exporter, plusieurs exporters complementaires enrichissent la vue. mysqld-exporter pour MariaDB ou MySQL : metriques connexions actives, slow queries, taille des tables. postgres-exporter pour PostgreSQL : pg_stat_database, replication lag, locks. nginx-exporter pour Nginx : requests par seconde, codes 4xx/5xx, latence p99. php-fpm-exporter pour PHP-FPM : pool busy, requete waiting, slow logs.
Chaque exporter tourne sur son port dedie (9104 mysql, 9187 postgres, 9113 nginx, 9253 php-fpm) et est ajoute comme target dans prometheus.yml avec son propre job. Cette modularite permet d enrichir le monitoring incrementalement sans tout reconfigurer.
Etape 13 : sauvegarde et retention des donnees Prometheus
Le repertoire /var/lib/prometheus contient la base TSDB. Sa taille croit lineairement avec le nombre de targets et la retention. Pour 10 VPS scrapes toutes les 30 secondes pendant 90 jours, comptez environ 5 a 10 GB. Sauvegardez avec un timer systemd nocturne qui execute prometheus snapshot puis rsync vers un storage S3-compatible (Backblaze B2 a 0.005 USD par GB par mois ou MinIO self-hosted).
Pour la retention longue (au-dela de 90 jours), evitez d augmenter la retention locale qui fait exploser le disque. Utilisez Thanos ou Mimir qui externalise vers S3 et permet la retention illimitee a cout marginal. Pour un projet freelance, 90 jours de retention locale suffisent dans 95 pourcents des cas d analyse.
Etape 14 : pieges courants et debug
Premier piege : oublier d augmenter ulimit nofiles sur le VPS de monitoring. Avec 50 targets et plusieurs exporters, Prometheus ouvre rapidement 1024 fichiers ce qui est la limite par defaut. Editer /etc/security/limits.conf avec prometheus soft nofile 65535 et prometheus hard nofile 65535 puis redemarrer le service.
Deuxieme piege : un scrape_interval trop court (5s) qui sature le CPU et inonde la TSDB. 30s a 60s est le compromis optimal pour un VPS standard. Reservez les 5s aux metriques critiques temporellement (latence API en heure de pointe par exemple) via un job separe.
Troisieme piege : ne pas tester l Alertmanager avant un vrai incident. Forcez une alerte fictive avec une expression toujours vraie (vector(1) > 0) et verifiez que la notification arrive bien sur Telegram, ntfy ou WhatsApp. C est la seule maniere de valider la chaine de bout en bout.
Etape 15 : strategie de montee en charge et conclusion
A mesure que votre flotte grandit (au-dela de 30 VPS), une seule instance Prometheus devient le goulot. Deux strategies : federation hierarchique avec un Prometheus central qui aggrege des Prometheus regionaux (un par DC ou par region), ou Thanos sidecar qui externalise vers S3 et offre une vue globale via Thanos Query. Pour un freelance qui passe d 1 client a 5 clients distincts, la federation suffit largement.
Synthese : Prometheus + node-exporter + Grafana + Alertmanager forment une stack open-source mature, eprouvee, gratuite et performante. Le ticket d entree est de 3 a 5 heures pour un setup propre, et les benefices sont permanents : visibilite operationnelle, alerte proactive, reduction des incidents non detectes. Sur un projet ouest-africain ou la qualite du service est un differentiateur fort, c est un investissement a tres haut ROI.
L observation continue d une infrastructure n est pas un luxe : c est la condition pour transformer un freelance reactif en partenaire technique proactif, capable de detecter et corriger un probleme avant que le client ne le signale, ce qui vaut bien plus que les quelques heures investies dans le setup initial.
Documentez systematiquement votre setup dans un README versionne avec les seuils, les exporters actifs, les dashboards Grafana exportes en JSON, et la procedure de restauration en cas de crash du VPS de monitoring. Sans cette documentation, votre stack devient une boite noire dependante de votre seule memoire.