Sommaire
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 ! 🙂
Connexion
