4. モニタリソースの詳細

本章では、CLUSTERPRO で監視を実行する単位であるモニタリソースについての詳細を説明します。

4.1. モニタリソースとは?
4.2. モニタ共通のプロパティ
4.3. モニタリソースのプロパティ
4.4. アプリケーションモニタリソースを理解する
4.5. ディスク RW モニタリソースを理解する
4.6. フローティング IP モニタリソースを理解する
4.7. IP モニタリソースを理解する
4.8. ミラーディスクモニタリソースを理解する
4.9. NIC Link Up/Down モニタリソースを理解する
4.10. マルチターゲットモニタリソースを理解する
4.11. レジストリ同期モニタリソースを理解する
4.12. ディスク TUR モニタリソースを理解する
4.13. サービスモニタリソースを理解する
4.14. 仮想コンピュータ名モニタリソースを理解する
4.15. ダイナミックDNSモニタリソースを理解する
4.16. 仮想 IP モニタリソースを理解する
4.17. CIFS モニタリソースを理解する
4.18. ハイブリッドディスクモニタリソースを理解する
4.19. ハイブリッドディスク TUR モニタリソースを理解する
4.20. カスタムモニタリソースを理解する
4.21. 外部連携モニタリソースを理解する
4.22. プロセス名モニタリソースを理解する
4.23. DB2 モニタリソースを理解する
4.24. FTP モニタリソースを理解する
4.25. HTTP モニタリソースを理解する
4.26. IMAP4 モニタリソースを理解する
4.27. ODBC モニタリソースを理解する
4.28. Oracle モニタリソースを理解する
4.29. POP3 モニタリソースを理解する
4.30. PostgreSQL モニタリソースを理解する
4.31. SMTP モニタリソースを理解する
4.32. SQL Server モニタリソースを理解する
4.33. Tuxedo モニタリソースを理解する
4.34. WebSphere モニタリソースを理解する
4.35. WebLogic モニタリソースを理解する
4.36. WebOTX モニタリソースを理解する
4.37. JVMモニタリソースを理解する
4.38. システムモニタリソースを理解する
4.39. プロセスリソースモニタリソースを理解する
4.40. ユーザ空間モニタリソースを理解する
4.41. LB プローブポートモニタリソースを理解する
4.42. AWS Elastic IPモニタリソースを理解する
4.43. AWS 仮想IPモニタリソースを理解する
4.44. AWS セカンダリ IP モニタリソースを理解する
4.45. AWS AZモニタリソースを理解する
4.46. AWS DNS モニタリソースを理解する
4.47. Azure DNS モニタリソースを理解する
4.48. Google Cloud DNS モニタリソースを理解する
4.49. Oracle Cloud セカンダリ IP モニタリソースを理解する
4.50. Oracle Cloud DNS モニタリソースを理解する

4.1. モニタリソースとは?

モニタリソースとは、指定された監視対象を監視するリソースのことを指します。監視対象の異常を検出した場合には、グループリソースの再起動やフェイルオーバなどを行います。

現在サポートされているモニタリソースは以下です。

モニタリソース名	略称	機能概要
アプリケーションモニタ	appliw	「アプリケーションモニタリソースを理解する」を参照
ディスク RW モニタ	diskw	「ディスク RW モニタリソースを理解する」を参照
フローティング IP モニタ	fipw	「フローティング IP モニタリソースを理解する」を参照
IP モニタ	ipw	「 IP モニタリソースを理解する」を参照
ミラーディスクモニタ	mdw	「ミラーディスクモニタリソースを理解する」を参照
NIC Link Up/Down モニタ	miiw	「 NIC Link Up/Down モニタリソースを理解する」を参照
マルチターゲットモニタ	mtw	「マルチターゲットモニタリソースを理解する」を参照
レジストリ同期モニタ	regsyncw	「レジストリ同期モニタリソースを理解する」を参照
ディスク TUR モニタ	sdw	「ディスク TUR モニタリソースを理解する」を参照
サービスモニタ	servicew	「サービスモニタリソースを理解する」を参照
仮想コンピュータ名モニタ	vcomw	「仮想コンピュータ名モニタリソースを理解する」を参照
ダイナミック DNS モニタ	ddnsw	「ダイナミックDNSモニタリソースを理解する」を参照
仮想 IP モニタ	vipw	「仮想 IP モニタリソースを理解する」を参照
CIFS モニタ	cifsw	「 CIFS モニタリソースを理解する」を参照
ハイブリッドディスクモニタ	hdw	「ハイブリッドディスクモニタリソースを理解する」を参照
ハイブリッドディスク TUR モニタ	hdtw	「ハイブリッドディスク TUR モニタリソースを理解する」を参照
カスタムモニタ	genw	「カスタムモニタリソースを理解する」を参照
外部連携モニタ	mrw	「外部連携モニタリソースを理解する」を参照
プロセス名モニタ	psw	「プロセス名モニタリソースを理解する」を参照
DB2 モニタ	db2w	「 DB2 モニタリソースを理解する」を参照
FTP モニタ	ftpw	「 FTP モニタリソースを理解する」を参照
HTTP モニタ	httpw	「 HTTP モニタリソースを理解する」を参照
IMAP4 モニタ	imap4w	「 IMAP4 モニタリソースを理解する」を参照
ODBC モニタ	odbcw	「 ODBC モニタリソースを理解する」を参照
Oracle モニタ	oraclew	「 Oracle モニタリソースを理解する」を参照
POP3 モニタ	pop3w	「 POP3 モニタリソースを理解する」を参照
PostgreSQL モニタ	psqlw	「 PostgreSQL モニタリソースを理解する」を参照
SMTP モニタ	smtpw	「 SMTP モニタリソースを理解する」を参照
SQL Server モニタ	sqlserverw	「 SQL Server モニタリソースを理解する」を参照
Tuxedo モニタ	tuxw	「 Tuxedo モニタリソースを理解する」を参照
WebSphere モニタ	wasw	「 WebSphere モニタリソースを理解する」を参照
WebLogic モニタ	wlsw	「 WebLogic モニタリソースを理解する」を参照
WebOTX モニタ	otxw	「 WebOTX モニタリソースを理解する」を参照
JVM モニタ	jraw	「 JVMモニタリソースを理解する」を参照
システムモニタ	sraw	「システムモニタリソースを理解する」を参照
プロセスリソースモニタ	psrw	「プロセスリソースモニタリソースを理解する」を参照
ユーザ空間モニタ	userw	「ユーザ空間モニタリソースを理解する」を参照
LB プローブポートモニタ	lbppw	「 LB プローブポートモニタリソースを理解する」を参照
AWS Elastic IP モニタ	awseipw	「 AWS Elastic IPモニタリソースを理解する」を参照
AWS 仮想 IP モニタ	awsvipw	「 AWS 仮想IPモニタリソースを理解する」を参照
AWS セカンダリ IP モニタ	awssipw	「 AWS セカンダリ IP モニタリソースを理解する」を参照
AWS AZ モニタ	awsazw	「 AWS AZモニタリソースを理解する」を参照
AWS DNS モニタ	awsdnsw	「 AWS DNS モニタリソースを理解する」を参照
Azure DNS モニタ	azurednsw	「 Azure DNS モニタリソースを理解する」を参照
Google Cloud DNS モニタ	gcdnsw	「 Google Cloud DNS モニタリソースを理解する」を参照
Oracle Cloud セカンダリ IP モニタ	ocsipw	「 Oracle Cloud セカンダリ IP モニタリソースを理解する」を参照
Oracle Cloud DNS モニタ	ocdnsw	「 Oracle Cloud DNS モニタリソースを理解する」を参照

4.1.1. モニタリソースの監視タイミング

モニタリソースによる監視は、常時監視と活性時監視の 2 つのタイプがあります。

モニタリソースによって設定可能な監視タイミングが異なります。

常時

モニタリソースは常に監視を行います。
活性時

特定のグループリソースが活性状態の間、監視を実行します。グループリソースが非活性状態の間は監視を実行しません。

Cluster startup: クラスタ起動

Group activation: グループ活性

Group deactivation: グループ非活性

Stop cluster: クラスタ停止

クラスタ起動からクラスタ停止までのうち、常時監視の区間と活性時監視の区間 — 図 4.1 モニタリソースの常時監視と活性時監視

モニタリソース	監視タイミング	対象リソース
アプリケーションモニタリソース	活性時 (固定)	appli
ディスク RW モニタリソース	常時または活性時	全て
フローティング IP モニタリソース	活性時 (固定)	fip
IP モニタリソース	常時または活性時	全て
ミラーディスクモニタリソース	常時 (固定)	-
NIC Link Up/Down モニタリソース	常時または活性時	全て
マルチターゲットモニタリソース	常時または活性時	全て
レジストリ同期モニタリソース	活性時 (固定)	regsync
ディスク TUR モニタリソース	常時または活性時	sd
サービスモニタリソース	常時または活性時	全て
仮想コンピュータ名モニタリソース	活性時 (固定)	vcom
ダイナミック DNS モニタリソース	活性時 (固定)	ddns
仮想 IP モニタリソース	活性時 (固定)	vip
CIFS モニタリソース	活性時 (固定)	cifs
ハイブリッドディスクモニタリソース	常時 (固定)	-
ハイブリッドディスク TUR モニタリソース	常時または活性時	hd
カスタムモニタリソース	常時または活性時	全て
外部連携モニタリソース	常時 (固定)	-
プロセス名モニタリソース	常時または活性時	全て
DB2 モニタリソース	活性時 (固定)	全て
FTP モニタリソース	活性時 (固定)	全て
HTTP モニタリソース	活性時 (固定)	全て
IMAP4 モニタリソース	活性時 (固定)	全て
ODBC モニタリソース	活性時 (固定)	全て
Oracle モニタリソース	活性時 (固定)	全て
POP3 モニタリソース	活性時 (固定)	全て
PostgreSQL モニタリソース	活性時 (固定)	全て
SMTP モニタリソース	活性時 (固定)	全て
SQL Server モニタリソース	活性時 (固定)	全て
Tuxedo モニタリソース	活性時 (固定)	全て
WebSphere モニタリソース	活性時 (固定)	全て
WebLogic モニタリソース	活性時 (固定)	全て
WebOTX モニタリソース	活性時 (固定)	全て
JVM モニタリソース	常時または活性時	全て
システムモニタリソース	常時 (固定)	全て
プロセスリソースモニタリソース	常時 (固定)	全て
ユーザ空間モニタリソース	常時 (固定)	-
LB プローブポートモニタリソース	活性時 (固定)	lbpp
AWS Elastic IP モニタリソース	活性時 (固定)	awseip
AWS 仮想 IP モニタリソース	活性時 (固定)	awsvip
AWS セカンダリ IP モニタリソース	活性時 (固定)	awssip
AWS AZ モニタリソース	常時 (固定)	-
AWS DNS モニタリソース	活性時 (固定)	awsdns
Azure DNS モニタリソース	活性時 (固定)	azuredns
Google Cloud DNS モニタリソース	活性時 (固定)	gcdns
Oracle Cloud セカンダリ IP モニタリソース	活性時 (固定)	ocsip
Oracle Cloud DNS モニタリソース	活性時 (固定)	ocdns

4.1.2. モニタリソースの擬似障害発生/解除

モニタリソースは擬似的に障害を発生させることが可能です。また、それを解除することもできます。擬似障害の発生/解除を行う方法は以下の 2 つの方法があります。

Cluster WebUI (検証モード) による操作

Cluster WebUI (検証モード) では、制御が不可能なモニタリソースの操作が無効になります。
[clpmonctrl] コマンドによる操作

[clpmonctrl] コマンドでは、コマンドの実行サーバ、または指定したサーバのモニタリソースに対して制御を行います。制御が不可能なモニタリソースに対して実行した場合、コマンドの実行自体は成功しますが、擬似障害を発生させることはできません。

モニタリソースには、擬似障害の発生/解除が可能なものと不可能なものがあります。本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「モニタリソースを制御する (clpmonctrl コマンド)」を参照してください。

擬似障害発生状態で下記の操作を行った場合、モニタリソースの擬似障害が解除されます。

Cluster WebUI (検証モード) で、モニタリソースの [擬似障害解除] を実行した場合
Cluster WebUI のモードを、[検証モード] から他のモードに変更する際に出力されるダイアログで [解除] を選択した場合
clpmonctrlコマンドに -nオプションを指定した場合
クラスタを停止した場合
クラスタをサスペンドした場合

4.1.3. モニタリソースの監視インターバルのしくみ

全てのモニタリソースは、監視インターバル毎に監視が行われます。

以下は、この監視インターバルの設定による正常または、異常時におけるモニタリソースへの監視の流れを時系列で表した説明です。

監視正常検出時

図は、クラスタ起動後に監視を開始または再開した際の動作を表しています。監視メインプロセス（Main monitoring process）が監視結果を受け取ると、監視インターバル（Monitor interval）の時間を空けて、繰り返し、監視が起動されます。

下記の値が設定されている場合の挙動の例：

<監視>
監視インターバル 30 秒
監視タイムアウト 60 秒
監視リトライ回数 0 回

監視メインプロセスと監視サブプロセス、および監視インターバル — 図 4.2 監視インターバル（監視正常検出時）

監視異常検出時 (監視リトライ設定なし)

図は、監視対象（Monitor target）で異常が発生し、それが検出された後の動作を表しています。監視メインプロセス（Main monitoring process）が監視結果（異常）を受け取ると、回復対象グループに対してフェイルオーバを実行します。

監視異常発生後、次回監視で監視異常を検出し回復対象に対してフェイルオーバが行われます。

下記の値が設定されている場合の挙動の例：

<監視>
監視インターバル 30 秒
監視タイムアウト 60 秒
監視リトライ回数 0 回

<異常検出>
回復対象 グループ
回復スクリプト実行回数 0 回
最大再活性回数 0 回
最大フェイルオーバ回数 1 回
最終動作 何もしない

監視異常検出時 (監視リトライ設定あり)

図は、監視対象（Monitor target）で異常が発生し、それが検出された後の動作を表しています。監視メインプロセス（Main monitoring process）が監視結果（異常）を受け取ると、設定された監視リトライ回数に達するまで、監視動作を実行します。それでも監視対象が回復しない場合、回復対象グループに対してフェイルオーバを実行します。

監視異常発生後、次回監視で監視異常を検出し監視リトライ以内で回復しなければ、回復対象に対してフェイルオーバが行われます。

下記の値が設定されている場合の挙動の例：

<監視>
監視インターバル 30 秒
監視タイムアウト 60 秒
監視リトライ回数 2 回

<異常検出>
回復対象 グループ
回復スクリプト実行回数 0 回
最大再活性回数 0 回
最大フェイルオーバ回数 1 回
最終動作 何もしない

監視タイムアウト検出時 (監視リトライ設定なし)

図は、設定された時間内に監視処理が終わらなかった場合の動作を表しています。監視メインプロセス（Main monitoring process）が監視を起動した後、監視タイムアウトに設定された時間内に監視結果が得られなかった場合、回復対象グループに対してフェイルオーバを実行します。

監視タイムアウト発生後、直ぐに回復対象への回復動作に対してフェイルオーバが行われます。

下記の値が設定されている場合の挙動の例：

<監視>
監視インターバル 30 秒
監視タイムアウト 60 秒
監視リトライ回数 0 回

<異常検出>
回復対象 グループ
回復スクリプト実行回数 0 回
最大再活性回数 0 回
最大フェイルオーバ回数 1 回
最終動作 何もしない

監視タイムアウト検出時 (監視リトライ設定あり)

図は、設定された時間内に監視処理が終わらなかった場合の動作を表しています。監視メインプロセス（Main monitoring process）が監視を起動した後、監視タイムアウトに設定された時間内に監視結果が得られなかった場合、設定された監視リトライ回数に達するまで、監視動作を実行します。それでも監視結果が得られなかった場合、回復対象グループに対してフェイルオーバを実行します。

監視タイムアウト発生後、監視リトライを行い回復対象に対してフェイルオーバが行われます。

下記の値が設定されている場合の挙動の例：

<監視>
監視インターバル 30 秒
監視タイムアウト 60 秒
監視リトライ回数 1 回

<異常検出>
回復対象 グループ
回復スクリプト実行回数 0 回
最大再活性回数 0 回
最大フェイルオーバ回数 1 回
最終動作 何もしない

4.1.4. モニタリソースによる異常検出時の動作

異常検出時には回復対象に対して以下の回復動作が行われます。

監視対象の異常を検出すると回復スクリプトを実行します。
回復スクリプト実行回数の回復スクリプト実行後、回復対象の再活性化を行います。再活性前スクリプト実行が設定されている場合はスクリプトを実行後に再活性化を行います。
再活性化しきい値の再活性化に失敗した場合、フェイルオーバを行います。フェイルオーバ前スクリプト実行が設定されている場合はスクリプトを実行後にフェイルオーバを行います。
最大フェイルオーバ回数のフェイルオーバを行っても異常を検出する場合、最終動作を行います。(フェイルオーバ回数は、回復対象がグループリソースまたはフェイルオーバグループの場合、クラスタ内で共有され、回復対象が All Groups の場合、サーバ毎にカウントされます。) 最終動作前スクリプト実行が設定されている場合はスクリプトを実行後に最終動作を行います。

回復動作が実行されるか否かは、回復対象の状態によって変わります。

回復対象	状態	再活性化 [1]	フェイルオーバ [2]	最終動作 [3]
グループリソース/ フェイルオーバグループ	停止済	No	No	No
〃	起動/停止中	No	No	No
〃	起動済	Yes	Yes	Yes
〃	異常	Yes	Yes	Yes
LocalServer	-	-	-	Yes

Yes：回復動作が行われる No：回復動作が行われない

注釈

モニタリソースの異常検出時の設定で回復対象にグループリソース (ディスクリソース、アプリケーションリソースなど) を指定し、モニタリソースが異常を検出した場合の回復動作遷移中 (再活性化 → フェイルオーバ → 最終動作) には、Cluster WebUI やコマンドによる以下の操作は行わないでください。

クラスタの停止/サスペンド

グループの起動/停止/移動

モニタリソース異常による回復動作遷移中に上記の制御を行うと、そのグループの他のグループリソースが停止しないことがあります。
また、モニタリソース異常状態であっても最終動作実行後であれば上記制御を行うことが可能です。
[フェイルオーバ回数のカウント単位] が"サーバ"の場合
モニタリソースの状態が異常から復帰 (正常) した場合は、再活性化回数、フェイルオーバ回数、最終動作の実行要否はリセットされます。

[フェイルオーバ回数のカウント単位] が"クラスタ"の場合

モニタリソースの状態が異常から復帰 (正常) した場合は、再活性化回数、フェイルオーバ回数、最終動作の実行要否はリセットされます。ただし、回復対象としてグループリソース/フェイルオーバグループが指定されている場合は、同一の回復対象が指定されている全てのモニタリソースの状態が正常状態になった場合のみ、これらのカウンタがリセットされます。
回復動作の再活性化回数およびフェイルオーバ回数は、回復動作に失敗した場合でも 1 回としてカウントされることに注意してください。

以下は、IP モニタリソースの IP アドレスとしてゲートウェイを指定した場合で片サーバのみ異常を検出する時の流れを説明します。

下記の値が設定されている場合の挙動の例：

<監視>
インターバル 30 秒
タイムアウト 30 秒
リトライ回数 3 回

<異常検出>
回復対象 フェイルオーバグループ A
回復スクリプト実行回数 3 回
最大再活性回数 3 回
最大フェイルオーバ回数 サーバ数に合わせる (以下のケースでは 2 回)
最終動作 何もしない

図は、2台のサーバにおいてIPモニタリソースが監視を行う場合の例です。IP monitor resource 1は、インターバル毎にGatewayのIPアドレスに対して、生存確認を行います。

図 4.7 IP モニタリソース異常検出の流れ（片サーバのみ異常検出） (1)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

0

0

再活性化回数

0

0

フェイルオーバ回数

0

0
IP monitor resource 1の監視が異常を検出しました（LANケーブルの断線、NICの故障など）。

図 4.8 IPモニタリソース異常検出の流れ（片サーバのみ異常検出） (2)
IP monitor resource 1は監視を3回までリトライします。

図 4.9 IPモニタリソース異常検出の流れ（片サーバのみ異常検出） (3)
監視リトライオーバした場合、Server 1で回復スクリプトの実行を開始します。

"回復スクリプト実行回数" は各サーバでの回復スクリプトの実行回数です。

これはServer 1での1回目の回復スクリプト実行です。

Server 2では、Failover group Aが "停止済" のため、回復動作は行われません。

図 4.10 IPモニタリソース異常検出の流れ（片サーバのみ異常検出） (4)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

0

0

フェイルオーバ回数

0

0
Server 1で回復スクリプト実行回数を超えた場合、Server 1でFailover group Aの再活性処理を開始します。

"再活性化回数" は各サーバでの再活性化の回数を表しています。

これは Server 1での1回目の再活性化処理です。

図 4.11 IPモニタリソース異常検出の流れ（片サーバのみ異常検出） (5)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

3

0

フェイルオーバ回数

0

0
Server 1で再活性化しきい値を超えた場合、Server 1で Failover group Aのフェイルオーバ処理を開始します。

"フェイルオーバしきい値" は各サーバでのフェイルオーバの回数を表しています。

これは Server 1での1回目のフェイルオーバ処理です。

図 4.12 IPモニタリソース異常検出の流れ（片サーバのみ異常検出） (6)
Failover group AをServer 1からServer 2へフェイルオーバします。

Server 2でFailover group Aのフェイルオーバ処理を完了します。

図 4.13 IPモニタリソース異常検出の流れ（片サーバのみ異常検出） (7)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

3

0

フェイルオーバ回数

1

1

サーバ 2 では、IP モニタリソース 1 が正常なのでフェイルオーバグループ A がフェイルオーバすることにより運用を継続することができます。

以下は、IP モニタリソースの IP アドレスとしてゲートウェイを指定した場合で、両サーバが異常を検出する時の流れを説明します。

下記の値が設定されている場合の挙動の例：

<監視>
インターバル 30 秒
タイムアウト 30 秒
リトライ回数 3 回

<異常検出>
回復対象 フェイルオーバグループ A
回復スクリプト実行回数 3 回
最大再活性回数 3 回
最大フェイルオーバ回数 サーバ数に合わせる (以下のケースでは 2 回)
最終動作 何もしない

図は、2台のサーバにおいてIPモニタリソースが監視を行う場合の例です。

IP monitor resource 1は、インターバル毎にGatewayのIPアドレスに対して、生存確認を行います。

図 4.14 IP モニタリソース異常検出の流れ（両サーバで異常検出） (1)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

0

0

再活性化回数

0

0

フェイルオーバ回数

0

0
Server 1、Server 2で、IP monitor resource 1の監視が異常を検出しました（LANケーブルの断線、NICの故障など）

図 4.15 IP モニタリソース異常検出の流れ（両サーバで異常検出） (2)
IP monitor resource 1は監視を3回までリトライします。

図 4.16 IP モニタリソース異常検出の流れ（両サーバで異常検出） (3)
監視リトライオーバした場合、Server 1で回復スクリプトの実行を開始します。

"回復スクリプト実行回数" は各サーバでの回復スクリプトの実行回数です。

これはServer 1での1回目の回復スクリプト実行です。

Server 2では、Failover group Aが "停止済" のため、回復動作は行われません。

図 4.17 IP モニタリソース異常検出の流れ（両サーバで異常検出） (4)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

0

0

フェイルオーバ回数

0

0
Server 1で回復スクリプト実行回数を超えた場合、Server 1でFailover group Aの再活性処理を開始します。

"再活性化回数" は各サーバでの再活性化の回数を表しています。

これは Server 1での1回目の再活性化処理です。

Server 2では、Failover group Aが "停止済" のため、回復動作は行われません。

図 4.18 IP モニタリソース異常検出の流れ（両サーバで異常検出） (5)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

3

0

フェイルオーバ回数

0

0
Server 1で再活性化しきい値を超えた場合、Server 1で Failover group Aのフェイルオーバ処理を開始します。

"フェイルオーバしきい値" は各サーバでのフェイルオーバの回数を表しています。

これは Server 1での1回目のフェイルオーバ処理です。

Server 2では、Failover group Aが "停止済" のため、回復動作は行われません。

図 4.19 IP モニタリソース異常検出の流れ（両サーバで異常検出） (6)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

3

0

フェイルオーバ回数

1

1
Failover group AをServer 1からServer 2へフェイルオーバします。

Server 2で IP monitor resource 1の監視異常が継続しています。

図 4.20 IP モニタリソース異常検出の流れ（両サーバで異常検出） (7)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

3

0

フェイルオーバ回数

1

1
IP monitor resource 1は監視を3回までリトライします。

図 4.21 IP モニタリソース異常検出の流れ（両サーバで異常検出） (8)
IP monitor resource 1が監視リトライオーバした場合、異常が継続すれば回復スクリプト実行を3回までリトライします。

図 4.22 IP モニタリソース異常検出の流れ（両サーバで異常検出） (9)
Server 2でも回復スクリプト実行処理でリトライオーバした場合、異常が継続すれば Failover group Aの再活性処理を 3回までリトライします。

図 4.23 IP モニタリソース異常検出の流れ（両サーバで異常検出） (10)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

3

再活性化回数

3

3

フェイルオーバ回数

1

1

Server 2で再活性化処理でリトライオーバした場合、Server 2で Failover group Aのフェイルオーバ処理を開始します。

これは Server 2での1回目のフェイルオーバ処理です。

図 4.24 IP モニタリソース異常検出の流れ（両サーバで異常検出） (11)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

3

再活性化回数

3

3

フェイルオーバ回数

2

2

Failover group AをServer 2からServer 1へフェイルオーバします。

Server 1で IP monitor resource 1の監視異常が継続します。

図 4.25 IP モニタリソース異常検出の流れ（両サーバで異常検出） (12)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

3

再活性化回数

3

3

フェイルオーバ回数

2

2

Server 1でIP monitor resource 1の監視を3回までリトライします。

図 4.26 IP モニタリソース異常検出の流れ（両サーバで異常検出） (13)

Server 1において、再度Disk monitor resource 1の監視でリトライオーバした場合、再活性化しきい値が3であるため、再活性処理は実行しません。

また、フェイルオーバしきい値が1なのでフェイルオーバ処理も実行せず、最終動作に設定された動作を開始します。

Server 1で IP monitor resource 1の最終動作を開始します。

"最終動作" はフェイルオーバがリトライオーバした後の動作です。

図 4.27 IP モニタリソース異常検出の流れ（両サーバで異常検出） (14)

【補足】

監視しているサーバでモニタリソースが異常から正常に状態変化すると、再活性化回数とフェイルオーバ回数は 0 にリセットされ、次回監視異常時には同様に回復動作を行います。

4.1.5. 監視異常からの復帰 (正常)

監視異常を検出し、回復動作遷移中または全ての回復動作を完了後にモニタリソースの復帰を検出すると、そのモニタリソースが保持している以下のしきい値に対する回数カウンタはリセットされます。ただし、回復対象としてグループリソース/フェイルオーバグループが指定されている場合は、同一の回復対象が指定されている全てのモニタリソースの状態が正常状態になった場合のみ、これらのカウンタがリセットされます。

再活性回数

フェイルオーバ回数

最終動作については、実行要否がリセット (実行要に) されます。

以下は「モニタリソースによる異常検出時の動作」の最終動作実行後から監視が正常に復帰し、再度監視が異常になる流れを説明します。

[設定例]

<監視>
インターバル 30 秒
タイムアウト 30 秒
リトライ回数 3 回

<異常検出>
回復対象 フェイルオーバグループ A
回復スクリプト実行回数 3 回
最大再活性回数 3 回
最大フェイルオーバ回数 サーバ数に合わせる (以下のケースでは 2 回)
最終動作 何もしない
を指定している場合の挙動の例

図は、2台のサーバにおいてIPモニタリソースが監視を行う場合の例です。

回復動作を全て実行後、監視異常が継続しています。

Server 1は IP monitor resource 1の最終動作実行済の状態です。

図 4.28 IPモニタリソース異常検出の流れ（監視異常からの復帰・正常） (1)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

3

再活性化回数

3

3

フェイルオーバ回数

2

2
Gatewayが復旧した場合、IP monitor resource 1の監視が正常を検出します。

図 4.29 IPモニタリソース異常検出の流れ（監視異常からの復帰・正常） (2)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

0

0

再活性化回数

0

0

フェイルオーバ回数

0

0

監視対象リソースが正常になったことを検出したため、再活性化回数およびフェイルオーバ回数はリセットされます。
再度、IP monitor resource 1の監視が異常を検出した場合です。

図 4.30 IPモニタリソース異常検出の流れ（監視異常からの復帰・正常） (3)
IP monitor resource 1の監視を3回までリトライします。

"リトライ回数" は、このサーバでのリトライ回数です。

図 4.31 IPモニタリソース異常検出の流れ（監視異常からの復帰・正常） (4)

Server 1

IP monitor resource 1

回復スクリプト実行回数

0

再活性化回数

0

フェイルオーバ回数

0
監視リトライオーバした場合、Server 1で回復スクリプト実行処理を開始します。 "回復スクリプト実行回数" は各サーバでの回復スクリプトの実行回数です。これはServer 1での1回目の回復スクリプト実行処理です。 Server 2では、Failover group Aが "停止済" のため、回復動作は行われません。

図 4.32 IPモニタリソース異常検出の流れ（監視異常からの復帰・正常） (5)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

0

0

フェイルオーバ回数

0

0
Server 1で回復スクリプト実行回数を超えた場合、Server 1でFailover group Aの再活性処理を開始します。

"再活性化回数" は各サーバでの再活性化の回数です。

これは Server 1での1回目の再活性化処理です。

以前に監視対象リソースが正常になったことを検出して再活性化回数がリセットされているため再度、再活性化処理を行います。

図 4.33 IPモニタリソース異常検出の流れ（監視異常からの復帰・正常） (6)

Server 1

IP monitor resource 1

Server 2

IP monitor resource 1

回復スクリプト実行回数

3

0

再活性化回数

3

0

フェイルオーバ回数

0

0

4.1.6. 回復動作時の回復対象活性/非活性異常

モニタリソースの監視先と回復対象のグループリソースが同一のデバイスの場合で監視異常を検出すると、回復動作中にグループリソースの活性/非活性異常を検出する場合があります。

以下はディスク TUR モニタリソースの監視先とフェイルオーバグループ A のディスクリソースを同一デバイスに指定した場合の回復動作の流れを説明します。

[ディスク TUR モニタリソースの設定例]

<監視>
インターバル 60 秒
タイムアウト 120 秒
リトライ回数 0 回

<異常検出>
回復対象 フェイルオーバグループ A
回復スクリプト実行回数 0 回
最大再活性回数 0 回
最大フェイルオーバ回数 サーバ数に合わせる (以下のケースでは 2 回)
最終動作 グループ停止

[フェイルオーバグループ A : ディスクリソースの設定例]

<活性異常>
活性リトライしきい値 0 回
フェイルオーバしきい値 サーバ数に合わせる (以下のケースでは 2 回)
最終動作 何もしない (次のリソースを活性しない)

<非活性異常>
非活性リトライしきい値 0 回
最終動作 クラスタサービス停止と OS シャットダウン
モニタリソースの最大再活性回数とグループリソースの活性リトライしきい値は、共に設定 回数が 0 回のため遷移図内では省略します。

図は、2台のサーバにおいてディスクTURモニタリソースが監視を行う場合の例です。 Server 1、Server 2で Disk TUR monitor resource 1、Failover group Aの活性処理を開始します。インターバル毎にデバイスへTURのioctlを実行します。

図 4.34 ディスクTURモニタリソース異常検出の流れ (1)

Server 1

Server 2

Disk TUR monitor resource 1

フェイルオーバ回数

0

0

Disk resource 1

フェイルオーバ回数

0

0
Server 1、Server 2で Disk TUR monitor resource 1の監視が異常（TURのioctlに失敗）を検出しました。

ディスクデバイスの障害箇所によっては、ディスクリソースの非活性処理で異常を検出する場合があります。

図 4.35 ディスクTURモニタリソース異常検出の流れ (2)
Server 1でDisk TUR monitor resource 1の監視異常により、Failover group Aのフェイルオーバ処理を開始します。

モニタリソースのフェイルオーバしきい値は、各サーバでのフェイルオーバの回数です。

これはServer 1での一回目のフェイルオーバ処理です。

図 4.36 ディスクTURモニタリソース異常検出の流れ (3)

Server 1

Server 2

Disk TUR monitor resource 1

フェイルオーバ回数

1

1

Disk resource 1

フェイルオーバ回数

0

0
Server 2でフェイルオーバ処理によるDisk resource 1の活性に失敗しました。

図 4.37 ディスクTURモニタリソース異常検出の流れ (4)
Server 2でDisk resource 1の活性異常により、Failover group Aのフェイルオーバ処理を開始します。

グループリソースのフェイルオーバしきい値は、各サーバでのフェイルオーバの回数です。

これはServer 2での一回目のフェイルオーバ処理です。

ディスクデバイスの障害箇所によっては、ディスクリソースの非活性処理で異常を検出する場合があります。

図 4.38 ディスクTURモニタリソース異常検出の流れ (5)

Server 1

Server 2

Disk TUR monitor resource 1

フェイルオーバ回数

1

1

Disk resource 1

フェイルオーバ回数

1

1

サーバ 2 でもサーバ 1 と同様にディスク TUR モニタリソース 1 の異常を検出していますが、回復対象である "フェイルオーバグループ A" が起動中のため回復動作は行われません。

モニタリソースが回復対象に対して回復動作を行う条件については、「モニタリソースによる異常検出時の動作」を参照してください。
Server 1でフェイルオーバ処理によるDisk resource 1の活性に失敗しました。

ディスクデバイスの障害箇所によっては、ディスクリソースの非活性処理で異常を検出する場合があります。

図 4.39 ディスクTURモニタリソース異常検出の流れ (6)

Server 1

Server 2

Disk TUR monitor resource 1

フェイルオーバ回数

1

1

Disk resource 1

フェイルオーバ回数

1

1
Server 1でDisk resource 1の活性異常により Failover group Aのフェイルオーバ処理を開始します。

これは Server 1での一回目のフェイルオーバ処理です。

図 4.40 ディスクTURモニタリソース異常検出の流れ (7)"

Server 1

Server 2

Disk TUR monitor resource 1

フェイルオーバ回数

1

1

Disk resource 1

フェイルオーバ回数

2

2
Server 2でフェイルオーバ処理によるDisk resource 1の活性に失敗しました。

ディスクデバイスの障害箇所によっては、ディスクリソースの非活性処理で異常を検出する場合があります。

図 4.41 ディスクTURモニタリソース異常検出の流れ (8)

サーバ 2 では、ディスクリソース 1 の活性異常によるフェイルオーバ回数がしきい値を超えているため、最終動作を実行します。

ただし、最終動作には "何もしない (次のリソースを活性しない)" が設定されているため、フェイルオーバグループ A の残りのグループリソースは活性されず、起動処理は異常終了となります。
Server 2でDisk resource 1の活性異常により最終動作を実行しました。

フェイルオーバグループAは活性異常状態です。

ディスクデバイスの障害箇所によっては、ディスクリソースの非活性処理で異常を検出する場合があります。

図 4.42 ディスクTURモニタリソース異常検出の流れ (9)
Server 2でDisk TUR monitor resource 1の監視異常によりFailover group Aのフェイルオーバ処理を開始します。

これはServer 2での1回目のフェイルオーバ処理です。

図 4.43 ディスクTURモニタリソース異常検出の流れ (10)

Server 1

Server 2

Disk TUR monitor resource 1

フェイルオーバ回数

2

2

Disk resource 1

フェイルオーバ回数

2

2

Server 1でフェイルオーバ処理によるDisk resource 1の活性に失敗しました。

図 4.44 ディスクTURモニタリソース異常検出の流れ (11)

サーバ 1 でもサーバ 2 と同様に、ディスクリソース 1 の活性異常によるフェイルオーバ回数がしきい値を超えているため、最終動作を実行します。

ただし、最終動作には "何もしない (次のリソースを活性しない)" が設定されているため、フェイルオーバグループ A の残りのグループリソースは活性されず、起動処理は異常終了となります。

ディスクデバイスの障害箇所によっては、ディスクリソースの非活性処理で異常を検出する場合があります。

Server 1でDisk TUR monitor resource 1の監視異常によりFailover group Aの最終動作（グループ停止）処理を開始します。

サーバ 1 では、ディスク TUR モニタリソース 1 の監視異常によるフェイルオーバ回数がしきい値を超えているため、最終動作を実行します。

図 4.45 ディスクTURモニタリソース異常検出の流れ (12)

サーバ 1 で実行されたディスク TUR モニタリソース 1 の最終動作によりフェイルオーバグループ A が停止したため、これ以降でディスク TUR モニタリソース 1 の監視異常を検出しても何も起こりません。

ただし、サーバ 2 ではディスク TUR モニタリソース 1 の最終動作がまだ実行されていないため、フェイルオーバグループ A を手動で起動した場合は、ディスク TUR モニタリソース 1の最終動作が実行されます。

4.1.7. 回復スクリプト、回復動作前スクリプトについて

モニタリソースの異常検出時に、回復スクリプトを実行させることが可能です。また、回復対象の再活性化、フェイルオーバ、最終動作を実行する前に回復動作前スクリプトを実行させることも可能です。

いずれの場合でも共通のスクリプトファイルが実行されます。

回復スクリプト、回復動作前スクリプトで使用する環境変数

CLUSTERPRO はスクリプトを実行する場合に、どの状態で実行したか (回復動作種別) などの情報を環境変数にセットします。

スクリプト内で下図の環境変数を分岐条件として、システム運用にあった処理内容を記述できます。

環境変数	環境変数の値	意味
CLP_MONITORNAME …モニタリソース名	モニタリソース名	回復スクリプト、回復動作前スクリプトを実行する原因となる異常を検出したモニタリソース名を示します。
CLP_VERSION_FULL …CLUSTERPROフルバージョン	CLUSTERPROフルバージョン	CLUSTERPROのフルバージョンを示す。（例） 14.00
CLP_VERSION_MAJOR …CLUSTERPROメジャーバージョン	CLUSTERPROメジャーバージョン	CLUSTERPROのメジャーバージョンを示す。（例）14
CLP_PATH …CLUSTERPROインストールパス	CLUSTERPROインストールパス	CLUSTERPROがインストールされているパスを示す。（例）C:\Program Files\CLUSTERPRO
CLP_OSNAME ……サーバOS名	サーバOS名	スクリプトが実行されたサーバのOSを示す。（例）Windows Server 2019 Standard
CLP_OSVER …サーバOSバージョン	サーバOSバージョン	スクリプトが実行されたサーバのOSバージョンを示す。（例）10.0.14393
CLP_ACTION …回復動作種別	RECOVERY	回復スクリプトとして実行された場合。
〃	RESTART	再起動前に実行された場合。
〃	FAILOVER	フェイルオーバ前に実行された場合。
〃	FINALACTION	最終動作前に実行された場合。
CLP_RECOVERYCOUNT …回復スクリプトの実行回数	回復スクリプト実行回数	何回目の回復スクリプト実行回数かを示す。
CLP_RESTARTCOUNT …再活性化回数	再活性化回数	何回目の再活性化回数かを示す。
CLP_FAILOVERCOUNT …フェイルオーバ回数	フェイルオーバ回数	何回目のフェイルオーバ回数かを示す。

回復スクリプト、回復動作前スクリプトの記述の流れ

前のトピックの、環境変数と実際のスクリプト記述を関連付けて説明します。

回復スクリプト、回復動作前スクリプトの一例

rem ******************************************************
rem *                    preaction.bat                   *
rem ******************************************************

echo START

IF "%CLP_ACTION%"=="" GOTO NO_CLP

IF "%CLP_ACTION%"=="RECOVERY" GOTO RECOVERY
IF "%CLP_ACTION%"=="RESTART" GOTO RESTART
IF "%CLP_ACTION%"=="FAILOVER" GOTO FAILOVER
IF "%CLP_ACTION%"=="FINALACTION" GOTO FINALACTION


:RECOVERY
echo RECOVERY COUNT: %CLP_RECOVERYCOUNT%

rem ここに回復処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem  回復動作：回復スクリプト

GOTO EXIT


:RESTART
echo RESTART COUNT: %CLP_RESTARTCOUNT%

rem ここに再活性化前処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem  回復動作：再活性化

GOTO EXIT


:FAILOVER
echo FAILOVER COUNT: %CLP_FAILOVERCOUNT%

rem ここに回復処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem  回復動作：フェイルオーバ

GOTO EXIT


:FINALACTION
echo FINALACTION

rem ここに回復処理を記述する。
rem この処理は以下のタイミングで実行される。
rem
rem  回復動作：最終動作

:NO_CLP

:EXIT
echo EXIT
exit

回復スクリプト、回復動作前スクリプト作成のヒント

以下の点に注意して、スクリプトを作成してください。

スクリプト中にて、実行に時間を必要とするコマンドを実行する場合には、コマンドの実行が完了したことを示すトレースを残すようにしてください。この情報は、問題発生時、障害の切り分けを行う場合に使用することができます。clplogcmdを使用してトレースを残す方法があります。

回復スクリプト、回復動作前スクリプト注意事項

最終動作時の回復動作前スクリプトが実行される条件について

最終動作時の回復動作前スクリプトはモニタの監視異常による最終動作の前に実行されます。最終動作に [何もしない] が設定されている場合にも、回復動作前スクリプトは実行されます。

最大再起動回数や、モニタリソースの回復動作の抑制機能、他のサーバが全て停止している場合の最終動作抑制機能によって最終動作が実行されない場合は、回復動作前スクリプトは実行されません。

4.1.8. モニタリソースの遅延警告

モニタリソースは、業務アプリケーションの集中などにより、サーバが高負荷状態になり監視タイムアウトを検出する場合があります。監視タイムアウトを検出する前に監視の監視処理時間 (実測時間) が監視タイムアウト時間の何割かに達した場合、アラート通報させることが可能です。

以下は、モニタリソースが遅延警告されるまでの流れを時系列で表した説明です。

監視タイムアウトに 60 秒、遅延警告割合には、既定値の 80% を指定します。

図は監視タイムアウトに 60 秒、遅延警告割合には既定値の 80%（48秒）を指定した場合です。矢印は監視のポーリング時間を表しています。

モニタリソースが遅延警告されるまでの時間 — 図 4.46 監視ポーリング時間と遅延警告

監視の監視処理時間は 10 秒で、モニタリソースは正常状態です。

この場合、アラート通報は行いません。
監視の監視処理時間は 50 秒で、監視の遅延を検出し、モニタリソースは正常状態です。

この場合、遅延警告割合の 80% を超えているためアラート通報を行います。
監視の監視処理時間は監視タイムアウト時間の 60 秒を越え、監視タイムアウトを検出し、モニタリソースは異常状態です。

この場合、アラート通報は行いません。

ハートビートリソースについても同様にハートビートの遅延警告をアラート通報します。

参考

モニタリソースの遅延警告は [クラスタのプロパティ]→[遅延警告] タブの [モニタ遅延警告] で設定します。詳細は本ガイドの「2. パラメータの詳細」を参照してください。

4.1.9. モニタリソースの監視開始待ち

監視開始待ちとは、監視を指定した監視開始待ち時間後から開始することをいいます。

以下は、監視開始待ちを 0 秒に指定した場合と 30 秒に指定した場合の監視の違いを時系列で表した説明です。

監視開始待ち時間が0秒の場合、クラスタ起動または監視再開後にモニタリソースポーリングを開始します。

[モニタリソース構成]

<監視>
インターバル 30 秒
タイムアウト 60 秒
リトライ回数 0 回
監視開始待ち時間 0 秒

監視開始待ち時間毎の挙動の違い — 図 4.47 モニタリソースの監視開始待ち（監視開始待ち時間0秒）

監視開始待ち時間が30秒の場合、クラスタ起動または監視再開後に30秒待ってからモニタリソースポーリングを開始します。

[モニタリソース構成]

<監視>
インターバル 30 秒
タイムアウト 60 秒
リトライ回数 0 回
監視開始待ち時間 30 秒

注釈

監視制御コマンドによるモニタリソースの一時停止/再開を行った場合も、指定された監視開始待ち時間後に再開します。

注釈

外部連携モニタリソースでは監視開始待ち時間機能は機能しません。

監視開始待ち時間は、アプリケーションモニタリソースが監視するアプリケーションリソースのようにアプリケーションの設定ミスなどにより監視開始後すぐに終了する可能性があり、再活性化では回復できない場合に使用します。

たとえば、以下のように監視開始待ち時間を 0 に設定すると回復動作を無限に繰り返す場合があります。

このケースにおいて、アプリケーションは一旦起動します。さらにアプリケーションモニタリソースによる監視が開始され、アプリケーションモニタリソースによるポーリングが一度正常終了します。しかしその後、アプリケーションは何らかの理由で異常終了します。

[アプリケーションモニタリソース構成]

<監視>
インターバル 5 秒
タイムアウト 60 秒
リトライ回数 0 回
監視開始待ち時間 0 秒 (既定値)

<異常検出>
回復対象 appli1
最大再活性回数 1 回
最大フェイルオーバ回数 1 回
最終動作 グループ停止

アプリケーションリソース、アプリケーションモニタリソース、アプリケーションの動作の推移 — 図 4.49 モニタリソースの監視開始待ち（監視開始待ち時間0秒）

この回復動作を無限に繰り返す原因は、初回の監視処理が正常終了することにあります。モニタリソースの回復動作の現在回数は、モニタリソースが正常状態になればリセットされます。そのため、現在回数が常に 0 リセットされ再活性化の回復動作を無限に繰り返すことになります。

上記の現象は、監視開始待ち時間を設定することで回避できます。

監視開始待ち時間には、アプリケーションが起動後、終了しうる時間として既定値で 60 秒を設定しています。

このケースにおいて、アプリケーションは一旦起動します。その後、設定された開始監視待ち時間待ちあわせた後に、アプリケーションモニタリソースによる監視が開始されます。その後、アプリケーションは何らかの理由で異常終了しますが、それはアプリケーション監視による初回のポーリングで検出されます。

[アプリケーションモニタリソース構成]

<監視>
インターバル 5 秒
タイムアウト 60 秒
リトライ回数 0 回
監視開始待ち時間 60 秒

<異常検出>
回復対象 appli1
最大再活性回数 1 回
最大フェイルオーバ回数 1 回
最終動作 グループ停止

グループのフェイルオーバ先のサーバでもアプリケーションが異常終了した場合、最終動作としてグループ停止を行います。

4.1.10. モニタリソース異常検出時の再起動回数制限

モニタリソース異常検出時の最終動作として [クラスタサービス停止とOSシャットダウン]、または [クラスタサービス停止と OS 再起動] を設定している場合に、モニタリソース異常の検出によるシャットダウン回数、または再起動回数を制限することができます。

注釈

再起動回数はサーバごとに記録されるため、最大再起動回数はサーバごとの再起動回数の上限になります。

また、グループ活性、非活性異常検出時の最終動作による再起動回数とモニタリソース異常の最終動作による再起動回数も別々に記録されます。

最大再起動回数をリセットする時間に 0 を設定した場合には、再起動回数はリセットされません。

以下の設定例で再起動回数制限の流れを説明します。

最大再起動回数が 1 回に設定されているため、一度だけ最終動作である [クラスタサービス停止と OS 再起動] が実行されます。

また、最大再起動回数をリセットする時間が 10 分に設定されているため、クラスタシャットダウン後再起動時にモニタリソースの正常状態が 10 分間継続した場合には、再起動回数はリセットされます。

[設定例]

<監視>
インターバル 60 秒
タイムアウト 120 秒
リトライ回数 3 回

<異常検出>
回復対象 フェイルオーバグループ A
最大再活性回数 0 回
最大フェイルオーバ回数 0 回
最終動作 クラスタサービス停止と OS 再起動

<再起動回数制限>
最大再起動回数 1 回
最大再起動回数をリセットする時間 10 分
を指定している場合の挙動の例

図は、2台のサーバにおいてディスクTURモニタリソースが監視を行う場合の例です。 Disk TUR monitor resource 1の活性処理を開始します。インターバル毎にデバイスへのI/O処理などを実行します。

図 4.51 再起動回数制限 (1)

Server 1

Server 2

最大再起動回数

1

1

再起動回数

0

0
Disk TUR monitor resource 1の監視が異常を検出しました（ioctl、readの異常など）。

図 4.52 再起動回数制限 (2)
クラスタサービスを停止後、OSを再起動します。 "活性リトライしきい値"、"フェイルオーバしきい値" は0のため、最終動作を実行します。再起動回数には 1が記録されます。そして、Failover group Aのフェイルオーバ処理を開始します。 "最大再起動回数" は各サーバでの再起動回数の上限値です。 Server 2では再起動回数は0です。

図 4.53 再起動回数制限 (3)

Server 1

Server 2

最大再起動回数

1

1

再起動回数

1

0
Server 1の再起動が完了しました。 clpgrpコマンド、Cluster WebUIを使用して、Failover group AをServer 1に移動します。

図 4.54 再起動回数制限 (4)

Server 1

Server 2

最大再起動回数

1

1

再起動回数

1

0
Disk TUR monitor resource 1の監視が異常を検出しました（ioctl、readの異常など）。 Server 1では再起動回数が最大起動回数に達しているため、最終動作は実行されません。 10分経過しても再起動回数はリセットされません。

図 4.55 再起動回数制限 (5)

Server 1

Server 2

最大再起動回数

1

1

再起動回数

1

0
Shared diskの異常を取り除き、clpstdnコマンド、Cluster WebUIを使用してクラスタシャットダウン後、再起動します。

図 4.56 再起動回数制限 (6)

Server 1

Server 2

最大再起動回数

1

1

再起動回数

1

0
Server 1のDisk TUR monitor resource 1は正常な状態になります。 10分経過すると、再起動回数はリセットされます。次回 Disk TUR monitor resource 1の異常検出時には最終動作が実行されます。

図 4.57 再起動回数制限 (7)

Server 1

Server 2

最大再起動回数

1

1

再起動回数

0

0

4.1.11. ライセンスが必要なモニタリソース

以下の表に記述されているモニタリソースは、オプション製品になるため、ライセンスが必要になります。

ご使用になる場合は、製品ライセンスを入手してライセンスを登録してください。

オプション製品名	モニタリソース名
CLUSTERPRO X Database Agent 6.0 for Windows	DB2 モニタリソース
〃	ODBC モニタリソース
〃	Oracle モニタリソース
〃	PostgreSQL モニタリソース
〃	SQL Server モニタリソース
CLUSTERPRO X Internet Server Agent 6.0 for Windows	FTP モニタリソース
〃	HTTP モニタリソース
〃	IMAP4 モニタリソース
〃	POP3 モニタリソース
〃	SMTP モニタリソース
CLUSTERPRO X Application Server Agent 6.0 for Windows	Tuxedo モニタリソース
〃	WebSphere モニタリソース
〃	WebLogic モニタリソース
〃	WebOTX モニタリソース
CLUSTERPRO X Java Resource Agent 6.0 for Windows	JVMモニタリソース
CLUSTERPRO X System Resource Agent 6.0 for Windows	システムモニタリソース
〃	プロセスリソースモニタリソース

ライセンスの登録手順については、『インストール&設定ガイド』の「ライセンスを登録する」を参照してください。

4.2. モニタ共通のプロパティ

「モニタ共通のプロパティ」ダイアログ

モニタリソースの一覧を表示します。
各種設定値を変更することができます。
名前のリンクを押下すると、該当のモニタリソースのプロパティ画面に遷移します。
一覧の項目名(名前、タイプ)を選択することにより各項目を並べ替えることができます。
[テーブルのカスタマイズ] を選択すると [テーブルのカスタマイズ] ダイアログボックスが表示され、一覧の項目の表示・非表示を設定することができます。
CSVダウンロードを押下すると、モニタリソースの一覧に表示している情報をCSV形式でダウンロードします。
各表示項目の詳細は「 モニタリソースのプロパティ 」を参照してください。

4.3. モニタリソースのプロパティ

4.3.1. 情報タブ

モニタリソースのプロパティの「情報」タブ（fipw）

名前

モニタリソース名を表示します。

モニタリソース名の変更

[その他]メニューをクリックして、[モニタリソースの名称変更]を選択してください。

[モニタリソース名の変更]ダイアログボックスが表示されます。

入力規則

1 バイトの英大文字・小文字，数字，ハイフン (-)，アンダーバー (_)，スペースのみ使用可能です。

最大 31 文字 (31 バイト) までです。

文字列先頭と文字列末尾にハイフン (-)とスペースは使えません。

コメント (127 バイト以内)

モニタリソースのコメントを設定します。半角英数字のみ入力可能です。

4.3.2. 監視 (共通) タブ

モニタリソースのプロパティの「監視（共通）」タブ（oraclew）

インターバル (1～999)

監視対象の状態を確認する間隔を設定します。

タイムアウト (5～999)

ここで指定した時間内に監視対象の正常状態が検出できない場合に異常と判断します。

注釈

ミラーディスクモニタリソース、およびハイブリッドディスクモニタリソースのタイムアウト値を変更することは推奨しません。

タイムアウト発生時に監視プロセスのダンプを採取する (Oracle モニタリソースの場合のみ)

タイムアウト発生時に、CLUSTERPRO の監視プロセスのダンプファイルを採取するかどうかを指定します。

採取されたダンプファイルは CLUSTERPRO インストールフォルダ配下の work\rm\リソース名\ errinfo.cur フォルダに保存されます。採取が複数回実行された場合は、過去の採取情報のフォルダ名が errinfo.1、errinfo.2 とリネームされ、最新の情報から 5 世代分まで保存されます。

タイムアウト発生時にリトライしない

本機能を有効にした場合、モニタリソースがタイムアウトすると即座に「タイムアウト発生時動作」を実行します。

タイムアウト発生時動作

モニタリソースタイムアウト発生時の動作を選択します。

また、タイムアウトが発生した場合にはリトライ回数の回数カウンタはリセットされます。

本機能は、[タイムアウト発生時にリトライしない] 機能を有効にしている場合のみ設定可能です。

[回復動作を実行する]

モニタリソースがタイムアウトした場合に回復動作を実行します。

[回復動作を実行しない]

モニタリソースがタイムアウトした場合に回復動作を実行しません。

[意図的なストップエラーを発生させる]

意図的なストップエラーを発生させます。

注釈

下記のモニタリソースでは、[タイムアウト発生時にリトライしない], [タイムアウト発生時動作] 機能は設定できません。

マルチターゲットモニタリソース

カスタムモニタリソース (監視タイプが [非同期] の場合のみ)

外部連携モニタリソース

JVM モニタリソース

システムモニタリソース

プロセスリソースモニタリソース

ユーザ空間モニタリソース

リトライ回数 (0～999)

異常状態を検出後、連続してここで指定した回数の異常を検出したときに異常と判断します。

0 を指定すると最初の異常検出で異常と判断します。

監視開始待ち時間 (0～9999)

監視を開始するまでの待ち時間を設定します。

監視タイミング

監視のタイミングを設定します。

[常時]

監視を常時行います。

[活性時]

指定したリソースが活性するまで監視を行いません。

対象リソース

活性時監視を行う場合に対象となるリソースを表示します。

参照

[対象リソースの選択] ダイアログボックスを表示します。LocalServerとクラスタに登録されているグループ名、リソース名がツリー表示されます。対象リソースとして設定するリソースを選択して [OK] をクリックします。

「対象リソースの選択」ダイアログボックス

監視を行うサーバを選択する

監視を行うサーバを設定します。

「異常検出サーバ」ダイアログボックス

全てのサーバ

全てのサーバで監視を行います。

個別に設定する

[利用可能なサーバ] に登録されているサーバで監視を行います。[利用可能なサーバ] は 1 つ以上設定する必要があります。

追加

[利用可能なサーバ] で選択したサーバを [起動可能なサーバ] に追加します。

削除

[起動可能なサーバ] で選択したサーバを削除します。

監視処理時間メトリクスを送信する

モニタリソースの監視処理時間メトリクスの送信機能を設定します。

チェックボックスがオン

監視処理メトリクスを送信します。

チェックボックスがオフ

監視処理メトリクスを送信しません。

注釈

Amazon CloudWatch連携機能を使用する場合は、本機能を有効にすることで任意のモニタリソースの監視処理時間メトリクスが送信出来ます。

下記のモニタリソースでは、[監視処理時間メトリクスを送信する] 機能は設定できません。

外部連携モニタリソース

4.3.3. 監視(固有) タブ

モニタリソースによっては監視動作時のパラメータを設定する必要があります。パラメータは各リソースの説明に記述しています。

4.3.4. 回復動作タブ

通常のモニタリソース (外部監視連携リソース以外) の場合

[クラスタのプロパティ] - [拡張]タブ - [フェイルオーバ回数のカウント単位] を[サーバ] にした場合

[クラスタのプロパティ] - [拡張]タブ - [フェイルオーバ回数のカウント単位] を[クラスタ] にした場合

外部連携モニタリソースの場合

回復対象と異常検出時の動作を設定します。異常検出時にグループのフェイルオーバやリソースの再起動やクラスタの再起動ができます。ただし、回復対象が非活性状態であれば回復動作は行われません。

回復動作

異常検出時の回復動作を選択します。

[回復対象に対してフェイルオーバ実行]

モニタ異常検出時に、回復対象に選択したグループまたはグループリソースの属するグループに対してフェイルオーバを行います。

[回復対象を再起動、効果がなければフェイルオーバ実行]

回復対象として選択されたグループまたはグループリソースを再活性します。再活性が失敗するか、再活性後に同じ異常が検出された場合は、フェイルオーバを行います。

[回復対象を再起動]

回復対象として選択されたグループまたはグループリソースを再活性します。

[最終動作のみ実行]

最終動作として選択された動作を実行します。

[カスタム設定]

回復スクリプトを最大スクリプト実行回数まで実行します。スクリプト実行後も異常が検出される状態が継続した場合、回復対象として選択されたグループまたはグループリソースを最大再活性回数まで再活性します。再活性が失敗するか、再活性後に同じ異常が検出される状態が継続し、最大再活性回数に達した場合は、回復対象として選択されたグループまたはグループリソースを最大フェイルオーバ回数までフェイルオーバを実行します。フェイルオーバに失敗するか、フェイルオーバ後に同じ異常が検出される状態が継続し、最大フェイルオーバ回数に達した場合は、最終動作として選択された動作を実行します。

回復対象

リソースの異常とみなした時に回復を行う対象のオブジェクトが表示されます。

参照

[回復対象の選択] ダイアログボックスを表示します。LocalServer、All Groupsとクラスタに登録されているグループ名、リソース名がツリー表示されます。回復対象として設定するものを選択して [OK] をクリックします。

「回復対象の選択」ダイアログボックス

回復スクリプト実行回数 (0 ～ 99)

異常検出時に [スクリプト設定] で設定されたスクリプトを実行する回数を設定します。0 を設定するとスクリプトを実行しません。

再活性前にスクリプトを実行する

再活性化を行う前にスクリプトを実行するかどうかを指定します。

最大再活性回数 (0 ～ 99)

異常検出時に再活性化を行う回数を設定します。0 を設定すると再活性化を行いません。回復対象にグループまたはグループリソースを選択した場合に設定可能です。外部連携モニタリソースではこの値は設定できません。

IP モニタリソースまたは NIC Link Up/Down モニタリソースの回復対象として、フェイルオーバ属性(拡張) の [指定したモニタリソースで異常を検出しているサーバをフェイルオーバ先から除外する] が設定されているグループまたはそのグループに属するリソースを設定している場合、指定したモニタリソースが異常を検出しているため、再活性処理に失敗します。

フェイルオーバ実行前にスクリプトを実行する

フェイルオーバを行う前にスクリプトを実行するかどうかを指定します。

フェイルオーバ先サーバ

異常検出時に再活性化が [最大再活性回数] で指定した回数失敗した場合にフェイルオーバさせるときの、フェイルオーバ先サーバを次の中から選択します。

安定動作サーバ

回復対象のリソースが属するグループのフェイルオーバ回数が最も少ないサーバにフェイルオーバします。

上記を満たすサーバが複数存在する場合は、それらの中から、最もプライオリティが高いサーバにフェイルオーバします。

最高プライオリティサーバ

リソース異常によるフェイルオーバ回数が最も少ないサーバにフェイルオーバします。

上記を満たすサーバが複数存在する場合は、それらの中から、最もプライオリティが高いサーバにフェイルオーバします。

サーバグループ外にフェイルオーバする

外部連携モニタリソースのみ設定できます。異常発生通知受信時に、現用系サーバグループとは別のサーバグループにフェイルオーバさせるかどうかを設定します。

最大フェイルオーバ回数 (0 ～ 99)

異常検出時に再活性化が [最大再活性回数] で指定した回数失敗した場合にフェイルオーバさせるときの回数を設定します。0 を設定するとフェイルオーバを行いません。回復対象にグループまたはグループリソースまたは All Groups を選択した場合に設定可能です。外部連携モニタリソースではこの値は設定できません。

[クラスタのプロパティ] - [拡張]タブ - [フェイルオーバ回数のカウント単位] を[サーバ]にした場合、最大フェイルオーバ回数に、任意の回数を設定します。

[クラスタのプロパティ] - [拡張]タブ - [フェイルオーバ回数のカウント単位] を[クラスタ]にした場合、最大フェイルオーバ回数に、以下の設定が可能です。

サーバ数にあわせる

最大フェイルオーバ回数にサーバ数を設定します。

回数を指定

最大フェイルオーバ回数に任意の回数を設定します。

フェイルオーバ回数のカウント単位の設定については、本ガイドの「2. パラメータの詳細」 - 「クラスタプロパティ」 - 「拡張タブ」を参照してください。

最終動作前にスクリプトを実行する

最終動作を実行する前にスクリプトを実行するかどうかを指定します。

チェックボックスがオン

最終動作を実施する前にスクリプト/コマンドを実行します。スクリプト/コマンドの設定を行うためには [スクリプト設定] をクリックしてください。

チェックボックスがオフ

スクリプト/コマンドを実行しません。

回復動作前にスクリプトを実行する

回復動作を実行する前にスクリプトを実行するかどうかを指定します。

外部連携モニタリソースのみ設定できます。

チェックボックスがオン

回復動作を実施する前にスクリプト/コマンドを実行します。スクリプト/コマンドの設定を行うためには [スクリプト設定] をクリックしてください。

チェックボックスがオフ

スクリプト/コマンドを実行しません。

スクリプト設定

[スクリプトの編集] ダイアログボックスを表示します。回復スクリプト/コマンドを設定します。

ユーザアプリケーション

スクリプトとしてサーバ上の実行可能ファイル (実行可能なバッチファイルや実行ファイル) を使用します。ファイル名にはサーバ上のローカルディスクの絶対パスまたは実行可能ファイル名を設定します。ただし、実行可能ファイル名のみを設定する場合、あらかじめ環境変数にパスを設定しておく必要があります。また、絶対パスやファイル名に空欄が含まれる場合は、下記のように、ダブルクォーテーション (") でそれらを囲ってください。

例：

"C:\Program Files\script.bat"

また VB スクリプトを実行させるには下記のように入力してください。

例：

cscript script.vbs

各実行可能ファイルは、Cluster WebUI のクラスタ構成情報には含まれません。Cluster WebUI で編集やアップロードはできませんので、各サーバ上に準備する必要があります。

この製品で作成したスクリプト

スクリプトとして Cluster WebUI で準備したスクリプトファイルを使用します。必要に応じて Cluster WebUI でスクリプトファイルを編集できます。スクリプトファイルは、クラスタ構成情報に含まれます。

ファイル (1023 バイト以内)

[ユーザアプリケーション] を選択した場合に、実行するスクリプト (実行可能なバッチファイルや実行ファイル) を設定します。

表示

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを表示します。

編集

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを編集します。変更を反映するには [保存] をクリックしてください。スクリプトファイル名の変更はできません。

置換

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルの内容を、ファイル選択ダイアログボックスで選択したスクリプトファイルの内容に置換します。スクリプトが既に表示中または編集中の場合は置換できません。ここではスクリプトファイルを選択してください。バイナリファイル (アプリケーションなど) は選択しないでください。

タイムアウト (1 ～ 9999)

スクリプトの実行完了を待ち合わせる最大時間を指定します。既定値は 5 秒です。

実行ユーザ

スクリプトを実行するユーザを指定します。実行ユーザは [クラスタのプロパティ] の [アカウント] タブに登録されたユーザの中から選択可能です。

実行ユーザを指定しなかった場合、スクリプトはローカルシステムアカウントとして実行されます。

最終動作

異常検出時に再活性化が [最大再活性回数] で指定した回数失敗し、フェイルオーバが [最大フェイルオーバ回数] で指定した回数失敗した後の動作を選択します。

最終動作は以下の動作が選択できます。

何もしない

何も行いません。

注釈

[何もしない] の設定は

一時的に最終動作を抑止したい場合

異常を検出したときにアラートの表示のみを行いたい場合

実際の最終動作はマルチターゲットモニタリソースで行いたい場合

に使用してください。

リソース停止

回復対象としてグループリソースが選択されている場合、選択したグループリソースとそのグループリソースに依存するグループリソースを停止します。回復対象に "LocalServer" 、"All Groups"、グループが選択されている場合は選択できません。

グループ停止

回復対象としてグループが選択されている場合そのグループを、また回復対象としてグループリソースが選択されている場合そのグループリソースが所属するグループを停止します。"All Groups" が選択されている場合は、モニタリソースが異常を検出したサーバで起動している全てのグループを停止します。回復対象にLocalServerが選択されている場合は選択できません。

クラスタサービス停止

異常検出したサーバの CLUSTERPRO Server サービスを停止します。

クラスタサービス停止と OS シャットダウン

異常検出したサーバの CLUSTERPRO Server サービスを停止し、OS をシャットダウンします。

クラスタサービス停止と OS 再起動

異常検出したサーバの CLUSTERPRO Server サービスを停止し、OS を再起動します。

意図的なストップエラーの発生

異常検出したサーバに対し意図的にストップエラーを発生させます。

4.4. アプリケーションモニタリソースを理解する

アプリケーションモニタリソースはアプリケーションリソースの監視を行います。

4.4.1. アプリケーションモニタリソースの監視方法

アプリケーションリソースが活性したサーバで監視を行います。

アプリケーションの死活監視を定期的に行い、アプリケーションの消滅を検出した場合に異常と判断します。

4.4.2. アプリケーションモニタリソースに関する注意事項

活性に成功したアプリケーションリソースを監視します。アプリケーションリソースの常駐タイプの設定が [常駐] の場合のみ監視できます。

本リソースはアプリケーションリソースを追加時、常駐タイプを「常駐」としていた場合に自動的に登録されます。各アプリケーションリソースに対応するアプリケーションモニタリソースが自動登録されます。
アプリケーションモニタリソースには既定値が設定されているので、必要があれば適切な値に変更してください。
アプリケーションリソースを追加時、常駐タイプを「非常駐」としていた場合、本リソースを追加することはできません。

4.4.3. 監視 (固有) タブ

アプリケーションモニタリソースの監視 (固有) タブはありません。

4.5. ディスク RW モニタリソースを理解する

ディスク RW モニタリソースは、ファイルシステムへのダミーデータ書込みによりディスクデバイスの監視を行います。

4.5.1. ディスク RW モニタリソースによる監視方法

指定されたファイルシステム (ベーシックボリュームまたはダイナミックボリューム) 上を指定された I/O サイズで write し、その結果 (write できたサイズ) を判断します (作成したファイルは write 後に削除されます)。

指定された I/O サイズが write できたことのみを判断し、書込みデータの正当性は判断しません。

write する I/O サイズを大きくすると OS やディスクへの負荷が大きくなります。

使用するディスクやインターフェイスにより、様々な write 用のキャッシュが実装されている場合があります。そのため I/O サイズが小さい場合にはキャッシュにヒットしてしまい writeのエラーを検出できない場合があります。

I/O サイズについては、ディスクの障害等を発生させ障害の検出ができることを確認してください。

注釈

監視対象ディスクのディスクパス障害発生時に、ディスクパス冗長化ソフトウェアなどの機能でパスフェイルオーバを行う場合、監視タイムアウトの時間 (既定値 300 秒) を、パスフェイルオーバにかかる時間よりも長く設定する必要があります。

4.5.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（diskw）

ファイル名 (1023 バイト以内)

アクセスするためのファイル名を入力します。このファイルは監視処理の際に作成され、I/O完了後に削除されます。

注釈

ファイル名には絶対パスを指定して下さい。相対パスを指定した場合、予期しない場所を監視する可能性があります。

重要

ファイル名には既に存在するファイルを指定しないで下さい。既に存在するファイルを指定した場合、そのファイルの情報は失われます。

I/O サイズ (1～9999999)

監視するディスクに行う I/O サイズを指定します。

ストール異常検出時動作

ストール異常検出時の動作を指定します。

[監視(共通)] タブの [タイムアウト] で指定した時間内に、I/O の制御が OS から戻らない場合にストール異常とみなします。

何もしない

何も行いません。

HW リセット [4]

ハードウェアをリセットします。

意図的なストップエラーの発生

ストップエラーを発生させます。

注釈

ストール異常検出時動作に関しては、擬似障害を発生させることができません。

ディスクフル検出時動作

ディスクフル（監視するディスクに空き容量がない状態）検出時の動作を指定します。

回復動作を実行する

ディスクRWモニタリソースはディスクフル検出時に異常として扱います。

回復動作を実行しない

ディスクRWモニタリソースはディスクフル検出時に警告として扱います。

Write Through方式を有効にする

監視I/Oの方式にWrite Through方式を適用します。

有効にした場合、ディスクRW監視の異常検出精度が向上しますが、

システムのI/O負荷が上昇する場合があります。

[4]
本機能を使用する場合は、強制停止機能とは異なり、 ipmiutil は必要ありません。

4.6. フローティング IP モニタリソースを理解する

フローティング IP モニタリソースはフローティング IP リソースの監視を行います。

4.6.1. フローティング IP モニタリソースの監視方法

フローティング IP リソースが活性したサーバで WMI を使用して監視を行います。

IP アドレス一覧にフローティング IP アドレスが存在するかどうか監視します。IP アドレス一覧にフローティング IP アドレスが存在しない場合、異常と判断します。

フローティング IP アドレスが活性している NIC の Link Up/Down を監視します。NIC のLink Down を検出すると異常と判断します。

4.6.2. フローティング IP モニタリソースに関する注意事項

本リソースはフローティング IP リソースを追加した時に自動的に登録されます。各フローティング IP リソースに対応するフローティング IP モニタリソースが自動登録されます。

フローティングIPモニタリソースには既定値が設定されているので、必要があれば適切な値に変更してください。

4.6.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（fipw）

NIC Link Up/Down を監視する

NIC Link Up/Down を監視するかどうかを設定します。

4.7. IP モニタリソースを理解する

IP モニタリソースは、[ping] コマンドを使用して応答の有無により、IP アドレスの監視を行うモニタリソースです。

4.7.1. IP モニタリソースの監視方法

指定した IP アドレスを [ping] コマンドで監視します。指定した IP アドレスすべての応答がない場合に異常と判断します。

複数の IP アドレスについてすべての IP アドレスが異常時に異常と判断したい場合、1 つの IP モニタリソースにすべての IP アドレスを登録してください。

以下の図は1つのIPモニタリソースに全てのIPアドレスを登録した場合の例です。指定したIPアドレスが一つでも正常な場合、IP monitor 1は正常と判断します。

図 4.58 1つのIPモニタリソースに全てのIPアドレスを登録（正常）

以下の図は1つのIPモニタリソースに全てのIPアドレスを登録した場合の例です。指定したIPアドレスが全て異常な場合、IP monitor 1は異常と判断します。

図 4.59 1つのIPモニタリソースに全てのIPアドレスを登録（異常検出）
複数の IP アドレスについてどれか 1 つが異常時に異常と判断したい場合、個々の IP アドレスについて 1 つずつの IP モニタリソースを作成してください。

図は各IPモニタリソースにIPアドレスを一つずつ登録した場合の例です。指定したIPアドレスの異常を検出した場合、IPモニタリソース（図ではIP monitor 1）は異常と判断します。

図 4.60 各IPモニタリソースにIPアドレスを一つずつ登録（異常検出）

4.7.2. 監視 (固有) タブ

[IP アドレス一覧] には監視する IP アドレスの一覧が表示されます。

モニタリソースのプロパティの「監視（固有）」タブ（ipw）

追加

監視する IP アドレスを追加します。[IP アドレスの入力] ダイアログボックスが表示されます。

「IPアドレスの入力」ダイアログボックス

IP アドレス (255 バイト以内)

監視を行う IP アドレス入力して [OK] を選択してください。パブリック LAN から通信可能な実 IP アドレスを入力してください。

削除

[IP アドレス一覧] で選択している IP アドレスを監視対象から削除します。

編集

[IP アドレスの入力] ダイアログボックスが表示されます。[IP アドレス一覧] で選択しているIP アドレスが表示されるので、編集して [OK] を選択します。

Ping タイムアウト (1～999999)

監視する IP アドレスへの Ping のタイムアウトをミリ秒単位で設定します。

4.8. ミラーディスクモニタリソースを理解する

ミラーパーティションデバイス (ミラードライバ) の健全性を監視します。

4.8.1. ミラーディスクモニタリソースの注意事項

本リソースはミラーディスクリソースを追加した時に自動的に登録されます。各ミラーディスクリソースに対応するミラーディスクモニタリソースが自動登録されます。
本リソースを削除した場合、自動ミラー復帰を行えなくなる事に注意してください。
詳細は本ガイドの「10. トラブルシューティング」-「ミラーブレイク状態からの復旧を行う」-「自動でミラーを復帰するには」を参照してください。

4.8.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（mdw）

ミラーディスクリソース

監視を行うミラーディスクリソースが表示されます。

参照

[ミラーディスクリソースの選択] ダイアログボックスが表示され、監視を行うミラーディスクリソースを設定します。クラスタに登録されているミラーディスクリソースがツリー表示されます。ミラーディスクリソースのみ選択可能です。ミラーディスクリソースを選択して [OK] を選択します。

4.9. NIC Link Up/Down モニタリソースを理解する

NIC Link Up/Down モニタリソースは、WMI を使用して指定した NIC の Link 状態を取得し、Link のUp/Down の監視を行います。

4.9.1. NIC Link Up/Down 監視の構成および範囲

インタコネクト (ミラーディスクコネクト) 専用の NIC を監視することもできますが、2 ノードで LAN ケーブルで直結している場合には片サーバダウン時に (リンクが確立しないため) 残りのサーバ側でも異常を検出します。

4.9.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（miiw）

追加

監視を行う NIC の IP アドレスを、監視を行うサーバ一覧に追加します。

削除

監視を行う NIC の IP アドレスを、監視を行うサーバ一覧から削除します。

編集

監視を行う NIC の IP アドレスを編集します。

「IPアドレスの入力」ダイアログボックス

IP アドレス (47 バイト以内)

監視を行う NIC の IP アドレスを設定してください。

4.10. マルチターゲットモニタリソースを理解する

マルチターゲットモニタリソースは、複数のモニタリソースの監視を行います。

4.10.1. マルチターゲットモニタリソースの注意事項

マルチターゲットモニタリソースは、登録されているモニタリソースのステータス停止済み(offline)を異常として扱います。そのため、活性時監視のモニタリソースを登録した場合、モニタリソースが異常を検出していない状態でマルチターゲットモニタリソースが異常を検出してしまうことがあります。活性時監視のモニタリソースを登録しないでください。

4.10.2. マルチターゲットモニタリソースのステータス

マルチターゲットモニタリソースのステータスは登録されているモニタリソースのステータスによって判断します。

マルチターゲットモニタリソースが下記のように設定されている場合、
登録されているモニタリソース数    2
異常しきい値    2
警告しきい値    1

マルチターゲットモニタリソースのステータスは以下のようになります。

マルチターゲットモニタリソースステータス		モニタリソース 1 ステータス
マルチターゲットモニタリソースステータス		正常 (normal)	異常 (error)	停止済 (offline)
モニタリソース 2 ステータス	正常 (normal)	正常 (normal)	警告 (caution)	警告 (caution)
	異常 (error)	警告 (caution)	異常 (error)	異常 (error)
	停止済 (offline)	警告 (caution)	異常 (error)	正常 (normal)

マルチターゲットモニタリソースは、登録されているモニタリソースのステータスを監視しています。

ステータスが異常 (error) であるモニタリソースの数が異常しきい値以上になった場合、マルチターゲットモニタリソースは異常 (error) を検出します。

ステータスが異常 (error) であるモニタリソース数が警告しきい値を超えた場合、マルチターゲットモニタリソースの status は警告 (caution) となります。

登録されている全てのモニタリソースのステータスが停止済み (offline) の場合、マルチターゲットモニタリソースのステータスは正常 (normal) となります。

登録されている全てのモニタリソースのステータスが停止済み (offline) の場合を除いて、マルチターゲットモニタリソースは登録されているモニタリソースのステータス停止済み (offline) を異常 (error) と判断します。
登録されているモニタリソースのステータスが異常 (error) となっても、そのモニタリソースの異常時アクションは実行されません。

マルチターゲットモニタリソースが異常 (error) になった場合のみ、マルチターゲットモニタリソースの異常時アクションが実行されます。

4.10.3. 監視 (固有) タブ

モニタリソースをグループ化して、そのグループの状態を監視します。[モニタリソース一覧] はモニタリソースを最大 64 個登録できます。

本リソースの [モニタリソース一覧] に唯一設定されているモニタリソースが削除された場合、本リソースは自動的に削除されます。

モニタリソースのプロパティの「監視（固有）」タブ（mtw）

追加

選択しているモニタリソースを [モニタリソース一覧] に追加します。

削除

選択しているモニタリソースを [モニタリソース一覧] から削除します。

調整

[マルチターゲットモニタリソース調整プロパティ] ダイアログボックスを表示します。マルチターゲットモニタリソースの詳細設定を行います。

マルチターゲットモニタリソース調整プロパティ

パラメータに関する詳細設定が表示されます。

「マルチターゲットモニタリソース調整プロパティ」ダイアログ

異常しきい値

マルチターゲットモニタが異常とする条件を選択します。

メンバ数に合わせる

マルチターゲットモニタの配下に指定したモニタリソースが全て異常となったとき、または異常と停止済が混在しているときにマルチターゲットモニタが異常になります。

マルチターゲットモニタの配下に指定したモニタリソースの全てが停止済の場合には、正常になります。

数を指定する

マルチターゲットモニタの配下に指定したモニタリソースのうち、異常しきい値に設定した数が異常または停止済となったときにマルチターゲットモニタが異常になります。

マルチターゲットモニタの配下に指定したモニタリソースのうち、何個のモニタリソースが異常または停止済となったときにマルチターゲットモニタを異常とするかの個数を設定します。

異常しきい値の選択が [数を指定する] のときに設定できます。

警告しきい値

チェックボックスがオン

マルチターゲットモニタの配下に指定したモニタリソースのうち、何個のモニタリソースが異常または停止済となったときにマルチターゲットモニタを警告とするかの個数を設定します。

チェックボックスがオフ

マルチターゲットモニタは警告のアラートを表示しません。

既定値

既定値に戻すときに使用します。[既定値] をクリックすると全ての項目に既定値が設定されます。

4.11. レジストリ同期モニタリソースを理解する

レジストリ同期モニタリソースはレジストリ同期リソースの監視を行います。

4.11.1. レジストリ同期モニタリソースに関する注意事項

本リソースはレジストリ同期リソースを追加した時に自動的に登録されます。各レジストリ同期リソースに対応するレジストリ同期モニタリソースが自動登録されます。

レジストリ同期モニタリソースには既定値が設定されているので、必要があれば適切な値に変更してください。

4.11.2. 監視 (固有) タブ

レジストリ同期モニタリソースの監視 (固有) タブはありません。

4.12. ディスク TUR モニタリソースを理解する

ディスク TUR モニタリソースはディスクリソースで指定されているディスクの監視を行います。

4.12.1. ディスク TUR モニタリソースに関する注意事項

SCSI の Test Unit Ready をサポートしていないディスク、ディスクインターフェイス (HBA) では使用できません。

ハードウェアがサポートしている場合でも、ドライバがサポートしていない場合があるので、ドライバの仕様も合わせて確認してください。
ディスク RW モニタリソースによるデータ書込みに比べて OS やディスクへの負荷は小さくなります。
Test Unit Ready では、実際のメディアへの I/O エラーは検出できない場合があります。
監視対象ディスクのディスクパス障害発生時に、ディスクパス冗長化ソフトウェアなどの機能でパスフェイルオーバを行う場合、監視タイムアウトの時間 (既定値300秒) を、パスフェイルオーバにかかる時間よりも長く設定する必要があります。
本リソースはディスクリソースを追加した時に自動的に登録されます。各ディスクリソースに対応するディスク TUR モニタリソースが自動登録されます。

ディスク TUR モニタリソースには既定値が設定されているので、必要があれば適切な値に変更してください。

4.12.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（sdw）

ディスクリソース

ディスクリソースを選択します。

参照

登録可能なディスクリソースが表示されます。

4.13. サービスモニタリソースを理解する

サービスモニタリソースはサービスリソースの監視、またはサービスの監視を行います。

4.13.1. サービスモニタリソースの監視方法

サービスの状態をサービス制御マネージャに対して定期的に問合せ、状態が「停止」状態となった場合に異常と判断します。

4.13.2. サービスモニタリソースに関する注意事項

[監視タイミング]-[活性時] を選択し、[対象リソース] にサービスリソースを設定している場合、サービスモニタリソースの [サービス名] はサービスリソースの [サービス名] が設定されます。

本リソースはサービスリソースを追加した時に自動的に登録されます。各サービスリソースに対応するサービスモニタリソースが自動登録されます。

4.13.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（servicew）

サービス名 (1023 バイト以内)

サービスリソースで使用するサービス名または、サービス表示名を設定します。

コンボボックスの選択肢はすべてのサーバから取得したサービスのサービス表示名一覧が表示されます。

サービス名は [監視タイミング]-[活性時]-[対象リソース] にサービスリソースを設定している場合、設定変更は行えません。

接続

すべてのサーバからサービス一覧を取得し、[サービス名] コンボボックスに表示するサービス表示名一覧を更新します。

4.14. 仮想コンピュータ名モニタリソースを理解する

仮想コンピュータ名モニタリソースは仮想コンピュータ名リソースの監視を行います。

4.14.1. 仮想コンピュータ名モニタリソースの監視方法

仮想コンピュータ名リソースが活性したサーバで監視を行います。

仮想コンピュータ名制御プロセスの死活監視を定期的に行い、プロセスの消滅を検出した場合に異常と判断します。

4.14.2. 仮想コンピュータ名モニタリソースに関する注意事項

本リソースは仮想コンピュータ名リソースを追加した時に自動的に登録されます。
本リソースの異常検出時の有効な最終動作は「クラスタサービス停止と OS シャットダウン」、「クラスタサービス停止と OS 再起動」、または「意図的なストップエラーの発生」のみです。

これは、仮想コンピュータ名制御プロセスが消滅した場合、仮想コンピュータ名リソースを正常に活性する為には OS の再起動を必要とするためです。

デフォルトでは「クラスタサービス停止と OS シャットダウン」が設定されています。この値を「クラスタサービス停止と OS シャットダウン」、「クラスタサービス停止と OS 再起動」、「意図的なストップエラーの発生」以外に変更しないでください。

仮想コンピュータ名制御プロセスが消滅した場合、異常を検出したサーバをシャットダウン、または再起動することでグループのフェイルオーバを行います。

4.14.3. 監視 (固有) タブ

仮想コンピュータ名モニタリソースの監視 (固有) タブはありません。

4.15. ダイナミックDNSモニタリソースを理解する

4.15.1. ダイナミックDNSモニタリソースに関する注意事項

CLUSTERPRO のダイナミック DNS リソースを使用する場合に使用します。

ダイナミック DNS リソースを追加すると自動的に作成されます。ダイナミック DNS リソース 1 つに対して 1 つのダイナミック DNS モニタリソースが自動的に作成されます。
ダイナミック DNS モニタリソースは削除できません。ダイナミック DNS リソースを削除すると自動的に削除されます。
回復対象は変更しないでください。
[clpmonctrl] コマンドまたは Cluster WebUI からの監視の一時停止、再開はできません。
クラスタサスペンド時に対象のダイナミック DNS リソースが活性状態であれば、ダイナミック DNS モニタリソースは停止せずに動作し続けます。
DDNS制御プロセス(clpddnsp.exe)の死活監視を定期的に行い、プロセスの消滅を検出した場合に異常と判断します。死活監視の間隔は[監視(共通)]タブ-[インターバル]毎です。ただし、監視対象のダイナミックDNSリソース[詳細]タブ-[定期的に動的更新を行う]チェックボックスがオフの場合は、DDNS制御プロセス(clpddnsp.exe)は生成しますが、死活監視は行いません。
DNS サーバがダウンしている場合、設定によってはフェイルオーバします。そのため、DNS サーバへの疎通確認は IP モニタリソースと併用することを推奨します。

4.15.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（ddnsw）

名前解決確認をする

チェックボックスがオン(既定値)

名前解決可能かをDDNSサーバへDNS queryパケットを送信し確認します。

チェックボックスがオフ

名前解決可能かを確認しません。

4.16. 仮想 IP モニタリソースを理解する

仮想 IP モニタリソースは仮想 IP リソースの監視を行います。

4.16.1. 仮想 IP モニタリソースの監視方法

仮想 IP リソースが活性したサーバで監視を行います。

IP アドレス一覧に仮想 IP アドレスが存在するかどうか監視します。IP アドレス一覧に仮想 IP アドレスが存在しない場合、異常と判断します。

仮想 IP アドレスが活性している NIC の Link Up/Down を WMI を使用して監視します。NIC の Link Down を検出すると異常と判断します。

4.16.2. 仮想 IP モニタリソースに関する注意事項

本リソースは仮想 IP リソースを追加した時に自動的に登録されます。

4.16.3. 監視 (固有) タブ

仮想 IP モニタリソースの監視 (固有) タブはありません。

4.17. CIFS モニタリソースを理解する

CIFS モニタリソースは CIFS リソースの監視を行います。

4.17.1. CIFS モニタリソースの監視方法

CIFS リソースが活性したサーバで監視を行います。

サーバ上で公開されている共有フォルダの情報を取得し、その中に CIFS リソースで公開したフォルダが含まれているかどうか監視します。CIFS リソースで公開した共有フォルダが存在しない場合、異常と判断します。

また、実際に共有フォルダに対してアクセスが可能かどうかを監視することができます。

ドライブ共有設定の自動保存を行う場合、共有設定の監視と保存を行う機能の死活監視も実施します。

4.17.2. CIFS モニタリソースに関する注意事項

アクセスチェックを行う場合、チェック方法として指定したアクセスが監視対象のCIFS リソースでローカルシステムアカウントに対して許可されている必要があります。
監視対象の CIFS リソースで [ドライブ共有設定の自動保存を行う] が設定され、[パス] に共有フォルダ名を指定せずに、CIFS モニタリソースでアクセスチェックを行う場合、チェック方法として指定したアクセスを、自動保存の対象となるドライブ上の全ての共有フォルダに対して実施します。このため、各共有フォルダに適切なアクセス権設定を行う必要があります。また、チェック方法としてフォルダチェックまたはファイルチェックの [読み込み] を指定した場合、[パス] で指定されたフォルダ/ファイルが各共有フォルダ上に存在している必要があります。
本リソースはCIFSリソースを追加した時に自動的に登録されます。各CIFS リソースに対応する CIFS モニタリソースが自動登録されます。

CIFS モニタリソースには既定値が設定されているため、必要があれば適切な値に変更してください。

4.17.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（cifsw）

アクセスチェック

共有フォルダに対するアクセスチェックの方法を設定します。

しない (既定値)

アクセスチェックを行いません。

フォルダチェック

[パス] で指定されたフォルダを参照できることを確認します。

ファイルチェック

[パス] で指定されたファイルに対して読み書き、または読み込み処理ができることを確認します。

パス (255 バイト以内)

アクセスチェックの対象となるファイル/フォルダを、共有フォルダも含めたパス、または、共有フォルダからの相対パスで指定します。

フォルダチェックの場合は共有フォルダ上に存在しているフォルダを指定してください。

監視対象の CIFS リソースにおいて [ドライブ共有設定の自動保存を行う] をチェックしている場合、共有フォルダを含めた絶対パス、もしくは共有フォルダからの相対パスで指定します。どちらを指定するかにより [アクセスチェック] のために予め作成しておくファイル/フォルダが異なります。

共有フォルダを含めたパスで指定する場合: 指定された共有名のフォルダ/ファイルのみ予め作成しておく必要があります。パスは「<共有名>\フォルダ名/ファイル名」で指定してください。共有名は <> で囲んでください。

共有フォルダからの相対パスで指定する場合: 共有設定が行われている全てのフォルダ上に同じ名前のフォルダを予め作成しておく必要があります。

監視対象の CIFS リソースにおいて共有設定を個別に指定する場合([ドライブ共有設定の自動保存を行う]をチェックしていない場合)、共有フォルダからの相対パスで指定します。

ファイルチェックでチェック方法に [読み書き] を選択した場合、指定されたファイルを新規に作成しますので、既存のファイルと重複しないファイル名を指定してください。

ファイルチェックでチェック方法に [読み込み] を選択した場合は共有フォルダ上に存在しているファイルを指定してください。また、監視対象のCIFSリソースに [ドライブ共有設定の自動保存を行う] が設定されている場合、共有設定が行われている全てのフォルダ上に同じ名前のファイルを予め作成しておく必要があります。

チェック

ファイルチェックでアクセスを確認する際の方法を選択します。

読み書き (既定値)

ファイルに対して書き込みを行い、書き込んだ内容が読み込めることを確認します。

読み込み

ファイルを開いて内容が読み込めることを確認します。

4.18. ハイブリッドディスクモニタリソースを理解する

ハイブリッドディスクのミラーパーティションデバイス (ミラードライバ) の健全性を監視します。

4.18.1. ハイブリッドディスクモニタリソースの注意事項

本リソースはハイブリッドディスクリソースを追加した時に自動的に登録されます。各ハイブリッドディスクリソースに対応するハイブリッドディスクモニタリソースが自動登録されます。
本リソースを削除した場合、自動ミラー復帰を行えなくなる事に注意してください。
詳細は本ガイドの「10. トラブルシューティング」-「ミラーブレイク状態からの復旧を行う」-「自動でミラーを復帰するには」を参照してください。

4.18.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（hdw）

ハイブリッドディスクリソース

監視を行うハイブリッドディスクリソースが表示されます。

参照

[ハイブリッドディスクリソースの選択] ダイアログボックスが表示され、監視を行うハイブリッドディスクリソースを設定します。クラスタに登録されているハイブリッドディスクリソースがツリー表示されます。ハイブリッドディスクリソースのみ選択可能です。ハイブリッドディスクリソースを選択して [OK] を選択します。

4.19. ハイブリッドディスク TUR モニタリソースを理解する

ハイブリッドディスク TUR モニタリソースはハイブリッドディスクリソースで指定されているディスクの監視を行います。

4.19.1. ハイブリッドディスク TUR モニタリソースに関する注意事項

本リソースはハイブリッドディスクリソースを追加した時に自動的に登録されます。各ハイブリッドディスクリソースに対応するハイブリッドディスク TUR モニタリソースが自動登録されます。

本リソースを削除した場合、自動ミラー復帰を行えなくなる事に注意してください。

詳細は本ガイドの「10. トラブルシューティング」-「ミラーブレイク状態からの復旧を行う」-「自動でミラーを復帰するには」を参照してください。
SCSI の Test Unit Ready をサポートしていないディスク、ディスクインターフェイス (HBA) では使用できません。

ハードウェアがサポートしている場合でも、ドライバがサポートしていない場合があるので、ドライバの仕様も合わせて確認してください。
ディスク RW 監視によるデータ書込みに比べて OS やディスクへの負荷は小さくなります。
Test Unit Ready では、実際のメディアへの I/O エラーは検出できない場合があります。

4.19.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（hdtw）

ハイブリッドディスクリソース

ハイブリッドディスクリソースを選択します。

参照

登録可能なハイブリッドディスクリソースが表示されます。

4.20. カスタムモニタリソースを理解する

カスタムモニタリソースは、任意のスクリプトを実行することによりシステムの監視を行うモニタリソースです。

4.20.1. カスタムモニタリソースの監視方法

カスタムモニタリソースは、任意のスクリプトによりシステム監視を行います。

監視タイプが [同期] の場合、スクリプトを定期的に実行し、そのエラーコードにより異常の有無を判別します。

監視タイプが [非同期] の場合、スクリプトを監視開始時に実行し、このスクリプトのプロセスが消失した場合に異常と判断します。

4.20.2. カスタムモニタリソースに関する注意事項

バッチファイル内でプロンプトへのメッセージ出力(標準出力、エラー出力)を行うコマンドを実行する場合は、コマンドを実行した際にバッチファイルが停止する可能性があるため、メッセージ出力先にファイルもしくは nul を指定(リダイレクト)してください。
監視タイプが [非同期] の場合は、タイムアウトに監視開始待ち時間より大きい値を設定してください。

4.20.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（genw）

ユーザアプリケーション

スクリプトとしてサーバ上の実行可能ファイル (実行可能なバッチファイルや実行ファイル) を使用します。各実行可能ファイル名は、サーバ上のローカルディスクの絶対パスで設定します。

各実行可能ファイルは、Cluster WebUI のクラスタ構成情報には含まれません。Cluster WebUI で編集やアップロードはできませんので、各サーバ上に準備する必要があります。

この製品で作成したスクリプト

スクリプトとして Cluster WebUI で準備したスクリプトファイルを使用します。必要に応じて Cluster WebUI でスクリプトファイルを編集できます。スクリプトファイルは、クラスタ構成情報に含まれます。

スクリプトの種類

[この製品で作成したスクリプト] を選択した場合に、実行するスクリプトの種類を選択します。

バッチファイル (既定値)

実行するスクリプトとしてバッチファイルを使用します。

PowerShell

実行するスクリプトとして PowerShell を使用します。

ファイル (255 バイト以内)

[ユーザアプリケーション] を選択した場合に、実行するスクリプト (実行可能なバッチファイルや実行ファイル) を、サーバ上のローカルディスクの絶対パスで設定します。ただし、スクリプトの後に引数は指定できません。

表示

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを表示します。

編集

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルを編集します。変更を反映するには [保存] をクリックしてください。スクリプトファイル名の変更はできません。

置換

[この製品で作成したスクリプト] を選択した場合に、スクリプトファイルの内容を、ファイル選択ダイアログボックスで選択したスクリプトファイルの内容に置換します。スクリプトが表示中または編集中の場合は置換できません。ここではスクリプトファイルを選択してください。バイナリファイル (アプリケーションなど) は選択しないでください。

監視タイプ

監視の方法を選択します。

同期 (既定値)

定期的にスクリプトを実行し、そのエラーコードにより異常の有無を判断します。

非同期

監視開始時にスクリプトを実行し、そのプロセスが消失した場合に異常と判断します。

正常な戻り値 (1023バイト以内)

監視タイプが [同期] の場合にスクリプトのエラーコードがどのような値の場合に正常と判断するかを設定します。複数の値がある場合は、0,2,3 というようにカンマで区切るか、 0-3 のようにハイフンで値の範囲を指定します。

既定値： 0

警告戻り値 (1023バイト以内)

監視タイプが [同期] の場合にスクリプトのエラーコードがどのような値の場合に警告と判断するかを設定します。複数の値がある場合は、0,2,3 というようにカンマで区切るか、 0-3 のようにハイフンで値の範囲を指定します。

[正常な戻り値]と[警告戻り値]に同じ値を設定した場合、正常と判断します。

終了時アプリケーションを強制終了する

監視停止時の終了処理としてアプリケーションを強制終了するかどうかを設定します。設定した場合、通常の終了処理を行わず強制終了によりアプリケーションを終了させます。監視タイプに「非同期」を設定している場合のみ有効となります。

クラスタ停止時に活性時監視の停止を待ち合わせる

クラスタ停止時にカスタムモニタリソースの停止を待ち合わせます。監視タイミングに [活性時] を設定している場合のみ有効となります。

実行ユーザ

スクリプトを実行するユーザを指定します。実行ユーザは [クラスタのプロパティ] の [アカウント] タブに登録されたユーザの中から選択可能です。

実行ユーザを指定しなかった場合、スクリプトはローカルシステムアカウントとして実行されます。

4.21. 外部連携モニタリソースを理解する

外部連携モニタリソースは受動的なモニタです。自身では監視処理を行いません。

CLUSTERPRO の外部から発行された異常発生通知を受信した場合に、外部連携モニタリソースのステータスの変更、異常発生時の回復動作を行うモニタリソースです。

4.21.1. 外部連携モニタリソースの監視方法

外部から異常発生通知を受信した場合、通知されたカテゴリとキーワード (キーワードは省略可能) が設定されている外部連携モニタリソースの異常発生時の回復動作を行います。通知されたカテゴリ、キーワードが設定されている外部連携モニタリソースが複数存在する場合は、各モニタリソースの回復動作を行います。
外部連携モニタは、[clprexec] コマンドからの異常発生通知を受信することができます。

図は外部連携モニタリソースを使用する構成の例です。 clprexec コマンドから異常発生通知を受けた Server 2 の外部連携モニタリソースは、自身のステータス変更と異常検出時の回復動作を実行します。

clprexecコマンドが実行されたServer 1、外部連携モニタリソースが動作するServer 2 — 図 4.61 外部連携モニタリソースを使用する構成

4.21.2. サーバグループ外フェイルオーバ

異常発生通知受信時に、現用系サーバグループから、別サーバグループのサーバにフェイルオーバさせることが出来ます。
サーバグループの設定と、以下の設定が必要となります。
- 回復対象のグループリソース
  - [サーバグループ設定を使用する]をON
- 外部連携モニタリソース
  - 回復動作を[回復対象に対してフェイルオーバ実行]
  - [サーバグループ外にフェイルオーバする]をON
サーバグループ外フェイルオーバ実行時には、ダイナミックフェイルオーバの設定やサーバグループ間のフェイルオーバ設定は無効となります。フェイルオーバ元のサーバが属するサーバグループとは別のサーバグループ内のサーバで、プライオリティが最も高いサーバにフェイルオーバします。

現用系サーバグループに属するServer 1とServer 2、待機系サーバグループに属する Server 3とServer 4 — 図 4.62 外部連携モニタリソースを使用する構成（サーバグループ外フェイルオーバ）

4.21.3. 外部連携モニタリソースに関する注意事項

<外部連携モニタリソース全般の注意事項>

外部連携モニタリソースが一時停止状態で外部からの異常発生通知を受信した場合、異常時動作は実行されません。
外部から異常発生通知を受信した場合、外部連携モニタリソースのステータスは "異常" になります。"異常" となった外部連携モニタリソースのステータスは、自動では "正常" に戻りません。ステータスを "正常" に戻したい場合は、[clprexec] コマンドを使用してください。[clprexec] コマンドについては本ガイドの「9. CLUSTERPRO コマンドリファレンス」の「クラスタサーバに処理を要求する (clprexec コマンド)」を参照してください。
外部から異常発生通知を受信して外部連携モニタリソースのステータスが "異常" となっている状態で異常発生通知を受信した場合、異常発生時の回復動作は実行されません。
回復動作が[回復対象に対してフェイルオーバ実行]の場合に、[サーバグループ外にフェイルオーバする]のチェックをONに設定している場合、フェイルオーバ先サーバは必ず、現用系サーバグループとは別のサーバグループのサーバになります。ただしこの設定の場合でも、回復対象のグループにサーバグループが設定されていない場合は、フェイルオーバ先は通常のフェイルオーバポリシーに従い決定されます。

4.21.4. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（mrw）

カテゴリとキーワードには、[clprexec] コマンドの引数 [-k] で渡すキーワードを設定します。監視対象は省略可能です。

カテゴリ (32 バイト以内)

[clprexec] コマンドの引数 [-k] で指定するカテゴリを指定します。

リストボックスでの既定文字列の選択または任意の文字列の指定が可能です。

キーワード (1023 バイト以内)

[clprexec] コマンドの引数 [-k] で指定するキーワードを指定します。

4.22. プロセス名モニタリソースを理解する

プロセス名モニタリソースは、任意のプロセス名のプロセスを監視するモニタリソースです。

4.22.1. プロセス名モニタリソースの注意事項

プロセス数下限値に1を設定した場合に監視対象に指定したプロセス名のプロセスが複数存在すると、次の条件で監視対象プロセスを一つ選択し監視します。

プロセス間に親子関係がある場合は、親プロセスを監視します。
プロセス間に親子関係がなければ、プロセスの起動時刻の最も古いものを監視します。
プロセス間に親子関係がなく、プロセスの起動時刻も同じであれば、もっともプロセスIDの小さいものを監視します。

同一名のプロセスが複数存在する場合にプロセスの起動個数によって監視を行う際には、プロセス数下限値に監視する個数を設定します。同一名プロセスが設定された個数を下回ると異常と判断します。プロセス数下限値に指定できる個数は1から999個までです。プロセス数下限値に1を設定した場合は、監視対象プロセスを一つ選択して監視します。

監視対象プロセス名に指定できるプロセス名は1023バイトまでです。1023バイトを超えるプロセス名を持つプロセスを監視対象として指定する場合は、ワイルドカード（＊）を使って指定します。

監視対象プロセスのプロセス名が1023バイトより長い場合、プロセス名として認識できるのはプロセス名の先頭から1023バイトまでです。ワイルドカード（＊）を使って指定する場合は、1023バイトまでに含まれる文字列を指定してください。

監視対象のプロセス名が長い場合、ログ等に出力されるプロセス名情報は後半を省略して表示されます。

プロセス名の中に「"」（ダブルクォーテーション）や「,」（カンマ）が含まれるプロセスを監視している場合、アラートメッセージにプロセス名が正しく表示できない場合があります

監視対象プロセス名は、実際に動作しているプロセスのプロセス名を以下のコマンドで確認し設定してください。

CLUSTERPROインストールパス\bin\GetProcess.ps1

上記コマンドを実行すると、コマンドを実行したフォルダ配下に GetProcess_Result.txt が出力されます。GetProcess_Result.txt を開き、表示されているプロセスの CommandLine 部分を指定してください。出力情報に「"」(ダブルクォーテーション)がある場合は、「"」も含めて指定してください。

出力ファイルの例

20XX/07/26 12:03:13
Caption         CommandLine
services.exe    C:\WINDOWS\system32\services.exe
svchost.exe     C:\WINDOWS\system32\svchost -k rpcss
explorer.exe    C:\WINDOWS\Explorer.EXE

上記のコマンド出力情報から svchost.exe を監視する場合、

C:\WINDOWS\system32\svchost -k rpcss を監視対象プロセス名に指定します。

監視対象プロセス名に指定したプロセス名はプロセスの引数もプロセス名の一部として監視対象のプロセスを特定します。監視対象プロセス名を指定する場合は、引数を含めたプロセス名を指定してください。引数を含めずプロセス名のみ監視したい場合は、ワイルドカード（＊）を使い、引数を含めない前方一致または部分一致で指定してください。

4.22.2. プロセス名モニタリソースの監視方法

指定されたプロセス名のプロセスを監視します。プロセス数下限値に１を設定した場合、プロセス名からプロセスIDを特定し、そのプロセスIDの消滅時に異常と判断します。プロセスのストールを検出することはできません。

プロセス数下限値に1より大きい値を設定した場合、指定されたプロセス名のプロセスを個数によって監視します。プロセス名から監視対象プロセスの個数を算出し、下限値を下回った場合に異常と判断します。プロセスのストールを検出することはできません。

4.22.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（psw）

プロセス名 (1023 バイト以内)

監視するプロセス名を設定します。必ず設定してください。

既定値：なし

また、次の3つのパターンでプロセス名のワイルドカード指定が可能です。このパターン以外の指定はできません。

【前方一致】＜プロセス名に含まれる文字列＞＊

【後方一致】＊＜プロセス名に含まれる文字列＞

【部分一致】＊＜プロセス名に含まれる文字列＞＊

プロセス数下限値（1～999）

監視対象プロセスの監視個数を設定します。プロセス名に設定した監視対象プロセスの個数が設定値を下回った場合に異常と判断します。

4.23. DB2 モニタリソースを理解する

DB2 モニタリソースは、サーバ上で動作する DB2 のデータベースを監視するモニタリソースです。

4.23.1. DB2 モニタリソースの注意事項

動作確認済みの DB2 のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」を参照してください。

監視処理は、DB2 の CLI を利用しているため、監視を行うサーバ上に、インターフェイス用の DLL (DB2CLI.DLL/DB2CLI64.DLL) がインストールされている必要があります。

監視の対象リソースには、DB2 を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後にデータベースがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視開始時に監視テーブルを作成します。フェイルオーバグループが停止することにより監視が停止する場合に、監視テーブルを削除します。監視の一時中断などの場合は、監視テーブルを削除しません。また、システム異常などで、フェイルオーバグループの停止する前にサーバダウンなどが発生した場合は、監視テーブルは削除されませんので、次回監視開始時に、「テーブルが存在する」旨のアラートメッセージが表示されることがありますが、異常ではありません。

監視動作ごとに DB2 自体が動作ログなどを出力することがありますが、その制御は、DB2側の設定で適宜行ってください。

次項の「DB2モニタリソースの監視方法」で説明する監視レベルについて、以下の点にご注意ください。
「レベル1」で監視開始時に監視テーブルが無い場合、監視エラーになります。下記の監視テーブルの作成を行ってください。
「レベル2」で監視開始時に監視テーブルが無い場合、CLUSTERPRO が監視テーブルを自動で作成します。このとき Cluster WebUI のアラートログに監視テーブルがない旨のメッセージが表示されます。

選択する監視レベル	監視テーブルの事前作成
レベル1 (selectでの監視)	必要あり
レベル2 (update/selectでの監視)	必要なし

監視テーブルの作成は以下の手順で行えます。

（以下の例は監視テーブル名をDB2WATCHとする場合）

sql> create table DB2WATCH (num int not null primary key)
sql> insert into DB2WATCH values(0)
sql> commit

4.23.2. DB2 モニタリソースの監視方法

DB2モニタリソースは、以下の監視レベルから選択した監視レベルに応じた監視を行います。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。SQL文の発行により最大１０桁の数値データの書き込みと読み込みを実行します。監視の開始時・終了時に監視テーブルの作成・削除が行われます。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
3. 書き込んだデータと読み込んだデータが一致していない場合

4.23.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（db2w）

監視レベル

選択肢の中から１つを選択します。必ず設定してください。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

既定値：レベル2(update/selectでの監視)

データベース名 (255 バイト以内)

監視するデータベース名を設定します。必ず設定してください。

既定値：なし

インスタンス名 (255バイト以内)

監視するデータベースのインスタンス名を設定します。必ず設定してください。

既定値： DB2

ユーザ名 (255 バイト以内)

データベースにログインする際のユーザ名を設定します。

既定値： db2admin

パスワード (255 バイト以内)

データベースにログインする際のパスワードを設定します。

既定値：なし

監視テーブル名 (255 バイト以内)

データベース上に作成する監視用テーブルの名前を設定します。必ず設定してください。テーブルの作成・削除を行いますので、運用に使用しているテーブル名と重ならないように注意してください。また、SQL 文の予約語と重ならないようにしてください。

データベースの仕様により監視テーブル名に設定できない文字があります。詳細はデータベースの仕様を確認してください。

既定値： DB2WATCH

4.24. FTP モニタリソースを理解する

FTP モニタリソースは、サーバ上で動作する FTP サービスを監視するモニタリソースです。FTP プロトコルを監視するものであり、特定のアプリケーションの監視ではありません。そのため、FTP プロトコルを実装するさまざまなアプリケーションの監視を行うことができます。

4.24.1. FTP モニタリソースの注意事項

監視の対象リソースには、FTP を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に FTP がすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視動作ごとに FTP サービス自体が動作ログなどを出力することがありますが、その制御は、FTP 側の設定で適宜行ってください。

FTPサーバのFTPメッセージ(バナー、接続時のメッセージなど)を既定から変更すると、監視異常とみなす場合があります。

[プロトコル] に FTPS を選択した場合、[クラスタのプロパティ] の [暗号化] タブに OpenSSL ライブラリのインストールパスを設定する必要があります。

4.24.2. FTP モニタリソースの監視方法

FTP モニタリソースは、以下の監視を行います。

FTP サーバに接続してファイル一覧取得コマンドを実行します。

監視の結果、以下の場合に異常とみなします。

FTP サービスヘの接続に失敗した場合

コマンドに対する応答で異常が通知された場合

4.24.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（ftpw）

IP アドレス (255 バイト以内)

監視する FTP サーバの IP アドレスを設定します。必ず設定してください。

通常は自サーバ上で動作する FTP サーバに接続しますので、ループバックアドレス(127.0.0.1) を設定しますが、FTP サーバの設定で接続可能なアドレスを制限している場合は、接続可能なアドレス (フローティング IP アドレス等) を設定します。

既定値： 127.0.0.1

ポート番号 (1～65535)

監視する FTP のポート番号を設定します。必ず設定してください。

既定値： 21

ユーザ名 (255 バイト以内)

FTP にログインする際のユーザ名を設定します。

既定値：なし

パスワード (255 バイト以内)

FTP にログインする際のパスワードを設定します。

既定値：なし

プロトコル

FTP サーバとの通信に使用するプロトコルを設定します。通常は FTP を選択しますが、FTP over SSL/TLS で接続する必要がある場合は FTPS を選択します。

既定値： FTP

4.25. HTTP モニタリソースを理解する

HTTP モニタリソースは、サーバ上で動作する HTTP のサービスを監視するモニタリソースです。HTTP プロトコルを監視するものであり、特定のアプリケーションの監視ではありません。そのため、HTTP プロトコルを実装するさまざまなアプリケーションの監視を行うことができます。

4.25.1. HTTP モニタリソースの注意事項

監視の対象リソースには、HTTP サービスを起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に HTTP がすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視動作ごとに HTTP サービス自体が動作ログなどを出力することがありますが、その制御は、HTTP 側の設定で適宜行ってください。

HTTP モニタリソースの DIGEST 認証で使用可能なアルゴリズムは MD5 です。

HTTP モニタリソースのクライアント認証で監視可能な Web サーバは IIS です。

[プロトコル] に HTTP を指定している場合、HTTP モニタリソースの HTTP リクエストは、デフォルトのポート番号(80)で発行を行います。

4.25.2. HTTP モニタリソースの監視方法

HTTP モニタリソースは、以下の監視を行います。

サーバ上の HTTP デーモンに接続し、HTTP リクエストの発行により、HTTP デーモンの監視を実行します。

監視の結果、以下の場合に異常とみなします。

HTTP デーモンへの接続で異常が通知された場合
HTTP リクエストの発行に対する応答メッセージが "HTTP/" で始まっていない場合
HTTP リクエストの発行に対する応答のステータスコードが 400、500 番台の場合（監視 URI に既定値以外の URI を指定した場合）

4.25.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（httpw）

接続先 (255 バイト以内)

監視する HTTP サーバの IP アドレスを設定します。必ず設定してください。

通常は自サーバ上で動作する HTTP サーバに接続しますので、ループバックアドレス(127.0.0.1) を設定しますが、HTTP サーバの設定で接続可能なアドレスを制限している場合は、接続可能なアドレス (フローティング IP アドレス等) を設定します。

既定値： 127.0.0.1

プロトコル

HTTP サーバとの通信に使用するプロトコルを設定します。通常は HTTP を選択しますが、HTTP over SSL で接続する必要がある場合は HTTPS を選択します。

注釈

[HTTPS]を選択した場合は、リクエスト種別の選択肢のうち、どちらを選択しても、GETリクエストを発行します。

ポート番号 (1～65535)

監視する HTTP のポート番号を設定します。必ず設定してください。

既定値：

80 (HTTP の場合)

443 (HTTPS の場合)

監視 URI (255 バイト以内)

監視する HTTP の URI を設定します。

指定しない場合は、ドキュメントルートに対して監視を行います。監視用のページを作成する必要はありません。

指定した場合は、指定した特定の URI に対して監視を行います。指定する URI は、匿名アクセスが可能な権限である必要があります。

記述は、以下のようにドキュメントルートからの URI で行います。

(例) 監視対象とする Web ページの URL が

http://WebServer:80/watch/sample.htm

の場合

/watch/sample.htm

既定値：なし

リクエスト種別

HTTP サーバに接続する際の HTTP リクエストの種類を設定します。必ず設定してください。

既定値： HEAD

認証方式

HTTP サーバに接続する際の認証方式を設定します。

既定値：認証なし

ユーザ名(255バイト以内)

HTTP にログインする際のユーザ名を設定します。

既定値：なし

パスワード(255バイト以内)

HTTP にログインする際のパスワードを設定します。

既定値：なし

クライアント認証

本機能を有効にした場合、クライアント認証を行います。[プロトコル]に HTTPS が選択されている場合のみ選択可能です。

注釈

クライアント認証を行わないHTTPサーバに対して本機能を有効にしても動作に影響はありません。

既定値：無効

クライアント証明書サブジェクト名(64バイト以内)

クライアント認証で使用するクライアント証明書のサブジェクト名を設定します。[クライアント認証]を有効にした場合に必ず設定してください。

注釈

[クライアント証明書サブジェクト名]に設定したサブジェクト名でローカルコンピューターの証明書ストアの「個人」に格納されているクライアント証明書を検索します。

既定値：なし

4.26. IMAP4 モニタリソースを理解する

IMAP4 モニタリソースは、サーバ上で動作する IMAP4 のサービスを監視するモニタリソースです。IMAP4 プロトコルを監視するものであり、特定のアプリケーションの監視ではありません。そのため、IMAP4 プロトコルを実装するさまざまなアプリケーションの監視を行うことができます。

4.26.1. IMAP4 モニタリソースの注意事項

監視の対象リソースには、IMAP4 サーバを起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に IMAP4 サーバがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視動作ごとに IMAP4 サーバ自体が動作ログなどを出力することがありますが、その制御は、IMAP4 サーバ側の設定で適宜行ってください。

4.26.2. IMAP4 モニタリソースの監視方法

IMAP4 モニタリソースは、以下の監視を行います。

IMAP4 サーバに接続して動作確認コマンドを実行します。

監視の結果、以下の場合に異常とみなします。

IMAP4 サーバヘの接続に失敗した場合
コマンドに対する応答で異常が通知された場合

4.26.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（imap4w）

IP アドレス (255 バイト以内)

監視する IMAP4 サーバの IP アドレスを設定します。必ず設定してください。

通常は自サーバ上で動作する IMAP4 サーバに接続しますので、ループバックアドレス(127.0.0.1) を設定しますが、IMAP4 サーバの設定で接続可能なアドレスを制限している場合は、接続可能なアドレス (フローティング IP アドレス等) を設定します。

既定値： 127.0.0.1

ポート番号 (1～65535)

監視する IMAP4 のポート番号を設定します。必ず設定してください。

既定値： 143

ユーザ名 (255 バイト以内)

IMAP4 にログインする際のユーザ名を設定します。

既定値：なし

パスワード (189 バイト以内)

IMAP4 にログインする際のパスワードを設定します。

既定値：なし

認証方式

IMAP4 にログインするときの認証方式を選択します。使用している IMAP4 の設定に合わせる必要があります。

AUTHENTICATE LOGIN (既定値)

[AUTHENTICATE LOGIN] コマンドを使用した暗号化認証方式です。

LOGIN

[LOGIN] コマンドを使用した平文方式です。

4.27. ODBC モニタリソースを理解する

ODBC モニタリソースは、サーバ上で動作する ODBC のデータベースを監視するモニタリソースです。

4.27.1. ODBC モニタリソースの注意事項

監視処理は、ODBC ドライバを利用しているため、あらかじめ、Windows の ODBCデータソースアドミニストレータを使用して、データソースの設定を行ってください。データソースは、システムデータソースに追加します。

監視の対象リソースには、データベースを起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後にデータベースがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視開始時に監視テーブルを作成します。フェイルオーバグループが停止することにより監視が停止する場合に、監視テーブルを削除します。監視の一時中断などの場合は、監視テーブルを削除しません。また、システム異常などで、フェイルオーバグループの停止する前にサーバダウンなどが発生した場合は、監視テーブルは削除されませんので、次回監視開始時に、「テーブルが存在する」旨のアラートメッセージが表示されることがありますが、異常ではありません。

監視動作ごとにデータベース自体が動作ログなどを出力することがありますが、その制御は、データベース側の設定で適宜行ってください。

次項の「ODBCモニタリソースの監視方法」で説明する監視レベルについて、以下の点にご注意ください。
「レベル1」で監視開始時に監視テーブルが無い場合、監視エラーになります。下記の監視テーブルの作成を行ってください。
「レベル2」で監視開始時に監視テーブルが無い場合、CLUSTERPROが監視テーブルを自動で作成します。このとき Cluster WebUI のアラートログに監視テーブルがない旨のメッセージが表示されます。

選択する監視レベル	監視テーブルの事前作成
レベル1(selectでの監視)	必要あり
レベル2(update/selectでの監視)	必要なし

監視テーブルの作成は以下の手順で行えます。

（以下の例は監視テーブル名をODBCWATCHとする場合）

sql> create table ODBCWATCH (num int not null primary key);
sql> insert into ODBCWATCH values(0);
sql> commit;

4.27.2. ODBC モニタリソースの監視方法

ODBCモニタリソースは、以下の監視レベルから選択した監視レベルに応じた監視を行います。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。SQL文の発行により最大１０桁の数値データの書き込みと読み込みを実行します。監視の開始時・終了時に監視テーブルの作成・削除が行われます。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
3. 書き込んだデータと読み込んだデータが一致していない場合

4.27.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（odbcw）

監視レベル

選択肢の中から１つを選択します。必ず設定してください。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

既定値：レベル2(update/selectでの監視)

データソース名 (255 バイト以内)

監視するデータソース名を設定します。必ず設定してください。

既定値：なし

ユーザ名 (255 バイト以内)

データベースにログインする際のユーザ名を設定します。データソースの設定で、ユーザ名を設定している場合は、指定する必要はありません。

既定値：なし

パスワード (255 バイト以内)

データベースにログインする際のパスワードを設定します。

既定値：なし

監視テーブル名 (255 バイト以内)

データベース上に作成する監視用テーブルの名前を設定します。必ず設定してください。テーブルの作成・削除を行いますので、運用に使用しているテーブル名と重ならないように注意してください。また、SQL 文の予約語と重ならないようにしてください。

データベースの仕様により監視テーブル名に設定できない文字があります。詳細はデータベースの仕様を確認してください。

既定値： ODBCWATCH

4.28. Oracle モニタリソースを理解する

Oracle モニタリソースは、サーバ上で動作する Oracle のデータベースを監視するモニタリソースです。

4.28.1. Oracle モニタリソースの注意事項

動作確認済みの Oracle のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」を参照してください。

監視処理は、Oracle の OCI を利用しているため、監視を行うサーバ上に、インターフェイス用の DLL (OCI.DLL) がインストールされている必要があります。

監視の対象リソースには、Oracle を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後にデータベースがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視開始時に監視テーブルを作成します。フェイルオーバグループが停止することにより監視が停止する場合に、監視テーブルを削除します。監視の一時中断などの場合は、監視テーブルを削除しません。また、システム異常などで、フェイルオーバグループの停止する前にサーバダウンなどが発生した場合は、監視テーブルは削除されませんので、次回監視開始時に、「テーブルが存在する」旨のアラートメッセージが表示されることがありますが、異常ではありません。

パラメータのOS認証のチェックがオフの場合、通常はパスワード認証でOracle監視を行いますが以下の条件の場合はOS認証でOracle監視が行われ、パラメータで指定したユーザ名およびパスワードは無視されます。

パラメータの認証方式がSYSDBAに指定されている。

Windows OSのora_dbaグループにAdministratorユーザが所属している。

パラメータのユーザ名に指定するユーザについて、デフォルトではsysとなっていますが、別途監視用ユーザを作成する場合、各監視レベルにおいて以下のアクセス権付与が必要です。（sysdba権限を与えない場合）

監視レベル	必要な権限
レベル0(データベースステータス)	V$PROCESSへのSELECT権限／V$INSTANCEへのSELECT権限
レベル1(selectでの監視)	V$PROCESSへのSELECT権限／監視テーブルへのSELECT権限
レベル2(update/selectでの監視)	V$PROCESSへのSELECT権限／CREATE TABLE／DROP ANY TABLE／監視テーブルへのINSERT権限／監視テーブルへのUPDATE権限／監視テーブルへのSELECT権限

監視動作ごとに Oracle 自体が動作ログなどを出力することがありますが、その制御は、Oracle 側の設定で適宜行ってください。

次項の「 Oracle モニタリソースの監視方法 」で説明する監視レベルについて、以下の点にご注意ください。
「レベル1」で監視開始時に監視テーブルが無い場合、監視エラーになります。下記の監視テーブルの作成を行ってください。
「レベル2」で監視開始時に監視テーブルが無い場合、CLUSTERPROが監視テーブルを自動で作成します。このとき Cluster WebUI のアラートログに監視テーブルがない旨のメッセージが表示されます。

選択する監視レベル	監視テーブルの事前作成
レベル0(データベースステータス)	必要なし
レベル1(selectでの監視)	必要あり
レベル2(update/selectでの監視)	必要なし

監視テーブルの作成は以下の手順で行えます。

（以下の例は監視テーブル名をORAWATCHとする場合）

sql> create table ORAWATCH (num int primary key);
sql> insert into ORAWATCH values(0);
sql> commit;

※パラメータのユーザ名に指定するユーザのスキーマに作成してください。

4.28.2. Oracle モニタリソースの監視方法

Oracle モニタリソースは、以下の監視レベルから選択した監視レベルに応じた監視を行います。

レベル0(データベースステータス)

Oracle の管理テーブル（ V$INSTANCE 表）を参照しDBの状態（インスタンスの状態）を確認します。監視テーブルに対してSQL文の発行は行わない簡易的な監視です。

監視の結果以下の場合に異常とみなします。
1. Oracle の管理テーブル( V$INSTANCE 表)のステータス（ status ）が未起動状態（ MOUNTED,STARTED ）の場合
2. Oracle の管理テーブル( V$INSTANCE 表)のデータベースステータス（ database_status ）が未起動（ SUSPENDED,INSTANCE RECOVERY ）の場合
レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。SQL文の発行により最大 10 桁の数値データの書き込みと読み込みを実行します。監視の開始時・終了時に監視テーブルの作成・削除が行われます。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
3. 書き込んだデータと読み込んだデータが一致していない場合

4.28.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（oraclew）

監視方式

監視対象とする Oracle の機能を選択します。

リスナーとインスタンスを監視

監視レベルに設定されたレベルに応じ、データベースへの接続、参照、更新の動作を監視します。

リスナーのみ監視

リスナーが動作しているかをOracleのコマンド（tnsping）を実行し監視します。モニタリソースプロパティでORACLE_HOMEを設定しておく必要があります。

ORACLE_HOMEが設定されていない場合、接続文字列に指定されている先に対して接続処理の動作のみ監視します。接続異常時にリスナーのサービス再起動による復旧を試みる場合に使用します。

本設定を選択した場合、監視レベルの設定は無視されます。

インスタンスのみ監視

データベースに対しリスナーを経由せず直接接続（BEQ接続）を行い、監視レベルに設定されたレベルに応じ、データベースへの接続、参照、更新の動作を監視します。モニタリソースプロパティで ORACLE_HOME を設定しておく必要があります。この方式はリスナーを経由せずインスタンスを直接監視し復旧動作を設定するために使用します。

ORACLE_HOME が設定されていない場合、接続文字列に指定されている先に対して接続を行い、接続処理で異常があった場合は無視します。この方式は、[リスナーのみ監視] 方式の Oracle モニタリソースと併用して、接続処理以外の異常に対する復旧動作を設定するために使用します。

既定値：リスナーとインスタンスを監視

監視レベル

選択肢の中から１つを選択します。必ず設定してください。

レベル0(データベースステータス)

Oracle の管理テーブル（ V$INSTANCE 表）を参照しDBの状態（インスタンスの状態）を確認します。監視テーブルに対してSQL文の発行は行わない簡易的な監視です。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行する SQL文は( select )です。

レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

既定値：レベル2(update/selectでの監視)

接続文字列 (255 バイト以内)

監視するデータベースの接続文字列を設定します。必ず設定してください。

監視方式を「インスタンスのみの監視」とした場合にはORACLE_SIDを設定します。

監視方式

ORACLE_HOME

接続文字列

監視レベル

リスナーとインスタンスを監視

入力不要

接続文字列を指定

設定に応じたレベルの監視

リスナーのみ監視

入力した場合、Oracleのコマンドを使用した監視

接続文字列を指定

レベル設定は無視される

〃

未入力の場合、リスナーを経由したインスタンスへの接続確認

接続文字列を指定

レベル設定は無視される

インスタンスのみ監視

入力した場合、BEQ接続によるインスタンスの確認

ORACLE_SIDを指定する

設定に応じたレベルの監視

〃

未入力の場合、リスナーを経由したインスタンスの確認となる

接続文字列を指定

設定に応じたレベルの監視

既定値：接続文字列の既定値はなし

ユーザ名 (255 バイト以内)

データベースにログインする際のユーザ名を設定します。監視方式として [リスナーのみ監視] 以外を選択している場合、および OS 認証を使用する場合は、必ず設定してください。

既定値： sys

パスワード (255 バイト以内)

データベースにログインする際のパスワードを設定します。

既定値：なし

OS 認証

Oracle にログインするときの認証方式を指定します。Oracle の設定に合わせる必要があります。

チェックボックスがオン

OS 認証を使用します。

チェックボックスがオフ (既定値)

データベース認証を使用します。

認証方式

Oracle にログインするときのユーザの権限を選択します。指定したユーザ名の権限に合わせる必要があります。

SYSDBA (既定値)

SYSDBA 権限で接続します。

DEFAULT

一般ユーザ権限で接続します。

監視テーブル名 (255 バイト以内)

データベース上に作成する監視用テーブルの名前を設定します。必ず設定してください。テーブルの作成・削除を行いますので、運用に使用しているテーブル名と重ならないように注意してください。また、SQL 文の予約語と重ならないようにしてください。

データベースの仕様により監視テーブル名に設定できない文字があります。詳細はデータベースの仕様を確認してください。

既定値： ORAWATCH

ORACLE_HOME (255 バイト以内)

ORACLE_HOMEに設定しているパス名を指定します。[/] で始まる必要があります。監視方式で「リスナーのみ監視」「インスタンスのみ監視」を選択したときに使用されます。

既定値：なし

文字コード

Oracle のキャラクタ・セットを選択します。

(Following the setting of the application) (既定値)

サーバにインストールされた Oracle のキャラクタセットを使用します。

AMERICAN_AMERICA.US7ASCII

Oracleの言語が日本語および英語以外の場合、AMERICAN_AMERICA.US7ASCIIを選択してください。

障害発生時にアプリケーションの詳細情報を採取する

Oracle データベースの異常を検出した場合に Oracle の詳細情報を採取するかどうかを指定します。

チェックボックスがオン

Oracle の詳細情報を採取します。

チェックボックスがオフ (既定値)

Oracle の詳細情報を採取しません。

この機能を使用する場合、情報採取のためのデータベース処理をローカルシステムアカウントで実行するため、ローカルシステムアカウントに DBA 権限が必要です。採取した情報はCLUSTERPRO インストールフォルダ配下の work\rm\リソース名\ errinfo.cur フォルダに保存されます。採取が複数回実行された場合は、過去の採取情報のフォルダ名がerrinfo.1、errinfo.2 とリネームされ、最大 5 世代分まで保存されます。

注釈

採取中にクラスタ停止などにより、Oracle サービスを停止させた場合、正しい情報が取得できない可能性があります。

採取中はグループ停止やグループ移動など手動での操作は行わないでください。手動での操作を行うタイミングによっては、その後の監視処理が正常に動作しない可能性があります。

採取タイムアウト (1～9999)

詳細情報採取時のタイムアウト時間を秒単位で指定します。

既定値：600

Oracleの初期化中またはシャットダウン中をエラーにする

本機能をオンにした場合、Oracleの初期化またはシャットダウン中の状態を検出すると、直ちに監視エラーになります。

Oracle Clusterware等の連携でOracleが運用中に自動で再起動される場合、本機能をオフにしてください。Oracle の初期化またはシャットダウン中の状態でも監視正常になります。

ただし１時間以上Oracleの初期化またはシャットダウン中の状態が続くと監視エラーになります。

既定値：オフ

4.29. POP3 モニタリソースを理解する

POP3 モニタリソースは、サーバ上で動作する POP3 のサービスを監視するモニタリソースです。POP3 プロトコルを監視するものであり、特定のアプリケーションの監視ではありません。そのため、POP3 プロトコルを実装するさまざまなアプリケーションの監視を行うことができます。

4.29.1. POP3 モニタリソースの注意事項

監視の対象リソースには、POP3 サーバを起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に POP3 がすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視動作ごとに POP3 自体が動作ログなどを出力することがありますが、その制御は、POP3 側の設定で適宜行ってください。

[認証方式]に POP3S を選択した場合、[クラスタのプロパティ] の [暗号化] タブに OpenSSL ライブラリのインストールパスを設定する必要があります。

4.29.2. POP3 モニタリソースの監視方法

POP3 モニタリソースは、以下の監視を行います。

POP3 サーバに接続して動作確認コマンドを実行します。

監視の結果、以下の場合に異常とみなします。

POP3 サーバヘの接続に失敗した場合

コマンドに対する応答で異常が通知された場合

4.29.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（pop3w）

IP アドレス (255 バイト以内)

監視する POP3 サーバの IP アドレスを設定します。必ず設定してください。

通常は自サーバ上で動作する POP3 サーバに接続しますので、ループバックアドレス(127.0.0.1) を設定しますが、POP3 サーバの設定で接続可能なアドレスを制限している場合は、接続可能なアドレス (フローティング IP アドレス等) を設定します。

既定値： 127.0.0.1

認証方式

POP3 にログインするときの認証方式を選択します。使用している POP3 の設定に合わせる必要があります。

APOP (既定値)

[APOP] コマンドを使用した暗号化認証方式です。

USER/PASS

[USER/PASS] コマンドを使用した平文方式です。

POP3S

SSL/TLSを使用した暗号化認証方式です。

ポート番号 (1～65535)

監視する POP3 のポート番号を設定します。必ず設定してください。

既定値：

110

995 (POP3S の場合)

ユーザ名 (255 バイト以内)

POP3 にログインする際のユーザ名を設定します。

既定値：なし

パスワード (255 バイト以内)

POP3 にログインする際のパスワードを設定します。

既定値：なし

4.30. PostgreSQL モニタリソースを理解する

PostgreSQL モニタリソースは、サーバ上で動作する PostgreSQL データベースを監視するモニタリソースです。

4.30.1. PostgreSQL モニタリソースの注意事項

動作確認済みの PostgreSQL/PowerGres のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」を参照してください。

監視処理は、PostgreSQL/PowerGres のライブラリを利用しているため、監視を行うサーバ上に、インターフェイス用の DLL (LIBPQ.DLL) がインストールされている必要があります。PostgreSQL の監視を行う際は、この DLL のパスを環境変数に設定してください。

監視の対象リソースには、PostgreSQL/PowerGres を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後にデータベースがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視開始時に監視テーブルを作成します。フェイルオーバグループが停止することにより監視が停止する場合に、監視テーブルを削除します。監視の一時中断などの場合は、監視テーブルを削除しません。また、システム異常などで、フェイルオーバグループの停止する前にサーバダウンなどが発生した場合は、監視テーブルは削除されませんので、次回監視開始時に、「テーブルが存在する」旨のアラートメッセージが表示されることがありますが、異常ではありません。

監視動作ごとに PostgreSQL/PowerGres 自体が動作ログなどを出力することがありますが、その制御は、PostgreSQL/PowerGres 側の設定で適宜行ってください。

PostgreSQL は、オープンソースソフトウェア (OSS) のため、動作確認はしますが、動作保証はしません。各自で評価を行った後、運用してください。

OS及びPostgreSQLのバージョンによっては、PostgreSQL監視を行うと、ライブラリが見つからないエラーが出力されることがあります。この場合は、システム環境変数のPATHにPostgreSQLのbinを追加してください。その後、クラスタ再起動を行ってください。

環境変数にPATHを追加する場合（以下はPostgreSQL 18 の bin の PATH の例）

C:\Program Files\PostgreSQL\18\bin

本モニタリソースを利用すると PostgreSQL 側のログに下記のようなメッセージが出力されます。監視処理に伴って出力されるメッセージで、問題はありません。

YYYY-MM-DD hh:mm:ss JST moodle moodle LOG: statement: DROP TABLE psqlwatch
YYYY-MM-DD hh:mm:ss JST moodle moodle ERROR: table "psqlwatch" does not exist
YYYY-MM-DD hh:mm:ss JST moodle moodle STATEMENT: DROP TABLE psqlwatch
YYYY-MM-DD hh:mm:ss JST moodle moodle LOG: statement: CREATE TABLE psqlwatch (num INTEGER NOT NULL PRIMARY KEY)
YYYY-MM-DD hh:mm:ss JST moodle moodle NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "psqlwatch_pkey" for table "psql watch"
YYYY-MM-DD hh:mm:ss JST moodle moodle LOG: statement: DROP TABLE psqlwatch

次項の「PostgreSQLモニタリソースの監視方法」で説明する監視レベルについて、以下の点にご注意ください。
「レベル1」で監視開始時に監視テーブルが無い場合、監視エラーになります。下記の監視テーブルの作成を行ってください。
「レベル2」で監視開始時に監視テーブルが無い場合、CLUSTERPROが監視テーブルを自動で作成します。このときCluster WebUI のアラートログに監視テーブルがない旨のメッセージが表示されます。

選択する監視レベル	監視テーブルの事前作成
レベル1(selectでの監視)	必要あり
レベル2(update/selectでの監視)	必要なし

監視テーブルの作成は以下の手順で行えます。

（以下の例は監視テーブル名をPSQLWATCHとする場合）

sql> create table PSQLWATCH (num int not null primary key);
sql> insert into PSQLWATCH values(0);
sql> commit;

4.30.2. PostgreSQL モニタリソースの監視方法

PostgreSQLモニタリソースは、以下の監視レベルから選択した監視レベルに応じた監視を行います。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。SQL文の発行により最大 10 桁の数値データの書き込みと読み込みを実行します。監視の開始時・終了時に監視テーブルの作成・削除が行われます。監視テーブルに対して発行するSQL文は（ create / update / select / reindex / drop / vacuum ）です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
3. 書き込んだデータと読み込んだデータが一致していない場合

4.30.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（psqlw）

監視レベル

選択肢の中から１つを選択します。必ず設定してください。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。監視テーブルに対して発行するSQL文は（ create / update / select / reindex / drop / vacuum ）です。

既定値：レベル2(update/selectでの監視)

データベース名 (255 バイト以内)

監視するデータベース名を設定します。必ず設定してください。

既定値：なし

IP アドレス

監視するデータベースサーバの IP アドレスを設定します。必ず設定してください。

既定値： 127.0.0.1

ポート番号

監視する PostgreSQL のポート番号を設定します。必ず設定してください。

既定値： 5432

ユーザ名 (255 バイト以内)

データベースにログインする際のユーザ名を設定します。

既定値： postgres

パスワード (255 バイト以内)

データベースにログインする際のパスワードを設定します。

既定値：なし

監視テーブル名 (255 バイト以内)

データベース上に作成する監視用テーブルの名前を設定します。必ず設定してください。テーブルの作成・削除を行いますので、運用に使用しているテーブル名と重ならないように注意してください。また、SQL 文の予約語と重ならないようにしてください。

データベースの仕様により監視テーブル名に設定できない文字があります。詳細はデータベースの仕様を確認してください。

既定値： PSQLWATCH

PostgreSQLの初期化中またはシャットダウン中をエラーにする

本機能を有効にした場合、PostgreSQL の初期化中またはシャットダウン中の状態を検出すると、直ちに監視エラーになります。本機能を無効にした場合、PostgreSQL の初期化中またはシャットダウン中の状態でも監視正常になります。ただし1時間以上PostgreSQLの初期化中またはシャットダウン中の状態が継続すると監視エラーになります。

既定値：有効

4.31. SMTP モニタリソースを理解する

SMTP モニタリソースは、サーバ上で動作する SMTP のサービスを監視するモニタリソースです。SMTP プロトコルを監視するものであり、特定のアプリケーションの監視ではありません。そのため、SMTP プロトコルを実装するさまざまなアプリケーションの監視を行うことができます。

4.31.1. SMTP モニタリソースの注意事項

監視の対象リソースには、SMTP を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後にデータベースがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視動作ごとに SMTP 自体が動作ログなどを出力することがありますが、その制御は、SMTP 側の設定で適宜行ってください。

4.31.2. SMTP モニタリソースの監視方法

SMTP モニタリソースは、以下の監視を行います。

SMTP サーバに接続して動作確認コマンドを実行します。

監視の結果、以下の場合に異常とみなします。

SMTP サーバヘの接続に失敗した場合

コマンドに対する応答で異常が通知された場合

4.31.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（smtpw）

IP アドレス

監視する SMTP サーバの IP アドレスを設定します。必ず設定してください。

既定値： 127.0.0.1

ポート番号

監視する SMTP のポート番号を設定します。必ず設定してください。

既定値： 25

ユーザ名 (255 バイト以内)

SMTP にログインする際のユーザ名を設定します。ユーザ名が指定されていない場合は、SMTP 認証を行いません。

既定値：なし

パスワード (255 バイト以内)

SMTP にログインする際のパスワードを設定します。

既定値：なし

認証方式

SMTP にログインするときの認証方式を選択します。使用している SMTP の設定に合わせる必要があります。

CRAM-MD5 (既定値)

CRAM-MD5 を使用した暗号化認証方式です。

LOGIN

[LOGIN] コマンドを使用した平文方式です。

メールアドレス (255 バイト以内)

監視する際のメールアドレスを設定します。

指定しない場合は、動作確認コマンドのみで監視を行います。内部では、ダミーのメールアドレスを使用したコマンドを実行します。

指定した場合は、指定したメールアドレスに対して [SMTP] コマンドを実行し、その結果を確認することによって監視を行います。指定する場合は、監視専用のメールアドレスを用意することを推奨します。

既定値：なし

4.32. SQL Server モニタリソースを理解する

SQL Server モニタリソースは、サーバ上で動作する SQL Server のデータベースを監視するモニタリソースです。

4.32.1. SQL Server モニタリソースの注意事項

動作確認済みの SQL Server のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」を参照してください。

監視の対象リソースには、SQL Server を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後にデータベースがすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視開始時に監視テーブルを作成します。フェイルオーバグループが停止することにより監視が停止する場合に、監視テーブルを削除します。監視の一時中断などの場合は、監視テーブルを削除しません。また、システム異常などで、フェイルオーバグループの停止する前にサーバダウンなどが発生した場合は、監視テーブルは削除されませんので、次回監視開始時に、「テーブルが存在する」旨のアラートメッセージが表示されることがありますが、異常ではありません。

監視動作ごとに SQL Server 自体が動作ログなどを出力することがありますが、その制御は、SQL Server 側の設定で適宜行ってください。

次項の「SQL Serverモニタリソースの監視方法」で説明する監視レベルについて、以下の点にご注意ください。
「レベル1」で監視開始時に監視テーブルが無い場合、監視エラーになります。下記の監視テーブルの作成を行ってください。
「レベル2」で監視開始時に監視テーブルが無い場合、CLUSTERPROが監視テーブルを自動で作成します。このときCluster WebUI のアラートログに監視テーブルがない旨のメッセージが表示されます。

選択する監視レベル	監視テーブルの事前作成
レベル0(データベースステータス)	必要なし
レベル1(selectでの監視)	必要あり
レベル2(update/selectでの監視)	必要なし

監視テーブルの作成は以下の手順で行えます。

（以下の例は監視テーブル名をSQLWATCHとする場合）

SET IMPLICIT_TRANSACTIONSがオフの場合

sql> create table SQLWATCH (num int not null primary key)
sql> go
sql> insert into SQLWATCH values(0)
sql> go

SET IMPLICIT_TRANSACTIONSがオンの場合

sql> create table SQLWATCH (num int not null primary key)
sql> go
sql> insert into SQLWATCH values(0)
sql> go
sql> commit
sql> go

4.32.2. SQL Server モニタリソースの監視方法

SQL Server モニタリソースは、以下の監視レベルから選択した監視レベルに応じた監視を行います。

レベル0(データベースステータス)

SQL Server の管理テーブルを参照しDBの状態を確認します。監視テーブルに対してSQL文の発行は行わない簡易的な監視です。

監視の結果以下の場合に異常とみなします。
1. データベースのステータスがオンラインでない場合
レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。SQL文の発行により最大 10 桁の数値データの書き込みと読み込みを実行します。監視の開始時・終了時に監視テーブルの作成・削除が行われます。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

監視の結果以下の場合に異常とみなします。
1. データベースへの接続に失敗した場合
2. SQL文の発行に対する応答で異常が通知された場合
3. 書き込んだデータと読み込んだデータが一致していない場合

4.32.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（sqlserverw）

監視レベル

選択肢の中から１つを選択します。必ず設定してください。

レベル0(データベースステータス)

SQL Server の管理テーブルを参照しDBの状態を確認します。監視テーブルに対してSQL文の発行は行わない簡易的な監視です。

レベル1(selectでの監視)

監視テーブルに対して参照のみを行う監視です。監視テーブルに対して発行するSQL文は( select )です。

レベル2(update/selectでの監視)

監視テーブルに対して更新も行う監視です。監視テーブルに対して発行するSQL文は（ create / update / select / drop ）です。

既定値：レベル2(update/selectでの監視)

データベース名 (255 バイト以内)

監視するデータベース名を設定します。必ず設定してください。

既定値：なし

インスタンス名 (255 バイト以内)

監視するデータベースのインスタンス名を設定します。必ず設定してください。

既定値： MSSQLSERVER

ユーザ名 (255 バイト以内)

データベースにログインする際のユーザ名を設定します。ユーザ名を指定しなかった場合は、Windows 認証として動作します。

既定値： SA

パスワード (255 バイト以内)

データベースにログインする際のパスワードを設定します。

既定値：なし

監視テーブル名 (255 バイト以内)

データベース上に作成する監視用テーブルの名前を設定します。必ず設定してください。テーブルの作成・削除を行いますので、運用に使用しているテーブル名と重ならないように注意してください。また、SQL 文の予約語と重ならないようにしてください。

データベースの仕様により監視テーブル名に設定できない文字があります。詳細はデータベースの仕様を確認してください。

既定値： SQLWATCH

ODBC ドライバ名 (255 バイト以内)

対象データベースの ODBC ドライバ名を設定します。

ODBC ドライバ名は、[ODBC データソースアドミニストレーター] の [ドライバ] タブで確認できます。

SQL Server 2014の場合は [SQL Server Native Client 11.0]

SQL Server 2016、SQL Server 2017 の場合は [ODBC Driver 13 for SQL Server]

SQL Server 2019、SQL Server 2022 の場合は [ODBC Driver 17 for SQL Server]

を選択、または直接入力してください。

既定値： ODBC Driver 13 for SQL Server

4.33. Tuxedo モニタリソースを理解する

Tuxedo モニタリソースは、サーバ上で動作する Tuxedo を監視するモニタリソースです。

4.33.1. Tuxedo モニタリソースの注意事項

動作確認済みの Tuxedo のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」を参照してください。

監視の対象リソースには、Tuxedo を起動するスクリプトリソース、アプリケーションリソースを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に Tuxedo がすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

監視動作ごとに Tuxedo 自体が動作ログなどを出力することがありますが、その制御は、Tuxedo 側の設定で適宜行ってください。

4.33.2. Tuxedo モニタリソースの監視方法

Tuxedo モニタリソースは、以下の監視を行います。

Tuxedo の API を利用して、アプリケーションサーバの監視を実行します。

監視の結果、以下の場合に異常とみなします。

アプリケーションサーバへの接続や状態取得に対する応答で異常が通知された場合

4.33.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（tuxw）

アプリケーションサーバ名 (255 バイト以内)

監視するアプリケーションサーバ名を設定します。必ず設定してください。

既定値： BBL

TUXCONFIG ファイル (1023 バイト以内)

Tuxedo の配置ファイル名を設定します。必ず設定してください。

既定値：なし

4.34. WebSphere モニタリソースを理解する

WebSphere モニタリソースは、サーバ上で動作する WebSphere を監視するモニタリソースです。

4.34.1. WebSphere モニタリソースの注意事項

動作確認済みの WebSphere のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」」を参照してください。

監視の対象リソースには、WebSphere を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に WebSphere がすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

本モニタリソースで監視を行うためには Java 環境が必要です。アプリケーションサーバシステムは Java の機能を利用しているため、Java のストールなどが発生した場合も異常とみなすことがあります。

監視動作ごとに WebSphere サービス自体が動作ログなどを出力することがありますが、その制御は、WebSphere 側の設定で適宜行ってください。

4.34.2. WebSphere モニタリソースの監視方法

WebSphere モニタリソースは、以下の監視を行います。

WebSphere の [serverStatus.bat] コマンドを利用して、アプリケーションサーバの監視を実行します。

監視の結果、以下の場合に異常とみなします。

取得したアプリケーションサーバの状態で異常が通知された場合

4.34.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（wasw）

アプリケーションサーバ (255 バイト以内)

監視するアプリケーションサーバ名を設定します。必ず設定してください。

既定値： server1

プロファイル名 (1023 バイト以内)

WebSphere のプロファイル名を設定します。必ず設定してください。

既定値： default

ユーザ名 (255 バイト以内)

WebSphere のユーザ名を設定します。必ず設定してください。

既定値：なし

パスワード (255 バイト以内)

WebSphere のパスワードを設定します。

既定値：なし

インストールパス (255 バイト以内)

WebSphere のインストールパスを設定します。必ず設定してください。

既定値： C:\Program Files\IBM\WebSphere\AppServer

4.35. WebLogic モニタリソースを理解する

WebLogic モニタリソースは、サーバ上で動作する WebLogic を監視するモニタリソースです。

4.35.1. WebLogic モニタリソースの注意事項

動作確認済みのWebLogicのバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」」を参照してください。

WebLogic 起動時にすぐに動作できない場合は異常とみなしてしまうため、[監視開始待ち時間] で調整してください。もしくは、WebLogic を先に起動するようにしてください(例：監視の対象リソースに、WebLogic を起動するスクリプトリソース、アプリケーションリソースを指定)。

本モニタリソースで監視方式に [WLST] を選択した場合は、監視を行うために Java 環境が必要です。アプリケーションサーバシステムは Java の機能を利用しているため、Java のストールなどが発生した場合も異常とみなすことがあります。

監視動作ごとに WebLogic 自体が動作ログなどを出力することがありますが、その制御は、WebLogic 側の設定で適宜行ってください。

4.35.2. WebLogic モニタリソースの監視方法

WebLogic モニタリソースは、以下の監視を行います。

監視方式：RESTful API を選択した場合

WebLogicでは WebLogic RESTful 管理サービスという RESTful API が用意されています。

このRESTful API を通してアプリケーションサーバの監視を実行します。

監視の結果、以下の応答で異常が通知された場合に異常とみなします。
1. RESTful API の応答で異常が通知された場合
注釈

監視方式：WLST と比較して、監視時のアプリケーションサーバのCPU負荷を低減できます。
監視方式：WLST を選択した場合

[weblogic.WLST] コマンドを利用して connect を行うことで、アプリケーションサーバの監視を実行します。

監視の結果、以下の場合に異常とみなします。
1. connect の応答で異常が通知された場合
[認証方式] により以下の動作となります。
- DemoTrust: WebLogic のデモ用認証ファイルを使用した SSL 認証方式
- CustomTrust: ユーザ作成認証ファイルを使用した SSL 認証方式
- Not Use SSL: SSL認証を行わない

4.35.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（wlsw）

IP アドレス (79 バイト以内)

監視するサーバの IP アドレスを設定します。必ず設定してください。

既定値： 127.0.0.1

ポート番号 (1～65535)

サーバに接続する際のポート番号を設定します。必ず設定してください。

既定値： 7002

監視方式

サーバの監視方式を設定します。必ず設定してください。

既定値： RESTful API

プロトコル

監視するサーバのプロトコルを設定します。[監視方式]に RESTful API を選択した場合に必ず選択してください。

既定値： HTTP

ユーザ名 (255 バイト以内)

WebLogic のユーザ名を設定します。[監視方式]に RESTful API を選択した場合に必ず入力してください。

既定値： weblogic

パスワード (255 バイト以内)

WebLogic のパスワードを設定します。[監視方式]に RESTful API を選択した場合に必要に応じて入力してください。

既定値：なし

アカウントの隠蔽

ユーザ名とパスワードを直接指定する場合は [しない] を、ファイル内に記述する場合は [する] を指定してください。必ず設定してください。

既定値：しない

コンフィグファイル (1023 バイト以内)

ユーザ情報を保持しているファイル名を設定します。アカウントの隠蔽 [する] の場合、必ず設定してください。

既定値：なし

キーファイル名 (1023 バイト以内)

コンフィグファイルパスにアクセスするためのパスワードを保存しているファイル名を、フルパスで設定します。アカウントの隠蔽 [する] の場合、必ず設定してください。

既定値：なし

ユーザ名 (255 バイト以内)

WebLogic のユーザ名を設定します。アカウントの隠蔽 [しない] の場合、必ず設定してください。

既定値：weblogic

パスワード (255 バイト以内)

WebLogic のパスワードを設定します。

既定値：なし

認証方式

アプリケーションサーバに接続する際の認証方式を設定します。必ず設定してください。

SSL 通信を用いた監視を行いたい場合、[認証方式] に [DemoTrust] または [CustomTrust] を指定してください。

[DemoTrust]、[CustomTrust] のいずれを選択するかは、WebLogic Administration Console 上の設定により異なります。

WebLogic Administration Console の[キーストア]が[デモ・アイデンティティとデモ信頼]の場合、[DemoTrust] を指定してください。この場合、[キーストアファイル] の設定は不要です。

WebLogic Administration Console の[キーストア]が[カスタム・アイデンティティとカスタム信頼]の場合、[CustomTrust] を指定してください。この場合、[キーストアファイル] の設定が必要です。

既定値： DemoTrust

キーストアファイル (1023 バイト以内)

SSL 認証時の認証ファイルを設定します。認証方式が [CustomTrust] の場合、必ず設定してください。WebLogic Administration Console 上の[カスタム・アイデンティティ・キーストア]で指定しているファイルを設定してください。

既定値：なし

インストールパス (255 バイト以内)

WebLogic のインストールパスを設定します。必ず設定してください。

既定値： C:\Oracle\Middleware\Oracle_Home\wlserver

追加コマンドオプション (1023 バイト以内)

[webLogic.WLST] コマンドへ渡すオプションを変更する場合に設定します。

既定値： -Dwlst.offline.log=disable -Duser.language=en_US

4.36. WebOTX モニタリソースを理解する

WebOTX モニタリソースは、サーバ上で動作する WebOTX を監視するモニタリソースです。

4.36.1. WebOTX モニタリソースの注意事項

動作確認済みの WebOTX のバージョンについては、『スタートアップガイド』の「CLUSTERPRO の動作環境」 - 「CLUSTERPRO Server の動作環境」 - 「監視オプションの動作確認済アプリケーション情報」を参照してください。

監視の対象リソースには、WebOTX を起動するサービスリソースやスクリプトリソースなどを指定してください。対象リソースの活性後、監視を開始しますが、対象リソースの活性直後に WebOTX がすぐに動作できない場合などは、[監視開始待ち時間] で調整してください。

本モニタリソースで監視を行うためには Java 環境が必要です。アプリケーションサーバシステムは Java の機能を利用しているため、Java のストールなどが発生した場合も異常とみなすことがあります。

監視動作ごとに WebOTX サービス自体が動作ログなどを出力することがありますが、その制御は、WebOTX 側の設定で適宜行ってください。

WebOTX モニタリソースは WebOTX が提供する otxadmin.bat コマンドを利用して、アプリケーションサーバの監視を行います。WebOTX V10.1以降では otxadmin.bat コマンドが配置されている ${AS_INSTALL}\bin が環境変数 PATH に含まれなくなりました。WebOTX V10.1 以降を監視する場合は、以下のいずれかの設定をしてください。

システム環境変数 PATH に [otxadmin.bat] コマンドが配置されているパスを追加。
[インストールパス]に WebOTX Application Server のインストールパスを設定(例. C:\WebOTX)。

4.36.2. WebOTX モニタリソースの監視方法

WebOTX モニタリソースは、以下の監視を行います。

WebOTX の [otxadmin.bat] コマンドを利用して、アプリケーションサーバの監視を実行します。

監視の結果、以下の場合に異常とみなします。

取得したアプリケーションサーバの状態で異常が通知された場合

4.36.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（otxw）

接続先 (255 バイト以内)

監視するサーバのサーバ名を設定します。必ず設定してください。

既定値： localhost

ポート番号 (1～65535)

サーバに接続する際のポート番号を設定します。必ず設定してください。

WebOTX ユーザドメインを監視する場合、WebOTX ドメインの管理ポート番号を設定してください。管理ポート番号とは、ドメイン作成時に <ドメイン名>.properties の domain.admin.port にて設定したポート番号です。<ドメイン名>.properties の詳細については WebOTX のドキュメントを参照してください。

既定値： 6212

ユーザ名 (255 バイト以内)

WebOTX のユーザ名を設定します。必ず設定してください。

WebOTX ユーザドメインを監視する場合、WebOTX ドメインのログインユーザ名を設定してください。

既定値：なし

パスワード (255 バイト以内)

WebOTX のパスワードを設定します。

既定値：なし

インストールパス (255 バイト以内)

WebOTX Application Server のインストールパスを設定します。WebOTX Application Server V10.1 以降を監視する場合は必ず設定してください。

既定値：なし

4.37. JVMモニタリソースを理解する

JVMモニタリソースは、サーバ上で動作するJava VMやアプリケーションサーバが使用するリソースの利用情報を監視するモニタリソースです。

4.37.1. JVMモニタリソースの注意事項

JVMモニタリソースを作成する前に[クラスタのプロパティ]の[JVM監視]タブの[Javaインストールパス]を前もって設定しておく必要があります。
監視対象のリソースには、WebLogic ServerやWebOTXなどJava VM上で動作するアプリケーションサーバを指定してください。JVMモニタリソースの活性後、Java Resource Agentは監視を開始しますが、JVMモニタリソースの活性直後に監視対象(WebLogic ServerやWebOTX)がすぐに動作できない場合は、[監視開始待ち時間]で調整してください。
[監視(共通)]-[リトライ回数]の設定は無効です。異常の検出を遅らせたい場合は、[クラスタのプロパティ]-[JVM監視]タブ-[リソース計測設定]-[共通]-[リトライ回数]の設定を変更してください。

4.37.2. JVMモニタリソースの監視方法

JVMモニタリソースは、以下の監視を行います。

JMX(Java Management Extensions)を利用して、アプリケーションサーバの監視を実行します。

監視の結果、以下の場合に異常とみなします。

監視対象のJava VMやアプリケーションサーバに接続できない場合
取得したJava VMやアプリケーションサーバのリソース使用量がお客様定義のしきい値を規定回数(異常判定しきい値)連続して超えた場合

監視の結果、以下の場合に異常から正常へ復帰したとみなします。

回復動作後の監視を再開時にしきい値を下回った場合

注釈

Cluster WebUI の[クラスタログ収集]では、監視対象(WebLogicやWebOTX)の設定ファイルおよびログファイルは収集されません。

図はJVMモニタリソースによる監視動作を表しています。
a)で監視対象のJava VMの監視を開始します。
Java VMの監視にはJMX（Java Management Extensions）を利用します。
Java Resource AgentがJMXを通じてJava VMに対して定期的に使用リソース量を取得することでJava VMの状態をチェックします。
状態が正常から異常へ変化した場合、b)でJava VMの異常を検出したことをCluster WebUIに表示します。
状態とアラートを確認することができます。
さらにc)で、障害があったことをイベントログやJVM運用ログへ通知します。
アラートサービスをご利用の場合、Eメール通報も可能です。
a)の後、状態が異常から正常に変化した場合、d)でJava VMの正常復帰を検出したことをCluster WebUIに表示します。
さらにe)で正常復旧した旨をイベントログやJVM運用ログへ通知します。

_images/img_w_how-jvm-monitor-resources-perform-monitoring-10.png — 図 4.63 JVMモニタリソースによる監視フロー

基本的なしきい値超過時の動作は以下の通りです。

図の横軸は時間の経過を表しており、縦軸は監視のしきい値を超えた（Exceeded）か超えていない（Not exceeded）かを表しています。

ここで、監視時のしきい値を超える状態が異常判定しきい値回（図では5回）以上連続すると、異常と判断します。

_images/img_how-jvm-monitor-resources-perform-monitoring-20.png — 図 4.64 しきい値超過時の動作

異常が継続する場合は以下の通りです

しきい値の超過が異常判定しきい値回連続して発生した場合、異常状態と判断します。

異常状態と判断後、再度異常判定しきい値回連続してしきい値を超過していても、Cluster WebUIには再度アラートは表示されません。

_images/img_how-jvm-monitor-resources-perform-monitoring-30.png — 図 4.65 異常継続時の動作

Full GC(Garbage Collection)を監視する場合を例に説明します。

図の横軸は時間の経過を表しています。
そして、図の上段は各監視タイミングでGCの発生を検出したか否かを示し、下段はそれぞれの時点で Full GC検出が何回連続しているかを示しています。
JVMモニタリソースは、異常判定しきい値回連続して Full GCが発生すると、モニタ異常を検出します。
異常判定しきい値を5回に設定しているので、 Full GC検出が 5回に達した時点でモニタ異常を検出します。

Full GCはシステムに与える影響が大きいため、異常判定しきい値は1回に設定することを推奨します。

_images/img_how-jvm-monitor-resources-perform-monitoring-40.png — 図 4.66 監視イメージ（異常判定しきい値を5回に設定した場合）

4.37.3. JVM統計ログとは

JVMモニタリソースが収集する監視対象Java VMの統計情報を保存したファイルが、JVM統計ログです。ファイル形式はcsv形式です。作成場所は以下のとおりです。

<CLUSTERPROインストールパス>\log\ha\jra\*.stat

下記の「監視項目」とは、JVMモニタリソースの[プロパティ]-[監視(固有)] タブ内の設定項目を表します。

それぞれの監視項目について、[監視する]をチェックし、かつ閾値を設定した場合に統計情報を採取し、JVM統計ログに情報を出力します。[監視する]をチェックしない場合、および[監視する]をチェックしたが閾値を設定しない場合は、JVM統計ログには情報は出力されません。

監視項目と該当するJVM統計ログは以下の通りです。

監視項目	該当するJVM統計ログ
[メモリ]タブ-[ヒープ使用率を監視する] [メモリ]タブ-[非ヒープ使用率を監視する] [メモリ]タブ-[ヒープ使用量を監視する] [メモリ]タブ-[非ヒープ使用量を監視する]	jramemory.stat
[スレッド]タブ-[動作中のスレッド数を監視する]	jrathread.stat
[GC]タブ-[Full GC 実行時間を監視する] [GC]タブ-[Full GC 発生回数を監視する]	jragc.stat
[WebLogic]タブ-[ワークマネージャのリクエストを監視する] [WebLogic]タブ-[スレッドプールのリクエストを監視する] 上記のいずれかがチェックされている場合、wlworkmanager.statとwlthreadpool.statの両方を出力します。一方のみ出力する設定は提供しておりません。	wlworkmanager.stat wlthreadpool.stat

4.37.4. 監視対象Java VMのJavaメモリ領域の使用量を確認する(jramemory.stat)

監視対象Java VMのJavaメモリ領域の使用量を記録するログファイルです。ファイル名はログ出力設定のローテーション方式により以下のいずれかになります。

[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[ファイルサイズ]を選択した場合：jramemory<0から始まる整数>.stat
[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[時間]を選択した場合：jramemory<YYYYMMDDhhmm>.stat

フォーマットは以下の通りです。

No	フォーマット	説明
1	yyyy/mm/dd hh:mm:ss.SSS	ログを記録した日時を示します。
2	半角英数字記号	監視対象Java VMの名称を示します。JVMモニタリソースの[プロパティ]-[監視固有]タブ-[識別名]で設定した値です。
3	半角英数字記号	Javaメモリプールの名称です。詳細は「Javaメモリプール名について」を参照してください。
4	半角英数字記号	Javaメモリプールのタイプです。 Heap、Non-Heap
5	半角数字	Java VMが起動時にOSに要求するメモリ量です。単位はバイトです。(init) 監視対象Java VMの起動時、以下のJava VM起動時オプションでサイズの指定が可能です。・HEAP：-Xms ・NON_HEAP メタデータ領域(Metaspace)：-XX:MetaspaceSize ・NON_HEAP コードキャッシュ領域(Code Cache)：-XX:InitialCodeCacheSize
6	半角数字	Java VMが現在使用しているメモリ量です。単位はバイトです。(used)
7	半角数字	Java VMが現在使用することを保証しているメモリ量です。単位はバイトです。(committed) メモリの使用状況により増減しますが、必ずused以上、max以下になります。
8	半角数字	Java VMが使用できる最大メモリ量です。単位はバイトです。(max) 以下のJava VM起動時オプションでサイズの指定が可能です。・HEAP：-Xmx (注意) -Xms と-Xmxに同じ値を指定すると、(init)>(max)となることがあります。これはHEAPのmaxが、-Xmx の指定によって確保される領域サイズからSurvivor Spaceのサイズの半分を除いたサイズを示すためです。
9	半角数字	計測対象のJava VMが起動してから使用したメモリ量のピーク値です。Javaメモリプールの名称がHEAP、NON_HEAPの場合、Java VMが現在使用しているメモリ量(used)と同じになります。単位はバイトです。
10	半角数字	[JVM種別]で[Oracle Java(usage monitoring)]選択時は無視してください。

4.37.5. 監視対象Java VMのスレッド稼働状況を確認する(jrathread.stat)

監視対象Java VMのスレッド稼働状況を記録するログファイルです。ファイル名はログ出力設定のローテーション方式により以下のいずれかになります。

[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[ファイルサイズ]を選択した場合：jrathread<0から始まる整数>.stat
[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[時間]を選択した場合：jrathread<YYYYMMDDhhmm>.stat

フォーマットは以下の通りです。

No	フォーマット	説明
1	yyyy/mm/dd hh:mm:ss.SSS	ログを記録した日時を示します。
2	半角英数字記号	監視対象Java VMの名称を示します。JVMモニタリソースの[プロパティ]-[監視固有]タブ-[識別名]で設定した値です。
3	半角英数字記号	監視対象Java VMで現在実行中のスレッド数を示します。
4	[半角数字: 半角数字:...]	監視対象Java VMでデッドロックしているスレッドIDを示します。デッドロック数分IDを繰り返します。
5	半角英数字記号	監視対象Java VMでデッドロックしているスレッドの詳細情報を示します。スレッド数分、以下の形式で繰り返します。スレッド名, スレッドID, スレッド状態, UserTime, CpuTime, WaitedCount, WaitedTime, isInNative, isSuspended <改行> stacktrace<改行> : stacktrace<改行> stacktrace=ClassName, FileName, LineNumber, MethodName, isNativeMethod

4.37.6. 監視対象Java VMのGC稼働状況を確認する(jragc.stat)

監視対象Java VMのGC稼働状況を記録するログファイルです。ファイル名はログ出力設定のローテーション方式により以下のいずれかになります。

[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[ファイルサイズ]を選択した場合：jragc<0から始まる整数>.stat
[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[時間]を選択した場合：jragc<YYYYMMDDhhmm>.stat

JVMモニタリソースではコピーGCとFull GCの2種類のGCの情報を出力しています。

JVMモニタリソースでは、Oracle Javaの場合は以下のGCについて、Full GCとして発生回数の増分をカウントしています。

MarkSweepCompact
PS MarkSweep
ConcurrentMarkSweep
G1 Old Generation

フォーマットは以下の通りです。

No	フォーマット	説明
1	yyyy/mm/dd hh:mm:ss.SSS	ログを記録した日時を示します。
2	半角英数字記号	監視対象Java VMの名称を示します。JVMモニタリソースの[プロパティ]-[監視固有]タブ-[識別名]で設定した値です。
3	半角英数字記号	監視対象Java VM のGC名称を示します。監視対象Java VMがOracle Javaの場合以下があります。 Copy MarkSweepCompact PS Scavenge PS MarkSweep ParNew ConcurrentMarkSweep G1 Young Generation G1 Old Generation G1 Concurrent GC(Java 20以降の場合のみ出力)
4	半角数字	監視対象Java VMの起動直後から計測時点までのGC発生回数を示します。 JVMモニタリソースが監視を開始する前に発生したGCの発生回数も値に含みます。
5	半角数字	監視対象Java VMの起動直後から計測時点までのGC総実行時間を示します。単位はミリ秒です。 JVMモニタリソースが監視を開始する前に発生したGCの実行時間も値に含みます。

4.37.7. WebLogic Serverのワークマネージャの稼働状況を確認する(wlworkmanager.stat)

WebLogic Serverのワークマネージャの稼働状況を記録するログファイルです。ファイル名はログ出力設定のローテーション方式により以下のいずれかになります。

[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[ファイルサイズ]を選択した場合：wlworkmanager<0から始まる整数>.stat
[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[時間]を選択した場合：wlworkmanager<YYYYMMDDhhmm>.stat

フォーマットは以下の通りです。

No	フォーマット	説明
1	yyyy/mm/dd hh:mm:ss.SSS	ログを記録した日時を示します。
2	半角英数字記号	監視対象Java VMの名称を示します。JVMモニタリソースの[プロパティ]-[監視固有]タブ-[識別名]で設定した値です。
3	半角英数字記号	アプリケーション名を示します。
4	半角英数字記号	ワークマネージャ名を示します。
5	半角数字	実行したリクエストの数を示します。
6	半角数字	待機しているリクエストの数を示します。

4.37.8. WebLogic Serverのスレッドプールの稼働状況を確認する(wlthreadpool.stat)

WebLogic Serverのスレッドプールの稼働状況を記録するログファイルです。ファイル名はログ出力設定のローテーション方式により以下のいずれかになります。

[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[ファイルサイズ]を選択した場合：wlthreadpool<0から始まる整数>.stat
[クラスタのプロパティ]-[JVM監視]タブ-[ログ出力設定]-[ローテーション方式]-[時間]を選択した場合：wlthreadpool<YYYYMMDDhhmm>.stat

フォーマットは以下の通りです。

No	フォーマット	説明
1	yyyy/mm/dd hh:mm:ss.SSS	ログを記録した日時を示します。
2	半角英数字記号	監視対象Java VMの名称を示します。JVMモニタリソースの[プロパティ]-[監視固有]タブ-[識別名]で設定した値です。
3	半角数字	実行したリクエストの総数を示します。
4	半角数字	処理待ちとなっているリクエスト数を示します。
5	半角数字	単位時間（秒）あたりのリクエスト処理数を示します。
6	半角数字	アプリケーションを実行するためのスレッドのトータル数を示します。
7	半角数字	アイドル状態となっているスレッドの数を示します。
8	半角数字	実行中のスレッド数を示します。
9	半角数字	スタンバイ状態となっているスレッド数を示します。

4.37.9. Javaメモリプール名について

JVM運用ログに出力するメッセージ中のmemory_nameとして出力するJavaメモリプール名、およびJVM統計ログjramemory.stat中に出力するJavaメモリプール名について説明します。

Javaメモリプール名として出力する文字列は、JVMモニタリソースで決定しているのではなく、監視対象Java VMから受け取った文字列を出力しています。

また、Java VMとしては仕様を公開していないため、Java VMのバージョンアップにより、予告なく変更される可能性があります。

そのため、メッセージ中のJavaメモリプール名をメッセージ監視することは推奨いたしません。

下記の監視項目とはJVMモニタリソースの[プロパティ]-[監視(固有)] タブ-[メモリ]タブ内の設定項目を表します。

以下に記載しているJavaメモリプール名はOracle Java において実機確認した結果です。

[JVM種別]に[Oracle Java(usage monitoring)]を選択、かつ監視対象Java VMの起動オプションに「-XX:+UseSerialGC」が付加されている場合、jramemory.statにおけるNo3のJavaメモリプール名は以下の通りです。

監視項目	memory_nameとして出力する文字列
[ヒープ使用量を監視する]-[領域全体]	HEAP
[ヒープ使用量を監視する]-[Eden Space]	Eden Space
[ヒープ使用量を監視する]-[Survivor Space]	Survivor Space
[ヒープ使用量を監視する]-[Tenured Gen]	Tenured Gen
[非ヒープ使用量を監視する]-[領域全体]	NON_HEAP
[非ヒープ使用量を監視する]-[Code Cache]	Code Cache(Java 9以降の場合、出力なし)
[非ヒープ使用量を監視する]-[Metaspace]	Metaspace
[非ヒープ使用量を監視する]-[CodeHeap non-nmethods]	CodeHeap non-nmethods
[非ヒープ使用量を監視する]-[CodeHeap profiled]	CodeHeap profiled nmethods
[非ヒープ使用量を監視する]-[CodeHeap non-profiled]	CodeHeap non-profiled nmethods
[非ヒープ使用量を監視する]-[Compressed Class Space]	Compressed Class Space

[JVM種別]に[Oracle Java(usage monitoring)]を選択、かつ監視対象Java VMの起動オプションに「-XX:+UseParallelGC」が付加されている場合、jramemory.statにおけるNo3のJavaメモリプール名は以下の通りです。

監視項目	memory_nameとして出力する文字列
[ヒープ使用量を監視する]-[領域全体]	HEAP
[ヒープ使用量を監視する]-[Eden Space]	PS Eden Space
[ヒープ使用量を監視する]-[Survivor Space]	PS Survivor Space
[ヒープ使用量を監視する]-[Tenured Gen]	PS Old Gen
[非ヒープ使用量を監視する]-[領域全体]	NON_HEAP
[非ヒープ使用量を監視する]-[Code Cache]	Code Cache(Java 9以降の場合、出力なし)
[非ヒープ使用量を監視する]-[Metaspace]	Metaspace
[非ヒープ使用量を監視する]-[CodeHeap non-nmethods]	CodeHeap non-nmethods
[非ヒープ使用量を監視する]-[CodeHeap profiled]	CodeHeap profiled nmethods
[非ヒープ使用量を監視する]-[CodeHeap non-profiled]	CodeHeap non-profiled nmethods
[非ヒープ使用量を監視する]-[Compressed Class Space]	Compressed Class Space

[JVM種別]に[Oracle Java(usage monitoring)]を選択、かつ監視対象Java VMの起動オプションに「-XX:+UseParNewGC」が付加されている場合、jramemory.statにおけるNo3のJavaメモリプール名は以下の通りです。Java 9以降の場合、「-XX:+UseParNewGC」を付加すると、監視対象Java VMは起動しません。

監視項目	memory_nameとして出力する文字列
[ヒープ使用量を監視する]-[領域全体]	HEAP
[ヒープ使用量を監視する]-[Eden Space]	Par Eden Space
[ヒープ使用量を監視する]-[Survivor Space]	Par Survivor Space
[ヒープ使用量を監視する]-[Tenured Gen]	Tenured Gen
[非ヒープ使用量を監視する]-[領域全体]	NON_HEAP
[非ヒープ使用量を監視する]-[Code Cache]	Code Cache
[非ヒープ使用量を監視する]-[Metaspace]	Metaspace
[非ヒープ使用量を監視する]-[CodeHeap non-nmethods]	CodeHeap non-nmethods
[非ヒープ使用量を監視する]-[CodeHeap profiled]	CodeHeap profiled nmethods
[非ヒープ使用量を監視する]-[CodeHeap non-profiled]	CodeHeap non-profiled nmethods
[非ヒープ使用量を監視する]-[Compressed Class Space]	Compressed Class Space

[JVM種別]に[Oracle Java(usage monitoring)]を選択、かつ監視対象Java VMの起動オプションに「-XX:+UseG1GC」が付加されている場合、jramemory.statにおけるNo3のJavaメモリプール名は以下の通りです。

監視項目	memory_nameとして出力する文字列
[ヒープ使用量を監視する]-[領域全体]	HEAP
[ヒープ使用量を監視する]-[Eden Space]	G1 Eden Space
[ヒープ使用量を監視する]-[Survivor Space]	G1 Survivor Space
[ヒープ使用量を監視する]-[Tenured Gen(Old Gen)]	G1 Old Gen
[非ヒープ使用量を監視する]-[領域全体]	NON_HEAP
[非ヒープ使用量を監視する]-[Code Cache]	Code Cache(Java 9以降の場合、出力なし)
[非ヒープ使用量を監視する]-[Metaspace]	Metaspace
[非ヒープ使用量を監視する]-[CodeHeap non-nmethods]	CodeHeap non-nmethods
[非ヒープ使用量を監視する]-[CodeHeap profiled]	CodeHeap profiled nmethods
[非ヒープ使用量を監視する]-[CodeHeap non-profiled]	CodeHeap non-profiled nmethods
[非ヒープ使用量を監視する]-[Compressed Class Space]	Compressed Class Space

JVM統計ログjramemory.statにおけるJavaメモリプール名と、Java VMメモリ空間の関係は以下の通りです。

Oracle Java 8/Oracle Java 9/Oracle Java 11/Oracle Java 17/Oracle Java 21の場合

_images/img_java-memory-pool-name-20.png — 図 4.67 Java VMメモリ空間（Oracle Java 8/Oracle Java 9/Oracle Java 11/Oracle Java 17/Oracle Java 21）

図中のNo	監視項目	jramemory.statのJavaメモリプール名
(1)	[ヒープ使用量を監視する]-[領域全体]	HEAP
(2)	[ヒープ使用量を監視する]-[Eden Space]	EdenSpace PS Eden Space Par Eden Space G1 Eden Space
(3)+(4)	[ヒープ使用量を監視する]-[Survivor Space]	Survivor Space PS Survivor Space Par Survivor Space G1 Survivor Space
(5)	[ヒープ使用量を監視する]-[Tenured Gen]	Tenured Gen PS Old Gen G1 Old Gen
(6)	[非ヒープ使用量を監視する]-[Code Cache]	Code Cache(Java 9以降の場合、出力なし)
(6)	[非ヒープ使用量を監視する]-[CodeHeap non-nmethods]	CodeHeap non-nmethods(Java 9以降の場合のみ出力)
(6)	[非ヒープ使用量を監視する]-[CodeHeap profiled]	CodeHeap profiled nmethods(Java 9以降の場合のみ出力)
(6)	[非ヒープ使用量を監視する]-[CodeHeap non-profiled]	CodeHeap non-profiled nmethods(Java 9以降の場合のみ出力)
(7)	[非ヒープ使用量を監視する]-[Metaspace]	Metaspace
(8)	[非ヒープ使用量を監視する]-[Compressed Class Space]	Compressed Class Space
(6)+(7)+(8)	[非ヒープ使用量を監視する]-[領域全体]	NON_HEAP

4.37.10. 異常検出時に障害原因別にコマンドを実行するには

モニタリソースの異常検出時、CLUSTERPROでは障害原因別に異なるコマンドを区別して実行する手段を提供していません。

JVMモニタリソースでは障害原因別にコマンドを区別して実行可能です。異常検出時に実行します。

障害原因別に実行するコマンドの設定項目は以下の通りです。

障害原因	設定項目
・監視対象のJava VMへ接続失敗・リソース計測失敗	[監視(固有)]タブ-[コマンド]
・ヒープ使用率・非ヒープ使用率・ヒープ使用量・非ヒープ使用量	[監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[コマンド]
・動作中のスレッド数	[監視(固有)]タブ-[調整]プロパティ-[スレッド]タブ-[コマンド]
・Full GC実行時間・Full GC発生回数	[監視(固有)]タブ-[調整]プロパティ-[GC]タブ-[コマンド]
・WebLogicのワークマネージャのリクエスト・WebLogicのスレッドプールのリクエスト	[監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[コマンド]

[コマンド]は障害原因の詳細をコマンドの引数として渡します。引数は[コマンド]の最後に結合して渡します。スクリプトなどを自身で作成し[コマンド]へ設定することにより、更に障害原因に特化した動作が可能です。引数として渡す文字列は以下の通りです。

引数として渡す文字列が複数記載している場合は、監視対象Java VMのGC方式によりいずれかを渡します。差異の詳細は「 Javaメモリプール名について」を参照してください。

障害原因の詳細	引数として渡す文字列
・監視対象のJava VMへ接続失敗・リソース計測失敗	なし
[メモリ]タブ- [ヒープ使用量を監視する]-[領域全体] (Oracle Java(usage monitoring)の場合)	HEAP
[メモリ]タブ- [ヒープ使用量を監視する]-[Eden Space] (Oracle Java(usage monitoring)の場合)	EdenSpace PSEdenSpace ParEdenSpace G1EdenSpace
[メモリ]タブ- [ヒープ使用量を監視する]-[Survivor Space] (Oracle Java(usage monitoring)の場合)	SurvivorSpace PSSurvivorSpace ParSurvivorSpace G1SurvivorSpace
[メモリ]タブ- [ヒープ使用量を監視する]-[Tenured Gen] (Oracle Java(usage monitoring)の場合)	TenuredGen PSOldGen CMSOldGen G1OldGen
[メモリ]タブ- [非ヒープ使用量を監視する]-[領域全体] (Oracle Java(usage monitoring)の場合)	NON_HEAP
[メモリ]タブ- [非ヒープ使用量を監視する]-[Code Cache] (Oracle Java(usage monitoring)の場合)	CodeCache
[メモリ]タブ- [非ヒープ使用量を監視する]-[Metaspace] (Oracle Java(usage monitoring)の場合)	Metaspace
[メモリ]タブ - [非ヒープ使用量を監視する]-[CodeHeap non-nmethods] (Oracle Java(usage monitoring)の場合)	non-nmethods
[メモリ]タブ - [非ヒープ使用量を監視する]-[CodeHeap profiled] (Oracle Java(usage monitoring)の場合)	profilednmethods
[メモリ]タブ - [非ヒープ使用量を監視する]-[CodeHeap non-profiled] (Oracle Java(usage monitoring)の場合)	non-profilednmethods
[メモリ]タブ - [非ヒープ使用量を監視する]-[Compressed Class Space] (Oracle Java(usage monitoring)の場合)	CompressedClassSpace
[スレッド]タブ-[動作中のスレッド数を監視する]	Count
[GC]タブ-[Full GC 実行時間を監視する]	Time
[GC]タブ-[Full GC 発生回数を監視する]	Count
[WebLogic]タブ-[ワークマネージャのリクエストを監視する]-[待機リクエストリクエスト数]	WorkManager_PendingRequests
[WebLogic]タブ-[スレッドプールのリクエストを監視する]-[待機リクエストリクエスト数]	ThreadPool_PendingUserRequestCount
[WebLogic]タブ-[スレッドプールのリクエストを監視する]-[実行リクエストリクエスト数]	ThreadPool_Throughput

以下に実行例に示します。

例1)

設定項目	設定内容
[監視(固有)]タブ-[調整]プロパティ-[GC]タブ-[コマンド]	c:\Program Files\bin\downcmd
[監視(固有)]タブ-[調整]プロパティ-[GC]タブ-[Full GC 発生回数を監視する]	1
[クラスタのプロパティ]-[JVM監視]タブ-[リソース計測設定]-[共通]タブ-[異常判定しきい値	3

JVMモニタリソースは、異常判定しきい値回(3回)連続してFull GCが発生すると、モニタ異常を検出し、「c:\Program Files\bin\downcmd Cont」としてコマンドを実行します。

例2)

設定項目	設定内容
[監視(固有)]タブ-[調整]プロパティ-[GC]タブ-[コマンド]	"c:\Program Files\bin\downcmd" GC
[監視(固有)]タブ-[調整]プロパティ-[GC]タブ-[Full GC実行時間を監視する]	65536
[クラスタのプロパティ]-[JVM監視]タブ-[リソース計測設定]-[共通]タブ-[異常判定しきい値	3

JVMモニタリソースは、異常判定しきい値回(3回)連続してFull GC 実行時間が 65535 ミリ秒超過すると、モニタ異常を検出し、「c:\Program Files\bin\downcmd GC Time」としてコマンドを実行します。

例3)

設定項目	設定内容
[監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[コマンド]	"c:\Program Files\bin\downcmd" memory
[監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[ヒープ使用率を監視する]	オン
[監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[Eden Space]	80
[監視(固有)]タブ-[調整]プロパティ-[メモリ]タブ-[Survivor Space]	80
[クラスタのプロパティ]-[JVM監視]タブ-[リソース計測設定]-[共通]タブ-[異常判定しきい値]	3

JVMモニタリソースは、異常判定しきい値回(3回)連続してJava Eden Space の使用率およびJava Survivor Spaceの使用率が80%を超過すると、モニタ異常を検出し、「c:\Program Files\bin\downcmd memory EdenSpace SurvivorSpace」としてコマンドを実行します。

[コマンド]で設定したコマンドの終了を待つタイムアウト(秒)は、[クラスタのプロパティ]-[JVM監視]タブ-[コマンドタイムアウト]で設定します。これは上記各タブの[コマンド]で同じ値を適用します。[コマンド]個別には設定できません。

タイムアウトした場合、[コマンド]プロセスを強制終了させるような処理は実行しません。[コマンド]プロセスの後処理(例：強制終了)は、お客様が実行してください。タイムアウトした場合は、以下のメッセージをJVM運用ログへ出力します。

action thread execution did not finish. action is alive = <コマンド>

注意事項は以下の通りです。

Java VMの正常復帰検出時(異常→正常時)には[コマンド]は実行しません。
[コマンド]はJava VM異常検出時(しきい値の超過が異常判定しきい値回連続して発生した場合)を契機として実行します。しきい値の超過毎には実行しません。
複数のタブにて[コマンド]を設定すると、同時に障害が発生した場合は複数の[コマンド]が実行されます。そのため、システム負荷にはご注意ください。
[監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[ワークマネージャのリクエストを監視する]-[待機リクエストリクエスト数]、[監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[ワークマネージャのリクエストを監視する]-[待機リクエスト平均値]を両方監視している場合、[コマンド]が同時に2回実行される可能性があります。
これは、[クラスタのプロパティ]-[JVM監視]タブ-[リソース計測設定]-[WebLogic]タブ-[インターバルリクエスト数]と[クラスタのプロパティ]-[JVM監視]タブ-[リソース計測設定]-[WebLogic]タブ-[インターバル平均値]の異常検出が同時に発生する可能性があるためです。回避策としては、どちらか一方のみ監視するようにしてください。以下の監視項目の組み合わせも同様です。
- [監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[スレッドプールのリクエストを監視する]-[待機リクエストリクエスト数]と、[監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[スレッドプールのリクエストを監視する]-[待機リクエスト平均値]
- [監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[スレッドプールのリクエストを監視する]-[実行リクエストリクエスト数]と、[監視(固有)]タブ-[調整]プロパティ-[WebLogic]タブ-[スレッドプールのリクエストを監視する]-[実行リクエスト平均値]

4.37.11. WebLogic Serverを監視するには

監視対象の WebLogic Server の設定が終了しアプリケーションサーバとして稼動させる手順は、WebLogic Server のマニュアルを参照してください。

本書では、JVM モニタリソースで監視するために必要な設定のみについて記述します。

WebLogic Server Administration Console もしくは WebLogic Remote Console を起動します。起動方法は、WebLogic Server マニュアルの「管理コンソールの概要」を参照してください。
- WebLogic Server Administration Consoleの場合
  
  ドメイン構成－ドメイン－コンフィグレーション－全般を選択します。ここで「管理ポートの有効化」のチェックがオフになっていることを確認してください。
- WebLogic Remote Console の場合
  
  構成ビュー・ツリー－環境－ドメイン－一般を選択します。ここで「管理ポートの有効化」のチェックがオフになっていることを確認してください。
ドメイン構成－サーバーもしくは構成ビュー・ツリー－環境－サーバーを選択し、監視対象のサーバ名を選択します。選択したサーバ名は Cluster WebUI の設定モードから選択可能な[プロパティ]-[監視(固有)] タブの識別名に設定します。「JVMモニタリソースを理解する」を参照してください。
WebLogic Server を停止します。停止方法は、WebLogic Server マニュアルの「WebLogic Server の起動と停止」を参照してください。
WebLogic Server の管理サーバ起動スクリプト (startWebLogic.cmd) を開きます。
開いたスクリプトに以下の内容を記述します。
- 監視対象が WebLogic Server の管理サーバの場合
```
set JAVA_OPTIONS=%JAVA_OPTIONS%
-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
```
  ※上記内容は実際には1行で記述してください。
  
  注釈
  
  n は、監視のために使用するポート番号を指定します。指定するポート番号は監視対象の Java VM の「リスニング・ポート」とは別の番号を指定してください。また同一のマシンに複数の監視対象の WebLogic Server が存在する場合、そのリスニング・ポート番号や他のアプリケーションのポート番号と重複しないポート番号を指定してください。
- 監視対象が WebLogic Server の管理対象サーバの場合
```
if "%SERVER_NAME%" == "SERVER_NAME"(
set JAVA_OPTIONS=%JAVA_OPTIONS%
-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
)
```
  ※上記で if文の中は実際には1行で記述してください。
  
  注釈
  
  SERVER_NAME は、「監視対象サーバ選択」で確認した監視対象となるサーバ名を指定します。監視対象のサーバが複数の場合、同様の設定(1～6行目)に対してサーバ名を変更し、繰り返し設定してください。
  注釈
  
  上記の記述内容の追加箇所は、以下の記述より前に記述するようにしてください。
  %JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %JAVA_OPTION % %PROXY_SETTINGS% %SERVER_CLASS%
  ※上記内容は実際には1行で記述してください
  
  ※WebLogic のバージョンによって、上記の java 引数の内容が異なっている場合がありますが、java の実行前に JAVA_OPTIONS を記述していただければ問題ありません。
ワークマネージャやスレッドプールのリクエストを監視する場合は以下の設定を行ってください。

監視対象の WebLogic Server の WLST(wlst.cmd) を起動します。

起動方法は [スタート] メニューの[Oracle WebLogic]-[WebLogic Server <バージョン番号>] - [Tools] - [WebLogic Scripting Tool]を選択します。

表示されたプロンプト画面上で、以下のコマンドを実行してください。
```
>connect('USERNAME','PASSWORD','t3://SERVER_ADDRESS:SERVER_PORT')
> edit()
> startEdit()
> cd('JMX/DOMAIN_NAME')
> set('PlatformMBeanServerUsed','true')
> activate()
> exit()
```
上記のUSERNAME、PASSWORD、SERVER_ADDRESS、SERVER_PORT、DOMAIN_NAMEはドメイン環境に応じた値に置き換えてください。

注釈

ワークマネージャやスレッドプールのリクエスト監視は WebLogic Server の「保護された本番モード」が有効化された環境はサポートしていません。

これらの監視を行う場合は「保護された本番モード」が無効になっていることを確認してください。
監視対象の WebLogic Server を再起動します

4.37.12. WebOTXを監視するには

本ガイドでは、JVMモニタリソースで監視する対象の WebOTX の設定手順について記述します。

WebOTX統合運用管理コンソールを起動します。起動方法は「WebOTX運用編（Web版統合運用管理コンソール）」マニュアルの「コンソールの実行」を参照してください。

以降の設定は、WebOTX上のJMXエージェントのJavaプロセスに対する監視を行う場合と、プロセスグループ上のJavaプロセスに対する監視を行う場合とで設定内容が異なります。監視する対象に合わせて、設定してください。

4.37.13. WebOTX ドメインエージェントのJavaプロセスを監視するには

特に設定作業は不要です。

4.37.14. WebOTX プロセスグループのJavaプロセスを監視するには

統合運用管理コンソールよりドメインと接続します。
ツリービューより[<ドメイン名>]-[TPシステム]-[アプリケーショングループ]-[<アプリケーショングループ名>]-[プロセスグループ]-[<プロセスグループ名>]を選択します。
右側に表示される[JavaVMオプション]タブ内の[その他の引数]属性に、次のJavaオプションを1行で指定します。nは、ポート番号を指定します。同一のマシンに複数の監視対象のJava VMが存在する場合、重複しないポート番号を指定してください。ここで指定するポート番号は、Cluster WebUI ([モニタリソースのプロパティ]→[監視(固有)]タブ→[接続ポート番号])でも設定します。
```
-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djavax.management.builder.initial=com.nec.webotx.jmx.mbeanserver.JmxMBeanServerBuilder
```
※WebOTX V9.2以降では -Djavax.management.builder.initial の指定は不要です。
設定後、「更新」ボタンを押します。設定が完了したら、プロセスグループを再起動します。

本設定は、WebOTX統合運用管理コンソールの[Javaシステムプロパティ]タブ内の[Javaシステムプロパティ]属性にて指定することも可能です。その場合は、"-D"は指定せず、また、"="より前の文字列を「名前」に、"="より後ろの文字列を「値」に指定してください。

注釈

WebOTX プロセスグループの機能でプロセス障害時の再起動を設定されている場合、CLUSTERPROからの復旧動作でプロセスグループの再起動を実行すると、WebOTX プロセスグループの機能が正常に動作しない場合があります。そのため、WebOTX プロセスグループを監視する場合は Cluster WebUI からJVMモニタリソースに対して以下のように設定してください。

設定タブ名

項目名

設定値

監視(共通)

監視タイミング

常時

回復動作

回復動作

最終動作のみ実行

回復動作

最終動作

何もしない

4.37.15. WebOTX notification通知を受信するには

特定のリスナクラスを登録することにより、WebOTXが障害を検出するとnotificationが発行されます。JVMモニタリソースはそのnotificationを受信し、JVM運用ログへ以下のメッセージを通知します。

%1$s:Notification received. %2$s.
%1$s、%2$sの意味は以下のとおりです。
%1$s：監視対象Java VM
%2$s：notificationの通知メッセージ (ObjectName=**,type=**,message=**)

現在、監視可能なリソースのMBeanの詳細情報は以下のとおりです。

ObjectName	[domainname]:j2eeType=J2EEDomain,name=[domainname],category=runtime
notificationタイプ	nec.webotx.monitor.alivecheck.not-alive
メッセージ	failed

4.37.16. Tomcatを監視するには

JVMモニタリソースで監視する対象のTomcat の設定手順について記述します。

Tomcatを停止し、 [スタート]-(Tomcatのプログラムフォルダ)-[Configure Tomcat]を開きます。
開いたウィンドウの[Java]タブの「Java Options」に以下の内容を記述します。n は、ポート番号を指定します。同一のマシンに複数の監視対象のJava VMが存在する場合、重複しないポート番号を指定してください。ここで指定するポート番号は、Cluster WebUI([モニタリソースのプロパティ]→[監視(固有)]タブ→[接続ポート番号])でも設定します。
-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
パスワード認証を使用する場合は、以下の内容を記述します。PasswordFilePath は、パスワードファイルのパスを指定します。
-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=PasswordFilePath
パスワード認証を使用するための必要最低限の設定について説明します。JMX(Java Management Extentions)のパスワード認証の使用に関する詳細は Java のドキュメントを参照してください。

パスワードファイルは、JAVA_HOME\conf\management ディレクトリのパスワードテンプレートファイル jmxremote.password.template をTomcat実行ユーザのホームディレクトリなどにコピーし、そのファイル名を jmxremote.password に変更して作成します。

パスワードファイルを開いて、monitorRole ロールとそのパスワードを追加します。ここで指定する monitorRole ロールは、Cluster WebUI([モニタリソースのプロパティ]→[監視(固有)]タブ→[ユーザ名])でも設定します。パスワードは、Cluster WebUI([モニタリソースのプロパティ]→[監視(固有)]タブ→[パスワード])でも設定します。

パスワードファイルはTomcat実行ユーザだけがファイルを読書きできるようにアクセス権を設定します。monitorRoleロールはモニタリングのための読取り専用アクセスを許可します。
上記設定を保存した後、Tomcatを起動します。

Cluster WebUI(JVMモニタリソース名→[プロパティ]→[監視(固有)] タブ→識別名) には他の監視対象と重ならない任意の文字列(例：tomcat)を設定してください。

4.37.17. SVFを監視するには

JVMモニタリソースで監視する対象のSVF の設定手順について記述します。

監視対象を下記より選択し、該当するファイルをエディタから開きます。

監視対象

編集するファイル

UCX Server Service(9.x以降の場合)

<SVFインストールパス>

\launcher\UCXServer.run

Report Director EnterpriseServer

<SVFインストールパス>

\launcher\ReportDirectorEnterpriseServer.run

Report Director Svf Server

<SVFインストールパス>

\launcher\ReportDirectorSvfServer.run

Report Director Spool Balancer

<SVFインストールパス>

\launcher\ReportDirectorSpoolBalancer.run

Tomcat

%FIT_PRODUCTS_BASE%\SetupUtils\setup_tomcat.bat

SVF Print Spooler services

<SVFインストールパス>\svfjpd\launcher\SpoolerDaemon.run
(監視対象がTomcatの場合)

setup_tomcat.bat 内の :install の --JvmOption の箇所に、以下のように追記します。n は、ポート番号を指定します。同一のマシンに複数の監視対象のJava VMが存在する場合、重複しないポート番号を指定してください。ここで指定するポート番号は、Cluster WebUI([モニタリソースのプロパティ]→[監視(固有)]タブ→[接続ポート番号])でも設定します。

変更前：
--JvmOptions=...
変更後：
--JvmOptions=...;-Dcom.sun.management.jmxremote.port=n;-Dcom.sun.management.jmxremote.ssl=false;-Dcom.sun.management.jmxremote.authenticate=false
(監視対象がTomcat以外の場合)Argumentsを指定している箇所に下記の内容を「-Xms」の設定箇所直後に挿入します。n は、ポート番号を指定します。同一のマシンに複数の監視対象のJava VMが存在する場合、重複しないポート番号を指定してください。ここで指定するポート番号は、Cluster WebUI([モニタリソースのプロパティ]→[監視(固有)]タブ→[接続ポート番号])でも設定します。
-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

4.37.18. 自製のJavaアプリケーションを監視するには

JVMモニタリソースで監視する対象のJavaアプリケーションの設定手順について記述します。監視対象のJavaアプリケーションが停止した状態で、Javaアプリケーションの起動時オプションに次のJavaオプションを1行で指定します。n は、監視のために使用するポート番号を指定します。同一のマシンに複数の監視対象のJava VMが存在する場合、重複しないポート番号を指定してください。ここで指定するポート番号は、Cluster WebUI([モニタリソースのプロパティ]→[監視(固有)]タブ→[接続ポート番号])でも設定します。

-Dcom.sun.management.jmxremote.port=n
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Javaアプリケーションによっては以下も追加で指定必要です。

-Djavax.management.builder.initial=<MBeanServerBuilder のクラス名>

4.37.19. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（jraw）

監視対象

監視対象をリストから選択します。WebSAM SVF for PDF、WebSAM Report Director Enterprise、WebSAM Universal Connect/X を監視する場合は、[WebSAM SVF] を選択してください。自製のJavaアプリケーションを監視する場合は、[Javaアプリケーション] を選択してください。

既定値：なし

JVM種別

監視対象のアプリケーションが動作するJava VMをリストから選択します。

Java 8 以降の場合は、[Oracle Java(usage monitoring)]を選択してください。

Java 9 では以下の仕様変更がありました。

Code Cache が分割されました。

そのため、Java 9 では[メモリ]タブの監視項目は以下に変更となります。

[Code Cache]は監視できません。チェックボックスはオフにしてください。

[CodeHeap non-nmethods]、[CodeHeap profiled]、[CodeHeap non-profiled]を監視可能です。

既定値：なし

識別名(255バイト以内)

識別名とは、JVM モニタリソースの JVM 運用ログに監視対象の情報を出力する際に、別のJVM モニタリソースと識別するために設定します。そのため、JVM モニタリソース間で一意の文字列を設定してください。必ず設定してください。

監視対象が「WebLogic Server」の場合

「 WebLogic Serverを監視するには」の 2 を参照して、監視対象のサーバインスタンス名を設定してください。

監視対象が「WebOTX プロセスグループ」の場合

プロセスグループ名を設定してください。

監視対象が「WebOTX ドメインエージェント」の場合

ドメイン名を設定してください。

監視対象が「WebOTX ESB」の場合

「WebOTX プロセスグループ」の場合と同じです。

監視対象が「Tomcat」の場合

「 Tomcatを監視するには」の 4 を参照して設定してください。

監視対象が「WebSAM SVF」の場合

「 SVFを監視するには」の 4 を参照して設定してください。

監視対象が「Javaアプリケーション」の場合

監視対象のJava VM プロセスを一意に識別可能な文字列を指定してください。

既定値：なし

接続ポート番号(1024～65535)

JVMモニタリソースが、監視対象Java VMとJMX接続を行う際に使用するポート番号を設定します。JVMモニタリソースは監視対象Java VMに JMX接続を行うことにより情報を取得します。そのためJVMモニタリソースを登録する場合は、監視対象Java VMにJMX接続用ポートを開放する設定を行う必要があります。必ず設定してください。クラスタ内のサーバにおいて、共通の設定となります。42424～61000 は推奨しません。

監視対象が「WebLogic Server」の場合

接続ポート番号は「 WebLogic Serverを監視するには」の 5 を参照して設定してください。

監視対象が「WebOTX プロセスグループ」の場合

「 WebOTX プロセスグループのJavaプロセスを監視するには」を参照して設定してください。

監視対象が「WebOTX ドメインエージェント」の場合

"(WebOTX インストールパス)\<ドメイン名>.properties" の "domain.admin.port" を設定してください。

監視対象が「WebOTX ESB」の場合

「WebOTX プロセスグループ」の場合と同じです。

監視対象が「Tomcat」の場合

「 Tomcatを監視するには」の 2 を参照して設定してください。

監視対象が「WebSAM SVF」の場合

「 SVFを監視するには」の 2 を参照して設定してください。

監視対象が「Javaアプリケーション」の場合

接続ポート番号は監視対象であるJavaアプリケーションに確認の上、設定してください。

既定値：なし

プロセス名(255バイト以内)

[接続ポート番号] により監視対象Java VMが識別可能なため、設定不要です。内部バージョン 11.35 までは仮想メモリ使用量を取得する際やJVM 運用ログに監視対象の情報を出力する際にも本パラメータを使用し識別していたため、指定が必要でした。しかし、内部バージョン 12.00 以降は [仮想メモリ使用量を監視する] が削除となったため、設定できません。

既定値：なし

ユーザ名(255バイト以内)

監視対象のJava VMに接続する管理ユーザ名を設定します。

監視対象が「WebOTXドメインエージェント」の場合

"(WebOTXインストールパス)\<ドメイン名>.properties"の"domain.admin.user"の値を設定してください。

監視対象が「Tomcat」の場合

「 Tomcatを監視するには」の 2 を参照して設定してください。パスワード認証を利用しない場合は空欄のままで構いません。

監視対象が上記以外の場合

設定できません。

既定値：なし

パスワード(255バイト以内)

監視対象のJava VMに接続する管理ユーザのパスワードを設定します。

監視対象が「WebOTXドメインエージェント」の場合

"(WebOTXインストールパス)\<ドメイン名>.properties"の"domain.admin.passwd"の値を設定してください。

監視対象が「Tomcat」の場合

「 Tomcatを監視するには」の 2 を参照して設定してください。パスワード認証を利用しない場合は空欄のままで構いません。

監視対象が上記以外の場合

設定できません。

既定値：なし

コマンド(255バイト以内)

監視対象のJava VM異常検出時に、実行するコマンドを設定します。異常の原因別に実行するコマンドおよび引数の指定が可能です。絶対パスで指定してください。また、実行ファイル名は二重引用符("")で括ってください。

例)"\Program Files\bin\command.bat" arg1 arg2

ここでは監視対象Java VMに接続できない場合や使用リソース量の取得における異常検出時に、実行するコマンドを設定します。

「異常検出時に障害原因別にコマンドを実行するには」も参照してください。

既定値：なし

さらに[調整]ボタンを選択すると以下の内容がポップアップダイアログに表示されます。以下の説明に従い詳細設定を行います。

4.37.20. メモリタブ([JVM種別]で[Oracle Java(usage monitoring)]選択時)

JVM監視リソース調整プロパティの「メモリ」タブ

ヒープ使用量を監視する

監視対象のJava VMが使用するJavaヒープ領域の使用量の監視設定をします。

チェックボックスがオン

監視します。

チェックボックスがオフ(既定値)

監視しません。

領域全体(0～102400)

監視対象のJava VMが使用するJavaヒープ領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

Eden Space(0～102400)

監視対象のJava VMが使用するJava Eden Spaceの使用量のしきい値を設定します。0の場合、監視しません。監視対象Java VMのGC方式としてG1 GCを指定している場合、G1 Eden Spaceと読み替えてください。

既定値： 0[MB]

Survivor Space(0～102400)

監視対象のJava VMが使用するJava Survivor Spaceの使用量のしきい値を設定します。0の場合、監視しません。監視対象Java VMのGC方式としてG1 GCを指定している場合、G1 Survivor Spaceと読み替えてください。

既定値： 0[MB]

Tenured Gen(0～102400)

監視対象のJava VMが使用するJava Tenured(Old) Gen領域の使用量のしきい値を設定します。0の場合、監視しません。監視対象Java VMのGC方式としてG1 GCを指定している場合、G1 Old Genと読み替えてください。

既定値： 0[MB]

非ヒープ使用量を監視する

監視対象のJava VMが使用するJava非ヒープ領域の使用量の監視設定をします。

チェックボックスがオン

監視します。

チェックボックスがオフ(既定値)

監視しません。

領域全体(0～102400)

監視対象のJava VMが使用するJava非ヒープ領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

Code Cache(0～102400)

監視対象のJava VMが使用するJava Code Cache領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

CodeHeap non-nmethods(0～102400)

監視対象のJava VMが使用するJava CodeHeap non-nmethods領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

CodeHeap profiled(0～102400)

監視対象のJava VMが使用するJava CodeHeap profiled nmethods領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

CodeHeap non-profiled (0～102400)

監視対象のJava VMが使用するJava CodeHeap non-profiled nmethods領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

Compressed Class Space(0～102400)

監視対象のJava VMが使用するCompressed Class Space領域の使用量のしきい値を設定します。0の場合、監視しません。

既定値： 0[MB]

Metaspace(0～102400)

監視対象のJava VMが使用するMetaspace領域の使用量のしきい値を設定します。

既定値： 0[MB]

コマンド(255バイト以内)

監視対象のJava VM異常検出時に、実行するコマンドを設定します。異常の原因別に実行するコマンドおよび引数の指定が可能です。絶対パスで指定してください。また、実行ファイル名は二重引用符("")で括ってください。

例)"\Program Files\bin\command.bat" arg1 arg2

ここでは監視対象Java VMのJavaヒープ領域、Java非ヒープ領域における異常検出時に、実行するコマンドを設定します。

「異常検出時に障害原因別にコマンドを実行するには」も参照してください。

既定値：なし

既定値

[既定値]ボタンをクリックすると全ての項目に既定値が設定されます。

4.37.21. スレッドタブ

JVM監視リソース調整プロパティの「スレッド」タブ

動作中のスレッド数を監視する(1～65535)

監視対象のJava VMで現在動作中のスレッド上限数のしきい値を設定します。

既定値： 65535[スレッド]

コマンド(255バイト以内)

監視対象のJava VM異常検出時に、実行するコマンドを設定します。異常の原因別に実行するコマンドおよび引数の指定が可能です。絶対パスで指定してください。また、実行ファイル名は二重引用符("")で括ってください。

例)"\Program Files\bin\command.bat" arg1 arg2

ここでは監視対象Java VMで現在動作中のスレッド数における異常検出時に、実行するコマンドを設定します。

「異常検出時に障害原因別にコマンドを実行するには」も参照してください。

既定値：なし

既定値

[既定値]ボタンをクリックすると全ての項目に既定値が設定されます。

4.37.22. GCタブ

JVM監視リソース調整プロパティの「GC」タブ

Full GC実行時間を監視する(1～65535)

監視対象のJava VMにおいて、前回計測以降のFull GC実行時間のしきい値を設定します。Full GC実行時間とは、前回計測以降のFull GC発生回数で割った平均値です。

前回計測以降のFull GC実行時間 3000ミリ秒、Full GC発生回数3回の場合を異常と判定したい場合、1000ミリ秒以下を設定してください。

既定値： 65535[ミリ秒]

Full GC発生回数を監視する(1～65535)

監視対象のJava VMにおいて、前回計測以降のFull GC発生回数のしきい値を設定します。

既定値： 1(回)

コマンド(255バイト以内)

監視対象のJava VM異常検出時に、実行するコマンドを設定します。異常の原因別に実行するコマンドおよび引数の指定が可能です。絶対パスで指定してください。また、実行ファイル名は二重引用符("")で括ってください。

例)"\Program Files\bin\command.bat" arg1 arg2

ここでは監視対象Java VMのFull GC実行時間やFull GC発生回数における異常検出時に、実行するコマンドを設定します。

「異常検出時に障害原因別にコマンドを実行するには」も参照してください。

既定値：なし

既定値

[既定値]ボタンをクリックすると全ての項目に既定値が設定されます。

4.37.23. WebLogicタブ

JVM監視リソース調整プロパティの「WebLogic」タブ

ワークマネージャのリクエストを監視する

WebLogic Serverでワークマネージャの待機リクエスト状態の監視設定をします。

チェックボックスがオン

監視します。

チェックボックスがオフ(既定値)

監視しません。

監視対象ワークマネージャ(255バイト以内)

監視対象のWebLogic Serverに対して監視したいアプリケーションのワークマネージャ名を設定します。ワークマネージャ監視を実施する場合、必ず設定してください。

App1[WM1,WM2,…];App2[WM1,WM2,…];…

App とWM にて指定可能な文字はASCII文字です。(Shift_JIS コード0x005C と0x00A1～0x00DF を除く)

アプリケーションアーカイブのバージョンを持つアプリケーションを指定する場合、App には「アプリケーション名#バージョン」を指定してください。

アプリケーション名に"["や"]"が付いている場合、"["や"]"の直前に「¥¥」を追加してください。

(例) アプリケーション名がapp[2]の場合、app¥¥[2¥¥]

既定値：なし

リクエスト数(1～65535)

監視対象のWebLogic Serverのワークマネージャにおいて、待機リクエスト数のしきい値を設定します。

既定値： 65535

平均値(1～65535)

監視対象のWebLogic Serverのワークマネージャにおいて、待機リクエスト数の平均値のしきい値を設定します。

既定値： 65535

前回計測値からの増加率(1～1024)

監視対象のWebLogic Serverのワークマネージャにおいて、待機リクエスト数の前回計測以降の増分に対するしきい値を設定します。

既定値： 80[%]

スレッドプールのリクエストを監視する

監視対象のWebLogic Serverのスレッドプールにおいて、待機リクエスト数(WebLogic Server内部で処理待ちとなっているHTTPリクエスト数)、実行リクエスト数(WebLogic Server内部で単位時間当たり実行したHTTPリクエスト数)の監視設定をします。

チェックボックスがオン(既定値)

監視します。

チェックボックスがオフ

監視しません。

待機リクエストリクエスト数(1～65535)

待機リクエスト数のしきい値を設定します。

既定値： 65535

待機リクエスト平均値(1～65535)

待機リクエスト数の平均値のしきい値を設定します。

既定値： 65535

待機リクエスト前回計測値からの増加率(1～1024)

待機リクエスト数の前回計測以降の増分に対するしきい値を設定します。

既定値： 80[%]

実行リクエストリクエスト数(1～65535)

単位時間あたりに実行したリクエスト数のしきい値を設定します。

既定値： 65535

実行リクエスト平均値(1～65535)

単位時間あたりに実行したリクエスト数の平均値のしきい値を設定します。

既定値： 65535

実行リクエスト前回計測値からの増加率(1～1024)

単位時間あたりに実行したリクエスト数の前回計測以降の増分に対するしきい値を設定します。

既定値： 80[%]

コマンド(255バイト以内)

監視対象のJava VM異常検出時に、実行するコマンドを設定します。異常の原因別に実行するコマンドおよび引数の指定が可能です。絶対パスで指定してください。また、実行ファイル名は二重引用符("")で括ってください。

例)"\Program Files\bin\command.bat" arg1 arg2

ここではWebLogic Serverのワークマネージャのリクエストやスレッドプールのリクエストにおける異常検出時に、実行するコマンドを設定します。

「異常検出時に障害原因別にコマンドを実行するには」も参照してください。

既定値：なし

既定値

[既定値]ボタンをクリックすると全ての項目に既定値が設定されます。

4.38. システムモニタリソースを理解する

システムモニタリソースは、システムリソースを監視するモニタリソースです。システムリソースの統計情報を継続的に収集し、一定のナレッジ情報にしたがい解析を行います。解析結果からリソース枯渇の発生を早期検出する機能を提供します。

4.38.1. システムモニタリソースの注意事項

回復対象には System Resource Agent がリソース監視異常を検出した際のフェイルオーバ対象リソースを指定してください。

System Resource Agent の設定値は、デフォルトで使用することを推奨します。

以下のような場合には、リソース監視異常を検出できないことがあります。

システムリソースがしきい値をはさんで増減を繰り返している場合

システムが高負荷な場合などでは、統計情報収集に時間がかかり統計情報収集間隔での情報収集ができない場合があります。

動作中に OS の日付/時刻を変更した場合、10 分間隔で行っている解析処理のタイミングが日付/時刻変更後の最初の 1 回だけずれてしまいます。以下のようなことが発生するため、必要に応じてクラスタのサスペンド・リジュームを行ってください。

異常として検出する経過時間を過ぎても、異常検出が行われない。
異常として検出する経過時間前に、異常検出が行われる。

クラスタのサスペンド・リジュームを行った場合、その時点から情報の収集を開始します。

システムリソースの使用量の解析は 10 分間隔で行います。そのため、監視継続時間を経過してから最大 10 分後に異常を検出する場合があります

ディスクリソースの使用量の解析は 60 分間隔で行います。そのため、監視継続時間を経過してから最大 60 分後に異常を検出する場合があります。

ディスクリソースの空き容量監視にて指定するディスクサイズは、実際のディスクサイズより小さい値を指定してください。大きい値を指定した場合、空き容量不足として異常検出します。

監視中のディスクを交換した際、交換前と交換後のディスクにて以下のいずれかが異なる場合、それまでの解析情報はクリアします。

ディスクの総容量
ファイルシステム

スワップ領域を割り当てていないマシンでは、[総仮想メモリ使用量の監視] のチェックを外してください。

[総仮想メモリ使用量の監視] チェックボックスをオンにすると、物理メモリを除いたスワップ領域の使用量の監視が有効になります。

ディスクリソース監視機能は、固定ディスク以外は監視対象外です。

ディスクリソース監視機能で同時に監視できる最大のディスク数は 26 台です。

モニタリソースの定義画面のタイプ欄に「システムモニタ」が表示されない場合は、[ライセンス情報取得] を選択し、ライセンス情報を取得してください。

システムモニタリソースの監視開始から、実際に監視処理を行うまでの間、システムモニタリソースのステータスは "警告" になります。

システムモニタリソース、プロセスリソースモニタリソースの登録数が多い場合は、下記メッセージがアラートログに出力され異常を検出する場合があります。

本メッセージが出力された場合は [監視(共通)] タブからタイムアウトの設定を見直してください。

監視 sraw は異常を検出しました。(99 : monitor was timeout)

4.38.2. システムモニタリソースの監視方法

システムモニタリソースは、以下の監視を行います。

システムおよびディスクのシステムリソースの使用量を継続的に収集し、解析します。

リソースの使用量があらかじめ設定したしきい値以上になった場合、異常を検出します。

異常を検出した状態が監視継続時間連続すると、リソース監視異常を通知します。

システムリソース監視をデフォルト値で運用した場合、リソースの使用量が 90% 以上の状態が連続すると、 60 分後にリソース監視の異常を通知します。

以下に、システムリソース監視をデフォルト値で運用した場合の総メモリ使用量の異常検出の例を示します。

総メモリ使用量が経過時間と共に総メモリ使用量のしきい値以上の状態が続き、一定時間以上になった

図 4.68 総メモリ使用量のしきい値以上の状態が一定時間続いた場合（異常検出する）
総メモリ使用量が経過時間と共に総メモリ使用のしきい値の前後で増減し、連続して総メモリ使用量のしきい値以上にならない

以下の図では、総メモリ使用量は一時的に総メモリ使用量のしきい値（90%）以上になります。しかし、そのしきい値を超える状態も監視継続時間（60分）連続することなく推移しているため、総メモリ使用量の異常を検出しません。

図 4.69 総メモリ使用量のしきい値以上の状態が一定時間続かない場合（異常検出しない）

ディスクリソース監視をデフォルト値で運用した場合、 24 時間後に通知レベルの異常を通知します。

以下に、ディスクリソース監視をデフォルト値で運用した場合のディスク使用率の異常検出の例を示します。

警告レベルのディスク容量監視

ディスク使用率が警告レベル上限値で指定された一定のしきい値以上になった

ディスク使用率が警告レベル上限値を超えたため、ディスク容量監視異常と判定します。

図 4.70 ディスク使用率が警告レベル上限値以上になった場合（異常検出する）
ディスク使用率が一定の範囲内で増減し、警告レベル上限値で指定された一定のしきい値以上にならない

ディスク使用率は警告レベル上限値を超えない範囲で増減しているため、ディスク容量監視異常と判定しません。

図 4.71 ディスク使用率が警告レベル上限値以上にならない場合（異常検出しない）

通知レベルのディスク容量監視

ディスク使用率が経過時間と共に通知レベル上限値で指定された一定のしきい値以上の状態が続き、一定時間以上になった

ディスク使用率が通知レベル上限値を連続して超えたため、ディスク容量監視異常と判定します。

図 4.72 ディスク使用率において、通知レベル上限値以上の状態が一定時間続いた場合（異常検出する）
ディスク使用率が一定の範囲内で増減し、通知レベル上限値で指定された一定のしきい値以上にならない

ディスク使用率が通知レベル上限値を一時的に超えるものの、その状態が一定時間続かないため、ディスク容量監視異常とは判定しません。

図 4.73 ディスク使用率において、通知レベル上限値以上の状態が一定時間続かない場合（異常検出しない）

4.38.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（sraw）

CPU使用率の監視

CPU使用率の監視を行うかどうかを設定します。

チェックボックスがオン

CPU使用率の監視を行います。

チェックボックスがオフ

CPU使用率の監視を行いません。

使用率 (1～100)

CPU使用率の異常を検出するしきい値を設定します。

継続時間 (1～1440)

CPU使用率の異常を検出する時間を設定します。

指定した時間以上連続してしきい値を超過した場合、異常を検出します。

総メモリ使用量の監視

総メモリ使用量の監視を行うかどうかを設定します。

チェックボックスがオン

総メモリ使用量の監視を行います。

チェックボックスがオフ

総メモリ使用量の監視を行いません。

使用量 (1～100)

メモリの使用量の異常を検出するしきい値(システムのメモリ搭載量に対する割合)を設定します。

継続時間 (1～1440)

総メモリ使用量の異常を検出する時間を設定します。

指定した時間以上連続してしきい値を超過した場合、異常を検出します。

総仮想メモリ使用量の監視

総仮想メモリ使用量の監視を行うかどうかを設定します。

チェックボックスがオン

総仮想メモリ使用量の監視を行います。

チェックボックスがオフ

総仮想メモリ使用量の監視を行いません。

使用量 (1～100)

仮想メモリの使用量の異常を検出するしきい値を設定します。

継続時間 (1～1440)

総仮想メモリ使用量の異常を検出する時間を設定します。

指定した時間以上連続してしきい値を超過した場合、異常を検出します。

追加

監視するディスクを追加します。[監視条件の入力] ダイアログボックスが表示されます。

[監視条件の入力] ダイアログの説明に従い異常とする監視条件の詳細設定を行います。

削除

[ディスク一覧] で選択しているディスクを監視対象から削除します。

編集

[監視条件の入力]ダイアログボックスが表示されます。[ディスク一覧] で選択しているディスクの監視条件が表示されるので、編集して[OK]を選択します。

論理ドライブ

監視を行う論理ドライブを設定します。

使用率

ディスク使用率の監視を行うかどうかを設定します。

チェックボックスがオン

ディスク使用率の監視を行います。

チェックボックスがオフ

ディスク使用率の監視を行いません。

警告レベル (1～100)

ディスク使用率の警報レベルの異常を検出するしきい値を設定します。

通知レベル (1～100)

ディスク使用率の通知レベルの異常を検出するしきい値を設定します。

継続時間 (1～43200)

ディスク使用率の通知レベルの異常を検出する時間を設定します。

指定した時間以上連続してしきい値を超過した場合、異常を検出します。

空き容量

ディスク空き容量の監視を行うかどうかを設定します。

チェックボックスがオン

ディスク空き容量の監視を行います。

チェックボックスがオフ

ディスク空き容量の監視を行いません。

警告レベル (1～4294967295)

ディスク空き容量の警報レベルの異常を検出する容量（MB）を設定します。

通知レベル (1～4294967295)

ディスク空き容量の通知レベルの異常を検出する容量（MB）を設定します。

継続時間 (1～43200)

ディスク空き容量の通知レベルの異常を検出する時間を設定します。

指定した時間以上連続してしきい値を超過した場合、異常を検出します。

4.39. プロセスリソースモニタリソースを理解する

プロセスリソースモニタリソースは、プロセスが使用するリソースを監視するモニタリソースです。プロセスが使用するリソースの統計情報を継続的に収集し、一定のナレッジ情報にしたがい解析を行います。解析結果からリソース枯渇の発生を早期検出する機能を提供します。

4.39.1. プロセスリソースモニタリソースの注意事項

回復対象にはプロセスリソースモニタリソースが異常を検出した際のフェイルオーバ対象リソースを指定してください。

プロセスリソースモニタリソースの設定値は、デフォルトで使用することを推奨します。

システムが高負荷な場合などでは、統計情報収集に時間がかかり統計情報収集間隔での情報収集ができない場合があります。

動作中に OS の日付/時刻を変更した場合、10分間隔で行っている解析処理のタイミングが日付/時刻変更後の最初の 1 回だけずれてしまいます。以下のようなことが発生するため、必要に応じてクラスタのサスペンド・リジュームを行ってください。

異常として検出する経過時間を過ぎても、異常検出が行われない。
異常として検出する経過時間前に、異常検出が行われる。

クラスタのサスペンド・リジュームを行った場合、その時点から情報の収集を開始します。

プロセスリソースの使用量の解析は 10 分間隔で行います。そのため、監視継続時間を経過してから最大 10 分後に異常を検出する場合があります

モニタリソースの定義画面のタイプ欄に「プロセスリソースモニタ」が表示されない場合は、[ライセンス情報取得]を選択し、ライセンス情報を取得してください。

プロセスリソースモニタリソースに必要なライセンスについては、本章の「モニタリソースとは? 」 - 「ライセンスが必要なモニタリソース」を参照してください。

プロセスリソースモニタリソースの監視開始から、実際に監視処理を行うまでの間、プロセスリソースモニタリソースのステータスは "警告" になります。

プロセスリソースモニタリソースのステータスを異常から正常に戻すには、以下のいずれかを実施してください。

クラスタのサスペンド・リジューム
クラスタの停止・開始

監視対象プロセス名は、実際に動作しているプロセスのプロセス名を以下のコマンドで確認し設定してください。

CLUSTERPROインストールパス\bin\GetProcess.ps1

上記コマンドを実行すると、コマンドを実行したフォルダ配下に GetProcess_Result.txt が出力されます。GetProcess_Result.txt を開き、表示されているプロセスの CommandLine 部分を指定してください。出力情報に「"」(ダブルクォーテーション)がある場合は、「"」も含めて指定してください。

出力ファイルの例

20XX/07/26 12:03:13
Caption         CommandLine
services.exe    C:\WINDOWS\system32\services.exe
svchost.exe     C:\WINDOWS\system32\svchost -k rpcss
explorer.exe    C:\WINDOWS\Explorer.EXE

上記のコマンド出力情報から svchost.exe を監視する場合、

C:\WINDOWS\system32\svchost -k rpcss を監視対象プロセス名に指定します。

監視対象プロセス名に指定したプロセス名はプロセスの引数もプロセス名の一部として監視対象のプロセスを特定します。監視対象プロセス名を指定する場合は、引数を含めたプロセス名を指定してください。引数を含めずプロセス名のみ監視したい場合は、ワイルドカード（＊）を使い、引数を含めない前方一致または部分一致で指定してください。

システムモニタリソース、プロセスリソースモニタリソースの登録数が多い場合は、下記メッセージがアラートログに出力され異常を検出する場合があります。

本メッセージが出力された場合は[監視(共通)]タブからタイムアウトの設定を見直してください。

監視 psrw は異常を検出しました。(99 : monitor was timeout)

4.39.2. プロセスリソースモニタリソースの監視方法

プロセスリソースモニタリソースは、以下の監視を行います。

プロセスリソースの使用量を継続的に収集し、解析します。

リソースの使用量があらかじめ設定したしきい値以上になった場合、異常を検出します。

異常を検出した状態が監視継続時間連続すると、リソース監視異常を通知します。

プロセスリソースモニタリソース（CPU、メモリ、スレッド数）をデフォルト値で運用した場合、24 時間後にリソース監視の異常を通知します。

以下に、プロセスリソース監視のメモリ使用量の異常検出の例を示します。

メモリ使用量が経過時間と共に増減しながら、規定回数以上最大値を更新し、増加率が初期値の 10% 以上になった

最大値更新回数が 24 時間（デフォルト）以上になり、増加率も初期値の 10％を上回っているため、メモリリークと判定します。

図 4.74 メモリ使用量が規定回数以上最大値を更新し、増加率が初期値の10%を超過（異常検出する）
メモリ使用量が経過時間と共に一定の範囲内で増減

メモリ使用量は、一定の値未満の範囲で増減しているため、メモリリークと判定しません。

図 4.75 メモリ使用量が一定の範囲内で増減（異常検出しない）

4.39.3. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（psrw）

プロセス名（1023 バイト以内）

監視対象プロセスのプロセス名を設定します。プロセス名を設定しない場合、起動中のすべてのプロセスが対象となります。

また、次の3つのパターンでプロセス名のワイルドカード指定が可能です。このパターン以外の指定はできません。

【前方一致】＜プロセス名に含まれる文字列＞＊

【後方一致】＊＜プロセス名に含まれる文字列＞

【部分一致】＊＜プロセス名に含まれる文字列＞＊

CPU使用率の監視

CPU使用率の監視を行うかどうかを設定します。

チェックボックスがオン

CPU使用率の監視を行います。

チェックボックスがオフ

CPU使用率の監視を行いません。

使用率（1～100）

CPU使用率の異常を検出するしきい値を設定します。

継続時間（1～4320）

CPU使用率の異常を検出する時間を設定します。

指定した時間以上連続してしきい値を超過した場合、異常を検出します。

メモリ使用量の監視

メモリ使用量の監視を行うかどうかを設定します。

チェックボックスがオン

メモリ使用量の監視を行います。

チェックボックスがオフ

メモリ使用量の監視を行いません。

初回監視時からの増加率（1～1000）

メモリ使用量の異常を検出するしきい値を設定します。

最大更新回数（1～4320）

メモリ使用量の異常を検出する更新回数を設定します。

指定した更新回数以上連続してしきい値を超過した場合、異常を検出します。

オープンファイル数の監視（最大値）

オープンファイル数の監視（最大値）を行うかどうかを設定します。

チェックボックスがオン

オープンファイル数の監視を行います。

チェックボックスがオフ

オープンファイル数の監視を行いません。

更新回数（1～4320）

オープンファイル数の異常を検出する更新回数を設定します。

オープンファイル数の最大値を指定した回数以上更新した場合、異常を検出します。

スレッド数の監視

スレッド数の監視を行うかどうかを設定します。

チェックボックスがオン

スレッド数の監視を行います。

チェックボックスがオフ

スレッド数の監視を行いません。

継続時間（1～4320）

スレッド数の異常を検出する時間を設定します。

スレッド数が増加し、指定した時間以上経過したプロセスがある場合、異常を検出します。

同一名プロセスの監視

同一名プロセスの監視を行うかどうかを設定します。

チェックボックスがオン

同一名プロセスの監視を行います。

チェックボックスがオフ

同一名プロセスの監視を行いません。

個数（1～10000）

同一名プロセスの異常を検出する個数を設定します。

同一名プロセスが指定した個数以上存在する場合、異常を検出します。

4.40. ユーザ空間モニタリソースを理解する

ユーザ空間モニタリソースは、ユーザ空間のストールを監視するモニタリソースです。

4.40.1. ユーザ空間モニタリソースの監視方法

ユーザ空間モニタリソースは以下の監視を行います。

監視開始時に keepalive タイマを起動し、以降、監視間隔ごとに keepalive タイマの更新を行います。ユーザ空間のストールによって、一定時間以上タイマの更新が行われなかった場合に異常を検出します。

監視処理を拡張させる設定として、ダミースレッドの作成があります。設定が有効な場合は、監視間隔ごとにダミースレッドの作成を行います。ダミースレッドの作成に失敗した場合は keepalive タイマの更新を行いません。

ユーザ空間モニタリソースの処理ロジックは以下の通りです。

処理概要

以下の 2～3 の処理を繰り返します。
1. keepaliveタイマセット
2. ダミースレッド作成
3. keepaliveタイマ更新
処理 2 は監視の拡張設定の処理です。設定を行っていないと処理を行いません。
タイムアウトしない（上記 2～3 が問題無く処理される）場合の挙動

リセットなどのリカバリ処理は実行されません。
タイムアウトした（上記 2～3 のいずれかが停止または遅延した）場合の挙動

CLUSTERPRO のカーネルモジュールを経由して他のサーバへ[自サーバのリセット]をアナウンスします。

アクションの設定にしたがって、CLUSTERPRO のカーネルモジュールによりHW リセットまたは意図的なストップエラーを発生させます。

4.40.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（userw）

監視方法

ユーザ空間の監視方法を指定します。

keepalive

clphbドライバを使用します。

タイムアウト発生時動作

タイムアウト発生時の動作を指定します。

何もしない

何も行いません。

HW リセット

ハードウェアをリセットします。

意図的なストップエラーの発生

ストップエラーを発生させます。

注釈

タイムアウト発生時動作に関しては、擬似障害を発生させることができません。

ダミースレッドの作成

監視を行う際にダミースレッドの作成を行うかどうかを設定します。

チェックボックスがオン (既定値)

ダミースレッドの作成を行います。

チェックボックスがオフ

ダミースレッドの作成を行いません。

4.41. LB プローブポートモニタリソースを理解する

LB プローブポートモニタリソースは、LB プローブポートリソースが起動しているノードに対して、LB プローブポートリソース活性時に起動する制御プロセスの死活監視を行います。正常に起動していない場合は、監視異常となります。

4.41.1. LB プローブポートモニタリソースの注意事項

LB プローブポートリソースを追加すると自動的に作成されます。LB プローブポートリソース 1 つに対して 1 つの LB プローブポートモニタリソースが自動的に作成されます。
LB プローブポートモニタリソースでは、LB プローブポートリソースでのヘルスチェックのタイムアウトの発生の有無を監視します。そのため、LB プローブポートモニタリソースの監視インターバルは、監視対象の LB プローブポートリソースで設定した[ヘルスチェックのタイムアウト]の値より、大きな値を設定する必要があります。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「LB プローブポートリソースの設定について」を参照してください。

4.41.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（lbppw）

ヘルスチェックのタイムアウト時動作

LB プローブポートリソースにおいて、ヘルスチェックのタイムアウトが発生した場合の回復動作を指定します。

4.42. AWS Elastic IPモニタリソースを理解する

AWS Elastic IPモニタリソースは、Elastic IP(以下、EIP)制御の場合は AWS CLI コマンドを利用して EIP の存在を確認するモニタリソースです。

4.42.1. AWS Elastic IPモニタリソースの注意事項

AWS Elastic IPリソースを追加すると自動的に作成されます。AWS Elastic IPリソース 1 つに対して 1 つの AWS Elastic IPモニタリソースが自動的に作成されます。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS Elastic IPリソースの設定について」を参照してください。
IAM の設定については『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

4.42.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（awseipw）

AWS CLIコマンド応答取得失敗時動作

AWS CLIコマンド応答取得失敗時の動作を指定します。AWS CLIコマンド応答取得失敗は、例えばリージョンのエンドポイントのメンテナンスによる停止やダウン、リージョンのエンドポイントまでの通信路の問題や遅延、高負荷によるAWS CLIのタイムアウト、credentialエラーの場合に発生します。以下を目安に設定してください。

AWS CLIコマンドの失敗時にフェイルオーバしたい場合: [回復動作を実行する]を設定してください。

AWS CLIコマンドの失敗時にフェイルオーバせず警告を表示させたい場合:[回復動作を実行しない(警告を表示する)]を設定してください。

AWS CLIコマンドの失敗は監視対象が異常ではないため何もしない場合:[回復動作を実行しない(警告を表示しない)]を設定してください。この場合でも登録した IP アドレスの健全性が確認できない場合の異常は検出可能です。そのため、この設定を推奨します。

4.43. AWS 仮想IPモニタリソースを理解する

AWS 仮想IPモニタリソースは、仮想IP(以下、VIP)制御の場合は VIP の存在及び VPC のルーティングの健全性を確認するモニタリソースです。

AWS仮想IPモニタリソースでは監視時に AWS CLI を実行して route table の確認処理を行います。

4.43.1. AWS 仮想IPモニタリソースの注意事項

AWS 仮想IPリソースを追加すると自動的に作成されます。AWS 仮想IPリソース 1 つに対して 1 つの AWS 仮想IPモニタリソースが自動的に作成されます。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS 仮想IPリソースの設定について」を参照してください。
IAM の設定については『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

4.43.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（awsvipw）

AWS CLIコマンド応答取得失敗時動作

AWS CLIコマンド応答取得失敗時の動作を指定します。AWS CLIコマンド応答取得失敗は、例えばリージョンのエンドポイントのメンテナンスによる停止やダウン、リージョンのエンドポイントまでの通信路の問題や遅延、高負荷によるAWS CLIのタイムアウト、credentialエラーの場合に発生します。以下を目安に設定してください。

AWS CLIコマンドの失敗時にフェイルオーバしたい場合: [回復動作を実行する]を設定してください。

AWS CLIコマンドの失敗時にフェイルオーバせず警告を表示させたい場合:[回復動作を実行しない(警告を表示する)]を設定してください。

AWS CLIコマンドの失敗は監視対象が異常ではないため何もしない場合:[回復動作を実行しない(警告を表示しない)]を設定してください。この場合でも登録した IP アドレスの健全性が確認できない場合の異常は検出可能です。そのため、この設定を推奨します。

4.44. AWS セカンダリ IP モニタリソースを理解する

AWS セカンダリ IP モニタリソースは、セカンダリ IP アドレスの存在有無を監視するモニタリソースです。

4.44.1. AWS セカンダリ IP モニタリソースの注意事項

AWS セカンダリ IP リソースを追加すると自動的に作成されます。AWS セカンダリ IP リソース 1 つに対して 1 つの AWS セカンダリ IP モニタリソースが自動的に作成されます。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS セカンダリ IP リソースの設定について」を参照してください。
IAM の設定については『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

4.44.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（awssipw）

AWS CLIコマンド応答取得失敗時動作

AWS CLIコマンド応答取得失敗時の動作を指定します。AWS CLIコマンド応答取得失敗は、例えばリージョンのエンドポイントのメンテナンスによる停止やダウン、リージョンのエンドポイントまでの通信路の問題や遅延、高負荷によるAWS CLIのタイムアウト、credentialエラーの場合に発生します。以下を目安に設定してください。

AWS CLIコマンドの失敗時にフェイルオーバしたい場合: [回復動作を実行する]を設定してください。

AWS CLIコマンドの失敗時にフェイルオーバせず警告を表示させたい場合:[回復動作を実行しない(警告を表示する)]を設定してください。

AWS CLIコマンドの失敗は監視対象が異常ではないため何もしない場合:[回復動作を実行しない(警告を表示しない)]を設定してください。この場合でも登録した IP アドレスの健全性が確認できない場合の異常は検出可能です。そのため、この設定を推奨します。

4.45. AWS AZモニタリソースを理解する

AWS AZ モニタリソースは、AWS CLI コマンドを利用して Availability Zone (以下、AZ) の健全性の監視を行うモニタリソースです。 AWS CLI を使って取得できる AZ の状態が available の場合は正常、information や impaired の場合は警告、unavailable の場合は異常となります。

4.45.1. AWS AZモニタリソースの注意事項

IAM の設定については『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

4.45.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（awsazw）

アベイラビリティーゾーン (45 バイト以内)

監視を行うアベイラビリティーゾーンを指定します。

注釈

クラスタ内のサーバがそれぞれ異なるアベイラビリティーゾーンに所属している場合は、サーバ個別設定を行い、各サーバに対応するアベイラビリティーゾーンを指定してください。

AWS CLI コマンド応答取得失敗時動作

AWS CLI コマンド応答取得失敗時の動作を指定します。AWS CLI コマンド応答取得失敗は、例えばリージョンのエンドポイントのメンテナンスによる停止やダウン、リージョンのエンドポイントまでの通信路の問題や遅延、高負荷による AWS CLI のタイムアウト、credential エラーの場合に発生します。以下を目安に設定してください。

AWS CLI コマンドの失敗時にフェイルオーバしたい場合 : [回復動作を実行する] を設定してください。

AWS CLI コマンドの失敗時にフェイルオーバせず警告を表示させたい場合 : [回復動作を実行しない(警告を表示する)] を設定してください。

AWS CLI コマンドの失敗は監視対象が異常ではないため何もしない場合 : [回復動作を実行しない(警告を表示しない)] を設定してください。この場合でも登録した IP アドレスの健全性が確認できない場合の異常は検出可能です。そのため、この設定を推奨します。

4.46. AWS DNS モニタリソースを理解する

AWS DNS モニタリソースは、AWS CLI コマンドを利用して登録した IP アドレスの健全性を確認するモニタリソースです。

以下の場合に異常を通知します。

該当するリソースレコードセットが存在しない場合。
登録した[IP アドレス]が仮想ホスト名(DNS 名)の名前解決によって得られない場合。

4.46.1. AWS DNS モニタリソースの注意事項

AWS DNS リソースを追加すると自動的に作成されます。AWS DNS リソース 1 つに対して 1 つの AWS DNS モニタリソースが自動的に作成されます。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「AWS DNS リソースの設定について」を参照してください。
IAM の設定については『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照してください。

4.46.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（awsdnsw）

AWS CLIコマンド応答取得失敗時動作

AWS CLIコマンド応答取得失敗時の動作を指定します。AWS CLIコマンド応答取得失敗は、例えばリージョンのエンドポイントのメンテナンスによる停止やダウン、リージョンのエンドポイントまでの通信路の問題や遅延、高負荷によるAWS CLIのタイムアウト、credentialエラーの場合に発生します。以下を目安に設定してください。

AWS CLIコマンドの失敗時にフェイルオーバしたい場合: [回復動作を実行する]を設定してください。

AWS CLIコマンドの失敗時にフェイルオーバせず警告を表示させたい場合:[回復動作を実行しない(警告を表示する)]を設定してください。

AWS CLIコマンドの失敗は監視対象が異常ではないため何もしない場合:[回復動作を実行しない(警告を表示しない)]を設定してください。この場合でも登録した IP アドレスの健全性が確認できない場合の異常は検出可能です。そのため、この設定を推奨します。

名前解決確認をする

チェックボックスがオン(既定)

登録した IP アドレスが仮想ホスト名(DNS 名)の名前解決によって得られるかを確認します。

チェックボックスがオフ

監視しません。

4.47. Azure DNS モニタリソースを理解する

Azure DNS モニタリソースは、Microsoft Azureの権威 DNS サーバーに対してクエリを発行し、登録した IP アドレスの健全性を確認するモニタリソースです。

以下の場合に異常を通知します。

登録した[IP アドレス]が仮想ホスト名(DNS 名)の名前解決によって得られない場合。
DNSサーバー一覧の取得に失敗した場合。

4.47.1. Azure DNS モニタリソースの注意事項

Azure DNS リソースを追加すると自動的に作成されます。Azure DNS リソース 1 つに対して 1 つの Azure DNS モニタリソースが自動的に作成されます。
パブリック DNS ゾーンを利用している場合、ゾーンの登録およびクエリに対して課金が発生します。そのため[名前解決確認をする]をオンにした場合、[インターバル]ごとに課金が発生します。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Azure DNS リソースの設定について」を参照してください。
IAM の設定については『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO インストール前」 - 「Azure環境におけるIAMの設定について」を参照してください。

4.47.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（azurednsw）

名前解決確認をする

チェックボックスがオン(既定)

登録した IP アドレスが仮想ホスト名(DNS 名)の名前解決によって得られるかを確認します。

チェックボックスがオフ

監視しません。

4.48. Google Cloud DNS モニタリソースを理解する

Google Cloud DNS モニタリソースは、活性時監視の対象リソースに指定された Google Cloud DNS リソースが制御するレコードセットや A レコードが、Google Cloud DNS 上に存在することを確認します。

4.48.1. Google Cloud DNS モニタリソースの注意事項

Google Cloud DNS リソースを追加すると自動的に作成されます。Google Cloud DNS リソース 1 つに対して 1 つの Google Cloud DNS モニタリソースが自動的に作成されます。
『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」 - 「Google Cloud DNS リソースについて」を参照してください。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Google Cloud DNS リソースの設定について」を参照してください。

4.48.2. 監視 (固有) タブ

Google Cloud DNS モニタリソースの監視 (固有) タブはありません。

4.49. Oracle Cloud セカンダリ IP モニタリソースを理解する

Oracle Cloud セカンダリ IP モニタリソースは、セカンダリ IP アドレスの存在有無を監視するモニタリソースです。

4.49.1. Oracle Cloud セカンダリ IP モニタリソースの注意事項

Oracle Cloud セカンダリ IP リソースを追加すると自動的に作成されます。Oracle Cloud セカンダリ IP リソース 1 つに対して 1 つの Oracle Cloud セカンダリ IP モニタリソースが自動的に作成されます。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の情報作成時」 -「Oracle Cloud セカンダリ IP リソースの設定について」を参照してください。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「OCI 環境における CLI の設定について」を参照してください。
『スタートアップガイド』の「注意制限事項」 - 「OSインストール後、CLUSTERPROインストール前」 - 「OCI 環境におけるポリシーの設定について」を参照してください。

4.49.2. 監視 (固有) タブ

Oracle Cloud セカンダリ IP モニタリソースの監視 (固有) タブはありません。

4.50. Oracle Cloud DNS モニタリソースを理解する

Oracle Cloud DNS モニタリソースは、活性時監視の対象リソースに指定された Oracle Cloud DNS リソースが制御するレコードセットや A レコードが、Oracle Cloud DNS 上に存在することを確認します。
マルチリージョン環境で構成されたクラスタの場合に対象リソースの設定で [マルチリージョンでのリソースレコードの操作範囲] を [クラスタサーバが所属するすべてのリージョン] とした場合、フェイルオーバグループが起動していないサーバが所属するリージョンの Oracle Cloud DNS に対して、 [インターバル]ごとにレコードセットの登録または更新処理を行います。

4.50.1. Oracle Cloud DNS モニタリソースの注意事項

Oracle Cloud DNS リソースを追加すると自動的に作成されます。Oracle Cloud DNS リソース 1 つに対して 1 つの Oracle Cloud DNS モニタリソースが自動的に作成されます。
パブリック DNS ゾーンを利用している場合、ゾーンの登録およびクエリに対して課金が発生します。そのため[名前解決確認をする]をオンにした場合やマルチリージョン環境で構成されたクラスタの場合に対象リソースの設定で [マルチリージョンでのリソースレコードの操作範囲] を [クラスタサーバが所属するすべてのリージョン] とした場合、[インターバル]ごとに課金が発生します。
マルチリージョン環境で構成されたクラスタにおいて、フェイルオーバグループが起動していないサーバのリージョン内から名前解決によって登録した IP アドレス(DNS 名)が得られない場合があります。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「Oracle Cloud DNS リソースの設定について」を参照してください。
『スタートアップガイド』の「注意制限事項」 - 「CLUSTERPRO の構成情報作成時」 - 「OCI 環境における CLI の設定について」を参照してください。
『スタートアップガイド』の「注意制限事項」 - 「OSインストール後、CLUSTERPROインストール前」 - 「OCI 環境におけるポリシーの設定について」を参照してください。

4.50.2. 監視 (固有) タブ

モニタリソースのプロパティの「監視（固有）」タブ（ocdnsw）

名前解決確認をする

チェックボックスがオン(既定)

フェイルオーバグループが起動しているサーバから登録した IP アドレスが仮想ホスト名(DNS 名)の名前解決によって得られるかを確認します。

チェックボックスがオフ

監視しません。

4. モニタリソースの詳細

4.1. モニタリソースとは?

4.1.1. モニタリソースの監視タイミング

4.1.2. モニタリソースの擬似障害 発生/解除

4.1.3. モニタリソースの監視インターバルのしくみ

4.1.4. モニタリソースによる異常検出時の動作

4.1.5. 監視異常からの復帰 (正常)

4.1.6. 回復動作時の回復対象活性/非活性異常

4.1.7. 回復スクリプト、回復動作前スクリプトについて

4.1.8. モニタリソースの遅延警告

4.1.9. モニタリソースの監視開始待ち

4.1.10. モニタリソース異常検出時の再起動回数制限

4.1.11. ライセンスが必要なモニタリソース

4.2. モニタ共通のプロパティ

4.3. モニタリソースのプロパティ

4.3.1. 情報タブ

4.3.2. 監視 (共通) タブ

4.3.3. 監視(固有) タブ

4.3.4. 回復動作タブ

4.4. アプリケーションモニタリソースを理解する

4.4.1. アプリケーションモニタリソースの監視方法

4.4.2. アプリケーションモニタリソースに関する注意事項

4.4.3. 監視 (固有) タブ

4.5. ディスク RW モニタリソースを理解する

4.5.1. ディスク RW モニタリソースによる監視方法

4.5.2. 監視 (固有) タブ

4.6. フローティング IP モニタリソースを理解する

4.6.1. フローティング IP モニタリソースの監視方法

4.6.2. フローティング IP モニタリソースに関する注意事項

4.6.3. 監視 (固有) タブ

4.7. IP モニタリソースを理解する

4.7.1. IP モニタリソースの監視方法

4.7.2. 監視 (固有) タブ

4.8. ミラーディスクモニタリソースを理解する

4.8.1. ミラーディスクモニタリソースの注意事項

4.8.2. 監視 (固有) タブ

4.9. NIC Link Up/Down モニタリソースを理解する

4.9.1. NIC Link Up/Down 監視の構成および範囲

4.9.2. 監視 (固有) タブ

4.10. マルチターゲットモニタリソースを理解する

4.10.1. マルチターゲットモニタリソースの注意事項

4.10.2. マルチターゲットモニタリソースのステータス

4.10.3. 監視 (固有) タブ

4.11. レジストリ同期モニタリソースを理解する

4.11.1. レジストリ同期モニタリソースに関する注意事項

4.11.2. 監視 (固有) タブ

4.12. ディスク TUR モニタリソースを理解する

4.12.1. ディスク TUR モニタリソースに関する注意事項

4.12.2. 監視 (固有) タブ

4.13. サービスモニタリソースを理解する

4.13.1. サービスモニタリソースの監視方法

4.13.2. サービスモニタリソースに関する注意事項

4.13.3. 監視 (固有) タブ

4.14. 仮想コンピュータ名モニタリソースを理解する

4.14.1. 仮想コンピュータ名モニタリソースの監視方法

4.14.2. 仮想コンピュータ名モニタリソースに関する注意事項

4.14.3. 監視 (固有) タブ

4.15. ダイナミックDNSモニタリソースを理解する

4.15.1. ダイナミックDNSモニタリソースに関する注意事項

4.15.2. 監視 (固有) タブ

4.16. 仮想 IP モニタリソースを理解する

4.16.1. 仮想 IP モニタリソースの監視方法

4.16.2. 仮想 IP モニタリソースに関する注意事項

4.16.3. 監視 (固有) タブ

4.17. CIFS モニタリソースを理解する

4.17.1. CIFS モニタリソースの監視方法

4.17.2. CIFS モニタリソースに関する注意事項

4.17.3. 監視 (固有) タブ

4.18. ハイブリッドディスクモニタリソースを理解する

4.18.1. ハイブリッドディスクモニタリソースの注意事項

4.18.2. 監視 (固有) タブ

4.19. ハイブリッドディスク TUR モニタリソースを理解する

4.19.1. ハイブリッドディスク TUR モニタリソースに関する注意事項

4.19.2. 監視 (固有) タブ

4.20. カスタムモニタリソースを理解する

4.20.1. カスタムモニタリソースの監視方法

4.20.2. カスタムモニタリソースに関する注意事項

4.20.3. 監視 (固有) タブ

4.21. 外部連携モニタリソースを理解する

4.21.1. 外部連携モニタリソースの監視方法

4.1.2. モニタリソースの擬似障害発生/解除