差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン最新のリビジョン両方とも次のリビジョン | ||
ja:documentation:03_monitoring:07_services [2023/10/27 06:41] – [ビジュアルコンソールでのサービス] junichi | ja:documentation:03_monitoring:07_services [2023/12/20 08:17] – [サービス監視] junichi | ||
---|---|---|---|
行 1: | 行 1: | ||
====== サービス監視 ====== | ====== サービス監視 ====== | ||
- | {{indexmenu_n> | + | {{indexmenu_n> |
[[ja: | [[ja: | ||
行 453: | 行 453: | ||
==== サービスツリー表示 ==== | ==== サービスツリー表示 ==== | ||
- | この表示は、ツリー形式でサービスを表示します。 | + | 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)** からアクセスできます。 |
- | * サービス: | + | <WRAP center round important 60%> |
- | * エージェント: | + | |
- | 他のサービスに属さないサービスは常に一番上のレベルに表示されます。 子サービスの場合は、親の中にネストされて表示されます。 | + | The ACL permission restriction only applies to the first level. |
- | [[: | + | </ |
- | <WRAP center round important 60%> ACL によるアクセス制御は、一番上のレベルにのみ適用されます。 </ | + | <WRAP center round important 60%> |
+ | |||
+ | ACL によるアクセス制御は、一番上のレベルにのみ適用されます。 | ||
+ | |||
+ | </ | ||
===== サービスの値の読み方 ===== | ===== サービスの値の読み方 ===== | ||
- | 計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。 | + | 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 レポートの値を再計算することができます (これは、**一般設定**で全体で有効にする必要があるオプションです)。サービスの要素に影響する計画停止がある場合、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 であり、その後、サーバは、サービスが障害または警告状態であるかどうかをチェックします。 | シンプルモードでは、通常のウエイトとは別に、障害ウエイトと 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時間 (実際の場合ではとても短いですが内部アルゴリズムを理解するには良いです) で 95% の稼働率として定義したサービスがあると仮定します。値を表示にして、t が時間、x が(SLAの)パーセンテージ、そして s がサービスが維持できているかどうか(1: | + | **障害** の重みは、要素の障害の重みの合計の半分、つまり 1 になるように計算されます。要素が 3 つある場合、サービスの障害の重みは 1.5 となり、サーバが障害の重みを超えているか、サービスを **障害** または **警告** 状態に移行するかを決定します。 |
- | この場合、最初の 11サンプル(最初の 55分)ではサービスを満たしており、60分のときに満たせずに次のようになったとします。 | + | ===== サービス関連障害検知抑制 ===== |
- | < | + | |
- | | + | 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 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 | + | |
- | 11 | + | |
- | 12 | + | |
- | </ | + | サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。 |
- | この場合は計算は簡単です。パーセンテージはサンプル数に依存して計算されます。たとえば、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. |
- | 途中で問題が発生したと仮定すると、ゆっくり復旧します。 | + | **サービ関連障害検知抑制**機能が有効な場合、ルートサービス用に設定されたテンプレートにリンクされたアクションが実行されます。 サービス内で不正な状態となっている要素を報告します。 |
- | < | + | |
- | | + | 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 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 | + | |
- | 11 | + | |
- | 12 | + | |
- | </ | + | このシステムでは、サービスの全体の状態が正常の場合でも、サービス内の要素が障害状態になったときにそのアラートを発報できるということを考慮することが必要です。 |
- | これまでのシナリオに似ていますが、その後時間が進んでいくとどうなるか見てみましょう。 | + | Service cascade protection will accurately notify which root elements have failed regardless of the depth of the defined Service. |
- | < | + | |
- | | + | サービス関連障害検知抑制は、定義されたサービスの深さに関係なく、どの要素が障害なのかを示します。 |
- | -------- ------- -------- | + | |
- | 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 の計算間隔は日次、週次、月次です)差は急ではなくなります。 | + | A macro called '' |
- | ===== サービス関連障害検知抑制 ===== | + | サービス状態の根本原因を示す '' |
- | <WRAP center round tip 60%> {{: | + | ---- |
- | サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。 | + | [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] |
- | 上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。 | + | [Web Application → Balancers → 192.168.10.139] |
- | ===== 根本原因分析 ===== | + | ---- |
- | サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。 | + | This example indicates that: |
- | これを利用するには、サービスにリンクしたテンプレートに以下のテキストを追加します。 | + | この例は次のような内容を示しています。 |
- | < | + | |
- | Alert body: Example message | + | * Apache servers 3, 4 and 10 are in critical |
- | The series of events that have caused the service | + | * MySQL_base 1 and 5 databases are stopped. |
- | _rca_ | + | * 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. |
- | < | + | このような情報によりサービスの問題原因をデバッグできるため、調査タスクを軽減することができます。 |
- | 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] | + | |
- | </ | + | ===== サービスグループ ===== |
- | この出力結果を見ることにより、以下を想定できます。 | + | Services are logical groupings that make up part of an organization' |
- | * Apache | + | サービスは、組織のビジネス構造の一部を構成する論理的なグループです。 このため、多くの場合、相互に依存関係が存在する可能性があるため、サービスをグループ化することにはある程度の意味がある場合があります。たとえば、一般的なサービス (会社) を複数のより具体的なサービス (企業 Web サイト、通信など) で構成するなどです。 |
- | * MySQL_base データベース | + | |
- | * ロードバランサー | + | |
- | この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。 | + | 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: |
- | + | ||
- | サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。 | + | |
- | + | ||
- | サービスグループをより理解するためには、以降の例を確認してください。 | + | |
- | ===== サービス監視の例 ===== | + | ===== (OBSOLETE) |
==== PandoraFMS サービス ==== | ==== PandoraFMS サービス ==== | ||
行 829: | 行 783: | ||
メタコンソールサービスの可能性も拡張され、他のサービス、モジュール、またはエージェントをサービス要素として追加できるようになりました。 以前のバージョンでは、ノードサービスのみを追加できました。 | メタコンソールサービスの可能性も拡張され、他のサービス、モジュール、またはエージェントをサービス要素として追加できるようになりました。 以前のバージョンでは、ノードサービスのみを追加できました。 | ||
- | ===== 新たなサービスの作成 ===== | + | ===== (OBSOLETE) |
==== Pandora FMS サーバ ==== | ==== Pandora FMS サーバ ==== | ||
行 1032: | 行 986: | ||
* **Service_Service: | * **Service_Service: | ||
- | ===== サービス表示 ===== | + | ===== (OBSOLETE) |
==== 全サービスの一覧表示 ==== | ==== 全サービスの一覧表示 ==== | ||
行 1157: | 行 1111: | ||
- | ===== サービスの値の読み方 | + | ===== (OBSOLETE) |
計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。 | 計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。 | ||
行 1233: | 行 1187: | ||
直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。 | 直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。 | ||
- | ===== サービス関連障害検知抑制 ===== | + | ===== (OBSOLETE) |
<WRAP center round tip 60%> | <WRAP center round tip 60%> | ||
行 1252: | 行 1206: | ||
上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。 | 上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。 | ||
- | ===== 根本原因分析 ===== | + | ===== (OBSOLETE) |
サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。 | サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。 | ||
行 1285: | 行 1239: | ||
この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。 | この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。 | ||
- | ===== サービスグループ ===== | + | ===== (OBSOLETE) |
サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。 | サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。 | ||
行 1293: | 行 1247: | ||
サービスグループをより理解するためには、以降の例を確認してください。 | サービスグループをより理解するためには、以降の例を確認してください。 | ||
- | ===== サービス監視の例 ===== | + | ===== (OBSOLETE) |
==== PandoraFMS サービス ==== | ==== PandoraFMS サービス ==== | ||
行 1448: | 行 1402: | ||
<WRAP center round tip 60%> サービスのモードが// | <WRAP center round tip 60%> サービスのモードが// | ||
+ | === ビジュアルコンソールでのサービス === | ||
+ | |||
+ | Pandora FMS バージョン 5 以降では、マップ内の他のアイテムのように、ビジュアルコンソールにサービスを追加することができます。 | ||
+ | |||
+ | [[: | ||
+ | |||
+ | マップ上にサービスアイテムを作成するには、ビジュアルマップの他のアイテムと同じように操作します。ただし、オプション画面は、スクリーンショットのようになります。 | ||
+ | |||
+ | [[: | ||
+ | |||
+ | 次の設定があります。 | ||
+ | |||
+ | * **ラベル(Label)**: | ||
+ | * **サービス(Service)**: | ||
+ | ビジュアルマップ上の他のアイテムとは異なり、サービスアイテムは他のビジュアルマップにリンクすることはできないことに注意してください。ビジュアルコンソール内のサービスアイテムをクリックすると、常に前述のツリーサービスマップ表示になります。 | ||