KUSANAGIはウェブサービスも監視しています|ω・)

遠藤博樹(NHN JAPAN株式会社)

NHNテコラスの遠藤が、プライム・ストラテジー様のサイトで、KUSANAGIというシステムの安定運用に役立つホスティングサービスについてのコラムを投稿することを告知しました。KUSANAGIは、monitという監視ツールが搭載されており、その使用方法や設定を詳しく説明しています。特に、エラー検知時のプロセス再起動やメール通知の設定、ログ解析の重要性などを紹介しています。また、メール通知の実際の設定例も提供されています。これらの情報は、KUSANAGIを活用し、システムの安定稼働を目指す方々にとって、大変有益なものとなります。

はじめに[ご挨拶]

この度、プライム・ストラテジー様のサイト上でKUSANAGIに関連したコラムを掲載させていただくこととなりました、NHNテコラスの遠藤と申します。
主にEX-CLOUD(エクスクラウド)というホスティングサービスブランドでの顧客サポートやサービス企画などを担当しております。

KUSANAGIを搭載したホスティングサービスは2016/10月より提供しており、EX-CLOUD for KUSANAGI誕生秘話を書いたりもしましたが、このように自社サービス上のブログでもKUSANAGIに関連した記事を投稿する場合があるため、プライム・ストラテジー様のサイト上ではネタ切れにならないよう、2ヶ月に1記事ペースの小出しで投稿させていただく予定です。

monitによる監視

早速ですが、KUSANAGIにはmonitという監視ツールが搭載されております(バージョン7.8.3より)
monit自体は設定によりURL死活監視やプロセス監視などが行えますが、KUSANAGIではウェブサービスのログ監視を行うように設定されています。
(アクセスログを監視し、500番台のエラーを検知したらプロセス再起動にて復旧を試みる)

ここまではKUSANAGIのバージョンアップ情報に記載されている情報ですが、監視によりプロセス再起動時にメール通知を行うことが可能なため、設定方法を紹介いたします。
(稀にプロセス再起動が行われてる程度であればまだ良いのですが、頻度な再起動が行われている場合はコンテンツの見直しやメモリなどのリソースを見直す目安になるのでログ解析を定期的に行われていない場合はメール通知の方が気付きの切っ掛けになります)

KUSANAGI環境では次のファイルで設定を行っています。

設定ファイル:
/etc/monitrc
/etc/monit.d/*
※monit.d以下はプロファイル毎の監視設定ファイルやメール通知用のalert、logファイルの出力先を定義しているloggingファイルなどがあります

500番台のエラーの発生条件

アクセス過多により503 Service Unavailableとなる場合や、PHPやCGIの構文・不適切なパーミッション設定による 500 Internal Server Error、DBへの接続がタイムアウトとなり 502 Bad Gatewayとなる、などが考えられます。

monitによる再起動とメール通知

monitがエラーを検知した場合や再起動が行われた場合は/var/log/monit.logに記録されます。
また、初期設定では再起動した旨はメール通知が行われませんが、/etc/monit.d/alertを書き換えることで指定したメールアドレスに通知することも可能です。

# set alert root@localhost on {instance, timeout}
set alert xxxx@example.org
初期設定ではmonit自身が再起動した場合にroot@localhost(/var/spool/mail/root に通知されますが
上記2行は初期設定をコメントアウトし、 xxxx@example.org 宛てにメール通知したい場合の設定例です
set mailserver localhost
set mail-format {
from: kusanagi@$HOST
subject: [KUSANAGI MONIT] $SERVICE $EVENT at $DATE
message: Monit alert this action.
Please check monit status on $HOST.

Service: $SERVICE
Event: $EVENT
Action: $ACTION
Data: $DATE
Host: $HOST

$DESCRIPTION.
}
送信されるメール件名や内容もこのファイルで定義しますが、今回はメール通知の宛先のみ設定変更しました

設定変更後は、#  systemctl restart monit.service にてmonitを再起動してください。

メール通知条件の変更

/etc/monit.d/(プロファイル名)_nginx.conf で調整します※nginxで動作させている場合

check file (プロファイル名)_nginx with path /home/kusanagi/(プロファイル名)/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
/etc/monitrc の設定に従い、初期設定では30秒毎に監視が行われますが、2回の監視で続けて500番台の
ログが記録されていたら再起動を行います。
        if 5 restarts within 5 cycles then alert
        if 5 restarts within 5 cycles then unmonitor
5回続けて再起動が行われた場合は監視を停止し、アラートを通知します。
        group nginx
・
・
以下SSL(https用)の設定が記述されていて、ログのpathのみ異なります

unmonitor(監視停止)されることで以後のメール通知も止まりますが、そのまま監視再開設定を忘れてしまう場合もありますので適宜、監視停止の設定はコメントアウトされても良いかもしれません。

監視状況や監視再開・停止などは次のようなコマンドで可能です。

・監視対象の情報の表示
# monit status

・すべての監視停止
# monit unmonitor all

・すべての監視再開
# monit monitor all

・監視対象を指定して実行することも可能です
# monit monitor (プロファイル名_nginx)

動作確認

不適切な設定のPHPやCGIを設置し、ウェブアクセスすることで擬似的にエラーをログに記録させられます。
index2.phpという不適切な設定のファイルを設置し、アクセスした場合のアクセスログ。

0.001 - - xxx.xxx.xxx.xxx - - [06/Feb/2017:20:33:17 +0900] "GET /index2.php HTTP/1.1" 500 5 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" "-"
0.002 - - xxx.xxx.xxx.xxx - - [06/Feb/2017:20:33:54 +0900] "GET /index2.php HTTP/1.1" 500 5 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" "-"

monitのログ /var/log/monit.log にも次のように記録され、再起動が行われます。

[JST Feb  6 20:34:01] info     : '(プロファイル名)_nginx' trying to restart
[JST Feb  6 20:34:01] info     : '(プロファイル名)_nginx' restart: /bin/kusanagi

メールでも通知がされました。

Monit alert this action.
Please check monit status on FQDN.Service: (プロファイル名)_nginx
Event: Content match
Action: restart
Data: Mon, 06 Feb 2017 23:34:01
Host: *****.com content match:
0.001 – – xxx.xxx.xxx.xxx – – [06/Feb/2017:20:33:17 +0900] “GET /index2.php HTTP/1.1” 500 5 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko” “-”
0.001 – – xxx.xxx.xxx.xxx – – [06/Feb/2017:20:33:54 +0900] “GET /index2.php HTTP/1.1” 500 5 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko” “-“

おまけ

monitによるメール通知について紹介しましたが、
メールプロセスが落ちている場合、メール通知は行われませんヾ(ーー )

実際にサーバの高負荷によりメールプロセスが落ちてしまい、WordPressで作成した記事に対してコメントがされていたが、コメント通知のメールが送信されていなくて気付かなかったというお問い合わせも頂戴したことがあります。

monitではプロセス監視も行えますので、sendmailなどのメールプロセスも監視していれば起動させることが出来なくもないですが、当社のサービスではcronでsendmailプロセスの有無をチェックし、プロセスが無い場合はsendmailを起動するように設定を初期状態で行っています。
(monitの設定ファイルをお客様への初期納品時にカスタマイズし、monitによる監視実装をしていない理由としては将来KUSANAGIがhttpdのログ監視以外にこのあたりの監視設定も初期で行うことがあったら、、、と思い、別の方法でメール監視を実装しました)

設定例:

/etc/cron.d/sendmail に以下を記述
*/10 * * * * root [[ ! -f '/var/run/sendmail.pid' ]] || [[ ! -d /proc/$(cat /var/run/sendmail.pid) ]] && systemctl start sendmail
10分毎にsendmailのプロセスファイルがあるかチェックし、存在しなければ再起動する

以上、KUSANAGIのことと少し離れてしまいましたが、標準でKUSANAGIに搭載されているツールの補足説明をさせていただきました。
また、4月ごろお邪魔させていただきますのでよろしくお願いいたします(*゚ー゚)(*。_。)

KUSANAGIはWordPressだけぢゃなぃ(´・д・`* = *´・д・`)  >>

関連記事

Webサイト運用の課題解決事例100選 プレゼント

Webサイト運用の課題を弊社プロダクトで解決したお客様にインタビュー取材を行い、100の事例を108ページに及ぶ事例集としてまとめました。

・100事例のWebサイト運用の課題と解決手法、解決後の直接、間接的効果がわかる

・情報通信、 IT、金融、メディア、官公庁、学校などの業種ごとに事例を確認できる

・特集では1社の事例を3ページに渡り背景からシステム構成まで詳解