ARMS Application Monitoring エージェントのバージョン 4.x 以降は、OpenTelemetry Java エージェントをベースに構築されており、オープンソース標準を完全に採用しています。以前のエージェントバージョンとの完全な機能パリティを提供しつつも、一部の機能が若干調整されています。このトピックでは、これらの変更点とその潜在的な影響、そしてレポートされるデータ量が増加する可能性がある理由について概説します。
変更点と影響
-
デフォルトでは、Spring で管理される Bean のメソッドインストルメンテーションは無効になっています。エージェントはコントローラーメソッドのみをインストルメントするようになりました。
潜在的なリスク：
-
アップグレード後、
@Serviceまたは@Componentでアノテーションが付けられたクラスのメソッドは、トレースに表示されなくなります。 -
@Serviceまたは@Componentでアノテーションが付けられたクラスのメソッドからスローされた例外はキャプチャされません。
-
-
スレッドプールモニタリングと接続プールモニタリングのメトリック名が変更されました。詳細については、「スレッドプールと接続プールのモニタリング」をご参照ください。
潜在的なリスク：
-
Application Monitoring でスレッドプールモニタリングのアラートルールを設定している場合は、再設定する必要があります。
[アプリケーションモニタリングのアラートルールを作成] ページで、[メトリックタイプ] を [Thread_Pool_Version_2] に設定します。
-
スレッドプールのメトリックを使用するカスタムダッシュボードがある場合、データが表示されなくなります。
-
メトリック量の増加により、従量課金コストが増加する可能性があります。
-
-
メッセージ遅延をモニタリングするためのメトリックは、arms_mq_delay_seconds に名前が変更されました。
潜在的なリスク：このメトリックを使用するカスタムダッシュボードがある場合、データが表示されなくなります。
-
エージェントは非同期呼び出しのトレースコンテキストを自動的に伝播するようになり、パッケージ名を設定する必要がなくなりました。
-
RabbitMQ のカスタムコンシューマーや Kafka のカスタム消費メソッドを定義する必要はなくなりました。既存の定義は影響を受けません。
-
MDC.get("EagleEye-TraceID")を使用したトレース ID の取得はサポートされなくなりました。ただし、ログとトレース ID の関連付けは影響を受けません。潜在的なリスク：
MDC.get("EagleEye-TraceID")を使用して取得したトレース ID は null になります。 -
エントリーポイントのない内部呼び出しでもスパンが生成されるようになりました。
潜在的なリスク：スパン数の増加により、従量課金コストが増加する可能性があります。
-
エージェントは、以前の Prometheus の Summary ベースのアルゴリズムに代わり、線形補間に基づくバケット分布法を使用して分位数統計を計算するようになりました。
潜在的なリスク：実際の持続時間分布が現在のバケット化と大幅に異なる場合、分位数メトリックが不正確になる可能性があります。
-
SpanStatusは OpenTelemetry 標準に準拠するようになりました。この標準では、4xxまたは5xxのレスポンスコードを持つ HTTP リクエストは「error」としてマークされます。その他のすべてのケースは「unset」としてマークされます。以前のエージェントバージョンでは、これらのその他のケースは「ok」としてマークされていました。 -
4.x エージェントにアップグレードした後、トレース ID は 32 文字の長さである必要があります。このフォーマットは、レガシーなブラウザ監視機能と互換性がありません。新しいリアルユーザーモニタリングサービスとの統合を推奨します。
-
エージェントのバージョン 4.1.12 以前は、JDK 21 の仮想スレッド機能と互換性がありません。完全な互換性は 4.3.x リリースで計画されています。ご利用のアプリケーションが仮想スレッドに大きく依存している場合は、3.x バージョンのエージェントを引き続き使用することを推奨します。
-
arms-sdkを使用してspring-cloud-gatewayフィルター経由でバゲージを追加するアプリケーションの場合、エージェント 4.2.x にアップグレードし、カスタム構成でspring-beanプラグインを有効にすると、バゲージの伝播が失敗します。
4.x でのデータレポート量の増加
3.x エージェントから 4.x エージェントにアップグレードした後、特定のシナリオでレポートされるメトリック量が増加することがあります。この増加は、以下の変更によるものです：
-
エージェントはエントリーポイントのない内部呼び出しに対してもスパンを作成するようになり、レポートされるスパンとメトリックの数が増加します。
-
エージェントはスレッドプールモニタリングでより多くのカスタムスレッドプールをサポートするようになり、レポートされるメトリックの数が増加します。
-
エージェントは接続プールモニタリングでより多くの接続プールタイプをサポートするようになり、レポートされるメトリックの数が増加します。
-
非同期呼び出しの場合、4.x エージェントがトレースコンテキストを自動的に伝播するため、アップストリームおよびダウンストリームのメトリック数が増加します。
-
エージェントは、Lettuce の拡張インストルメンテーションなど、プラグインのサポートを拡大したため、レポートされるメトリックが増加します。
-
スレッド数が多いアプリケーションでのスレッドプロファイリングのパフォーマンスを向上させるため、4.x エージェントはデータの収集と保存の方法を調整しています。3.x エージェントと比較して、スレッドプロファイリングを有効にすると、
arms_grouped_threadというプレフィックスが付いた少数の追加メトリックがレポートされるようになりました。この機能を無効にする方法については、「スレッドプロファイリング」をご参照ください。 -
メッセージキュー (MQ) でのバッチメッセージ消費において、エージェントはバッチ全体に対して 1 つのスパンを作成する代わりに、バッチ内の各メッセージに対して個別のスパンを作成するようになりました。バッチに多くのメッセージが含まれている場合、これによりレポートされるスパンの数が大幅に増加する可能性があります。これは、より詳細なデータを提供するための意図的な変更です。データ量が懸念される場合は、サンプリングレートの調整または関連する MQ プラグインの無効化をご検討ください。