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 lisible pour les serveurs StackX de ScalarX.

SMS, pour StackX Monitoring System, génère une page HTML statique à la volée, directement depuis le serveur, afin de vérifier rapidement l’état des composants essentiels : processus, réseau, DNS, filesystems, stockage, mémoire, charge système, bases de données, cache, SMTP, sauvegardes et mises à jour système.

Le principe est volontairement simple : pas de stack lourde, pas d’agent complexe, pas de dépendance inutile. Un script Bash, quelques fichiers de configuration, des checks locaux, et une sortie HTML immédiatement exploitable depuis une page interne ou un endpoint protégé.

– Génération d’une page HTML locale de monitoring.
– Affichage clair des états OK, WARNING et ERROR.
– Journalisation des exécutions dans /home/sx/log/sms/.
– Fallback automatique vers /tmp/sx-sms si le répertoire de log principal n’est pas accessible.
– Agrégation des erreurs détectées dans une liste dédiée.
– Lecture d’un fichier de configuration StackX.
– Lecture automatique des processus à surveiller depuis /home/sx/data/process2monitor.txt.
– Support d’une intégration simple dans une page PHP.

Checks système :

– processus serveur critiques.
– connectivité Internet.
– réseau local.
– résolution DNS.
– filesystems montés.
– espace disque.
– inodes.
– mémoire.
– load average.
– dernières mises à jour APT.

Checks services :

– MySQL / MariaDB.
– réplication MySQL / MariaDB.
– PostgreSQL.
– réplication PostgreSQL.
– Memcached.
– Redis.
– Postfix SMTP.
– Elasticsearch / OpenSearch.
– OpenSearch sécurisé.
– RAID logiciel.
– ZFS.

Checks sauvegardes :

– fraîcheur des logs de sauvegarde base de données.
– présence des dumps SQL / PostgreSQL.
– détection du marqueur de fin de sauvegarde.
– détection d’un backup en cours.
– vérification des sauvegardes fichiers via sxfilesbkp / rdiff-backup.
– gestion différenciée entre module absent, module non configuré, backup en cours, backup récent ou backup en erreur.

SMS repose sur une approche très directe et compatible avec un monitoring décentralisé :

– Bash pur.
– checks locaux.
– commandes système standard.
– sortie HTML minimale.
– configuration par fichiers texte.
– pas de daemon.
– pas de base de données.
– pas de dépendance applicative lourde.

Le script lit notamment :

/home/sx/.sx
/home/sx/data/process2monitor.txt
/home/sx/data/fs_list.txt

Le fichier /home/sx/.sx contient les variables nécessaires à certains checks, par exemple les identifiants SQL ou PostgreSQL.

Le fichier process2monitor.txt contient la liste des processus à surveiller.

Exemple :

apache2
fail2ban-server
memcached
php-fpm8.2
pure-ftpd
sshd

Le fichier fs_list.txt contient la liste des points de montage attendus.

Exemple :

/
 /datastore
 /datadrop/cd101

SMS peut être exécuté directement :

./sms.sh

Ou intégré dans une page PHP protégée :

<?php
function checkall()
{
        $homecheck = "/home/sx/data";
        $checkscript = "sms.sh";
        $check = "$homecheck/$checkscript";
        system("$check");
}
checkall();
?>

Note importante : le script doit être placé dans un répertoire non lisible directement par le serveur web. La page PHP appelle le script côté serveur, mais le script lui-même ne doit pas être exposé publiquement.

Exemple minimal pour le fichier de configuration :

loginsxmysql:sx
passsxmysql:xxxxxxxx

Pour PostgreSQL, le script peut utiliser :

postgresql_database:sx
postgresql_user:sx
postgresql_password:xxxxxxxx
postgresql_port:5432

Pour Redis :

redis_password:xxxxxxxx

Pour OpenSearch :

opensearch_password:xxxxxxxx
opensearch_security_enabled:1

Processus serveur :

SMS vérifie que chaque processus listé dans /home/sx/data/process2monitor.txt est actif via pgrep.

all_process_check
check_process

Réseau :

SMS peut vérifier la connectivité vers des IP définies, par exemple 1.1.1.1, 8.8.8.8 ou 127.0.0.1.

network_check "Internet" 1.1.1.1 8.8.8.8
network_check "localhost network" 127.0.0.1

DNS :

SMS vérifie la résolution DNS de domaines de référence.

dns_check google.com cloudflare.com

Filesystems :

SMS vérifie que les points de montage attendus sont bien présents.

fs_check yes

Stockage :

SMS vérifie l’espace disque et les inodes, avec seuils WARNING / ERROR.

storage_check 95 90 95 90

Dans cet exemple :

– erreur espace disque à 95%.
– warning espace disque à 90%.
– erreur inodes à 95%.
– warning inodes à 90%.

Mémoire :

SMS vérifie l’utilisation mémoire.

mem_check 95 90

Load average :

SMS calcule automatiquement le nombre de threads CPU et applique un seuil basé sur :

THREADS * 4

Si la charge dépasse le seuil, le script effectue une seconde mesure après une courte pause pour distinguer une charge élevée qui monte encore d’une charge élevée en train de redescendre.

load_check

Mises à jour système :

SMS vérifie la date de la dernière mise à jour APT à partir des logs /var/log/apt/history.log*.

check_update 10

Dans cet exemple, un warning est affiché si la dernière mise à jour date de plus de 10 jours.

MySQL / MariaDB :

SMS vérifie la connexion SQL, l’accès à la base sx et la capacité à lister les tables.

mysql_check $LOGINSXMYSQL $PASSSXMYSQL 0

Si un seuil de réplication différent de 0 est fourni, SMS vérifie également :

– Last_Errno.
– Seconds_Behind_Master.
– Slave_IO_Running.
– Slave_SQL_Running.

PostgreSQL :

SMS peut vérifier :

– disponibilité via pg_isready.
– login via psql.
– rôle du noeud : primary ou standby.

postgresql_check 127.0.0.1 5432

Réplication PostgreSQL :

SMS vérifie la réplication selon le rôle du noeud :

– sur un standby : état du WAL receiver.
– sur un primary : nombre de connexions standby en streaming.
– lag de réplication si disponible.

postgresql_replication_check 9600

Memcached :

memcached_check 127.0.0.1 11211

Redis :

SMS tente d’abord redis-cli si disponible, puis bascule sur une requête RESP minimale via /dev/tcp si nécessaire.

redis_check 127.0.0.1 6379

Le script sait distinguer :

– PONG.
– authentification requise.
– échec de connexion.

Postfix SMTP :

smtp_check 127.0.0.1 25

Elasticsearch / OpenSearch :

SMS peut vérifier un endpoint Elasticsearch / OpenSearch en HTTP, puis lire l’état du cluster.

elastic_open_check 127.0.0.1 9200

États gérés :

– HTTP 2xx/3xx : OK.
– HTTP 401/403 : WARNING, authentification requise.
– cluster green/yellow : OK.
– cluster red : ERROR.
– réponse inconnue : WARNING.

OpenSearch sécurisé :

SMS supporte aussi OpenSearch avec authentification admin et TLS.

opensearch_check 127.0.0.1 9200

Si la sécurité est activée mais que le mot de passe est absent, le script remonte un WARNING plutôt qu’un faux ERROR.

RAID logiciel :

SMS peut vérifier /proc/mdstat et détecter un RAID dégradé.

raid_check

ZFS :

SMS peut vérifier l’état des pools ZFS via zpool status -x.

zfs_check

Si zpool est absent, le check retourne une erreur lorsque le module est explicitement activé.

SMS intègre des checks spécifiques aux sauvegardes StackX.

Sauvegarde base de données :

Selon le type de base, SMS vérifie :

– sxbkpmdb pour MySQL / MariaDB.
– sxbkppgdb pour PostgreSQL.

Le script vérifie :

– fraîcheur du dernier log.
– présence du marqueur [INF] Done.
– présence d’un dump récent.
– détection d’un backup encore en cours.
– distinction entre pending, running, missing et error.

Sauvegarde fichiers :

SMS vérifie sxfilesbkp lorsque le module est installé et configuré.

Il contrôle notamment :

– présence des logs.
– fraîcheur des logs.
– présence du marqueur [INF] Done.
– présence du marqueur d’exécution de backup.
– configuration distante valide.

Utilisation :

backup_check 30 54

Dans cet exemple :

– warning si le dernier backup a plus de 30 heures.
– erreur si le dernier backup a plus de 54 heures.

Exemple de séquence utilisée en bas du script :

startpage "StackX Local monitoring"
title "StackX Monitoring System"
table_init
titlecheck "Server processes"
all_process_check
network_check "Internet" 1.1.1.1 8.8.8.8
network_check "localhost network" 127.0.0.1
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 0
memcached_check 127.0.0.1 11211
smtp_check 127.0.0.1 25
backup_check 30 54
check_update 10
table_end
endpage
log

Certains checks sont présents mais désactivés par défaut dans l’exemple final, afin d’être activés uniquement selon le profil du serveur :

#elastic_open_check 127.0.0.1 9200
#opensearch_check 127.0.0.1 9200
#redis_check 127.0.0.1 6379
#postgresql_check 127.0.0.1 5432
#postgresql_replication_check 9600
#raid_check
#zfs_check

SMS est pensé pour les besoins opérationnels de StackX : vérifier vite, localement, sans couche inutile, l’état réel d’un serveur.

L’objectif est d’avoir une vue locale fiable, immédiatement lisible, adaptée aux environnements StackX et utilisable de manière décentralisée. Ainsi n’importe quel système dans le monde, qu’il soit maison ou tier (exemple Pingdom / Solarwind), peut venir questionner la sortie et renvoyer une alerte en fonction des états retournés (WARNING, ERROR…)

Le script privilégie :

– la simplicité d’exécution.
– la lisibilité.
– l’absence de dépendances lourdes.
– la compatibilité avec des serveurs hétérogènes.
– la capacité à fonctionner même sur des environnements limités.
– une intégration facile dans les outils internes ScalarX.

SMS suit une logique pragmatique : si un service critique est arrêté, si un filesystem attendu n’est pas monté, si un backup n’a pas tourné, si la réplication est cassée, si la mémoire ou le stockage dépassent les seuils, l’information doit apparaître immédiatement.

– La sortie HTML est volontairement minimale et ancienne génération.
– Certains checks dépendent de commandes système disponibles localement.
– Les credentials SQL/PostgreSQL/OpenSearch doivent être correctement renseignés dans la configuration.
– Le script doit être protégé côté web et ne doit pas être exposé directement.
– La logique est orientée StackX et n’a pas vocation à devenir un agent de supervision générique universel.

– Ajouter un mode CLI texte en plus du rendu HTML.
– Ajouter un mode –quick pour limiter les checks aux éléments critiques.
– Ajouter un mode –full pour activer tous les checks disponibles.
– Ajouter une gestion plus fine des timeouts.
– Ajouter une sortie synthétique exploitable par cron ou par un agent externe.
– Ajouter de stackx-smsd sans toucher à sms.sh pour disposer d’un serveur autonome et éviter les impacts de mises à jour système.

Script : sms.sh

—
Christophe Casalegno (retrouvez tous mes réseaux sur : all.bo)