先日、大変申し訳ないことに設定ミスによってお客様の Web サイトをダウンさせてしまいました。JetPack (WordPress.com) による監視機能を使用していたので、本来であれば 1 時間もしないうちにダウンを通知するメールが届くはずでしたが、残念ながら何らかの原因によって機能しなかったようです。
JetPack による監視の利点は、簡単に設定できることと、外部サーバーによる監視のためホスティングサービスの状態に依存しないことです。しかし今回は上手く機能しませんでした。原因の解明も重要ですが、監視を多重化させて機能の安定化を優先したいと思いました。
まずサイトのトップページを叩いてステータスコードを監視することを検討しましたが、localhost からの訪問は除外されているように見えたものの、統計情報に影響を与えそうなのでやめることにしました。
次に思い当たったのは wp-cron です。http で /wp-cron.php を叩けば当然ですが本番環境で実行した結果となります (余談ですが、wp-cli から wp-cron を実行するのは、PHP の実行環境が Web と cli で異なる場合があるので避けた方が良いこともあります)。wp-cron の実行自体は以前から cron で行っていたのですが、次のようなよくあるコマンドでした。
wget -q -O - https://example.com/wp-cron.php?doing_wp_cronこのコマンドですと出力がほとんど捨てられてしまいます。-q を外せばステータスコードが出力されますが 200 でも出力されてしまいます。
user@debian:~$ wget -O - https://localhost/wp-cron.php?doing_wp_cron
--2018-06-18 03:23:55-- https://localhost/wp-cron.php?doing_wp_cron
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:443... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2018-06-18 03:23:55 ERROR 500: Internal Server Error.
user@debian:~$ wget -O - https://localhost/wp-cron.php?doing_wp_cron
--2018-06-18 03:25:48-- https://localhost/wp-cron.php?doing_wp_cron
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘STDOUT’
[ <=> ] 0 --.-K/s in 0s
2018-06-18 03:25:49 (0.00 B/s) - written to stdout [0]
今回のようなことを考えると、これはあまり良くない例ということになります。wget のオプションを詰めてステータスコードを判別しても良いのですが、私はシェルより Python に通じているので Python で簡単なスクリプトを作成しました。
[gist https://gist.github.com/chrono-meter/aa5499a9bd3b54270763bd2d4de1c95b]もし使用する場合は拙作の urlpath というライブラリを使用していますので、pip install urlpath といったコマンドなどで依存関係を解決してください。
監視は様々な機能やサービスを使用し、さらに随時対応が必要となる、意外とデリケートで人的リソースを食う作業です。様々なシステムやサービスで自動アップデートが実施されている現在では、昨日まで有効だったノウハウが通用しなくなることもあります。ホスティング業者や外部のサービスが謳う自動化機能も、ある程度のノウハウを有した人間が関わらなければ有効に機能しません。今回は監視機能が多重化されていなければ障害を見逃す恐れがあることを痛感しました。