Debugging-Monitor

Question

Ich finde Debugging-Monitor zu einem großen Schmerz. Die Shell-Umgebung von Monit enthält im Grunde nichts (keine Pfade oder andere Umgebungsvariablen). Außerdem gibt es keine Protokolldatei, die ich finden kann.

Das Problem ist, wenn der Start oder Stop-Befehl im Monit-Skript fehlschlägt, ist es schwierig zu erkennen, was daran falsch ist. Oft ist es nicht so einfach, nur den Befehl für die Shell auszuführen, da sich die Shell-Umgebung von der Monit-Shell-Umgebung unterscheidet.

Welche Techniken verwenden Leute zum Debuggen von Monit-Konfigurationen?

Zum Beispiel würde ich gerne eine Monit-Shell haben, um meine Skripte zu testen, oder eine Log-Datei, um zu sehen, was schiefgelaufen ist.

Answer 1

Ich hatte das gleiche Problem. Die Verwendung der ausführlichen Befehlszeilenoption von monit hilft ein wenig, aber ich fand den besten Weg, eine Umgebung zu erstellen, die der Monit-Umgebung so ähnlich wie möglich ist, und das Start/Stop-Programm von dort auszuführen.

# 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 
$ 

Ich habe die häufigsten Probleme sind Umgebungsvariable im Zusammenhang (insbesondere PATH) oder die Erlaubnis bezogenen gefunden. Sie sollten daran denken, dass Monit normalerweise als root ausgeführt wird.

Auch wenn Sie as uid myusername in Ihrer Monit Config verwenden, sollten Sie vor der Durchführung des Tests zu Benutzer myusername wechseln.

Ich hoffe, dass hilft.

Answer 2

Sie können auch versuchen, monit validate auszuführen, sobald Prozesse ausgeführt werden, um herauszufinden, ob einige von ihnen Probleme haben (und manchmal mehr Informationen erhalten, als Sie in den Protokolldateien erhalten würden, wenn es Probleme gibt). Darüber hinaus können Sie nicht viel mehr tun.

Answer 3

Achten Sie darauf, immer Ihre conf zu überprüfen und Ihre Prozesse von Hand zu überwachen, bevor Sie monit alles handhaben lassen. systat (1), top (1) und ps (1) sind deine Freunde, um Ressourcennutzung und -limits zu ermitteln. Es ist auch wichtig, dass Sie den von Ihnen überwachten Prozess kennen.

In Bezug auf die Start-und Stop-Skripts verwende ich ein Wrapper-Skript, um die Ausgabe umzuleiten und Umgebung und andere Variablen zu überprüfen. Etwas wie folgt aus:

$ 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 

Dann in 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" 

Sie immer noch herauszufinden, was Infos Sie in der Wrapper wollen, wie Prozessinformationen, id, Systemressourcen Grenzen usw.

Answer 4

Standardmäßig protokolliert monit in Ihrem Systemnachrichtenprotokoll und Sie können dort nachschauen, was passiert.Schwanz

auch je nach Konfiguration, können Sie

tail -f /var/log/monit 

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

Unter der Annahme, Standardwerte an einen anderen Ort werden Anmeldung (ab, was auch immer alte Version von monit Ich verwende), können Sie die Protokolle als solche:

CentOS:

tail -f /var/log/messages 

Ubuntu:

tail -f /var/log/syslog 

Mac OSX

tail -f /var/log/system.log 

Windows-

Hier werden Drachen

Aber es gibt ein neato Projekt I fou nd während der Suche, wie dies zu tun aus morbider Neugier: https://github.com/derFunk/monit-windows-agent

Answer 5

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

Answer 6

Ja monit zu debuggen nicht zu einfach ist.

Hier einige Best Practices

• ein Wrapper-Skript, das Ihre Log-Datei einrichtet. Schreiben Sie Ihren Befehl Argumente gibt, während Sie gerade dabei sind:

Schale:

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

Das hilft viel.

Die andere Sache, die ich finde, hilft, monit mit '-v' zu laufen, die Ihnen Ausführlichkeit gibt. So ist der Workflow ist

• erhalten Sie Ihre Wrapper aus der Shell arbeiten "sudo my-Wrapper"
• dann versuchen und erhalten sie von monit gehen, von der Kommandozeile ausgeführt mit "-v"
• dann versuchen, und lass es von Monit laufen, der im Hintergrund läuft.

Answer 7

Sie können Monit starten im ausführlichen/Debug-Modus von MONIT_OPTS="-v"-/etc/default/monit Hinzufügen (vergessen Sie nicht neu zu starten; /etc/init.d/monit restart).

können Sie dann die Ausgabe erfassen mit 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]