Quatre programmes, un seul mot : « monitoring »
« Mettre en place le monitoring », voilà la demande. Derrière se cachent au moins trois programmes distincts que l'on confond régulièrement. node_exporter expose les métriques d'une machine sur un port HTTP — il mesure, il ne stocke pas. Prometheus scrape ce port à intervalle régulier et stocke les séries temporelles — il collecte, il ne dessine pas. Grafana interroge Prometheus et rend les graphes — il dessine, il ne stocke rien qui lui soit propre et qu'on regretterait de perdre. Ratez qui fait quoi et vous finissez à déboguer Grafana pour un trou causé par Prometheus, ou à attendre de node_exporter un historique qu'il n'a jamais eu.
La thèse est donc ennuyeuse et porteuse : la stack est facile à installer et facile à laisser grande ouverte, et l'histoire de sécurité se résume presque entièrement à quels ports font face au monde et à quel mot de passe par défaut vous avez oublié de changer. Les graphes sont la partie amusante. Les adresses d'écoute sont la partie qui compte.
Avant de commencer : qu'est-ce qui écoute déjà ?
Chaque brique de cette stack veut un port bien connu, et un serveur chargé en a peut-être déjà pris un. Les collisions ici ne sont pas subtiles — un service qui ne peut pas se lier à son port ne démarre tout simplement pas — mais elles s'évitent en regardant d'abord.
- Le 9100 de node_exporter —
ss -tlnH 'sport = :9100'. Si quelque chose y répond déjà, un exporter tourne probablement déjà, et un second n'est que du bruit. - Le 9090 de Prometheus et le 3000 de Grafana — les deux que vous atteindrez réellement. Le 3000 de Grafana est un port populaire ; un serveur de dev ou une autre app peut le détenir.
- Est-ce que tout ou partie est déjà installé ? Un Prometheus à moitié configuré d'une tentative précédente vaut la peine d'être trouvé avant d'écrire un second fichier de config qui le combat.
Il y a deux façons honnêtes de faire tourner cette stack, et la bonne dépend de la machine. Les paquets natifs — Grafana depuis son dépôt, Prometheus et node_exporter en services systemd — sont les plus transparents et survivent proprement aux redémarrages. Une stack Docker Compose met les trois plus le câblage dans un seul fichier, plus rapide à monter et à démonter. Aucune n'est fausse ; ce qui compte, c'est de savoir laquelle vous avez choisie, parce que le jour où vous la déboguerez, il faut savoir s'il faut lire un fichier d'unité ou un fichier compose.
1. node_exporter : la chose mesurée
Commencez par le bas. node_exporter est un petit binaire qui lit la vue qu'a le noyau de la machine — CPU, mémoire, disque, réseau, charge — et l'expose en texte sur le port 9100. Il ne garde aucun historique ; il répond « qu'est-ce qui est vrai à l'instant » à chaque scrape. Installez le binaire, faites-le tourner sous un utilisateur dédié non privilégié dans un service systemd, et prouvez-le avec la seule vérification qui compte : quelque chose écoute sur 9100. Une chaîne de version ne suffit pas ; un socket en écoute, oui.
Et voici la première décision d'exposition. Le point d'accès de node_exporter en révèle beaucoup sur une machine. Il n'a aucune authentification propre, il ne devrait donc être joignable que par Prometheus et rien d'autre — lié à une interface privée, ou filtré par pare-feu vers l'adresse du collecteur. Un exporter ouvert sur Internet est un flux de reconnaissance gratuit pour quiconque le trouve.
2. Prometheus : la chose qui collecte
Prometheus est la mémoire de la stack. À intervalle régulier, il scrape chaque cible listée — node_exporter ici, mais aussi des métriques d'application, cAdvisor pour les conteneurs, tout ce qui parle le format — et stocke les séries sur disque. Sa configuration est une liste de cibles de scrape et d'intervalles, et sa vérification n'est pas « le service est actif » mais « le service est prêt » : curl -sf http://localhost:9090/-/ready qui rend un 200 signifie que Prometheus a chargé sa config et scrape réellement, une affirmation plus forte qu'une unité verte.
L'interface web de Prometheus sur 9090 est utile et complètement non authentifiée. Traitez le 9090 comme le 9100 : liez-le au loopback, atteignez-le via un proxy qui vérifie qui vous êtes, et ne le publiez jamais brut. Les métriques qu'il détient sont une carte de votre infrastructure, et l'interface de requête dessinera volontiers cette carte pour quiconque peut charger la page.
3. Grafana : la chose qui dessine — et son unique défaut dangereux
Grafana est la partie que tout le monde voulait vraiment : les dashboards, sur le port 3000, interrogeant Prometheus comme source de données. L'installer et confirmer qu'il répond — un curl sur /api/health qui rend 200 — est la partie facile. La partie qui compte tient en une phrase :
Grafana est livré avec l'identifiant admin / admin, et tant que vous ne l'avez pas changé, votre stack de monitoring est modifiable par quiconque atteint le port. Ce n'est pas un risque théorique. Les instances Grafana à identifiants par défaut sont trouvées et prises en main régulièrement, et un outil de dashboards avec une source de données configurée est une console de requête sur votre Prometheus. Changez le mot de passe admin à la première connexion, avant toute autre chose, et vérifiez que vous l'avez fait — un système de monitoring que vous ne contrôlez pas est pire que rien, parce qu'il vous ment avec autorité.
4. Câbler l'ensemble, et là où les fils ne doivent pas atteindre
Une stack Compose fait de l'assemblage un seul fichier : Prometheus scrapant node_exporter, Grafana pointé sur Prometheus, les trois sur un réseau privé avec seul le port de Grafana exposé — et même celui-ci derrière un reverse proxy avec TLS s'il fait face à autre chose que localhost. La vérification que la stack est réelle n'est pas trois contrôles « active » séparés ; c'est Grafana qui répond à /api/health et un dashboard qui rend réellement une métrique née dans node_exporter, ce qui prouve toute la chaîne de bout en bout.
Pour les logs plutôt que les métriques, la même forme se répète une couche au-dessus : Loki stocke, un agent expédie (Grafana Alloy maintenant que Promtail est en fin de vie), et Grafana dessine. Les règles d'exposition sont identiques — lier en privé, proxifier avec auth, changer chaque défaut — parce qu'un agrégateur de logs ouvert sur le monde fuit plus qu'un de métriques.
Ce que cette stack ne fait pas
Monter Prometheus et Grafana vous donne de la visibilité, pas de la fiabilité. Cela n'alerte personne — c'est le travail d'Alertmanager, et une alerte sans routage est un graphe que personne ne regarde à trois heures du matin. Cela ne décide pas ce qui est normal ; les seuils et l'hystérésis qui empêche un simple soubresaut de crier au loup sont à vous de régler. Cela ne se surveille pas soi-même — un Prometheus qui meurt cesse d'enregistrer la panne qu'il aurait dû attraper. Et ce n'est pas gratuit : la rétention, c'est du disque, le scraping, c'est de la charge, et un dashboard par métrique est une façon de ne rien voir en se noyant dans tout. L'observabilité est une pratique, pas une installation.
La vérification qui le prouve
Dans l'ordre : un socket en écoute sur 9100 pour l'exporter ; /-/ready sur 9090 pour un Prometheus qui scrape réellement ; /api/health sur 3000 pour Grafana ; un mot de passe admin confirmé non par défaut ; ss -tlpn pour prouver que 9100 et 9090 ne font pas face à Internet et que seule la porte de Grafana — proxifiée et authentifiée — le fait ; et, la vraie preuve, un panneau de dashboard qui dessine une valeur vivante ayant voyagé exporter → Prometheus → Grafana.
Ce que Servor apporte là-dedans
Servor livre chaque brique et toute la stack Compose comme des recettes — parmi 150+ playbooks vérifiés — et la forme d'une recette est ce qui empêche « mettre en place le monitoring » de laisser en douce trois ports non authentifiés ouverts. Une recette n'est pas un script tiré à l'aveugle : elle commence par la reconnaissance, en vérifiant si 9100, 9090 et 3000 sont libres et si quoi que ce soit est déjà installé, pour s'adapter à la vraie machine. Chaque étape porte sa propre vérification — le socket en écoute, le 200 sur /-/ready, le 200 sur /api/health — si bien que le run prouve la chaîne, pas seulement les paquets. Le playbook est idempotent : un exporter ou un Prometheus existant est vérifié et rapporté, pas empilé par-dessus. Et les guardrails sont explicites sur les défauts qui mordent — changer le admin/admin de Grafana, garder les ports internes hors de 0.0.0.0, mettre un proxy TLS devant tout ce qui est public.
Une stack auto-hébergée observe l'intérieur d'une machine en détail fin. Elle ne vous dit pas, à elle seule, que la machine est joignable depuis l'extérieur, que son certificat est sur le point d'expirer, ou que SSH a cessé de répondre — c'est le rôle des monitors propres à Servor, depuis un autre point de vue, avec l'hystérésis configurable qui empêche un paquet perdu de réveiller qui que ce soit. Faire tourner les deux n'est pas redondant ; ils voient des pannes différentes. Garder cette seconde couche assez silencieuse pour valoir la peine d'être écoutée fait l'objet de l'article sur le bruit d'alerte, et le tableau d'exploitation plus large vit dans notre présentation du monitoring.
Quelle que soit la recette qui l'installe, l'exécution reste sur le chemin zero-knowledge : chaque commande est signée dans votre navigateur avec une clé dérivée de votre clé de vault, relayée verbatim, et vérifiée par l'agent sur la machine avant de s'exécuter — la même discipline décrite dans l'article Plan-Execute-Verify.