システム監視の理想と現実システム監視ツールを導入すれば終わりではありません。
重要なのは監視設計です。
十分な監視設計を行ったうえで、ツールに設定を投入します。
当然監視設計はシステム構成を十分に把握した者が行うべきです。
また、監視設計者に重要な資質として「想像力」と「疑う事」が非常に重要になります。
想像力
このLANケーブルが抜けたらどうなる？サービスにどんな影響がでる？
この機器が停止したら、どうなるんだっけ？
このプロセスが止まったら、どうなるんだっけ？
疑う事
「このシステムにはシングルポイントはないから、大丈夫」
本当にシングルポイントはないのでしょうか？
たとえばストレージのバックプレインが壊れる事は本当にないのでしょうか？
ストレージのHDDはRAIDで構成されます。
ストレージのコントローラは冗長化されています。
HDDやコントローラが接続されるバックプレインは本当に壊れないのでしょうか？
バックプレインはHDDやコントローラを接続する基盤ととらえると、誰かが物理的に壊さない限り、
故障は発生しないと考えられます。しかし今ではバックプレインにも多少のインテリジェントな機能が備わっていたりします。
バックプレインが完全な配線のみで構成されるのであれば、壊れないと考えてもいいでしょう。
しかし、インテリジェントな機能が備わっているということは、そこに不具合が発生する可能性があります。
ここまでは監視設計者に必要な資質のことでした。
監視ツールに監視設定を導入し、監視を始めるとさまざまなアラートが発生します。
「対処が不要なアラートが発報されてませんか？」
システム監視の理想は、何かしら対処が必要な場合にのみ、アラートが発報されることです。
ここで重要になるのは対処です。
たとえばWebシステムのApacheのプロセスが停止したと想定します。
その場合の対処は、Apacheのプロセスを迅速に起動することです。
また、なぜプロセスが停止したのか調査することです。
これは比較的簡単な監視アラートの対処です。
しかし、世の中にはありとあらゆるハードウェア、ソフトウェアがあります。
たとえばWindowsServerのイベントログ困ったことありませんか？
「○○が○○しました。」「○○が解決できませんでした。」はて？何のことやら。。。
重要なことは真にサービスに影響があるメッセージを見極める事です。
その為に、機器毎にエラーメッセージのナレッジベースを作成すると良いでしょう。
ナレッジベースが育てば、監視設計の初期フェーズの精度は飛躍的に向上します。
そうなれば夜中に起こされる頻度も減りますね。
