【モニタリング101コース】 ITモニタリングの基礎講座: Lesson2 - 監視の構成要素

Version 7

    【モニタリング101コース ― ITモニタリングの基礎講座】

    レッスン2: 監視の構成要素

     

    モニタリング101コース』のレッスン2にようこそ。今回は、監視の構成要素を取り上げます。

     

    利用するソフトウェア、プロトコル、技法とは無関係に、監視システムには、いくつかの基礎項目が存在しています。

    それが、監視の基本構成要素です。すべての構成要素が、すべてのソフトウェア・ツールや監視技術の中に含まれるわけでは

    ありませんが、どの構成要素も監視作業に組み込まれる可能性のある重要な概念です。

     

     

    <要素>

    監視対象のデバイスに存在する1つの構成要素であり、監視システムに様々な情報を返します。

    例えば、IPアドレスですが、次の3つのデータ のポイントを把握できる可能性があります。

    1) 応答しているかどうか、2) どのくらいの早さで応答しているか、3) 応答中に破棄されたあらゆるパケット

     

    <取得方法>

    情報の取得方法も、1つの重要な概念となります。

    デバイスが状況のアップデートを送信してくるのを待っているか (プッシュ型)、それとも、積極的にデバイスに対し、

    状況を取得しようとしているか (プル型)。また、どのようなプロトコルを使用して対象デバイスと接続しているか。

    などが挙げられます。

     

    <頻度>

    取得方法と密接に結び付いているのが、情報の取得頻度です。

    たとえば、デバイスはハートビートを数分ごとに送信しているか、問題が生じたときにだけデータを送ってくるのか。

    5分ごとにポーリングし、構成要素の情報を収集しているのか、などが挙げられます。

     

    <データ保持期間>

    監視とは、その本質から、データ集約型です。

    取得方法がプッシュであれプルであれ、得られた統計データは、通常、然るべき処理を行い集積されます。

    最も単純なデータ保持に関する選択肢は、データを保持するか、保持しないかの決定となります。

    つまり、統計データは、収集、評価、行動、そして破棄されるか、データストアに保存されるかのどちらかです。

    データ保持の方法について、より詳しく見てみると、データを一定サイズのログとして保存する方法と、特定の期間に従ってデータを

    保持する方法があります。また、ログとして保存し、事前に決めた間隔 (すなわち、ファイルが一定のサイズまで増大したとき、

    特定の期間が経過したとき、など)でアーカイブしたり、データベースなど、より堅牢なデータストアに保存することも可能です。

     

    <データ集約>

    統計データをしばらく保持しておくと、一定期間経過した細分化されたデータは不必要であることが分かります。

    集約とは、ある範囲の複数のデータを統合あるいは平均化して1つの数値にする操作です。

    たとえば、5分ごとの統計データを収集しているとします。1週間経過すると、5分単位で集められた複数のデータは、

    1時間の平均値に集約(つまり、12個のデータが平均化され、1時間分の1つのデータになる)されます

    1か月後、その1時間単位の複数のデータはさらに集約されて、1日の平均値になります。

    このようにして、詳細分析が可能な短期的な統計データと、多少精度の落ちる集約された長期的な統計データ

    組み合わせることにより、分析精度を維持しつつ、データベース利用量を最適化します。

     

    <しきい値>

    ここでもう一度、FCAPSモデルに戻りましょう。

    障害(Fault)の監視とは、統計データを収集し、それが何らかの一線を越えていないことを調べる、という発想です。

    これは、ごく単純な条件、たとえば「サーバーの電源がオンかオフか?」が挙げられます。実際には、もう少し複雑な場合が多いでしょう。

    いずれにしても、境界線がしきい値です。以下に、しきい値の例を示します。

    • ひとつのトリガー

    トリガーとは、ある条件に到達した場合です。

    条件は、「X50を超えたとき」のような単純なものである必要はなく、複雑でもかまいません。

    たとえば、現在の時刻が午前8時から午後5時までの間で、かつX50を超えており、かつY20未満である、など

    トリガー自体の複雑さがどうであれ、トリガーとは、超えてはならない一線のことです。

    • 差分

    このしきい値は、固定値ではなく、変更量に注目します。たとえば、ディスク使用率が20%増加した時、などです。

    • 発生回数

    多くの場合、トリガーと組み合わせ、特定のトリガーが発生する回数を測定します。

    たとえば、CPU使用率が85%を超える現象が、15分以内に続けて5回起こったとき、などです。

     

    <リセット>

    リセットは、しきい値の論理的な対義語です。リセットは、デバイスが「正常に復帰した」と見なされるポイントを示します。

    単純な例で言えば、しきい値が「デバイスがダウンしたとき」であれば、リセットは「デバイスが起動したとき」になるでしょう。

    しかし、そのように常に厳密に一致するわけではありません。

    しきい値が「ディスク使用率が85%を上回ったとき」のリセットは「ディスク使用率が70%を下回ったとき」になることもあります。

    しきい値と同様に、リセットはひとつのトリガー、差分、または発生回数に基づいて評価されます。

     

    <レスポンス>

    しきい値とリセットに関する説明をしてきましたが、次に浮かぶ疑問は「OK、それで」かもしれません。

    しきい値を超過すると、何が起こるのでしょうか? レスポンスが、それを定義します。

    レスポンスとしては、eメールの送信、音声ファイルの再生、事前に定義されたスクリプトの実行などがあります。

    実際に実行できる選択肢は、個々の監視アプリケーションの対応する機能によって制約を受けますが、レスポンスの概念は同じです。

     

    <リクエスタ> (ローカル エージェントまたはリモート システム)

    では、このデータ要求は、どこで実行されるのでしょうか?言い換えると、監視の統計データは、どのシステムが要求しているのか?

    あるいは、どの宛先に対し統計データ送信されるのか? と言えます。

    簡単に言えば、以下の2つの方式があります:

    1) 監視対象のデバイス自体の上で動作するソフトウェア コンポーネント (すなわちエージェント)

    2) 監視対象デバイスの外部の何か (エージェントレス)

    これについては、本コースの後続のレッスンで詳しく取り上げます。

     

    <認証>

    リクエスタと切り離せない関係にあるのが認証です。リクエスタは (エージェントであれ、エージェントレスであれ)

    どのようにして監視統計データを要求したり受け取る許可を得るのでしょうか?

    認証手法は多種多様であり、通常は、監視技術ごとに固有のものとなります。これについても、後で詳しく説明します。

    今のところは、何かを監視するということは、監視データの受信許可を持つことと直接結び付いている、ということを

    理解しておけば十分です。

     

    次回は、監視技術へと話を進める予定です。それまでに、以下のちょっとした質問について考えてみてください。

     

    • 「監視におけるIPアドレスは、要素に分類される」これは正しいでしょうか、誤りでしょうか?

     

     

    レオン・アダト(Leon Adato

    ソーラーウインズ認定ヘッドギーク

     

    Lesson1: FCAPSモデル https://thwack.solarwinds.com/docs/DOC-191361

    Lesson3: