なにを監視すれば正解？

こんにちは、さすらいのIT運用コンサルタント・ウータイです。

先の監視についてのブログで、

管理者：「御社の監視ツールで何が監視できるか教えて。」

という依頼について、監視機能のリストを提出すると

管理者：「何を監視すべきか教えて。」


っていうような、要求をされて困るなぁ。って話がありました。

また、
監視はITサービスを構成する構成アイテムのステータスを収集することから始まる。
ステータスはデータソースからなんらかのインターフェースを使って取り出す。
ということも書きました。

では、IT運用のコンサルタントとして、管理者さんのお悩みにどう答えましょう・・・？

監視対象となるITシステムは、主に

• ハードウェア（ネットワーク、サーバ、ストレージなど）
• オペレーティングシステム（Windows, Linux, UNIXなど）
• ミドルウェア（データベース、アプリケーションサーバ）
• アプリケーション

などなどの構成タイプが存在しますよね？
で、市販の監視ツールにはテンプレートなるある程度、上記の製品の監視項目をまとめた定義体がそろっています。

ところが、これらのテンプレートは取得できるほとんどの項目を含んでいるため、管理者さんの「監視すべき項目」の答えにはマッチしないようです。
大抵、テンプレートなる監視項目群を適用すると、訳の解らんアラームがバンバン表示されて使えないってな事になりがちです。
つまり、ツールベンダが用意しているテンプレートはあくまで参考として、管理者は自分でその中から選択して使用するという心構えが必要なのです。

では、監視すべき項目をどう決めるのか？
という事に関しての考え方ですが、目的をいくつか設定してみます。

1. 障害やその予兆検知のため
2. 障害発生後の詳細な分析のため
3. 今後のシステム増強計画（キャパシティ計画）のため

ってな感じです。
上記３つは全て構成アイテムのステータスを収集したデータを基礎として利用されます。

１は監視そのものです。何らかのルール（ポリシー）を決めておき、ステータスがイレギュラーになったかどうか逐次評価を行います。

２は評価は行わず、詳細情報として直近の期間だけ記録しておき、トラブルシューティングに利用するという目的で使われます。

３は１や２を中長期のサマリとして記録しておき今後のシステムリソースの使用状態傾向などを推測するために使用します。

監視すべき項目は１の目的を果たす項目になります。これを構成アイテムのKPIと私は呼んでいます。つまり、その構成アイテムがITサービスに貢献できているかどうかを測る基準ということです。
KPIの数値が事前に設定した閾値以下であればシステムの稼働要件を満たしているということになり、閾値を超過すると稼働要件を満たせない状態に陥っており、イレギュラーとなる。
という感じの解釈になります。

これらKPIは、そのシステムの仕様や動作によって変化することがあります。
単純な故障やエラーは検知しやすいですが、性能劣化の予兆を検知するには監視項目の吟味が必要かもしれません。

例えば、データベースサーバのデータ領域のディスク容量は監視しておいたほうが良いと考える方が多いかもしれませんが、あまりデータの書き込みが少ないようなWebサーバはディスクフルは動作上起こりにくいから監視しなくてもいいかな？という感じです。
また、CPUのトータル使用率（％）も何パーセント以上が性能劣化なのかは判断しずらいですが、ロードアベレージなどを見ればCPU処理待ちプロセスがどれだけいるのかがわかり、判定はしやすくなったりします。

このように、システムがどのような原理で動いているのかを知り、性能劣化の予兆がでやすい状態はどんな状態なのかを知ることが重要になるわけです。

なので、事前の負荷テストなどでシステムの稼働状態を記録しておき、ボトルネックになりやすい構成アイテムとその項目を探しておくということが推奨されます。

ま、一般的にサーバならシステムログのエラーやシステムリソースの全体使用率やキューサイズ、使用されているプロセスの死活などを監視することが一般的でしょう。

監視項目の設計には、「それを監視してどんなイレギュラーを検知したいか？」という目的意識を持つこと。

が重要です。
なので、「イレギュラーではない状態の定義、何を持って正しいとするか？」を必ず取り決めることになります。