80 votes

Moniteur de débogage

Je trouve le débogage monit être une douleur importante. Monit de l'environnement de shell, fondamentalement, n'a rien (pas de chemins ou d'autres variables d'environnement). Aussi, il n'existe pas de fichier journal que je peux trouver.

Le problème est que si le début ou la commande d'arrêt dans le monit script échoue, il est difficile de discerner ce qui est mal avec elle. Souvent, il n'est pas aussi simple que juste de lancer la commande sur le shell parce que l'environnement du shell est différente de la monit de l'environnement de shell.

Ce sont quelques-unes des techniques que les gens utilisent pour déboguer monit configurations?

Par exemple, je serais heureux d'avoir un monit shell, pour tester mes scripts, ou d'un fichier journal pour voir ce qui n'allait pas.

94voto

James Mead Points 2432

J'ai eu le même problème. À l'aide de monit est détaillé option de ligne de commande aide un peu, mais j'ai trouvé le meilleur moyen était de créer un environnement aussi proche que possible de la monit environnement et exécuter le démarrer/arrêter le programme à 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 trouvé les problèmes les plus courants sont la variable d'environnement liées (en particulier PATH) ou de l'autorisation. Vous devez vous rappeler que monit généralement s'exécute en tant que root.

Aussi, si vous utilisez as uid myusername dans votre monit config, alors vous devez changer d'utilisateur myusername avant d'effectuer le test.

J'espère que ça aide.

38voto

billitch Points 1091

Assurez-vous de toujours vérifier votre conf et de surveiller vos processus à la main, avant de le laisser monit occuper de tout. systat(1), haut(1) et le ps(1) sont vos amis pour comprendre l'utilisation des ressources et les limites. Connaître le processus à surveiller est essentielle aussi.

Concernant le démarrage et l'arrêt des scripts j'utilise un script de redirection de sortie et d'inspecter l'environnement et d'autres variables. Quelque chose comme ceci :

$ 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 avez encore à comprendre ce que les infos que vous voulez dans l'emballage, comme le processus d'infos, id, système de ressources limites, etc.

10voto

vimdude Points 988

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

5voto

WattsInABox Points 1349

Par défaut, surveille les journaux dans / var / log / messages et vous pouvez y vérifier ce qui se passe.

 tail -f /var/log/messages
 

2voto

Bret Weinraub Points 101

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

Voici quelques-unes des meilleures pratiques

  • l'utilisation d'un script de lancement qui met en place de votre fichier de log. Écrire vos arguments de la commande, tandis que vous êtes à elle:

shell:

#!/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

Ça aide beaucoup.

L'autre chose que je trouve qui m'aide c'est de courir avec monit '-v", qui vous donne le niveau de verbosité. De sorte que le flux de travail est

  • obtenez votre enveloppe de travail à partir de l'interpréteur de commandes "sudo mon-wrapper"
  • puis essayer de l'obtenir allant de monit, exécutez la ligne de commande avec l'option "-v"
  • puis essayer de l'obtenir allant de monit, en cours d'exécution en arrière-plan.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X