Alors que les solutions de monitoring serveur deviennent toujours plus complexes et dépendantes de stacks lourdes, deux projets open source (NdM: absence de licence) récents prennent le contre-pied de cette tendance : MonitorBox et Monitux. Leur objectif commun : revenir à un monitoring lisible, fiable et maîtrisable, pensé avant tout pour les administrateurs Linux.

MonitorBox : réduire le bruit pour mieux gérer l’urgence

MonitorBox part d’un constat largement partagé dans les équipes techniques : la multiplication des alertes engendre une fatigue des notifications, au point que les incidents critiques risquent d’être ignorés.
Le projet introduit une logique volontairement simple mais efficace : réduction des faux positifs par vérifications successives, séparation claire entre alertes critiques et informationnelles, et retour d’un outil longtemps abandonné mais redoutablement efficace : le pager (bipper).

En complément des notifications classiques, MonitorBox propose :

• une interface terminal pensée pour l’exploitation,
• un dashboard web léger,
• et une alerte matérielle dédiée pour les situations réellement urgentes.

Le projet assume une philosophie pragmatique : mieux vaut peu d’alertes fiables que beaucoup d’alertes ignorées.

Code source : https://github.com/simple-group/MonitorBox
Présentation : https://www.ihaveto.be/2026/01/pourquoi-jai-ressuscite-le-pager-des.html

Monitux : un monitoring “zero-dependency” pour réduire la surface d’attaque

Monitux s’inscrit dans une démarche encore plus radicale de sobriété technique. Le projet se définit comme un outil de monitoring serveur sans base de données, sans langage interprété (PHP, Python, Node.js), et sans dépendances externes.

Il repose exclusivement sur :

• les outils natifs GNU/Linux (top, df, ss, systemd…), un affichage web minimaliste, et une protection d’accès via les mécanismes standards d’Apache (.htaccess / .htpasswd).

Ce choix permet de limiter fortement la surface d’attaque, de simplifier l’installation et de garantir une excellente lisibilité du code. Monitux se destine particulièrement aux environnements où la stabilité, la sécurité et la compréhension priment sur la sophistication fonctionnelle.

Code source : https://github.com/simple-group/Monitux/
Présentation : https://www.ihaveto.be/2025/12/monitux-le-monitoring-serveur-revient.html

Une même philosophie : simplicité, contrôle et responsabilité

Bien que différents dans leur approche, MonitorBox et Monitux partagent une vision commune :
le monitoring ne doit pas devenir une boîte noire, ni un empilement de dépendances difficile à auditer. Ces projets s’adressent aux administrateurs et équipes techniques qui souhaitent reprendre le contrôle, réduire la complexité et privilégier des outils compréhensibles, durables et open source.

Les deux projets sont publiés sous licence libre et ouverts aux contributions.

NdM: aucune licence n'est mentionnée sur les deux projets en question, qui ne sont donc pas libres en l'état.

Quand on développe et distribue des applications open-source auto-hébergées, il y a une question très simple à laquelle il est presque impossible de répondre :

Combien d’instances actives de mon application sont réellement utilisées ?

C’est exactement le problème que j’ai rencontré avec Ackify, une application open-source de preuve de lecture de documents (politiques internes, procédures, formations, etc.), déployée en self-hosted par ses utilisateurs - sans que j'ai le moindre contrôle dessus.

Pas de SaaS, pas de compte centralisé, pas de tracking utilisateur.
Résultat : zéro visibilité.

👉 Combien d’instances Ackify tournent vraiment ?
👉 Quelles versions sont encore actives ?
👉 Quelles fonctionnalités sont utilisées (ou pas) ?

C’est pour répondre à ce besoin très concret que j’ai créé SHM – Self-Hosted Metrics.

SHM, c’est quoi ?

SHM est un serveur de télémétrie privacy-first, conçu spécifiquement pour les applications self-hosted open-source.

L’idée est simple :

• chaque instance auto-hébergée envoie périodiquement un snapshot de métriques agrégées
• aucune donnée utilisateur
• aucun événement individuel
• aucun tracking comportemental

Juste ce qu’il faut pour comprendre l’usage réel d’un logiciel déployé “dans la nature”.

Un point important : SHM est agnostique

Contrairement à beaucoup d’outils existants, SHM n’impose aucun schéma.

Tu envoies :

{
  "documents_created": 123,
  "active_users": 42,
  "webhooks_sent": 9
}

➡️ le dashboard s’adapte automatiquement :

• nouvelles cartes KPI
• nouvelles colonnes
• graphiques générés dynamiquement

Aucun frontend à recompiler, aucune migration à écrire.

Un petit mot sur Ackify

Ackify est l’application qui a déclenché tout ça :

• open-source
• self-hosted
• preuve de lecture avec signature cryptographique
• alternative légère à DocuSign pour des usages internes

SHM est désormais utilisé pour répondre à des questions très simples :

• combien d’instances actives ?
• combien de documents créés ?
• combien de signatures générées ?

Projet open-source

• Code source : https://github.com/btouchard/shm
• Déploiement simple en docker compose
• SDK Go (et Node.js) pour intégrer la collecte facilement

Le projet est encore très jeune (MVP), mais fonctionnel et déjà utilisé en conditions réelles.

Les retours, critiques et idées sont évidemment bienvenus 🙂

Stack technique (sobre et assumée)

• Backend : Go (binaire unique, léger)
• Stockage : PostgreSQL (JSONB)
• Déploiement : Docker
• Licence : AGPLv3 (SDK en MIT)
• Auth des instances : Ed25519 (clé générée localement, signature des snapshots)

Chaque instance :

• génère une identité cryptographique locale
• s’enregistre une seule fois
• signe chaque envoi de métriques ➡️ impossible de spoof une instance existante.

Et côté vie privée ?

C’était non négociable.

SHM :

• ne collecte aucune donnée personnelle
• ne collecte pas les IP (hors reverse-proxy)
• ne collecte ni hostname, ni username
• fonctionne sur des compteurs agrégés uniquement

C’est au mainteneur du logiciel de décider quelles métriques exposer, et à l’utilisateur final de pouvoir désactiver la télémétrie.

Première fournée de l'année pour vos magazines préférés. Voici donc un petit panorama, de plus en plus restreint au niveau des éditeurs, forcément subjectif et parti{e,a}l, de la presse papier sortie récemment.

D'ailleurs cette année nous pouvons fêter les 30 ans des éditions Diamond. Encore plus vieux que LinuxFr.org ! 🎉 Joyeux anniversaire 🎂. À cette occasion, elles proposent de (re)découvrir l'une de leurs publications en offrant le numéro 270 de GNU/Linux Magazine via leur support de lecture en ligne, Kiosk Online (en HTML).

Sinon, voici les nouveautés sorties en janvier 2025 et disponibles jusque fin février, sauf pour le hors-série MISC disponible jusqu'à la fin mars :

• GNU/Linux Magazine France n^o 273 vous explique comment accéder au matériel PCIE depuis vos VM ;
• Linux Pratique n^o 147 utilise GATUS pour déployer une page de monitoring de vos services ;
• MISC magazine n^o 137 publie le second article de la série sur le Cyber Resilience Act et propose une intégration des exigences de ce dernier dans vos cycles DevSecOps ;
• Hackable n^o 58 allie domotique & vidéosurveillance sans sacrifier votre vie privé ;
• MISC hors-série n^o 31 donnera des idées aux Red Team avec cinq articles techniques décrivant des attaques concrètes et réussies sur le terrain.

Télécharger GNU/Linux Magazine numéro 270

Pour le récupérer, il suffit de

1. se connecter ou de créer un compte sur leur boutique en ligne ;
2. d'ajouter le numéro 270 de GNU/Linux Magazine à votre panier en sélectionnant bien le support Kiosk Online avant ;
3. d'indiquer le code de remise ED30LINUXFR lors de la validation de la commande.

Bonne lecture !

Les sommaires des numéros sortis en janvier 2025

MISC hors‑série numéro 31

Au sommaire de ce numéro hors-série :

• Threat modeling : anticiper et identifier les menaces sur les infrastructures
• Dossier : Red Team
  • IPSpinner : un outil innovant de rotation d’adresses IP
  • Comment (ne pas) définir ses stratégies d'accès conditionnel Entra ID
  • CI/CD : de l'intégration à l'intrusion avec GitHub Actions
  • SCCM : techniques d’exploitation pour les intrusions Red Team
  • Contournements EDR : analyse de SentinelOne
• Exploitation de l’AD CS : ESC12, ESC13 et ESC14

GNU/Linux Magazine numéro 273

Au sommaire de ce numéro de janvier – février 2025 :

• Awk comparé aux outils Unix et Python ;
• Encapsulation et gestion d’états en Erlang avec ETS/DETS ;
• Chroot n'est pas mort, il va d'ailleurs très bien… sous OpenBSD ;
• Développement noyau, machine virtuelle et périphérique PCIe physique ;
• Réalisez un module Caddy : exemple de génération d’AVIF et de JXL à la volée ;
• Le temps sous Linux - 3e volet.

Linux Pratique numéro 147

Au sommaire de ce numéro de janvier – février 2025 :

• Virtualisez facilement de nouveaux systèmes avec Quickemu ;
• Introduction au filtrage réseau avec BPF ;
• La pile web sous OpenBSD ;
• Une météo des services de manière simple et efficace avec Gatus ;
• Modéliser un contrôle d’accès basé sur les attributs avec OPA ;
• Automatisation avec Ansible Navigator et Red Hat Ansible Automation Platform ;
• Adoptez PimCore, bien plus qu’un CMS.

MISC Magazine numéro 137

Au sommaire de ce numéro de janvier – février 2025 :

• Cyber Resilience Act / DevSecOps : mise en perspective et intégration dans le run ;
• Opération Triangulation : 2 ans après, analyse et détection de l'implant ;
• Détection d’exploits du noyau Linux avec eBPF ;
• Sécuriser les clés privées avec la séparation de privilèges cryptographiques ;
• RETEX d’implémentation d’une architecture N-tier Active Directory ;
• Chiffrement homomorphe et Private Information Retrieval en Python ;
• Une solution à la transition vers la cryptographie post-quantique.

Hackable numéro 58

Au sommaire de ce numéro de janvier – février 2025 :

• FSiC2024 : L’Open Silicium décolle à Paris !
• Mettre en place une surveillance domotique avec Raspberry Pi ;
• S'initier à OpenCL sur Raspberry Pi 3 ;
• FX2LP : une autre solution pour créer des périphériques USB ;
• Sécuriser tout et n'importe quoi avec des mini-signatures ;
• LiteX : Linux sur un SoC RISC-V en FPGA.

Il y a un nouveau venu parmi les logiciels de supervision : Argos Panoptès !

Loin de la complexité des Nagios, Centreon, Icinga et autres mastodontes qui font le café, Argos Panoptès (on l’appellera Argos dans la suite de ce texte) ne surveille que des sites web, ce qui lui permet d’être bien plus simple et léger.

Argos a été développé par Alexis Métaireau pour Framasoft dans le cadre de Framaspace (du Nextcloud fourni gracieusement par Framasoft aux associations et collectifs militants).
Framasoft a fait appel à un prestataire, faute de temps disponible pour développer nous-même l’outil.

Sommaire

• Le nom
• Le cahier des charges
• Le code
• Le fonctionnement en production
• Le futur
• One more thing

Pourquoi cet outil ? Lorsque l'on prévoit de créer plein d’espace Nextcloud, il semble pertinent de les surveiller.
Et comme Framasoft prévoit de déployer jusqu’à 10 000 espaces, il fallait quelque chose qui tienne la route… ce que le Shinken de l’association ne permettait pas : trop de sondes à exécuter, trop peu de temps pour le faire et on se retrouve avec des coups de sondes pas assez fréquents, laissant les sites avec des problèmes avec de trop longs délais de détection.

Sans compter que Shinken est en Python 2, qui est obsolète depuis déjà bien longtemps.

Le passage à une nouvelle solution de supervision complète (nous lorgnons sur Icinga) étant trop chronophage pour le temps que nous avons à lui consacrer pour l’instant, nous avons préféré partir sur une solution de surveillance de sites web, suivant l’adage UNIX « un logiciel qui fait une seule chose, mais qui la fait bien ».

Mais enfin, y a déjà des outils pour ça !

Bien sûr ! Nous avons testé statping-ng et Uptime Kuma mais avec nos très nombreux sites à surveiller, cela les mettait à genoux… ou alors c’est le navigateur qui ne tenait pas : ces deux solutions affichent sur la page d’accueil l’état de tous les sites à surveiller, et avec un historique de leur état en plus. Lorsque l'on veut surveiller des centaines de sites avec au moins trois coups de sondes chacun (un pour vérifier que le site HTTP redirige bien vers la version sécurisée, un pour vérifier que la version sécurisée répond bien, et un pour vérifier l’expiration du certificat du site), ça fait énormément d’appels AJAX au serveur quand on consulte le site et soit c’est le serveur qui a du mal, soit c’est le navigateur qui peine.

Ainsi est née l’idée du développement d’une solution qui remplisse notre cahier des charges

Le nom

Argos Panoptès fait référence au géant aux cent yeux de l’antiquité grecque, « Panoptès » signifiant « celui qui voit tout ».

Le cahier des charges

Il était simple mais toutefois complet, rédigé par votre serviteur (étant adminSys et développant aussi, j’avais mon idée sur ce que je voulais déployer et ce que j’aurais voulu coder moi-même) :

• un langage simple, qui peut attirer du monde pour les contributions : Python ;
• un langage moderne : la cible était Python 3.11, à savoir la version de Debian Bookworm ;
• le support d’une base de donnée robuste : PostgreSQL ;
• une architecture agents / serveur, permettant d’ajouter des agents pour les coups de sondes au fur et à mesure de l’augmentation des besoins. Ceci pour éviter le goulot d’étranglement constaté sur Shinken (l’ajout de plus d’agents Shinken n’étant pas possible puisque Python2) ;
• une configuration simple et automatisable : l’infrastructure de Framasoft étant gérée via Salt, de même que la configuration des sondes de Shinken, il était vital de pouvoir créer la configuration des sites à surveiller de façon programmatique. Le YAML fut choisi pour cela ainsi que pour sa simplicité de lecture par un humain ;
• divers moyens de notifications, courriel et Gotify a minima.

Le code

Le code d’Argos est sur la forge logicielle de Framasoft : https://framagit.org/framasoft/framaspace/argos/.

Une suite de tests est exécutée en intégration continue, ainsi que du linting, ce qui permet d’éviter autant que possible les régressions et de maintenir un style de code uniforme.

Pour les dépendances, rien d’exotique (et c’est tant mieux !) :

• Click pour l'interface en ligne de commande ;
• FastAPI est le cadriciel qui nous permet d'exposer l'API HTTP ;
• HTTPX est utilisé pour émettre des requêtes asynchrones dans les agents ;
• Jinja gère la mise en page ;
• Pydantic est utile pour s'assurer que les données correspondent à nos attentes ;
• SQLAlchemy est l'ORM que nous utilisons pour nous connecter à notre base de données et lancer des requêtes ;
• Alembic est utilisé pour les migrations de bases de données ;
• Tenacity un petit utilitaire pour réessayer une fonction en cas d'erreur ;
• Uvicorn est l'outil utilisé pour faire tourner notre serveur ;
• Gunicorn est le serveur WSGI HTTP recommandé pour la production.

Pour aider les potentiels contributeurs, une partie du site officiel est dédiée au développement.

L’API d’Argos est auto-documentée : en installant Argos, vous aurez des pages de documentation aux formats Swagger et Redoc.

Le fonctionnement en production

Si Argos a été annoncé sur le Framablog mi-mai 2024, cela faisait déjà plusieurs mois que la version de développement était en production.

Le moins qu’on puisse dire, c’est qu’Argos tient ses promesses ! Il est rapide… très rapide !

Lors du dernier démarrage à vide d’une version de développement, Argos a lancé ses 2145 tests configurés à une vitesse impressionnante : il ne lui a fallu qu’une minute et 15 secondes pour tous les effectuer.

L’API présentant un point permettant de connaître le nombre de sondes dans chaque état (les classiques ok, warning, critical et unknown), nous avons ajouté une sonde à notre Shinken pour intégrer les résultats d’Argos dans celui-ci.

En effet, avoir un outil dédié, c’est sympa, mais si ça fait une page web de plus à consulter, c’est enquiquinant. La centralisation de la supervision au sein de Shinken permet de contourner ce problème.

Le futur

Depuis la première version et une version de micro-changements, la majeure partie des modifications s’est concentrée sur l’amélioration de la documentation, ainsi que sur la simplification de la configuration et de l’installation.

Quelques nouvelles fonctionnalités seront de la partie, réduisant quelques frictions rencontrées depuis la mise en production de la dernière version.

Les contributions sont les bienvenues (peut-être quelqu’un intégrera-t-il les notifications via Apprise ?) 😉

One more thing

Framasoft est actuellement en pleine campagne de collecte de fonds dans le cadre de la démarche de soin de nos services en ligne « Dorlotons Dégooglisons » (mais ça, vous le saviez peut-être déjà).

Merci de nous soutenir si vous le pouvez ! 🙂