サービス監視

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

A Service in Pandora FMS is a grouping of Information Technology resources (Information Technology, abbreviated IT) based on their functionalities.

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

PFMS Services are logical groupings that include hosts, routers, switches, firewalls, websites and even other Services. For example, the company's official website, Customer Relationship Management (CRM), a support application, or even all the printers in a company or home.

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

The basic monitoring in Pandora FMS consists of collecting metrics from different sources, representing them as monitors (called Modules). Monitoring based on Services allows the previous elements to be grouped in such a way that, by establishing certain margins based on the accumulation of failures, groups of elements of different types and their relationship in a larger and general service can be monitored.

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

Service monitoring is represented under three concepts: simply, by their importance weights and chained by cascading events.

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

In this mode it is only necessary to indicate which elements are critical. Access Operation → Topology maps → Services → Service tree view → Create service.

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

Only elements marked as critical will be taken into account for calculations and only the critical status of said elements will have value.

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

• When between 0 and 50% of the critical elements are in the critical state, the service will enter the warning warning state.
• When more than 50% of the critical elements enter the critical state, the service will enter the critical state.

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

A Service Tree must be defined in which both the elements that affect the application or applications and the degree to which they affect are indicated.

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

All elements added to the service trees will correspond to information that is already being monitored, whether in the form of modules, specific agents or other services.

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

To indicate the degree to which the states of each element affect the global state, a system of sum of weights will be used, so that the most important (with more weight) will be more relevant to adjust the global state of the service complete to an incorrect state before the less important elements (with less weight).

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

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

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

A root Service is one that is not part of another Service. This provides more efficient distributed logic and allows applying a service-based cascade protection system.

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

The Services in Metaconsole allow adding other Services, Modules and/or Agents as elements of a Service.

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

The Prediction server follows a calculation chain in a hierarchical manner, from top to bottom, to obtain the state of each and every component of the root service. For services with up to a thousand elements, it is a satisfactory solution.

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

By checking Asynchronous mode the service will be evaluated independently, at its own interval, even if it is part of another service, being an exception to the default synchronous behavior in which the evaluation is cascaded from the root service . An asynchronous service can be forced to run independently, even if it is part of a higher service (root service)

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

If a service that is part of another service (subservice) is marked as asynchronous at the time of evaluation of the root service, it will not execute the calculation of the state of the asynchronous service, but will take as valid the last value stored by it from the last time it was executed. This configuration can be of great help in evaluating elements in large services to improve their performance, in addition to allowing execution priority to be given to services that are elements of a root service.

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

It is necessary that the PredictionServer component is running and the Enterprise version of Pandora Server is installed.

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

Once you have all the devices monitored, within each Service add all the modules, agents or subservices necessary to monitor the Service. To create a new Service, access Operation → Topology maps → Services → Service tree view → Create service.

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

• Agent to store data: The Service saves the data in Prediction Modules). It is necessary to introduce an agent to be the container for these modules, and at the same time it will also contain the alarms.
• Mode:
  • Smart: The weights and elements that are part of the Service will be calculated automatically based on established rules.
  • Manual: The weights and elements that are part of the Service will be indicated manually with fixed values.
• Critical: Weight threshold to declare the service as critical. In Smart mode this value will be a percentage.
• Warning: Weight threshold to declare the service as in warning state. In Smart mode this value will be a percentage.
• Unknown elements as critical: Allows you to indicate that elements in an unknown state contribute their weight as if they were a critical element.
• Asynchronous mode: By default the calculation of the states of each component is carried out synchronously. By activating this option, the calculation of the subordinate components will be carried out asynchronously.
• Cascade protection enabled: Activates cascade protection on the elements of the Service. These will not generate alerts or events if they belong to a Service (or subservice) that is in critical state.
• Calculate continuous SLA: Triggers the creation of Service Level Agreement (SLA) and SLA value modules for the current Service. It is used for cases where the number of Services required is so high that it can affect performance. If you deactivate this option after having created the Service, the historical data of these Modules will be deleted, so information will be lost.
• SLA interval: Time period to calculate the effective SLA of the 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を計算する期間。

Once an empty Service has been created, access the Service editing form and select the Configuration elements tab. The Add element button is clicked and a pop-up window with a form will appear. The form will be slightly different if the service is in smart mode or manual mode. In Type you must select module, agent, service or dynamic.

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

To calculate the status of a service, the weight of each of its elements will be added based on its status, and if it exceeds the thresholds established in the service for warning or critical, the status of the service will become warning or critical as appropriate. .

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

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

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

• critical
• warning
• unknown
• normal

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

In services in Smart mode, their status is calculated as follows:

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

• Critical elements contribute their entire percentage to the weight of the service. This means that if, for example, we have 4 elements in the service and only 1 of them is critical, that element will add 25% to the weight of the service. If instead of 4 elements there were 5, the critical element would add 20% to the weight of the service.
• The elements in warning contribute half of their percentage to the weight of the service. This means that if, for example, we have 4 elements in the service and only 1 of them in warning, that element will add up to 12.5% to the weight of the service. If instead of 4 elements there were 5, the warning element would add 10% to the weight of the service.

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

Dynamic Mode

動的モード

The following fields will only be available for elements of type Dynamic (Services in Smart mode):

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

• Matching object types: Drop-down list to choose whether the elements for which the dynamic rules will be evaluated, and which will be part of the service, will be Agents or Modules.
• Filter by group: Rule to indicate the group to which the element must belong to be part of the service.
• Having agent name: Rule to indicate the name of the Agent that the element must have to be part of the Service. A text will be indicated that must be part of the name of the desired Agent.
• Having module name: Rule to indicate the name of the Module that the element must have to be part of the Service. A text will be indicated that must be part of the name of the desired Module.
• Use regular selector expressions: If you activate this option, the search mechanism will be used using MySQL regex.
• Having custom field name: Rule to indicate the name of the custom field that the element must have to be part of the service. A text will be indicated that must be part of the name of the desired custom field.
• Having custom field value: Rule to indicate the value of the custom field that the element must have to be part of the service. A text will be indicated that must be part of the value of the desired custom field. It is possible to add searches in more custom fields with the Add custom field match button too.

• マッチする要素のタイプ(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) ボタンを使用して、さらにカスタムフィールドに検索を追加することもできます。

In the upper right tab, when creating or editing a service, the wizard for adding items appears with the following options:

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

• Add items: To add elements (agents, modules or services).
• Edit items: To edit elements.
• Delete items: To delete items.

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

To add items, the wizard presents a drop-down list in Item type to be added and by default it presents the option to add agents to the service. To do this, you must click on Agents and immediately, right next to it, the available agents will be displayed by name. You can also type in that element (free search) and it will automatically display agent matches by name. If the list of agents is long, you can filter by groups in the drop-down list named Group.

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

For modules and services the selection process is similar, except that in the case of modules there is no free search for elements.

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

In all cases you must choose one or more elements and then press the Add selected button. Below, in Service items summary there will be a summary with the agents, modules and services added to the service.

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

Once you have selected the desired elements in Service items summary, click Add elements to add and save the new components to the service being edited.

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

• SLA Value Service: It is the percentage value of SLA compliance ( async_data ).
• Service_SLA_Service: Shows whether the SLA is being met or not ( async_proc ).
• Service_Service: Shows the sum of the service weights ( async_data ).

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

It is the operation list that shows all the services created and to which the user has access rights in the Pandora FMS Console. Click Operation → Topology map → Service tree view and inside this List of services.

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

Quick display table of all visible services and their current status.

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

To add elements, there is a dialog box that allows you to select agents, modules or other services and clicking on each of them at the bottom will show the elements available to select and be added with Add selected. Once you have finished adding elements click the Add elements button to save the changes. For editing and deletion it works similarly.

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

This view allows the visualization of services in tree form. It is accessed through the menu Operation → Topology maps → Services → Service tree view.

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

Planned stops recalculate the value of SLA reports taking into account allowing recalculation “back in time” with planned stops added later (this is an option that must be activated globally in the General setup). When it comes to a service SLA report, if there is a planned stoppage that affects one or more elements of the service, the planned stoppage is considered to affect the entire service, as it is not possible to define the impact that the stoppage has on the service. overall service.

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

It is important to note that this is at the report level, the service trees, and the information they present in the visual console are not altered with respect to planned stops created after their supposed execution. These % service compliance values are calculated in real time based on historical data for the same service.

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

Weights are treated somewhat differently in simple mode as there is only the critical weight andhave the possibility of falling into two states apart from the normal one. Each element is given a weight of 1 in critical and 0 in the rest, and each time a change is made to the service elements, the service weights are recalculated. The warning weight of the service is negligible, it always has a value of 0.5 because if it is left at 0 the service will always be at a minimum in warning (but the warning weight is not used in the mode simple).

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

The critical weight is calculated so that it is half of the sum of the critical weights of the elements, which is 1. If there are 3 elements the critical weight of the service is 1.5 then the server is in charge of deciding if the critical weight has been exceeded or equaled to move the service to critical or warning status.

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

It is possible to silence those elements of a Service dynamically. This allows you to avoid an avalanche of alerts for each element that belongs to the Service or subservices.

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

When you enable the Cascade protection enabled feature, the action associated with the template that has been configured for the root service will be executed, thus reporting elements that have an incorrect state within the Service.

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

It is important to keep in mind that this system allows alerts to be used for elements that are going to be critical within the Service, even if its general status is correct.

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

Service cascade protection will accurately notify which root elements have failed regardless of the depth of the defined Service.

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

A macro called _rca_ is available which will indicate the root cause of the service state. To use it, it will be added to the template that has been associated with the service. This macro will return output similar to the following:

サービス状態の根本原因を示す _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]

This example indicates that:

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

• Apache servers 3, 4 and 10 are in critical status.
• MySQL_base 1 and 5 databases are stopped.
• Balancer 192.168.10.139 is not responding.

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

This added information makes it possible to debug the reason for the service status, reducing investigation tasks.

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

Services are logical groupings that make up part of an organization's business structure. For this reason, the grouping of services may make some sense, since in many cases there may be dependencies between one another, for example forming a general service (the company) several more specific services (corporate website, communications, etc.).

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

To group services, it is necessary that both the general or higher service and the lower services that will be added to it be created to create the logical tree-shaped structure.

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

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

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 ドキュメント一覧に戻る

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

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

• 要素の 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 ノードで定義されたサービスがメタコンソールでのルートサービス要素として表示され、メタコンソールサーバがそれを評価し、ノードに保存されている値を更新します。

これにより、より効率的な分散ロジックが提供され、サービスに基づく関連障害検知抑制を行うことができます。これに関しては、.E9.96.A2.E9.80.A3.E9.9A.9C.E5.AE.B3.E6.A4.9C.E7.9F.A5.E6.8A.91.E5.88.B6 関連障害検知抑制 にて説明しています。

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

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

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

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

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

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

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

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

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

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

名前(Name)

サービス名。

説明(Description)

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

グループ(Group)

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

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

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

モード(Mode)

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

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

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

• 静観モード(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 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。

フィールドを正しく入力したら、以下のように、要素またはサービス項目で埋める必要がある空のサービスがあります。サービス編集フォームで、'要素設定(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 コンソールを使用しているユーザがアクセスできるグループのみを表示します。

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

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

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

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

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

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

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

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

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

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

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

• モジュールノード(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 ドキュメント一覧に戻る

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

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

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

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

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

In the simple list of a service there is a drop-down icon with three options: adding, editing and bulk deletion of elements of a service.

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

• Adding:

• 追加:

• Editing:

• 編集:

• Deletion:

• 削除:

To add elements you have a dialog box that allows you to select agents, modules or other services and by clicking on each of them at the bottom it will show the elements available to be selected and added with the following options Add selected:

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

Once you have finished adding elements click on the Add elements button to save the changes. Editing and deleting works in a similar way.

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

See also “Massive operations: Services” for similar operations applied to services.

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

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

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

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

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

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

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

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

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

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

次の設定があります。

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

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