個人用ツール

Pandora:Documentation ja:Services

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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

サービスモニタリング

概要

A service is a way to group your IT resources based on their functionalities.

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

A service could be your official website, your CRM system, your support application, or even your printers. Services are logical groups which can include hosts, routers, switches, firewalls, CRMs, ERPs, websites and of course, numerous other services.

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

In Pandora FMS, we represent the services as a grouping of monitored elements (modules, agents or other services) whose individual status affects in a certain way the global functionality of the service that is provided.

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

Pandora FMS におけるサービス

Pandora FMS でのサービスの動作

The basic monitoring in Pandora FMS consists of collecting metrics from different origins, representing them as monitors (modules).

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

The monitoring in services allows us to group these modules, so that, playing with certain margins based on the accumulation of failures, we can monitor groups of different types of elements and their relationship in a larger and general service.

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

In short, service monitoring allows us to check the status of a global service. We will be able to know if our service is being provided normally (green), degraded (yellow) or if we are not providing the service (red).

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

To better understand what service monitoring is all about, let's give a small example.

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

Suppose we want to monitor our web application, which we have balanced through a series of redundant elements. The infrastructure on which our application is based could consist of the following elements:

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

  • Two routers in HA.
  • Two switches in HA.
  • 20 Apache Web Servers.
  • Four Weblogic Appliance Servers.
  • One MySQL Cluster consisting of two Storage and two SQL Processing Nodes.
  • HA 構成の 2つのルータ
  • HA 構成の 2つのスイッチ
  • 20 の apache Web サーバ
  • 4つの Weblogic アプライアンスサーバ
  • 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ

Since our goal is to know if our web application is working correctly, that is, the final assessment by our customers is that the application works.

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

The need to monitor services as something "abstract" arises when faced with the following question:

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

What happens to my application if a non-critical element falls down?

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

For example, if one of the twenty Apache servers were to crash. In theory, we could not warn, because so much redundancy arises to have problematic situations covered. But then, which one to alert about? everyone? Just some? What's the rule for the warning?

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

We could think that Pandora should only warn us if a more critical element is dropped (for example a router) or if several Apache servers are dropped.

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

The monitoring through services in Pandora FMSfeature appears to solve all these doubts.

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

The services in Pandora FMS help us to:

  • Limit the number of received alerts. We will receive alerts about situations that compromise the reliability of the services we provide.
  • Track the compliance level.
  • Simplify the visualization of the monitoring of our infrastructure.

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

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

To achieve this, we will have to monitor every element that could negatively affect our application.

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

Through the Pandora FMS console, we will have to define a service tree in which we will indicate both the elements that affect our application, as well as the degree to which they affect.

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

All the elements we add 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 status of each element affect the overall status, a system of sum of weights will be used, so that the most important (with more weight) will be more relevant to adjust the overall status of the complete service to an incorrect status before the less important elements (with less weight).

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

Let's look at all these ideas through a practical example:

  • Switches and routers: 5 points each when in critical, and 3 points if in warning.
  • WEB servers: 1.2 points for each one in critical, we do not contemplate the warning status.
  • WebLogic Servers: 2 points each in critical.
  • MySQL Cluster: 5 points for each node in critical and 3 points in warning.

例を見てみましょう:

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

We set a warning threshold for service of 4, and a critical threshold of 6. In this way, and assuming that everything is going well, the service would be "OK" if all the monitored elements are OK or not important enough to cause deficiencies in the provision of our service.

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

Service configuration
Normal Warning Critical
0 >=4 >=6
サービス設定
正常 警告 障害
0 >=4 >=6

Now let's suppose that one (1) Apache web server goes down:

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

  • 1 x SApache server in CRITICAL x 1.2 pto = 1.2 because 1.2 < 4 (Warning), the service is stil in OK status.
  • 1 x 障害状態の Apache サーバ x 1.2 ポイント = 1.2 となり、ここで、1.2 < 4 (警告) であるため、サービスの状態はまだ正常です。

The weight contribution will be:

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

2 x 0 (routers in OK)
+ 2 x 0 (switches in OK)
+ 19 x 0 (apache OK)
+ 1 x 1.2 (apache CRIT)
+ 4 x 0 (weblogic OK)
+ 1 x 0 (mysql OK)
Total: 1.2 --> Our service will be in NORMAL
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 --> サービスは正常

Let's see what happens if a WEB server and a Weblogic go down:

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

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

Total, 3,2 is still< 4 so the server remains in OK status, it is still working, it's not necessary to make a technical action immediately.

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

The weight contribution will be:

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

2 x 0 (routers in OK)
+ 2 x 0 (switches in OK)
+ 19 x 0 (apache OK)
+ 1 x 1.2 (apache CRIT)
+ 3 x 0 (weblogic OK)
+ 1 x 2 (weblogic CRIT)
+ 1 x 0 (mysql OK)
Total: 3.2 --> Our service will be in NORMAL
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 --> サービスは正常

Let's see what happens if two WEB servers and a WEblogic go down:

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

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

Total, 4.4 now it is > 4 and the service goes into WARNING status, our service has gone into a degraded status. It continues to work, and may not require immediate technical action, but it is clear that there has been a problem with our infrastructure.

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

2 x 0 (routers in OK)
+ 2 x 0 (switches in OK)
+ 18 x 0 (apache OK)
+ 2 x 1.2 (apache CRIT)
+ 3 x 0 (weblogic OK)
+ 1 x 2 (weblogic CRIT)
+ 1 x 0 (mysql OK)
Total: 4.4 --> Our service will be in WARNING
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 --> サービスは警告状態

Let's suppose that in addition to the above, a Router goes down:

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

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

Now we have 9.4 above the threshold set at 6 for CRITICAL, so, the service is in critical, it is not working Immediate technical action is imperative.

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

1 x 0 (routers in OK)
+ 1 x 5 (router in CRIT)
+ 2 x 0 (switches in OK)
+ 18 x 0 (apache OK)
+ 2 x 1.2 (apache CRIT)
+ 3 x 0 (weblogic OK)
+ 1 x 2 (weblogic CRIT)
+ 1 x 0 (mysql OK)
Total: 9.4 --> Our service is in CRÍTICAL
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 will alert the corresponding work team (operators, technicians, etc.).

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

Service monitoring is a feature only of the Enterprise version of Pandora FMS.

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


シンプルモードの動作

The weight system may be too complex when the monitoring needs are basic. To deal with this situation, a new simple mode is available on the service configuration since the 5.1 version.

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

In this mode the only configuration needed is select which elements are critical and which not. Only the critical elements will be taken into account when calculating the service status and only the critical status of the critical elements will have value. The service will going to warning when the 50% of the critical elements reached the critical status. When the 50% of the critical elements in critical were surpassed, the service will going to critical.

このモードでは、どの要素が障害でどれがそうでないかを選択する設定をするだけです。障害の要素のみがサービスの状態の計算に使われ、障害要素の 障害 状態のみが値を持ちます。障害要素の 50% が障害状態になると、サービスは警告状態になります。障害要素の 50% を超えて障害状態になると、サービスは障害状態となります。

Let's follow an example of a simple service:

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

  • Router as critical element.
  • Printer as non critical element.
  • Apache server as critical element.
  • 障害要素としてのルータ
  • 非障害要素としてのプリンタ
  • 障害要素としての apache サーバ

One day the elements report this status:

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

  • Router on critical.
  • Printer on critical.
  • Apache server on warning.
  • ルータが障害
  • プリンタが障害
  • apache サーバが警告

The service status is warning, because the printer isn't a critical element and its status is not taken into account, as well as the Apache service status, which even though is a critical element, will only be taken into account in critical status. On this situation, one critical element is on critical status, the 50% of the critical elements.

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

Another day the elements report this status:

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

  • Router on critical.
  • Printer on critical.
  • Apache server on critical.
  • ルータが障害
  • プリンタが障害
  • apache サーバが障害

The service status is critical, since more of the 50% of the critical elements are on critical status.

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

Finally, another day the elements report this status:

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

  • Router on normal.
  • Printer on critical.
  • Apache on normal.
  • ルータが正常
  • プリンタが障害
  • apache が正常

The service status is normal, since less of the 50% of the critical elements are on critical status. Only the printer is on critical status but, as we have seen, the non critical elements aren't taken into account when calculating the service status. Probably no one fix it for this.

障害要素の 50% 未満が障害状態なので、サービスの状態は正常になります。プリンタのみ障害状態ですが、障害要素ではないのでサービスの状態計算には含まれません。おそらく、これに関しては誰も対応しません。

新たなサービスの作成

概要

Template warning.png

You need the Enterprise version and the PredictionServer component enabled to be able to use the services.


Template warning.png

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


The services can represent:

  • modules
  • agents
  • other services

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

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

The service values are calculated using the Prediction Server which utilizes the default interval of the prediction modules.

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

Once you have all the devices monitored. Within each service, you can add all the modules, agents or sub-services you need to monitor the service. For example, if you want to monitor the Online Store service you need a module for content, a service that monitors the status of communications and so on. Through the following steps, you can see how to create a service with Pandora FMS.

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

To create a new service, please click on Services at the Topology Maps .

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



A list of all the available services will be shown. The next screenshot shows an empty service list.

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



初期設定

To create a new service, just click on the 'Create' button and fill out the form as shown below.

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





The names of the form fields and their meaning are as follows:

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

  • Name: name of the service.
  • Description: Service description, a long mandatory text. Said description will be the one to appear in the service map, the service table view and the service widget (instead of the name).
  • Group: group of the service. Useful for organization purposes and enforcing SLA constraints.
  • Mode: mode in which the calculation of the elements weights will be performed.
    • Manual: the weights should be entered manually into the service and their elements.
    • Auto: implying the 'critical' threshold for the service to be '1' and the 'warning' threshold to be '0.5'. It's also assumed that you'll automatically assign weights of '0' for the 'OK' status, '0.5' for 'warning' and '1' for 'critical' each time you're creating an element for this service.
    • Simple: there is no need to enter weights, only enable or disable a checkbox to indicate if the element is critical.
  • Critical: weight threshold to enter critical status. This field is disabled when the Auto calculate check is enabled, having 1 value by default.
  • Warning: weight threshold to enter warning status. This field is disabled when the Auto calculate check is enabled, having 0.5 value by default.
  • Agent to store Data: the service stores the data in special data modules (specifically the prediction modules) and it is necessary to introduce an agent to be the container of these modules, as well as the alarms that you will later have to configure in this form. Note Please note that the interval at which all service module calculations will be performed depends on the agent interval configured as a container.
  • Quiet:Activates the silent mode of the service, it will not generate alerts or events
  • Cascade Protection:Activates cascade protection over the elements of the service. These will not generate alerts or events if they belong to a service (or subservice) that is in critical condition.
  • Favourite: Token to convert the new service in favourite. If it is activated, it will have a direct link in the lateral menu.
  • Calculate continuous SLA for this service: Activates the creation of SLA and SLA value modules for the current service. If disabled, dynamically calculated SLA information is not available, and SLA compliance alerts for this service do not work. It is used for cases where the number of services needed is so high that it can affect performance.If this option is disabled, once the service has been created, the data history of these modules will be deleted and information will be lost.
  • S.L.A. Interval: time range for performing the S.L.A. constraint calculation. The default value is 1 month.
  • SLA Limit: OK status threshold of the service considered an SLA as positive for the period of time you have set in the previous field.
  • Warning Service Alert: alert template that the service will use to issue the alert when the service goes into warning status.
  • Critical Service alert: alert template that the service will use to issue the alert when the service goes into critical status.
  • SLA Critical Service Alert: alert template that the service will use to issue the alert if the SLA restrictions aren't met.
  • 名前(Name): サービス名。
  • 説明(Description): サービスの説明。長いテキストも可能です。この説明は、サービスマップ、サービス一覧表示、およびサービスウィジェットに(名前の代わりに)表示されます。
  • グループ(Group): サービスのグループ。組織分けと SLA の条件設定に便利です。
  • モード(Mode): 要素のウエイトの計算モードです。
    • 手動(Manual): サービスとその要素に手動でウエイトを入れます。
    • 自動(Auto): サービスの障害閾値は 1、警告閾値は 0.5です。また、いつでもサービスの要素を作成することができ、正常状態の場合のウエイトは 0、警告状態は 0.1、障害状態は 1 が自動的に割り当てられます。
    • シンプル(Simple): ウエイトを入力する必要がありません。チェックボックスで障害要素とするかどうかを有効化・無効化するだけです。
  • 障害(Critical): 障害状態のウエイト閾値です。自動計算が有効の場合デフォルトで 1 となり、このフィールドは無効です。
  • 警告(Warning): 警告状態のウエイト閾値です。自動計算が有効の場合デフォルトで 0.5 となり、このフィールドは無効です。
  • データ保存エージェント(Agent to store data): サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。注意: すてべのサービスモジュールの計算間隔は、コンテナとしてのエージェントに設定された間隔に依存します。* SLA 間隔(S.L.A. Interval): SLA 計算を行う時間間隔です。デフォルト値は 1ヶ月です。
  • 静観(Quiet):サービスの静観モードを有効化します。アラートやイベントを生成しません。
  • 関連障害検知抑制(Cascade Protection):サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。
  • お気に入り(Favourite): 新しいサービスをお気に入りに指定する設定です。 有効になっている場合は、メニューに直接リンクされます。
  • このサービスの連続SLAを計算する(Calculate continuous SLA for this service): 現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。このオプションが無効化されている場合、サービスが作成されると、モジュールの履歴データは削除され情報が失われます。
  • SLA Limit: OK status threshold of the service considered an SLA as positive for the period of time you have set in the previous field.
  • SLA 制限(S.L.A. limit): 前述のフィールドで設定した時間間隔で SLA を満たすと判断するサービスの正常状態閾値です。
  • 警告サービスアラート(Warning Service alert): サービスが警告状態になった場合に利用するアラートテンプレートです。
  • 障害サービスアラート(Critical Service alert): サービスが障害状態になった場合に利用するアラートテンプレートです。
  • SLA 障害サービスアラート(S.L.A. critical service alert): SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。

要素設定

Once the form has been filled in correctly, you will have an empty service which must be filled in with elements or service items as we will see below. In the service edit form, the' Config Elements' tab is selected.

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



Then you will see a page like the following screenshot, where you can manage service elements (modify, add new or delete).

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



Some important items on the service configuration page are:

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

  • Type: a drop-down list that can show service, module or agent.
  • Agente: smart search input control for agent. Only visible if the element type is of agent or module type.
  • Module: The drop-down list along with the modules' agent under previously chosen via smart search. This control is only visible when editing or creating a service element for the 'module' type.
  • Service: drop-down list of the services to create an item. Only visible if the item is to create or edit service type. We also have to keep in mind that the services appear in the drop down list are those that are not ancestors of the service, it is necessary to show proper tree structure dependency between services.
  • Critical: A checkbox to select if the element is critical. Not visible unless the service is in simple mode.
  • weight on critical: weight of the element if it is in critical condition, default is 1 and is disabled if the service is in "auto calculate".
  • wight on warning: weight of the state if this warning, default is 0.5 and is disabled if the service is in "auto calculate".
  • Weight on Unknown: The weight of the element if it's in unknown state. The default value is '0'. It's disabled if the service is in 'auto calculate' mode. Not visible if the service is in simple mode.
  • weight on "OK": weight of the element if it is in perfect condition, defaults to 0 and is disabled if the service is in "auto calculate".
  • タイプ(Type): サービス、モジュール、エージェントを表示するドロップダウンリストです。
  • エージェント(Agent): エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
  • モジュール(Module): 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
  • サービス(Service): アイテムを作成するためのサービス一覧のドロップダウンリストです。アイテム作成またはサービスタイプ編集の場合のみ表示されます。ドロップダウンリストに表示されるサービスは、すべてが依存サービスではないことに注意する必要があります。サービス間の依存関係はツリー表示で見る必要があります。
  • 障害(Critical): 障害要素かどうかを選択するチェックボックスです。サービスがシンプルモードの場合のみ表示されます。
  • 障害ウエイト(weight on critical): 障害状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 1 で操作できません。
  • 警告ウエイト(wight on warning): 警告状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0.5 で操作できません。
  • 不明ウエイト(Weight on Unknown): 不明状態の場合の要素のウエイトです。デフォルト値は '0' です。サービスが自動計算モードの場合は無効化されています。サービスがシンプルモードの場合は表示されません。
  • 正常ウエイト(weight on "OK"): 正常状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0 で操作できません。

In which, in the last column on the right, entitled "Actions", you have icons for:

  • Edit: which is the icon represented by a wrench with an orange handle. Edit the element of the row corresponding to that icon.
  • Delete: which is the icon represented by a red cross. When clicking on it, you will be asked in a modal window for confirmation to remove and delete the service element from the database.

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

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

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

  • SLA Value Service: Is the percentage value of the SLA compliance. (async_data).
  • Service_SLA_Service: This shows if the SLA is being accomplishing or not. (async_proc).
  • Service_Service: This module shows the sum of the weights of the service. (async_proc).
  • SLA Value Service: SLA を満たすパーセンテージです。(async_data)
  • Service_SLA_Service: これは、SLA を満たしているかどうかを表示します。(async_proc)
  • Service_Service: このモジュールはサービスのウエイトの合計を表示します。(async_proc)

サービス表示

全サービスの一覧表示

It is the operation list that shows all the services created, of course, it only shows those of the groups that the user that is using the Pandora console has access to.

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

To get to this view, just go to the Operation menu, open the Monitoring entry and within this is the Services section.

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

Each row represents a service, and the columns represent:

  • Name: The name of the service.
  • Description: The service description.
  • Group: The icon of the group the service belongs to.
  • Critical: The threshold value for the sums of weights to put the service into 'critical' status.
  • Warning: The threshold value for the sums of weights to put the service into 'warning' status.
  • Value: The current value for the sum of all weights for the service.
  • Status: An icon which represents the status of the service.

Four possible status are represented:

    • Red: The service is in 'critical' status because the value exceeded the critical threshold.
    • Yellow: The service is in 'warning' status because the value exceeded the critical threshold.
    • Green: The service is within the 'normal' range.
    • Gray: The service is in 'unknown' status. This usually means the service has been recently created and doesn't contain any modules or the Prediction Server is down.
  • SLA: The current value of the SLA Service. The values can be:
    • OK: the SLA is met for the interval defined in the SLA service.
    • INCORRECT: The SLA is not meant for the interval currently defined in the SLA Service.
    • N/A: The SLA is in 'unknown' status because there is insufficient data to perform the calculation.

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

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

A table for quick display of all visible services and their current status.

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



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

This view is accessible by clicking on the name of a service in the list of all services, or through the magnifying glass icon tab in the service title header.

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

Pandora will show a page similar to the one shown in the following screenshot:

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

In the screenshot, we can distinguish two zones, the service with the same columns as in the previous view at the top. And the list of the elements that compose this service at the bottom.

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

The list of elements appears in table format, where the rows correspond to each element and the columns represent:

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

  • Type: icon that represents the type of the element. It is a lego block for modules, stacked lego blocks for an agent, and a network diagram icon for the services.
  • Name: text that contains the name of the module / agent / service. They are also links to the proper section.
  • Description: short text description.
  • Weight critical: value to sum when the element is in a critical status.
  • Weight warning: value to sum when the element is in warning status.
  • Weight normal: value to sum when the element is in a normal status.
  • Data: the value of the element, it can be:
    • Module value of the module.
    • Agents text that shows the status of the agent.
    • Service the sum of all weights of the elements of the selected service.
  • Status icon that represents with a color the status of the element.
  • タイプ(Type): 要素のタイプを表すアイコン。モジュールを表すレゴブロック、エージェントを表す積み重なったレゴブロック、サービスのネットワークダイアグラムアイコンです。
  • 名前(Name): モジュール / エージェント / サービスの名前を含んだテキストです。それぞれのセクションへのリンクもあります。
  • 説明(Description): 説明のテキストです。
  • 障害ウエイト(Weight critical): 要素が障害状態の合計値です。
  • 警告ウエイト(Weight warning): 要素が警告状態の合計値です。
  • 正常ウエイト(Weight normal): 要素が正常状態の合計値です。
  • データ(Data): エレメントの値で、次のいずれかです。
    • モジュール(Module) モジュールの値。
    • エージェント(Agents) エージェントの状態を表すテキスト。
    • サービス(Service) 選択したサービスの要素の全ウエイトの合計。
  • 状態(Status) 要素の状態を色とともに表すアイコン。

Template warning.png

Keep in mind that the service elements calculation is performed by the prediction server, so it is not not real time data. And there may be situations where an agent of module are added to the service and the weight of the service is not updated until the calculation is performed again


Template warning.png

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


サービスマップ表示

This view will display the service in arborescent form as you can see in the following screenshot. In this way, it is possible to quickly see how modules, agents or sub-services influence the monitoring of the service. Even in the subservices you can see what influences them when calculating the status by the sum of the weights.

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

The possible nodes can be:

  • Module node represented with the heartbeat icon. This node is always final (leaf).
  • Agent node represented by the CPU box icon. This module is always final (leaf):
  • Service node represented by the crosed hammer and wrench icon. This module is not a final node, it must contain additional nodes.

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

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

The node's colors and the arrow that connects them to the service itself depends on the node's status.

ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。

Inside the node you can find:

  • Title name of the service / agent / module node.
  • Value list
    • Critical: weight that will sum if it reach a critical status, except if it is the root service node, which represents the threshold to reach the critical status.
    • Warning: weight that will sum if it reach a warning status, except if it is the root service node, which represents the threshold to reach the warning status.
    • Normal: weight that will sum if it reach a normal status, except if it is the root service node, which nothing will be shown.
    • Unknown: Unknown status, except if it is the root service node, which represents the threshold to reach the unknown status.

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

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

Each node in the tree is clickable, and the target link is the operational view of the node itself.

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

Info.png

When the service mode is simple, a red exclamation mark appears on the right side of the critical elements.


Info.png

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


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

From Pandora FMS version 5 onwards, in the visual console you can add services like any other item in the map.

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

To create a service item on a map, the process is the same as for all other visual map items, but the options palette will be the same as in the screenshot.

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

It will contain:

  • Label: title that will be shown in the visual console node.
  • Service: service that will be represented.

次の設定があります。

  • ラベル(Label): ビジュアルコンソールノードに表示するタイトル。
  • サービス(Service): 表示するサービス。

Note that a service item, unlike other items on the visual map, cannot be linked to other visual maps, and always the clickable link in the visual console is intended for the tree service map view described above.

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

サービスツリー表示

This view allows you to view the services in the form of a tree.

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

At each level, a count of the number of elements included in each service or agent is shown.

  • Services: reports the total number of services, agents and modules that belong to that service.
  • Agents: reports the number of modules in critical state (red color), warning (yellow color), unknown (gray color), uninitiated (blue color) and normal state (green color).

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

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

Services that do not belong to another one will always be shown in the first level. In the case of a child service, it will be shown nested inside its parent.

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

ファイル:Services treeview.png

Template warning.png

ACLs permission restriction is only applied to the first level.


Template warning.png

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




サービスの値の読み方

Planned shutdowns added before the stop date allow us to recalculate the value of the SLA reports. First, we need to activate it in the general setup. When it comes to a report SLA service if there is a scheduled outage affecting one or more elements of the service, it is considered that the planned shutdown affects entire service, because the system cannot evaluate the impact of a service component "inactive" in the whole service.

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

It is noteworthy that this is at report level, service map, and the information presented in the visual console are not altered based on planned shutdown added after the efective execution date. These service compliance percentage are calculated in real-time, based on the history data of the same service, it is very different than a report which can be "cooked" adding a "fake" planned downtime.

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

On the other hand, it is important to know how the compliance of a service is calculated:

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

Let's suppose we have a service defined by a 95% compliance in an interval of 1 hour (this is very short for the real world, but good for understanding the internal algorithm). We will use a table of values, where t is time, x is the% compliance (SLAs), and s is whether or not the service meets (1 complies, 0 fails). In 1 hour we should have exactly 12 values, assuming an interval of 5 minutes.

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

A similar case, where the service comply for the first 11 samples (first 55 minutes) and in the 60th minute, it fails, we would have these values:

この場合、最初の 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

This case is easier to calculate. the % is calculated depending on the number of samples, for example in t3 there are a total of three samples that meet service, 100%, whereas t12, we have 12 and 11 valid samples: 11 / 12.

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

Assume you are in the middle of the series, and it is recovering slowly:

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

   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

So far all seems similar to the previous scenario, but let's see what happens if we go over time:

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

   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
....

Now we see a unintuitive behavior, because the volume of valid samples remains 11 for a window of time to get to t18, where the only invalid value is out of the window, so in t18 compliance becomes 100%. This step between 91.6 and 100 is explained by the size of the window. The larger the window is (usually SLA calculation interval is daily, weekly or monthly), less abrupt will be the step.

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

サービスグループ

Services are logical groups that conform part of a business structure. Due to that, it makes sense to group services, because in a lot of cases there can be dependences between them, conforming for example a global company service composed by some other particular services (webpage, communications, etc). To group the services, it's necessary to create the big general service and the smaller ones that will be agregated to the global service, creating a logical tree structure.

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

The service groups can help us to: create visual maps, configure alerts, apply monitorin policies, etc. So we can create specific alerts when the company service is down due to the comercial department not being able to work, or the webpage is offline.

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

Next we have two examples to understand the service grouping.

次に、サービスグループを理解するための 2つの例を示します。

サービス監視の例

PandoraFMS サービス

In this case the service of PandoraFMS is being monitored, it is composed by the Apache service, MySQL, Pandora server and Tentacle server. Every one of this elements also constitutes a service with different components, creating a tree-type structure.

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


The general Pandora service will turn into critical status if it reaches the weight of 2, and warning status with 1. As you can see, the four components have different weights over the Pandora service:

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

  • MySQL: critical for the Pandora service, individual weight of 2 if MySSQL is down. It will have weight 1 if it turns into warning status, already displaying yellow status on the Pandora service.
  • Pandora Server: critical for the Pandora service, individual weight of 2 if Pandora Server is down. Individual weight of 1 if it is on warning status, displaying the warning state on the Pandora service for example, if it reaches a heavy CPU load.
  • Apache: it means a degradation of the global Pandora service, but not a complete interruption, so it will has an individual weight of 1 if it is down, showing the warning status on the Pandora service.
  • Tentacle: same as the Apache, it means a degradation of the service, but not a total interruption, so it gets 1 of weight if down, and will display warning status.
  • MySQL: Pandora サービスにとってクリティカルで、MySQL がダウンしたらウエイトは 2です。警告状態の場合は、ウエイトは 1で、Pandora サービスで黄色の状態表示となります。
  • Pandora Server: Pandora サービスにとってクリティカルで、Pandora サーバがダウンしたらウエイトは 2 です。警告状態の場合のウエイトは 1 で、たとえば CPU のロードが上がった場合に Pandora サービスが警告状態を表示します。
  • Apache: Pandora サービス全体としてはデグレード状態で、完全に止まっているわけではありません。ダウンした場合のウエイトは 1 で、Pandora サービスは警告状態になります。
  • Tentacle: Apache の場合と同じで、Pandora サービス全体としてはデグレード状態で、完全に止まっているわけではありません。ダウンした場合のウエイトは 1 で、警告状態となります。

In the following picture we can see the setup of the different weights for the elements over the Pandora general service:

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


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

Services are logically arranged groups which are part of a company's business structure. Therefore, it may be necessary to create groups of services, because services alone sometimes don't have an appropriate context. To create service groups, you're required to add each service to an existing agent. In this case, a service is going to be a module of an agent. You're able to create a new logical structure (a group of services) by these groups.

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

On the following example we have an HA storage cluster. For this case there are a two fileserver systems working in paralell, each one controlling the percentage and status of some different disks that provide service to specific departments, creating a tree-type structure with grouped services.

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


According to this structure, the criticity threshold of the storage service will be reached only if both of the fileservers fail, this would totally deny the service, and if only one of the fileservers fail it would only suppose a degradated service. In the screenshot below we can appreciate the weight configuration of the two main elemnts of the storage service:

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


In the following image, we can see the content and weight configuration of the grouped service FS01. Here, the elemets will have an specific weigh according to its criticity, being:

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

  • FS01 ALIVE: critical to the FS01 service, since it is the virtual IP assigned to the first disk cluster. Individual weigh 2, if it's down, the other elements would automatically be inoperative. In this case there is no warning threshold, since it is a yes/no based type of information.
  • DHCPserver ping: critic to the FS01 service, we give it an individual weight of 2. In this case there is no warning threshold either.
  • Disks we give them an individual weight of 1 in case they reach its own critical status, and 0.5 for their warning status. According to this, the FS01 service will only reach critical status if there are two disks on critical status o four in warning status.
  • FS01 ALIVE: FS01 サービスの障害ポイントです。1つ目のディスククラスタに割り当てられた仮想 IP です。ダウンした場合のウエイトは 2 で、他の要素は機能しなくなります。この場合、警告の閾値はなく、情報としては OK か NG かです。
  • DHCPserver ping: FS01 サービスの障害ポイントです。ウエイトは 2 を指定しています。これには、警告の閾値はありません。
  • Disks 障害状態の場合のウエイトは 1 で、警告状態では 0.5 です。これにより、2つのディスクが障害状態となった場合または 4つのディスクが警告状態になった場合に、FS01 サービスが障害状態になります。

Pandora サーバ

It is mandatory that the Prediction service is up and running and having installed the Enterprise version of Pandora FMS.

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