Pandora: Documentation ja: Services

From Pandora FMS Wiki
Jump to: navigation, search

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

1 サービスモニタリング

Info.png

Enterprise 版
サービスモニタリングは、Pandora FMS Enterprise 版の機能です。

 


1.1 概要

Pandora FMS における サービス は、その機能に基づいてITリソースをグループ化する方法です。

サービスは、公式のWebサイト、CRMシステム、サポートアプリケーション、またはプリンタなどです。 サービスは、ホスト、ルーター、スイッチ、ファイアウォール、CRM、ERP、Webサイトその他の多数のサービスを含む論理的なグループです。

Pandora FMS では、監視要素(モジュール、エージェント、その他サービス)のグルーピングとしてサービスを表現します。それぞれの個々の状態が、特定の方法でサービス全体が機能しているかの判断を行います。ビデオチュートリアル "Service monitoring in Pandora FMS" もご覧ください。

1.2 Pandora FMS におけるサービス

Pandora FMS における基本的な監視は、異なる対象からの情報を収集することから成っています。それらを監視項目(モジュール)と呼びます。 サービスの監視により、これらのモジュールをグループ化することができます。その結果、障害の蓄積に基づいて一定のマージンを持ちながら、大規模かつ一般的なサービスにおけるさまざまな種類の要素のグループとそれらの関係を監視できます。

一言で言えば、サービス監視は、私たちがグローバルサービスの状態をチェックすることを可能にします。 サービスが正常に提供されているか(緑色)、劣化しているか(黄色)、サービスを提供していないか(赤色)がわかります。

Leyenda de colores y su significado.

サービス監視には、シンプル、重要度、カスケードイベントの連鎖という 3つの概念があります。

1.2.1 シンプルモードの動き

このモードでは、どの要素が重要で、どの要素が重要でないかを指定するだけで済みます。

When creating a new service you may select simple mode.

重要としてチェックされた要素のみが計算に考慮され、その要素の 障害 状態のみが値を持ちます。

  • 要素の 0~50% が 障害 状態の場合、サービスは、警告 状態になります。
  • 障害 状態の要素が 50% を 超えると、サービスは、障害 状態になります。

例:

  • ルータは 重要 要素です。
  • プリンタは、非重要 要素です。
  • Apache Web サーバは、重要 要素です。

状況 1:

  • ルータは、障害 状態。
  • プリンタは、障害 状態。
  • Apache サーバは、警告 状態。

結果: プリンタは重要ではなく、ルータは 重要 で、重要な要素は 50% のため、サービスは 警告 状態となります。Apache サーバは障害状態になく、評価に含まれません。

状況 2:

  • ルータは、障害 状態。
  • プリンタは、障害 状態。
  • Apache サーバは、障害 状態。

結果: サービスは、障害 状態となります。(プリンタは評価に含まれません)

状況 3:

  • ルータは、正常 状態。
  • プリンタは、障害 状態。
  • Apache サーバは、正常 状態。

結果: 重要な要素が障害状態にないため、サービスの状態は 正常 となります。(プリンタは評価に含まれません)

1.2.2 ウエイトに基づく動き

次のような問いかけに直面した場合、「抽象的な」ものとしてサービスを監視する必要が生じます。

重要でない要素に障害が発生した場合、アプリケーションはどうなるのか?

このような問題を解決するために、Pandora FMS には次のようなサービス監視機能があります。

  • 受信するアラートの数を制限します。提供するサービスの信頼性を損なう状況になった場合にアラートを受け取ります。
  • SLAコンプライアンスレベルを追跡します。
  • インフラストラクチャの監視表示を簡素化します。

これを実現するには、アプリケーションに悪影響を与える可能性のあるすべての要素を監視します。

Pandora FMS コンソールを使用して、アプリケーションに影響を与える要素とその影響度の両方を示す サービスツリー を定義します。

サービスツリーに追加されたすべての要素は、モジュール、特定のエージェント、またはその他のサービスの形式で、すでに監視されている情報に対応します。

各要素の状態が全体の状態にどの程度影響するかを示すために、重みを合計する システムが使用されます。これにより、重要度の低い要素(重みが少ない)よりも、最も重要な要素(重みが大きい)が全体の状態への影響度が高くなり、サービス全体が障害状態と判断します。

1.2.2.1

冗長要素によってバランスをとっている Web アプリケーションを監視したいとします。 アプリケーションの基盤となるインフラストラクチャは、次の要素で構成されます。

  • HA 構成の 2つのルータ
  • HA 構成の 2つのスイッチ
  • 20 の apache Web サーバ
  • 4つの Weblogic アプライアンスサーバ
  • 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ

私たちの目標は、Webアプリケーションが正しく機能しているかどうかを知ることです。つまり、顧客による最終的な評価は、アプリケーションが機能することです。

冗長化されている 20台の Apache サーバの 1つが障害の場合、すべての従業員に警告通知することは賢明でしょうか? アラートのルールは何でしょうか?

Pandora FMS は、重要な要素における問題(例えばルータ)や複数の Apache サーバが同時に障害の場合のみ警告を発するべきだと考えることができます。ただ、何台の場合でしょうか? これを解決するために、前述のコンポーネントにウエイトの値を割り当てる必要があります。

例を見てみましょう:

  • スイッチおよびルータ: 個々の障害状態の時は 5ポイント、警告状態の時は 3ポイント
  • ウェブサーバ: 個々の障害状態の場合は 1.2 ポイント、警告状態はポイント無し
  • WebLogic サーバ: 個々の障害状態の場合は 2ポイント
  • MySQL クラスタ: それぞれのノードに 5ポイント、警告状態で 3ポイント
要素のタイプ ウエイトの割り当て
正常 警告 障害 不明
ルータ0355
スイッチ0355
Web サーバ001.21.2
Weblogic サーバ0022
MySQL サーバ0355

サービスの警告しきい値を 4、障害しきい値を 6に設定します。このようにして、すべてが正しく設定できていれば、監視対象の要素すべてが正常であるか、またはサービス提供の不備を引き起こすほど重要でない場合、サービスは正常になります。

サービス設定
正常 警告 障害
0 >=4 >=6

1台の apache サーバダウンが発生した場合は次のようになります。

  • 1 x 障害状態の Apache サーバ x 1.2 ポイント = 1.2 となり、ここで、1.2 < 4 (警告) であるため、サービスの状態はまだ正常です。

ウエイトの計算は次のようになります。

2 x 0 (ルータ正常)
+ 2 x 0 (スイッチ正常)
+ 19 x 0 (apache 正常)
+ 1 x 1.2 (apache 障害)
+ 4 x 0 (weblogic 正常)
+ 1 x 0 (mysql 正常)
合計: 1.2 --> サービスは正常

Web サーバと Weblogic がダウンした場合どうなるかを見てみましょう。

  • 1 x 障害状態の Apache サーバ x 1.2ポイント = 1.2
  • 1 x 障害状態の Weblogic サーバ x 2 = 2

合計は 3.2 となり、まだ < 4 です。そのため、サービスの状態はまだ正常です。オペレータが起きる必要はありません。

ウエイトの計算は次のようになります。

2 x 0 (ルータ 正常)
+ 2 x 0 (スイッチ 正常)
+ 19 x 0 (apache 正常)
+ 1 x 1.2 (apache 障害)
+ 3 x 0 (weblogic 正常)
+ 1 x 2 (weblogic 障害)
+ 1 x 0 (mysql 正常)
合計: 3.2 --> サービスは正常

2台のウェブサーバと、1台の Weblogic サーバがダウンした場合を見てみましょう。

  • 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4
  • 1 x 障害状態の Weblogic サーバ x 2 = 2

合計が 4.4 > 4 となり、サービスが警告状態になります。サービスはまだ動き続け緊急の技術的な対応は必要ありませんが、インフラに問題が発生していることは明らかです。

2 x 0 (ルータ 正常)
+ 2 x 0 (スイッチ 正常)
+ 18 x 0 (apache 正常)
+ 2 x 1.2 (apache 障害)
+ 3 x 0 (weblogic 正常)
+ 1 x 2 (weblogic 障害)
+ 1 x 0 (mysql 正常)
合計: 4.4 --> サービスは警告状態

上記の状態に加え、1台のルータがダウンした場合を想定してみましょう。

  • 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4
  • 1 x 障害状態の Weblogic サーバ x 2 = 2
  • 1 x 障害状態のルータ x 5 = 5

合計ポイントは 9.4 となり、障害状態の閾値である 6 を越えています。サービスは障害状態となり、動作していません。 すぐに技術的な対処が必要です。

1 x 0 (ルータ 正常)
+ 1 x 5 (ルータ 障害)
+ 2 x 0 (スイッチ 正常)
+ 18 x 0 (apache 正常)
+ 2 x 1.2 (apache 障害)
+ 3 x 0 (weblogic 正常)
+ 1 x 2 (weblogic 障害)
+ 1 x 0 (mysql 正常)
合計: 9.4 --> サービスは障害状態

Pandora FMS は、対応チーム(オペレータ、技術者など)にアラートをあげます。

リンタのみ障害状態ですが、障害要素ではないのでサービスの状態計算には含まれません。

1.2.3 ルートサービス

Info.png

Enterprise 版
バージョン NG 726 以上

 


あるサービスの一部ではないサービスが評価されます。これは ルートサービス と呼ばれます。 この論理的な概念により、監視を高速化し、処理キューを最小限に抑えることができます。

さらに、これに基づき、Pandora FMS ノードで定義されたサービスがメタコンソールでのルートサービス要素として表示され、メタコンソールサーバがそれを評価し、ノードに保存されている値を更新します。

これにより、より効率的な分散ロジックが提供され、サービスに基づく関連障害検知抑制を行うことができます。これに関しては、[関連障害検知抑制] にて説明しています。

メタコンソールサービスの可能性も拡張され、他のサービス、モジュール、またはエージェントをサービス要素として追加できるようになりました。 以前のバージョンでは、ノードサービスのみを追加できました。

1.3 新たなサービスの作成

1.3.1 Pandora FMS サーバ

Template warning.png

サービスを利用するには、予測サーバ が有効化されている必要があります。

 


予測サーバ が起動しており、Pandora FMS Enterprise 版がインストールされていることが必要です。

1.3.2 概要

サービスは以下を表すことができます。

  • モジュール
  • エージェント
  • 他のサービス

サービスの値は、予想サーバを使って計算されます。

一度、すべてのデバイスを監視します。 各サービスには、サービスを監視するために必要なすべてのモジュール、エージェント、またはサブサービスを追加できます。 たとえば、オンラインストアサービスを監視する場合は、コンテンツのモジュール、通信の状態を監視するサービスなどが必要です。 以下の手順で、Pandora FMS を使用してサービスを作成する方法を確認できます。

新たなサービスを作成するには、トポロジマップサービス をクリックします。


Menu services.png


全サービスを含むツリー表示がされます。


Arbol servicios.png


1.3.3 初期設定

新たなサービスを作成するには、作成ボタンをクリックし、以下に示す画面に表示されるフォームに入力します。



Formulario servicios.png


フィールド名とその意味は以下の通りです。

名前(Name)
サービス名。
説明(Description)
サービスの説明。長いテキストも可能です。この説明は、サービスマップ、サービス一覧表示、およびサービスウィジェットに(名前の代わりに)表示されます。
グループ(Group)
サービスが属するグループ。ACL による制限をするのに便利です。
データ保存エージェント(Agent to store data)
サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。

Info.png

注意: すてべのサービスモジュールの計算間隔は、コンテナとしてのエージェントに設定された間隔に依存します。

 


モード(Mode)
要素のウエイトの計算モードです。2つの値があります。
    • スマート(Smart): サービスの一部であるウエイトと要素は、確立されたルールに基づいて自動的に計算されます。
    • 手動(Manual): サービスの一部であるウエイトと要素は、固定値で手動で設定されます。

Template warning.png

スマート モードは Pandora FMS バージョン 7.0NG 748 から利用できます。 以前のバージョンの 自動 および シンプル モードは、MR 40 のアップデートを適用することにより 手動 になります。

 


  • 障害(Critical): 障害状態のウエイト閾値です。スマート モードの場合は、この値はパーセンテージです。要素がこの値にどのように寄与するかについては後で説明します。
  • 警告(Warning): 警告状態のウエイト閾値です。スマート モードの場合は、この値はパーセンテージです。要素がこの値にどのように寄与するかについては後で説明します。
  • 障害としての不明要素(Unknown elements as critical): 不明状態の要素が障害状態の要素であるかのように重みを設定することができます。
  • お気に入り(Favourite): サービスをお気に入りに指定する設定です。サイドメニューに直接リンクが作成され、サービスのフィルタができます。


Servicios favoritos.png


  • 静観モード(Silent mode):サービスの静観モードを有効化します。アラートやイベントを生成しません。
  • 関連障害検知抑制(Cascade Protection enabled):サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。
  • 連続SLAを計算する(Calculate continuous SLA): 現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。このオプションが無効化されている場合、サービスが作成されると、モジュールの履歴データは削除され情報が失われます。
  • SLA 間隔(SLA Interval): サービスにおける有効なSLAを計算する期間。
  • SLA 制限(SLA limit): 前述のフィールドで設定した時間間隔で SLA を満たすと判断するサービスの正常状態閾値です。
  • 警告サービスアラート(Service alert in warning status): サービスが警告状態になった場合に利用するアラートテンプレートです。
  • 障害サービスアラート(Service alert in critical status): サービスが障害状態になった場合に利用するアラートテンプレートです。
  • 不明サービスアラート(Service alert in unknown status): サービスが不明状態になった場合に利用するアラートテンプレートです。
  • SLA 障害アラート(SLA critical alert): SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。

1.3.4 要素設定

フィールドを正しく入力したら、以下のように、要素またはサービス項目で埋める必要がある空のサービスがあります。サービス編集フォームで、'要素設定(Config Elements)' タブを選択します。


Elementos servicios.png


要素追加ボタンをクリックすると、フォームを含むポップアップウィンドウが表示されます。 サービスがスマートモードまたは手動モードの場合で、フォームは少し異なります。


Formulario elementos servicios.png


フォームのフィールドは次の通りです。

  • 説明(Description): サービスマップ上の要素を表すために使用されるオプションのテキスト。設定されていない場合は、モジュール、エージェント、またはサービスの名前(追加された要素に応じて)が使用されます。
  • タイプ(Type): 要素がサービス、モジュール、またはエージェントのいずれであるかを選択するためのドロップダウンリスト。 スマートモードのサービスでは、動的タイプを選択することもできます。
  • エージェント(Agent): エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
  • モジュール(Module): 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
  • サービス(Service): アイテムを作成するためのサービス一覧のドロップダウンリストです。アイテム作成またはサービスタイプ編集の場合のみ表示されます。ドロップダウンリストに表示されるサービスは、すべてが依存サービスではないことに注意する必要があります。サービス間の依存関係はツリー表示で見る必要があります。

1.3.4.1 手動モード

以下フィールドは手動モードのサービスにのみ存在します。

  • 障害(Critical): 要素が障害状態のときにサービスに追加されるウエイト。
  • 警告(Warning): 要素が警告状態のときにサービスに追加されるウエイト。
  • 不明(Unknown): 要素が不明状態のときにサービスに追加されるウエイト。
  • 正常(Normal): 要素が正常状態のときにサービスに追加されるウエイト。

サービスの状態を計算するために、各要素のウエイトがその状態に基づいて追加され、それが警告または障害のサービスにおけるしきい値を超える場合、サービスの状態は適切に警告または障害に変更されます。

1.3.4.2 スマートモード

スマートモードサービスでは、要素に重みが定義されていないため、要素の状態計算は次のように行われます。

  • 障害状態の要素は、完全にサービスの重みの割合となります。 これは、たとえば、サービスに 4つの要素があり、そのうちの 1つだけが障害である場合、その要素はサービスの重みとして 25% になることを意味します。 要素が 4つではなく 5つであった場合、障害要素はサービスの重みとして 20% です。
  • 警告状態の要素は、その割合の半分がサービスの重みとなります。 これは、たとえば、サービスに 4つの要素があり、そのうちの 1つだけが警告状態にある場合、その要素はサービスの重みとして 12.5% になることを意味します。 要素が 4つではなく 5つであった場合、警告要素はサービスの重みとして10% です。
1.3.4.2.1 動的モード
Topology maps-services-edit service elements-add element-01.png

次のフィールドはスマートモードでの動的タイプの要素でのみ存在します。

マッチする要素のタイプ(Matching object types)
動的ルールが評価され、サービスの一部となる要素がエージェントまたはモジュールかどうかを選択するドロップダウンリスト。
グループによるフィルタ(Filter by group)
要素がサービスの一部である必要があるグループを示すルール。
エージェント名に利用(Having agent name)
サービスの一部となる要素でエージェントの名前を示すルール。指定のエージェントの名前の一部となるテキストが表示されます。
モジュール名に利用(Having module name)
サービスの一部となる要素でモジュールの名前を示すルール。指定のモジュールの名前の一部となるテキストが表示されます。
Topology maps-services-edit service elements-add element-02.png
正規表現セレクタの利用(Use regular expresions selector)
このオプションを有効化すると、検索の仕組みとして 正規表現 (regex または regexp) が利用されます。ただし、MySQL での扱い に従います。
カスタムフィールド名に利用(Having custom field name)
サービスの一部となる要素でカスタムフィールドの名前を示すルール。指定のカスタムフィールドの名前の一部となるテキストが表示されます。
カスタムフィールドの値に利用(Having custom field value): サービスの一部となる要素でカスタムフィールドの値を示すルール。指定のカスタムフィールドの値の一部となるテキストが表示されます。
Topology maps-services-edit service elements-add element-03.png

Info.png

カスタムフィールドで検索するときに考慮されるように、両方のフィールドにテキストを入力する必要があります。

 


Topology maps-services-edit service elements-add element-04.png

Info.png

バージョン NG 752 以降では、より多くのカスタムフィールドに検索を追加することが可能です。これらは、設定されたキーワードペアのいずれかに一致する場合に選択されます。

 


Topology maps-services-edit service elements-add element-07.png
グループ Servers 内のエージェントをフィルタリングすることを選択した場合、そのエージェント名は Firewall を含み、モジュール名は Network含みます。 以下の結果が得られます。
Topology maps-services-edit service elements-add element-06.png
動的要素の設定が次の場合
Topology maps-services-edit service elements-add element-05.png

名前に "Host Alive" が含まれるすべてのモジュールで、名前に "SW" が含まれるエージェント、"Servers" グループ内にあり、カスタムフィールドに "Department" が含まれる名前のもので値に "Systems" を含むものが、サービス要素として使用されます。

Template warning.png

動的要素は、関連障害検知抑制の影響を受けません。

 


1.3.5 サービス設定時に作成されるモジュール

  • SLA Value Service: SLA を満たすパーセンテージです。(async_data)
  • Service_SLA_Service: これは、SLA を満たしているかどうかを表示します。(async_proc)
  • Service_Service: このモジュールはサービスのウエイトの合計を表示します。(async_data)

1.4 サービス表示

1.4.1 全サービスの一覧表示

作成した全サービスを表示する一覧です。もちろん、Pandora コンソールを使用しているユーザがアクセスできるグループのみを表示します。

この画面へ行くには、操作メニューで監視のサービスを開きます。

Services list services admin v5.png

それぞれの行がサービスで、カラムは次の通りです。

  • 名前(Name): サービス名。
  • 説明(Description): サービスの説明。
  • グループ(Group): サービスが所属するグループのアイコン。
  • 障害(Critical): サービスが障害状態になるウエイトの合計の閾値。
  • 警告(Warning): サービスが警告状態になるウエイトの合計の閾値。
  • 値(Value): サービスのウエイトの合計値。
  • 状態(Status): サービスの状態を表現するアイコン。以下の 4種類があります。
    • : 障害閾値を超え、サービスが障害状態にある場合。
    • 黄色: 警告閾値を超え、サービスが警告状態にある場合。
    • : サービスが正常状態の場合。
    • グレー: サービスが不明状態の場合。これは、サービスが作成されたばかりでモジュールを含んでない場合または、予測サーバがダウンしている場合です。
  • SLA: サービス SLA の現在の値。とりうる値は次の通りです。
    • OK: SLA サービスで定義された間隔で SLA の条件に適合している場合。
    • INCORRECTO: SLA サービスで定義された間隔で SLA の条件に適合していない場合。
    • N/A: 計算のための十分なデータが無く、SLA が不明状態の場合。

1.4.1.1 全サービスの表

全サービスとその状態を表で表示します。


Servs.JPG


1.4.1.2 サービスとその要素の一覧表示

全サービスの一覧でサービス名をクリックするかまたは、サービスタイトルヘッダーの虫眼鏡アイコンをクリックすることにより参照することができます。

Pandora は、次のようなスクリーンショットの画面を表示します。

Services list elements operation v5.png

2つのパートに分かれており、上に前述の表示と同じカラム、下にサービスを構成する要素の一覧です。

要素の一覧は表形式で表示されます。行は各要素に対応し、列は以下を表します。

  • タイプ(Type): 要素のタイプを表すアイコン。モジュールを表すレゴブロック、エージェントを表す積み重なったレゴブロック、サービスのネットワークダイアグラムアイコンです。
  • 名前(Name): モジュール / エージェント / サービスの名前を含んだテキストです。それぞれのセクションへのリンクもあります。
  • 説明(Description): 説明のテキストです。
  • 障害ウエイト(Weight critical): 要素が障害状態の合計値です。
  • 警告ウエイト(Weight warning): 要素が警告状態の合計値です。
  • 正常ウエイト(Weight normal): 要素が正常状態の合計値です。
  • データ(Data): エレメントの値で、次のいずれかです。
    • モジュール(Module) モジュールの値。
    • エージェント(Agents) エージェントの状態を表すテキスト。
    • サービス(Service) 親サービスの要素として選択したサービスの要素の全ウエイトの合計。
  • 状態(Status) 要素の状態を色とともに表すアイコン。

Template warning.png

サービス要素の計算は、予測サーバによって実施されることに注意してください。リアルタイムのデータではありません。また、サービスにエージェントが追加された場合、サービスのウエイトは、計算が再実行されるまで更新されないことに注意してください。

 


1.4.1.3 サービスマップ表示

ここでは、次の画面のようにサービスをツリー構造で表示します。これにより、どのようなモジュール、エージェント、サブサービスがサービスに影響を与えるのかを見ることができます。サブサービスにおいても、ステータスをウェイトの合計で計算し、何がサブサービスに影響を与えるのかを確認できます。

Services servicemap v5.png

ノードの種類は次の通りです。

  • モジュールノード(Module node) ハートビートアイコンで表示されます。このノードは常に末端です。
  • エージェントノード(Agent node) CPU ボックスアイコンで表示されます。このモジュールは常に末端です。
  • サービスノード(Service node) ハンマーとスパナアイコンで表示されます。他のノードを含む必要があります。

ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。常に、緑が正常、赤が障害、黄色が警告、グレーが不明状態です。

ノード内は次の通りです。

  • タイトル(Title) サービス / エージェント / モジュールノードの名前。
  • 値一覧(Value list)
    • 障害(Critical): 障害状態になるウエイトの合計です。ルートサービスノードの場合は、障害状態になる閾値を表します。
    • 警告(Warning): 警告状態になるウエイトの合計です。ルートサービスノードの場合は、警告状態になる閾値を表します。
    • 正常(Normal): 正常状態になるウエイトの合計です。ルートサービスノードの場合は何も表示しません。
    • 不明(Unknown): 不明状態。ルートサービスノードの場合は、不明状態になる閾値を表します。

ツリー内の各ノードはクリックすることができ、ノードの操作画面へのリンクになっています。

Info.png

サービスのモードがシンプルの場合、赤い ! マークが障害要素の右に表示されます。

 


1.4.1.4 ビジュアルコンソールでのサービス

Pandora FMS バージョン 5 以降では、マップ内の他のアイテムのように、ビジュアルコンソールにサービスを追加することができます。



Servicios1.JPG


マップ上にサービスアイテムを作成するには、ビジュアルマップの他のアイテムと同じように操作します。ただし、オプション画面は、スクリーンショットのようになります。



Servicios2.JPG


次の設定があります。

  • ラベル(Label): ビジュアルコンソールノードに表示するタイトル。
  • サービス(Service): ドロップダウンリストから選択するマップに追加するサービス。

ビジュアルマップ上の他のアイテムとは異なり、サービスアイテムは他のビジュアルマップにリンクすることはできないことに注意してください。ビジュアルコンソール内のサービスアイテムをクリックすると、常に前述のツリーサービスマップ表示になります。

1.4.2 サービスツリー表示

この表示は、ツリー形式でサービスを表示します。

各レベルで、各サービスまたはエージェントに含まれる要素数のカウントが表示されます。

  • サービス: そのサービスに属するサービス、エージェント、およびモジュールの総数を報告します。
  • エージェント: 障害状態(赤色)、警告(黄色)、不明(灰色)、未初期化(青色)、および正常状態(緑色)のモジュール数を報告します。

他のサービスに属さないサービスは常に一番上のレベルに表示されます。 子サービスの場合は、親の中にネストされて表示されます。

Services treeview.png

Template warning.png

ACL によるアクセス制御は、一番上のレベルにのみ適用されます。

 




1.5 サービスの値の読み方

計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。

あとから設定した計画停止に基づいて変更されないレポートレベル、サービスマップ、ビジュアルコンソールでの表示情報は注目に値します。これらのサービス提供状況のパーセンテージは、同じサービスの過去のデータをもとにリアルタイムで計算されます。ダミーの計画停止を設定した場合と比べてレポートは大きく異なります。

一方で、サービスの順守状況の計算方法を知ることも重要です。

シンプルモードにおけるウエイトの計算

シンプルモードでは、通常のウエイトとは別に、障害ウエイトと 2つの状態のみがあるため、ウエイトの扱いが少し異なります。 各要素は、障害の場合は 1、その他の状態の場合は 0 のウエイトとなり、サービス要素に変化があるたびに、サービスのウエイトが再計算されます。 警告のウエイトは無視できます。 値が 0 の場合、サービスは少なくとも常に警告状態になるため、値は常に 0.5 になりますが、シンプルモードでは警告のウエイトは使用されません。 障害ウエイトは、障害要素の合計の半分になるように計算されます。これは 1 となります。3 つの要素がある場合、サービスの障害ウエイトは 1.5 であり、その後、サーバは、サービスが障害または警告状態であるかどうかをチェックします。

重要度に応じたウエイトの計算

1時間 (実際の場合ではとても短いですが内部アルゴリズムを理解するには良いです) で 95% の稼働率として定義したサービスがあると仮定します。値を表示にして、t が時間、x が(SLAの)パーセンテージ、そして s がサービスが維持できているかどうか(1:正常,0:異常)です。1時間のうちに、5分間隔で 12個の値を取得します。

この場合、最初の 11サンプル(最初の 55分)ではサービスを満たしており、60分のときに満たせずに次のようになったとします。

   t    |   s   |    x  
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          1      100
7          1      100
8          1      100
9          1      100
10         1      100
11         1      100
12         0      91,6

この場合は計算は簡単です。パーセンテージはサンプル数に依存して計算されます。たとえば、t 3 ではサービスを満たすトータル 3つのサンプルがあり 100% です。t 12 では、12 サンプル中満たしているのが 11 なので、11 / 12 です。

途中で問題が発生したと仮定すると、ゆっくり復旧します。

   t    |   s   |    x  
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          0      83,3
7          1      85,7
8          1      87,5
9          1      88,8
10         1      90 
11         1      90,9
12         1      91,6

これまでのシナリオに似ていますが、その後時間が進んでいくとどうなるか見てみましょう。

   t    |   s   |    x  
--------+-------+--------
13        1      91,6
14        1      91,6
15        1      91,6
16        1      91,6
17        1      91,6
18        1      100
19        1      100
....

直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。

1.6 サービス関連障害検知抑制

Info.png

Enterprise 版
バージョン NG 725 以上

 


サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。

'サービ関連障害検知抑制' 機能が有効な場合、ルートサービス用に設定されたテンプレートにリンクされたアクションが実行されます。 サービス内で不正な状態となっている要素を報告します。

このシステムでは、サービスの全体の状態が正常の場合でも、サービス内の要素が障害状態になったときにそのアラートを発報できるということを考慮することが必要です。

サービス関連障害検知抑制は、定義されたサービスの深さに関係なく、どの要素が障害なのかを示します。

Service2test.png

上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。

1.7 根本原因分析

サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。

これを利用するには、サービスにリンクしたテンプレートに以下のテキストを追加します。

Alert body: Example message
The series of events that have caused the service status is the following one:
_rca_

これは、次のような出力を返します。

Alert body: Example message
The series of events that have caused the service status is the following one:
[Web Application -> HW -> Apache server 3]
[Web Application -> HW -> Apache server 4]
[Web Application -> HW -> Apache server 10]
[Web Application -> DB Instances -> MySQL_base_1]
[Web Application -> DB Instances -> MySQL_base_5]
[Web Application -> Balanceadores -> 192.168.10.139]

この出力結果を見ることにより、以下を想定できます。

  • Apache サーバ 3,4 および 10 が障害状態
  • MySQL_base データベース 1 および 5 が停止
  • ロードバランサー 192.168.10.139 が応答していない

この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。

1.8 サービスグループ

サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。

サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。

サービスグループをより理解するためには、以降の例を確認してください。

1.9 サービス監視の例

1.9.1 PandoraFMS サービス

Apache および MySQL サービスによって作成された Pandora FMS 監視サービス、および Pandora FMS サーバと Tentacle の状態がそれぞれの重みで監視されるユースケースです。

Click to zoom in

これらの各要素は、同時に異なるコンポーネントを備えたサービスであり、サービスを通じてツリー状の構造をグループ化して作成します。

Click to zoom in

この場合、Pandora FMS のサービスは、ウエイトが 2になると障害状態になり、1 であれば警告状態になります。 ご覧のとおり、4つのコンポーネントが Pandora サービスで異なるウエイトを持っています。

  • MySQL: Pandora サービスにとってクリティカルで、MySQL がダウンしたらウエイトは 2です。警告状態の場合は、ウエイトは 1で、Pandora サービスで黄色の状態表示となります。
  • Pandora Server: Pandora サービスにとってクリティカルで、Pandora サーバがダウンしたらウエイトは 2 です。警告状態の場合のウエイトは 1 で、たとえば CPU のロードが上がった場合に Pandora サービスが警告状態を表示します。
  • Apache: Pandora サービス全体としてはデグレード状態で、完全に止まっているわけではありません。ダウンした場合のウエイトは 1 で、Pandora サービスは警告状態になります。
  • Tentacle: Apache の場合と同じで、Pandora サービス全体としてはデグレード状態で、完全に止まっているわけではありません。ダウンした場合のウエイトは 1 で、警告状態となります。

1.9.2 ストレージクラスタ、サービスのグルーピング

サービスは、企業のビジネス構造の一部を論理的なグループで表現したものです。そのため、サービスのグループを正しく作成する必要があるでしょう。なぜなら、サービス単体では適切な内容を持たないことがあるからです。サービスグループを作成するには、それぞれのサービスを既存のエージェントに追加する必要があります。この場合、サービスはエージェントのモジュールになります。新たな論理的な構造(サービスのグループ)を、これらのグループごとに作成することができます。

次の例では、HA ストレージクラスタがあります。この場合、2つのファイルサーバシステムが並行して稼働しており、それぞれが特定の部署にサービスを提供するために、いくつかの異なるディスクを制御しています。グループ化したサービスでツリー構造を作ります。

Cluster.JPG

この構造では、ストレージサービスが障害状態になるのは、双方のファイルサーバが障害になったときのみです。これはサービス全体が提供できません。もし一方のファイルサーバが障害の場合は、サービスとしてはデグレードという想定です。 以下の画面では、ストレージサービスの 2つのメインの要素のウエイト設定が見られます。

Pesoscluster.JPG

以下の画面では、グループ化したサービス FS01 のウエイト設定を見ることができます。ここでは、要素の状態に応じた特定のウエイトが設定されています。

  • FS01 ALIVE: FS01 サービスの障害ポイントです。1つ目のディスククラスタに割り当てられた仮想 IP です。ダウンした場合のウエイトは 2 で、他の要素は機能しなくなります。この場合、警告の閾値はなく、情報としては OK か NG かです。
  • DHCPserver ping: FS01 サービスの障害ポイントです。ウエイトは 2 を指定しています。これには、警告の閾値はありません。
  • Disks 障害状態の場合のウエイトは 1 で、警告状態では 0.5 です。これにより、2つのディスクが障害状態となった場合または 4つのディスクが警告状態になった場合に、FS01 サービスが障害状態になります。
Pesosfs01.JPG