Les métriques au niveau de l’hôte (CPU, mémoire, disque, réseau) et les métriques par conteneur proviennent de deux exporters différents. Ce guide exécute Prometheus aux côtés des deux avec Docker Compose, configure Prometheus pour les scraper, et confirme que tout fonctionne avant de confier les données à un tableau de bord dans le guide suivant.

Les trois éléments

• Prometheus lui-même : scrape les cibles selon un calendrier et stocke les résultats.
• node_exporter : expose les métriques propres du système d’exploitation de l’hôte (CPU, mémoire, disque, réseau) sur /metrics, port 9100.
• cAdvisor (Container Advisor, maintenu par Google) : expose l’utilisation des ressources par conteneur (CPU, mémoire, E/S) sur /metrics, port 8080.

Les deux exporters ont besoin d’une visibilité sur des éléments qu’un conteneur ordinaire ne peut pas voir : node_exporter a besoin du système de fichiers racine et du namespace de processus de l’hôte pour rapporter correctement sur l’hôte, et pas seulement sur son propre conteneur, et cAdvisor a besoin d’accéder aux données propres du runtime de conteneurs pour rapporter sur chaque conteneur exécuté sur l’hôte, et pas seulement sur lui-même.

Docker Compose pour les trois

version: "3"

volumes:
  prometheus-data:

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.retention.time=15d"

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    pid: host
    volumes:
      - /:/host:ro,rslave
    command:
      - "--path.rootfs=/host"

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

L’option pid: host de node-exporter et le montage en lecture seule de la racine sont ce qui lui permet de rapporter sur l’hôte plutôt que sur la vue isolée de son propre conteneur ; --path.rootfs=/host lui indique où cette racine montée se trouve réellement dans le conteneur. cadvisor a besoin de son propre ensemble de montages en lecture seule vers l’état d’exécution de l’hôte pour la même raison : sans eux, il ne peut voir que lui-même, pas les autres conteneurs de l’hôte. Rien ici n’a besoin d’un accès en écriture à l’hôte, tous les montages sont en lecture seule, ce qui mérite d’être gardé en tête si une revue de sécurité demande ce que ces conteneurs peuvent réellement faire.

Configurer Prometheus pour scraper les deux

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "cadvisor"
    static_configs:
      - targets: ["cadvisor:8080"]

global.scrape_interval n’est pas la valeur par défaut intégrée de Prometheus (qui est d’une minute) ; la définir explicitement à 15 secondes, comme le font la plupart des exemples de prise en main, est une convention à suivre, car c’est assez fréquent pour donner des tableaux de bord réactifs sans générer un volume de scraping excessif. Chaque job_name est une étiquette arbitraire que vous choisissez, attachée à chaque série que ce job scrape ; c’est ainsi que vous distinguerez plus tard, dans une requête, « cette métrique vient de node-exporter » de « cette métrique vient de cadvisor ». Les cibles sont adressées par leur nom de service Compose (node-exporter, cadvisor) car les conteneurs d’un même réseau Compose se résolvent mutuellement par nom de service automatiquement ; il n’y a besoin ni d’adresses IP de conteneurs ni de localhost ici.

Démarrer et confirmer que les cibles sont saines

docker compose up -d

Ouvrez http://localhost:9090/targets dans un navigateur. Chaque job configuré devrait apparaître comme UP. Si l’un d’eux ne l’est pas, vérifiez d’abord les logs de ce conteneur, et confirmez que vous pouvez joindre directement son endpoint /metrics (curl http://localhost:9100/metrics depuis l’hôte, ou docker exec dans le conteneur Prometheus puis curl sur le nom de service Compose de la cible) avant de supposer que le problème vient de la configuration de Prometheus plutôt que de la cible elle-même.

Depuis la page Graph de Prometheus, essayez une vérification rapide :

up{job="node-exporter"}

up est une métrique synthétique que Prometheus génère lui-même pour chaque cible : 1 si le dernier scrape a réussi, 0 sinon, ce qui en fait un moyen rapide de vérifier la santé d’une cible directement via PromQL plutôt que via la page Targets.

Une remarque avant d’aller plus loin

Ni l’interface de Prometheus ni celle de cAdvisor ne sont livrées avec une authentification ou TLS par défaut. C’est un comportement par défaut raisonnable pour quelque chose destiné à être scrapé et interrogé depuis un réseau de confiance, mais cela signifie que ces ports ne devraient pas être exposés directement sur l’Internet public sans ajouter un contrôle d’accès, que ce soit un reverse proxy avec authentification devant eux, ou simplement en ne les rendant accessibles que depuis un réseau interne dès le départ.

Avec les deux exporters qui rapportent à Prometheus, le guide suivant explique comment en faire un véritable tableau de bord avec Grafana.