Status Engine¶
Documentation technique¶
Packaging¶
Le packaging de Status Engine est fait en trois parties:
Un module naemon (
status-engine-module) en C, qui écoute les événements émis par naemon et les envoie à gearmand, une sorte de « broker de jobs » (similaire à RabbitMQ, ZeroMQ)Un service php (
status-engine-worker), chargé de suivre les jobs envoyés à gearmand et les traiter pour les stocker à leur destination finale (une base de données MySQL)Un frontend php (
status-engine-interface), chargé d’afficher les données sur une page web.
Mises à jour¶
Worker¶
Le worker utilise comme dépendance une extension php
pecl-networking-gearman. Cette
extension doit être mise à jour avec la version de php, et il faut
s’assurer également que le worker est compatible avec la version de
l’extension. Actuellement la version 8.2 de php n’est pas compatible
avec la dernière version publiée, donc on utilise la version
master publiée sur github
Mise à jour¶
L’extension peut être mise à jour juste en modifiant la version de php et le commit associé.
La mise à jour du worker nécessite auparavant de cloner et mettre à jour
le fichier composer.lock (qui n’est pas inclu dans git) et le
fichier php-packages.nix:
cd /path/to/worker/code
path_to_nix=/home/immae/projets/nix
mypkgs_php_path='(builtins.getFlake "path:'$path_to_nix'/flakes/mypackages").packages.x86_64-linux.status-engine-worker'
nix-shell -p "${mypkgs_php_path}.php.packages.composer" "${mypkgs_php_path}.php" "import (builtins.fetchGit ''https://github.com/svanderburg/composer2nix'' { php = ''${mypkgs_php_path}.php''; }"
[nix-shell] $ composer install
[nix-shell] $ rm -rf vendor
[nix-shell] $ composer2nix
Copier ensuite les fichiers composer.lock et
php-packages.nix à leur emplacement dans
$path_to_nix/flakes/mypackages. Le fichier
composer-env.nix généré par composer2nix est déjà
enregistré globalement dans le dépôt nix:
flakes/mypackages/pkgs/composer-env/default.nix. Il peut être
utile de vérifier qu’ils sont toujours compatibles.
Le fichier php-packages.nix ne doit pas être copié en l’état
mais doit être modifié pour correspondre au format utilisé en interne.
Migration de la base de données¶
La base de données doit être migrée après la mise à jour:
status-engine-worker database --update --dry-run
Module¶
Le module naemon est associé à une version spécifique de naemon. Les détails d’installation et de compatibilité sont indiqués sur le site du module.
Un remplacement implémenté en C++ a vu le jour, mais ne semble pas beaucoup plus maintenu que l’ancien, qui fonctionne correctement.
Outils/Déboggage¶
Gearmand¶
Gearmand est un broker de jobs (aperçu de l’architecture de l’outil sur
le site de gearmand). On peut vérifier l’état
des jobs avec la commande gearadmin:
gearadmin --status
# affiche la liste condensée des jobs.
# Première colonne : nombre de jobs en attente
# Deuxième colonne : nombre de jobs en cours
# Troisième colonne : nombre de workers capables de prendre ces jobs
# C’est normal que certains types de jobs ne soient pas traités par le worker
gearadmin --show-jobs
# affiche la liste détaillée des jobs en attente
gearadmin --workers
# affiche la liste des workers capables de prendre un job
Redis¶
Redis sert à la fois de stockage d’informations de calculs pour le worker et stocke également les informations de performances. Ces des dernières informations ne sont pas utiles actuellement étant donné qu’elles contiennent la même chose que la base de données.
La base numéro 0 est celle utilisée:
redis-cli
127.0.0.1:6379> keys '*'
Worker¶
Le worker est un service systemd, couplé avec une tâche régulière de
cleanup. Certaines tâches d’administration (migration de base de
données) peuvent être réalisées avec la console
(status-engine-worker). Les procédures de mise à jour
particulières sont documentées sur le site du logiciel
Suivi des versions¶
Releases de Gearmand : https://github.com/gearman/gearmand/releases
Releases du module status-engine : https://github.com/statusengine/module
Nouveau module status-engine (non utilisé) : https://github.com/statusengine/broker
Releases du worker status-engine : https://github.com/statusengine/worker
Suivi des CVE¶
Accès / Suppression des données¶
Le worker stocke les données de monitoring dans une base de données mariadb. Ces données peuvent contenir des informations semi-personnelles selon les informations fournies pour mettre en place le monitoring.
La suppression d’un service n’entraîne pas automatiquement la suppression des données de performance associées. Cependant, les données sont nettoyées régulièrement (jusqu’à 1 an pour les états des services et hôtes) de la base de données, en fonction du fichier de configuration du worker.
