5 つの基本的なメトリック

内容
apmdevops96jp
内容
インスツルメントされたほとんどのメソッドでは、以下の 5 つのメトリックがレポートされます。
これらは Blame メトリックと呼ばれます。
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.
上の図は、Introscope Workstation に表示される EJB セッションの Average Response Time(平均応答時間)のグラフを表示します。 以下の点に注意してください。
  • データ ポイントにマウス カーソルを合わせると、データ ポイントに関する詳細情報を含むヒントが表示されます。
  • 上記の例は、次のことを示しています。
    • データ ポイントの
      、8919 ms は、間隔中に完了した要求の平均応答時間です。
    • 4 という数は、選択した間隔中に 4 つの要求が完了したことを意味します。
  • 値とカウントの他に、各データ ポイントには、最小値と最大値のデータがあります。
    • Min(最小)は、カウントで表わされる要求の中で最も低い 1 つの値です。この例では、完了までに最短の時間を要した応答です。
    • Max(最大)は、カウントで表わされる要求の中で最も高い 1 つの値です。この例では、完了までに最長の時間を要した応答です。
平均応答時間を使用した分類
平均応答時間をほかのメトリックの変化と組み合せて、傾向を分析することで、問題を識別し、診断できます。 (索引を利用して、このセクションに記載されたほかのメトリックの情報を調べてください。)
継続的な問題
利用可能なスレッド数の値が低く、平均応答時間の値が一貫して高い場合は、以下の問題を示している可能性があります。
  • 非効率なコード
  • 外部システムの過剰使用
  • バックエンドが遅い
  • レイヤが多すぎる
定期的な問題
平均応答時間が定期的に高くなる場合は、定期的に急増した後に通常に戻る状態を表すグラフで示されます。
利用可能なスレッド数の値が低く、平均応答時間の値が定期的に高くなる場合は、以下の問題を示している可能性があります。
  • GC リークが頻繁に発生
  • 負荷に関連するバックエンドのボトルネック
CPU 使用率の値が低く、平均応答時間の値が定期的に高くなる場合は、以下の問題を示している可能性があります。
  • 内部問題
進行的な問題
平均応答時間が長期にわたって安定して増加しており、間隔ごとの応答数の値が低い場合は、以下の問題を示している可能性があります。
  • メモリ リーク
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 値が一貫して高い場合は、以下の問題を示唆します。
  • 外部システムの過剰使用
  • バックエンドが遅い
Responses Per Interval 値が低く、Concurrent Invocations 値が一貫して高い場合は、以下の問題を示している場合があります。
  • 非効率なコード
  • レイヤが多すぎる
定期的な問題
Concurrent Invocations 値が定期的に高くなる場合は、定期的に急増した後に通常に戻る状態を表すグラフで示されます。 これは、次の問題を示している場合があります。
  • 負荷に関連するバックエンドのボトルネック
Available Connections 値が低く、Concurrent Invocations 値が定期的に高くなる場合は、以下の問題を示している場合があります。
  • リークのガベージ処理が頻繁に収集される
利用可能なスレッド数の値が低く、Concurrent Invocations 値が定期的に高くなる場合は、以下の問題を示している場合があります。
  • 内部問題
進行的な問題
Concurrent Invocations 値が長期にわたって安定して増加しており、特に、間隔ごとの応答数の値が低い場合は、以下の問題を示している可能性があります。
  • スレッド リーク
Errors Per Interval
エラー数は、JVM および HTTP エラー コードでレポートされる例外の数です。 エラーの例には、以下のものが挙げられます。
  • HTTP サーバによりレポートされた 404 Page Not Found ステータス
  • SQL 例外
  • Java 例外
エラー数は少ない方が理想的です。
The illustration shows a sample metric graph for Errors Per Interval, with one of the points selected to display a tooltip.
このメトリックは、間隔中にレポートされるエラーを単純にカウントします。 上の図では、選択された 1 つのデータ ポイントの値が 11 を示しており、そのタイムスライスで 11 個のエラーがレポートされたことを意味します。 これは単純なカウント メトリックであるため、値と最大値は常に同じになります。
グラフの下のメトリック パスで、例外をレポートするアプリケーションを識別します。 グラフに示されるエラーに関する詳細については、そのアプリケーションのログを参照してください。
エラー スナップショット
ErrorDetector が有効になっているシステムの場合、エラー スナップショットも生成されます。スナップショットは、エラーが発生したときに起こったことに関する詳細な情報を示し、トランザクション イベント データベースに格納されます。 エラーの数が多いと、ドキュメント化される情報も多くなり、このことを避けることもまた、エラーを最小限に抑えるもう一つの理由でもあります。
Responses per Interval
Responses Per Interval (間隔ごとの応答数)メトリックには、その間隔中に完了した呼び出しの数が反映されます。 データ処理量の測定値であるため、アプリケーションのパフォーマンスを示します。 一般的に、
  • 数字が大きい方が理想的で、
  • 数字が小さい方が望ましくありません。
  • 応答の予測されなかった急上昇は、外部システムの過剰使用を示します。Web サイトへのサービス妨害攻撃などです。
The illustration shows a sample graph of Responses Per Interval, with one data point selected to display a tooltip.
このメトリックは、間隔中に完了した応答を単純にカウントします。
上の図では、選択されたデータ ポイントがヒントに表示されています。 これは単純なカウント メトリックであるため、値とメトリックの最大値は常に同じになります。
ただし、以下の点に注意してください。
  • Responses Per Interval (間隔ごとの応答)メトリックの値は、Average Response Time (平均応答時間)メトリックのカウントと常に同じです。
  • Responses Per Interval は、タイプ IntCounter のメトリックです。 これは、応答の数の平均値ではなく、常に間隔中の応答の数の最大値です。
間隔ごとの応答数メトリックを使用した分類
Responses Per Interval をほかのメトリックの変化と組み合せて、傾向を分析することで、問題を識別および診断できます。 (索引を利用して、このセクションに記載されたほかのメトリックの情報を調べてください。)
継続的な問題
Responses Per Interval 値が一貫して高いことは、以下のことを示唆しています。
  • 外部システムの過剰使用
Stall Count (ストール数)
ストールした要求とは、指定した時間しきい値内に完了しなかった要求です。 要求がストールとしてカウントされる場合、要求がハングしたり、完了しないことを意味するものではなく、その実行がストールしきい値を超えたことを示します。
  • カウントが小さい方が理想的です。
  • カウントが高い方が望ましくありません。
デフォルトのストールしきい値は、30 秒です。
ストール イベントの情報は、トランザクション イベント データベースに格納されます。
ストール数の測定方法
場合によっては、トランザクション追跡で、指定した時間しきい値の間に完了しなかったいくつかの要求(ストールなど)が表示されます。ただし、Investigator では、別の数が Stall Count として表示されます。
ストール数は、(期間に対する)値の範囲ではなく、(間隔中の 1 時点の)ポイント値として記録されているからです。 このことは、間隔中に完了する長いトランザクションを表すいくつかのストール値が存在する可能性がある一方で、ある瞬間に使用できるカウントのみがデータ ポイントとして使用されることを意味します。
ストール数を使用した分類
Stall Count をほかのメトリックの変化と組み合せて、傾向を分析することで、問題を識別し、診断できます。 (索引を利用して、このセクションに記載されたほかのメトリックの情報を調べてください。)
継続的な問題
一貫して高い Stall Count 値は、以下のような状況を示す場合があります。
  • バックエンド システムが遅い
定期的な問題
定期的に高い Stall Count 値は、以下のような状況を示す場合があります。
  • 負荷に関連するバックエンドのボトルネック
進行的な問題
Stall Count 値が長期にわたって安定して増加しており、特に、Available Threads 値が低い場合は、以下の問題を示している可能性があります。
  • リソース リーク - スレッド