Moniteur système Linux
SupKrellM
Moniteur système pour Linux écrit en Python pur : il collecte les métriques de la machine (processeur, mémoire, disques, températures, réseau, processus), en lisant directement les fichiers que le noyau expose, et les restitue en rapport HTML autonome ou en tableau de bord temps réel.
Le projet
Les outils de surveillance classiques supposent d'installer des paquets, ce qui n'est pas toujours possible sur un serveur verrouillé ou une machine minimale. Le besoin : savoir dans quel état est une machine Linux sans rien installer dessus, et pouvoir en extraire un rapport partageable (un seul fichier HTML, ouvrable n'importe où, sans serveur).
D'où la contrainte que nous nous sommes imposée : n'utiliser que la bibliothèque standard de Python et aller chercher l'information à la source, là où le noyau la publie.
J'ai repris le projet seul après le rendu, hors cadre scolaire, sous le nom AEGIS Systems, avancé à environ 70 %. Cette version change la nature de l'outil : là où SupKrellM produit un état des lieux quand on le lance, AEGIS démarre automatiquement et envoie des alertes dès qu'une métrique sort de la normale. On passe d'un outil d'observation à un service de surveillance.
Fonctionnalités
- Collecte complète sans aucune dépendance : mémoire, disques, températures, batterie, interfaces réseau, dix processus les plus gourmands
- Rapport HTML autonome : styles et scripts intégrés au fichier, données injectées par un moteur de gabarit maison ; un fichier unique, transportable par courriel ou clé USB
- Tableau de bord temps réel, rafraîchi chaque seconde, avec mise à jour en place des valeurs pour éviter tout clignotement
- Détection des services web à l'écoute, en lisant les tables de connexions du noyau plutôt qu'en appelant un outil externe
Les difficultés rencontrées
Pour détecter les services web sans dépendance, nous lisons directement la table des connexions du noyau. Les adresses y figurent en hexadécimal brut, et ma première conversion donnait des adresses absurdes : 127.0.0.1 ressortait en 1.0.0.127. En comparant plusieurs lignes avec la sortie d'un outil de référence, j'ai compris que le noyau écrit ces champs tels qu'ils sont en mémoire, sans les normaliser : l'adresse est stockée dans l'ordre d'octets du processeur, qui est inversé sur nos machines, tandis que le numéro de port suit la convention réseau, dans l'ordre naturel. Les deux moitiés du même champ ne suivent donc pas la même règle, ce qui explique qu'une lecture naïve de gauche à droite fonctionnait pour le port et échouait pour l'adresse. La correction consistait à découper la chaîne en octets et à les relire à l'envers pour l'adresse seulement. Ce qui compte ici : je n'ai pas contourné le problème en ajoutant une dépendance, je suis remonté à la représentation réelle de la donnée en mémoire. C'est un bug qui ne produit aucune erreur (juste une valeur fausse), donc introuvable en cherchant un message d'erreur.
Le calcul de la charge processeur par processus donne un temps cumulé depuis le démarrage du processus : le rapporter à la durée de fonctionnement de la machine produit une moyenne historique, pas la charge instantanée. Les outils de référence procèdent autrement, en comparant deux mesures espacées dans le temps. J'ai identifié l'écart, mesuré ce qu'il coûterait de le corriger (conserver un état entre deux passes, alors que le rapport HTML est une opération unique), et j'ai assumé la simplification en la documentant explicitement, plutôt que de laisser croire à une mesure exacte.
Ce que j'en ai retiré
- Une compréhension concrète de la frontière entre le noyau et les programmes sous Linux : ces fichiers système ne sont pas des fichiers, ce sont des vues sur les structures internes du noyau. Le savoir change la façon de diagnostiquer une machine.
- La dégradation progressive comme décision d'architecture : chaque lecture est isolée et retombe sur une valeur neutre. Une machine sans batterie ou sans capteur thermique produit un rapport partiel, jamais une erreur fatale.
- « Sans dépendance » est un vrai choix d'ingénierie, avec un prix : nous avons gagné en portabilité et en compréhension, perdu en précision sur la mesure du processeur. Savoir nommer ce compromis vaut mieux que de l'avoir évité.
- Séparer la collecte de la présentation paie : la couche de mesure ignore tout du HTML comme de l'interface graphique, et c'est ce qui a permis de brancher deux interfaces très différentes sur exactement la même source.