サーバーの運用を自動的に行うMonitの設定を見てみる(kusanagi環境)
手動で導入も可能みたいだが、kusanagi環境(8.4.0-3)でprovisionで作成されるファイルを見てみる。 https://kusanagi.tokyo/
バージョンは以下の通り
CentOS 7.5
Nginx 1.15.2
Monit 5.25.1
access.logが自動で復活している現象を発見
logrotateの動作確認中にaccess.logを間違えて消してしまったが、少しすると自動的に復活していた。
→ 調べてみるとmonitというデーモンが30秒ごとにaccess.logの存在を監視していて、なければ自動的にリスタートをかけてくれていた。
logrotateでコケるとaccess.logとかが作成されない不具合が起きた場合、monitがそれをサポートしてくれるというのもメリットの一つ。
Monitとは
総合監視デーモンとしてファイルシステムからHTTPレスポンス内容・プロセス監視などの機能を持っています。GPLライセンスでLinux/BSD/Solaris上で動作可能です。CentOSならDAGリポジトリからyum installもでき、configも簡潔ですので15分程度で導入ができます。
15分で始めるmonitによるサーバ監視 より引用
kusanagi環境では初期設定で導入されているので、logrotateと同様にデプロイ関連ツールを導入してログの場所が変わってしまうとmonitも動作しない。
設定ファイル
/etc/monitrc/etc/monit.d/xxxx配下にある
/etc/monitrcを覗いてみる
###############################################################################
## Global section
###############################################################################
##
## Start Monit in the background (run as a daemon):
#
set daemon 30 # check services at 30 seconds intervals
# with start delay 240 # optional: delay the first check by 4-minutes (by
# # default Monit check immediately after Monit start)
#
#
## Set syslog logging. If you want to log to a standalone log file instead,
## specify the full path to the log file
#
set log syslog
(略)
## Monit has an embedded HTTP interface which can be used to view status of
## services monitored and manage services from a web interface. The HTTP
## interface is also required if you want to issue Monit commands from the
## command line, such as 'monit status' or 'monit restart service' The reason
## for this is that the Monit client uses the HTTP interface to send these
## commands to a running Monit daemon. See the Monit Wiki if you want to
## enable SSL for the HTTP interface.
#
set httpd port 2812 and
use address localhost # only accept connection from localhost
allow localhost # allow localhost to connect to the server and
allow admin:monit # require user 'admin' with password 'monit'
#with ssl { # enable SSL/TLS and set path to server certificate
# pemfile: /etc/ssl/certs/monit.pem
#}
(略)
include /etc/monit.d/*
分かる範囲だと
- 30秒ごとに監視している。
/etc/monit.d/*以下も含んでいるので実行できる
なので、/etc/monit.d/以下に名前をつけて独自で設定すれば30秒ごとに監視してくれる。
/etc/monit.d/配下の設定ファイル
こちらはkusanagiでprovisioningをしたあと に自動的に作られる/etc/monit.d/project_nginx.conf
check file project_nginx with path /home/kusanagi/project/log/nginx/access.log
restart program = "/bin/kusanagi restart"
depends on nginx
if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then restart
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor
group nginx
check file project_nginx_ssl with path /home/kusanagi/project/log/nginx/ssl_access.log
restart program = "/bin/kusanagi restart"
depends on nginx
if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then restart
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor
group nginx
構築した環境によっては、ログの位置が変わったりするので、 monitを利用してサーバーの監視をしたい場合はこちらのファイルのログのパスを編集する。
個人的な解釈としては、
monitが30秒ごと(/etc/monitrcの設定で変更可)に指定したファイルを見に行って、
指定ファイルが存在しなければkusanagi restartされる。
それを5回繰り返したらalert出すし、モニタリングをやめる。
monitの状況確認
２つのコマンドがある。
- # monit status
- # monit summary
どちらも同じような内容?だが、個人的には見やすいので、monit statusを見ている。
monit status
kusanagiでは、自動的にNginxかApacheのどちらで動かしているかを判断して、 片方を監視から外してくれている。
Nginxがwebサーバーとして可動している場合は、以下の記述。
# monit status Monit 5.25.1 uptime: 5d 17h 54m File 'project_nginx' status OK monitoring status Monitored monitoring mode active on reboot start permission 644 uid 1001 gid 1002 size 0 B access timestamp Tue, 02 Oct 2018 03:32:32 change timestamp Tue, 02 Oct 2018 03:32:32 modify timestamp Tue, 02 Oct 2018 03:32:32 content match no data collected Tue, 02 Oct 2018 08:11:16
以下はApacheは起動していないので、kusanagiがあえて最初から監視からはずしてくれている。
また、先程記述した/etc/monit.d/project_nginx.confにあったように
monitが起動しているのに指定のログファイルのパスがおかしい場合、
5回リスタートを繰り返しても不具合がある場合はモニタリングをやめるという記述をしたが、
もし、それに該当するようになった場合はprojct_nginxでも以下のようにNot monitoredという扱いになる。
File 'project_httpd' status Not monitored monitoring status Not monitored monitoring mode active on reboot start data collected Wed, 26 Sep 2018 14:16:35
monit summary
# monit summary Monit 5.25.1 uptime: 5d 18h 1m ┌─────────────────────────────────┬────────────────────────────┬───────────────┐ │ Service Name │ Status │ Type │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ system-1 │ OK │ System │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ project_nginx │ OK │ File │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ project_nginx_ssl │ OK │ File │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ project_httpd │ Not monitored │ File │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤
テーブルを作って、最低限だが表示をしてくれる。
monitのログを見る
kusanagi環境で構築した場合には/var/log/monit.logに記載されている
以下は、projectのログの出力先(nginxのconfファイルで設定)とmonitの設定のログの出力先の整合性が合わない時に、発生。
5回restartを繰り返してもう監視やめまーすという状態。
こうなるとmonit summary or monit status で見た時に、Not monitoredとなる。
[JST Sep 16 12:08:36] error : 'project_nginx' file doesn't exist [JST Sep 16 12:08:36] info : 'project_nginx' trying to restart [JST Sep 16 12:08:36] info : 'project_nginx' restart: '/bin/kusanagi restart' (略) [JST Sep 16 12:09:07] error : 'sleepdays_nginx' service restarted 5 times within 5 cycles(s) - unmonitor
monitの設定変更時
Not monitoredになっている設定を監視開始(再開)したいときは、monit start project_nginxとかで監視を再開できる。
うまくいかない場合はmonit restartとかsystemctl monit restatとかでmonit自体をリスタートかける。
# monit -tで構文チェックもできる。
monitコマンド
以下、参考
# monit -h
Usage: monit [options]+ [command]
Options are as follows:
-c file Use this control file
-d n Run as a daemon once per n seconds
-g name Set group name for monit commands
-l logfile Print log information to this file
-p pidfile Use this lock file in daemon mode
-s statefile Set the file monit should write state information to
-I Do not run in background (needed when run from init)
--id Print Monit's unique ID
--resetid Reset Monit's unique ID. Use with caution
-B Batch command line mode (do not output tables or colors)
-t Run syntax check for the control file
-v Verbose mode, work noisy (diagnostic output)
-vv Very verbose mode, same as -v plus log stacktrace on error
-H [filename] Print SHA1 and MD5 hashes of the file or of stdin if the
filename is omited; monit will exit afterwards
-V Print version number and patchlevel
-h Print this text
Optional commands are as follows:
start all - Start all services
start <name> - Only start the named service
stop all - Stop all services
stop <name> - Stop the named service
restart all - Stop and start all services
restart <name> - Only restart the named service
monitor all - Enable monitoring of all services
monitor <name> - Only enable monitoring of the named service
unmonitor all - Disable monitoring of all services
unmonitor <name> - Only disable monitoring of the named service
reload - Reinitialize monit
status [name] - Print full status information for service(s)
summary [name] - Print short status information for service(s)
report [up|down|..] - Report state of services. See manual for options
quit - Kill the monit daemon process
validate - Check all services and start if not running
procmatch <pattern> - Test process matching pattern
