KUSANAGIのWebサーバーにはいろいろな理由で異常が発生したときのリスタート設定があります。
Monitを使ってるんですが、ボクの場合は復旧しませんでした。設定を確認したところ、たしかにそういうことも起きるよな、という感じです。
Webサーバーの完全停止というめったにないことが起きたからなんですが。
KUSANAGIが設定するMonitの内容を確認
KUSANAGIのWebサーバーのリカバリ機能はMonitを使っています。KUSANAGIでのMonitについてはすでに書いたので、ここではいきなり設定内容から見ていきます。
まずはじめに、Monitの設定ファイルは /etc/monit.d/下にあり、KUSANAGIは、Webサーバー全体とプロファイルごとの設定を作っています。
httpd.conf | Apache HTTP Server (httpd) 用。 サーバーがダウンしたときの設定を書いている が、コメント化されて動作していない。 (くわしくは後述。) |
nginx.conf | Nginx用。 サーバーがダウンしたときの設定を書いている が、コメント化されて動作していない。 (くわしくは後述) |
(profile)_httpd.conf | KUSANAGIプロファイル固有のhttpd用。 HTTPステータスが5xxのときサーバーをリスタ ートする設定。 'kusnagi init' でプロビジョニングを行うと作成さ れる。 |
(profile)_nginx.conf | KUSANAGIプロファイル固有のnginx用。 HTTPステータスが5xxのときサーバーをリスタ ートする設定。 'kusnagi init' でプロビジョニングを行うと作成さ れる。 |
(profile)_runner.conf | WEXAL用。 KUSANAGI Premium Editonではpst用が追加。 |
ログファイルを監視
check file (profile)_httpd with path /home/user/profile/log/httpd/access.log
start program = "/bin/kusanagi restart"
stop program = "/bin/systemctl stop httpd"
depends on httpd
if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then start
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor
group httpd
check file (profile)_httpd_ssl with path /home/user/profile/log/httpd/ssl_access.log
start program = "/bin/kusanagi restart"
stop program = "/bin/systemctl stop httpd"
depends on httpd
if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then start
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor
group httpd
check file (profile)_nginx with path /home/user/profile/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 (profile)_nginx_ssl with path /home/user/profile/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
この設定では、Webサーバーのログファイルの出力内容を監視し、HTTPステータスが5xxのものを見つけようとします。
もし、指定回数分見つかったら、'kusanagi restart' コマンドで、KUSANAGIパッケージを丸ごと再起動します。
('kusanagi restart' には、httpd, nginx で使ってる方のリスタートコマンド 'systemctl restart' が含まれる。)
Webサーバーは、とくに異常はないはずなんだけど、やけに5xxのサーバーエラーを返すことがあります。その対応ですね?
ただし、この設定ではWebサーバーが完全停止したときには動作しません。
Webサーバーは完全停止すると、そもそもHTTPリクエストを受け付けないので、ログファイルの書き込みすらないから。
プログラムの実行結果で確認
check program httpd with path "/bin/systemctl is-enabled httpd"
#start program = "/bin/kusanagi restart"
if status != 0 then unmonitor
group httpd
check program nginx with path "/bin/systemctl is-enabled nginx"
#start program = "/bin/kusanagi restart"
if status != 0 then unmonitor
group nginx
これ、systemctlを実行してサーバーが止まってるかどうかを確認してるんですが、気になるところが2点。
まず、systemctl is-enabled の実行結果は enabled / disabled です。
systemctl is-enabled httpd
disabled
systemctl is-enabled nginx
enabled
その判定が見当たらない。if status に入るのか? 文字列結果は使える? よく分かりません。
そして、start program をコメント化しているので全く意味がありません。この設定ファイルは使ってないんじゃないか?
systemctl is-enabled は本来、OSが起動したときに自動起動するかどうかを判定するもの。
だがKUSANAGIは、使用Webサーバー選択時に自動起動(enable)にすることから、判定に使えるとしたかったらしい。
Webサーバーが完全停止したときのリカバリができない
この設定内容を見るに、Webサーバーが完全停止しているときのリカバリは無いんじゃないか?
じっさいボクの場合、原因は特定できてませんが、早朝6時にnginxが停止し、気づいて手動で起動するまでの3時間、止まったままでした。
そのころはKUSANAGIがMonitを使ってるのも知らず、systemdのサービスファイルにRestart設定をしたほどです。
『systemdにあるサービスのリカバリはsystemdでするべし』だと思う。
Monitを使ってることを知った今でも、この対応は正解だったと思います。
systemdに登録されたサービスのリカバリ設定をMonitでするメリットは無いですからね? systemdはLinuxの標準機能だし。
Webサーバーの完全停止なんてめったにあるもんじゃありません。メモリやディスク不足、そもそもOSがパンクしたときくらい。かなり危ない状態。
それを考えると完全停止のリカバリは無くてもいいという判断もあるのかな?
リソース不足が原因の場合、リカバリが発動してしまうと、リソースのパンパン具合を悪化させてしまうという考えもある。
こういうときは最悪、プロンプトからのコマンド入力さえできなくなり、専門家による復旧作業すらできない。
手立てがないからOS再起動になるが、その手は最終手段。できればやりたくない。
ボクは経験したので、あったほうがいいと思うけど。システムとしてWebサーバーの重要度が高いのであれば。
(DBはsystemdのリカバリ設定が入っている。)
ちなみに、ログファイルの監視は必要だと思ってます。systemdの補完としてはMonitは良いものなので。