Déployez Prometheus + Grafana sur Linux (Guide 2026)

Pourquoi Prometheus + Grafana reste la stack de monitoring la plus « rentable » en 2026

Il y a un truc qui revient dans toutes les équipes infra. Tout va bien. Les graphes sont plats. Les tickets sont rares. Et puis un mardi à 14 h 07, un service tombe, ou pire, il se dégrade lentement. Latence. Temps morts. Des clients qui râlent. Et là, vous réalisez que vous n’avez pas les métriques. Ou vous en avez, mais pas au bon endroit, pas avec la bonne rétention, pas avec des labels exploitables.

C’est exactement pour ça que Prometheus + Grafana reste, en 2026, la stack de monitoring la plus rentable au sens très terre à terre du terme. Pas « rentable » parce que c’est gratuit. Rentable parce que ça couvre l’essentiel, sans vous enfermer, sans vous faire exploser les coûts, et parce que vous trouvez des réponses vite.

Ce que cette stack couvre réellement :

• Prometheus : collecte et stockage des métriques en séries temporelles.
• PromQL + règles : requêtage, agrégations, alertes.
• Alertmanager : déduplication, déroute, silences, regroupement.
• Grafana : visualisation, dashboards, partage, alerting côté UI si vous l’utilisez.

En entreprise, les cas d’usage sont presque toujours les mêmes au départ : supervision serveurs Linux, VM, conteneurs, reverse proxy, bases de données, et ensuite vous montez en maturité vers SLA, SLO, erreurs, saturation, capacité.

Pourquoi c’est encore un bon choix en 2026 ? Écosystème mûr, exporters partout, intégration propre avec Kubernetes et avec les VM, communauté énorme, patterns connus. Et, détail qui compte, vous pouvez rester « simple » longtemps avant d’aller vers Thanos, Mimir, ou des setups HA.

Ce guide va livrer un déploiement reproductible, plutôt propre, avec persistance, des dashboards utiles, et des alertes basiques mais pas bruyantes. Pas une usine à gaz. Un socle.

Avant de déployer : architecture cible et prérequis (à ne pas zapper)

On clarifie l’architecture cible, sinon vous allez bricoler et refaire dans 2 semaines.

Modèle simple et efficace :

• 1 serveur de monitoring : Prometheus + Grafana + Alertmanager.
• N nœuds monitorés : Node Exporter sur chaque Linux.

Ensuite, vous rajoutez des exporters applicatifs au fil de l’eau (Nginx, PostgreSQL, Redis, etc.). Mais au début, Node Exporter, c’est le vrai point de départ.

Choisir le mode de déploiement

Deux options réalistes :

• Docker Compose (recommandé) : versioning, rollback, portabilité, config centralisée. Très bien pour infra VM, et même pour un petit cluster bare metal.
• « Bare metal » (paquets + systemd) : ça marche, mais ça demande plus de discipline sur les versions, et vous allez écrire plus de glue.

Dans ce guide, on part sur Docker Compose pour le serveur de monitoring. Et Node Exporter en systemd sur les nœuds, parce qu’en entreprise c’est souvent le plus stable et le plus standard.

Prérequis système

• Debian / Ubuntu / RHEL compatibles.
• Accès root ou sudo.
• DNS ou hostnames stables (évitez les IP qui changent).
• NTP / synchronisation horaire (chrony ou systemd-timesyncd). Les métriques avec une heure fausse, c’est la misère à diagnostiquer.

Réseau et ports à prévoir

• 9090 : Prometheus
• 3000 : Grafana
• 9093 : Alertmanager
• 9100 : node_exporter

Bonnes pratiques entreprise, et oui c’est “chiant”, mais c’est ce qui évite les sueurs froides :

• Utilisateurs dédiés quand c’est possible.
• Pare-feu : n’exposez pas Prometheus et Alertmanager à Internet.
• TLS derrière un reverse proxy.
• Sauvegardes (au moins la config et Grafana).
• Journalisation et accès contrôlés.

Option recommandée : déployer Prometheus + Grafana avec Docker Compose (propre et maintenable)

Pourquoi Compose marche si bien en infra :

• vous versionnez tout dans Git,
• vous pinnez des versions d’images,
• vous pouvez faire un rollback,
• et la config est centralisée, lisible, diffable.

Arborescence projet

Sur le serveur de monitoring :

bash sudo mkdir -p /opt/monitoring/{prometheus,alertmanager,grafana}/{config,data,provisioning} sudo mkdir -p /opt/monitoring/prometheus/rules sudo mkdir -p /opt/monitoring/grafana/provisioning/{datasources,dashboards}

On va viser trois choses : persistance Prometheus, persistance Grafana, et des fichiers de config montés en volumes.

docker-compose.yml

/opt/monitoring/docker-compose.yml

yaml services: prometheus: image: prom/prometheus:v2.55.1 container_name: prometheus user: "65534:65534" command: - "--config.file=/etc/prometheus/prometheus.yml" - "--storage.tsdb.path=/prometheus" - "--storage.tsdb.retention.time=15d" - "--web.enable-lifecycle" volumes: - ./prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml:ro - ./prometheus/rules:/etc/prometheus/rules:ro - ./prometheus/data:/prometheus ports: - "127.0.0.1:9090:9090" networks: - monnet restart: unless-stopped

alertmanager: image: prom/alertmanager:v0.28.0 container_name: alertmanager command: - "--config.file=/etc/alertmanager/alertmanager.yml" - "--storage.path=/alertmanager" volumes: - ./alertmanager/config/alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro - ./alertmanager/data:/alertmanager ports: - "127.0.0.1:9093:9093" networks: - monnet restart: unless-stopped

grafana: image: grafana/grafana:11.1.0 container_name: grafana environment: - GF_SECURITY_ADMIN_USER=admin - GF_SECURITY_ADMIN_PASSWORD=change-me-now - GF_USERS_ALLOW_SIGN_UP=false volumes: - ./grafana/data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning ports: - "127.0.0.1:3000:3000" networks: - monnet restart: unless-stopped

networks: monnet: driver: bridge

Quelques choix importants ici :

• 127.0.0.1
• latest
• docker compose down

Commandes essentielles

/opt/monitoring

bash docker compose up -d docker compose ps docker compose logs -f prometheus docker compose restart prometheus docker compose down

Stratégie d'upgrade simple : vous modifiez les tags d'images, vous relisez les notes de release, et vous redémarrez.

prometheus.yml

/opt/monitoring/prometheus/config/prometheus.yml

yaml global: scrape_interval: 15s evaluation_interval: 30s

alerting: alertmanagers: - static_configs: - targets: ["alertmanager:9093"]

rule_files: - /etc/prometheus/rules/*.yml

scrape_configs:

job_name: "prometheus" — static_configs: targets: ["prometheus:9090"], labels: env: "prod", role: "monitoring", site: "dc1"

job_name: "linux-nodes" — static_configs: targets: "linux01.example.lan:9100", "linux02.example.lan:9100", labels: env: "prod", role: "linux", site: "dc1"

Remarques utiles

• scrape_interval
• envrolesite

Découverte : ici on fait du statique (targets). Ça marche très bien sur VM et serveurs. Service discovery (Consul, SD Kubernetes, fichiers générés) existe, mais n'est pas détaillé dans ce guide — c'est l'étape suivante.

Valider et recharger

bash docker compose restart prometheus

Puis allez sur l'UI Prometheus via votre reverse proxy, ou en local :

bash curl -s http://127.0.0.1:9090/-/healthy

Ajouter Alertmanager (sans en faire une usine à gaz)

Alertmanager, c'est ce qui rend les alertes vivables : déduplication, regroupement, silences, routage. Sans ça, vous finissez avec 48 notifications identiques quand un switch tombe.

/opt/monitoring/alertmanager/config/alertmanager.yml

yaml global: resolve_timeout: 5m

route: receiver: "default" group_by: ["alertname", "env", "site"] group_wait: 30s group_interval: 5m repeat_interval: 4h

receivers: name: "default" webhook_configs: url: https://hooks.example.com/alertmanager send_resolved: true

Vous pouvez remplacer le webhook par email, Slack, Teams, peu importe. L'idée : une route simple au début.

Bonnes pratiques :

• for:
• Commencez avec des seuils progressifs : warning puis critical, pas l'inverse.
• Si ça bip trop, ce n'est pas que les gens n'aiment pas le monitoring — c'est que la règle est mauvaise.

Sécuriser l'accès : reverse proxy + authentification

Deux risques classiques à éviter : Grafana exposé en clair sur Internet, et Prometheus accessible publiquement avec vos métriques internes lisibles par n'importe qui.

Approche recommandée :

• Mettez un reverse proxy en frontal (Nginx, Traefik ou Caddy).
• Activez TLS — Let's Encrypt si vous pouvez.
• Ajoutez une authentification : basic auth au minimum, ou SSO/LDAP/OIDC si votre contexte le permet.
• 127.0.0.1

//prometheus

Installer Node Exporter sur les serveurs Linux à monitorer (le vrai point de départ)

Node Exporter donne les métriques OS : CPU, mémoire, swap, load, FS, réseau, et plein d’autres. Et c’est ce qui vous permet de répondre à 80 % des questions du quotidien.

Métriques infra typiques qui sauvent des heures :

• disque presque plein,
• iowait élevé (souvent stockage saturé ou compaction TSDB ailleurs),
• CPU saturé ou “steal” sur VM,
• erreurs réseau, drops,
• load qui grimpe sans CPU (souvent I/O).

Méthode : binaire officiel + systemd. C’est reproductible et ça se gère bien.

Installation via systemd (exemple reproductible)

Sur un nœud Linux (Debian/Ubuntu, adaptez si RHEL) :

1. Créer l’utilisateur dédié :

bash sudo useradd --system --no-create-home --shell /usr/sbin/nologin node_exporter

1. Télécharger et installer le binaire (adaptez la version) :

bash cd /tmp curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz sudo mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/ sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter sudo chmod 0755 /usr/local/bin/node_exporter

1. /etc/systemd/system/node_exporter.service

ini [Unit] Description=Prometheus Node Exporter Wants=network-online.target After=network-online.target

[Service] User=node_exporter Group=node_exporter Type=simple ExecStart=/usr/local/bin/node_exporter

Restart=on-failure RestartSec=3

NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ReadWritePaths=/run LockPersonality=true MemoryDenyWriteExecute=true RestrictRealtime=true

[Install] WantedBy=multi-user.target

Oui, un peu de hardening. Pas parfait, mais déjà mieux que “run as root”.

1. Démarrer et activer :

bash sudo systemctl daemon-reload sudo systemctl enable --now node_exporter sudo systemctl status node_exporter --no-pager

1. Ouvrir le port 9100 uniquement depuis le serveur Prometheus

UFW (exemple) :

bash sudo ufw allow from <IP_PROMETHEUS> to any port 9100 proto tcp sudo ufw deny 9100/tcp

Ou firewalld / iptables selon votre standard. L’idée reste la même : pas de 9100 ouvert au monde.

1. Vérifier :

bash curl -s http://127.0.0.1:9100/metrics | head

Déclarer les targets Node Exporter côté Prometheus

prometheus.yml

yaml

job_name: "linux-nodes" static_configs:

Groupe production

• targets: "linux01.example.lan:9100", "linux02.example.lan:9100"
• labels: env: "prod", role: "linux", site: "dc1"

Groupe staging

• targets: "staging01.example.lan:9100"
• labels: env: "staging", role: "linux", site: "dc1"

Puis :

bash docker compose restart prometheus

UPDOWN

Brancher Grafana "comme un pro" : datasource, provisioning et dashboards utiles

Accédez à Grafana (via votre reverse proxy) et faites les basiques :

• Changez le mot de passe admin.
• Créez un compte lecture seule pour partager en interne.
• Évitez de donner les droits admin à toute la boîte "juste pour regarder un graphe".

Provisioning datasource Prometheus

/opt/monitoring/grafana/provisioning/datasources/datasource.yml

yaml apiVersion: 1

datasources:

• name: Prometheus
• type: prometheus
• access: proxy
• url: http://prometheus:9090
• isDefault: true

Redémarrez Grafana :

bash docker compose restart grafana

http://prometheus:9090

Les 5 dashboards à mettre en place dès le premier jour

Vous pouvez les importer depuis Grafana.com (IDs à chercher selon versions), ou partir sur des dashboards Node Exporter "full". Ce qui compte, ce n'est pas l'ID exact, c'est la couverture.

1. Vue Linux globale — CPU, RAM, load, iowait, filesystems, réseau. Votre page d'accueil.
2. Disques — Occupation par mountpoint, inodes, et si possible une vue "tendance" (projection simple). Même sans forecast parfait, ça change la vie.
3. Réseau — Débit, erreurs, drops. Si vous avez des soucis intermittents, c'est souvent là que ça se voit.
4. Santé Prometheus — Ingestion, séries actives, temps de scrape, règles, et alertes. L'observabilité de l'observabilité, sinon vous ne voyez pas que Prometheus souffre.
5. Alerting overview — Alertes actives, silences, historique. Vous voulez un tableau de bord "on call" lisible.

Règles d'alertes Prometheus : commencer simple, éviter le bruit

Philosophie : alerter sur l'impact et la saturation, pas sur chaque micro variation. Une alerte doit déclencher une action. Si personne ne sait quoi faire quand ça sonne, c'est une mauvaise alerte.

On va ajouter des règles simples : disque, mémoire, iowait, instance down.

/opt/monitoring/prometheus/rules/linux-alerts.yml

yaml groups:

• name: linux-basics rules:
• alert: InstanceDown expr: up == 0 for: 2m labels: severity: critical annotations: summary: "instance down" description: "La cible {{ $labels.instance }} ne répond plus au scrape depuis 2 minutes."
• alert: DiskSpaceLow expr: | (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|squashfs"}) < 0.15 for: 10m labels: severity: warning annotations: summary: "espace disque faible" description: "Espace disque < 15 % sur {{ $labels.instance }} (mount : {{ $labels.mountpoint }})."
• alert: MemoryAvailableLow expr: | (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.10 for: 10m labels: severity: warning annotations: summary: "mémoire disponible faible" description: "MemAvailable < 10 % sur {{ $labels.instance }}."
• alert: CpuIowaitHigh expr: | avg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) > 0.20 for: 15m labels: severity: warning annotations: summary: "iowait élevé" description: "iowait > 20 % sur {{ $labels.instance }} depuis 15 minutes."

Rechargez Prometheus :

bash docker compose restart prometheus

Exemples PromQL compréhensibles (avec intention)

Disque (éviter tmpfs)

avail / size

promql node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|squashfs"}

Instance down

for:

promql up == 0

Charge CPU

rate()[5m]

promql rate(node_cpu_seconds_total{mode!="idle"}[5m])

Mémoire

MemAvailable

promql node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

Persistance, rétention et performance : ce qui fait (souvent) échouer Prometheus en entreprise

Les échecs classiques ne sont pas des bugs. Ce sont des pièges de design.

Le piège n°1 : la cardinalité

user_idrequest_idpath

Conséquence : RAM qui grimpe, disque qui se remplit, requêtes lentes, compactions douloureuses. Et au final, vous coupez des métriques au hasard.

Règle simple : les labels doivent représenter des dimensions stables. Environment, service, instance, cluster, zone. Pas des identifiants.

Rétention et dimensionnement disque

Vous avez déjà un paramètre dans Compose :

• --storage.tsdb.retention.time=15d

15 jours, c’est souvent un bon point de départ pour infra. Si vous voulez 90 jours, dimensionnez le disque. Ne “mettez pas 90d” juste parce que ça fait sérieux.

Compaction TSDB et impact I/O

Prometheus compacte les blocs TSDB. Ça fait de l’I/O. Si votre disque est lent, vous allez le sentir. Et si vous hébergez Prometheus sur la même VM que d’autres choses sensibles, vous allez créer des incidents… à cause du monitoring.

Étape suivante : long terme

Si vous avez besoin de long terme, multi cluster, ou requêtes globales : Thanos, Cortex, Mimir. À mentionner comme prochaine marche, pas comme prérequis.

Sauvegardes : quoi sauvegarder

À sauvegarder :

• prometheus.yml
• configs Alertmanager,
• provisioning Grafana,
• grafana/data

prometheus/data

Exploitation au quotidien : mises à jour, logs, et checks de santé

La routine hebdo qui évite les surprises :

• UP
• Erreurs de scrape : timeouts, 500, certificats, latence.
• Disque : Prometheus remplit il son volume ?
• Temps de scrape : si ça grimpe, c’est souvent un signal de charge.

Mises à jour :

• testez en préprod si vous pouvez,
• pin des versions Docker,
• lisez les notes de release, surtout Grafana.

Observabilité de l’observabilité :

• Prometheus scrape Prometheus (déjà fait),
• Grafana expose des métriques (optionnel),
• Alertmanager aussi.

Logs :

• docker compose logs -f prometheus
• docker compose logs -f grafana
• journalctl -u node_exporter -f

Ce que vous cherchez : timeouts, “bad config”, OOM, erreurs de permission sur volumes, compactions qui prennent trop de temps.

Gestion des accès Grafana :

• rôles (Admin, Editor, Viewer),
• tokens API si vous automatisez,
• partage en lecture seule, et évitez l’édition ouverte.

Conclusion : une stack prête pour la prod (et les prochaines étapes)

Récap, parce que c’est ça qu’on veut au final :

• Prometheus collecte et stocke.
• Node Exporter alimente en métriques OS.
• Grafana visualise et rend ça lisible.
• Alertmanager notifie, proprement, sans spam.

Ce que vous avez maintenant : un déploiement reproductible, persistant, plus sécurisé (reverse proxy, ports internes), avec des dashboards de base et des alertes qui évitent le bruit.

Prochaines étapes naturelles :

• exporters applicatifs : Nginx, PostgreSQL, Redis, JVM, etc.
• SSO/LDAP/OIDC dans Grafana si vous êtes en contexte entreprise.
• haute dispo si votre monitoring devient critique.
• stockage long terme via Thanos ou Mimir si vous devez garder des mois.

Et si vous voulez que ça tienne dans le temps : standardisez. Un repo Git, un Compose propre, des variables, une petite CI qui valide la syntaxe, et vous étendez progressivement. Pas plus. Pas moins.

Questions fréquemment posées

Pourquoi Prometheus + Grafana est-il considéré comme la stack de monitoring la plus rentable en 2026 ?

Prometheus + Grafana reste la stack de monitoring la plus rentable en 2026 car elle couvre l'essentiel des besoins sans coûts excessifs, offre une grande flexibilité sans enfermement, permet de trouver rapidement des réponses grâce à un écosystème mature et une intégration propre avec Kubernetes et les VM. Ce n’est pas seulement parce que c’est gratuit, mais parce que cette solution est efficace, évolutive et adaptée aux besoins réels des équipes infra.

Quels sont les composants clés de la stack Prometheus + Grafana et leurs rôles respectifs ?

La stack comprend : Prometheus pour la collecte et le stockage des métriques en séries temporelles ; PromQL et règles pour le requêtage, les agrégations et les alertes ; Alertmanager pour la déduplication, le routage, les silences et le regroupement des alertes ; Grafana pour la visualisation, les dashboards, le partage et l'alerting côté interface utilisateur.

Quel modèle d'architecture cible est recommandé avant de déployer Prometheus + Grafana ?

Le modèle simple conseillé est un serveur de monitoring unique hébergeant Prometheus, Grafana et Alertmanager, avec N nœuds monitorés via Node Exporter sur chaque machine Linux. Les exporters applicatifs comme Nginx ou PostgreSQL peuvent être ajoutés progressivement selon les besoins.

Quelles sont les options recommandées pour déployer Prometheus + Grafana en entreprise ?

Deux options réalistes : Docker Compose (recommandé) pour sa portabilité, versioning, rollback facile et configuration centralisée — idéal pour VM ou petits clusters bare metal ; ou une installation « bare metal » via paquets et systemd qui demande plus de discipline sur les versions mais reste possible. Le guide privilégie Docker Compose pour le serveur de monitoring et systemd pour Node Exporter sur les nœuds.

Quels prérequis système et réseau faut-il respecter avant d’installer cette stack ?

Les prérequis incluent un système Debian/Ubuntu/RHEL compatible, accès root ou sudo, DNS ou hostnames stables (éviter IP dynamiques), synchronisation horaire via NTP (chrony ou systemd-timesyncd). Côté réseau, prévoir l'ouverture des ports 9090 (Prometheus), 3000 (Grafana), 9093 (Alertmanager) et 9100 (Node Exporter).

Quelles bonnes pratiques sécurité sont recommandées lors du déploiement ?

Il est conseillé d'utiliser des utilisateurs dédiés quand c’est possible, ne pas exposer Prometheus ni Alertmanager directement à Internet via un pare-feu, mettre en place TLS derrière un reverse proxy, assurer des sauvegardes régulières des configurations et données Grafana ainsi qu’une journalisation rigoureuse avec contrôle d’accès.