⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Le Contexte : Pourquoi se Lancer dans le Monitoring ?

Dans le cadre de ma formation d’administrateur système et réseau avec spécialisation cybersécurité, le monitoring s’impose comme une compétence essentielle. Impossible de détecter une intrusion, une anomalie ou un problème de performance sans une surveillance adéquate de son infrastructure.

Après quelques recherches, Prometheus + Grafana s’est imposé comme le standard de facto pour le monitoring moderne. Utilisé par Netflix, Spotify, et la plupart des entreprises tech, ce combo offre une solution open-source, scalable et professionnelle.

Mon objectif : Mettre en place une stack de monitoring sur un Mac Pro (via Docker) qui servira de “tour de contrôle”, puis étendre progressivement cette surveillance à mes machines Proxmox, mon NAS Synology, et mon routeur pfSense.

Étape 1 : Installation de Docker Desktop

L’installation de Docker Desktop sur macOS s’est déroulée sans difficulté particulière. Après le téléchargement et l’installation classique, les vérifications de base confirment le bon fonctionnement :

1
2

docker --version
docker run hello-world

Docker est opérationnel et prêt à héberger notre infrastructure de monitoring.

Étape 2 : Déploiement de Prometheus et Grafana

Le déploiement s’effectue via Docker Compose, qui permet de définir et gérer des applications multi-conteneurs. Le fichier docker-compose.yml configure :

  • Prometheus : serveur de métriques écoutant sur le port 9090
  • Grafana : interface de visualisation sur le port 3000
  • Volumes persistants : pour conserver les données entre les redémarrages
  • Réseau isolé : pour la communication entre conteneurs

Le fichier de configuration prometheus.yml définit les cibles à surveiller (targets) et les paramètres de collecte.

1

docker compose up -d

Les deux conteneurs démarrent correctement. Prometheus est accessible via http://localhost:9090 et Grafana via http://localhost:3000 (identifiants par défaut : admin/admin123).

La connexion entre Grafana et Prometheus se configure via l’interface Grafana, en ajoutant Prometheus comme data source avec l’URL http://prometheus:9090. Un dashboard communautaire (“Prometheus 2.0 Overview”) permet de vérifier rapidement que la stack fonctionne et que les métriques de base de Prometheus lui-même sont collectées.

Étape 3 : Node Exporter et la Découverte d’une Limitation Majeure

Pour surveiller les métriques système du Mac (CPU, RAM, disque, réseau), l’installation d’un “exporter” est nécessaire. Node Exporter est l’outil standard qui lit ces métriques et les expose dans un format compatible Prometheus.

L’ajout initial d’un service node-exporter dans le docker-compose.yml semblait être la solution logique. Après redémarrage de la stack et configuration de Prometheus pour scraper ce nouvel exporter, les premières observations dans Grafana révèlent un problème inattendu :

  • 4 cœurs CPU détectés au lieu des 14 cœurs du M4 Pro
  • 16 Go de RAM affichés au lieu des 64 Go disponibles

Analyse : Docker Desktop et la Virtualisation sur macOS

La cause de cette discordance réside dans l’architecture même de Docker Desktop sur macOS (et Windows) :

Sur Linux, Docker partage le noyau de l’hôte et accède directement aux ressources système.

Sur macOS, Docker Desktop crée une machine virtuelle Linux légère dans laquelle tournent tous les conteneurs. Cette VM dispose de ressources allouées via les paramètres de Docker Desktop.

Dans ma configuration, j’avais précisément alloué 4 cœurs et 16 Go de RAM à Docker. Node Exporter, fonctionnant dans un conteneur de cette VM, ne pouvait donc voir que ces ressources limitées, et non celles du Mac hôte.

Conclusion technique : Sur macOS et Windows, un exporter en conteneur Docker ne peut pas accéder aux véritables métriques système de la machine hôte.

Étape 4 : Installation Native de Node Exporter

La solution consiste à installer Node Exporter directement sur macOS, en dehors de Docker.

Installation via Homebrew

1
2

brew install node_exporter
brew services start node_exporter

Node Exporter s’exécute maintenant en tant que service natif macOS et a accès aux véritables ressources système.

Configuration de Prometheus

Le fichier prometheus.yml doit être modifié pour que Prometheus interroge l’exporter natif plutôt que celui dans Docker :

1
2
3
4
5
6
7
8

- job_name: 'mac-m4-pro'
  static_configs:
    - targets: ['host.docker.internal:9100']
      labels:
        hostname: 'mac-m4-pro'
        os: 'macos'
        location: 'homelab'
        role: 'workstation'

Note technique : host.docker.internal est une adresse DNS spéciale fournie par Docker Desktop qui résout vers l’hôte. Cela permet aux conteneurs Docker d’accéder aux services tournant directement sur macOS.

Le service node-exporter a été supprimé du docker-compose.yml puisqu’il n’est plus nécessaire.

Après rechargement de la configuration Prometheus, les métriques collectées reflètent maintenant correctement les ressources du Mac : 14 cœurs CPU et 64 Go de RAM.

Étape 5 : Compatibilité des Dashboards Grafana

Une fois les métriques correctement collectées, l’import de dashboards Grafana communautaires a révélé un second problème : l’incompatibilité des noms de métriques entre Linux et macOS.

Le Problème : Nommage des Métriques

La majorité des dashboards Grafana disponibles sont conçus pour des systèmes Linux. Node Exporter utilise des noms de métriques différents selon le système d’exploitation :

Métrique LinuxMétrique macOS
node_memory_MemTotal_bytesnode_memory_total_bytes
node_memory_MemAvailable_bytesnode_memory_free_bytes + node_memory_inactive_bytes
node_memory_MemFree_bytesnode_memory_free_bytes

Résultat : les dashboards cherchent des métriques qui n’existent pas sur macOS, provoquant l’affichage de “No data” dans de nombreux panels.

Solution : Adaptation des Requêtes PromQL

Il est nécessaire d’adapter manuellement les requêtes PromQL pour qu’elles correspondent aux métriques macOS. Par exemple, pour calculer l’usage mémoire :

Requête Linux (ne fonctionne pas sur macOS) :

1

(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

Requête macOS (adaptée) :

1

((node_memory_active_bytes + node_memory_wired_bytes) / node_memory_total_bytes) * 100

Cette adaptation permet d’obtenir des visualisations fonctionnelles, même si elle nécessite un travail manuel de modification des dashboards existants.

État Actuel de l’Infrastructure

Après cette première phase d’installation et de résolution de problèmes, l’infrastructure de monitoring est fonctionnelle avec les composants suivants :

  • Docker Desktop : configuré avec 4 cœurs et 8 Go de RAM alloués
  • Prometheus : déployé en conteneur Docker, collecte les métriques sur le port 9090
  • Grafana : déployé en conteneur Docker, interface de visualisation sur le port 3000
  • Node Exporter : installé nativement sur macOS, expose les métriques système réelles
  • Dashboards Grafana : nécessitent des adaptations manuelles pour la compatibilité macOS

Enseignements Techniques

Cette première expérience a permis de comprendre plusieurs points importants :

  1. Architecture Docker sur macOS : la virtualisation inhérente à Docker Desktop impose des contraintes spécifiques pour le monitoring système
  2. Nommage des métriques : Node Exporter génère des noms de métriques différents selon l’OS, impactant la portabilité des dashboards
  3. Installation native nécessaire : sur macOS et Windows, les exporters de métriques système doivent être installés en dehors de Docker
  4. Environnement Linux différent : sur les futures machines Proxmox (Linux), Node Exporter pourra fonctionner directement en conteneur Docker sans ces limitations

Prochaines Étapes du Projet

L’infrastructure de base étant désormais opérationnelle, les développements futurs incluront :

  1. Création de dashboards personnalisés adaptés aux spécificités macOS
  2. Déploiement d’exporters additionnels :
    • cAdvisor pour le monitoring Docker
    • Blackbox Exporter pour la surveillance réseau
    • Exporters spécifiques pour les services critiques
  3. Extension aux machines Proxmox où Node Exporter fonctionnera en conteneur
  4. Configuration d’Alertmanager pour les notifications automatiques
  5. Intégration du NAS Synology et du routeur pfSense au système de monitoring

L’objectif à terme est de disposer d’une vue centralisée complète de l’infrastructure du homelab.

Conclusion

Ce premier déploiement de Prometheus et Grafana a permis de mettre en évidence une particularité importante de Docker Desktop sur macOS : la virtualisation sous-jacente limite l’accès direct aux ressources système de l’hôte. Cette contrainte architecturale impose l’installation native des exporters de métriques système sur macOS et Windows.

Point Clé à Retenir

Sur macOS/Windows : les outils de monitoring système doivent être installés nativement, en dehors de Docker. Sur Linux : ces mêmes outils peuvent fonctionner efficacement dans des conteneurs Docker.

Cette différence fondamentale est essentielle à comprendre lors de la mise en place d’une infrastructure de monitoring multi-plateforme. Pour mon homelab, cela signifie une approche hybride : exporter natif sur le Mac de contrôle, exporters conteneurisés sur les serveurs Proxmox Linux.

L’infrastructure de base est maintenant opérationnelle et prête à être étendue au reste des équipements du homelab.

La suite : Créer mon premier tableau de bord sous Grafana avec mes indicateurs personnels. Ça va me rappeler de bons souvenirs avec Power BI.

Ressources Techniques :