Difference between revisions of "Pandora: Documentation ja: Services"

From Pandora FMS Wiki
Jump to: navigation, search
(Pandora FMS バージョン 5 以降)
(ビジュアルコンソールでのサービス)
 
(33 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
== 概要 ==
 
== 概要 ==
  
=== サービスモニタリングの概念 ===
+
サービスは、その機能に基づいてITリソースをグループ化する方法です。
  
サービスは、機能に基づいて IT リソースをグループ化する手法です。例えば、サービスは、公式ウェブサイト、CRM システム、アプリケーション、または、プリンタなどです。サービスは、ホストやルータ、スイッチ、ファイアーウォール、CRM、ERP、ウェブやその他サービスの論理的なグループです。以下の例で、サービスとは何かをより明確にします。
+
サービスは、公式のWebサイト、CRMシステム、サポートアプリケーション、またはプリンタなどです。 サービスは、ホスト、ルーター、スイッチ、ファイアウォール、CRM、ERP、Webサイトその他の多数のサービスを含む論理的なグループです。
  
Chip Company は、ウェブサイトを通してコンピュータを世界中に販売しています。オンラインショップ、サポート、および管理の 3つの大きな部門があります。
+
Pandora FMS では、監視要素(モジュール、エージェント、その他サービス)のグルーピングとしてサービスを表現します。それぞれの個々の状態が、特定の方法でサービス全体が機能しているかの判断に影響を与えます。
  
<center>
+
== Pandora FMS におけるサービス ==
[[Image:Chip-departments.png‎]]
 
</center>
 
  
ご覧の通り、オンラインショップ、サポート、直接ではありませんが管理の 3つのサービスが顧客に提供されています。すべてのサービスは、どれか一つが機能しなくなると他に影響が出て会社としての機会損失を発生させるため、ビジネスに重要です。最終的には、満足した顧客は、他の顧客を連れてきます。
+
=== Pandora FMS でのサービスの動作 ===
  
Chip Company のサービスをモニタするには、それぞれのサービスの詳細をより知る必要があります。
+
Pandora FMS における基本的な監視は、異なる対象からの情報を収集することから成っています。それらを監視項目(モジュール)と呼びます。
  
オンラインショップ部門は、ショップのウェブサイトが稼働し、買い物がしやすいように、すべての製品の価格が正しい状態であること、製品の分類をし製品の情報を提供すること、配送および支払い方法を正しく示すことに責任があります。このサービスでは、次のようなパラメータをモニタリングしたいと考えます。
+
サービスの監視により、これらのモジュールをグループ化することができます。その結果、障害の蓄積に基づいて一定のマージンを持ちながら、大規模かつ一般的なサービスにおけるさまざまな種類の要素のグループとそれらの関係を監視できます。
  
<center>
+
一言で言えば、サービス監視は、私たちがグローバルサービスの状態をチェックすることを可能にします。 サービスが正常に提供されているか(緑色)、劣化しているか(黄色)、サービスを提供していないか(赤色)がわかります。
[[Image:Operation-detail.png]]
 
</center>
 
  
サポート部門は、顧客が買ったコンピュータに関する全ての問題解決を行います。この部門の業務は、顧客のコンピュータ設定に対するヘルプ、返品されたコンピュータの交換などです。この部門は、オンラインショップと連携し、顧客サイドのサービスを行っています。そのため、高品質な会社であると認識してもらうためにとても重要です。サポートサービスでは、次のようなパラメータをモニタリングしたいと考えます。
+
サービス監視をより理解しやすいように、小さな例をみていきます。
  
<center>
+
冗長要素によってバランスをとっている Web アプリケーションを監視したいとします。 アプリケーションの基盤となるインフラストラクチャは、次の要素で構成されます。
[[Image:Support-service-detail.png]]
 
</center>
 
  
3番目の部門は、マーケティング、広報など、その他内部管理を目的とした管理部門です。彼らの主な業務は、組織におけるすべてのプロセスが正しいかを見ることです。この部門のサービスは、すべての部門のとりまとめであるため、とても重要です。管理サービスのためのパラメータは次の通りです。
+
* HA 構成の 2つのルータ
 
+
* HA 構成の 2つのスイッチ
<center>
+
* 20 の apache Web サーバ
[[Image:Management-detail.png]]
+
* 4つの Weblogic アプライアンスサーバ
</center>
+
* 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ
 
 
サービスをモニタするために、Pandora FMS ビジュアルコンソールで Chip Company のサービス構造を説明した画像を使ってマップを作成します。これらのマップは、リアルタイムで更新されるため、常にサービスの状態を知ることができます。最初に作成するマップは、それぞれのサービスのマップです。
 
 
 
次の画像は、それぞれのパラメータのステータスを含むオンラインショップサービスのマップを示しています。ご覧の通り、'''Content Updated''' というパラメータが赤くなっています。これは、そこに問題があることを意味しています。他のパラメータは、緑表示になっているため問題が無いといえます。緑の矢印をクリックすると、全体のビューに行くことができます。次のステップで示します。
 
 
 
<center>
 
[[Image:Screen-onlineshop-detail.png]]
 
</center>
 
 
 
どんな問題が発生しているかを知りたい場合は、赤いアイコンをクリックします。すると、問題に関してより詳細を知ることができる、技術的な表示を見ることができます。この表示では、Pandora FMS が CRM、ERP、SAP サーバ、データベース (MySQL、Oracle など)、その他サーバやルータ、PC といったデバイスなど多くのソースから収集したデータが示されています。
 
 
 
<center>
 
[[Image:Agent-detail.png|700px]]
 
</center>
 
 
 
また、以下に示すようなサポートサービスのマップも作成します。ご覧の通り、サポートサービスの重要なパラメータが表示され、すべてが緑で問題無いことを示しています。
 
 
 
<center>
 
[[Image:Screen-support-detail.png]]
 
</center>
 
 
 
最後に、次に示すような管理サービスのマップを作成します。こちらもまた、重要なパラメータが表示され、すべてが緑で問題無いことを示しています。
 
 
 
<center>
 
[[Image:Screen-management-detail.png]]
 
</center>
 
  
さらに、全てのサービスの全体のマップを作成します。次の画像に示します。このマップでは、Chip Company のそれぞれのサービス状態と構造を見ることができます。また、それぞれのアイコンをクリックすると、それぞれのサービスマップを見ることができます。それぞれのサービスの状態は、それぞれのサービスのマップで見たものと同じで、管理およびサポートサービスには問題がありませんが、オンラインショップサービスには問題が発生しています。'''ご覧の通り、サービスの状態が構造的にトップまで影響しています。'''
+
私たちの目標は、Webアプリケーションが正しく機能しているかどうかを知ることです。つまり、顧客による最終的な評価は、アプリケーションが機能することです。
  
<center>
+
次の質問に直面したときに、"抽象的な" ものとしてサービスを監視する必要性が発生します。
[[Image:Screen-chip-overview.png]]
 
</center>
 
  
== Pandora FMS におけるサービス ==
+
'''クリティカルではない要素で障害が発生したときに、アプリケーションでは何が発生しているのでしょうか?'''
  
=== Pandora FMS でのサービスの動作 ===
+
たとえば、20台の Apache サーバのうちの 1台がクラッシュしたとします。 理論的には、冗長構成になっているため警告は通知できませんでした。しかし、この時何に関して警告すべきだったのでしょうか? すべて? ほんの一部? 警告のルールは何でしょうか?
  
Pandora FMS でのサービスのモニタリングは、ある特定の値だけのモニタリングではなく、異なる種類の要素グループのモニタによる複数の障害情報に基づいて実現します。
+
Pandora は、クリティカルな部分の問題(例えばルータ)や複数の Aapache サーバの障害の場合のみ警告を発するべきだと考えることができます。
  
サービスモニタリングどのように構成されるのか理解しやすいように、例を示します。
+
<b>Pandora FMS のサービス監視</b>機能はこれらすべてを解決します。
  
我々は、サービスとしてのウェブクラスタが正常かどうかをモニタしたいとします。
+
Pandora FMS のサービスは以下の手助けをします。
このクラスタは、以下の要素から構成されます。
+
* 受け取るアラートの制限。提供するサービスの信頼性を損なう状況でのアラートを受け取り。
 +
* コンプライアンスレベルの確認
 +
* インフラ監視の簡単なビジュアル表示
  
* HA 構成の 2つのルータ
+
これを達成するには、アプリケーションに悪影響を与える可能性のあるすべての要素を監視する必要があります。
* HA 構成の 2つのスイッチ
 
* 20 の apache サーバ
 
* 4つの Weblogic アプライアンスサーバ
 
* 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ
 
  
それぞれの要素は個別にモニタリング可能です。実際、最初にサービスモニタリングを有効にする必要がありますが、サービスに含まれるそれぞれの要素は、Pandora で個別にモニタします。これは、サービスモニタリングの前に設定することです。
+
Pandora FMS コンソールを通して、私たちはアプリケーションに影響を与える要素とそれが影響を与える度合の両方を指定する '''サービスツリー''' を定義する必要があります。
  
サービスモニタリングの概念として必要なこととして、このような疑問がでてきます。例えば、20 の apache サーバのうちの一つなど、一つの項目が障害状態だったとしても、全体としては障害では無いのではないだろうか。実際に、よくダウンするとしても 20ノードあるので警告でもないのではないだろうか。1ノードのダウンに対して警告は発するべきではありません (警告が ''寝てる誰かを起こす''ことを考えてください)。実際、サービスは冗長化されており、より安全になっており、緊急作業は不要です。よりクリティカルな要素 (ルータなど) がダウンしたときや、4,5台の複数のウェブサーバダウンしたときに警告を発するべきです。
+
サービスツリーに追加するすべての要素は、モジュール、特定のエージェントまたはその他のサービスのいずれかで、すでに監視されている要素です。
  
次のように、それぞれの要素に "ウエイト" を付与します。
+
それぞれの要素の状態が全体の状態にどの程度影響を与えるかを示すために、'''ウエイトの合計''' が利用されます。最重要(ウエイトが高い)な要素は、サービス全体の状態に与える影響が重要度が低い(ウエイトが低い)要素より高くなります。
  
 +
例を見てみましょう:
 
* スイッチおよびルータ: 個々の障害状態の時は 5ポイント、警告状態の時は 3ポイント
 
* スイッチおよびルータ: 個々の障害状態の時は 5ポイント、警告状態の時は 3ポイント
 
* ウェブサーバ: 個々の障害状態の場合は 1.2 ポイント、警告状態はポイント無し
 
* ウェブサーバ: 個々の障害状態の場合は 1.2 ポイント、警告状態はポイント無し
Line 97: Line 62:
 
* MySQL クラスタ: それぞれのノードに 5ポイント、警告状態で 3ポイント
 
* MySQL クラスタ: それぞれのノードに 5ポイント、警告状態で 3ポイント
  
サービスを警告状態と判断する閾値を 4、障害状態と判断する閾値を 6 とします。すべてのモニタリング要素が正常であれば、サービスも正常です。
+
<table border="0" style="width: 80%; margin: 15px auto; border-collapse: collapse;">
 +
<tr>
 +
<th rowspan="2" style="color: #fff;padding-left: 0;text-align: center;">要素のタイプ</th>
 +
<th colspan="4" style="color: #fff;padding-left: 0;text-align: center;">ウエイトの割り当て</th>
 +
</tr>
 +
<tr>
 +
<th style="color: #fff;background-color: #80BA27 !important;padding-left: 0;text-align: center;">正常</th>
 +
<th style="color: #fff;background-color: #FFB900 !important;padding-left: 0;text-align: center;">警告</th>
 +
<th style="color: #fff;background-color: #FC4444 !important;padding-left: 0;text-align: center;">障害</th>
 +
<th style="color: #fff;background-color: #B2B2B2 !important;padding-left: 0;text-align: center;">不明</th>
 +
</tr>
 +
<tr><td>ルータ</td><td>0</td><td>3</td><td>5</td><td>5</td></tr>
 +
<tr><td>スイッチ</td><td>0</td><td>3</td><td>5</td><td>5</td></tr>
 +
<tr><td>Web サーバ</td><td>0</td><td>0</td><td>1.2</td><td>1.2</td></tr>
 +
<tr><td>Weblogic サーバ</td><td>0</td><td>0</td><td>2</td><td>2</td></tr>
 +
<tr><td>MySQL サーバ</td><td>0</td><td>3</td><td>5</td><td>5</td></tr>
 +
</table>
 +
 
 +
サービスの警告しきい値を 4、障害しきい値を 6に設定します。このようにして、すべてが正しく設定できていれば、監視対象の要素すべてが正常であるか、またはサービス提供の不備を引き起こすほど重要でない場合、サービスは正常になります。
 +
 
 +
<table border="0" style="width: 80%; margin: 15px auto; border-collapse: collapse;">
 +
<tr>
 +
<th colspan="3" style="color: #fff;padding-left: 0;text-align: center;">サービス設定</th>
 +
</tr>
 +
<tr>
 +
<th style="color: #fff;background-color: #80BA27 !important;padding-left: 0;text-align: center;">正常</th>
 +
<th style="color: #fff;background-color: #FFB900 !important;padding-left: 0;text-align: center;">警告</th>
 +
<th style="color: #fff;background-color: #FC4444 !important;padding-left: 0;text-align: center;">障害</th>
 +
</tr>
 +
<tr>
 +
<td style="padding-left: 0;text-align: center;">0</td>
 +
<td style="padding-left: 0;text-align: center;">&gt;=4</td>
 +
<td style="padding-left: 0;text-align: center;">&gt;=6</td>
 +
</tr>
 +
</table>
  
 
1台の apache サーバダウンが発生した場合は次のようになります。
 
1台の apache サーバダウンが発生した場合は次のようになります。
Line 103: Line 102:
 
* 1 x 障害状態の Apache サーバ x 1.2 ポイント = 1.2 となり、ここで、1.2 < 4 (警告) であるため、サービスの状態はまだ正常です。
 
* 1 x 障害状態の Apache サーバ x 1.2 ポイント = 1.2 となり、ここで、1.2 < 4 (警告) であるため、サービスの状態はまだ正常です。
  
ウェブサーバと Weblogic サーバがダウンすると次のようになります。
+
ウエイトの計算は次のようになります。
  
* 1 x 障害状態の apache サーバ x 1.2 ポイント = 1.2  
+
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
 
* 1 x 障害状態の Weblogic サーバ x 2 = 2
  
合計すると 3.2 となり、まだ < 4 です。そのため、サービスの状態はまだ正常です。オペレータが起きる必要はありません。
+
合計は 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台のウェブサーバと、1台の Weblogic サーバがダウンした場合を見てみましょう。
  
 
* 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4  
 
* 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4  
 
* 1 x 障害状態の Weblogic サーバ x 2 = 2
 
* 1 x 障害状態の Weblogic サーバ x 2 = 2
  
この場合、4.4 > 4 となり、サービスが警告状態になります。オペレータはまだ緊急の SMS を受信しませんが、少なくとも誰かがメールを受け取ります。引き続き例を見ていきましょう。
+
合計が 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台のルータがダウンすると次のようになります。
+
上記の状態に加え、1台のルータがダウンした場合を想定してみましょう。
  
 
* 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4  
 
* 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4  
Line 123: Line 152:
 
* 1 x 障害状態のルータ x 5 = 5
 
* 1 x 障害状態のルータ x 5 = 5
  
合計ポイントは 9.4 となり、障害状態の閾値である 8 を越えています。サービスは障害状態となり、オペレータは起きることになります。
+
合計ポイントは 9.4 となり、障害状態の閾値である 6 を越えています。サービスは障害状態となり、<b>動作していません。</b> すぐに技術的な対処が必要です。
 +
 
 +
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 のみにある機能です。
 
サービスモニタリングは、エンタープライズ版の Pandora FMS のみにある機能です。
 +
<br><br>
  
 
==== シンプルモードの動作 ====
 
==== シンプルモードの動作 ====
  
監視要件が基本的な内容の場合、ウエイトシステムは複雑すぎるかもしれません。このような状況に対応するために、バージョン 5.1 からはサービス設定に新たなシンプルモードがあります。
+
監視要件が基本的な内容の場合、ウエイトシステムは複雑すぎるかもしれません。このような状況に対応するために、サービス設定にシンプルモードがあります。
 +
 
 +
このモードでは、どの要素が障害で、どの要素が障害でないかを設定するだけです。
 +
 
 +
障害としてチェックされた要素のみが計算に用いられ、''障害'' 状態の要素のみが実際の値を持ちます。
  
このモードでは、どの要素が障害でどれがそうでないかを選択する設定をするだけです。障害の要素のみがサービスの状態の計算に使われ、障害要素の ''障害'' 状態のみが値を持ちます。障害要素の 50% ''障害''状態になると、サービスは''警告''状態になります。障害要素の 50% を超えて''障害''状態になると、サービスは''障害''状態となります。
+
* 障害要素のうち、''障害'' 状態のものが 0 から 50% の間の割合であれば、''警告'' 状態となります。
 +
* 障害要素のうち、''障害'' 状態のものが 50% を超えると、''障害'' 状態となります。
  
 
シンプルサービスの例を見てみましょう。
 
シンプルサービスの例を見てみましょう。
Line 161: Line 208:
 
* apache が'''正常'''
 
* apache が'''正常'''
  
障害要素の 50% 未満が'''障害'''状態なので、サービスの状態は'''正常'''になります。プリンタのみ'''障害'''状態ですが、障害要素ではないのでサービスの状態計算には含まれません。おそらく、これに関しては誰も対応しません。
+
障害要素の 50% 未満が'''障害'''状態なので、サービスの状態は'''正常'''になります。プリンタのみ'''障害'''状態ですが、障害要素ではないのでサービスの状態計算には含まれません。
 +
 
 +
====  ルートサービス ====
 +
 
 +
Pandora FMS バージョン 7.0 OUM726 から、サービスの評価が若干異なります。
 +
 
 +
あるサービスの一部ではないサービスが評価されます。これは ''ルートサービス'' と呼ばれます。 この論理的な変更により、監視を高速化し、処理キューを最小限に抑えることができます。
 +
 
 +
さらに、これに基づき、Pandora FMS ノードで定義されたサービスがメタコンソールでのルートサービス要素として表示され、メタコンソールサーバがそれを評価し、ノードに保存されている値を更新します。
 +
 
 +
これにより、より効率的な分散ロジックが提供され、サービスに基づく関連障害検知抑制を行うことができます。これに関しては、[[https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:Alerts#.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 バージョン 5 以降 ====
+
==== 概要 ====
 +
 
 +
{{Warning|サービスを利用するには、Enterprise 版および ''予測サーバ'' が有効化されている必要があります。}}
 +
 
 +
サービスは以下を表すことができます。
  
サービスは、以下を表すことができます。
 
 
* モジュール
 
* モジュール
 
* エージェント
 
* エージェント
Line 174: Line 236:
 
サービスの値は、予測モジュールのデフォルト間隔で予想サーバを使って計算されます。
 
サービスの値は、予測モジュールのデフォルト間隔で予想サーバを使って計算されます。
  
それぞれのサービスには、作成したサービスをモニタするのに必要な全てのモジュール、エージェント、サブサービスを追加することができます。例えば、オンラインショップをモニタしたい場合、それに関連するモジュール、通信などをモニタするサブサービスなどが必要です。
+
一度、すべてのデバイスを監視します。 各サービスには、サービスを監視するために必要なすべてのモジュール、エージェント、またはサブサービスを追加できます。 たとえば、オンラインストアサービスを監視する場合は、コンテンツのモジュール、通信の状態を監視するサービスなどが必要です。 以下の手順で、Pandora FMS を使用してサービスを作成する方法を確認できます。
  
新たなサービスを作成するには、操作メニューのサービスタブをクリックし、作成ボタンをクリックします。
+
新たなサービスを作成するには、'''トポロジマップ''' の '''サービス''' をクリックします。
  
'''Pandora 6.0 の場合''': 新たなサービスを作成するには、'''トポロジマップ(Toipology Maps)''' タブでサービス(Services)''' をクリックし、'''サービスの作成(Create Service)''' ボタンをクリックします。
+
<br>
 
 
<br><center><br>
 
 
[[Image:menu_services.png|center]]
 
[[Image:menu_services.png|center]]
</center><br><br>
+
<br>
  
 
定義済みのサービス一覧が表示されます。以下はサービス定義が無い例です。
 
定義済みのサービス一覧が表示されます。以下はサービス定義が無い例です。
  
<br><center><br>
+
<br>
 
[[Image:Services empty v5.png|center|800px]]
 
[[Image:Services empty v5.png|center|800px]]
</center><br><br>
+
<br>
 +
 
 +
====初期設定====
  
 
新たなサービスを作成するには、作成ボタンをクリックし、以下に示す画面に表示されるフォームに入力します。
 
新たなサービスを作成するには、作成ボタンをクリックし、以下に示す画面に表示されるフォームに入力します。
Line 194: Line 256:
 
<br><center><br>
 
<br><center><br>
 
[[Image:Services creation v5.png|center|800px]]
 
[[Image:Services creation v5.png|center|800px]]
</center>
+
</center><br><br>
  
<center>
+
フィールド名とその意味は以下の通りです。
[[Image:new_service2.png|center|800px]]
 
</center><br><br>
 
  
フィールドの意味は次の通りです。
 
 
* '''名前(Name)''': サービス名。
 
* '''名前(Name)''': サービス名。
* '''説明(Description)''': サービスの説明。
+
* '''説明(Description)''': サービスの説明。長いテキストも可能です。この説明は、サービスマップ、サービス一覧表示、およびサービスウィジェットに(名前の代わりに)表示されます。
 
* '''グループ(Group)''': サービスのグループ。組織分けと SLA の条件設定に便利です。
 
* '''グループ(Group)''': サービスのグループ。組織分けと SLA の条件設定に便利です。
 
* '''モード(Mode)''': 要素のウエイトの計算モードです。
 
* '''モード(Mode)''': 要素のウエイトの計算モードです。
Line 208: Line 267:
 
** '''自動(Auto)''': サービスの障害閾値は 1、警告閾値は 0.5です。また、いつでもサービスの要素を作成することができ、正常状態の場合のウエイトは 0、警告状態は 0.1、障害状態は 1 が自動的に割り当てられます。
 
** '''自動(Auto)''': サービスの障害閾値は 1、警告閾値は 0.5です。また、いつでもサービスの要素を作成することができ、正常状態の場合のウエイトは 0、警告状態は 0.1、障害状態は 1 が自動的に割り当てられます。
 
** '''シンプル(Simple)''': ウエイトを入力する必要がありません。チェックボックスで障害要素とするかどうかを有効化・無効化するだけです。
 
** '''シンプル(Simple)''': ウエイトを入力する必要がありません。チェックボックスで障害要素とするかどうかを有効化・無効化するだけです。
* '''障害(Critical)''': 障害状態のウエイト閾値です。自動計算が有効の場合デフォルトで 1 となり、このフィールドは無効です。
+
* '''障害(Critical)''': 障害状態のウエイト閾値です。自動計算が有効の場合デフォルトで 1 となり、このフィールドは無効です。シンプルモードを選択している場合は表示されません。
 
* '''警告(Warning)''': 警告状態のウエイト閾値です。自動計算が有効の場合デフォルトで 0.5 となり、このフィールドは無効です。
 
* '''警告(Warning)''': 警告状態のウエイト閾値です。自動計算が有効の場合デフォルトで 0.5 となり、このフィールドは無効です。
* '''データ保存エージェント(Agent to store data)''': サービスモジュールを持つエージェントです。サービスは、特別なモジュール(予測モジュール)にデータを保存します。なぜなら、データを保存するモジュールおよび、サービスのアラート設定のために、エージェントが必要だからです。
+
* '''データ保存エージェント(Agent to store data)''': サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。'''注意''': すてべのサービスモジュールの計算間隔は、コンテナとしてのエージェントに設定された間隔に依存します。
 +
* '''静観(Quiet)''':サービスの静観モードを有効化します。アラートやイベントを生成しません。
 +
* '''関連障害検知抑制(Cascade Protection)''':サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。
 +
* '''お気に入り(Favourite)''': 新しいサービスをお気に入りに指定する設定です。 有効になっている場合は、メニューに直接リンクされます。
 +
* '''このサービスの連続SLAを計算する(Calculate continuous SLA for this service)''': 現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。'''このオプションが無効化されている場合、サービスが作成されると、モジュールの履歴データは削除され情報が失われます。'''
 
* '''SLA 間隔(S.L.A. Interval)''': SLA 計算を行う時間間隔です。デフォルト値は 1ヶ月です。
 
* '''SLA 間隔(S.L.A. Interval)''': SLA 計算を行う時間間隔です。デフォルト値は 1ヶ月です。
* '''SLA 制限(S.L.A. limit)''': SLA が正常状態の閾値です。
+
* '''SLA 制限(S.L.A. limit)''': 前述のフィールドで設定した時間間隔で SLA を満たすと判断するサービスの正常状態閾値です。
 
* '''警告サービスアラート(Warning Service alert)''': サービスが警告状態になった場合に利用するアラートテンプレートです。
 
* '''警告サービスアラート(Warning Service alert)''': サービスが警告状態になった場合に利用するアラートテンプレートです。
 
* '''障害サービスアラート(Critical Service alert)''': サービスが障害状態になった場合に利用するアラートテンプレートです。
 
* '''障害サービスアラート(Critical Service alert)''': サービスが障害状態になった場合に利用するアラートテンプレートです。
 
* '''SLA 障害サービスアラート(S.L.A. critical service alert)''': SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。
 
* '''SLA 障害サービスアラート(S.L.A. critical service alert)''': SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。
  
ノードを追加するには、'要素設定(Config elements)' タブへ行きます。
+
====要素設定====
 +
 
 +
フィールドを正しく入力したら、以下のように、要素またはサービス項目で埋める必要がある空のサービスがあります。サービス編集フォームで、'要素設定(Config Elements)' タブを選択します。
  
<br><center><br>
+
<br>
 
[[Image:Services tab setup v5.png|center]]
 
[[Image:Services tab setup v5.png|center]]
</center><br><br>
+
<br>
  
 
次のような画面が表示されます。ここで、サービス要素を管理(編集、追加、削除)することができます。
 
次のような画面が表示されます。ここで、サービス要素を管理(編集、追加、削除)することができます。
  
<br><center><br>
+
<br>
 
[[Image:Services elements empty v5.png|center|800px]]
 
[[Image:Services elements empty v5.png|center|800px]]
</center><br><br>
+
<br>
  
 
サービス設定ページでの重要なアイテムは次の通りです。
 
サービス設定ページでの重要なアイテムは次の通りです。
  
* '''タイプ(Type)''': モジュールまたはエージェント。エージェントサービスは全モジュールで動作します。
+
* '''タイプ(Type)''': サービス、モジュール、エージェントを表示するドロップダウンリストです。
 
* '''エージェント(Agent)''': エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
 
* '''エージェント(Agent)''': エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
 
* '''モジュール(Module)''': 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
 
* '''モジュール(Module)''': 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
Line 241: Line 306:
 
* '''正常ウエイト(weight on "OK")''': 正常状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0 で操作できません。
 
* '''正常ウエイト(weight on "OK")''': 正常状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0 で操作できません。
  
このページでサービスアイテムを作成すると、次のような画面で一覧が表示されます。
+
最後のカラムの右にあるアクションのアイコンは次の通りです。
 
+
* '''編集(Edit)''': オレンジ色のスパナアイコンです。アイコンに対応した行の要素を編集します。
<br><center><br>
+
* '''削除(Delete)''': 赤い×印のアイコンです。クリックすると、サービスの要素を削除してもよいか別ウインドウで確認がされます。
[[Image:Services list elements admin v5.png|800px|center]]
 
</center><br><br>
 
  
===== サービス設定時に作成されるモジュール =====
+
==== サービス設定時に作成されるモジュール ====
  
 
* '''SLA Value Service:''' SLA を満たすパーセンテージです。(async_data)
 
* '''SLA Value Service:''' SLA を満たすパーセンテージです。(async_data)
 
* '''Service_SLA_Service:''' これは、SLA を満たしているかどうかを表示します。(async_proc)
 
* '''Service_SLA_Service:''' これは、SLA を満たしているかどうかを表示します。(async_proc)
* '''Service_Service:'''  このモジュールはサービスのウエイトの合計を表示します。(async_proc)
+
* '''Service_Service:'''  このモジュールはサービスのウエイトの合計を表示します。(async_data)
  
 
=== サービス表示 ===
 
=== サービス表示 ===
==== Pandora FMS 5 およびそれ以上のバージョン ====
 
  
これ以降のバージョンでは、サービスを表示する複数の方法があります。ツリー表示と一覧表示で、サービスの状態の見方を選択できます。
+
==== 全サービスの一覧表示 ====
  
===== 全サービスの一覧表示 =====
+
作成した全サービスを表示する一覧です。もちろん、Pandora コンソールを使用しているユーザがアクセスできるグループのみを表示します。
ユーザが参照可能(アクセス制御があります)なサービス一覧です。
 
  
この表示をするには、操作(Operation)メニュー >> モニタリング(Monitorization) >> サービス(Services) へ行きます。
+
この画面へ行くには、操作メニューで監視のサービスを開きます。
  
<br><center><br>
+
<center>
 
[[Image:Services list services admin v5.png|center|800px]]
 
[[Image:Services list services admin v5.png|center|800px]]
</center><br><br>
+
</center>
  
 
それぞれの行がサービスで、カラムは次の通りです。
 
それぞれの行がサービスで、カラムは次の通りです。
Line 283: Line 344:
 
** '''INCORRECTO''': SLA サービスで定義された間隔で SLA の条件に適合していない場合。
 
** '''INCORRECTO''': SLA サービスで定義された間隔で SLA の条件に適合していない場合。
 
** '''N/A''': 計算のための十分なデータが無く、SLA が不明状態の場合。
 
** '''N/A''': 計算のための十分なデータが無く、SLA が不明状態の場合。
 +
 +
===== 全サービスの表 =====
 +
 +
全サービスとその状態を表で表示します。
 +
 +
<br>
 +
[[File:Servs.JPG|center|800px]]
 +
<br>
  
 
===== サービスとその要素の一覧表示 =====
 
===== サービスとその要素の一覧表示 =====
  
この表示をするには、全サービス表示でサービス名をクリックするか、サービス名の近くの虫眼鏡アイコンをクリックします。
+
全サービスの一覧でサービス名をクリックするかまたは、サービスタイトルヘッダーの虫眼鏡アイコンをクリックすることにより参照することができます。
 +
 
 +
Pandora は、次のようなスクリーンショットの画面を表示します。
  
<br><center><br>
+
<center>
 
[[Image:Services list elements operation v5.png|center|800px]]
 
[[Image:Services list elements operation v5.png|center|800px]]
</center><br><br>
+
</center>
 +
 
 +
2つのパートに分かれており、上に前述の表示と同じカラム、下にサービスを構成する要素の一覧です。
  
2つのパートに分かれており、前述の表示と同じカラムと、以下に示すサービスの要素一覧のカラムがあります。
+
要素の一覧は表形式で表示されます。行は各要素に対応し、列は以下を表します。
  
 
* '''タイプ(Type)''': 要素のタイプを表すアイコン。モジュールを表すレゴブロック、エージェントを表す積み重なったレゴブロック、サービスのネットワークダイアグラムアイコンです。
 
* '''タイプ(Type)''': 要素のタイプを表すアイコン。モジュールを表すレゴブロック、エージェントを表す積み重なったレゴブロック、サービスのネットワークダイアグラムアイコンです。
Line 303: Line 376:
 
** '''モジュール(Module)''' モジュールの値。
 
** '''モジュール(Module)''' モジュールの値。
 
** '''エージェント(Agents)''' エージェントの状態を表すテキスト。
 
** '''エージェント(Agents)''' エージェントの状態を表すテキスト。
** '''サービス(Service)''' 選択したサービスの要素の全ウエイトの合計。
+
** '''サービス(Service)''' 親サービスの要素として選択したサービスの要素の全ウエイトの合計。
 
* '''状態(Status)''' 要素の状態を色とともに表すアイコン。
 
* '''状態(Status)''' 要素の状態を色とともに表すアイコン。
  
Line 310: Line 383:
 
===== サービスマップ表示 =====
 
===== サービスマップ表示 =====
  
この表示をするには、次の画面に示すサービス操作画面のヘッダーのタブをクリックします。
+
ここでは、次の画面のようにサービスをツリー構造で表示します。これにより、どのようなモジュール、エージェント、サブサービスがサービスに影響を与えるのかを見ることができます。サブサービスにおいても、ステータスをウェイトの合計で計算し、何がサブサービスに影響を与えるのかを確認できます。
  
<br><center><br>
+
<center>
[[Image:Services tab servicemap v5.png|center]]
 
</center><br><br>
 
 
 
ここでは、次の画面のようにサービスをツリー構造で表示します。これにより、サービスがどのような要素で構成されているかを一目で素早く確認することができます。
 
 
 
<br><center><br>
 
 
[[Image:Services servicemap v5.png|center|800px]]
 
[[Image:Services servicemap v5.png|center|800px]]
</center><br><br>
+
</center>
  
 
ノードの種類は次の通りです。
 
ノードの種類は次の通りです。
Line 327: Line 394:
 
* '''サービスノード(Service node)''' ハンマーとスパナアイコンで表示されます。他のノードを含む必要があります。
 
* '''サービスノード(Service node)''' ハンマーとスパナアイコンで表示されます。他のノードを含む必要があります。
  
ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。
+
ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。常に、緑が正常、赤が障害、黄色が警告、グレーが不明状態です。
  
 
ノード内は次の通りです。
 
ノード内は次の通りです。
Line 346: Line 413:
  
 
<br><center><br>
 
<br><center><br>
[[Image:Services visualmap v5.png|center|800px]]
+
[[Image:Servicios1.JPG|center|800px]]
 
</center><br><br>
 
</center><br><br>
  
マップ上にサービスを作成するには、ビジュアルマップの他のアイテムと同じように操作します。
+
マップ上にサービスアイテムを作成するには、ビジュアルマップの他のアイテムと同じように操作します。ただし、オプション画面は、スクリーンショットのようになります。
  
 
<br><center><br>
 
<br><center><br>
[[Image:Services visualmap add item v5.png|center|800px]]
+
[[Image:Servicios2.JPG|center|800px]]
 
</center><br><br>
 
</center><br><br>
  
 
次の設定があります。
 
次の設定があります。
 
* '''ラベル(Label)''': ビジュアルコンソールノードに表示するタイトル。
 
* '''ラベル(Label)''': ビジュアルコンソールノードに表示するタイトル。
* '''サービス(Service)''': 表示するサービス。
+
* '''サービス(Service)''': ドロップダウンリストから選択するマップに追加するサービス。
 +
 
 +
ビジュアルマップ上の他のアイテムとは異なり、サービスアイテムは他のビジュアルマップにリンクすることはできないことに注意してください。ビジュアルコンソール内のサービスアイテムをクリックすると、常に前述のツリーサービスマップ表示になります。
 +
 
 +
==== サービスツリー表示 ====
  
サービスのどは、他のビジュアルマップへはリンクできないことに注意してください。リンクは、サービスツリー表示になります。
+
この表示は、ツリー形式でサービスを表示します。
 +
 
 +
各レベルで、各サービスまたはエージェントに含まれる要素数のカウントが表示されます。
 +
* サービス: そのサービスに属するサービス、エージェント、およびモジュールの総数を報告します。
 +
* エージェント: 障害状態(赤色)、警告(黄色)、不明(灰色)、未初期化(青色)、および正常状態(緑色)のモジュール数を報告します。
 +
 
 +
他のサービスに属さないサービスは常に一番上のレベルに表示されます。 子サービスの場合は、親の中にネストされて表示されます。
 +
 
 +
<center>
 +
[[File:services_treeview.png]]
 +
</center>
 +
 
 +
{{Warning|ACL によるアクセス制御は、一番上のレベルにのみ適用されます。}}
 +
 
 +
<br><br>
  
 
=== サービスの値の読み方  ===
 
=== サービスの値の読み方  ===
Line 427: Line 512:
  
 
直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。
 
直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。
 +
 +
'''シンプルモードにおけるウエイトの計算'''
 +
 +
シンプルモードでは、通常のウエイトとは別に、障害ウエイトと 2つの状態のみがあるため、ウエイトの扱いが少し異なります。 各要素は、障害の場合は 1、その他の状態の場合は 0 のウエイトとなり、サービス要素に変化があるたびに、サービスのウエイトが再計算されます。 警告のウエイトは無視できます。 値が 0 の場合、サービスは少なくとも常に警告状態になるため、値は常に 0.5 になりますが、シンプルモードでは警告のウエイトは使用されません。 障害ウエイトは、障害要素の合計の半分になるように計算されます。これは 1 となります。3 つの要素がある場合、サービスの障害ウエイトは 1.5 であり、その後、サーバは、サービスが障害または警告状態であるかどうかをチェックします。
 +
 +
=== 根本原因分析 ===
 +
 +
サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、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 が応答していない
 +
 +
この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。
  
 
=== サービスグループ ===
 
=== サービスグループ ===
Line 434: Line 552:
 
サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。
 
サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。
  
次に、サービスグループを理解するための 2つの例を示します。
+
サービスグループをより理解するためには、以降の例を確認してください。
  
 
=== サービス監視の例 ===
 
=== サービス監視の例 ===

Latest revision as of 00:26, 12 December 2019

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

1 サービスモニタリング

1.1 概要

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

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

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

1.2 Pandora FMS におけるサービス

1.2.1 Pandora FMS でのサービスの動作

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

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

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

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

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

  • HA 構成の 2つのルータ
  • HA 構成の 2つのスイッチ
  • 20 の apache Web サーバ
  • 4つの Weblogic アプライアンスサーバ
  • 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ

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

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

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

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

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

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

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

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

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

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

サービスツリーに追加するすべての要素は、モジュール、特定のエージェントまたはその他のサービスのいずれかで、すでに監視されている要素です。

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

例を見てみましょう:

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

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

サービス設定
正常 警告 障害
0 >=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 のみにある機能です。

1.2.1.1 シンプルモードの動作

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

このモードでは、どの要素が障害で、どの要素が障害でないかを設定するだけです。

障害としてチェックされた要素のみが計算に用いられ、障害 状態の要素のみが実際の値を持ちます。

  • 障害要素のうち、障害 状態のものが 0 から 50% の間の割合であれば、警告 状態となります。
  • 障害要素のうち、障害 状態のものが 50% を超えると、障害 状態となります。

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

  • 障害要素としてのルータ
  • 非障害要素としてのプリンタ
  • 障害要素としての apache サーバ

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

  • ルータが障害
  • プリンタが障害
  • apache サーバが警告

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

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

  • ルータが障害
  • プリンタが障害
  • apache サーバが障害

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

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

  • ルータが正常
  • プリンタが障害
  • apache が正常

障害要素の 50% 未満が障害状態なので、サービスの状態は正常になります。プリンタのみ障害状態ですが、障害要素ではないのでサービスの状態計算には含まれません。

1.2.1.2 ルートサービス

Pandora FMS バージョン 7.0 OUM726 から、サービスの評価が若干異なります。

あるサービスの一部ではないサービスが評価されます。これは ルートサービス と呼ばれます。 この論理的な変更により、監視を高速化し、処理キューを最小限に抑えることができます。

さらに、これに基づき、Pandora FMS ノードで定義されたサービスがメタコンソールでのルートサービス要素として表示され、メタコンソールサーバがそれを評価し、ノードに保存されている値を更新します。

これにより、より効率的な分散ロジックが提供され、サービスに基づく関連障害検知抑制を行うことができます。これに関しては、[関連障害検知抑制] にて説明しています。

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

1.2.2 新たなサービスの作成

1.2.2.1 概要

Template warning.png

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

 


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

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

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

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

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


Menu services.png


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


Services empty v5.png


1.2.2.2 初期設定

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



Services creation v5.png


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

  • 名前(Name): サービス名。
  • 説明(Description): サービスの説明。長いテキストも可能です。この説明は、サービスマップ、サービス一覧表示、およびサービスウィジェットに(名前の代わりに)表示されます。
  • グループ(Group): サービスのグループ。組織分けと SLA の条件設定に便利です。
  • モード(Mode): 要素のウエイトの計算モードです。
    • 手動(Manual): サービスとその要素に手動でウエイトを入れます。
    • 自動(Auto): サービスの障害閾値は 1、警告閾値は 0.5です。また、いつでもサービスの要素を作成することができ、正常状態の場合のウエイトは 0、警告状態は 0.1、障害状態は 1 が自動的に割り当てられます。
    • シンプル(Simple): ウエイトを入力する必要がありません。チェックボックスで障害要素とするかどうかを有効化・無効化するだけです。
  • 障害(Critical): 障害状態のウエイト閾値です。自動計算が有効の場合デフォルトで 1 となり、このフィールドは無効です。シンプルモードを選択している場合は表示されません。
  • 警告(Warning): 警告状態のウエイト閾値です。自動計算が有効の場合デフォルトで 0.5 となり、このフィールドは無効です。
  • データ保存エージェント(Agent to store data): サービスは、特別なモジュール(予測モジュール)にデータを保存します。これらのモジュールを持つエージェントが必要です。のちほど設定するアラートにも必要です。注意: すてべのサービスモジュールの計算間隔は、コンテナとしてのエージェントに設定された間隔に依存します。
  • 静観(Quiet):サービスの静観モードを有効化します。アラートやイベントを生成しません。
  • 関連障害検知抑制(Cascade Protection):サービスの要素に対する関連障害検知抑制を有効化します。サービスまたはその子サービスが障害状態になっても、アラートやイベントを生成しません。
  • お気に入り(Favourite): 新しいサービスをお気に入りに指定する設定です。 有効になっている場合は、メニューに直接リンクされます。
  • このサービスの連続SLAを計算する(Calculate continuous SLA for this service): 現在のサービスの SLA の作成および、モジュールの SLA 値を有効化します。無効化すると、動的な SLA 計算は行われません。また、このサービスにおける SLA 適合アラートは動作しません。必要なサービスの数が非常に多く、パフォーマンスに影響が出る可能性がある場合に無効化します。このオプションが無効化されている場合、サービスが作成されると、モジュールの履歴データは削除され情報が失われます。
  • SLA 間隔(S.L.A. Interval): SLA 計算を行う時間間隔です。デフォルト値は 1ヶ月です。
  • SLA 制限(S.L.A. limit): 前述のフィールドで設定した時間間隔で SLA を満たすと判断するサービスの正常状態閾値です。
  • 警告サービスアラート(Warning Service alert): サービスが警告状態になった場合に利用するアラートテンプレートです。
  • 障害サービスアラート(Critical Service alert): サービスが障害状態になった場合に利用するアラートテンプレートです。
  • SLA 障害サービスアラート(S.L.A. critical service alert): SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。

1.2.2.3 要素設定

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


Services tab setup v5.png


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


Services elements empty v5.png


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

  • タイプ(Type): サービス、モジュール、エージェントを表示するドロップダウンリストです。
  • エージェント(Agent): エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
  • モジュール(Module): 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
  • サービス(Service): アイテムを作成するためのサービス一覧のドロップダウンリストです。アイテム作成またはサービスタイプ編集の場合のみ表示されます。ドロップダウンリストに表示されるサービスは、すべてが依存サービスではないことに注意する必要があります。サービス間の依存関係はツリー表示で見る必要があります。
  • 障害(Critical): 障害要素かどうかを選択するチェックボックスです。サービスがシンプルモードの場合のみ表示されます。
  • 障害ウエイト(weight on critical): 障害状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 1 で操作できません。
  • 警告ウエイト(wight on warning): 警告状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0.5 で操作できません。
  • 不明ウエイト(Weight on Unknown): 不明状態の場合の要素のウエイトです。デフォルト値は '0' です。サービスが自動計算モードの場合は無効化されています。サービスがシンプルモードの場合は表示されません。
  • 正常ウエイト(weight on "OK"): 正常状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0 で操作できません。

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

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

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

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

1.2.3 サービス表示

1.2.3.1 全サービスの一覧表示

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

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

Services list services admin v5.png

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

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

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


Servs.JPG


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

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

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

Services list elements operation v5.png

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

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

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

Template warning.png

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

 


1.2.3.1.3 サービスマップ表示

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

Services servicemap v5.png

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

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

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

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

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

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

Info.png

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

 


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

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



Servicios1.JPG


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



Servicios2.JPG


次の設定があります。

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

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

1.2.3.2 サービスツリー表示

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

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

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

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

Services treeview.png

Template warning.png

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

 




1.2.4 サービスの値の読み方

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

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

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

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 の計算間隔は日次、週次、月次です)差は急ではなくなります。

シンプルモードにおけるウエイトの計算

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

1.2.5 根本原因分析

サービス内に無限の数のサブサービス(パス)が存在する場合があります。 以前のバージョンでは、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 が応答していない

この追加情報で、サービス状態の裏にある理由を見つけることができ、原因調査のためのタスクを削減することができます。

1.2.6 サービスグループ

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

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

サービスグループをより理解するためには、以降の例を確認してください。

1.2.7 サービス監視の例

1.2.7.1 PandoraFMS サービス

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

Arbol.JPG

一般的な Pandora のサービスは、ウエイトが 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 で、警告状態となります。

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

Pesos.JPG


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

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

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

Cluster.JPG

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

Pesoscluster.JPG

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

  • FS01 ALIVE: FS01 サービスの障害ポイントです。1つ目のディスククラスタに割り当てられた仮想 IP です。ダウンした場合のウエイトは 2 で、他の要素は機能しなくなります。この場合、警告の閾値はなく、情報としては OK か NG かです。
  • DHCPserver ping: FS01 サービスの障害ポイントです。ウエイトは 2 を指定しています。これには、警告の閾値はありません。
  • Disks 障害状態の場合のウエイトは 1 で、警告状態では 0.5 です。これにより、2つのディスクが障害状態となった場合または 4つのディスクが警告状態になった場合に、FS01 サービスが障害状態になります。
Pesosfs01.JPG

1.3 Pandora サーバ

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