Reporting JSON et Jsonreader2

last update: 20/09/2021

Historique

J’utilise SaltStack depuis déjà pas mal d’années.

L’idée d’exploiter les sorties pour avoir une idée de l’état de mon parc serveur a fait son chemin depuis de nombreuses années. J’ai ainsi réalisé mon 1er petit outil reporting en php/html/js en 2016, alors même que j’utilisais SaltStack depuis environ un an ou deux.

A cette époque, j’exploitais déjà les sorties de test.ping et de l’état des services avec une recette custom.

Puis un nouveau développeur est arrivé dans l’équipe et a repris plusieurs projets dont ce petit outil de parsing en php qui ne faisait qu’une seule grosse page monolithique à l’époque.

Portail_admin est alors né. L’outil est une usine à gaz jouant les rôles de CMDB /IPAM / outil d’inventaire et de gestion des utilisateurs et des listes de diffusion. Bref, cet outil mériterait un article à lui tout seul mais reste intimement imbriqué à l’infrastructure de la plateforme MBB, et le packaging et la distribution de l’outil serait un job à temps plein.

Il manquait l’aspect gestion des logs, monitoring, et reporting à l’outil.

Ces aspects ont été rajouté, au moins partiellement à l’outil. Vous pouvez penser à cet outil comme un mélange de netbox + une partie de glpi et de fusiondirectory… Le côté monitoring étant trop peu développé pour le comparer à d’autres outils de monitoring.

Reporting avec SaltStack

SaltStack offre la possibilité d’avoir des sorties au format json. Un script dans un cron permet d’avoir ainsi de nombreux résultats, dans un dossier dédié, avec la date et l’heure.

C’est assez simple et ça fonctionne bien. Bien entendu, en environnement plus contraint, on peut faire bien mieux, même en restant sous SaltStack, notamment par le biais des beacons SaltStack pour faire un semblant de monitoring.

Actuellement, je considère que le reporting vient en complément d’une vraie solution de monitoring telle que prometheus + grafana.

Le cron est donc réglé sur une exécution toutes les 30mn. Le nombre de tâches à réalisées par le cron étant telles, qu’il faut parfois 5mn pour en exécuter la totalité sur ~100 machines (minions SaltStack). Ça mériterait certainement un peu d’optimisation…

Pour pouvoir exploiter tout ça, il suffit de partager les résultats avec un serveur Web (qui, dans mon cas, est le Master SaltStack lui-même), et mettre en forme, pour que ça soit humainement lisible et compréhensible rapidement.

Jsonreader2

La version 1 de l’outil, comme indiqué dans le premier paragraphe, était une simple page Web en PHP avec du Js + une feuille de style en CSS.

Suite à la reprise de l’outil par mon collègue et un changement de service (et l’état des RH en informatique chez nous étant ce qu’il est), j’avais besoin de reprendre la main sur le code, récupérer celui-ci, le rendre compatible et suffisamment générique pour le nouveau service que je gère et au-delà. Je ne me considère pas développeur, ce genre de projet n’est donc pas simple pour moi, surtout que cette partie du code fut peu développée par mon ex-collègue.

Il a fallu donc sortir jsonreader, renommé alors “Jsonreader2”, le transformer en plugin pour Portail_admin (alors même que l’outil n’a pas de gestion de plugins (et donc avec création d’un système de plugin rudimentaire pour Portail_admin), reprendre et continuer son développement…

Autres formules et scripts avec sorties Json

Pendant la période où mon collègue développeur était sur la plateforme avec moi, bien d’autres sorties Json ont été rajoutées !

En vrac, je lui avais demandé d’intégrer les versions de SaltStack, du Bios, du kernel et de l’OS, de l’état des disques et de leur usage, la présence de processus en D state, l’état des zpool ZFS et de l’état des sites Web (checksums sur pages Web, statut des certificats électroniques (validité), réponses HTTP des serveurs). Je produisais les rapports et lui trouvais un moyen de les intégrer.

Côté disques, j’ai créé un script et une recette SaltStack associée, qui va consulter le statut smart des disques avec smartmontools et produire un log chaque jour, là aussi, par le biais d’un cron.

Concernant les sorties Json sur les serveurs et sites Web, ce n’est pas lié à SaltStack et les scripts peuvent être utilisés indépendamment.

BorgBackup et l’absence d’interface centralisée

Depuis quelques temps, je suis aussi très heureux d’utiliser BorgBackup. Néanmoins, en version centralisée, comparativement au précédent outil que j’utilisais, (BackupPC), il manque une interface d’administration (ou au moins de reporting).

J’ai réalisé plusieurs recettes SaltStack pour gérer BorgBackup (installation du serveur (qui n’est, au final, qu’un serveur ssh partageant un gros volume…), gestion des clés SSH), et borgmatic (avec installation côté client).

Par ailleurs BorgBackup permet d’avoir des exports Json. L’idée fut donc d’exploiter ces rapports avec Jsonreader2 de façon centralisée.

Le script cron que j’ai réalisé inclut ainsi beaucoup de awk et sed pour formater correctement les sorties Json depuis SaltStack. En effet, une simple relecture d’un fichier Json sur le minion par le Master SaltStack ne produirait pas un résultat correct en Json. Par ailleurs, en rajoutant --out=json, on perd une bonne partie de l’information…

Un autre cron sur les minions génère un rapport json pour BorgBackup chaque jour.

Installation

L’installation est un poil complexe, vu qu’il faut en prérequis un serveur salt, un serveur Web avec php, un serveur de bdd, un crontab à paramétrer et des recettes salt fonctionnelle, mais rien d’insurmontable. Le plus simple est de tout mettre sur une seule machine, sinon il faudra exporter par NFS les rapports JSON.

En version minimaliste, on peut se contenter d’exploiter les résultats des modules SaltStack, sans aucune recette (test.ping, grains os, kernelrelease, disk.usage, …).

L’installation est décrite dans le README du projet que vous trouverez ici, avec les liens vers toutes les recettes et scripts divers (ceux pour sites et serveurs Web notamment).

Configuration

Il y a deux fichiers importants dans config/ : Conf.php pour la configuration à la base de données et Plugin.php (il faut renommer ou copier depuis les .sample puis les éditer) incluant les $SECTIONS à afficher dans le tableau, correspondant aux types de rapport JSON.

Vous pouvez changer les couleurs correspondant à chaque message ou rajouter des types de messages à intégrer dans la partie Configuration/Jsonreader Config du WebUI.

Pour rajouter toute une catégorie de rapport JSON à intégrer, c’est un peu plus complexe puisqu’il faut coder une fonction capable de parser le fichier JDON selon le fichier de sortie et rajouter la catégorie correspondante dans l’outil (Configuration/Jsonreader Table puis Configuration/Jsonreader Config).

Fréquence : par défaut, un cron est lancé toutes les 30mn, mais il est possible d’augmenter la fréquence. Il faudra alors adapter la fonction JS de choix des heures/minutes dans le fichier services/jsonreader.php.

Utilisation

La manière d’utiliser le logiciel est assez simple. Il faut aller dans Reporting > jsonreader dans la WebUI pour afficher les différentes valeurs, à partir du moment où les crons ont commencé à tourner.

Quelques captures d’écrans :

Hosts Status
Hosts Status
Disks
Disks
Salt Version
Salt Version
Services check
Services check
Color config
Color config
Borg status
Borg status