サービス監視

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

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

Pandora FMS サービスは、ホスト、ルーター、スイッチ、ファイアウォール、Web サイト、さらには他のサービス を含む論理グループです。 たとえば、会社の公式 Web サイト、顧客関係管理 (CRM)、サポートアプリケーション、さらには会社や家庭にあるすべてのプリンターなどです。

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

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

このモードでは、どの要素が重要で、どの要素が重要でないかを指定するだけで済みます。操作(Operation) → トポロジーマップ(Topology maps) → サービス(Services) → サービスツリー表示(Service tree view) → サービスの作成(Create service) にアクセスします。

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

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

サービスツリー は、アプリケーションに影響を与える要素とその影響の度合いの両方を示すように定義する必要があります。

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

各要素の状態が全体的な状態に影響を与える度合いを示すために、重みを合計 する仕組が使用されます。これにより、最も重要なもの (より重みが大きい) が、重要性の低い要素 (重みが小さい) よりも、サービス全体の状態に影響します。

冗長要素によってバランスをとっている 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ポイント

サービスの警告しきい値を 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 は、対応チーム(オペレータ、技術者など)にアラートをあげます。

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

ルートサービスは、別のサービスの一部ではないサービスです。 これにより、より効率的な分散ロジックが提供され、サービスに基づく関連障害検知抑制 システムを利用できます。

メタコンソールのサービスでは、他のサービス、モジュール、エージェントをサービスの要素として追加できます。

全体的かつ単純化された方法の予測サーバは、ルートサービスのすべてのコンポーネントの状態を取得するために、上から下まで階層的な計算チェーンに従います。 数十または数百のコンポーネントから成るサービスとって満足のいくソリューションです。

サービスを非同期としてマークすることにより、そのサービスは別のサービスの一部であっても独自の間隔で個別に評価されます。これは、ルートサービスからたどって評価されるデフォルトの同期処理の例外です。非同期サービスは、親サービス (ルートサービス) の一部であっても、強制的に独立して実行できます。

別のサービス(サブサービス)の一部であるサービスがルートサービスの評価時に非同期としてマークされている場合、非同期サービスのステータスの計算は実行されませんが、前回実行したルートサービスで最後に保存された値が有効と見なされます。この設定は、大規模なサービスの要素を評価してパフォーマンスを向上させたり、ルートサービスの要素であるサービスに実行の優先順位を与えたりするのに非常に役立ちます。

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

すべてのデバイスを監視したら、各サービス内に、サービスの監視に必要なすべてのモジュール、エージェント、またはサブサービスを追加します。 新しいサービスを作成するには、操作(Operation) → トポロジマップ(Topology maps) → サービス(Services) → サービスツリー表示(Service tree view) → サービスの作成(Create service) にアクセスします。

• データ保存エージェント(Agent to store data): サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。
• モード(Mode):
  • スマート(Smart): サービスの一部であるウエイトと要素は、確立されたルールに基づいて自動的に計算されます。
  • 手動(Manual): サービスの一部であるウエイトと要素は、固定値で手動で設定されます。
• 障害(Critical): サービスを障害状態とする重みのしきい値。 スマート モードでは、この値はパーセントになります。
• 警告(Warning): サービスを警告状態とする重みのしきい値。 スマート モードでは、この値はパーセントになります。
• 障害としての不明要素(Unknown elements as critical): 不明状態の要素が障害状態の要素であるかのように重みを設定することができます。
• 非同期モード(Asynchronous mode): デフォルトでは、それぞれのコンポーネントの状態計算は同期で実行されます。このオプションを有効化すると、従属コンポーネントの計算は、非同期で実行されます。
• 関連障害検知抑制(Cascade Protection enabled): サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。
• 連続SLAを計算する(Calculate continuous SLA): 現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。
• SLA 間隔(SLA Interval): サービスにおける有効なSLAを計算する期間。

空のサービスが作成されたら、サービス編集フォームにアクセスし、要素設定(Configuration elements) タブを選択します。 要素の追加(Add element) ボタンをクリックすると、フォームを含むポップアップ ウィンドウが表示されます。 サービスが スマート(smart) モードか 手動(manual) モードかでフォームは若干異なります。 タイプ(Type) では、モジュール、エージェント、サービス、または動的かを選択する必要があります。

サービスの状態の計算では、その状態に基づいて各要素の重みが追加されます。サービス内で設定された警告または障害のしきい値を超えた場合、サービスの状態は必要に応じて警告または障害になります。

The following fields will only be available for services in manual mode:

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

• 障害(Critical)
• 警告(Warning)
• 不明(Unknown)
• 正常(Normal)

スマートモードサービスでは、状態は次のように計算されます。

• 障害状態の要素は、全体の割合がサービスの重みの割合となります。 これは、たとえば、サービスに 4つの要素があり、そのうちの 1つだけが障害である場合、その要素はサービスの重みとして 25% になることを意味します。 要素が 4つではなく 5つであった場合、障害要素はサービスの重みとして 20% です。
• 警告状態の要素は、その割合の半分がサービスの重みとなります。 これは、たとえば、サービスに 4つの要素があり、そのうちの 1つだけが警告状態にある場合、その要素はサービスの重みとして 12.5% になることを意味します。 要素が 4つではなく 5つであった場合、警告要素はサービスの重みとして10% です。

動的モード

次のフィールドは、動的 タイプ (スマート モードのサービス) の要素にのみ存在します。

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

右上のタブでは、サービスを作成または編集するときに、項目を追加するためのウィザードが次のオプションとともに表示されます。

• アイテム追加(Add items): 要素(エージェント、モジュール、サービス)を追加します。
• アイテム編集(Edit items): 要素の編集。
• アイテム削除(Delete items): 要素の削除。

要素を追加する場合、ウィザードの 追加する項目タイプ(Item type to be added) にドロップダウンリストが表示され、デフォルトではサービスにエージェントを追加するオプションが表示されます。 ここで、横の エージェント(Agents) をクリックする必要があります。利用可能なエージェントが名前で表示されます。 その要素を(自由検索で)入力することもでき、名前で一致するエージェントが自動的に表示されます。 エージェントの一覧が長い場合は、グループ(Group) という名前のドロップダウンリスト内のグループでフィルタリングできます。

モジュールとサービスの場合も選択処理は同様ですが、モジュールの場合は要素を自由に検索できない点が異なります。

いずれの場合も、1 つ以上の要素を選択して、選択した要素を追加(Add selected) ボタンを押す必要があります。 以下の サービス項目の概要(Service items summary) には、サービスに追加されたエージェント、モジュール、サービスの概要が表示されます。

サービス項目の概要(Service items summary)で必要な要素を選択したら、要素の追加(Add elements) をクリックして、編集中のサービスに新しいコンポーネントを追加して保存します。

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

作成した全サービスを表示する一覧です。Pandora FMS コンソールを使用しているユーザがアクセスできるグループのみを表示します。この画面へ行くには、操作(Operationi) → トポロジマップ(Topology map) → サービスツリー表示(Service tree view) クリックし、サービス一覧(List of services) に行きます。

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

要素を追加するには、エージェント、モジュール、またはその他のサービスを選択できるダイアログボックスがあり、下部にあるそれぞれのサービスをクリックし、選択可能な要素が表示されたら、選択項目を追加(Add selected) を行います。 要素の追加が完了したら、要素の追加(Add elements) ボタンをクリックして変更を保存します。 編集と削除の場合も同様です。

この表示は、ツリー形式でサービスを表示します。操作(Operation) → トポロジマップ(Topology maps) → サービス(Services) → サービスツリー表示(Service tree view) からアクセスできます。

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

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

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

障害 の重みは、要素の障害の重みの合計の半分、つまり 1 になるように計算されます。要素が 3 つある場合、サービスの障害の重みは 1.5 となり、サーバが障害の重みを超えているか、サービスを 障害 または 警告 状態に移行するかを決定します。

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

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

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

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

サービス状態の根本原因を示す _rca_ というマクロが利用可能です。 これを使用するには、サービスに関連付けられているテンプレートに追加します。 このマクロは、次のような出力を返します。

[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 → Balancers → 192.168.10.139]

この例は次のような内容を示しています。

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

このような情報によりサービスの問題原因をデバッグできるため、調査タスクを軽減することができます。

サービスは、組織のビジネス構造の一部を構成する論理的なグループです。 このため、多くの場合、相互に依存関係が存在する可能性があるため、サービスをグループ化することにはある程度の意味がある場合があります。たとえば、一般的なサービス (会社) を複数のより具体的なサービス (企業 Web サイト、通信など) で構成するなどです。

サービスをグループ化するには、一般的な上位サービスと、それに追加される下位サービスの両方を作成し、論理的なツリー構造を構築する必要があります。

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