Débogage monit

Je trouve que le débogage est une douleur majeure. L’environnement shell de Monit ne contient pratiquement rien (pas de chemin ou d’autres variables d’environnement). De plus, il n’y a pas de fichier journal que je puisse trouver.

Le problème est que, si la commande de démarrage ou d’arrêt du script de vérification échoue, il est difficile de discerner ce qui ne va pas. Souvent, il n’est pas aussi simple que d’exécuter la commande sur le shell car l’environnement shell est différent de l’environnement shell monit.

Quelles sont les techniques que les gens utilisent pour déboguer les configurations monit?

Par exemple, je serais heureux d’avoir un shell monit, de tester mes scripts ou un fichier journal pour voir ce qui ne va pas.

J’ai eu le même problème. L’utilisation de l’option de ligne de commande détaillée de monit aide un peu, mais j’ai trouvé que le meilleur moyen était de créer un environnement aussi similaire que possible à l’environnement monitoire et d’exécuter le programme start / stop à partir de là.

# monit runs as superuser $ sudo su # the -i option ignores the inherited environment # this PATH is what monit supplies by default $ env -i PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/sh # try running start/stop program here $ 

J’ai constaté que les problèmes les plus courants étaient liés aux variables d’environnement (en particulier PATH ) ou aux permissions. Vous devriez vous rappeler que le monit est généralement root.

Aussi, si vous utilisez as uid myusername dans votre configuration de as uid myusername , vous devez alors passer à myusername utilisateur avant d’effectuer le test.

J’espère que ça aide.

Assurez-vous de toujours vérifier votre configuration et de surveiller vos processus à la main avant de laisser tout gérer. systat (1), top (1) et ps (1) sont vos amis pour déterminer l’utilisation et les limites des ressources. Connaître le processus que vous surveillez est également essentiel.

En ce qui concerne les scripts de démarrage et d’arrêt, j’utilise un script wrapper pour redirect la sortie et inspecter l’environnement et d’autres variables. Quelque chose comme ça :

 $ cat monit-wrapper.sh #!/bin/sh { echo "MONIT-WRAPPER date" date echo "MONIT-WRAPPER env" env echo "MONIT-WRAPPER $@" $@ R=$? echo "MONIT-WRAPPER exit code $R" } >/tmp/monit.log 2>&1 

Puis dans monit:

 start program = "/home/billitch/bin/monit-wrapper.sh my-real-start-script and args" stop program = "/home/billitch/bin/monit-wrapper.sh my-real-stop-script and args" 

Vous devez toujours savoir quelles informations vous voulez dans le wrapper, telles que les informations de processus, les identifiants, les limites de ressources système, etc.

monit -c /path/to/your/config -v

Par défaut, surveillez les journaux dans le journal des messages de votre système et vous pouvez y accéder pour voir ce qui se passe.

De plus, selon votre configuration, vous vous connectez peut-être à un autre endroit

 tail -f /var/log/monit 

http://mmonit.com/monit/documentation/monit.html#LOGGING

En supposant que les valeurs par défaut (quelle que soit l’ancienne version de monit, j’utilise), vous pouvez suivre les journaux en tant que tels:

CentOS:

 tail -f /var/log/messages 

Ubuntu:

 tail -f /var/log/syslog 

Mac OS X

 tail -f /var/log/system.log 

les fenêtres

Voilà des dragons

Mais il y a un projet neato que j’ai trouvé en cherchant comment faire cela par curiosité morbide: https://github.com/derFunk/monit-windows-agent

Vous pouvez démarrer Monit en mode verbose / debug en ajoutant MONIT_OPTS="-v" à /etc/default/monit (n’oubliez pas de redémarrer; /etc/init.d/monit restart ).

Vous pouvez ensuite capturer la sortie en utilisant tail -f /var/log/monit.log

 [CEST Jun 4 21:10:42] info : Starting Monit 5.17.1 daemon with http interface at [*]:2812 [CEST Jun 4 21:10:42] info : Starting Monit HTTP server at [*]:2812 [CEST Jun 4 21:10:42] info : Monit HTTP server started [CEST Jun 4 21:10:42] info : 'ocean' Monit 5.17.1 started [CEST Jun 4 21:10:42] debug : Sending Monit instance changed notification to monit@example.io [CEST Jun 4 21:10:42] debug : Trying to send mail via smtp.sendgrid.net:587 [CEST Jun 4 21:10:43] debug : Processing postponed events queue [CEST Jun 4 21:10:43] debug : 'rootfs' succeeded getting filesystem statistics for '/' [CEST Jun 4 21:10:43] debug : 'rootfs' filesytem flags has not changed [CEST Jun 4 21:10:43] debug : 'rootfs' inode usage test succeeded [current inode usage=8.5%] [CEST Jun 4 21:10:43] debug : 'rootfs' space usage test succeeded [current space usage=59.6%] [CEST Jun 4 21:10:43] debug : 'ws.example.com' succeeded testing protocol [WEBSOCKET] at [ws.example.com]:80/faye [TCP/IP] [response time 114.070 ms] [CEST Jun 4 21:10:43] debug : 'ws.example.com' connection succeeded to [ws.example.com]:80/faye [TCP/IP] 

Ouais monit n’est pas trop facile à déboguer.

Voici quelques bonnes pratiques

  • Utilisez un script wrapper qui configure votre fichier journal. Écrivez vos arguments de commande pendant que vous y êtes:

coquille:

 #!/usr/bin/env bash logfile=/var/log/myjob.log touch ${logfile} echo $$ ": ################# Starting " $(date) "########### pid " $$ >> ${logfile} echo "Command: the-command $@" >> ${logfile} # log your command arguments { exec the-command $@ } >> ${logfile} 2>&1 

Cela aide beaucoup.

L’autre chose que je trouve utile, c’est d’exécuter monit avec ‘-v’, ce qui vous donne de la verbosité. Le workflow est donc

  • faire fonctionner votre wrapper depuis le shell “sudo my-wrapper”
  • puis essayez de le faire passer de monit, exécutez la ligne de commande avec “-v”
  • puis essayez de le faire passer de monit, en cours d’exécution en arrière-plan.

Vous pouvez également essayer de lancer monit validate une fois que les processus sont en cours, pour essayer de savoir si l’un d’entre eux rencontre des problèmes (et parfois obtenir plus d’informations que dans les fichiers journaux en cas de problème). Au-delà, vous ne pouvez pas faire grand chose.