差分

このページの2つのバージョン間の差分を表示します。

--- ja:documentation:03_monitoring:07_services [2023/10/27 06:40] – [要素の一括操作] junichi
+++ ja:documentation:03_monitoring:07_services [2023/12/20 08:17] – [サービス監視] junichi
@@ 行 1: / 行 1: @@
 ====== サービス監視 ======
-{{indexmenu_n>7}}
+{{indexmenu_n>9}}
 [[ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]]
@@ 行 449: / 行 449: @@
-=== サービスマップ表示 ===
-ここでは、次の画面のようにサービスをツリー構造で表示します。これにより、どのようなモジュール、エージェント、サブサービスがサービスに影響を与えるのかを見ることができます。サブサービスにおいても、ステータスをウェイトの合計で計算し、何がサブサービスに影響を与えるのかを確認できます。
-{{  :wiki:services_servicemap_v5.png?800  }}
+==== サービスツリー表示 ====
-ノードの種類は次の通りです。
+This view allows the visualization of services in tree form. It is accessed through the menu **Operation** → **Topology maps** → **Services** → **Service tree view.**
-  * **モジュールノード(Module node)**  ハートビートアイコンで表示されます。このノードは常に末端です。
+この表示は、ツリー形式でサービスを表示します。**操作(Operation)** → **トポロジマップ(Topology maps)** → **サービス(Services)** → **サービスツリー表示(Service tree view)** からアクセスできます。
-  * **エージェントノード(Agent node)**  CPU ボックスアイコンで表示されます。このモジュールは常に末端です。
-  * **サービスノード(Service node)**  ハンマーとスパナアイコンで表示されます。他のノードを含む必要があります。
-ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。常に、緑が正常、赤が障害、黄色が警告、グレーが不明状態です。
-ノード内は次の通りです。
+<WRAP center round important 60%>
-  * **タイトル(Title)**  サービス / エージェント / モジュールノードの名前。
+The ACL permission restriction only applies to the first level.
-  * **値一覧(Value list)**
-      * **障害(Critical)**: 障害状態になるウエイトの合計です。ルートサービスノードの場合は、障害状態になる閾値を表します。
-      * **警告(Warning)**: 警告状態になるウエイトの合計です。ルートサービスノードの場合は、警告状態になる閾値を表します。
-      * **正常(Normal)**: 正常状態になるウエイトの合計です。ルートサービスノードの場合は何も表示しません。
-      * **不明(Unknown)**: 不明状態。ルートサービスノードの場合は、不明状態になる閾値を表します。
-ツリー内の各ノードはクリックすることができ、ノードの操作画面へのリンクになっています。
-<WRAP center round tip 60%> サービスのモードが//シンプル// の場合、赤い ! マークが障害要素の右に表示されます。 </WRAP>
+</WRAP>
-=== ビジュアルコンソールでのサービス ===
+<WRAP center round important 60%>
-Pandora FMS バージョン 5 以降では、マップ内の他のアイテムのように、ビジュアルコンソールにサービスを追加することができます。
+ACL によるアクセス制御は、一番上のレベルにのみ適用されます。
-[[:wiki:servicios1.jpg?id=ja%3Adocumentation%3A03_monitoring%3A07_services&media=wiki:servicios1.jpg|{{  :wiki:servicios1.jpg?800  |servicios1.jpg}}]]
+</WRAP>
-マップ上にサービスアイテムを作成するには、ビジュアルマップの他のアイテムと同じように操作します。ただし、オプション画面は、スクリーンショットのようになります。
+===== サービスの値の読み方 =====
-[[:wiki:servicios2.jpg?id=ja%3Adocumentation%3A03_monitoring%3A07_services&media=wiki:servicios2.jpg|{{  :wiki:servicios2.jpg?800  |servicios2.jpg}}]]
+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 レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。
-  * **ラベル(Label)**: ビジュアルコンソールノードに表示するタイトル。
+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.
-  * **サービス(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).
-各レベルで、各サービスまたはエージェントに含まれる要素数のカウントが表示されます。
-  * サービス: そのサービスに属するサービス、エージェント、およびモジュールの総数を報告します。
-  * エージェント: 障害状態(赤色)、警告(黄色)、不明(灰色)、未初期化(青色)、および正常状態(緑色)のモジュール数を報告します。
-他のサービスに属さないサービスは常に一番上のレベルに表示されます。 子サービスの場合は、親の中にネストされて表示されます。
-[[:wiki:services_treeview.png?id=ja%3Adocumentation%3A03_monitoring%3A07_services&media=wiki:services_treeview.png|{{  :wiki:services_treeview.png  }}]]
-<WRAP center round important 60%> ACL によるアクセス制御は、一番上のレベルにのみ適用されます。 </WRAP>
-===== サービスの値の読み方 =====
-計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。
-あとから設定した計画停止に基づいて変更されないレポートレベル、サービスマップ、ビジュアルコンソールでの表示情報は注目に値します。これらのサービス提供状況のパーセンテージは、同じサービスの過去のデータをもとにリアルタイムで計算されます。ダミーの計画停止を設定した場合と比べてレポートは大きく異なります。
-一方で、サービスの順守状況の計算方法を知ることも重要です。
-**シンプルモードにおけるウエイトの計算**
 シンプルモードでは、通常のウエイトとは別に、障害ウエイトと 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.
-時間 (実際の場合ではとても短いですが内部アルゴリズムを理解するには良いです) で 95% の稼働率として定義したサービスがあると仮定します。値を表示にして、t が時間、x が(SLAの)パーセンテージ、そして s がサービスが維持できているかどうか(1:正常,0:異常)です。1時間のうちに、5分間隔で 12個の値を取得します。
+**障害** の重みは、要素の障害の重みの合計の半分、つまり 1 になるように計算されます。要素が 3 つある場合、サービスの障害の重みは 1.5 となり、サーバが障害の重みを超えているか、サービスを **障害** または **警告** 状態に移行するかを決定します。
-この場合、最初の 11サンプル(最初の 55分)ではサービスを満たしており、60分のときに満たせずに次のようになったとします。
+===== サービス関連障害検知抑制 =====
-<code>
-   t    |   s   |    x
+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.
--------- ------- --------
-          1      100
-          1      100
-          1      100
-          1      100
-          1      100
-          1      100
-          1      100
-          1      100
-          1      100
-         1      100
-         1      100
-         0      91,6
-</code>
+サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。
-この場合は計算は簡単です。パーセンテージはサンプル数に依存して計算されます。たとえば、t 3 ではサービスを満たすトータル 3つのサンプルがあり 100% です。t 12 では、12 サンプル中満たしているのが 11 なので、11 / 12 です。
+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.
-途中で問題が発生したと仮定すると、ゆっくり復旧します。
+**サービ関連障害検知抑制**機能が有効な場合、ルートサービス用に設定されたテンプレートにリンクされたアクションが実行されます。 サービス内で不正な状態となっている要素を報告します。
-<code>
-   t    |   s   |    x
+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.
--------- ------- --------
-          1      100
-          1      100
-          1      100
-          1      100
-          1      100
-          0      83,3
-          1      85,7
-          1      87,5
-          1      88,8
-         1      90
-         1      90,9
-         1      91,6
-</code>
+このシステムでは、サービスの全体の状態が正常の場合でも、サービス内の要素が障害状態になったときにそのアラートを発報できるということを考慮することが必要です。
-これまでのシナリオに似ていますが、その後時間が進んでいくとどうなるか見てみましょう。
+Service cascade protection will accurately notify which root elements have failed regardless of the depth of the defined Service.
-<code>
-   t    |   s   |    x
+サービス関連障害検知抑制は、定義されたサービスの深さに関係なく、どの要素が障害なのかを示します。
--------- ------- --------
-        1      91,6
-        1      91,6
-        1      91,6
-        1      91,6
-        1      91,6
-        1      100
-        1      100
-....
-</code>
+===== 根本原因分析 =====
-直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。
+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_'' というマクロが利用可能です。 これを使用するには、サービスに関連付けられているテンプレートに追加します。 このマクロは、次のような出力を返します。
-<WRAP center round tip 60%> {{:wiki:icono-modulo-enterprise.png  |Enterprise 版}}バージョン NG 725 以上 </WRAP>
+----
-サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。
+[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]
-[[:wiki:service2test.png?id=ja%3Adocumentation%3A03_monitoring%3A07_services&media=wiki:service2test.png|{{  :wiki:service2test.png  }}]]
+[Web Application → DB Instances → MySQL_base_5]
-上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。
+[Web Application → Balancers → 192.168.10.139]
-===== 根本原因分析 =====
+----
-サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。
+This example indicates that:
-これを利用するには、サービスにリンクしたテンプレートに以下のテキストを追加します。
+この例は次のような内容を示しています。
-<code>
- Alert body: Example message
+   * Apache servers 3, 4 and 10 are in critical status.
- The series of events that have caused the service status is the following one:
+   * MySQL_base 1 and 5 databases are stopped.
- _rca_
+   * Balancer 192.168.10.139 is not responding.
-</code>
+   * 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.
-<code>
+このような情報によりサービスの問題原因をデバッグできるため、調査タスクを軽減することができます。
- 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]
-</code>
+===== サービスグループ =====
-この出力結果を見ることにより、以下を想定できます。
+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.).
-  * Apache サーバ 3,4 および 10 が障害状態
+サービスは、組織のビジネス構造の一部を構成する論理的なグループです。 このため、多くの場合、相互に依存関係が存在する可能性があるため、サービスをグループ化することにはある程度の意味がある場合があります。たとえば、一般的なサービス (会社) を複数のより具体的なサービス (企業 Web サイト、通信など) で構成するなどです。
-  * MySQL_base データベース 1 および 5 が停止
-  * ロードバランサー 192.168.10.139 が応答していない
-この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。
+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.
-===== サービスグループ =====
+サービスをグループ化するには、一般的な上位サービスと、それに追加される下位サービスの両方を作成し、論理的なツリー構造を構築する必要があります。
-サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。
+[[ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]]
-サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。
-サービスグループをより理解するためには、以降の例を確認してください。
-===== サービス監視の例 =====
+===== (OBSOLETE) サービス監視の例 =====
 ==== PandoraFMS サービス ====
@@ 行 868: / 行 783: @@
 メタコンソールサービスの可能性も拡張され、他のサービス、モジュール、またはエージェントをサービス要素として追加できるようになりました。 以前のバージョンでは、ノードサービスのみを追加できました。
-===== 新たなサービスの作成 =====
+===== (OBSOLETE) 新たなサービスの作成 =====
 ==== Pandora FMS サーバ ====
@@ 行 1071: / 行 986: @@
   * **Service_Service:**  このモジュールはサービスのウエイトの合計を表示します。(async_data)
-===== サービス表示 =====
+===== (OBSOLETE) サービス表示 =====
 ==== 全サービスの一覧表示 ====
@@ 行 1196: / 行 1111: @@
-===== サービスの値の読み方  =====
+===== (OBSOLETE) サービスの値の読み方  =====
 計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。
@@ 行 1272: / 行 1187: @@
 直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。
-===== サービス関連障害検知抑制 =====
+===== (OBSOLETE) サービス関連障害検知抑制 =====
 <WRAP center round tip 60%>
@@ 行 1291: / 行 1206: @@
 上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。
-===== 根本原因分析 =====
+===== (OBSOLETE) 根本原因分析 =====
 サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。
@@ 行 1324: / 行 1239: @@
 この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。
-===== サービスグループ =====
+===== (OBSOLETE) サービスグループ =====
 サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。
@@ 行 1332: / 行 1247: @@
 サービスグループをより理解するためには、以降の例を確認してください。
-===== サービス監視の例 =====
+===== (OBSOLETE) サービス監視の例 =====
 ==== PandoraFMS サービス ====
@@ 行 1403: / 行 1318: @@
 <WRAP center round important 60%> サービス要素の計算は、予測サーバによって実施されることに注意してください。リアルタイムのデータではありません。また、サービスにエージェントが追加された場合、サービスのウエイトは、計算が再実行されるまで更新されないことに注意してください。 </WRAP>
+=== 要素の一括操作 ===
+<WRAP center round info 60%>
+NG 765 version or later.
+</WRAP>
+<WRAP center round info 60%>
+バージョン NG 765 以降
+</WRAP>
+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:**
+  * **追加:**
+{{  :wiki:services_list_elements_operation_bulk_addition.png  }}
+  * **Editing:**
+  * **編集:**
+{{  :wiki:services_list_elements_operation_bulk_edition.png  }}
+  * **Deletion:**
+  * **削除:**
+{{  :wiki:services_list_elements_operation_bulk_deletion.png  }}
+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)** オプションで追加できます。
+{{  :wiki:services_list_elements_operation_bulk_addition_dialog.png  }}
+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)** ボタンをクリックして変更を保存します。 編集と削除も同様です。
+<WRAP center round info 60%>
+In the cases of addition and editing, the service must be in **Manual**  mode because in **Smart**  mode the weights are calculated automatically: for this reason the **Service items summary**  option will be absent or empty.
+</WRAP>
+<WRAP center round info 60%>
+追加および編集の場合、**Smart** モードでは重みが自動的に計算されるため、サービスは **手動(Manual)** モードである必要があります。このため、**サービス要素概要(Service items summary)** オプションは存在しないか空になります。 .
+</WRAP>
+See also "[[:en:documentation:05_big_environments:01_massive_operations#massive_operations:services|Massive operations: Services]]" for similar operations applied to services.
+サービスに適用される同様の操作については、「[[:ja:documentation:05_big_environments:01_massive_operations#一括操作サービス|一括操作: サービス]]」も参照してください。
+=== サービスマップ表示 ===
+ここでは、次の画面のようにサービスをツリー構造で表示します。これにより、どのようなモジュール、エージェント、サブサービスがサービスに影響を与えるのかを見ることができます。サブサービスにおいても、ステータスをウェイトの合計で計算し、何がサブサービスに影響を与えるのかを確認できます。
+{{  :wiki:services_servicemap_v5.png?800  }}
+ノードの種類は次の通りです。
+  * **モジュールノード(Module node)**  ハートビートアイコンで表示されます。このノードは常に末端です。
+  * **エージェントノード(Agent node)**  CPU ボックスアイコンで表示されます。このモジュールは常に末端です。
+  * **サービスノード(Service node)**  ハンマーとスパナアイコンで表示されます。他のノードを含む必要があります。
+ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。常に、緑が正常、赤が障害、黄色が警告、グレーが不明状態です。
+ノード内は次の通りです。
+  * **タイトル(Title)**  サービス / エージェント / モジュールノードの名前。
+  * **値一覧(Value list)**
+      * **障害(Critical)**: 障害状態になるウエイトの合計です。ルートサービスノードの場合は、障害状態になる閾値を表します。
+      * **警告(Warning)**: 警告状態になるウエイトの合計です。ルートサービスノードの場合は、警告状態になる閾値を表します。
+      * **正常(Normal)**: 正常状態になるウエイトの合計です。ルートサービスノードの場合は何も表示しません。
+      * **不明(Unknown)**: 不明状態。ルートサービスノードの場合は、不明状態になる閾値を表します。
+ツリー内の各ノードはクリックすることができ、ノードの操作画面へのリンクになっています。
+<WRAP center round tip 60%> サービスのモードが//シンプル// の場合、赤い ! マークが障害要素の右に表示されます。 </WRAP>
+=== ビジュアルコンソールでのサービス ===
+Pandora FMS バージョン 5 以降では、マップ内の他のアイテムのように、ビジュアルコンソールにサービスを追加することができます。
+[[:wiki:servicios1.jpg?id=ja%3Adocumentation%3A03_monitoring%3A07_services&media=wiki:servicios1.jpg|{{  :wiki:servicios1.jpg?800  |servicios1.jpg}}]]
+マップ上にサービスアイテムを作成するには、ビジュアルマップの他のアイテムと同じように操作します。ただし、オプション画面は、スクリーンショットのようになります。
+[[:wiki:servicios2.jpg?id=ja%3Adocumentation%3A03_monitoring%3A07_services&media=wiki:servicios2.jpg|{{  :wiki:servicios2.jpg?800  |servicios2.jpg}}]]
+次の設定があります。
+  * **ラベル(Label)**: ビジュアルコンソールノードに表示するタイトル。
+  * **サービス(Service)**: ドロップダウンリストから選択するマップに追加するサービス。
+ビジュアルマップ上の他のアイテムとは異なり、サービスアイテムは他のビジュアルマップにリンクすることはできないことに注意してください。ビジュアルコンソール内のサービスアイテムをクリックすると、常に前述のツリーサービスマップ表示になります。