Pandora: Documentation ja: Intro Monitoring

From Pandora FMS Wiki
Jump to: navigation, search

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

1 モニタリングの概要

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

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

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

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

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

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

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

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

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

3 Pandora FMS のエージェント

Pandora FMS で行われるすべての監視は、一般的に "エージェント" と呼ばれる対象を通して管理されます。それは、グループと呼ばれるより一般的な単位に分類されます。これらのエージェントは、監視しているさまざまなコンピュータ、デバイス、Webサイト、またはアプリケーションのそれぞれを表します。

Pandora FMS コンソールで定義されたエージェントは、ソフトウェアエージェントを通じて収集されたローカル情報、ネットワークチェックによって収集されたリモート情報、またはその両方を表示できます。 したがって、Pandora FMS コンソールの管理単位としてのエージェントと、ローカルでデータ収集を行うソフトウェアエージェントは別の意味であることを認識しておく必要があります。




AgentHierarchy.png



4 状態監視

監視をするとき、システムから、メモリ、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

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

 


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

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

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


Threshold3.JPG


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

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

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

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

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

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


Threshold4.JPG


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

4.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


4.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


4.3.2 ケーススタディ 2

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


Dynamic7.JPG


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


Dynamic8.JPG


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


Dynamic9.JPG


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


Dynamic10.JPG


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

5 その他共通モニタリングパラメータ

5.1 監視間隔

すべての同期監視システムでは、どのくらいの頻度で監視を行うかを定義する必要があります。5秒、5分、5時間などです。期間が短い場合、多くの情報が保存されます。5分ごとに処理すると、1日で 5x12x24=288 件のデータ、30秒ごとに処理すれば、2880件になります。どれだけのデータを扱うかを理解するためには、Pandora FMS では単に「間隔」と呼ばれる概念を理解することが重要です。

5.2 データの保存

Historicaldata.png

Pandora FMS は、どんなデータでも個別に保存することができます。デフォルトでは、すべてのモジュールのデータを保存します (それにより、グラフ表示やレポートの作成等が可能です)。しかし、多くのデータをモニタする必要がある大きなシステムでは、リソースの消費を押さえるために、いくつかのデータは保存しなくてもいいかもしれません。

このオプションにより、保存の必要がないモジュールのデータを保存しないようにできます。保存を無効にしても、アラートの動作、イベントの生成、現在の状態の参照は可能です。

5.3 連続抑制回数

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 を設定します。