2.7.5　ヘルスチェック機能を利用した他ホストの監視

(1)　JP1/IM - Managerを利用したシステムでの他ホスト監視

他ホストのJP1/Baseのヘルスチェック機能，およびイベントサービスが正常に稼働しているかどうかを監視できます。

次の図に示す構成例を基に，JP1/IM - Managerを利用したシステムでの他ホストの監視について説明します。

図2‒36　JP1/IM - Managerを利用したシステムでの他ホスト監視の例

図の例では，各ホストで次のように設定されています。

ホスト	役割	他ホスト監視の設定
hostA	マネージャーホスト	hostB，hostXを監視する。
hostB	サブマネージャーホスト	hostA，hostY，hostZを監視する。
hostX	エージェントホスト	設定なし。
hostY	エージェントホスト	設定なし。
hostZ	エージェントホスト	設定なし。

エージェントホストhostY，およびマネージャーホストhostAで，ヘルスチェック機能，およびイベントサービスに異常が生じた場合の処理について説明します。

hostYのヘルスチェック機能に異常が生じた場合

hostBのヘルスチェック機能が異常を検知してJP1イベントを発行します。発行されたJP1イベントはhostAに転送され，JP1/IM - ViewにhostYの異常通知が表示されます。

hostYのイベントサービスに異常が生じた場合

hostYのヘルスチェック機能が異常を検知しますが，JP1イベントを発行できないため，hostBのヘルスチェック機能が異常を検知してJP1イベントを発行します。hostBで発行されたJP1イベントはhostAに転送され，JP1/IM - ViewにhostYの異常通知が表示されます。

hostAのヘルスチェック機能に異常が生じた場合

hostBのヘルスチェック機能が異常を検知してJP1イベントを発行します。発行されたJP1イベントはhostAに転送され，JP1/IM - ViewにhostAの異常通知が表示されます。

hostAのイベントサービスに異常が生じた場合

hostAのJP1/IM - Managerでヘルスチェック機能を有効にしている場合は，JP1/IM - Managerのヘルスチェック機能がhostAのイベントサービスの異常を検知し，JP1/IM - ViewにhostAの異常通知が表示されます。

ページの先頭へ

(2)　監視対象ホストの数が多い場合の運用方法

1台のホストで複数のホストを監視する場合，ヘルスチェック機能は1台ずつホストのプロセス状況を確認します。1台のホストの監視に掛かる時間は3秒程度です。そのため，1台のホストが監視するホスト数が多いと監視に時間が掛かります。

例えば，1台のホストで200台のホストを監視すると，すべてのホストを監視し終わるまでに600秒程度掛かります。監視時間を短縮したい場合は，監視対象ホストをグループに分け，グループごとに擬似的なマネージャーホストを決めて監視してください。

図2‒37　200台のホストを監視する場合の運用例

図の例では監視対象ホストを20台ずつのグループに分けています。また，マネージャーホストhostAから擬似的なマネージャーホストhost1，host21などを監視するよう設定します。グループごとに監視すると，監視に掛かる時間を60秒程度に短縮できます。

ページの先頭へ

(3)　1回ごとの監視に掛かった時間を知りたい場合

1回ごとの監視（ポーリング）に掛かった時間を知りたい場合は，ポーリング完了メッセージ（KAVA7239-I）で確認できます。ポーリング完了メッセージ（KAVA7239-I）は，1回の監視が完了するごとに次に示すメッセージが出力されます。

KAVA7239-I ヘルスチェックによる監視が完了しました. (ホスト名=監視元ホスト名, 監視時間=監視時間秒, 監視間隔=監視間隔秒)

ポーリング完了メッセージ（KAVA7239-I）は，ヘルスチェック定義ファイルのPOLLENDMSGパラメーターにYESを指定すると出力されます。インストール時は出力しない設定になっています。ヘルスチェック定義ファイルの詳細については，「16.　定義ファイル」の「ヘルスチェック定義ファイル」を参照してください。

ページの先頭へ

(4)　階層管理した構成で障害が発生した場合の運用方法

監視対象ホストを階層管理している構成で，障害が発生した場合の運用方法について次の図で説明します。

図2‒38　階層管理している構成で，障害が発生した場合の運用例

hostBのヘルスチェック機能やイベントサービスに障害が発生した場合，hostBが監視しているhostDやhostEの異常を検知，および通知できなくなります。

hostBが短時間で復旧した場合は，hostBの停止中にhostDやhostEで障害が発生してJP1イベントが発行されても，JP1イベントの転送のリトライによって，hostBが回復した時点でJP1イベントが転送されます。hostBの復旧に長時間掛かる場合は，hostBが復旧するまでの間，hostAからhostD，hostEを直接監視するようヘルスチェック定義ファイル（jbshc.conf）を設定し直す必要があります。

このように階層管理している構成では，サブマネージャーホストの障害に備えて，マネージャーホストから直接エージェントホストを監視するよう定義したヘルスチェック定義ファイル（jbshc.conf）をあらかじめ用意しておくと便利です。

ページの先頭へ

(5)　一時的な障害で監視エラーが発生する場合の運用方法

ヘルスチェック機能の他ホスト監視では，システムに負荷が掛かったりネットワークに問題が発生したりして，監視対象ホストの監視が失敗した場合，監視元ホスト（マネージャー）に異常を通知します。

ただし，システムやネットワークの障害が一時的な場合，時間を置くことで障害が回復するときもあるため，そのつど監視元ホストに異常を通知したくないケースもあります。そのようなケースでは，異常が発生したと判断するしきい値（監視しきい値）を指定します。監視しきい値には，監視に連続で失敗した回数を指定します。指定した回数に達した場合，監視対象で異常が発生したと判断して，監視元ホストに異常を通知します。

監視しきい値を設定しない場合と監視しきい値に3を設定した場合の動作の違いを次の図に示します。

図2‒39　ヘルスチェック機能の監視しきい値による動作の違い

図に示したように，監視しきい値を設定しない場合は，監視が1回失敗した時点でエラーメッセージを通知します。それに対して，監視しきい値に3を設定した場合は，3回連続で監視に失敗した時点でエラーメッセージを通知します。なお，監視しきい値に1を設定した場合は，監視しきい値を設定しない場合と同じ動作になります。

監視しきい値は，ヘルスチェック定義ファイル（jbshc.conf）で指定できます。なお，監視しきい値を設定すると，「監視間隔×（監視しきい値-1）」秒程度監視対象ホストの異常の検知が遅れます。通常の運用では，監視しきい値は初期設定の1（回）のままで運用してください。監視しきい値を変更する場合は，障害やエラーの発生状況を考慮して値を検討してください。

監視の失敗が一時的な障害であるかどうかは，出力されるメッセージを目安に判断します。目安となるメッセージを次に示します。

1. 監視が失敗したときにKAVA7223-EメッセージまたはKAVA7229-Wメッセージが出力される。

2. そのあとの接続確認で監視ができる状態になって，KAVA7224-Iメッセージが出力される。

上記の順番でメッセージが出力されている場合は，一時的に障害が発生して，そのあと障害が回復したことを示しています。また，監視が失敗した要因としては，監視対象ホストへの接続の失敗，監視対象ホストとのセッションの切断，接続処理や通信処理のタイムアウトなどがあります。要因については，KAVA7223-EメッセージまたはKAVA7229-Wメッセージに出力される詳細情報を確認してください。なお，メッセージの詳細情報を出力するには，ヘルスチェック定義ファイル（jbshc.conf）のERROR_DETAILパラメーターが有効（ON）になっている必要があります。監視が失敗した要因が接続処理または通信処理のタイムアウトの場合は，通信タイムアウト時間の見直しも必要です。

ページの先頭へ

(6)　監視間隔の見直し

他ホストを監視する場合は，ヘルスチェック定義ファイル（jbshc.conf）で監視間隔を指定できます。運用を開始する前に試運転をして，指定した監視間隔が妥当かどうか確認してください。このとき，統合トレースログにKAVA7219-Wのメッセージが出力された場合は，指定した監視間隔が短いおそれがあります。「16.　定義ファイル」の「ヘルスチェック定義ファイル」に記載してある見積もり式を参照して，監視間隔を設定し直してください。

ページの先頭へ

(7)　通信タイムアウト時間の見直し

監視対象ホストのシステム負荷が高い状態の場合，監視対象ホストから監視元ホスト（マネージャー）への他ホスト監視の応答が遅延して，監視に失敗することがあります。そのような場合，マネージャー側の通信タイムアウト時間を調整して，タイムアウトによる監視の失敗を減らすことができます。

通信タイムアウト時間は，ヘルスチェック定義ファイル（jbshc.conf）で指定できます。なお，通信タイムアウト時間を監視間隔よりも長く設定すると，監視間隔の時間内で監視が完了しないおそれがあるため，通信タイムアウト時間は監視間隔よりも短くなるように設定してください。通常の運用では，通信タイムアウト時間は初期設定の60（秒）のままで運用してください。次に示すような状況で処理遅延が発生している場合は，運用状況に合わせて通信タイムアウト時間の見直しを検討してください。

• 一時的または定期的にシステム負荷が高まる。

• システムの限界性能に近い状態で運用している。

通信タイムアウトが発生したかどうかは，監視が失敗したときに出力されるKAVA7223-EメッセージまたはKAVA7229-Wメッセージの詳細情報を確認してください。要因に「接続処理がタイムアウトしました」または「通信処理がタイムアウトしました」が出力されている場合は，通信タイムアウトが発生していることを示します。なお，メッセージの詳細情報を出力するには，ヘルスチェック定義ファイル（jbshc.conf）のERROR_DETAILパラメーターが有効（ON）になっている必要があります。

ページの先頭へ

(8)　監視対象ホストが停止する場合の運用方法

監視元ホストと監視対象ホストにインストールされているJP1/Baseのバージョンが両方とも09-10以降の場合，監視対象ホストの起動・停止を監視するかどうかを選択できます。監視対象ホストの起動・停止を監視すると，運用上計画的にホストが停止する場合，正常に停止したホストはエラーとして通知されません。

監視対象ホストの起動・停止を監視する場合と監視しない場合の動作の違いを次の図に示します。

図2‒40　監視対象ホストの起動・停止を監視する場合と監視しない場合の動作の違い

JP1/Baseが起動・停止した場合，JP1イベントを発行します。監視対象ホストの起動・停止を監視する場合は，監視対象ホストの停止通知イベントを受信すると，KAVA7228-Iメッセージを出力します。この場合，停止通知イベントを受信したあとも，指定された監視間隔で接続確認をしますが，接続できなくても正常な運用と見なし，エラーの通知はしません。

なお，監視元ホストのJP1/Baseが停止中は，監視対象ホストの停止通知イベントを受信できません。そのため，監視元ホストのJP1/Baseが起動後，監視した実績がない監視対象ホストに対して，監視が失敗した場合は，KAVA7229-Wメッセージを出力します。

KAVA7229-W 停止通知を受けていない ホストB に接続できないため監視ができません.

また，監視した実績がある監視対象ホストまたは起動通知イベントを受信した監視対象ホストに対して，監視が失敗した場合は，KAVA7223-Eメッセージを出力します。

KAVA7223-E ホストB に接続できないため監視ができません.

KAVA7229-WメッセージまたはKAVA7223-Eメッセージを出力した監視対象ホストが，接続確認によって監視できる状態になった場合，またはその監視対象ホストから起動通知イベントを受信した場合，KAVA7224-Iメッセージを出力して監視を再開します。

メモ

監視対象ホストの起動・停止を監視する場合は，監視対象ホストで起動通知イベントと停止通知イベントを監視元ホストへ転送する設定が必要です。

一方，監視対象ホストの起動・停止を監視しない場合は，起動または停止通知イベントを受信しても，メッセージを出力しません。この場合，停止通知イベントを受信したあとも，通常の監視をして，接続できない場合はKAVA7223-Eメッセージを出力します。

現在どちらの設定になっているかは，ヘルスチェック（他ホスト監視）を起動したときに出力されるメッセージで確認できます。設定とメッセージIDの対応を次に示します。

設定	メッセージID
監視対象ホストの起動・停止を監視する	KAVA7231-I
監視対象ホストの起動・停止を監視しない	KAVA7230-I

監視対象ホストの起動・停止を監視するかどうかの設定は，ヘルスチェック定義ファイル（jbshc.conf）のSTOP_CHECKパラメーターで変更できます。

ページの先頭へ