Pandora: Documentation ja: Intro Monitoring

From Pandora FMS Wiki
Jump to: navigation, search

Pandora FMS ドキュメント一覧に戻る

1 モニタリングの概要

Pandora FMS のすべてのユーザ操作は、ウェブコンソールを通して行います。コンソールへのアクセスは、任意のコンピュータから特別なプログラムを必要とせずブラウザで行うことができます。

監視とは、情報を収集して保存し、そのデータに基づいて決定した処理を実行すために、あらゆるタイプのシステム上のプロセスを実行することです。

Pandora FMS は、収集する情報の範囲や量を拡張できる複数の機能をもったスケール可能な監視システムです。

2 Pandora FMS におけるエージェント

Pandora FMS によるすべての監視は、'グループ' と呼ばれるより一般的な範囲に含まれる 'エージェント' と呼ばれる一般的なエンティティを通して管理されます。 これらエージェントは、監視対象のさまざまなコンピュータ、デバイス、Webサイト、またはアプリケーションを表します。

Pandora FMS コンソールで定義されたエージェントでは、ソフトウェアエージェントを通じて収集されたローカル情報、ネットワークチェックを通じて収集されたリモート情報、またはその両方を表示できます。 そのため、Pandora FMS コンソール上で表現されるエージェントと、対象システムにインストールしてローカルでデータを収集するソフトウェアエージェントは異なるということを理解することが重要です。




AgentHierarchy.png



2.1 ソフトウエアエージェントでのモニタリングと、リモートモニタリング

Pandora FMS には、主にソフトウエアエージェントを使った方法とリモートで行う方法の 2つの監視手法があります。

エージェントベースの監視 は、監視対象にインストールした小さなソフトウエアを用い、ローカルでコマンドやスクリプトを実行して情報を取得します。

リモート監視 は、監視対象の確認をリモートからネットワークを介して行います。監視対象には、追加のソフトウエアをインストールする必要はありません。

つまり、エージェントベースの監視は監視対象のローカルでチェックをして情報を取得し、リモート監視は Pandora FMS サーバからリモートでのチェックで情報を取得します。

Pandora FMS においては、一つの手法もしくは組み合わせでの監視が可能です。

両方のタイプのエージェントは、同じ一般設定とデータ表示を共有します。

2.2 コンソールでのエージェント設定




Configuracion agente consola1.png






Configuracion agente consola2.png



  • 別名(Alias): Pandora FMS がエージェント/モジュールを使って実行するすべての機能を正しく処理するために、エージェント名には /、\、|、%、#、&、$などの文字を使用しないことをお勧めします。 これらのエージェントを使うと、システムパスを使用しているときや他のコマンドを実行しているときに誤解を招き、サーバー上でエラーを引き起こす可能性があります。
  • サーバ(Server): エージェント監視で設定されたチェックを実行するサーバです。インストールで HA を設定した場合は特別なパラメータです。
  • セカンダリグループ(Secondary groups): エージェントが複数のグループに属するためのオプションパラメータ。
  • 関連障害検知抑制(Cascade protection): 関連アラートが大量にあがることを回避することができるパラメータ。 エージェントまたはエージェントのモジュールを選択することができます。 前者の場合、選択されたエージェントが障害状態にあると、エージェントはアラートを生成しません。 後者の場合、指定されたモジュールが障害の場合は、エージェントはアラートを生成しません。
  • モジュール定義(Module definition): 3つの動作モードを選択できます。
    • 学習モード(Learning mode)): 新たなモジュールを含む XML を受け取った場合、モジュールを自動的に作成します。(デフォルト)
    • 通常モード(Normal mode): 新たなモジュールを含む XML を受け取った場合、すでにコンソールに設定が無ければ作成しません。
    • 自動無効化モード(Auto-disable mode): 学習モードと同じですが、全モジュールが不明になった場合に情報が再度車でエージェントを無効化します。

2.3 コンソールでのエージェント参照

この画面では、エージェントに関する多くの情報を見ることができます。リモート実行を強制し、データを更新することができます。

Visualizacion agente consola1.png

上部には、エージェントデータの概要が表示されます。

  • 全モジュールとその状態
  • 直近 24時間のイベント
  • エージェント情報
    • 名前
    • バージョン
    • エージェント接続
    • グループ
  • ...
Visualizacion agente consola2.png

次に、エージェントに属するモジュールの一覧が表示されます。ここでは、初期化されていない状態のモジュールを表示されません。また、モジュールで生成されたアラートが下に表示されます。

Visualizacion agente consola3.png

最後に、エージェントから生成されたイベントが表示されます。

Visualizacion agente consola4.png

3 モジュール

モジュールは、エージェント内に格納されている情報の単位です。 これらは、エージェントが指しているデバイスまたはサーバの状態を見る監視項目です。 各モジュールに格納できるメトリックは 1つだけです。 同じエージェント内に同じ名前の 2つのモジュールを設定することはできません。 すべてのモジュールは以下の状態を持ちます。

  • 未初期化(Not started): まだデータを受け取っていません。
  • 正常(Normal): データを受け取っており、値が警告や障害の閾値を超過していません。
  • 警告(Warning): データを受け取っており、値が警告閾値を超過しています。
  • 障害(Critical): データを受け取っており、値が障害閾値を超過しています。
  • 不明(Unknown): モジュールは動作していますが、一定期間情報の受け取りが停止しています。

モジュールは、二値、数値、文字列といった、異なるタイプのデータを持ちます。モジュールが収集する情報によって、いずれかのタイプになります。

3.1 モジュールのタイプ

Pandora FMS には、いくつかのモジュールのタイプがあります。

  • データモジュール(Data module): これは、たとえばデバイスの CPU や空きメモリの使用など、ソフトウエアエージェントがインストールされているシステムでチェックが行われるローカル監視モジュールです。 この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • ネットワークモジュール(Network module): これは、エージェントが機能しているかどうか、または特定のポートが開いているかどうかなど、エージェントが指しているデバイスまたはサーバとの接続を確認するために使用されるリモート監視モジュールです。 この種の監視についてもっと知るためには、こちら を参照してください。
  • プラグインモジュール(Plugin module): これは、ローカルまたはリモートの監視モジュールで、スクリプトを作成してカスタムチェックを行うことができます。 それらを使って、Pandora FMS コンソールからデフォルトの監視機能よりもさらに高度で広範囲なチェックを行うことができます。この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • WMI モジュール(WMI module): これは、Windows システムに対して、インストールされているサービスのリストや現在の CPU 負荷の取得などができるリモート監視モジュールです。 この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • 予測モジュール(Prediction module): これは、監視対象サーバーの平均 CPU 使用率や接続待ち時間の合計など、他の "基本" モジュールからのデータを参照してさまざまな算術演算を実行する予測監視モジュールです。 この種の監視についてもっと知るためには、こちら を参照してください。
  • ウェブサーバモジュール(Webserver module): これは、たとえば Web サイトが停止しているかどうか、または特定の単語が含まれているかどうかを確認するなど、Web サイトの状態をチェックしてデータを取得する Web 監視です。この種の監視についてもっと知りたい場合は、こちら を参照してください。
  • ウェブ分析モジュール(Web analysis module): これは、Web サイトの参照、資格情報の導入、フォームへの準拠など、ユーザの Web 参照のシミュレーションが実行できる Web 監視です。 この種の監視についてもっと知りたい場合は、こちら を参照してください。

3.2 共通パラメータ

各モジュールの設定には、全体を通して共通のパラメータがあります。




Parametros comunes modulos1.png



  • モジュールコンポーネントの利用(Using module component): Pandora FMS には、使用可能なデフォルトモジュールのレパートリーがあります。 選択したモジュールに応じて、監視を実行するために必要なパラメータが自動的に入力されます。 この設定は予測モジュールを除くすべてのタイプのモジュールにあります。
  • 動的閾値間隔(Dynamic Threshold Interval): 後述の章で説明する動的監視の設定です。
  • 警告/障害状態(Warning/Critical Status): 後述の章で説明する状態監視の設定です。
  • 連続抑制回数(FF threshold): 障害と復旧の繰り返しは、監視における一般的な現象として知られています。値が正常・障害の間で頻繁に変動する場合、扱いが難しくなります。 これが発生すると、通常 "しきい値" に従って状態が変化してしまうため、一定回数連続して障害状態になった場合のみ障害としたい場合があります。 これを Pandora FMS の用語では "連続抑制回数(FF threshold)" と呼びます。



Fft.png


連続抑制回数 (FF Threshold: FF は FlipFlop を意味します) パラメータは、イベントや状態の連続的な変化をフィルタするために利用します。オリジナルの状態から変化した状態が連続して X 回を超えて続かないと、変化が発生したと Pandora FMS が認識しないようにすることができます。以下に例を見てみましょう。あるホストへの ping でパケットロスがあります。このような場合、次のような結果になります。

1
1
0
1
1
0
1
1
1

しかし、ホストは稼働しています。連続抑制回数を 2に設定し、少なくとも 3回連続でダウン状態にならないと、Pandora にダウンと認識し通知して欲しくないとすると、上記の例はダウンと見なさないパターンに該当します。逆に以下のような場合にダウンと認識します。

1
1
0
1
0
0
0

最後の状態になったときに、ダウンと認識し、それ以前はダウンではありません。

連続抑制回数は、このような不安定な変動を避けるために便利です。すべてのモジュールにおいて実装されており、状態の変化を避けるのに利用します (*proc モジュールの場合は、設定された制限もしくは自動制限により制限されます)。

バージョン 5.1 からは、連続抑制回数には 2つのモードがあります。

  • 全状態変化(All state changing): 正常、警告、障害すべての状態変化に対して、同じ値を利用します。
  • 個別状態変化(Each state changing): 正常、警告、障害への状態変化ごとに異なる値を設定できます。

非同期モジュールでは、タイムアウト(連続抑制タイムアウト)も設定できます。短時間に複数回、警告や障害のデータを受信した場合にのみ障害通知をしたい場合に便利です。 データを受信する間隔がタイムアウト値を超えた場合は、連続抑制回数のカウンタがリセットされます。

Ff timeout.png

たとえば、エージェントから 5分以内に 2回障害データが送られた場合にのみ通知をしたい場合(5分を超える間隔でデータが送られてきても障害通知したくない場合)は、連続抑制回数に 1、連続抑制タイムアウトに 300 を設定します。

    • カウンタ保持

これは、連続抑制の高度なオプションで、モジュールの状態を制御します。"カウンタ保持" によって、値ではなく、受け取った値を持つモジュールの状態に応じて、あるステータスから別のステータスに移行するためのいくつかのカウンタ値が設定されます。

どのように動作するか例を以下に示します。

次のようなモジュールがあると仮定します。

間隔: 5分
しきい値:
  障害: 90 - 100;
  警告: 80 - 90;

連続抑制:
   正常: 0;
   警告: 3;
   障害: 2;

現在の状態: 正常;

そして、以下のようなデータ/状態を受け取ります。

データ 状態
81 警告
83 警告
95 障害
89 警告
98 障害
81 警告
86 警告

例からわかるように、データから状態は警告と障害になりますが、連続抑制の定義にマッチしないため現在の状態は正常です。

カウンタ保持パラメータを設定することにより、カウンタは維持され、結果、状態の変化は以下のようになります。

データ データの状態 モジュールの状態
81 警告 正常
83 警告 正常
95 障害 正常
89 警告 警告
98 障害 警告
81 警告 警告
86 警告 警告

別の例を見てみます。

次のようなモジュールがあると仮定します。

間隔: 5分
しきい値:
  障害: 90 - 100;
  警告: 80 - 90;

連続抑制:
   正常: 2;
   警告: 3;
   障害: 2;

現在の状態: 正常;

状態カウンタは、正常状態と障害状態が連続して到着した場合にのみ累積します。一方で、警告状態は連続して到着しなくてもカウンタを累積することがあります。

状態カウンタは、以下のような場合にリセットされます。 - 値の状態が現在の状態と一致する値が到着した場合 - "カウンタ保持" の状態にマッチし、状態が変更された場合

正常カウンタと障害カウンタには特別な動作があり、連続していない場合はこれらのカウンタのみがリセットされます。

この場合、次のようなデータを受け取ります。

データ データの状態 障害カウンタ 警告カウンタ 正常カウンタ モジュールの状態
81 警告 0 1 0 正常
83 警告 0 2 0 正常
95 障害 1 2 0 正常
89 警告 0 0 0 警告
警告カウンタが 3 になったとき、状態が警告に変更されカウンタはリセットされます。
50 正常 0 0 1 警告
98 障害 1 0 0 警告
正常カウンタと障害カウンタが増え続けるには、連続している必要があります。障害状態の値を受信したとき、正常カウンタは 0 になります。
91 障害 0 0 0 障害
障害カウンタが 2 に達すると、状態は障害に変更されカウンタはリセットされます。
30 正常 0 0 1/td> 障害
31 正常 0 0 0/td> 正常
正常カウンタが 2 に達すると、状態は正常に変更されカウンタはリセットされます。
81 警告 0 1 0/td> 正常
83 警告 0 2 0/td> 正常
12 正常 0 0 0/td> 正常
受け取ったデータが正常状態で、かつ現在の状態と同じであれば、カウンタはリセットされます。

モジュールの高度なオプションには、次の共通パラメータがあります。




Parametros comunes modulos2.png






Parametros comunes modulos3.png



  • 間隔(Interval): モジュールがデータを返す間隔を定義するパラメータです。 リモートモジュールの場合、これはリモートチェックが実行される期間です。 データモジュールの場合、それは定義されたエージェント間隔の X倍を表し、その期間にローカルチェックを実行する数値です。 モジュールがデータを受信しない状態が 3周期以上続くと、不明状態になります。
  • 保存倍率(Post process): モジュールの受信データの保存時の倍率です。デフォルトは 0 で無効状態です。次の変換を実行できます。
    • Seconds to months
    • Seconds to weeks
    • Seconds to days
    • Seconds to minutes
    • Bytes to Gigabytes
    • Bytes to Megabytes
    • Bytes to Kilobytes
    • Timeticks to weeks
    • Timeticks to days
  • 連続抑制時の間隔(FF interval): 連続抑制が有効で状態変化がある場合、次の実行でモジュールの間隔が変更されます。
  • 連続抑制タイムアウト(FlipFlop timeout): 非同期モジュールでのみ使用できるパラメータです。連続抑制による状態変化を有効にするためには、指定された間隔内に連続してデータを受信しなければなりません。
  • 静観(Quiet): モジュールが情報を受信し続けますが、イベントや警告は生成されません。
  • サービス関連障害検知抑制(Cascade Protection Services): これが有効になっている場合、イベントおよびアラートの生成はそれが属するサービスによります。
  • Cron: 分、時間、日、月、曜日でモジュールの実行を指定することができます。3つの設定があります。
    • Cron from: any -> 制限はありません。(デフォルト)
    • Cron from: specific. Cron to: any -> 特定のタイミングで実行します。例: 15 20 * * * は、毎日 20:15 に実行します。
    • Cron desde: specific. Cron to: specific -> 特定の期間で実行します。例: 5-10 * * * * は、毎時 5 から 10分に実行します。
  • カスタムマクロ(Custom macros): 任意の数のカスタムモジュールマクロが定義できます。マクロのフォーマットは次の通りです。
   _macroname_

例:

   _technology_
   _modulepriority_
   _contactperson_

これらのマクロは、モジュールのアラートで利用できます。 モジュールが Web 分析モジュールタイプの場合:

動的マクロは @ で始まる特別なフォーマットを持ち、これらは置換されます。

   @DATE_FORMAT (ユーザが指定したフォーマットでの現在日時)
   @DATE_FORMAT_nh (時間)
   @DATE_FORMAT_nm (分)
   @DATE_FORMAT_nd (日)
   @DATE_FORMAT_ns (秒)
   @DATE_FORMAT_nM (月)
   @DATE_FORMAT_nY (年)

ここで、"n" は符号やマイナスを含まない数値です。

3.3 状態監視

監視をするとき、システムから、メモリ、CPU、筐体温度、接続ユーザ数、eコマースサイトの注文数、その他数値情報をシステムから取得します。時々、我々はデータにのみ興味を持ちますが、一般的に値に対して状態を関連付けたいと考えます。そこで「しきい値」を越えたときに状態が変化し、何が正常か異常かを知らせてくれるようにします。これが監視です。状態の概念につじて説明します。

Pandora FMS は、データに基づき状態を決定するための しきい値 を定義することができます。3つの可能な状態として、正常、警告、障害があります。しきい値は、ある状態が他の状態に移る値です。モジュールの状態は、それぞれのモジュールの設定において次のパラメータによって指定されたしきい値に依存します。

  • 警告状態 - 最小 最大(Warning status - Min. Max.): 警告状態の下限と上限です。モジュールの値がこの範囲に入ると、モジュールは警告状態になります。上限を設定しない場合は、無限(下限を超えたすべての値が対象)となります。
  • 警告状態 - 文字列(Warning status - Str.): 文字列モジュールに対する正規表現です。マッチするとモジュールは警告状態になります。
  • 障害状態 - 最小 最大(Critical status - Min. Max.): 障害状態の下限と上限です。モジュールの値がこの範囲に入ると、モジュールは障害状態になります。上限を設定しない場合は、無限(下限を超えたすべての値が対象)となります。
  • 障害状態 - 文字列(Critical status - Str.): 文字列モジュールに対する正規表現です。マッチするとモジュールは障害状態になります。
  • 範囲の反転(Inverse interval): 警告と障害のしきい値両方の設定に存在します。有効化すると、モジュールは、値がしきい値に指定した 範囲外 になった場合に状態変化します。文字列モジュールに対しても動作します。文字列が、警告/障害文字列にマッチしなかった場合に状態が変わります。


Threshold1.JPG



Threshold2.JPG


Info.png

"警告" と "障害" のしきい値が重なっている場合は、"障害" しきい値が常に優先されます。

 


3.3.1 数値しきい値 - ケーススタディ 1

CPU 使用率モジュールは、エージェントのステータスの中で常に緑色です。これは単に 0% と 100% の間の値を報告するためです。 70% に達したときに CPU 使用率モジュールが警告状態(黄色)になり、90% に達したときに障害状態(赤)になるようにするには、次のようにしきい値を設定する必要があります。

  • 警告状態 最小値: 70
  • 障害状態 最小値: 90


Threshold3.JPG


値が 90 に達すると、モジュールは赤(障害)、70 とp 89.99 の間は黄色(警告)、70 を下回ると緑(正常)になります。

閾値の操作で、このような場合は上限を設定する必要はありません。 これは、下限しきい値のみが設定されている場合、上限しきい値は「無限」として考慮されるため、下限を超える任意の値がしきい値範囲内であると考慮されるからです。 さらに、しきい値を超えた場合は、警告よりもクリティカルなしきい値が優先され、前のスクリーンショットに示すしきい値のグラフが表示されます。


3.3.2 文字列しきい値 - ケーススタディ 2

文字列 タイプのモジュールの場合、警告状態 および 障害状態文字列(Str)パラメータフィールドに正規表現を使うことにより状態を設定することができます。 ここでは、実行結果として "OK", "ERROR connection fail", "BUSY too many devices" を返すモジュールがあるとします。

テキストモジュールの警告および障害状態を設定するには、次の正規表現を使います。

警告状態: .*BUSY.*
障害状態: .*ERROR.*


Threshold4.JPG


この設定により、モジュールは、データに BUSY という文字列が含まれている場合は警告状態、データに ERROR という文字列が含まれている場合は障害状態となります。正規表現は大文字小文字を区別するということに注意してください。

3.3.3 動的監視 (自動しきい値設定)

動的監視は、インテリジェントかつ予測的な方法でモジュールの状態しきい値を自動的かつ動的に調整します。この処理では、しきい値の設定を指定の期間で収集した値から平均および標準偏差を計算することによって行います。

設定はモジュール単位で行い、設定可能なパラメータは次の通りです。

  • 動的しきい値の間隔(Dynamic Threshold Interval): しきい値を計算するための時間間隔です。1ヵ月を選択すると、システムは過去 1ヵ月間のデータを使ってしきい値を設定します。
  • 2つの動的しきい値を使う(Dynamic Threshold Two Tailed): 有効化すると、動的しきい値システムは、平均より のしきい値も設定します。無効化(デフォルト)している場合は、平均値の のみのしきい値を設定します。
  • 最大動的しきい値(Dynamic Threshold Max.): パーセンテージの設定で上限を増加させることができます。例えば、平均値が 60前後で障害状態のしきい値が 80のときに、最大動的しきい値を 10 に設定すると、障害状態のしきい値を 10% あげることができます。結果、障害状態しきい値は 88 となります。
  • 最小動的しきい値(Dynamic Threshold Min.): 2つの動的しきい値を使うが有効の場合のみ設定可能です。パーセンテージの設定で下限を下げることができます。例えば、平均値が 60前後で障害状態のしきい値が 40のときに、最小動的しきい値を 10 に設定すると、障害状態のしきい値を 10% 下げることができます。結果、障害状態しきい値は 36 となります。

また、pandora_server.conf にいくつかの追加の設定パラメータがあります。

  • dynamic_updates: このパラメータは、動的しきい値の間隔 で指定した期間に何回しきい値を再計算するかを決定します。動的しきい値の間隔 を 1週間に設定した場合、通常は 1週間前までのデータを集め、1回のみ計算します。1週間後、同じ処理を実施します。"dynamic_updates" パラメータの設定で、この頻度を増やすことができます。例えば、値を 3に設定すると、1週間(動的しきい値の間隔で指定した期間)の中で最大 3回再計算します。デフォルトの値は 5です。
  • dynamic_warning: 警告および障害しきい値の間の差分パーセンテージです。デフォルト値は 25 です。
  • dynamic_constant: しきい値を設定するために使う平均の標準偏差を定義します。値を大きくすると、平均値からしきい値が離れていきます。デフォルト値は 10 です。

以下の例では、計算された平均値は赤線です。(約 30)


Thresh1.JPG


動的しきい値が有効化されている場合、上限のしきい値は次のように設定されます。(約 45かそれ以上)


Thresh2.JPG


2つの動的しきい値を使う(Dynamic Threshold Two Tailed) を有効化している場合、障害しきい値は平均値の下にも設定されます。(約 15およびそれ以下)


Thresh3.JPG


"最大動的しきい値(Dynamic Threshold Max.)" および "最小動的しきい値(Dynamic Threshold Min.)" を 20 および 30 に設定すると、しきい値の範囲が少しだけ広がります。


Thresh4.JPG


3.3.3.1 ケーススタディ 1

Web の応答時間モジュールを例にとります。しきい値の計算期間は 1週間です。


Dynamic1.JPG


設定を保存し、pandora_db が実行後されると、しきい値は次のように設定されます。


Dynamic2.JPG


このとき、モジュールは、応答時間が 0.33秒より大きい場合には「警告」ステータスに、0.37秒より大きい場合には「障害」に切り替わります。 グラフは次のようになります。


Dynamic3.JPG


ここでは、しきい値はやや高いと考えられるため、パラメータ 最小動的しきい値 を使用して最小のしきい値を下げることにしました。 この場合、ある値を超えるものはすべて対象となり、しきい値は最大値を持たないため、 最大動的しきい値 は使用しません。変更は次のようになります。


Dynamic4.JPG


変更を行ったあと pandora_db が実行されると、しきい値の設定は次のようになります。


Dynamic5.JPG


グラフは次のようになります。


Dynamic6.JPG


3.3.3.2 ケーススタディ 2

この例では、制御室または CPD の温度を監視しています。グラフは、わずかなばらつきのある値を示しています。


Dynamic7.JPG


このような状況では、温度は安定した状態で、極端に高い値や極端に低い値になることはあまりありません。そのため、パラメータ 2つの動的しきい値を使う を設定して、上下両方のしきい値を調整します。 設定は次のとおりです。


Dynamic8.JPG


自動的に生成されたしきい値は次の通りです。


Dynamic9.JPG


グラフは以下のようになります。


Dynamic10.JPG


この場合、23.10 と 26 の間の値は常に正常とみなされます。これが制御室で許容される温度です。必要に応じて "最小動的しきい値" および "最大動的しきい値" でしきい値を調整することができます。