CA APM クライアント要件
CA APM には、クライアントの要件があります。
apmdevops97jp
CA APM には、クライアントの要件があります。
CA APM クライアント
CA APM では以下のクライアント コンポーネントが提供されます。
- Workstation
- WebView
- コマンドライン Workstation
- CEM コンソール
CEM コンソール
CEM コンソールは、Enterprise Manager サービスを実行するスタンドアロンの Enterprise Manager または MOM が提供する、Web ブラウザ ベースのクライアントです。 CEM コンソールは、特別なキャパシティ プランニングまたはサイジングを必要としません。
Enterprise Manager での Workstation リソース消費
Enterprise Manager への Workstation 接続はリソースを大量に消費しません。また、Enterprise Manager が処理できる Workstation の数に、ソフトウェアに基づいた実質的な制限はありません。 Workstation セッション リソースの消費は完全に、Workstation ユーザが実行しているタスクによって決まります。 たとえば、多くのユーザは、リソースをほとんど消費せずに、同時実行されているライブ メトリックを表示することができます。 ただし、多くのユーザが大きなトランザクションに対してトランザクション追跡を頻繁にトリガしたりスレッド ダンプを要求したりすると、Enterprise Manager で大量のメモリを消費します。
Workstation の並列接続の数に関するクランプは、apm-events-thresholds-config.xml ファイルで定義されます。 このクランプは introscope.workstation.max.users プロパティです。 デフォルト値は 40 です。これは控えめな値です。 Enterprise Manager のリソース可用性、および予想される Workstation ユーザの行動に基づいて、この値を増やすことができます。
Workstation クライアントを介するユーザ アクティビティは、以下の Enterprise Manager リソースを消費します。重要リソースから順番に列挙します。
- ヒープ メモリ
- ネットワーク帯域幅
- ディスク ストレージと I/O
- CPU
Workstation と MOM パフォーマンス
クラスタ化された環境で、Workstation、CLW、WebView、および CEM コンソールをすべて、コレクタ
ではなく
、MOM に接続する理由は、以下のとおりです。- Workstation をコレクタに直接接続すると、MOM のクエリ負荷と競合し、クラスタの反応状態に悪影響を与える可能性があります。
- クライアント クエリの処理は Collector メトリック キャパシティを減少させます。
- コレクタとの接続を介して表示されるメトリック データはすべて、MOM を介して表示されます。 そのため、データを表示するためにコレクタに接続する理由はありません。
- Introscope ユーザは、使用する Workstation がコレクタに直接接続されていると、アプリケーション問題切り分けマップを表示できません。
スタンドアロン Enterprise Manager に適用される Workstation のスケーラビリティに関する考慮事項は、MOM にも同じように適用されます。 ただし、追加の考慮事項もあります。コレクタ全体でのメトリック クエリの分散も、MOM の反応状態とスケーラビリティに影響します。 クエリで複数のコレクタからのメトリック データが必要な場合、MOM は必要なメトリックを関係するすべてのコレクタから受け取るまで、クエリの結果を返すことができません。 そのため、過負荷のコレクタが 1 つあると、クラスタの反応状態が低下する可能性があります。
重要:
すべての Workstation 接続がアクティブなユーザに関係している場合に、そのすべてのクエリが同じコレクタにデータを要求すると、Workstation のパフォーマンス問題の生じる可能性があります。 この問題が発生すると、コレクタ自体の内部的な同時履歴クエリの制限のため、パフォーマンスが低下することがあります。上位 N のグラフ
上位 N のグラフは、Introscope ダッシュボード上にメトリックのグラフを表示する際に、上位 N (N は選択可能)までのメトリックのみを表示する方法です。 上位 N のグラフの処理は、多くの Enterprise Manager リソースを必要とします。 たとえば、システムで 100,000 個のサーブレットに対する平均応答時間をクエリするメトリック グループをセットアップできます。 ダッシュボードには、最も遅い 5 件のサーブレットのグラフが表示されます。 Enterprise Manager は、最も遅い 5 件を決定するために、100,000 個のサーブレットすべてのデータをサブスクライブして処理する必要があります。
上位 N のグラフの計算機は非常に多くの数のメトリックに対してクエリを実行しますが、クライアントに返すメトリックの数は少数です。 このため、CA APM の大規模なクエリ最適化を実行しても、上位 N のグラフの計算機には役に立ちません。 上位 N のグラフは慎重に使用してください。 上位 N のグラフが要求されるたびに、すべてのデータがリアル タイムで提供されるため、Introscope システムに大量のリソースが要求されます。
上位 N 個のクエリおよび CLW クエリが環境内で進行している問題の原因になっている場合は、クエリ リソースの消費を制限するため、IntroscopeEnterpriseManager.properties ファイルに以下の 2 つのクランプ プロパティを追加できます。
- introscope.enterprisemanager.query.datapointlimit - Enterprise Manager が SmartStor ディスクから読み取るデータ ポイントの数をクランプします。
- introscope.enterprisemanager.query.returneddatapointlimit - Enterprise Manager がネットワークを介して送信するデータ ポイントの数をクランプします。
アプリケーション問題切り分けマップと同時 Workstation ユーザ
Workstation がアプリケーション問題切り分けマップを描画するたびに、必要なデータのクエリを Enterprise Manager に対して実行する必要があります。 ほとんどのインスタンスでは、これらのクエリはわずかで、Enterprise Manager への影響はほとんどありません。 しかし、数百以上のマップ ノードを含む大規模なアプリケーション問題切り分けマップでは、これらの Workstation クエリは Enterprise Manager の CPU に非常に高い負荷をかける可能性があります。 このため、Introscope ユーザは、所定の期間にアプリケーション問題切り分けマップのデータを要求する同時 Workstation を 8 つ以下にすることをお勧めします。 アプリケーション問題切り分けマップ クエリの負荷は主として Enterprise Manager の CPU にかかるため、処理リソースを増やすことで、より多くのユーザがアプリケーション問題切り分けマップを並列して処理できるようになります。
WebView ブラウザのガイドライン
WebView クライアントでは、カスタマイズ可能なコンソール ダッシュボードや、Workstation ツリー ビューが、ブラウザ インターフェースで提供されます。 WebView では、以下のキャパシティに関するガイドラインに従っていない場合に、ブラウザ クライアントのパフォーマンスが低下することがあります。
- WebView クライアント ブラウザは、参考用のクライアント ハードウェアのダッシュボードあたり最大 20 のグラフを表示できます。 ダッシュボードの各グラフは、パフォーマンスが低下することなく、最大 25 のメトリックを処理できます。 合計でダッシュボードあたり 500 のメトリックを表示できます。注:ダッシュボードの表示中にブラウザのパフォーマンスが低下した場合は、大きなダッシュボードを小さなダッシュボードに分割して、それらを相互にリンクすることを検討してください。
- グラフ(またはグラフ内のメトリック)の数が多すぎると、最初のダッシュボード ページの応答時間やその後のライブ データの更新が遅くなることがあります。 この問題を回避するには、グラフの数が多すぎるダッシュボードを作成しないようにします。 メトリック グループの関連付けを限定したり、または上位 N 件のクエリに限定するなどして、グラフあたりのメトリックの負荷を減らしてみてください。
ブラウザのパフォーマンスを向上させるには、以下の点を考慮してください。
- 凡例のないグラフのパフォーマンスは、凡例のあるグラフより高くなります。
- Firefox のパフォーマンスは Internet Explorer 9 より高くなります。
- Internet Explorer 8 は、HTML 5 をベースとするアプリケーションを実行したときのパフォーマンスが最新版のブラウザに比べて低いことが判明しており、推奨できません。 IE 8 を使用する場合は、大きなダッシュボードを小さく分割してダッシュボードの内容を減らすと効果があります。
WebView サーバのキャパシティ
CA Introscope® クライアントでは、アプリケーション環境で収集されたメトリックを表示できます。 メトリックはメトリック クエリを使用して、クライアントに提供されます。メトリック クエリはメモリを消費します。 WebView では、ほかのメトリック クエリと比較して、アプリケーション問題切り分けマップおよび SOA 依存性マップでメモリを多く消費します。 また、複数のユーザが同時にマップを操作している場合、アプリケーション問題切り分けマップは WebView サーバでより多くの CPU リソースを使用します。
アプリケーション問題切り分けマップ メトリック クエリおよび SOA 依存マップ メトリック クエリは、サーバのヒープ メモリを消費します。 WebView サーバへのヒープ割り当てを増加させることにより、サーバのキャパシティを向上させることができます。
注:
参考用のサーバ ハードウェアで、WebView サーバは最大 25,000 のメトリックを処理できます。 このベンチマーク テストは、Intel Xeon X5460 (3.16 GHz、12 GB RAM)を搭載した MBX Rev. D サーバで行いました。 このサーバでは 64 ビット システム上で Red Hat Enterprise Linux 5.7 を実行していました。 サーバのヒープ サイズは 4 GB に設定しました。WebView サーバのガイドライン
WebView では、以下のサーバ ガイドラインを使用してください。
メモリ
WebView クライアントから発行されるクエリの場合、メモリ消費は、コア Enterprise Manager と WebView サーバ間で分配されます。 WebView サーバのインストールには以下のオプションがあります。
- Enterprise Manager のインストール時にインストールする。
- 個別にインストールする。
インストール
Enterprise Manager のインストール時に WebView サーバをインストールする場合、WebView は別個の JVM プロセスとして実行されます。 この WebView インストールでは、CA APM クエリの拡張性を最適化してもメリットはありません。
WebView と Enterprise Manger を同じサーバ上で実行するには、以下の装備が必要です。
- 16 GB の RAM。
- 8 つの CPU コア
重要:
CA APM クライアントの拡張性最適化からメリットを得るには、WebView を個別にインストールしてください。SOA 依存マップ
SOA 依存マップが WebView サーバのパフォーマンスおよびオペレーションに影響を与えないようにするために、以下のプロパティを設定することによって、依存マップ ノードおよびマップの辺のサイズおよび複雑さを制限できます。
- com.wily.introscope.soa.dependencymap.ui.view.nodecountSOA 依存マップに表示されるマップ ノードの最大数を指定します。
- com.wily.introscope.soa.dependencymap.ui.view.edgecountSOA 依存マップに表示されるマップの辺の最大数を指定します。
注
: 詳細については、「SOA 実装ガイド」の SOA 専用の WebView プロパティを参照してください。最適化
クライアントの拡張性を最適化するには、以下のタスクを実行します。
- 少なくとも 4 つの専用 CPU コアを WebView サーバに提供する。
- できるだけ多くのヒープ メモリを WebView サーバに割り当て、さらに以下の項目に従ってください。
- WebView サーバを 64 ビットのオペレーティング システムにインストールし、64 ビットの JVM をインストールする 64 ビット インストーラを使用します。
- 最大ヒープ サイズが、使用可能な RAM から 1 GB を引いた値を超えないようにしてください。
Introscope_WebView.lax ファイル内の
lax.nl.java.option.additional
プロパティを変更することで、WebView サーバのヒープ割り当てを調節できます。WebView サーバには、専用の I/O サブシステムは必要ありません。
コマンドライン Workstation
コマンドライン Workstation(CLW)を使用すると、コマンド ライン、スクリプトベースのメトリック クエリ、およびその他のさまざまな管理コマンドを Enterprise Manager に送信することができます。 CLW は、Enterprise Manager にクライアント処理の大部分を委任するように設計された軽量のプログラムです。 このため、CLW は、CA APM クエリ最適化を実現する分散型のリソース消費には関与しません。
同時実行 CLW クエリは大量のメトリック データを返すため、Enterprise Manager で使用可能なヒープ メモリが不足する状況が発生することがあります。
頻繁で大きな CLW の上位 N 個のクエリおよび CLW クエリが環境内で進行している問題の原因になっている場合は、クエリ リソースの消費を制限するため、IntroscopeEnterpriseManager.properties ファイルに以下の 2 つのクランプ プロパティを追加できます。
- introscope.enterprisemanager.query.datapointlimit - Enterprise Manager が SmartStor ディスクから読み取るデータ ポイントの数をクランプします。
- introscope.enterprisemanager.query.returneddatapointlimit - Enterprise Manager がネットワークを介して送信するデータ ポイントの数をクランプします。
上位 N のグラフおよび CLW クエリのリソースの消費を制限するクランプ
重要:
クランプによって機能が制限されます。 クランプのしきい値に達すると、クエリは正確なデータを返しません。 ほかの方法で監視環境の安定性を維持できない場合にのみクランプを使用してください。 Enterprise Manager のリソースを追加またはアップグレードするか、必要なデータのみが含まれるようにクエリをチューニングするほうが、クランプの設定よりも良いソリューションです。introscope.enterprisemanager.query.datapointlimit プロパティは、Enterprise Manager が SmartStor ディスクから読み取るデータ ポイントの数をクランプします。 このクランプは、大きな履歴クエリでのディスクの競合が SmartStor 継続時間に悪影響を及ぼしていて、Enterprise Manager のキャパシティにも影響している状況で使用できます。
introscope.enterprisemanager.query.returneddatapointlimit プロパティは、Enterprise Manager がネットワークを介して送信するデータ ポイントの数をクランプし、Enterprise Manager がクエリのために処理するデータ量を制限します。 このクランプを使用すると、Enterprise Manager のメモリ エラーを防ぐことができます。
これらのクランプは、CLW ベースのクエリおよび上位 N のグラフを表示するためのクエリに
のみ
適用されます。これらのクランプの最適な値は、以下の要因に基づいて決まります。
- 利用可能なリソース
- ディスク I/O のパフォーマンス
- 使用できるヒープ メモリ
- 予期される CLW および上位 N のクエリの負荷
Introscope のユーザが上位 N または CLW の問題を持っている場合は、サポータビリティ メトリックを使用して調査できます。 問題の原因が上位 N および CLW のクエリであることを確認したら、テスト環境のクランプ値を変更します。
以下の手順に従います。
- 以下のサポータビリティ メトリックを検査して、ディスクの競合またはメモリの問題が発生した時間のクエリの負荷を判別します。*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal:Number of Metric Data Queries per Interval*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal:Query memory in transit (bytes)*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:Queries Exceeding Max Data Points Read From Disk Limit Per Interval*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:Queries Exceeding Max Data Points Returned Limit Per Interval*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:SmartStor Queries Duration (ms)*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:SmartStor Queries Per Interval*SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Tasks:SmartStor Duration (ms)
- 必要に応じて、クランプ プロパティを追加して設定します。注:これらのクランプ プロパティの追加および設定の詳細については、「apm-events-thresholds-config.xml」を参照してください。
- テスト環境を使用して、メトリックの格納およびクエリに対するクランプ値の効果をテストします。
- テスト環境に実運用 SmartStor をコピーします。
- コピーした SmartStor のデータの期間と一致するように、上位 N のグラフのクエリおよび CLW のクエリの期間を変更します。
- 上位 N のグラフおよび CLW のクエリを実行して、使用する環境で必要となる最大のデータ セットを要求し、そのクエリによって関連するクランプがトリガされることを確認します。
- クランプが正しくトリガされるまで、手順 2 と 3c を繰り返します。