ヘルス・ポリシーは、具体的なヘルス基準の定義です。Intelligent Management は、これらの基準に従って環境を
保護します。ヘルス管理機能は、定義済みのポリシーを使用して、環境におけるソフトウェアの
誤動作を識別します。
始める前に
- ヘルス・ポリシーを作成するには、コンフィギュレーターまたは管理者の管理特権
が必要です。ヘルス・コントローラーは有効になっていなければなりません。
- ヘルス条件に違反したときにターゲット・サーバーでカスタム・アクション が
実行されるようにする場合、ヘルス・ポリシーを作成する前にそのカスタム・アクションを
定義する必要があります。詳しくは、ヘルス・ポリシーのカスタム・アクションの作成についての説明を
お読みください。
このタスクについて
ヘルス・ポリシーは、ヘルス・コントローラーと連動して、環境内の各サーバーのオペレーションをモニターします。
ヘルス・コントローラーによって、ご使用のサーバーが定義済みのヘルス・ポリシーを満たしていないことが検出された場合は、
その問題を修正するアクションを実行できます。
管理者に問題を
通知することも、
Intelligent Management で問題を自動的に修正することもできます。
手順
- 管理コンソールで、とクリックします。
- ヘルス・ポリシーのヘルス条件プロパティーを定義します。
要確認: 超過要求タイムアウトおよびストーム・ドレーンの条件は、
Java™ Message Service (JMS) および Inter-ORB Protocol (IIOP) トラフィックには適用されません。
ヘルス・ポリシー条件には、以下のプロパティーが含まれています。
- 選択したヘルス条件に関連する設定プロパティー。カスタム・ヘルス条件の作成を選択した場合は、カスタム条件で評価するメトリックを表す副次式を指定します。設定できる条件について詳しくは、「構文ヘルプ」をクリックしてください。
ベスト・プラクティスとしては、カスタム条件を定義する際に、データの収集、データの分析、および必要に応じたヘルス・ポリシーの実施にかかるコストを考慮してください。データを生成するサーバーの
数を増やす場合は特に、ネットワークのトラフィック量について考慮してください。新規ヘルス・ポリシーを
実稼働環境に導入する前に、カスタム・ヘルス条件のこれらの観点を分析
してください。
PMI モジュールを活用するカスタム・ヘルス条件は、特に webAppModules など、サーバーの細分度よりも細分度を高めて、さらに構成できます。
例えば、副次式ビルダーを使用し、開始点として webAppModule ポリシーを作成し、次にその式を編集して以下のように細分度を高めて定義できます。
PMIMetric_FromServerStart$webAppModule$SlamSess\#SlamSess.war\/webAppModule.servlets\/SlamSess\/responseTime > 100L
この例では、管理コンソールにアプリケーションをリストした場合、アプリケーション名は SlamSess と表示されます。
EAR ファイルを使用している場合は、EAR ファイル名の後に Web アーカイブ (WAR) ファイル名を指定します。WAR が EAR ファイルに埋め込まれていない場合は、
WAR ファイル名のみを指定します。SlamSess の値は、
web.xml ファイルにリストされているサーブレット名です。
responseTime の値は、Performance Monitoring Infrastructure (PMI) モジュール定義にリストされている統計値です。
- リアクション・モードを選択します。
「監視」モードの場合、
管理者はアクションが実行される前にアクションを承認または拒否できます。
- ヘルス・ポリシー条件が満たされない場合に実行されるアクションを選択します。
使用可能なアクションは、ヘルス条件のタイプによって決まります。
これらのアクションでは、既存のデフォルト・アクションにするか、または実行可能ファイルを実行するカスタム・アクションを定義できます。
アクションのリストは、ヘルス条件に違反したときに実行される順序で表示されます。
このリストからステップを追加または除去できます。
- ヘルス・ポリシーのカスタム・アクションを選択すると、カスタム・アクションのターゲットを指定しなければなりません。「不具合のあるサーバーをホストするノード (Node hosting the sick server)」をターゲット・ノードとして選択している場合、ターゲット・サーバー・オプションは「不具合のあるサーバーのノード・エージェント (Node agent of the sick server)」および「不具合のあるサーバー (sick server)」です。
- モニターするメンバーを選択します。 論理のレイヤーはモニターされたメンバーに適用できます。例えば、
クラスターの各メンバーや、クラスターの外側のアプリケーション・サーバーに、
特定のヘルス・ポリシーを適用できます。
- ヘルス・ポリシーを確認して、保存します。
タスクの結果
ヘルス・ポリシーを作成し、ターゲット環境に適用しました。
ヘルス・コントローラーは、ヘルス・ポリシー・メンバーに対して定義した
条件をモニターして、ヘルス・ポリシーの条件に違反したときに、メンバーで
定義済みのアクションを行います。
次のタスク
「監視」リアクション・モードを選択した場合は、
ヘルス状態を改善するための推奨を受け取ります。これらの推奨は、
受け入れるか、拒否するか、またはクローズすることができるランタイム・タスクとして
表示されます。ランタイム・タスクを管理するには、管理コンソールでとクリックします。「自動」リアクション・モードを選択した場合は、環境の正常性を改善するためのアクションが自動的に実行されます。
監視リアクション・モードのランタイム・タスクの場合、Java 仮想マシン (JVM) の com.ibm.ws.xd.hmm.controller.ControlConfig.approvalTimeOutMinutes カスタム・プロパティーを
設定できます。このプロパティーでは、ヘルス・コントローラーのランタイム・タスクの有効期限が切れるまでの
分数を指定します。この値を 5 分以下に設定すると、
その代わりにデフォルト値の 30 分が自動的に使用されます。ランタイム・タスクにおいてアクションをとらないと、
このプロパティーで指定された分数でそのタスクの有効期限が切れます。正常性の問題がまだ存在しているときにランタイム・タスクの有効期限が切れた場合、
新しいランタイム・タスクが生成されます。
ヘルス・ポリシーを頻繁に構成する場合は、AdminTask コマンドを使用してプロセスを自動化することを検討してください。