Skip to main content

Où trouver les logs Medulla ?

Medulla utilise plusieurs journaux permettant de diagnostiquer le fonctionnement des agents, des services du serveur, des déploiements, de l'enregistrement des machines et des mises à jour.

Le journal à consulter dépend du composant ou de la fonctionnalité concernée.

Information :
Avant de redémarrer un service ou de modifier sa configuration, il est recommandé de consulter les journaux correspondants afin d'identifier l'origine du problème.


1. Tableau récapitulatif des principaux logs Medulla

Fonction Journal / commande Utilisation
Agent Medulla Windows C:\Program Files\Medulla\var\log\xmpp-agent-machine.log Connexion, enregistrement, reconfiguration et fonctionnement de l'agent
Attribution des relais /var/log/mmc/master-asse.log Attribution des machines aux serveurs relais
Enregistrement des machines /var/log/mmc/master-reg.log Enregistrement et réenregistrement des agents
Windows Updates /var/log/mmc/master-upd.log Traitement des KB et recherche des mises à jour
Services Medulla journalctl -u NOM_DU_SERVICE Diagnostic d'un service systemd
SSH Windows C:\ProgramData\ssh\logs\ Diagnostic du serveur OpenSSH Windows

2. Logs de l'agent Medulla sur Windows

Sur une machine Windows, le journal principal de l'agent Medulla est :

C:\Program Files\Medulla\var\log\xmpp-agent-machine.log

Ce fichier permet notamment de diagnostiquer :

  • le démarrage de l'agent ;
  • la connexion de l'agent à Medulla ;
  • l'enregistrement de la machine ;
  • les reconfigurations de l'agent ;
  • les informations envoyées par l'agent ;
  • la remontée des KB Windows ;
  • certains problèmes rencontrés pendant un déploiement.

Rechercher une reconfiguration de l'agent

Le message suivant indique le lancement d'une reconfiguration :

We start a reconfiguration of the medulla agent

Pour rechercher ce message depuis Windows :

find /c "We start a reconfiguration of the medulla agent" "C:\Program Files\Medulla\var\log\xmpp-agent-machine.log"

Un nombre important d'occurrences sur une courte période peut indiquer que l'agent se reconfigure de manière répétée.


3. Logs d'attribution des serveurs relais

Les opérations liées à l'attribution d'une machine à un serveur relais peuvent être retrouvées dans :

/var/log/mmc/master-asse.log

Ce journal est notamment utile pour diagnostiquer :

  • l'attribution d'un relais à une machine ;
  • les changements d'affectation ;
  • les reconfigurations anormalement fréquentes ;
  • les problèmes liés aux règles d'attribution.

Afficher les dernières lignes

tail -n 100 /var/log/mmc/master-asse.log

Suivre le journal en temps réel

tail -f /var/log/mmc/master-asse.log

Rechercher une machine

grep -i "NOM_DE_LA_MACHINE" /var/log/mmc/master-asse.log

Identifier les machines reconfigurées plusieurs fois

Le document d'exploitation fournit également la commande suivante pour compter les reconfigurations enregistrées dans la journée :

grep "$(date +'%Y-%m-%d') .*Configuring machine" /var/log/mmc/master-asse.log* | awk '{print $NF}' | sort | uniq -c | sort -n

Cette commande permet notamment de repérer une machine qui serait reconfigurée de manière anormalement fréquente.


4. Logs d'enregistrement des machines

L'enregistrement des machines est journalisé dans :

/var/log/mmc/master-reg.log

Ce journal est particulièrement utile lorsqu'une machine :

  • ne s'enregistre pas dans Medulla ;
  • met anormalement longtemps à apparaître ;
  • se réenregistre régulièrement ;
  • présente une incohérence entre ses interfaces réseau et son enregistrement.

Afficher les dernières lignes

tail -n 100 /var/log/mmc/master-reg.log

Suivre les enregistrements en temps réel

tail -f /var/log/mmc/master-reg.log

Rechercher une machine

grep -i "NOM_DE_LA_MACHINE" /var/log/mmc/master-reg.log

Compter les enregistrements des machines

La commande suivante permet de retrouver le nombre d'enregistrements des machines sur la journée :

grep "$(date +'%Y-%m-%d') .*Registering machine" /var/log/mmc/master-reg.log* | cut -f 8 -d ' ' | cut -f 1 -d'/' | sort | uniq -c | sort -n

Elle peut notamment être utilisée pour identifier une machine qui s'enregistre anormalement souvent.


5. Logs du module Windows Updates

Les traitements liés aux mises à jour Windows peuvent être retrouvés dans :

/var/log/mmc/master-upd.log

Ce journal permet notamment de vérifier les informations transmises par les machines au module Updates.

Vérifier la remontée des KB depuis la machine

Dans le journal de l'agent Windows, la liste des KB installées peut apparaître sous la forme :

"kb_list": "(5037592,5003791,5026037,...)"

Pour rechercher cette information :

findstr "kb_list" "C:\Program Files\Medulla\var\log\xmpp-agent-machine.log"

Vérifier la réception des KB sur le serveur

Lorsque le niveau de log du composant Updates est en DEBUG, la liste des KB installées peut être retrouvée dans :

/var/log/mmc/master-upd.log

Par exemple :

Installed KB list: (5037592,5003791,5026037,...)

Pour rechercher ces lignes :

grep "Installed KB list" /var/log/mmc/master-upd.log

Information :
La comparaison entre le kb_list présent sur l'agent et la liste reçue dans master-upd.log permet de vérifier que les informations Windows Updates sont correctement transmises jusqu'au serveur.


6. Journaux des services Medulla avec journalctl

Les services gérés par systemd peuvent être diagnostiqués avec la commande journalctl.

Consulter les logs d'un service

journalctl -u NOM_DU_SERVICE

Par exemple :

journalctl -u mmc-agent

Afficher les 100 derniers événements

journalctl -u NOM_DU_SERVICE -n 100

Exemple :

journalctl -u mmc-agent -n 100

Suivre un service en temps réel

journalctl -u NOM_DU_SERVICE -f

Afficher les logs depuis le dernier démarrage

journalctl -u NOM_DU_SERVICE -b

Conseil :
Lorsqu'un service Medulla est en erreur, commencez par consulter son état avec systemctl status, puis utilisez journalctl pour obtenir le détail des événements.


7. Vérifier l'état d'un service avant de consulter ses logs

Avant d'analyser les journaux, vérifiez l'état du service concerné :

systemctl status NOM_DU_SERVICE

Par exemple :

systemctl status mmc-agent

Pour obtenir uniquement son état :

systemctl is-active mmc-agent

Un service fonctionnant normalement retourne :

active

Les états suivants nécessitent une analyse :

inactive
failed

8. Logs SSH sur les machines Windows

Lorsque le problème concerne la connexion SSH à une machine Windows, commencez par vérifier l'état du service :

sc query sshd

Les journaux OpenSSH peuvent ensuite être consultés avec :

powershell Get-Content C:\ProgramData\ssh\logs\*.log

Ces journaux peuvent notamment être utiles lors d'erreurs telles que :

Permission denied

ssh_exchange_identification: read: Connection reset by peer

Information :
Les problèmes SSH et ceux liés au compte pulseuser peuvent nécessiter des contrôles complémentaires sur la machine Windows.


9. Rechercher une erreur dans un journal

La commande grep permet de rechercher rapidement une information dans les logs du serveur.

Rechercher une machine

grep -i "NOM_DE_LA_MACHINE" /var/log/mmc/NOM_DU_LOG.log

Rechercher une erreur

grep -i "error" /var/log/mmc/NOM_DU_LOG.log

Rechercher plusieurs types d'erreurs

grep -Ei "error|warning|failed|abort" /var/log/mmc/NOM_DU_LOG.log

Inclure les fichiers de logs archivés

grep -i "NOM_DE_LA_MACHINE" /var/log/mmc/NOM_DU_LOG.log*

Conseil :
Lors d'un incident, recherchez si possible le nom de la machine et l'heure exacte du problème afin de limiter le volume d'informations à analyser.


10. Quel log consulter selon le problème ?

Problème Premier journal à consulter
Machine hors ligne C:\Program Files\Medulla\var\log\xmpp-agent-machine.log
Machine qui ne s'enregistre pas /var/log/mmc/master-reg.log puis log de l'agent
Machine qui se reconfigure régulièrement /var/log/mmc/master-asse.log et log de l'agent
Mauvaise attribution à un relais /var/log/mmc/master-asse.log
Windows Updates / KB non remontées C:\Program Files\Medulla\var\log\xmpp-agent-machine.log puis /var/log/mmc/master-upd.log
Service Medulla en erreur journalctl -u NOM_DU_SERVICE
Problème SSH Windows C:\ProgramData\ssh\logs\

11. Augmenter temporairement le niveau de logs

Lorsque les informations disponibles dans les journaux ne sont pas suffisantes pour identifier l'origine d'un problème, certains composants Medulla peuvent être temporairement configurés avec un niveau de journalisation DEBUG.

Attention :
Le niveau DEBUG génère une quantité beaucoup plus importante de logs. Il doit être utilisé temporairement pendant le diagnostic puis désactivé une fois les informations nécessaires collectées.

La procédure complète est décrite dans la documentation :

Activer temporairement les logs DEBUG de Medulla


12. Bonnes pratiques de diagnostic

  • identifier précisément la machine, le relais ou le service concerné ;
  • noter la date et l'heure de l'incident ;
  • commencer par les journaux correspondant à la fonctionnalité concernée ;
  • rechercher le nom de la machine dans les logs lorsque cela est possible ;
  • consulter l'état du service avant de le redémarrer ;
  • conserver les logs correspondant à la période de l'incident ;
  • n'activer le niveau DEBUG que pendant la durée nécessaire au diagnostic.

Recommandation :
Pour diagnostiquer efficacement un incident Medulla, commencez par identifier le composant concerné, puis consultez son journal et recherchez les événements correspondant à l'heure exacte du problème. Le croisement des logs de la machine cliente et du serveur permet souvent d'identifier rapidement à quelle étape la communication ou le traitement a échoué.