BlamePoint メトリック

CA APM では、BlamePoint メトリックと呼ばれる 5 つの基本的なメトリックを使用します。 BlamePoint メトリックでは、問題切り分け担当者に初期の方向性を示します。これにより、問題解決を支援するために招集する必要があるシステムの専門家を識別できます。 APM は、Java メソッドが監視対象の場合は常に、これらのメトリックをレポートします。たとえば、次のようなものがあります。
apmdevops98jp
CA APM では、
BlamePoint メトリック
と呼ばれる 5 つの基本的なメトリックを使用します。 BlamePoint メトリックでは、問題切り分け担当者に初期の方向性を示します。これにより、問題解決を支援するために招集する必要があるシステムの専門家を識別できます。 APM は、Java メソッドが監視対象の場合は常に、これらのメトリックをレポートします。たとえば、次のようなものがあります。
  • フロントエンド
  • Backends
  • SQL
  • Servlets
  • Web サービス(SOAP 障害メトリックを含む)
  • EJB
  • JSP
  • すべてのカスタム Java クラス/メソッド
インスツルメントされたほとんどのメソッドでは、以下の 5 つのメトリックがレポートされます。
2
2
以下の図は、APM レポートが Java メソッドの BlamePoint メトリックをレポートする方法を示します。
BlamePoint Metrics
Average Response Time (ms)
Average Response Time(平均応答時間)メトリックは、間隔中に完了したすべての要求の応答時間の平均を示します。 応答時間は要求を完了するための時間です。 この時間は、アプリケーション応答速度の基本的な測定値を示します。そのため、
  • 応答時間が短いのが望ましい状態です。
  • 長い応答時間は、問題があることを示しています。
注:
Average Response Time のカウントは、Responses Per Interval の値と同じです。
The illustration shows the tooltip which appears when you mouse over a graph datapoint.
この図は、Workstation に表示される EJB セッションの Average Response Time のグラフを表示します。 以下の点に注意してください。
  • データ ポイントにマウス カーソルを合わせると、データ ポイントに関する詳細情報を含むヒントが表示されます。
  • 例:
    • データ ポイントの値 8919 ms は、間隔中に完了した要求の平均応答時間です。
    • 4 という数は、選択した間隔中に 4 つの要求が完了したことを意味します。
  • 値とカウントの他に、各データ ポイントには、最小値と最大値のデータがあります。
    • 最小値は、カウントで表される要求の中で最も低い単一の値です。 この例では、完了までに最短の時間を要した要求です。
    • 最大値は、カウントで表される要求の中で最も高い単一の値です。 この例では、完了までに最長の時間を要した要求です。
Average Response Time に関する以下の情報を考慮してください。
  • Average Response Time を使用した分類
    Average Response Time をほかのメトリックの変化と組み合わせて、傾向を分析することで、問題を識別し、診断できます。
  • 継続的な問題
    利用可能なスレッド数の値が低く、平均応答時間の値が一貫して高い場合は、以下の問題を示している可能性があります。
    - 非効率なコード
    - 外部システムの過剰使用
    - バックエンドが遅い
    - レイヤが多すぎる
  • 定期的な問題
    グラフ内で Average Response Time が定期的に高くなり、その後、通常に戻る様子が示されます。 利用可能なスレッド数の値が低く、Available Thread Count の値が定期的に高くなる場合は、以下の問題を示している可能性があります。
    - GC リークが頻繁に発生
    - 負荷に関連するバックエンドのボトルネック
    CPU 使用率の値が低く、平均応答時間の値が定期的に高くなる場合は、以下の問題を示している可能性があります。
    - 内部問題
  • 進行的な問題
    Average Response Time が長期にわたって安定して増加しており、Responses Per Interval の値が低い場合は、メモリ リークを示している可能性があります。
Concurrent Invocations
呼び出しは、アプリケーションおよびそのさまざまな部分によって処理される要求です。 Concurrent Invocations (同時進行中の呼び出し)は、一定の時間に処理される要求の数です。
CA APM は、特定の間隔の終了時にまだ処理中であった要求の数を数えて、Concurrent Invocations メトリックを計算します。
  • Concurrent Invocations 値は低い方が理想的です。
  • 同時進行中の呼び出し値が高い場合は、問題があることを示唆しています。
同時進行中の呼び出しは、同じ間隔中に終了を待たずに起動します。 メソッドをできるだけ早く終了するためには、同時進行中の呼び出しが異常に多いのは望ましくありません。 複数の呼び出しが同時に進行中のときは、一時的に値が急増する可能性がありますが、メトリックは毎回、ゼロに戻ります。 ゼロに戻らないメトリックは、スレッド、データベース接続の数、またはその他の共有リソースのボトルネックを示している可能性があります。
The illustration shows a sample Concurrent Invocations graph.
この図の 1 という値は、選択した間隔の終了時に、1 つの要求がまだ処理中であったことを示しています。 選択した間隔の終了時に進行中であった要求は、その後の間隔中に完了すると思われます。 指定したしきい値の前に完了しなかったこれらの要求は、ストールと呼ばれます(「Stall Count」を参照)。
Concurrent Invocations に関する以下の情報を考慮してください。
  • Concurrent Invocations (同時発生中の呼び出し)を使用した分類
    Concurrent Invocations をほかのメトリックの変化と組み合わせて、傾向を分析することで、問題を識別して診断できます。
  • 継続的な問題
    Concurrent Invocations 値が一貫して高い場合は、以下の問題を示している可能性があります: 外部システムの過剰使用、バックエンドが遅い
    Responses Per Interval 値が低く、Concurrent Invocations 値が一貫して高い場合は、以下の問題を示している可能性があります。
    - 非効率なコード
    - レイヤが多すぎる
  • 定期的な問題
    Concurrent Invocations 値が定期的に高くなる場合は、定期的に急増した後に通常に戻る状態を表すグラフで示されます。 この急激な増加は、負荷に関連するバックエンドのボトルネックを示している可能性があります。
    Available Connections 値が低く、Concurrent Invocations 値が定期的に高くなる場合は、頻繁に収集されるガベージ リークを示している可能性があります。
    Available Thread Count の値が低く、Concurrent Invocations 値が定期的に高くなる場合は、内部の問題を示している可能性があります。
  • 進行的な問題
    Concurrent Invocations 値が長期にわたって安定して増加しており、特に、Responses Per Interval の値が低い場合は、スレッド リークを示している可能性があります。
Errors Per Interval
エラーは、JVM および HTTP エラー コードでレポートされる例外の数です。 エラーの例には、以下のものが挙げられます。
  • HTTP サーバによりレポートされた 404 Page Not Found ステータス
  • SQL 例外
  • Java 例外
エラー数は少ない方が理想的です。
1470851.png
このメトリックは、間隔中にレポートされるエラーを単純にカウントします。 この図では、選択された 1 つのデータ ポイントの値が 11 を示しており、そのタイムスライスで 11 個のエラーがレポートされたことを意味します。 このメトリックは、単純なカウントであるため、値および最大値は常に同じです。
グラフの下のメトリック パスで、例外をレポートするアプリケーションを識別します。 グラフに示されるエラーに関する詳細については、そのアプリケーションのログを参照してください。
ErrorDetector が有効になっているシステムの場合、エラー スナップショットも生成します。 エラー スナップショットは、エラーが発生したときに何が起こっていたかを示す詳しい情報を提供します。 この情報は、トランザクション イベント データベースに格納されます。 エラーの数が多いと、ドキュメント化される情報も多くなります。 この情報を避けることもまた、エラーを最小限に抑えるもう一つの理由でもあります。
Responses Per Interval
Responses Per Interval メトリックには、その間隔中に完了した呼び出しの数が反映されます。 このメトリックは、データ処理量の測定値であるため、アプリケーションのパフォーマンスを示します。 このメトリックは、間隔中に完了した応答を単純にカウントします。
  • Responses Per Interval (間隔ごとの応答)メトリックの値は、Average Response Time (平均応答時間)メトリックのカウントと常に同じです。
  • Responses Per Interval は、タイプ IntCounter のメトリックです。 このメトリックは、応答の数の平均値ではなく、常に間隔中の応答の数の最大値です。
一般的に、
  • 数字が大きい方が理想的で、
  • 数字が小さい方が望ましくありません。
  • 応答の予測されなかった急上昇は、外部システムの過剰使用を示します。Web サイトへのサービス妨害攻撃などです。
The illustration shows a sample graph of Responses Per Interval, with one data point selected to display a tooltip.
上の図では、選択されたデータ ポイントがヒントに表示されています。 このメトリックは、単純なカウントであるため、メトリックの値および最大値は常に同じです。
Responses Per Interval に関する以下の情報を考慮してください。
  • Responses Per Interval を使用した分類
    Responses Per Interval をほかのメトリックの変化と組み合わせて、傾向を分析することで、問題を識別および診断できます。
  • 継続的な問題
    Responses Per Interval の値が一貫して高い場合は、外部システムの過剰使用を示している可能性があります。
Stall Count
ストールした要求とは、指定した時間しきい値内に完了しなかった要求です。 (デフォルトのストールしきい値は、30 秒です。)ストールとしてカウントされる要求では、その実行がストールのしきい値を超えたことを意味します。
  • カウントが小さい方が理想的です。
  • カウントが高い方が望ましくありません。
ストールは、以下のいずれかを表す場合があります。 ストールには、その他の理由がある場合がありますが、これらのケースが最も一般的です。
  • 無限ループ内のスレッド
    プログラマが、正常に終了するはずのループが、終了しないコードを書くことがあります。 スレッドが無限ループに入ったときに、それを呼び出すコンポーネントでストール数が増加します。 無限ループには、CPU コアがビジーになるという追加の特徴があります。 たとえば、4 つのコアを持つあまり処理が行われていないシステム上で、スレッドが無限ループに入った場合、合計 CPU 使用率は約 25% に上昇する可能性があります。 2 つ目のスレッドが無限ループに入ると CPU は 50% に上昇する、などです。
  • 長時間待機するスレッド、またはタイムアウトしないスレッド
    スレッドがリモート システムへのソケットのようなリソースを開こうとするとき、プログラマは一定の秒数の後に停止することを指定できます。 この期間が十分である場合(たとえば 5 分間)、Stall Count は上昇し、5 分間の間、増分され続けます。 接続の試行がタイムアウトしない場合があります。その場合、スレッドは占有され続け、Stall Count が減ることはありません。
    多くのシステムで、日常的な理由でこのようにブロックされるスレッドがあります。 この動作が、システムがアイドル状態のときにもコンポーネントで Stall Count がゼロ以外である理由です。 「自然な」スレッド数に注意し、異常な変化がある問題のみを取り上げます。
  • デッドロックまたはライブロックに関連しているスレッド
    プログラマはロックを使用して、データが破損しないようにします。 誤った順番でロックが取得される場合があります。その場合、プログラムはデッドロックと呼ばれる状態になります。 デッドロックは、2 つ以上のスレッドが相互に続行を待機してスタックしていることを意味します。 スレッドは、他方のスレッドでリソースをすでにチェックアウトしていなければ続行することができません。 デッドロックは、ほとんどすべての場合において重大なシステム障害です。 スレッド ダンプは多くの場合、中断したコードを識別するための最も役に立つ技術です。 ライブロックは、1 つ以上のスレッドが CPU を頻繁に使用するデッドロックです。 デッドロックは、次の点で無限ループとは異なります。無限ループは、ループに対する中断状態の結果に過ぎませんが、デッドロックは、それが発生したアプリケーションのロッキング セマンティクス、つまり「同期された」コードに関連しています。
注:
ストール イベントの情報は、トランザクション イベント データベースに格納されます。
Stall Count に関する以下の情報を考慮してください。
  • ストール数の測定
    トランザクション追跡は指定した時間しきい値の間に完了しなかったいくつかの要求を示します(ストール)。ただし、Investigator は Stall Count と異なる数を表示します。
    これは、ストール数が(期間に対する)値の範囲ではなく、(間隔中の一時点の)ポイント値として記録されているからです。 このことは、間隔中に完了する長いトランザクションを表すいくつかのストール値が存在する可能性がある一方で、ある瞬間に使用できるカウントのみがデータ ポイントとして使用される可能性があります。
  • ストール数を使用した分類
    Stall Count (ストール数)をほかのメトリックの変化と組み合わせて、傾向を分析することで、問題を識別し、診断します。
  • 継続的な問題
    Stall Count の値が一貫して高い場合は、低速のバックエンド システムを示している可能性があります。
  • 定期的な問題
    定期的に高い Stall Count 値は、負荷に関連するバックエンドのボトルネックを示している可能性があります。
  • 進行的な問題
    Stall Count 値が長期にわたって安定して増加しており、特に、Available Threads 値が低い場合は、リソース リーク(スレッド)を示している可能性があります。