Web・インターネットサービスは初期開発もだけど、それ以上に運用の方が期間的に非常に長い。一度公開したら、「運用期間 >>> 初期開発期間」という具合に運用期間の方が圧倒的に長い。

よく監視で何を見て、どうすれば？というのを聞かれたりするけど、確かにそういう何を監視してどうするか？といった部分で経験的な所や監視ツールの説明はあるけど、Web上にあまり情報が無いような気がする。特に開発側はあまり意識しないで、リリース&開発優先!!という流れもあったりするけど、基本的な所だけでも意識しておいた方が良い気がする。

Nagios/Cacti/Munin/Zabbix…etc とか運用監視ソリューションを使って監視をしよう!!というのよく見たりするけど、それはツールの話であって、そもそも監視って何で？何の役に立つの？という所を書き残しておくことは必要かなと(大体はSNMPだし)。いきなりツールの話をしちゃいけないような気が若干…ってことで、自分の経験的な所も含めて書いてみる。

 

– 運用監視って？
前提として、「監視をしていないシステムは止まっているのと一緒」だと思っている。
監視＆確認されないシステムが正常に稼働しているかどうか？は24時間365日ベタ付きで見ていない限り、「ちゃんと動いています!!」と言えない。もちろん、どこまで監視用の設備を用意するかどうか？といったコスト見合いもあるけどね。
更に監視は障害が発生した時の検知・原因分析や情報を残しておく事で、運用におけるスケーラビリティ・増強についての指針、ボトルネックや問題解決の特定といった情報のベースにもなる。そこで監視を行う理由としては以下がある。

1. 正常に稼働している事を確認する
2. 何かシステムに問題があった時の検知を行う
3. システムにおけるボトルネック・問題発生後の原因分析
4. スケーラビリティ・増強を検討する際の指針

 

– 何を監視するのか？
監視をキーワードに書籍とか何かを見ると長々と書いてあったり、監視用ミドルの話が多いと思うけど、視点として大体は次を覚えときゃOKと思っている。

1. 死活
2. リソース
3. プロセス
4. ログ
5. サービス・アプリ(optional)

これらの監視を行って、何か問題があればメール(携帯直撃は当たり前)で通知が行われる。つまり、[監視]-(問題発生)->[通知]->[対応]といった一連の流れになる。
ここで前後するけど、監視には「インフラ・ネットワーク」「OS以上のレイヤーであるシステムアプリ周り」という２つの側面があって、どちらがどこまで監視を行うか？どちらに問題があるのか？はよく話に上がる（いわゆる責任分解点というやつ）。ここでは、OS以上の層について対象としておく。

1-5は何なのか？というと次の通り。

 

1. 死活
これはその名の通り、サーバ・ミドルが死んでいるのか活きているのか監視を行う。よく対象とするのは、

– OSが稼働しているかどうか(ping)
– ミドルが稼働しているかどうか(Web:telnet/wget, DB/Memcache…その他ミドル:接続する)

というのが基本になる。OSの稼働は対象のIPに対してpingを打つ。サーバが稼働していればレスポンスが戻ってくるというもの。またミドルに関しては実際に接続して、対象のミドル・ポートに対して接続できる事といった感じ。OSの死活はもちろん、経路上のNWの問題も検知する事が出来たりする。
ただし残念な事だけど、たまにこのどちらも稼働していても、対象のサーバに接続できないという事もあったりする。

 

2. リソース
これは、CPU・メモリ・ディスク、LoadAvg、Connection数といったOS上の統計情報、ミドルが持っている統計情報から、安定稼働の状態で推移しているかどうか監視を行う。過負荷な状態・データファイルを大量に使っている・スレッド数が凄いことになってるー!!…etc等をフックに、システムの増強・問題点の対応・分析を行うことになる。
ここで、インフラ・ネットワーク的な所だと、NIC＆ポート・ファン・電源・ディスクといった機器リソースの監視等もあったりする。

死活もだけど通知にはよく何種類かあって、Warning, Criticalという警告レベルがある。例えばメモリ使用量が7割を超えたらWaring、9割を超えたらCrititalというように、通知される警告レベルに段階を設定する事で、急転直下で「突然ヤバいぜ!!」(Critical)という事が無くなる。

 

3.プロセス
これもその名の通り、OS上で動いているプロセス数を監視する。「プロセスが無くなったら止まっているんだし、死活で分かるじゃん」とパッと思うかも知れないけど、forkや何かバッチでプロセスが大量生成されていないか？サービスレベル(Apache/DB)以外の物で確認が必要なプロセスがあった時のも含まれる。

 

4.ログ
これはOSが吐き出すsyslogもだけど、アプリケーションが吐き出すログも対象にして、「ログにこの文字(CRITICAL)が含まれていたら、何か異常が発生しているから通知する」といった感じになる。通知しないにしても、ERRORやWARNINGをカウントして監視用ミドルに残しておいて、状態の確認を行えたりする。

ちなみに、監視のタイミングは常時行われてる物ではなく、大抵は5分に1回のタイミングで監視のタスクが実行される。つまり、定点観測される時間以内に発生した事はある意味ブラックボックスになってしまうため、ログ監視を行うことでそれらを補完する事が出来る。例えば、死活・リソース・プロセス監視を行っていても、その5分以内にWeb(Apache)が再起動したとしても検知は出来ない。ただしログを見ると、”caught SIGTERM, shutting down”といったように再起動が行われたイベントが書いてあると、再起動が行われた!!と通知を行う事が出来る。

 

5.サービス・アプリ(optional)
1-4は基本的な監視でシステムが何であっても大抵は同じような感じだと思う。ただ、これは「サービス・アプリがどういった状態で稼働しているのが正しいのか？」という、サービス・アプリが正常に動作している事を確認する事になる。
例えば、何らかの認証APIを利用しているアプリケーションの場合、上記の監視1-4が正常に稼働していてもアプリケーションに不具合が発生して認証出来ない事が発生するかも知れない。その時、認証APIが正常に動作しているか監視を行うことで、問題点の早期発見につながる。

この監視が付随的だと思っているのは、サービス・アプリの独自の正確が出ることで、監視側もそのサービス・アプリに特化した監視用スクリプトを用意する事になる。前述の認証APIのように、あるプロトコルや引数を渡さないと確認出来ないような物は、その監視のために特別な物を用意する事になって…そう、つまり面倒の一言に尽きる。ただ、ちゃんとしている所は、「サービス・アプリとしてこの部分の動作確認が取れていないとヤバいだろう」という部分については監視を行っていたりする。

 

他にもセキュリティ監視(iptablesで怪しいのは通知＆取っておいたり、WebだとWAFを仕掛けておくとか)、ミドルレベルならメールキューの数を監視したり色々他にもある。あと冒頭に書いたように、色んな監視用ミドルがある訳で、最初に用意しておけば使い回しも出来るしとっても便利だと思う。ただツールを使うにしても、デフォルトの設定や書いてある通りに行うのではなく、何で？どういう監視が必要なのか？というのを知っておいた方が良い。
監視していないシステムは止まっているのと一緒だと思うけど、何でもかんでも監視すれば良いという訳でも無いと思うし、監視を運用するコスト・問題が発生した時の対応といった別の課題もある。ただ、最低限の監視(1-4のどれか)を行っておいた方が良いのは間違い無いと思うけど。