はじめに
【前回】-> 我々はなぜ監視を行うのか【第二章】～監視システムチューニング編～
【第三章】～自動復旧編～
本当に対応が必要な障害が発生した時だけ自分宛ての通知をするようにしたAだが、もっと監視運用の効率化に欲が出てきてしまった。
思いついたのが、対応の自動化だ。Aは最近アイマスクを購入し、睡眠の質に凝っていた。極力起きたくない。楽をしたい。
Zabbixなどの監視システムには、「アクション」という機能が搭載されている。
アラート発生時、自動的にNginxの再起動等を実施することができる。
実際の設定についての記事(Apacheの再起動の場合)
考えてみれば、障害発生時にたたき起こされた際、WEBサーバであるNginxの再起動を実施すると治ることが多かった。
毎度毎度、決まりきったサービス再起動を行うためにたたき起こされるのは面倒だ。Aは寝ていたい。
ということで、Aは「Nginx再起動」というアクションを作成し、各WEBサービスのアラート発生時のアクションとして登録した。
現在の監視システムのアラート発生時のフローとしては、以下のような設定となる
1. アラートが発生する
2. 1度目の通知が、監視システムの「アクション」機能へと飛ぶ
3.1 60秒後に復旧していれば、通常監視に戻る
4.2 60秒後も復旧していなければ、Aへ通知が飛ぶ
「アクション」を登録することにより、Aは自分で対応していた復旧作業の大部分をシステムに任せることに成功した。
AがチューニングしたZabbixも、どこか誇らしげに見えた。
もしNginx再起動で復旧しない場合は、Aに通知が飛ぶ。
その場合、Nginxが原因でなかったり、Nginxを再起動しようとしていたものの失敗して、Nginxのステータスがfailedになっていたりする。
このような場合はAの手による障害対応が必要となるので、通知を飛ばす。
これを飛ばさないと、障害がほったらかされた状態になってしまうので大変だ。
Aは少し楽しくなってきて、色んなところに監視を追加していった。
- WEBサービスが死んでいると思って確認したら、原因はDBサーバが過負荷になっていたことにあった。DBサーバにもMysqlプロセスに関する監視を設定し、アクションとしてMysqlの再起動を設定する。
- WEBサービスが死んでいると思ったら、サーバ自体が死んでいた。PING監視を設定する。環境はAWS上にあるインスタンスなので、PING監視のアクションとしてインスタンスの再起動を設定する。
Aの日常的な負担は少しずつ減っていって、復旧も迅速に行えるようになった。
一次対応の大部分をシステムに任せることに成功したAの業務は、障害のそもそもの根本原因を探る業務、二次対応がメインになっていった。
Aは頑張ってくれている監視システムにご褒美を上げようとインスタンスタイプをひとつ上げてみたが、無駄な出費が増えたのでCloudwatch経由で上司に通知が行って怒られた。
まとめ
- 通知を行ったのち、毎度同じような対応をしている場合は、通知先をシステムとし、システムによる自動実行を設定する。
メリットとして、
・障害対応時のミスが減少する
・手動対応よりも迅速に復旧が行える
・人の負担を減らすことができる
・担当者が通知に気づかないことによる、障害対応漏れを減らせる
などが挙げられる。
以上のような効果が、システム監視を設定することにより得られる。
あとがき
次回は、切り分けのための監視設定編を予定...。