CA APM クライアント要件

CA APM では以下のクライアント コンポーネントが提供されます。
apmdevops102jp
CA APM では以下のクライアント コンポーネントが提供されます。
Team Center ブラウザのガイドライン
Team Center は、Google Chrome、Mozilla Firefox、Microsoft Internet Explorer 10 および 11、Microsoft Edge を完全にサポートします。Team Center は、HTML 5 をサポートしないため、Internet Explorer 7 または IE 8 をサポートできません。Internet Explorer 9 では、HTML 5 をサポートします。ただし、Team Center で Internet Explorer 9 に対するテストまたは検証はまだ行っていません。そのため、Internet Explorer 9 での Team Center 機能のパフォーマンスまたは信頼性は確認できません。
CEM コンソール
CEM コンソールは、Enterprise Manager サービスを実行するスタンド アロンの Enterprise Manager または MOM が提供する、ブラウザ ベースのクライアントです。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 リソースを消費します。重要リソースから順番に列挙します。
  1. ヒープ メモリ
  2. ネットワーク帯域幅
  3. ディスク ストレージと I/O
  4. 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 つのクランプ プロパティを追加して、クエリ リソースの消費を制限します。
  • i
    ntroscope.enterprisemanager.query.datapointlimit
Enterprise Manager が SmartStor から読み取るデータ ポイントの数をクランプします。
  • disk.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 サーバのキャパシティ
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.nodecount
    このプロパティは、SOA 依存マップに表示されるマップのノードの最大数を指定します。
  • com.wily.introscope.soa.dependencymap.ui.view.edgecount
    このプロパティは、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
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 から読み取るデータ ポイントの数をクランプします。
  • disk.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 のメモリ エラーを防ぐには、このクランプを使用します。
これらのクランプは、上位 N のグラフを含む、すべてのクエリに適用されます。
これらのクランプの最適な値は、以下の要因に基づいて決まります。
  • 利用可能なリソース
    • ディスク I/O のパフォーマンス
    • 使用できるヒープ メモリ
  • 予期されるクエリ負荷
上位 N または CLW の問題が発生した場合は、サポータビリティ メトリックを調査します。クエリで問題が発生したことを確認したら、テスト環境でクランプの値を変更します。
以下の手順に従います。
  1. 以下のサポータビリティ メトリックを検査して、ディスクの競合またはメモリの問題が発生した時間のクエリの負荷を判別します。
    *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)
  2. 必要に応じて、クランプ プロパティを追加して設定します。
  3. テスト環境を使用して、メトリックの格納およびクエリに関するクランプの値の効果をテストします。
    1. テスト環境に実運用 SmartStor をコピーします。
    2. コピーした SmartStor のデータの期間と一致するように、上位 N のグラフおよび CLW のクエリの期間を変更します。
    3. 上位 N のグラフおよび CLW のクエリを実行して、使用する環境で必要となる最大のデータ セットを要求します。そのクエリによって関連するクランプがトリガされることを確認します。
    4. クランプが正しくトリガされるまで、手順 2 と 3c を繰り返します。