| Oracle Composite Application Monitor and Modelerユーザーズ・ガイド リリース10.2.0.5 B56252-01 |
|
 戻る |
CAMMは、自動的にパフォーマンス・メトリックを選択して、様々なアプリケーションのコンテキスト関係を追跡します。ユーザーが効果的なアプリケーション・パフォーマンス監視環境を設定して管理できるように、CAMM Methodologyが他の重要なアクティビティを専門的に処理します。
これらのアクティビティを次に示します。
Oracle CAMM Methodologyでは、CAMMユーザーが、CAMM独特の機能を活用して先見的なアプリケーション・パフォーマンス監視環境を設定および管理する一連の手順を示します。図9-1で、これらのステップを順番に説明しています。
Methodologyのステップ:
ビジネスSLAをパフォーマンスSLOにマップします。
同意されたビジネスSLAを使用して、パフォーマンスSLOの価値を決定するプロセス。
目標パフォーマンス特徴を指定します。
ステップ1で指定したパフォーマンスSLOを使用して、アプリケーションの理想的なパフォーマンス特徴を指定します。
ベースライン・パフォーマンスの特徴付けを行います。
パフォーマンス・ボトルネックを特定します。
パフォーマンス・ボトルネックを削除します。
ステップ3、4、5を合せると、パフォーマンスが段階的に改善するプロセスになります。アプリケーション・パフォーマンスがステップ2で指定したパフォーマンス目標に到達するように、場合によってはこのプロセスを繰り返す必要があります。
重要なメトリックにSLOを設定します。
アプリケーション・パフォーマンスが目標に到達したら、先見的な監視環境を確立するため、重要なメトリックにパフォーマンスSLOを設定する必要があります。このような環境では、重要なパフォーマンス・メトリックで異常がレポートされ始めると、警告が発行されます。これらの警告により、潜在的な問題がビジネスに影響を及ぼさないうちに事前に解決することができます。
この章では、Oracle Methodologyアクティビティがなぜ重要なのかを示し、次のアクティビティについて詳しく説明します。
これらの詳細説明の項には、目標パフォーマンス特徴の指定（ステップ2）やパフォーマンス・ボトルネックの削除（ステップ5）は含まれません。通常、これらのアクティビティではCAMMを使用しないためです。ただし、これらのアクティビティがOracle Methodologyの重要な部分であることに変わりありません。
CAMM Methodologyのアクティビティは次のとおりです。
先見的なアプリケーション・パフォーマンス監視環境の設定を成功させるための最初のステップは、監視できるように、一連のビジネス目標を一連のパフォーマンスしきい値にマップすることです。このようなビジネス目標は、多くの場合ビジネス・サービス・レベル合意（SLA）と呼ばれます。このようなビジネスSLAは、高レベルでの基本的なアプリケーション・パフォーマンス要件を示します。このため、これらの高レベルSLAを低レベルのパフォーマンスしきい値に適切にマップするのは、大変難しいアクティビティです。
テクノロジ・レベル（EJB、JSP、サーブレット、ポートレット、SQLコールなど）でパフォーマンスの測定のみを行うツールを使用しても、このようなタイプのアクティビティを行うのは非常に困難です。低レベルのメトリックと高レベルの目標の相関関係はあいまいな場合が多いためです。この結果、マッピング・アクティビティは科学ではなく芸術であるとみなされることもあります。
CAMMは、テクノロジ・レベルと機能レベルの両方でパフォーマンスを測定することで、このマッピング・アクティビティの複雑さを大幅に低減しています。機能メトリックによって高レベル構成メンバー（ビジネス・プロセスまたはポータル・デスクトップなど）のパフォーマンスが測定されるため、ビジネスSLAのパフォーマンスSLO（サービス・レベル目標）への直接マッピングを単純に行えます。
監視対象アプリケーションの目標パフォーマンス特徴の定義が、ビジネスSLAをパフォーマンスSLOにマッピングした次のステップです。このようなSLOはアプリケーションの絶対的な最小パフォーマンス要件を表すため、これらの違反しきい値を目標パフォーマンス特徴として使用することにはほとんど意味がありません。かわりに、通常の操作でのパフォーマンスの許容範囲や、異常なアクティビティに関して注意を促すアラートをいつ送るかを定義する必要があります。
アプリケーションによっては、一連の注意のパフォーマンスしきい値を指定するだけで十分です。CAMMのようなアプリケーション・パフォーマンス・モニタリング・ツールは、これらのしきい値に違反があると、注意のためのアラートを送信します。これらのしきい値は注意を促すものであるため、いくつかの違反が発生してからアラートを送信しても間に合うことがあります。違反の最短期間を定義することで、重複したアラートの生成数を最小限に抑えることができます。図9-2にこの概念を示します。
図9-2では、違反の最短期間が15秒に定義されています。注意の状態が続くのが15秒以内であれば、注意のアラートは起動されません。
アプリケーションによっては、高と低のパフォーマンスしきい値を両方定義する必要があります。両方のしきい値を設定することで、これらのアプリケーションの通常操作の範囲を効果的に定義できます。CAMMでは、すべてのSLOで高と低のトリガーを両方設定できます。
一連の目標パフォーマンス特徴を明確に設定しておくと、理想のパフォーマンス範囲を実現するためにどの程度のパフォーマンス・チューニングが必要かを判断することができます。また、一連の注意のためのパフォーマンスしきい値も設定でき、先見的なパフォーマンス監視環境を確立することができます。
この項で説明するアクティビティを合せると、1つのパフォーマンス改善プロセスになります。このプロセスは、アプリケーションのベースライン・パフォーマンスの特徴付けから、パフォーマンス・ボトルネックの特定へと進み、パフォーマンス・ボトルネックの削除で終わります。アプリケーションのパフォーマンスが目標の特徴に到達するまで、これらのアクティビティを繰り返して行います。
目標パフォーマンス特徴の指定が終了したら、次のアクティビティは、アプリケーションのパフォーマンス・ベースラインを取得することです。パフォーマンス・ベースラインを、目標パフォーマンス特徴と比べることで、さらにパフォーマンス改善が必要かどうかを判別します。必要であれば、パフォーマンスが目標の特徴に到達するまで、この後の2つのステップを繰り返してアプリケーション・パフォーマンスを改善します。
パフォーマンス・ボトルネックを特定するには、まずパフォーマンス・ベースラインからパフォーマンスの異常を分離する必要があります。パフォーマンスの異常を分離したら、その現象が局所的に発生しているのか体系的な問題なのかを判別する必要があります。監視や診断のツールを使用して、パフォーマンス・ボトルネックの原因を特定するために必要な分析を実行することができます。
このようにパフォーマンス・ボトルネックが特定されたら、削除方法を決定する必要があります。ボトルネックを削除する戦略は原因に応じて多様です。一部の例を次に示します。
ボトルネックの原因がアプリケーションの不具合である場合、戦略にはアプリケーション開発チームの協力が必要です。
ボトルネックの原因が構成の問題にある場合、システム管理者の助力が必要になります。
ボトルネックがアプリケーション・サーバーまたはフレームワークに存在する場合、それらのベンダーに支援を求めることになります。
次のようなボトルネック削除アクティビティが考えられます。
アプリケーション・コードを変更して不具合を修正します。
環境設定を変更して構成の問題を修正します。
パッチをインストールしてソフトウェアの不具合を修正します。
故障したハードウェアを交換します。
ネットワーク・インフラストラクチャをアップグレードします。
コンピューティング・リソースを追加します。
リソースを大量消費するプログラムを削除します。
バックエンド接続とレスポンス時間をチューニングします。
このリストからわかるように、パフォーマンス・ボトルネックを削除するアクティビティは原因ごとに大きく異なります。パフォーマンス・ボトルネックの解決を支援する適切なグループを正しく迅速に見つけることが、このアクティビティを成功させる鍵になります。パフォーマンス・ボトルネックの削除が完了したら、ベースライン・パフォーマンスの特徴付けのアクティビティを再び実行して、行った修正によって実際にパフォーマンスの改善があったことを確認します。
アプリケーション固有のパフォーマンスしきい値を設定する他に、重要なシステム・メトリックや選択したコンポーネント・メトリックにパフォーマンスしきい値を設定することも重要です。このようなしきい値を設定すると、早期警告システムを確立することにつながり、小さな問題が本番環境の大きな問題に発展する前に注意を促すようになります。
重要なシステム・メトリックにSLOを設定するには、負荷がかかったときにシステムがどのように動作するかを基本的に理解していることが必要です。JDBCの空き接続またはExecuteQueueのアイドル・スレッドがなくなって、システムが不安定になった場合、または実行に問題が発生した場合は、このようなシステム・メトリックを監視する必要があります。
どのシステム・メトリックを監視するかを決めるには、システム全体のパフォーマンスと特定のシステム・メトリックの相関関係を判断することが不可欠です。その情報を使用して監視するシステム・メトリックを決定します。適切なシステム・メトリックを識別したら、次は、通常の操作でのパフォーマンス範囲を確認して、注意のしきい値と違反のしきい値を決定します。
監視すべきシステム・メトリックやシステム・メトリックのパフォーマンスしきい値の決定はまだ単純なのに対し、重要なコンポーネント・メトリックでのSLOの設定はかなり困難になります。理論的には、コンポーネント・レベルでのパフォーマンス低下はアプリケーション・レベルのパフォーマンスに悪い影響を与えると仮定できます。ただし、この仮定は現実を正しく反映していない可能性があります。
コンポーネント・レベルのパフォーマンス・メトリックを監視してアプリケーション・パフォーマンスを予測するには、特定のコンポーネントのパフォーマンスとアプリケーションのパフォーマンスの間に非常に密接な相関関係が必要です。あるコンポーネントでパフォーマンスが低下しても、別のコンポーネントのパフォーマンスの上昇によって埋め合されることがあります。コンポーネント・レベルのこのような反対方向のパフォーマンスの変化は、本質的にアプリケーション・レベルでの変化にはほとんど影響しません。したがって、強い相関関係がないかぎり、少数のコンポーネントのパフォーマンスを監視して結論を出すことには注意が必要です。
最後に実行するタスクは、様々なしきい値の違反について様々なアクションとレスポンスを関連付けることです。このような関連付けが終了したら、先見的なアプリケーション・パフォーマンス監視環境の使用を開始できます。
企業が先見的なアプリケーション・パフォーマンス監視を確立するためにソリューションを購入する大きな理由の1つは、ビジネスSLAを達成するという要求です。エンタープライズ・アプリケーションにとってのビジネスSLAは、社内または社外顧客によって定められる一連のサービス・レベルの期待値です。ほとんどのケースで、これらのビジネスSLAはこのように高レベルで定義されているため、アプリケーション・パフォーマンス・モニタリング・ツールでのしきい値の設定には役立ちません。
この結果、ビジネスSLAをパフォーマンスSLOにマップするプロセスは、顧客によって設定されたサービス要件を企業が満たすためにきわめて重要になります。CAMMでは機能レベルとテクノロジ・レベルの両方でパフォーマンスが監視されるため、このマッピング作業を容易に実行することができます。
この項では、例によって、一連のビジネスSLAに対する適切なパフォーマンスしきい値を判別するためにCAMMを使用する方法を説明します。
この例では、次のような高レベルのビジネスSLAが与えらています。
表9-1 例: ビジネスSLAのガイドライン
| ビジネスSLA | SLA要件 |
|---|---|
|
高速の顧客セルフサービス・ポータル。 |
顧客セルフサービス・ポータルのページは、平均で2秒以内にロードされる必要があります。このSLAは99%の確率で実現する必要があります。 |
|
顧客サービス代理ポータルが、メインフレーム・システムと同じくらい高速であることが必要です。 |
顧客サービス代理ポータルのすべてのページは、6秒以内にロードされる必要があります。このSLAは99.9%の確率で実現する必要があります。 |
|
サービス・コールのスケジュールの短縮。 |
サービス・コールのスケジュール設定を平均30秒未満で行う必要があります。このSLAは99.99%の確率で実現する必要があります。 |
最初のビジネスSLAをパフォーマンスSLOにマップします。このSLA要件は、顧客セルフサービス・ポータル（デスクトップ）の平均レスポンス時間が2秒未満であるべきと示しています。CAMMで、このデスクトップに高レベル・パフォーマンスSLOを設定します。CAMM UIの階層を使用して、「顧客」デスクトップを選択し、右クリックしてSLOを設定します。
CAMMでは機能レベルとテクノロジ・レベルの両方でパフォーマンスが監視されるため、ビジネスSLAを機能メトリックのSLOに直接変換することができます。この例では、メトリックはポータル・デスクトップ「顧客」のレスポンス時間です。ここでは、違反のSLOと警告のSLOを設定します。
違反が発生する頻度を計算して、現在のシステムがSLA要件の確率99%を満たすかどうかを判断できます。CAMMでは、明らかな違反があるかどうかを確認できます。違反またはそれに近い状態がある場合は、実際のデータを調べて確認する必要があります。少なくとも24時間分のデータがある場合は、CAMMのエクスポート機能を使用してこの計算のために生データを用意します。
他の2つのビジネスSLAについても、適切なメトリックにパフォーマンスSLOを設定します。
ベースライン・パフォーマンスの特徴付けは、パフォーマンスのベースライン設定とも呼ばれますが、特定レベルのロードでのシステムのベースライン・パフォーマンスを取得する一連のアクティビティが含まれます。たとえば、WebLogicクラスタにデプロイされているポータル・アプリケーションのベースライン・パフォーマンスを測定することができます。
たとえば、ロード・テストの最初の4時間のパフォーマンス・データをCAMMに表示することができます。当初90分間はアクティブ・セッションの数が一定のペースで増加します。やがて、新たなセッションと期限切れになるセッションの数が均衡して、アクティブ・セッションの数は約700で止まります。
次にポータルのパフォーマンスについて詳しく説明します。これは、最初はパフォーマンスが遅いが次第に安定した状態に到達するという典型的なパターンをたどります。アプリケーション・サーバーがコンポーネントをメモリーにロードし、キャッシュ・メカニズムにデータを移入するため、当初の遅いパフォーマンスは想定されたものです。パフォーマンスは次第に改善し、およそ30分後には安定した状態になります。この初期30分間のパフォーマンス・パターンの特徴は、ロードが増加する起動時のパフォーマンスです。30分以降にはポータル・アプリケーションのパフォーマンスは安定します。
アプリケーション・パフォーマンス監視環境を迅速に確立するCAMMの機能により、ベースライン・パフォーマンスの特徴付けを苦労せずに行うことができます。CAMMではクラスタ・レベルと個別サーバー・レベルの両方で監視できるため、クラスタ全体または個別サーバーのパフォーマンスの特徴付けを行えます。
ロードの少ないサーバーはリソース使用率が低く、パフォーマンスが速いことを確認することにより、この環境で実行するポータル・アプリケーションのパフォーマンス特徴に関して次のような観察結果を導くことができます。
サーバーAのリソース使用率が最大値に近づいているため、そのサーバーのロードを個別サーバーの上限値として使用できます。個別サーバーのロードの上限値を計算するには、CAMMで提供されるロード・メトリックを使用します。
ロード・バランシング・アルゴリズムおよびロード・バランサの構成を調べる必要があります。
クラスタ内の2つのサーバーのロードとリソース使用率を比較すると、リソース使用率がロードに反比例することを確認できます。
|
注意: これは、個別のサーバーの非常に基本的なパフォーマンス特徴です。複数サーバー・クラスタのパフォーマンスは、クラスタ構成に付随するオーバーヘッドがあるため、個々のサーバーのパフォーマンス特徴を加算して求めることはできません。クラスタ・レベルのパフォーマンスは、CAMMのよなアプリケーション・パフォーマンス・モニタリング・ツールで測定する必要があります。 |
CAMMを使用すると、QA、ステージングおよび本番設定におけるパフォーマンス・ボトルネックもすぐに特定することができます。CAMMの階層モデルを使用すると、アプリケーションのパフォーマンス・ボトルネックを特定できます。さらに、CAMMを使用して、リソース不足によって引き起こされたアプリケーションのパフォーマンス問題を追跡できます。
この例では、WebLogicで実行するポータル・アプリケーションのパフォーマンス・ボトルネックを特定します。CAMMではパフォーマンス・メトリックが階層に編成されているため、ポータル階層のルートから調査を開始します。
この例では、sampleportalアプリケーションがSLOにわずかに足りません。パフォーマンス・ボトルネックの可能性があるコンポーネントを特定するために、ポータルの階層ツリーを展開して、下位のパフォーマンス・メトリックを調べます。
アクティブなポータル・デスクトップは1つしかないため、Acsera_Desktop_2ツリーから「ページ」ノードに調査を続けます。ここで最もパフォーマンスが悪いページを特定する必要があります。パフォーマンスが最低のページが明らかな場合、そのページの下の階層をトラバースして調査を続けます。パフォーマンスが悪いページが複数ある場合は、パフォーマンスが遅いコンポーネントを特定できるまで、複数のパスをたどって調査を続ける必要があります。
このケースでは、マイ・ページが最も遅いページです。したがって、マイ・ページの階層をドリルダウンすることで調査を開始します。
マイ・ページの階層をさらにドリルダウンすると、マイ・ページを構成するすべてのポートレットのパフォーマンスを比較できます。CAMMによって、ThreadedDiscussionポートレットのパフォーマンスが最も悪いことがはっきりと示されます。
この例では、CAMMで提供される階層ツリーを使用して、ポータル・アプリケーションのパフォーマンス・ボトルネックを迅速に特定できます。パフォーマンス・メトリックを論理階層に編成するCAMM独特の機能により、パフォーマンス・ボトルネックの特定を迅速かつ正確に行うことができます。
CAMMでは、パフォーマンス・メトリックを論理的な階層に編成するだけでなく、パフォーマンス情報をタイプ別に編成しています。次の例では、CAMMの様々な階層にある複数のパフォーマンス・メトリックを使用して、パフォーマンス・ボトルネックの発生源を判別します。
この例では、CAMMによって、csrデスクトップの平均レスポンス時間が、事前に定義した注意と違反両方のSLOを超えたことが警告されます。CAMMを使用してこれらのSLO違反を調査すると、90分間にわたるパフォーマンスの大幅な低下が明らかになりました。このような継続的なSLO違反は、このパフォーマンス低下の発生源を探してさらに調査する根拠になります。
デスクトップ・ヒット・グラフを見ると、問題の期間にcsrデスクトップに対する急激なロードの増加はありません。この情報により、パフォーマンス低下の潜在的な理由を1つ消すことができます。
次に、ポータルの階層をドリルダウンして、動作がおかしいコンポーネントがないかを調べます。
問題の期間には、どのポートレットも異常な動作を行っていません。実際は、デスクトップのパフォーマンスが低下し始めたとき、すべてのポートレットのパフォーマンスも低下しています。この情報に基づいて、デスクトップの特定のポートレットはこのパフォーマンス低下の発生源ではないと結論できます。
パフォーマンスの問題がすべてのコンポーネントに同様に影響しているように見えるため、システム・レベルでなんらかのパフォーマンス低下があるのではないかと考えてみます。システム・レベルのパフォーマンス・データを確認するには、「リソース」階層の下を調べます。「リソース」階層の下のパフォーマンス・メトリックから、相関関係分析を実行するための生データを得ることができます。このようなタイプの分析は、リソース不足がパフォーマンス低下の原因かどうかを判別するために必要です。
このタイプの分析を実行するため、CAMMで様々なパフォーマンスの表やグラフを組み合せて、カスタム・ビューを作成します。カスタム・ビューを使用すると、マシン・リソース、JVMリソースおよびアプリケーション・サーバー管理リソース（JDBC接続プール）の間の相関関係を分析できます。
グラフから興味深いパターンが明らかになることもあります。
OSエージェントの異常
問題の期間に、CPU使用率の急激な低下とディスク使用率の急激な上昇があることに気づきます。このパターンは、このマシンでの大容量の仮想メモリー・ページング・アクティビティを示しています。ディスクへのメモリー・ページングは、非常にコストがかかる処理であり、CPU使用率の低下からもわかるようにリクエストの処理を遅らせます。ページングが発生する理由を理解するために、JVMに関するパフォーマンス・メトリックを調べます。
JVMヒープ・サイズ
この例では、最初の12時間に、JVM合計ヒープ・サイズとJVM空きヒープ・サイズの両方が少しずつ増えていることがわかります。JVM合計ヒープ・サイズの増加は512MBで止まっています。WebLogiの最大ヒープ・サイズを512MBに構成しているため、これは予測される動作です。合計ヒープ・サイズが512MBになった後はJVM空きヒープ・サイズの増加が止まると予測されますが、実際にはJVM空きヒープ・サイズは減り始めます。この情報を前に取得した情報（ロードの急な増加がないことなど）と組み合せると、メモリー・リークの可能性が高いという結論を得られます。
このようなメモリーの異常な消費により、JVM合計ヒープ・サイズが事前定義された最大値に到達しました。このメモリー・リークが、仮想メモリー・ページング・アクティビティの増加を招き、それに応じてCPU使用率が減少したと考えられます。このようなCPU使用率の減少は、JDBC接続を含めてこのマシンで実行するすべてのコンポーネントのレスポンス時間に影響します。
メモリー・リーク
WebLogicのメモリー・リークを特定することができました。JVMによってリソース不足が次第に引き起こされ、最終的にはアプリケーション・パフォーマンスに影響していました。この問題をさらに診断するには、JVMのメモリー使用方法を理解するために詳細レベルのメモリー・プロファイル・ツールが必要です。
Oracle Methodologyのこのステップを実行すると、重要なシステム・メトリックを先見的に監視することができ、サーバーのハング（応答なし）、サーバーのクラッシュ、クラスタのハングなど破滅的な障害を回避できます。このような破滅的な障害につながる兆候を認識する機能は、WebLogicインフラストラクチャのサービス品質を維持するために欠かせません。
WebLogicの重要なシステム・メトリックのしきい値とアクションを前もって設定できます。表9-2に、WebLogicプラットフォームの重要なシステム・メトリックを示します。
表9-2 WebLogicの重要なシステム・メトリック
| 重要なシステム・メトリック | 監視する理由 |
|---|---|
|
ExecuteQueueアイドル・スレッド数 |
ExecuteQueueスレッドの不足は、多くの場合アプリケーション・サーバー・ハング（応答なし）の前に発生します。深刻なケースでは、アプリケーション・サーバーでExecuteQueueスレッドがなくなると、すべての操作が停止することもあります。 |
|
ExecuteQueue保留リクエスト数 |
ExecuteQueueの保留リクエスト数の一定ペースでの増加も、サーバー・ハングの前に発生します。このメトリックは、ExecuteQueueアイドル・スレッド数メトリックとは反比例の関係にあります。 |
|
JVM合計ヒープ・サイズ |
このメトリックを監視する理由は次の2つです。
|
|
JVM空きヒープ・サイズ |
JVM空きヒープ・サイズが少しずつ減少する場合、メモリー・リークまたはアプリケーション・サーバーの構成に問題があることがあります。ヒープ不足のJVMは、不安定になってパフォーマンスが低下します。これは、ガベージ・コレクタとJVMが、それぞれクリーンアップとオブジェクト作成を実行するために、リソースを競合していることによります。 |
|
オープン・セッション数 |
オープン・セッション数が0まで減少し、一定期間0のままである場合、調査が必要です。多くの場合、このパターンは、ネットワークまたはロード・バランシングの問題を示します。 |
|
アプリケーション呼出し数 |
アプリケーション呼出し数が0まで減少し、一定期間0のままである場合、調査が必要です。このパターンは、多くの場合ネットワークまたはロード・バランシングの問題を示しますが、サーバー・ハングの症状でもあります。 |
このようなWebLogicの重要なシステム・メトリックを理解した上で、SLOしきい値を設定し、適切なレスポンスを割り当てることが、先見的な監視の確立に不可欠です。この例では、CAMMでSLOとアクションを構成します。
最初のタスクは、注意と違反のSLOをExecuteQueueアイドル・スレッド数メトリックに設定することです。これにより、使用可能なExecuteQueueが減ってきたときに適切な人物にアラートを送ることができます。SLOを構成するには、実行キューのメトリックを右クリックして、「サービス・レベル目標値の構成」を選択します。この例では、ExecuteQueueのアイドル・スレッドについて次のSLOを作成します。
表9-3 ExecuteQueueのアイドル・スレッドのSLO
| SLO名 | メトリック | しきい値のタイプ | しきい値 | トリガー値 |
|---|---|---|---|---|
|
ExecuteQueueアイドル・スレッド（低） |
Metric.J2EE.Dispatcher.IdleThreads |
注意 |
3 |
低 |
|
ExecuteQueueアイドル・スレッドの消失 |
Metric.J2EE.Dispatcher.IdleThreads |
違反 |
0 |
低 |
SLOトリガーを「低」に設定すると、現在の測定がしきい値に到達し、前回の測定がしきい値よりも高い場合にアラートが起動されます。
たとえば、事前に定義したSLOに対して次のアクションを作成します。
表9-4 SLOのアクション
| SLO名 | アクション名 | アクション・タイプ |
|---|---|---|
|
ExecuteQueueアイドル・スレッド（低） |
ExecuteQueueアイドル・スレッド（低）イベントをサーバー・ログに入力します。 |
ログ |
|
ExecuteQueueアイドル・スレッドの消失 |
ExecuteQueueアイドル・スレッドの消失アラートを電子メール送信します。 |
電子メール |
|
ExecuteQueueアイドル・スレッドの消失SNMPトラップをHP Overviewに送信します。 |
SNMP |
|
|
ExecuteQueueアイドル・スレッドの消失イベントをサーバー・ログに入力します。 |
ログ |
このようにSLOとアクションを構成したところで、破滅的なイベントが発生する前にExecuteQueueのリソース不足を検出できる先見的な監視環境が整いました。このアプローチを使用して、WebLogicの他の重要なシステム・メトリックについても先見的な監視を確立します。
Oracleの推奨設定を次に示します。
表9-5 ExecuteQueue保留リクエスト
| SLO名 | メトリック | しきい値のタイプ | しきい値 | トリガー値 |
|---|---|---|---|---|
|
ExecuteQueue保留リクエスト数の警告 |
Metric.J2EE.Dispatcher.PendingRequests |
注意 |
5〜10脚注1 |
高 |
|
ExecuteQueue保留リクエスト数の違反 |
Metric.J2EE.Dispatcher.PendingRequests |
違反 |
10〜20 |
高 |
脚注1 これらのSLOのしきい値は環境によって異なります。使用するしきい値を決めるのは繰返しプロセスです。ユーザーは、最初のステップとして、自らのWebLogic環境のパフォーマンス特徴の情報を集める必要があります。その情報に基づいてユーザーはSLOを設定できます。ユーザーがWebLogic環境のパフォーマンスの改善を続けるときは、これらのしきい値を再評価し、必要に応じて変更する必要があります。
SLOトリガーを「高」に設定すると、現在の値がしきい値と等しくなったときにCAMMによってアラートがトリガーされます。
表9-6 JVM合計ヒープ・サイズ
| SLO名 | メトリック | しきい値のタイプ | しきい値 | トリガー値 |
|---|---|---|---|---|
|
JVMヒープが最大値に増加 |
Metric.J2EE.JVM.HeapSizeCurrent |
注意 |
512MB脚注1 |
高 |
|
JVMヒープが0に減少 |
Metric.J2EE.JVM.HeapSizeCurrent |
違反 |
0MB |
低 |
脚注1 このSLOのしきい値は環境によって異なります。ユーザーは、WebLogic構成ファイルに指定されている最大ヒープ・サイズにこの値を設定できます。
表9-7 JVM空きヒープ・サイズ
| SLO名 | メトリック | しきい値のタイプ | しきい値 | トリガー値 |
|---|---|---|---|---|
|
JVM空きヒープ（低）の警告 |
Metric.J2EE.JVM.HeapFreeCurrent |
注意 |
72MB |
低 |
|
JVM空きヒープ（低）の違反 |
Metric.J2EE.JVM.HeapFreeCurrent |
違反 |
24MB |
低 |
表9-8 オープン・セッション数
| SLO名 | メトリック | しきい値のタイプ | しきい値 | トリガー値 |
|---|---|---|---|---|
|
5分間システムにユーザー・セッションなし |
Metric.J2EE.WebApplication.OpenSessionCurrentCount |
注意 |
0脚注1 |
低 |
脚注1 この例では、このSLOの測定ウィンドウは5分間です。測定ウィンドウを5分間にすると、条件が5分以上持続したときのみアラートが起動されます。
表9-9 アプリケーション呼出し数
| SLO名 | メトリック | しきい値のタイプ | しきい値 | トリガー値 |
|---|---|---|---|---|
|
5分間システムにアプリケーション呼出しなし |
Metric.J2EE.Servlet.InvocationTotalCount |
注意 |
0 |
低 |
これらのSLOと対応するアクションを設定すると、WebLogicデプロイメントの先見的な監視環境が確立されます。この先見的な監視アプローチにより、システムのパフォーマンスと可用性に影響する前に、破滅的な問題につながる現象を特定できます。
