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