DEV Community

Cover image for PandApache version 3.4 est la !

PandApache version 3.4 est la !

Ça a mis un peu de temps (C’est ce qui arrive quand un dev backend travaille sur du front), mais ça y est, PandApache3.4 est disponible ! Release

Cette nouvelle version apporte beaucoup de nouveautés que nous allons voir ensemble maintenant.

Après la version 3.3, qui était très axée sur la partie administration, PandApache continue sur le chemin d’être un serveur web fait pour et par un SRE. Pas de fonctionnalités pour les utilisateurs finaux, mais juste pour nous, les administrateurs ! Au programme : télémétrie, monitoring et opérations d’administration simplifiées.

C’est parti !


Architecture modulaire

Pour un développement et une administration plus simples, le service PandApache3 est maintenant découpé en modules. Trois précisément au moment de cette version :

  • Le module Web
  • Le module Admin
  • Le module Télémétrie

Le module Web est tout simplement le cœur de PandApache, il s’agit du module qui sert à écouter sur le port 80, c’est le module qui permet de rediriger chaque requête HTTP vers la bonne ressource.

Le module Admin n’est pas nouveau, c’est toujours le deuxième service web qui tourne par défaut sur le port 4040 et qui permet d’exécuter des endpoints afin de réaliser des tâches d’administration, comme arrêter ou redémarrer le serveur.

Le module Télémétrie, lui, est nouveau. On en parlera un peu plus tard, mais c’est un module qui permet de recueillir en temps réel des informations sur votre système afin de s’assurer par exemple que votre système hôte a toujours assez de mémoire, assez de CPU, vérifier les écritures sur le disque, etc.

Cette nouvelle architecture est très importante pour plusieurs raisons :

  • Simplifier grandement le développement dans le futur grâce à cette approche plus modulaire.
  • Diagnostiquer des problèmes plus finement, notamment grâce aux logs séparés. Vous pouvez mettre le module Web en mode debug et garder les autres en mode info ou erreur pour ne pas polluer vos logs.
  • En cas de problème sur un module, il peut simplement être désactivé, tout en continuant à profiter des autres modules.

Ces modules sont indépendants et peuvent donc être activés ou désactivés comme vous le souhaitez.

En vrai, c’est un peu bête d’activer le module Télémétrie sans le module Admin par exemple, car vous n’aurez pas accès aux endpoints pour recueillir les infos de télémétrie. Et ça serait très bizarre de ne pas avoir de module Web sur un serveur web, mais après vous faites ce que vous voulez, hein.

Par contre, vous pouvez très bien n’avoir que le module Web, ou que le module Web et Admin. Les endpoints de télémétrie ne fonctionneront pas, mais le reste marchera sans problème.

Ils ont aussi leur propre fichier de log, ce qui permet un troubleshooting plus efficace, en plus d'avoir leur propre niveau de log.

Voici un exemple de la configuration des modules :

<Module Telemetry>
    ModuleLogLevel error
    enable true
    ModuleLogFile telemetry.log
</Module>
<Module Web>
    enable true
    ModuleLogLevel debug
    ModuleLogFile web.log
</Module>
<Module Admin>
    enable true
    ModuleLogFile admin.log
</Module>
Enter fullscreen mode Exit fullscreen mode

Entre nous :

le serveur lui-même est visible comme un module, on peut donc avoir dans les logs des entrées qui viennent du module « Serveur ». C’est tout simplement le processus principal qui lance tous les autres modules et lui ne peut bien sûr pas être désactivé.

Toujours entre nous :

La télémétrie étant quelque chose de très spécifique à l’OS, mais aussi à la langue, elle ne fonctionne que sur Windows. Cependant, le gros du travail est fait pour pouvoir itérer sur cette première base de modules et permettre dans le futur un monitoring plus large sur les différents systèmes.


Télémétrie

Vous le savez, la télémétrie pour assurer la fiabilité d’un service est essentielle, aussi bien pour le service lui-même que pour son hôte. C’est pourquoi un nouveau endpoint /admin/monitor a vu le jour. Sous ce endpoint, vous allez pouvoir retrouver plusieurs métriques afin de vérifier le bon fonctionnement de votre service et de votre système. Retrouvez notamment les endpoints suivants :

  • /monitor/cpu
  • /monitor/availablememory
  • /monitor/diskread
  • /monitor/diskwrite
  • /monitor/diskqueue
  • /monitor/gcheapsize

Et d'autres encore.

Ces endpoints vous permettent de connaître en temps réel les valeurs de votre système correspondant à la métrique associée.

Voici par exemple le résultat du endpoint : http://127.0.0.1:4040/admin/monitor/cpu : 72,80516052246094. Correspondant à la valeur actuelle du CPU.

Bien sûr, cette métrique change à chaque fois. Voici par exemple 3 valeurs différentes obtenues à la suite :

72,80516052246094

64,66727752685547

55,4402359008789

Pour ne pas demander à votre système de monitoring de venir récupérer chaque nouvelle valeur chaque seconde. Il y a un dernier endpoint fonctionnant avec un paramètre: /monitor/metric.

Le paramètre name peut être utilisé avec les valeurs suivantes :

  • CpuUsagePercentage
  • AvailableMemoryMB
  • DiskReadBytesPerSecond
  • DiskWriteBytesPerSecond
  • DiskQueueLength
  • GCCollectionCount
  • GCHeapSizeBytes

Ce endpoint renverra, contrairement aux autres, une réponse au format JSON :

[{"Key":"2024-12-01T23:57:30.1295087+02:00","Value":57.67658710479736},
 {"Key":"2024-12-01T23:57:38.7241797+02:00","Value":59.110374450683594},
 {"Key":"2024-12-01T23:58:08.2192014+02:00","Value":62.357760747273765},
 {"Key":"2024-12-01T23:58:12.4449679+02:00","Value":54.44178104400635},
 {"Key":"2024-12-01T23:58:21.103619+02:00","Value":65.64530436197917},
 {"Key":"2024-12-01T23:58:21.1044157+02:00","Value":76.43288993835449},
 {"Key":"2024-12-01T23:58:29.665167+02:00","Value":64.24466037750244},
 {"Key":"2024-12-01T23:58:59.2308917+02:00","Value":74.4074338277181},
 {"Key":"2024-12-01T23:59:03.3638932+02:00","Value":78.21070289611816},
 {"Key":"2024-12-01T23:59:11.9931579+02:00","Value":73.42640749613444},
 {"Key":"2024-12-01T23:59:11.993631+02:00","Value":84.76824760437012},
 {"Key":"2024-12-01T23:59:20.7471495+02:00","Value":92.40722846984863},
 {"Key":"2024-12-01T23:59:29.3142203+02:00","Value":65.4045352935791}]
Enter fullscreen mode Exit fullscreen mode

Cela permet d’obtenir plusieurs valeurs sur un temps plus long.

Entre nous :
chaque métrique est capturée toutes les 30 secondes en faisant une moyenne des valeurs obtenues, et les 10 dernières métriques vous sont renvoyées ensuite sous un format qui permet facilement de visualiser l'information sur un graphique.


La console d’administration

Souvenez-vous, lors de la précédente version, la 3.3, nous expliquions que des endpoints administratifs pouvaient être utilisés pour administrer facilement, de manière programmatique, un ou plusieurs services PandApache3, mais aussi pour construire une console d’administration si nous le souhaitions.

C’est désormais chose faite avec la version 3.4, bienvenue dans la console d’administration de PandApache !

Image de la console admin

Il n’y a rien de plus dur et chiant pour un dev backend que de faire une interface graphique, alors je remercie chaleureusement l’équipe d'AdminLTE pour leur template de console d’administration. C’est leur travail qui a été repris pour réaliser une console fonctionnelle et vous allez voir, que leur template envoie du pâté !

La console d’administration dispose, pour le moment, de 4 sous-sections :

Status :

Une page pour du troubleshooting rapide. Elle permet de connaître le statut de votre service, ainsi que d’avoir un bref historique des derniers logs, dont le format a d’ailleurs été retravaillé.

Image de la page status

En plus de l’information du module qui emet les logs, vous avez également son thread ID. Toute la partie gestion de tache de PandApache a été revue.

Health :

Une page avec les métriques de PandApache. Comme vu dans la partie télémétrie, les métriques sont maintenant disponibles via API. Nous en avons donc fait un joli dashboard pour voir en temps réel ce qui se passe.

Image de la page health

(Encore une fois, merci à AdminLTE pour leur travail qui a permis une intégration assez facile !)

Management :

Cette page permet d’effectuer des opérations sur le service PandApache3, et vous allez voir qu’il n’y a pas beaucoup de limites à ce que vous pouvez y faire !

Il y a bien sûr les opérations de base qui étaient déjà implémentées : Recharger la configuration, redémarrer le service ou l’arrêter.

Image de la page management

Mais vous pouvez aussi maintenant avoir des scripts personnalisés exécutés directement par le service !

Les scripts exécutables sont ceux présents dans votre dossier admin. Nous listons tous les scripts PowerShell ou Shell selon la plateforme.

Vous pouvez, via un nouveau endpoint, les exécuter et obtenir le résultat du script.

Image d’un script en cours d’exécution

Image d’un script exécuté avec succès

Avant de faire une syncope en pensant qu’il est possible d’exécuter du code à distance, sachez que cette option est bien sûr désactivable dans la configuration. Mais les vrais savent à quel point c’est une fonctionnalité importante pour la bonne maintenance d’un service.

Configuration :

Enfin, la dernière page vous affiche la configuration actuelle au format JSON.

Image de la page configuration

Bien que le fichier de configuration au format JSON ne soit pas encore implémenté, cela vous donne un avant-goût du futur : plus de formats de configuration supportés et une gestion de la configuration et de ses changements facilitée.

_Entre nous : _

L’exécution des scripts et leurs résultats est, pour le moment, synchrone. Ce n’est pas idéal, notamment car certains scripts peuvent être longs à s’exécuter. Un système asynchrone avec un task ID qui vous sera renvoyé pour connaître l’état de votre script va être proposé dans le futur, toujours pour faciliter au mieux l’administration du service.


Pour finir

C’était une présentation rapide des nouvelles fonctionnalités clés de PandApache 3.4. J’espère que ce tour d’horizon vous a plu. Cette nouvelle version vient avec, bien sûr, plein de changements non visibles (gestion des logs, gestion des threads, etc.), mais bien réels et qui seront le sujet de futurs articles de blog plus techniques, où nous nous concentrerons sur une problématique à la fois (sinon ce blog post serait beaucoup trop long !).

Comme pour toute nouvelle version, il faut s’attendre à quelques corrections mineures dans les prochains jours, lorsque de nouveaux problèmes seront détectés au fur et à mesure du déploiement sur différentes configurations.

Suivez mes aventures sur Bluesky @pykpyky.bsky.social pour rester informé de toutes les nouveautés. Vous pouvez également explorer le projet complet sur GitHub et me rejoindre pour des sessions de codage en direct sur Twitch pour des moments excitants et interactifs. À bientôt derrière l’écran !

Top comments (0)