Skip to main content

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 nécessairesMedulla, aumais fonctionnementégalement deles laressources plateforme.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êtarrê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

    NousSur 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 :
    SelonTous les fonctionnalités installées et activées sur votre infrastructure Medulla, certainsces services peuventne nesont pas êtrenécessairement présents sur touschaque lesinstallation. serveurs.La liste de supervision doit être construite à partir des services réellement installés et activés sur chaque serveur.

    2.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 le service mmc-agent :

    systemctl status mmc-agent

    Pour vérifierobtenir simplementuniquement sison le service est actifé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

    3.5. Vérifier l'ensemble des services Medulla

    Pour effectuer rapidement un contrôle rapide 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

    LeExemple de résultat permet d'identifier rapidement les services actifs et ceux nécessitant une vérification.

    Exemple :

    [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.

    4.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

        5222

        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 servicesdifférents Medullacontrôles décrits dans cette documentation peuvent être supervisésintégrés avecdans votrela solutionplupart habituelledes solutions de monitoring.supervision.

          LeLes principecontrôles consistepeuvent àêtre vérifierregroupés régulièrementen queplusieurs chaquecatégories service:

          attendu
          estdansl'étatCaté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 :

          active

          Une alerte peut être générée lorsqu'un service passe dans un état différent, notammentIntervalle :

          inactive5 failedminutes
Alerte : après 3 échecs consécutifs

          Important :
          LaCes présencevaleurs d'unconstituent une recommandation générique et doivent être adaptées à votre niveau de service dépend du rôle du serveur et des fonctionnalités Medulla installées. La liste des services à superviservotre doit donc être adaptée à chaque serveurpolitique de votre infrastructure.supervision.

          5.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

          Vous pouvezConsultez ensuite consulter ses journaux avec :

          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

          6.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, il est recommandé de consulterconsultez 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.

          7.17. ServicesRésumé recommandéspar pourrôle lade supervisionserveur

          ServiceRôle SupervisionPrincipaux contrôles
          ejabberdServeur Medulla principal Recommandée
          CPU, RAM, disques, HTTP/HTTPS, mmc-agentagent, RecommandéeXMPP, services substitute, pulse-xmpp-agent-relaypackages, RecommandéePXE pulse2-register-pxe Selonselon configuration pulse2-package-serverServeur relais RecommandéeCPU, RAM, disques, pulse-xmpp-agent-relay, XMPP, Syncthing, repository, HTTP selon configuration pulse-xmpp-master-substitute-masterServeur MariaDB RecommandéeCPU, RAM, datadir, service MariaDB, connexions, erreurs, requêtes lentes, backups pulse-xmpp-master-substitute-loggerServeur MaxScale RecommandéeCPU, RAM, disques, pulse-xmpp-master-substitute-updatesservice RecommandéeMaxScale, ports de pulse-xmpp-master-substitute-assessor Recommandée pulse-xmpp-master-substitute-inventory Recommandée pulse-xmpp-master-substitute-deployment Recommandée pulse-xmpp-master-substitute-monitoring Recommandée pulse-xmpp-master-substitute-registration Recommandée pulse-xmpp-master-substitute-subscription Recommandéeconnexion

          Résumé18. Bonnes pratiques

          Pour superviser une infrastructure Medulla On-Premise :

          • surveillezadapter l'étatles des services Medulla nécessairescontrôles au rôle réel de chaque serveur ;
          • déclenchezsuperviser 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 lorsqu'sur un serviceseul attenduéchec n'est plus dans l'état activeponctuel ; utilisezsurveiller systemctlparticulièrement statusl'espace pourdisque obtenir un premier diagnosticdisponible ; consultezsurveiller les files de messages ejabberd ; superviser MariaDB au-delà du simple état du service ; consulter les journaux avec journalctl avant detout redémarrerredémarrage d'un service en; erreur.tester régulièrement le bon fonctionnement des alertes.

          Recommandation :
          IntégrezUne 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 servicesservices, Medullaressources àsystème, votreports outilréseau, métriques XMPP, performances MariaDB et espaces de supervision afin d'être alerté automatiquement en cas d'arrêt d'un composant de la plateforme.stockage. Adaptez laensuite listeles des services surveilléscontrôles au rôle et aux fonctionnalités réellement installées sur chaque serveur Medulla.de votre infrastructure.

          Back to top