やっぱ監視でしょ？

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

IT運用といえば、最初に出てくるのがやはり監視でしょう。
世の中にも監視ツールが氾濫してきており、最近ではオープンソース系の監視ソフトウェアなんかも出てきていますよね。

よく監視システムの要件を検討している人に言われるのが、

「この監視ツールで何が監視できるか提示してくれ。」

大抵、この回答をつくると膨大な項目を記載したExcelファイルとか、製品のマニュアルコピーが提出される。
そもそも、監視の仕組みが分かっている人であればこんな要求はしないはずである。

監視とはそもそも
ITサービスを構成しているコンポーネント（ITIL的には構成アイテム、CI）の状態の変化を情報化し評価すること
である。

この情報がレコード化されるとイベントと言ったりする。評価の際に平常時（標準状態）から乖離した場合にイレギュラーな状態と評価・判断され、その情報イベントはインシデントとなる。

ここで注意すべきは、
「イベントは必ずしもインシデントにはならない」
ということだ。

先にも述べたとおり、イベントは変化を情報化しているわけで異常とは限らない。
例えば、「定期的なジョブ実行が正常に終了した。」という変化は異常ではないし、「CPUのトータル使用率が60%を超過した。」からと言って異常とは言いきれない。

インシデントは、ITILぽく言うと
「ビジネスの停止や劣化を招く恐れのある全てのイベント」
であるからだ。

監視の仕組みの話に戻ろう。
監視というのは構成アイテムの状態の変化を捉えることであるから、その状態の変化をどうやって情報化するかが仕組みを知るということになる。

結論を言うと、監視するためにはデータソースが必要で監視ツールは、そのデータソースがないと情報を取得できない。

データソースはその構成アイテムを製造しているベンダが何らかの仕様をもって実装しているわけで、実装されていない情報は取得できるはずがない。

例えば、ネットワーク機器のCPU使用率を監視できるか？という質問については、以下のような仕組みを知っていればよい。
ネットワーク機器のCPU使用率はSNMPのMIBとして、製造元が実装していることが前提となる。
監視ツールがSNMP GETを実行出来る機能を装備しており、閾値を定義出来れば監視可能となる。これはネットワーク機器のメモリ使用率でも同じことだ。この場合、データソースはMIBであり、取得方式はSNMP GETである。


UNIXオペレーティングシステムであれば、sar(1m)やvmstat(1m)などのコマンドからデータソースであるUNIXカーネル情報にアクセスして目的の値を取得できる。この場合のデータソースはカーネル空間であり、取得方式はコマンドラインインターフェイスとなる。

つまり、
「この監視ツールで何が監視できるか提示してくれ。」
という回答を考えると、数百項目の情報になってしまい、あまり参考にならなかったという顛末になる。仕組みが分かっていれば応用が効くので、なにも一つ一つ洗いだして確認する必要はないのだ。この後に来るお客からの要求は、
「何を監視すればいいのか教えてくれ。」
だ。
この回答については、これまた長くなるので次回にしよう。

監視は何のためにするのか？

私は、

「ITサービスを構成するCIが正常に稼働していることを評価し、証明すること」

が目的だと考えている。
そうなれば、そもそも

• システムを構成しているCIは何か？
• それらが正常稼動している状態はどういう状態か？（逆を言えば何を持って異常とするか？）

を知っておく必要がある。
こう言ったことはシステムの特性によって異なるので、監視を含め運用を設計する人材を早めに開発工程に参画させる必要がある。

「監視するには監視対象がどんな仕組みになっているか知っておく必要がある。」