monitのデバッグは大きな苦痛だと思います。Monitのシェル環境には、基本的に何も含まれていません（パスやその他の環境変数はありません）。また、私が見つけることができるログファイルはありません。
問題は、monitスクリプトのstartまたはstopコマンドが失敗した場合、何が問題なのかを識別するのが難しいことです。多くの場合、シェル環境はmonitシェル環境とは異なるため、シェルでコマンドを実行するほど簡単ではありません。
人々がモニター構成をデバッグするために使用するいくつかのテクニックは何ですか？
たとえば、monitシェルを使用してスクリプトをテストしたり、ログファイルを使用して何が問題になったかを確認したりできれば幸いです。
私も同じ問題を抱えています。monitの冗長コマンドラインオプションを使用すると少し役立ちますが、monit環境にできるだけ似た環境を作成し、そこから開始/停止プログラムを実行するのが最善の方法であることがわかりました。
# 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
$
最も一般的な問題は、環境変数関連（特にPATH）または権限関連であることがわかりました。monitは通常rootとして実行されることを覚えておく必要があります。
またas uid myusername、monit構成で使用する場合myusernameは、テストを実行する前にuserに変更する必要があります。
それがお役に立てば幸いです。
monitにすべてを処理させる前に、必ずconfを再確認し、プロセスを手動で監視してください。systat（1）、top（1）、およびps（1）は、リソースの使用量と制限を把握するための友達です。監視するプロセスを知ることも不可欠です。
開始スクリプトと停止スクリプトに関しては、ラッパースクリプトを使用して出力をリダイレクトし、環境やその他の変数を検査します。このようなもの ：
$ 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
それから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"
プロセス情報、ID、システムリソースの制限など、ラッパーに必要な情報を把握する必要があります。
MONIT_OPTS="-v"に追加することで、詳細/デバッグモードでMonitを起動できます/etc/default/monit（再起動することを忘れないでください; /etc/init.d/monit restart）。
次に、を使用して出力をキャプチャできます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]
monit -c /path/to/your/config -v
デフォルトでは、monitはシステムメッセージログにログを記録し、そこで何が起こっているかを確認できます。
また、設定によっては、別の場所にログインしている可能性があります
tail -f /var/log/monit
http://mmonit.com/monit/documentation/monit.html#LOGGING
デフォルト（私が使用しているmonitの古いバージョン）を想定すると、ログを次のように調整できます。
CentOS：
tail -f /var/log/messages
Ubuntu：
tail -f /var/log/syslog
Mac OSX
tail -f /var/log/system.log
ウィンドウズ
ここにドラゴンがいます
しかし、病的な好奇心からこれを行う方法を探しているときに見つけたネイトプロジェクトがあります：https ：//github.com/derFunk/monit-windows-agent
ええ、monitはデバッグするのが簡単ではありません。
ここにいくつかのベストプラクティスがあります
シェル：
#!/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
それは大いに役立ちます。
私が役立つもう1つのことは、冗長性を与える「-v」を使用してmonitを実行することです。つまり、ワークフローは
また、プロセスの実行後にmonit validateを実行して、プロセスに問題があるかどうかを確認することもできます（問題がある場合は、ログファイルよりも多くの情報を取得することもあります）。それを超えて、あなたができることはそれほど多くありません。