Tout commence par une frustration simple : pourquoi est-ce qu'il faut envoyer ses données système à un serveur américain pour savoir si son CPU dépasse 80% ? La question paraît naïve. Elle est en réalité fondamentale.
Xytherion Monitoring est né de cette contradiction — et de la conviction que le monitoring serveur peut être à la fois simple, puissant et entièrement privé. Voici comment on l'a construit.
Le point de départ : un binaire, une promesse
La décision la plus importante prise dès le premier jour : tout dans un seul binaire Go. Pas de base de données à déployer, pas de YAML à apprendre, pas de stack de quatre outils à maintenir. On installe, on lance, ça fonctionne.
Ce choix architectural a des conséquences en cascade. Go compile en statique — le binaire embarque toutes ses dépendances. Il tourne sur macOS arm64, macOS amd64, Linux arm64, Linux amd64. Une seule base de code, quatre cibles. Aucune surprise à l'installation.
Un outil qui demande trois heures de configuration avant de devenir utile n'est pas un outil — c'est un projet à part entière.
— Philosophie Xytherion
L'architecture : SSE plutôt que WebSocket
Le choix du protocole de streaming a été l'un des plus débattus. WebSocket offre une communication bidirectionnelle, mais cette complexité n'apporte rien ici : le dashboard n'a pas besoin d'envoyer des données à l'agent, il a juste besoin de recevoir en continu.
Les Server-Sent Events (SSE) résolvent exactement ce problème avec une élégance redoutable : une connexion HTTP longue, un flux de données unidirectionnel, une reconnexion automatique en cas de coupure. Pas de protocole d'upgrade, pas de handshake complexe. Le dashboard se connecte à http://IP:9001/stream et reçoit les métriques toutes les secondes.
La collecte de métriques : lire le noyau directement
Plutôt que d'utiliser des bibliothèques tierces, l'agent lit directement les fichiers virtuels exposés par le noyau Linux : /proc/stat pour le CPU, /proc/meminfo pour la RAM, /proc/diskstats pour le disque.
Sur macOS, on passe par les syscalls host_statistics64 et sysctlbyname. Cette approche directe garantit une consommation de ressources minimale — l'agent lui-même utilise moins de 10 Mo de RAM.
L'agent Xytherion consomme en permanence moins de 0,3% de CPU sur une machine à charge normale. Il ne perturbe pas ce qu'il surveille.
Les technologies exclusives
Fingerprint de processus (z-score)
Chaque processus a un comportement habituel. nginx consomme en moyenne 1.2% de CPU avec un écart-type de 0.4%. Si ce chiffre monte à 8%, quelque chose d'inhabituel se passe. Le Fingerprint calcule le z-score de chaque processus en continu sur une fenêtre glissante de 60 secondes et émet un badge visuel dès qu'il dépasse 2 écarts-types.
Drain Score et prédictions
Toutes les 30 secondes, une régression linéaire (méthode des moindres carrés) est exécutée sur les 3 600 derniers points de RAM et CPU. Le résultat : une pente en %/heure et une ETA de saturation. "RAM saturée dans 4h 12min" — une information, pas une alarme.
Time Capsule
Un snapshot complet de l'état du serveur peut être capturé à tout moment via l'API. Le diff capsule→état actuel montre précisément ce qui a changé : processus apparus ou disparus, deltas de métriques, changements de configuration. L'intégration CI/CD est immédiate.
Le Medikit : la sécurité intégrée
La décision d'intégrer un scanner de sécurité directement dans l'agent Go plutôt que de le laisser comme un outil séparé a été l'une des plus structurantes. Le Medikit orchestre sept moteurs d'audit — trois natifs Go (intégrité de fichiers, audit cron, audit réseau) et quatre outils externes optionnels (rkhunter, chkrootkit, ClamAV, Lynis).
Le résultat est un score de sécurité sur 100, des findings classés par sévérité avec des pénalités différenciées, et un système de remédiation (quarantaine ou liste blanche) accessible depuis le dashboard. Pas de configuration, pas d'installation supplémentaire pour le noyau — tout est dans le binaire.
Ce qui vient
La feuille de route de Xytherion Monitoring s'articule autour de trois axes. D'abord, l'observabilité des applications : monitoring des logs applicatifs en plus des métriques système. Ensuite, le clustering : une vue agrégée d'un parc de dizaines de machines avec alertes consolidées. Enfin, l'API ouverte : permettre à des outils tiers de consommer les métriques Xytherion sans passer par le dashboard.
Xytherion Monitoring est open source sous licence MIT. Contributions et retours bienvenus sur GitHub — OpenDojoSystems0/xytherion-core.