Supervision des services Medulla

Dans le cadre de la supervision d'une infrastructure Medulla On-Premise, il est recommandé de surveiller non seulement l'état des principaux services Medulla, mais également les ressources système, les ports réseau, les composants XMPP, les bases MariaDB et, selon l'architecture, MaxScale et les serveurs relais.

Cette supervision peut être intégrée à votre outil de monitoring habituel afin de détecter rapidement l'arrêt, la dégradation ou le dysfonctionnement d'un composant Medulla.

Information :
Les éléments à superviser dépendent du rôle de chaque serveur. Un serveur principal, un relais, un serveur MariaDB ou un serveur MaxScale ne disposent pas nécessairement des mêmes services.

1. Principes généraux de supervision

Pour une infrastructure Medulla, nous recommandons de superviser au minimum les éléments suivants :

disponibilité du serveur ;
charge CPU ;
utilisation de la mémoire ;
occupation des systèmes de fichiers ;
disponibilité de l'interface Web ;
état des services Medulla ;
connectivité sur les principaux ports utilisés ;
état du service XMPP ejabberd ;
état et performances de MariaDB lorsque la base est hébergée sur le serveur ;
état de MaxScale lorsque celui-ci est utilisé ;
occupation des espaces de stockage utilisés pour les packages, données et sauvegardes.

Fréquence de contrôle recommandée

Pour les services critiques, un contrôle toutes les 5 minutes constitue une base raisonnable.

Afin d'éviter de déclencher des alertes sur une indisponibilité très ponctuelle, il est possible de déclencher l'alerte après plusieurs échecs consécutifs.

Par exemple :

Contrôle : toutes les 5 minutes
Alerte : après 3 contrôles consécutifs en erreur

Recommandation :
Les fréquences et seuils doivent être adaptés aux contraintes de disponibilité et à l'architecture de votre organisation.

2. Supervision système

Quel que soit le rôle du serveur Medulla, les ressources système doivent être supervisées.

Élément	Contrôle recommandé
CPU	Charge et utilisation processeur
Mémoire	Utilisation RAM et mémoire disponible
Systèmes de fichiers	Occupation et espace libre
Système d'exploitation	Disponibilité et informations système
Interface Web	Contrôle HTTP/HTTPS de l'URL Medulla

Important :
Une attention particulière doit être portée aux partitions contenant les bases de données, les packages de télédistribution, les sauvegardes et les journaux. Un espace disque saturé peut provoquer plusieurs dysfonctionnements simultanés de Medulla.

3. Services Medulla à superviser

Sur un serveur Medulla principal, nous recommandons de surveiller les services suivants lorsqu'ils sont installés :

ejabberd
mmc-agent
pulse-xmpp-agent-relay
pulse2-register-pxe
pulse2-package-server
pulse-xmpp-master-substitute-master
pulse-xmpp-master-substitute-logger
pulse-xmpp-master-substitute-updates
pulse-xmpp-master-substitute-assessor
pulse-xmpp-master-substitute-inventory
pulse-xmpp-master-substitute-deployment
pulse-xmpp-master-substitute-monitoring
pulse-xmpp-master-substitute-registration
pulse-xmpp-master-substitute-subscription

Selon votre version et les fonctionnalités installées, d'autres services peuvent également être présents, notamment :

pulse-xmpp-master-substitute-reconfigurator

Information :
Tous ces services ne sont pas nécessairement présents sur chaque installation. La liste de supervision doit être construite à partir des services réellement installés et activés sur chaque serveur.

4. Vérifier l'état d'un service

La commande systemctl permet de vérifier manuellement l'état d'un service.

Par exemple, pour vérifier mmc-agent :

systemctl status mmc-agent

Pour obtenir uniquement son état :

systemctl is-active mmc-agent

Lorsque le service fonctionne normalement, la commande retourne :

active

Les états suivants doivent notamment être considérés comme anormaux pour un service attendu :

inactive
failed

5. Vérifier l'ensemble des services Medulla

Pour effectuer rapidement un contrôle des principaux services, vous pouvez utiliser le script suivant :

#!/bin/bash

SERVICES="
ejabberd
mmc-agent
pulse-xmpp-agent-relay
pulse2-register-pxe
pulse2-package-server
pulse-xmpp-master-substitute-master
pulse-xmpp-master-substitute-logger
pulse-xmpp-master-substitute-updates
pulse-xmpp-master-substitute-assessor
pulse-xmpp-master-substitute-inventory
pulse-xmpp-master-substitute-deployment
pulse-xmpp-master-substitute-monitoring
pulse-xmpp-master-substitute-registration
pulse-xmpp-master-substitute-subscription
"

for SERVICE in $SERVICES
do
    if systemctl is-active --quiet "$SERVICE"; then
        echo "[OK] $SERVICE"
    else
        echo "[ERROR] $SERVICE"
    fi
done

Exemple de résultat :

[OK] ejabberd
[OK] mmc-agent
[OK] pulse-xmpp-agent-relay
[ERROR] pulse2-package-server
[OK] pulse-xmpp-master-substitute-master

Attention :
Ce script utilise une liste générique. Retirez les services qui ne sont pas installés sur le serveur supervisé afin d'éviter de générer de faux incidents.

6. Supervision d'ejabberd

ejabberd est un composant important de l'architecture de communication Medulla. Il est recommandé de surveiller à la fois son service système et plusieurs indicateurs XMPP.

État du service

systemctl status ejabberd

Ou :

systemctl is-active ejabberd

Nombre d'utilisateurs connectés

/usr/bin/ejabberdctl stats onlineusers

Cette valeur peut être utilisée comme indicateur de fonctionnement et suivie dans le temps.

Nombre d'utilisateurs enregistrés

/usr/bin/ejabberdctl stats registeredusers

Une variation importante ou inattendue de cette valeur peut être utilisée comme signal de supervision.

Messages hors ligne

Le nombre de messages en attente peut également être supervisé pour les différents comptes techniques Medulla.

Exemple :

/usr/bin/ejabberdctl get_offline_count NOM_DU_COMPTE pulse

Une augmentation importante et persistante du nombre de messages hors ligne peut indiquer qu'un composant Medulla ne consomme plus correctement ses messages.

Recommandation :
Les valeurs onlineusers, registeredusers et les files de messages hors ligne sont particulièrement intéressantes à historiser afin de détecter des évolutions anormales, même lorsqu'aucun service n'est arrêté.

7. Supervision des ports du serveur Medulla

En complément de la supervision des services, il est recommandé de contrôler que les ports nécessaires sont bien en écoute et accessibles depuis les équipements concernés.

Selon l'architecture et les fonctionnalités utilisées, les ports suivants peuvent notamment être supervisés :

Port	Utilisation
`5222`	Communication XMPP
`7080`	Service MMC
`8443`	Service HTTPS Medulla selon configuration
`2222`	Service SSH selon architecture
`22000`	Synchronisation / dépendance Medulla selon configuration
`23000`	Synchronisation / dépendance Medulla selon configuration
`57040`	Agent master selon architecture

Important :
Cette liste est générique. Les ports réellement utilisés dépendent de votre architecture Medulla, des fonctionnalités activées et du rôle du serveur. Ne déclenchez pas d'alerte sur un port qui n'est pas attendu sur le serveur concerné.

8. Supervision du serveur Web et de Guacamole

La disponibilité de l'interface Web doit être supervisée avec un contrôle HTTP ou HTTPS.

Il est recommandé de vérifier :

que le serveur Web fonctionne ;
que l'URL Medulla répond ;
que le code HTTP retourné correspond au comportement attendu.

Selon l'installation, l'état du service Web peut par exemple être contrôlé avec :

systemctl status httpd

ou avec le nom du service Web utilisé par votre installation.

Guacamole

La disponibilité du composant Guacamole peut également être contrôlée à travers son URL locale.

Exemple de point de contrôle :

http://localhost:8081/guacamole/

Dans une configuration où l'accès direct à cette URL n'est pas autorisé, une réponse HTTP 403 peut constituer le comportement attendu et confirmer que le service répond.

9. Supervision de Syncthing

Lorsque Syncthing est utilisé dans l'architecture Medulla, surveillez son service :

systemctl status syncthing@syncthing

Les ports associés peuvent également être supervisés selon la configuration :

22000
23000
8384

Information :
Les ports à surveiller doivent correspondre à la configuration Syncthing réellement utilisée par votre infrastructure.

10. Supervision d'un serveur relais Medulla

Un serveur relais Medulla nécessite généralement une supervision plus limitée que le serveur principal.

Selon les fonctions activées, nous recommandons notamment de surveiller :

pulse-xmpp-agent-relay ;
ejabberd lorsque celui-ci est présent sur le relais ;
Syncthing lorsque celui-ci est utilisé ;
le serveur Web lorsque le relais distribue des packages ;
la connectivité XMPP ;
l'espace disque utilisé par le repository de télédistribution.

Service Relay

systemctl status pulse-xmpp-agent-relay

Port XMPP

Syncthing

systemctl status syncthing@syncthing

Espace disque

Le système de fichiers contenant les packages de télédistribution doit être surveillé afin de garantir qu'un espace suffisant reste disponible.

Selon l'installation, il peut notamment s'agir de :

/telediffusion

Important :
Une saturation du repository d'un relais peut empêcher la synchronisation ou la distribution de nouveaux packages sans nécessairement provoquer l'arrêt d'un service.

11. Supervision de MariaDB

Lorsque MariaDB est hébergé sur une infrastructure dédiée ou sur le serveur Medulla, il est recommandé de superviser son service, ses connexions, ses erreurs et les ressources utilisées.

État du service

systemctl status mariadb

Ou :

systemctl is-active mariadb

Éléments recommandés

Indicateur	Objectif
Service MariaDB	Vérifier que le service est actif
Temps de connexion	Détecter une dégradation des performances
Connexions abandonnées	Détecter des erreurs ou problèmes réseau
Threads connectés	Surveiller la consommation des connexions disponibles
Fichiers ouverts	Détecter l'approche des limites système ou MariaDB
Requêtes lentes	Détecter les dégradations de performances
Journal d'erreurs MariaDB	Détecter les erreurs serveur
Occupation du datadir	Prévenir une saturation disque
Occupation du stockage des sauvegardes	Prévenir une saturation du stockage de backup

Nombre de connexions

Il est notamment recommandé de surveiller le nombre de connexions actives par rapport au nombre maximal de connexions autorisées.

Une alerte peut être déclenchée lorsque l'utilisation approche une proportion importante de la capacité maximale.

Exemple :
Un seuil d'alerte peut être positionné avant d'atteindre 100 % de max_connections, afin de disposer d'une marge permettant d'intervenir avant saturation.

Requêtes lentes

Le nombre de requêtes lentes peut être historisé afin de détecter une dégradation progressive des performances de la base.

Erreurs MariaDB

Il est recommandé de surveiller le journal d'erreurs MariaDB et de déclencher une alerte lorsqu'une nouvelle erreur significative apparaît.

12. Supervision de MaxScale

Lorsque l'architecture Medulla utilise MariaDB MaxScale, son état doit également être supervisé.

État du service

systemctl status maxscale

Ou :

systemctl is-active maxscale

Ports

Selon la configuration MaxScale utilisée, les ports suivants peuvent notamment être supervisés :

Port	Utilisation
`4006`	Connexion Read / Write selon configuration
`4008`	Connexion Read Only selon configuration

Information :
Les ports MaxScale doivent être adaptés à la configuration réelle définie dans votre infrastructure.

13. Supervision des espaces de stockage

La disponibilité des services ne suffit pas à garantir le bon fonctionnement de Medulla. Les systèmes de fichiers doivent également être supervisés.

Une attention particulière doit être portée :

à la partition racine / ;
au répertoire temporaire /tmp ;
au datadir MariaDB ;
au stockage des sauvegardes ;
au repository de télédistribution ;
aux volumes contenant les logs et données Medulla.

Important :
Définissez des seuils d'alerte suffisamment tôt pour permettre une intervention avant saturation complète du système de fichiers.

14. Intégration dans un outil de supervision

Les différents contrôles décrits dans cette documentation peuvent être intégrés dans la plupart des solutions de supervision.

Les contrôles peuvent être regroupés en plusieurs catégories :

Catégorie	Exemples
Système	CPU, mémoire, espace disque, disponibilité OS
Services	systemctl is-active
Réseau	Ports TCP, disponibilité HTTP/HTTPS
XMPP	ejabberd, utilisateurs connectés, files de messages
Base de données	MariaDB, connexions, erreurs, requêtes lentes
Proxy DB	MaxScale et ports associés
Stockage	Datadir, sauvegardes, télédistribution

Pour les services critiques, une politique de type suivante peut être utilisée :

Intervalle : 5 minutes
Alerte : après 3 échecs consécutifs

Important :
Ces valeurs constituent une recommandation générique et doivent être adaptées à votre niveau de service et à votre politique de supervision.

15. Consulter les journaux d'un service

Lorsqu'un service est arrêté ou en erreur, commencez par vérifier son état :

systemctl status NOM_DU_SERVICE

Consultez ensuite ses journaux :

journalctl -u NOM_DU_SERVICE

Pour afficher les 100 événements les plus récents :

journalctl -u NOM_DU_SERVICE -n 100

Par exemple :

journalctl -u mmc-agent -n 100

Pour suivre les événements en temps réel :

journalctl -u NOM_DU_SERVICE -f

16. Redémarrer un service

Après analyse du problème, un service peut si nécessaire être redémarré avec :

systemctl restart NOM_DU_SERVICE

Par exemple :

systemctl restart mmc-agent

Vérifiez ensuite son état :

systemctl status mmc-agent

Attention :
Avant de redémarrer un service en erreur, consultez son état et ses journaux afin d'identifier l'origine du problème. Un redémarrage systématique peut masquer un problème récurrent sans en traiter la cause.

17. Résumé par rôle de serveur

Rôle	Principaux contrôles
Serveur Medulla principal	CPU, RAM, disques, HTTP/HTTPS, mmc-agent, XMPP, services substitute, packages, PXE selon configuration
Serveur relais	CPU, RAM, disques, pulse-xmpp-agent-relay, XMPP, Syncthing, repository, HTTP selon configuration
Serveur MariaDB	CPU, RAM, datadir, service MariaDB, connexions, erreurs, requêtes lentes, backups
Serveur MaxScale	CPU, RAM, disques, service MaxScale, ports de connexion

18. Bonnes pratiques

adapter les contrôles au rôle réel de chaque serveur ;
superviser les services mais également les ressources système et les ports ;
historiser les métriques importantes afin de détecter les dérives progressives ;
éviter de déclencher une alerte sur un seul échec ponctuel ;
surveiller particulièrement l'espace disque disponible ;
surveiller les files de messages ejabberd ;
superviser MariaDB au-delà du simple état du service ;
consulter les journaux avant tout redémarrage d'un service ;
tester régulièrement le bon fonctionnement des alertes.

Recommandation :
Une supervision Medulla efficace ne doit pas se limiter à vérifier que les processus sont démarrés. Il est recommandé de combiner la surveillance des services, ressources système, ports réseau, métriques XMPP, performances MariaDB et espaces de stockage. Adaptez ensuite les contrôles au rôle et aux fonctionnalités réellement installées sur chaque serveur de votre infrastructure.