Skip to main content

Health Check d’un serveur Medulla

Cette procédure permet de vérifier rapidement le bon fonctionnement d'un serveur Medulla et de ses principaux composants.

Elle peut notamment être utilisée :

  • après un redémarrage du serveur ;
  • après une opération de maintenance ;
  • après une mise à jour de Medulla ;
  • après une modification de configuration ;
  • lorsqu'un dysfonctionnement général de la plateforme est suspecté.

Information :
Ce Health Check a pour objectif de confirmer rapidement que les principaux composants Medulla sont opérationnels. Si l'un des contrôles échoue, consultez les logs du composant concerné avant de redémarrer ou modifier le service.

1. Vérifier l'accès à l'interface Medulla

Commencez par vous connecter à l'interface Web Medulla.

Vérifiez notamment que :

  • la page de connexion est accessible ;
  • l'authentification fonctionne ;
  • l'interface principale se charge correctement ;
  • les machines apparaissent dans l'inventaire.

Résultat attendu :
L'administrateur peut se connecter à Medulla et consulter normalement l'inventaire des machines.

2. Vérifier l'état des principaux services Medulla

Vérifiez l'état des principaux services Medulla avec systemctl.

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

Pour un contrôle plus rapide, utilisez :

systemctl is-active NOM_DU_SERVICE

Le résultat attendu est :

active

Attention :
Selon l'installation Medulla et les fonctionnalités activées, certains services peuvent ne pas être présents. L'absence d'un service optionnel n'indique donc pas nécessairement un dysfonctionnement.

3. Identifier rapidement les services en erreur

Pour rechercher les services actuellement en échec :

systemctl --failed

Si un service Medulla apparaît dans cette liste, consultez son état :

systemctl status NOM_DU_SERVICE

puis ses derniers journaux :

journalctl -u NOM_DU_SERVICE -n 100

Conseil :
Ne redémarrez pas systématiquement un service en erreur avant d'avoir consulté ses logs. Les messages présents avant le redémarrage peuvent être essentiels pour identifier la cause de l'incident.

4. Vérifier ejabberd et XMPP

Medulla utilise XMPP pour la communication avec ses agents et plusieurs de ses composants internes.

Vérifiez que le service ejabberd fonctionne :

systemctl is-active ejabberd

Le résultat attendu est :

active

Consultez ensuite le nombre d'utilisateurs actuellement connectés :

/usr/bin/ejabberdctl stats onlineusers

et le nombre d'utilisateurs enregistrés :

/usr/bin/ejabberdctl stats registeredusers

Pour afficher les utilisateurs actuellement connectés :

ejabberdctl connected_users

Résultat attendu :
ejabberd est actif et les agents et composants Medulla attendus sont connectés à XMPP.

5. Vérifier MariaDB

Vérifiez que le service MariaDB est actif :

systemctl is-active mariadb

Le résultat attendu est :

active

Vérifiez ensuite que MariaDB accepte correctement les requêtes :

mariadb -e "SELECT 1;"

Le résultat attendu contient :

1
1

6. Vérifier le serveur de packages

Vérifiez le service du serveur de packages :

systemctl is-active pulse2-package-server

Le résultat attendu est :

active

Vérifiez également depuis l'interface Medulla qu'un package existant est correctement visible.

7. Vérifier le serveur relais

Si le serveur joue également le rôle de relais, vérifiez :

systemctl is-active pulse-xmpp-agent-relay

Le résultat attendu est :

active

Dans une architecture comportant plusieurs relais, vérifiez également que les relais attendus sont accessibles.

Une indisponibilité d'un relais peut notamment provoquer :

ABORT RELAY DOWN
ABORT ALTERNATIVE RELAYS DOWN

8. Vérifier Syncthing

Lorsque Syncthing est utilisé pour la synchronisation des packages, vérifiez son état :

systemctl is-active syncthing@syncthing

Le résultat attendu est :

active

Attention :
Un service Syncthing actif ne garantit pas à lui seul que tous les packages sont correctement synchronisés. En cas d'erreur de transfert ou de package absent sur un relais, contrôlez également la synchronisation effective.

9. Vérifier l'espace disque

Vérifiez l'espace disponible sur les systèmes de fichiers :

df -h

Portez une attention particulière au système de fichiers contenant les packages de télédistribution.

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.

10. Vérifier les ressources du serveur

Contrôlez la mémoire disponible :

free -h

Contrôlez ensuite la charge du serveur :

uptime

Pour une vue dynamique :

top

Vérifiez notamment :

  • la mémoire disponible ;
  • l'utilisation du swap ;
  • la charge système ;
  • la présence d'un processus consommant anormalement des ressources.

11. Vérifier qu'une machine communique avec Medulla

Depuis l'interface Medulla, sélectionnez une machine connue comme étant allumée et vérifiez qu'elle apparaît en ligne.

Ce contrôle permet de valider simplement la chaîne de communication :

Agent
  ↓
Réseau
  ↓
XMPP / ejabberd
  ↓
Medulla

Si toutes les machines apparaissent hors ligne alors qu'elles sont allumées, recherchez en priorité un problème global de communication ou de service.

12. Vérifier l'inventaire

Sélectionnez une machine de test et vérifiez que ses informations d'inventaire sont disponibles dans Medulla.

Contrôlez par exemple :

  • le hostname ;
  • le système d'exploitation ;
  • les informations réseau ;
  • les logiciels installés.

Résultat attendu :
Les informations d'inventaire de la machine sont disponibles et cohérentes.

13. Tester une télédistribution

Après une maintenance importante ou une mise à jour, il est recommandé d'effectuer une télédistribution sur une machine de test.

Utilisez de préférence un package simple et sans impact fonctionnel important.

Le déploiement doit se terminer par :

DEPLOYMENT SUCCESS

Ce test valide notamment :

  • la communication avec l'agent ;
  • l'affectation du relais ;
  • la disponibilité du package ;
  • le transfert ;
  • l'exécution sur la machine cible.

14. Consulter les erreurs récentes

Même lorsque tous les services sont actifs, recherchez les erreurs récentes dans les journaux.

Pour un service :

journalctl -u NOM_DU_SERVICE -n 100

Pour afficher les erreurs depuis le dernier démarrage :

journalctl -p err -b

Information :
Un service peut être active tout en rencontrant des erreurs fonctionnelles. L'état systemd ne suffit donc pas toujours à valider le bon fonctionnement du composant.

15. Checklist rapide

Contrôle Résultat attendu
Interface Web Accessible
Authentification Fonctionnelle
Services Medulla Actifs
systemctl --failed Aucun service Medulla critique en erreur
ejabberd Actif
XMPP Composants attendus connectés
MariaDB Active et accessible
Serveur de packages Actif
Serveur relais Actif et accessible
Syncthing Actif si utilisé
Espace disque Espace disponible suffisant
Mémoire / charge Pas de saturation
Machine de test En ligne
Inventaire Disponible
Télédistribution de test DEPLOYMENT SUCCESS

16. Que faire si un contrôle échoue ?

Problème constaté Diagnostic à poursuivre
Service Medulla inactif Consulter systemctl status puis journalctl
ejabberd indisponible Diagnostiquer le service XMPP
Composant absent de connected_users Diagnostiquer sa connexion XMPP
MariaDB indisponible Consulter l'état et les logs MariaDB
Relais indisponible Diagnostiquer le serveur relais
Package absent d'un relais Contrôler Syncthing et la synchronisation
Machine hors ligne Consulter la FAQ « Pourquoi une machine apparaît-elle hors ligne ? »
Machine non enregistrée Consulter la FAQ « Pourquoi une machine ne s'enregistre-t-elle pas ? »
Télédistribution en erreur Consulter le statut et l'audit du déploiement

17. Résumé

Un serveur Medulla peut être considéré comme globalement opérationnel lorsque :

  • l'interface Web est accessible ;
  • les principaux services sont actifs ;
  • ejabberd fonctionne ;
  • les composants attendus sont connectés à XMPP ;
  • MariaDB fonctionne ;
  • les serveurs relais sont disponibles ;
  • les packages sont accessibles et synchronisés ;
  • les ressources système ne sont pas saturées ;
  • au moins une machine communique normalement avec Medulla ;
  • l'inventaire fonctionne ;
  • une télédistribution de test peut être effectuée avec succès.

Recommandation :
Après une maintenance ou une mise à jour importante, ne vous limitez pas à vérifier que les services sont active. Validez également le fonctionnement de bout en bout avec une machine en ligne, une remontée d'inventaire et une télédistribution de test.

Back to top