Argos Panoptès : la supervision de sites web simple et efficace

Posté par  (site web personnel) . Édité par Xavier Teyssier et Benoît Sibaud. Modéré par Ysabeau 🧶. Licence CC By‑SA.
27
20
juin
2024
Supervision

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

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 !

Anakin : « J’ai besoin d’un logiciel de supervision ». Padme, tout sourire : « Donc tu vas en prendre un qui existe ? ». Anakin ne dit rien et la regarde avec un rictus. Padme, inquiète : « Tu vas en prendre un qui existe, hein ? »

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.

Quelqu’un susurre « PostgreSQL » à l’oreille d’une autre personne, on voit un bras couvert de chair de poule

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.

Capture d’écran de la page de statut d’Argos

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

Aller plus loin

  • # Au travail !

    Posté par  (site web personnel) . Évalué à 10.

    Maintenant que vous avez votre outil simple et léger, il est temps d'être sérieux, et de travailler à le rendre complexe, lourd et gras.

  • # Superviser en un clin d'oeil, le rêve

    Posté par  . Évalué à 4.

    Excellente idée, super cahier des charges. Bravo !

  • # opentelemetry

    Posté par  . Évalué à 3.

    OpenTelemetry intègre depuis quelques temps un httpcheck receiver dans le collector officiel.

    J'utilise déjà Uptrace pour mes metrics, traces et alerts, ça m'a pris 2 clics à rajouter.

    Titre de l'image

    • [^] # Re: opentelemetry

      Posté par  (site web personnel) . Évalué à 6.

      Je ne nie pas qu’il existe déjà plein d’autres outils mais :
      - ton outil m’a l’air de présenter le même problème que statping-ng et uptime kuma : il affiche tous les checks avec pleins d’informations sur la page de consultation. Pour 5 checks, c’est cool, pour 2 145… moins sûr
      - es-tu sûr que le service serait capable de gérer autant de checks ? Parce que statping-ng, qui est aussi basé sur un seul binaire, non. Il s’écroulait.
      - tu ajoutes tes sondes en 2 clics. C’est pratique, mais quand tu dois en ajouter 2 145 (et qu’il y en a régulièrement en plus ou en moins), ce n’est pas une sinécure. Je construis mon fichier de conf YAML avec un script qui pioche dans un fichier avec les trucs à surveiller (-> le script ajoute automatiquement les 3 checks de base + éventuellement d’autres) et je n’ai rien d’autre à faire qu’à recharger la config après.

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: opentelemetry

        Posté par  . Évalué à 2.

        Salut, est-ce que ton outil permet de réaliser des tests périodiques de temps de réponse ? Un peu comme si on mettait ab de Apache dans un cron et qu'on agrégeait les données.

        (Rien à voir avec le commentaire du dessus, mais répondre à un commentaire est le seul moyen sur LinuxFR d'interpeller directement un utilisateur et qu'il en soit notifié…)

        • [^] # Re: opentelemetry

          Posté par  . Évalué à 2.

          Salut, est-ce que ton outil permet de réaliser des tests périodiques de temps de réponse ? Un peu comme si on mettait ab de Apache dans un cron et qu'on agrégeait les données.

          Ce collecteur ne génère pas de test de charge comme ab. Par défaut, il lance une request sur ton endpoint et retourne le httpcode et le temps de réponse (httpckeck).

          Tu peux scripter cependant pour envoyer les données issues de ab vers le service qui va s'occuper du stockage des données et leur visualisation. Ici Uptrace dispose d'une interface graphique vraiment sympa et puissante pour interroger les données qu'il a stocké dans clickhouse

  • # Quis custodiet ipsos custodes?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    La centralisation de la supervision au sein de Shinken permet de contourner ce problème.

    Mais qui surveille Shinken ?

    • [^] # Re: Quis custodiet ipsos custodes?

      Posté par  (site web personnel) . Évalué à 1.

      Le sysadmin.

      Adhérer à l'April, ça vous tente ?

      • [^] # Re: Quis custodiet ipsos custodes?

        Posté par  (site web personnel) . Évalué à 3.

        Effectivement. J’ai :
        - un Argos perso qui surveille le Shinken du boulot
        - un script sur mon ordi qui va interroge Shinken via l’API LiveStatus et qui met des couleurs sur un blinkstick accroché à mon écran selon l’état de la supervision. Ça me permet de ne pas avoir à regarder mes mails ou l’interface web de Shinken pour savoir si tout va bien ou pas.

        Avec ça, je sais si Shinken fonctionne ou pas 🙂

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Un outil existant

    Posté par  (site web personnel) . Évalué à 3.

    Pourquoi ne pas utiliser une suite de collecte et visualisation existante ? Grafana ou OpenSearch par exemple.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Un outil existant

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 01 juillet 2024 à 20:50.

      Pourquoi prendre une solution de visualisation pour faire de la supervision ? Pourquoi un moteur d'indexation pour faire de la supervision ?

      J'imagine que tu pensais à une stack genre TICK (kapacitor, InfluxDB, Chronograph et je sais plus quoi), mais franchement, la complexité d'une telle stack pour faire des checks HTTP… bazooka, mouche, toussa.

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.