Pandora:Documentation ja:Services

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

1 サービスモニタリング

1.1 概要

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

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

Pandora FMS では、監視要素(モジュール、エージェント、その他サービス)のグルーピングとしてサービスを表現します。それぞれの個々の状態が、特定の方法でサービス全体が機能しているかの判断に影響を与えます。

1.2 Pandora FMS におけるサービス

1.2.1 Pandora FMS でのサービスの動作

Pandora FMS における基本的な監視は、異なる対象からの情報を収集することから成っています。それらを監視項目(モジュール)と呼びます。

サービスの監視により、これらのモジュールをグループ化することができます。その結果、障害の蓄積に基づいて一定のマージンを持ちながら、大規模かつ一般的なサービスにおけるさまざまな種類の要素のグループとそれらの関係を監視できます。

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

サービス監視をより理解しやすいように、小さな例をみていきます。

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

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

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

次の質問に直面したときに、"抽象的な" ものとしてサービスを監視する必要性が発生します。

クリティカルではない要素で障害が発生したときに、アプリケーションでは何が発生しているのでしょうか?

たとえば、20台の Apache サーバのうちの 1台がクラッシュしたとします。 理論的には、冗長構成になっているため警告は通知できませんでした。しかし、この時何に関して警告すべきだったのでしょうか？ すべて？ ほんの一部？ 警告のルールは何でしょうか？

Pandora は、クリティカルな部分の問題(例えばルータ)や複数の Aapache サーバの障害の場合のみ警告を発するべきだと考えることができます。

Pandora FMS のサービス監視機能はこれらすべてを解決します。

Pandora FMS のサービスは以下の手助けをします。

• 受け取るアラートの制限。提供するサービスの信頼性を損なう状況でのアラートを受け取り。
• コンプライアンスレベルの確認
• インフラ監視の簡単なビジュアル表示

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

Pandora FMS コンソールを通して、私たちはアプリケーションに影響を与える要素とそれが影響を与える度合の両方を指定する サービスツリー を定義する必要があります。

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

それぞれの要素の状態が全体の状態にどの程度影響を与えるかを示すために、ウエイトの合計 が利用されます。最重要(ウエイトが高い)な要素は、サービス全体の状態に与える影響が重要度が低い(ウエイトが低い)要素より高くなります。

例を見てみましょう:

• スイッチおよびルータ: 個々の障害状態の時は 5ポイント、警告状態の時は 3ポイント
• ウェブサーバ: 個々の障害状態の場合は 1.2 ポイント、警告状態はポイント無し
• WebLogic サーバ: 個々の障害状態の場合は 2ポイント
• MySQL クラスタ: それぞれのノードに 5ポイント、警告状態で 3ポイント

要素のタイプ	ウエイトの割り当て
	正常	警告	障害	不明
ルータ	0	3	5	5
スイッチ	0	3	5	5
Web サーバ	0	0	1.2	1.2
Weblogic サーバ	0	0	2	2
MySQL サーバ	0	3	5	5

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

サービスモニタリングは、エンタープライズ版の Pandora FMS のみにある機能です。

1.2.1.1 シンプルモードの動作

監視要件が基本的な内容の場合、ウエイトシステムは複雑すぎるかもしれません。このような状況に対応するために、サービス設定にシンプルモードがあります。

このモードでは、どの要素が障害で、どの要素が障害でないかを設定するだけです。

障害としてチェックされた要素のみが計算に用いられ、障害 状態の要素のみが実際の値を持ちます。

• 障害要素のうち、障害 状態のものが 0 から 50% の間の割合であれば、警告 状態となります。
• 障害要素のうち、障害 状態のものが 50% を超えると、障害 状態となります。

シンプルサービスの例を見てみましょう。

• 障害要素としてのルータ
• 非障害要素としてのプリンタ
• 障害要素としての apache サーバ

あるとき、要素が次の状態になります。

• ルータが障害
• プリンタが障害
• apache サーバが警告

サービスの状態は警告になります。なぜならプリンタは障害要素ではなく状態の計算には利用されません。また、apache サーバは障害要素ですが、障害状態の場合のみ計算に利用されます。この場合、一つの障害要素が障害状態であり、障害要素の 50% となります。

別のタイミングで、要素が次の状態になったとします。

• ルータが障害
• プリンタが障害
• apache サーバが障害

障害要素の 50% を超えて障害状態となるため、サービスの状態は障害になります。

最後に、次の状態になったとします。

• ルータが正常
• プリンタが障害
• apache が正常

障害要素の 50% 未満が障害状態なので、サービスの状態は正常になります。プリンタのみ障害状態ですが、障害要素ではないのでサービスの状態計算には含まれません。

1.2.1.2 ルートサービス

Pandora FMS バージョン 7.0 OUM726 から、サービスの評価が若干異なります。

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

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

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

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

1.2.2 新たなサービスの作成

1.2.2.1 概要

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

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

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

サービスの値は、予測モジュールのデフォルト間隔で予想サーバを使って計算されます。

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

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

定義済みのサービス一覧が表示されます。以下はサービス定義が無い例です。

1.2.2.2 初期設定

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

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

• 名前(Name): サービス名。
• 説明(Description): サービスの説明。長いテキストも可能です。この説明は、サービスマップ、サービス一覧表示、およびサービスウィジェットに(名前の代わりに)表示されます。
• グループ(Group): サービスのグループ。組織分けと SLA の条件設定に便利です。
• モード(Mode): 要素のウエイトの計算モードです。
  • 手動(Manual): サービスとその要素に手動でウエイトを入れます。
  • 自動(Auto): サービスの障害閾値は 1、警告閾値は 0.5です。また、いつでもサービスの要素を作成することができ、正常状態の場合のウエイトは 0、警告状態は 0.1、障害状態は 1 が自動的に割り当てられます。
  • シンプル(Simple): ウエイトを入力する必要がありません。チェックボックスで障害要素とするかどうかを有効化・無効化するだけです。
• 障害(Critical): 障害状態のウエイト閾値です。自動計算が有効の場合デフォルトで 1 となり、このフィールドは無効です。シンプルモードを選択している場合は表示されません。
• 警告(Warning): 警告状態のウエイト閾値です。自動計算が有効の場合デフォルトで 0.5 となり、このフィールドは無効です。
• データ保存エージェント(Agent to store data): サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。注意: すてべのサービスモジュールの計算間隔は、コンテナとしてのエージェントに設定された間隔に依存します。
• 静観(Quiet):サービスの静観モードを有効化します。アラートやイベントを生成しません。
• 関連障害検知抑制(Cascade Protection):サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。
• お気に入り(Favourite): 新しいサービスをお気に入りに指定する設定です。 有効になっている場合は、メニューに直接リンクされます。
• このサービスの連続SLAを計算する(Calculate continuous SLA for this service): 現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。このオプションが無効化されている場合、サービスが作成されると、モジュールの履歴データは削除され情報が失われます。
• SLA 間隔(S.L.A. Interval): SLA 計算を行う時間間隔です。デフォルト値は 1ヶ月です。
• SLA 制限(S.L.A. limit): 前述のフィールドで設定した時間間隔で SLA を満たすと判断するサービスの正常状態閾値です。
• 警告サービスアラート(Warning Service alert): サービスが警告状態になった場合に利用するアラートテンプレートです。
• 障害サービスアラート(Critical Service alert): サービスが障害状態になった場合に利用するアラートテンプレートです。
• SLA 障害サービスアラート(S.L.A. critical service alert): SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。

1.2.2.3 要素設定

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

次のような画面が表示されます。ここで、サービス要素を管理(編集、追加、削除)することができます。

サービス設定ページでの重要なアイテムは次の通りです。

• タイプ(Type): サービス、モジュール、エージェントを表示するドロップダウンリストです。
• エージェント(Agent): エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
• モジュール(Module): 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
• サービス(Service): アイテムを作成するためのサービス一覧のドロップダウンリストです。アイテム作成またはサービスタイプ編集の場合のみ表示されます。ドロップダウンリストに表示されるサービスは、すべてが依存サービスではないことに注意する必要があります。サービス間の依存関係はツリー表示で見る必要があります。
• 障害(Critical): 障害要素かどうかを選択するチェックボックスです。サービスがシンプルモードの場合のみ表示されます。
• 障害ウエイト(weight on critical): 障害状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 1 で操作できません。
• 警告ウエイト(wight on warning): 警告状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0.5 で操作できません。
• 不明ウエイト(Weight on Unknown): 不明状態の場合の要素のウエイトです。デフォルト値は '0' です。サービスが自動計算モードの場合は無効化されています。サービスがシンプルモードの場合は表示されません。
• 正常ウエイト(weight on "OK"): 正常状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0 で操作できません。

最後のカラムの右にあるアクションのアイコンは次の通りです。

• 編集(Edit): オレンジ色のスパナアイコンです。アイコンに対応した行の要素を編集します。
• 削除(Delete): 赤い×印のアイコンです。クリックすると、サービスの要素を削除してもよいか別ウインドウで確認がされます。

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

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

1.2.3 サービス表示

1.2.3.1 全サービスの一覧表示

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

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

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

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

1.2.3.1.1 全サービスの表

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

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

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

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

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

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

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

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

1.2.3.1.3 サービスマップ表示

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

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

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

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

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

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

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

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

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

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

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

次の設定があります。

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

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

1.2.3.2 サービスツリー表示

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

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

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

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

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

1.2.4 サービスの値の読み方

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

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

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

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 の計算間隔は日次、週次、月次です)差は急ではなくなります。

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

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

1.2.5 根本原因分析

サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、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.2.6 サービスグループ

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

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

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

1.2.7 サービス監視の例

1.2.7.1 PandoraFMS サービス

ここでは、PandoraFMS のサービスを監視します。これは、Apache、MySQL、Pandora サーバおよび、Tentacle サーバから構成されます。これらの要素全てがまた、異なるコンポーネントのサービスで構成され、ツリー構造を作ります。

一般的な Pandora のサービスは、ウエイトが 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 で、警告状態となります。

次の画面では、Pandora サービスにおける要素ごとに異なるウエイトの設定を見ることができます。

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

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

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

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

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

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

1.3 Pandora サーバ

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