差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン最新のリビジョン両方とも次のリビジョン | ||
ja:documentation:03_monitoring:07_services [2023/10/27 23:08] – [サービスの値の読み方] junichi | ja:documentation:03_monitoring:07_services [2023/12/20 08:17] – [サービス監視] junichi | ||
---|---|---|---|
行 1: | 行 1: | ||
====== サービス監視 ====== | ====== サービス監視 ====== | ||
- | {{indexmenu_n> | + | {{indexmenu_n> |
[[ja: | [[ja: | ||
行 489: | 行 489: | ||
===== サービス関連障害検知抑制 ===== | ===== サービス関連障害検知抑制 ===== | ||
- | <WRAP center round tip 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. |
サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。 | サービス要素を動的に停止することができます。これにより、特定のサービスまたはサブサービスに属する各要素でアラートが過負荷になることを回避できます。 | ||
- | 'サービ関連障害検知抑制' | + | 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. | ||
サービス関連障害検知抑制は、定義されたサービスの深さに関係なく、どの要素が障害なのかを示します。 | サービス関連障害検知抑制は、定義されたサービスの深さに関係なく、どの要素が障害なのかを示します。 | ||
- | [[: | + | ===== 根本原因分析 ===== |
- | 上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。 | + | A macro called '' |
- | ===== 根本原因分析 ===== | + | サービス状態の根本原因を示す '' |
- | サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。 | + | ---- |
- | これを利用するには、サービスにリンクしたテンプレートに以下のテキストを追加します。 | + | [Web Application → HW → Apache server 3] |
- | < | + | |
- | Alert body: Example message | + | [Web Application → HW → Apache server 4] |
- | The series of events that have caused the service status is the following one: | + | |
- | _rca_ | + | |
- | </ | + | [Web Application → HW → Apache server 10] |
- | これは、次のような出力を返します。 | + | [Web Application → DB Instances → MySQL_base_1] |
- | < | + | [Web Application |
- | Alert body: Example message | + | |
- | The series of events that have caused the service status is the following one: | + | |
- | [web Application | + | |
- | [web Application -> HW -> Apache server 4] | + | |
- | [web Application -> HW -> Apache server 10] | + | |
- | [web Application -> DB Instances | + | |
- | [web Application -> DB Instances -> MySQL_base_5] | + | |
- | [web Application -> Balanceadores -> 192.168.10.139] | + | |
- | </ | + | [Web Application → Balancers → 192.168.10.139] |
- | この出力結果を見ることにより、以下を想定できます。 | + | ---- |
- | * Apache サーバ 3,4 および 10 が障害状態 | + | This example indicates that: |
- | * MySQL_base データベース 1 および 5 が停止 | + | |
- | * ロードバランサー 192.168.10.139 が応答していない | + | |
- | この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。 | + | この例は次のような内容を示しています。 |
+ | |||
+ | * 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 | ||
+ | * 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' |
- | サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。 | + | サービスは、組織のビジネス構造の一部を構成する論理的なグループです。 このため、多くの場合、相互に依存関係が存在する可能性があるため、サービスをグループ化することにはある程度の意味がある場合があります。たとえば、一般的なサービス (会社) を複数のより具体的なサービス (企業 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. |
+ | |||
+ | サービスをグループ化するには、一般的な上位サービスと、それに追加される下位サービスの両方を作成し、論理的なツリー構造を構築する必要があります。 | ||
+ | |||
+ | [[ja: | ||
- | ===== サービス監視の例 ===== | + | ===== (OBSOLETE) |
==== PandoraFMS サービス ==== | ==== PandoraFMS サービス ==== | ||
行 774: | 行 783: | ||
メタコンソールサービスの可能性も拡張され、他のサービス、モジュール、またはエージェントをサービス要素として追加できるようになりました。 以前のバージョンでは、ノードサービスのみを追加できました。 | メタコンソールサービスの可能性も拡張され、他のサービス、モジュール、またはエージェントをサービス要素として追加できるようになりました。 以前のバージョンでは、ノードサービスのみを追加できました。 | ||
- | ===== 新たなサービスの作成 ===== | + | ===== (OBSOLETE) |
==== Pandora FMS サーバ ==== | ==== Pandora FMS サーバ ==== | ||
行 977: | 行 986: | ||
* **Service_Service: | * **Service_Service: | ||
- | ===== サービス表示 ===== | + | ===== (OBSOLETE) |
==== 全サービスの一覧表示 ==== | ==== 全サービスの一覧表示 ==== | ||
行 1102: | 行 1111: | ||
- | ===== サービスの値の読み方 | + | ===== (OBSOLETE) |
計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。 | 計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。 | ||
行 1178: | 行 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%> | ||
行 1197: | 行 1206: | ||
上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。 | 上記の例では、サービスの要素の 1つが障害状態にあることがわかります。メインサービスが正常な場合でも、内部の要素における障害状態を警告し、障害状態の要素に関連するアラートを発報します。 | ||
- | ===== 根本原因分析 ===== | + | ===== (OBSOLETE) |
サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。 | サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、Pandora FMS はサービスの状態(正常、障害、警告など)を示すアラートを出していました。 OUM725 からは、サービスの状態の根本原因を示す新しいマクロが利用可能になりました。 | ||
行 1230: | 行 1239: | ||
この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。 | この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。 | ||
- | ===== サービスグループ ===== | + | ===== (OBSOLETE) |
サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。 | サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。 | ||
行 1238: | 行 1247: | ||
サービスグループをより理解するためには、以降の例を確認してください。 | サービスグループをより理解するためには、以降の例を確認してください。 | ||
- | ===== サービス監視の例 ===== | + | ===== (OBSOLETE) |
==== PandoraFMS サービス ==== | ==== PandoraFMS サービス ==== |