Azure Web Apps の WordPress で発生した障害の調査の時のメモ

Azure

「Azure Web Apps の WordPress で発生した障害の調査の時のメモ」 ってタイトルにしてみましたが、このブログにアクセスできなくなってから復旧するまでにやったことのメモです。

多分、WordPress に詳しい方なら、すぐに解決できそうな気もするのですが、素人の自分には何をしていいかわからないところからのスタートでしたので。。。。

障害通知

まず最初に、こんなメールが飛んできてました。
飛んできてましたと過去形で書いてるのは、確かに朝に見たのですが、なんかメールきてるなぁーと流したからw

ちゃんと監視が効いているのに、スルーしちゃうと何もできないですよねーw
(俗に言うヒューマンエラーとかになっちゃいますかねー。)

障害発見

帰宅途中の電車の中で、たまたま自分のブログを確認しようと見たら真っ白画面で何も表示されなくて、なんか起きてることを知りました。
ブログのアクセス解析を見ると、今日は1桁PV でどうも2時前になんか起きて今日1日はほぼ動いてない状態だと知りました。

そんで思ったのが、なんか朝 Application Insights からなんかメール来てたなぁーってこと。
メールの着信は1:36でしたので、障害発生から既に19時間以上経過していました。
(本番のお客さん環境だったら、超怒られそー)

 

やったこと

まず最初にやったのは、なんとなくすんごい気乗りがしなかったのですが、Web Apps のリスタート。
なんせ電車の中だったので、ポータルから簡単に操作できることを試してみようかな位の感覚です。

まぁーやっても変化なしですよねー。

 

で、帰宅してまず試そうと思ったのは、Plug-in の停止です。
2年くらい前のチューニングマニアックスで Web App のチューニングをした際に、Plug-in を適当に入れまくったら真っ白画面になって、なんもできなくて Plug-in を全部引っこ抜いたら復活した記憶があったからです。

だけど、なんとなく全部引っこ抜くのは嫌なので、debug ログを出力して怪しいのから順番にPlug-inを抜く作戦にしました。

デバッグログを出力の設定は、以下の手順を参考にしました。
http://qiita.com/miiitaka/items/9c8ea4e36c78381c3748

そして、wp-config.php の変更は、App Service Editor(プレビュー)を使いました。

まぁー、VS Online(monaco) と言われてたのみたいですねー

 

wp-content/debug.log を見ると、Stack Trace を吐いているPlug-inと、定期的に大量のログを吐いているPlug-inがいたので、この両方の plug-in をリネームをしたところ復旧!!
管理画面でプラグインの更新情報を見ると、Stack Trace 吐いているplug-inは、新しいバージョンがでてたので早速Updateしたら、復活しました。

 

復旧通知

ブラウザでURL叩いて接続確認後、割とすぐにApplication Insights からも復旧のメールきてました。

 

まとめ

やっぱり死活監視は大切っすね!!

あと、監視を入れていても、その通報をスルーしちゃダメっすね。

ひとまず、復旧してよかったです。

コメント

タイトルとURLをコピーしました