SMS (StackX Monitoring System)
SMS est un script Bash sous licence GPL conçu pour fournir une page locale de monitoring système simple, rapide et immédiatement lisible pour les serveurs StackX de ScalarX.
Le principe n’a pas changé : pas de stack lourde, pas d’agent opaque, pas de base de données ajoutée juste pour savoir si un service est mort. Un script Bash, des checks locaux, quelques fichiers de configuration et une page HTML exploitable directement par un humain comme par un système de supervision.
SMS reste SMS
La version publique actuelle est la 1.1.0 et correspond à la deuxième génération du moteur. Le fichier s’appelle encore sms2.sh sur certaines machines uniquement parce qu’il doit cohabiter un temps avec l’ancienne version pendant les migrations. Le produit, lui, reste SMS, et la version publique conserve donc le nom sms.sh.
Cette génération ajoute un rendu responsive structuré en cartes, un statut global OK, WARNING ou ERROR, un inventaire beaucoup plus large et plusieurs protections sur les secrets, les fichiers temporaires et les journaux.
Fonctionnalités principales
– page HTML responsive, sans framework JavaScript ;
– statut global et détail par contrôle ;
– états distincts OK, WARNING et ERROR ;
– marqueur invisible stable pour un contrôle externe de type Pingdom ;
– inventaire des erreurs réellement détectées ;
– journal local protégé sous /home/sx/log/sms/ ;
– lecture des processus et points de montage attendus depuis des fichiers texte ;
– aucune base de données propre à SMS, aucun daemon supplémentaire.
Contrôles système
SMS vérifie notamment :
– les processus critiques attendus ;
– la connectivité Internet et le réseau local ;
– la résolution DNS ;
– les filesystems attendus ;
– l’espace disque et les inodes ;
– la mémoire et la charge système ;
– l’âge de la dernière mise à jour APT ;
– l’état de la base de paquets avec dpkg --audit, avec une période de grâce pour ne pas transformer une transaction en cours en fausse alerte ;
– le RAID logiciel et ZFS lorsqu’ils sont activés.
Les processus surveillés proviennent par défaut de :
/home/sx/data/process2monitor.txt
Les points de montage attendus proviennent de :
/home/sx/data/fs_list.txt
Bases de données et services
La génération actuelle sait contrôler :
– MariaDB et MySQL, avec détection du fournisseur et vocabulaire de réplication adapté ;
– PostgreSQL, son rôle primaire ou standby et l’état de sa réplication ;
– Memcached ;
– Redis, avec ou sans authentification ;
– RabbitMQ et son interface de management ;
– Postfix SMTP ;
– Elasticsearch et OpenSearch, y compris OpenSearch sécurisé.
Un état inconnu, incomplet ou ambigu n’est pas transformé artificiellement en vert. Selon le contrôle, SMS remonte un WARNING ou un ERROR.
Sauvegardes et synchronisation
SMS suit les sauvegardes de bases et de fichiers utilisées dans StackX. Il contrôle notamment la fraîcheur des journaux et des dumps, les marqueurs de fin, les erreurs connues et la présence d’une opération encore en cours.
Il sait distinguer un module absent, une sauvegarde non encore initialisée, un backup en cours, un succès récent, un retard et un véritable échec.
La deuxième génération suit aussi les marqueurs structurés de synchronisation de fichiers produits par SxSync : initialisation, dernier succès, avertissement facultatif, erreur active ou erreur réellement récupérée.
Configuration
Le fichier principal est, par défaut :
/home/sx/.sx
Il contient uniquement les valeurs nécessaires aux contrôles activés. Exemple volontairement incomplet :
loginsxmysql:sx
passsxmysql:xxxxxxxx
postgresql_database:sx
postgresql_user:sx
postgresql_password:xxxxxxxx
postgresql_port:5432
redis_password:xxxxxxxx
rabbitmq_user:monitoring
rabbitmq_password:xxxxxxxx
Ce fichier contient potentiellement des secrets : il doit appartenir au compte d’exploitation, être protégé en lecture et rester hors de toute racine web.
Traitement des secrets
SMS ne transmet pas les mots de passe SQL dans les arguments des clients. Il crée au besoin des fichiers temporaires privés pour MariaDB/MySQL ou PostgreSQL, ainsi qu’un fichier d’en-tête privé pour les authentifications HTTP. Ces fichiers sont supprimés à la fin de l’exécution, y compris lors des sorties interrompues prévues par le script.
Les variables sensibles sont conservées dans le shell courant sans être exportées aux sous-processus. Les emplacements temporaires et le journal font l’objet de contrôles de type, de propriétaire et de lien symbolique avant utilisation.
Le répertoire /home/sx/log/sms doit exister, être privé et être accessible au compte qui exécute SMS. La version actuelle ne bascule pas silencieusement vers un répertoire temporaire moins maîtrisé si ce journal est dangereux ou indisponible.
Exécution
La version publique conserve volontairement l’appel historique :
bash sms.sh
Dans StackX, la copie opérationnelle du script est habituellement installée hors de la racine web et appelée depuis un endpoint interne protégé. Seule sa sortie HTML doit être consultable. Cette copie opérationnelle, son fichier .sx et ses journaux ne doivent jamais être servis directement par Apache. Le lien de téléchargement ci-dessous distribue uniquement le code public, sans configuration ni secret.
L’image locale ScalarX.jpg doit être disponible à côté de la page de monitoring si vous souhaitez conserver le bandeau d’origine.
Exemple de séquence
La variante StackX active les contrôles communs puis laisse les modules propres au serveur désactivés jusqu’à leur configuration :
startpage "StackX Local monitoring v2"
title "StackX Monitoring System"
table_init
titlecheck "Server processes"
all_process_check
network_check "Internet" 1.1.1.1 8.8.8.8
dns_check google.com cloudflare.com
fs_check yes
storage_check 95 90 95 90
mem_check 95 90
load_check
center_column
mysql_check "$LOGINSXMYSQL" "$PASSSXMYSQL" "$(mysql_replication_threshold)"
memcached_check 127.0.0.1 11211
smtp_check 127.0.0.1 25
backup_check 30 54
file_sync_check
check_update 10
dpkg_audit_check
table_end
endpage
log
Redis, RabbitMQ, PostgreSQL, OpenSearch, RAID ou ZFS doivent être activés seulement sur les profils qui les utilisent réellement.
Périmètre
SMS reste un outil opérationnel conçu pour StackX. Il est publié parce qu’il peut servir de base lisible et modifiable, pas parce qu’il prétend remplacer tous les systèmes de supervision du marché.
Il suppose l’arborescence et plusieurs conventions StackX. Si vous l’utilisez ailleurs, vous devez adapter les chemins, les services, les seuils et la séquence finale à votre propre environnement. Ne recopiez jamais une configuration ni des identifiants de production dans une version publique.
Ressources
Script : sms.sh
—
Christophe Casalegno (retrouvez tous mes liens, mes projets et mes réseaux sur all.bo)