サービスモニタリング

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

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

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

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

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

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

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

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

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

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

例:

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

状況 1:

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

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

状況 2:

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

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

状況 3:

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

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

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

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

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

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

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

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

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

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

冗長要素によってバランスをとっている 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 は、対応チーム(オペレータ、技術者など)にアラートをあげます。

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

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

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

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

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

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

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

非同期サービスは、親サービス(ルートサービス)の一部であっても、強制的に独立して実行することができます。

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

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

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

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

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

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

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

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

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

名前(Name)

サービスを特定する名前です。ランダム(Random)ボタンをクリックすることによりランダムな名前を割り当てます。

説明(Description)

サービスの説明。長いテキストも可能です。この説明は、サービスマップ、サービス一覧表示、およびサービスウィジェットに(名前の代わりに)表示されます。

グループ(Group)

サービスが属するグループ。ACL による制限をするのに便利です。

データ保存エージェント(Agent to store data)

サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。

モード(Mode)

要素のウエイトの計算モードです。2つの値があります。

• スマート(Smart): サービスの一部であるウエイトと要素は、確立されたルールに基づいて自動的に計算されます。
• 手動(Manual): サービスの一部であるウエイトと要素は、固定値で手動で設定されます。
• 障害(Critical): 障害状態のウエイト閾値です。スマート モードの場合は、この値はパーセンテージです。要素がこの値にどのように寄与するかについては後で説明します。
• 警告(Warning): 警告状態のウエイト閾値です。スマート モードの場合は、この値はパーセンテージです。要素がこの値にどのように寄与するかについては後で説明します。
• 障害としての不明要素(Unknown elements as critical): 不明状態の要素が障害状態の要素であるかのように重みを設定することができます。

これにより、不明状態にある要素が重要な要素であるかのように重みに寄与させることができます。

お気に入り(Favourite)

サービスをお気に入りに指定する設定です。サイドメニューに直接リンクが作成され、サービスのフィルタができます。

静観(Quiet)

サービスの静観モードを有効化します。アラートやイベントを生成しません。

非同期モード(Asynchronous mode)

デフォルトでは、それぞれのコンポーネントの状態計算は同期で実行されます。このオプションを有効化すると、従属コンポーネントの計算は、非同期で実行されます。

関連障害検知抑制(Cascade Protection enabled)

サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。

サンバーストの有効化(Enable Sunburst)

中心点から放射状に分岐する表示を有効にすることができます。例：

次のアイコンをクリックすることによりツリー表示ができます。

放射状の表示に戻すには:

連続SLAを計算する(Calculate continuous SLA)

現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。

SLA 間隔(SLA Interval)

サービスにおける有効なSLAを計算する期間。

SLA 制限(SLA limit)

前述のフィールドで設定した時間間隔で SLA を満たすと判断するサービスの正常状態閾値です。

アラート(Alerts)

このセクションでは、サービスが警告、障害、不明のステータスになったとき、またはサービス SLA が満たされていないときに、サービスがアラートを発報するためのテンプレートを選択します。

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

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

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

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

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

• 障害(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)

このオプションを有効化すると、検索の仕組みとして 正規表現 (regex または regexp) が利用されます。ただし、MySQL での扱い に従います。

カスタムフィールド名に利用(Having custom field name)

サービスの一部となる要素でカスタムフィールドの名前を示すルール。指定のカスタムフィールドの名前の一部となるテキストが表示されます。

カスタムフィールドの値に利用(Having custom field value): サービスの一部となる要素でカスタムフィールドの値を示すルール。指定のカスタムフィールドの値の一部となるテキストが表示されます。

例

グループ Servers 内のエージェントをフィルタリングすることを選択した場合、そのエージェント名は Firewall を含み、モジュール名は Network を含み ます。 以下の結果が得られます。

例

動的要素の設定が次の場合

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

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

作成した全サービスを表示する一覧です。もちろん、Pandora コンソールを使用しているユーザがアクセスできるグループのみを表示します。この画面へ行くには、操作(Operationi) > モニタリング(Monitoring) へ行き、サービス(Services) をクリックします。

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

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

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

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

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

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

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

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

サービスのシンプルな一覧には、サービスの要素の一括での追加、編集、削除の 3 つのオプションのドロップダウンアイコンがあります。

• 追加:

• 編集:

• 削除:

要素を追加するには、エージェント、モジュール、またはその他のサービスを選択できるダイアログボックスがあり、下部にある各サービスをクリックすることにより、選択して追加できる要素が表示され、次の 選択したものを追加(Add selected) オプションで追加できます。

要素の追加が完了したら、要素の追加(Add elements) ボタンをクリックして変更を保存します。 編集と削除も同様です。

サービスに適用される同様の操作については、「一括操作: サービス」も参照してください。

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

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

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

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

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

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

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

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

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

次の設定があります。

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

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

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

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

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

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

計画停止をあとから追加することにより、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つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。

サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、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 が応答していない

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

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

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

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

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

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

この場合、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 で、警告状態となります。

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

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

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

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

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

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