■ Zabbixの概要
本記事執筆時点（※2014年12月）での最新版は「2.4」です。「3.0」のリリースを2015年5月に予定しているそうです。
◇
Zabbixでは、システム／アプリケーション監視に係るありとあらゆることが実施可能です。“およそぱっと思い付くようなことはほぼ全て実現可能”と言ってよいでしょう。
（監視の例）
- ICMP等による死活監視- シナリオベースのWeb監視- クエリーベースのRDBMS監視- CPU、メモリー、ディスク等の監視（※要ターゲットへのエージェント導入）- ログの監視（※要ターゲットへのエージェント導入）
（通知の例）- メールの送信- SMSの送信- 任意のシェルコマンドの実行
「シナリオベースのWeb監視」では、複数の一連のHTTPリクエストを特定の順序で発行して応答を監視することができます。よって、例えば「ログインして発注履歴の特定の1件を表示」といった動線の流れで監視することができます。（※応答の内容によって次に発行するHTTPリクエストを動的に切り替えることはできないようです。）もちろん、単一のHTTPリクエストで、単純な死活監視に用いることもできます。
「クエリーベースのRDBMS監視」では、RDBMSへ直接SQL SELECT（※一般にはSELECT COUNT(*) ...）を発行して、SELECT COUNTの結果値やSQLの応答速度を監視することができます。SELECTの結果値は、第一行目の第一カラムの内容だけチェックができるようです。よって、一般にはCOUNT(*)を取ってみることが多いようです。
「CPU、メモリー、ディスク等の監視」では、設定した閾値を上回ったら／下回ったら通知する、といった運用ができます。
「ログの監視」では、ログファイル中に特定文字列パターン出現したらその旨通知する、という運用ができます。典型例として、Log4j等によるログ出力で"FATAL"や"ERROR"が出現したら通知する、といった運用が考えられます。
■ システム／アプリケーション監視に係る総合的な運用設計について
「システム／アプリケーションの監視」といっても、プロセスの死活監視するとか、メモリー使用量監視するとか、個々のアクティビティは分かるのだが、それらの総体としての運用設計をどのように組み立てればよいのか、つまり、いざ“インシデント”が発生したときどのように対処をしていけばよいか、トータルの運用フローを想起することがなかなかできませんでした。しかし、その点に関してヒントとなる言及を下記ページに見出すことができました。
"Pro-active monitoring（プロアクティブな監視）"：
"IT services（ITサービス）"：
※マニュアルの日本語版は「2.2」ならばオープンなようで、いかなるsubscriptionなくとも参照できるようです。ただ内容は当然最新ではありません。英語版は「2.4」、「3.0」ともオープンでした。
"Pro-active monitoring"の論旨を私は以下のように解釈しました。
(1) インシデントを検知したら、Redmine、Backlogといったイシュー・トラッカーに直接チケット登録する
通知すべきイベントを検知したら、メール等で通知する以外に、イシュー・トラッカーに直接チケット登録するスクリプトを開発して、それを連携させることもできます。これにより、インシデントの効率的な共有・管理が可能となるでしょう。
(2) 直ぐ参照できるように、監視対象のプロフィールを整備しておく監視対象のハードウェアやソフトウェアの各種諸元や属性、あるいは担当連絡先を登録しておくと、インシデント発生時の通知に当該情報を含める事ができます。このことは初動を早めることに貢献するでしょう。Zabbixは、監視対象に関する諸元や属性情報の登録簿機能を提供しています。
(3) インシデントに対応して、緊急復旧措置を行うスクリプトを用意する
イベント検知に対応して、任意のシェルコマンドをSSHで監視対象側で実行させることができるので、例えば応答の無くなったプロセスを再起動するというような、緊急復旧措置を行うスクリプトを実行する、という運用を検討する事ができます。前述のイシュー・トラッカーへのチケット登録と同時に、緊急復旧スクリプトを実行するのがよいでしょう。
(4) 緊急復旧スクリプトが実行されても同一インシデントが検知され続けたり、緊急復旧スクリプト自体が失敗あるいは異常終了した場合、それをエスカレーションする運用フローを用意する
あるイベントが一定期間の間検知され続けるとき、通常とは別の通知やシェルコマンド実行を行うよう構成することができます。この仕組みと緊急復旧スクリプトを組み合わせると、下記のような運用を実現する事ができます。
1. 例えば、あるプロセスの応答が無いという死活監視イベントを検知した。2. イシュー・トラッカーにその旨を登録した。担当者の携帯端末への通知はしない。3. 同時に、緊急復旧スクリプトによってプロセス再起動を実行した。4. 再起動によって、当該プロセスの応答が復帰すれば、以上で緊急復旧措置は完了。（続いて、イシュー・トラッカーに登録されているチケットに基づいて根本の問題解消を図る。）5. 再起動したにも関わらず、当該プロセスの応答が無いままであれば、エスカレーションフローを発動し、エスカレーション・イシューの登録と、担当者へのSMS通知を行う。
"IT services"については、以下のように解釈しました。
業務あるいは“サービス”のレベルで見たとき、個々のサブシステム／アプリケーションが機能停止したうんぬんということより、その障害は、つまるところどの業務あるいは“サービス”に影響するのか、そこを直ちに知りたいのです。Zabbixは、この要求に対して、業務／サービスがどのサブシステム／アプリケーションによって担われているか、その依存関係を定義、管理し、インシデントがいずれかのサブシステム／アプリケーションにおいて生じたときに、それが波及する業務／サービスがいずれであるか直ちにビジュアライズする機能を提供しています。
例えば、受注の参照系業務には、認証、受注管理の両サブシステムが必要、受注の入力系業務には、認証、受注管理、在庫管理の各サブシステム、また出荷業務は、認証、在庫管理、配送管理の各サブシステムに担われているとします。そして、認証サブシステムはサーバーAで、受注管理はサーバーB、在庫管理と配送管理はサーバーCで稼働しているとします。ここで、サーバーCにディスク障害が発生した場合、影響を受ける業務はどれでしょうか？
【依存関係のグラフ】
Zabbixのモニタリング画面で直ちにこのような状況を一瞥することができます。
◇
ただ、上記ような運用を実践するには、個々のシステムの、実装（≒提供）観点から見た構成だけでなく、「業務とそれを支えるITシステム」の全体を、俯瞰的に、要求（≒利用）観点から“モデリング”しておくことが必要となります。
◆以上
＜'15/3/7更新＞
関連記事
