Professional Edition アプリケーションのアプリケーションモニタリングが有効になると、ARMS はアプリケーションをモニタリングできます。[依存サービス] ページでは、外部呼び出し、データベース呼び出し、メッセージキューに関する情報など、依存サービスの詳細を表示できます。
サポートされているフレームワーク
依存サービスの表示
[サービス] タブでは、クイックフィルターエリア（アイコン 1 ）でリクエストタイプ、リクエストターゲット、またはインスタンスをフィルターしたり、トレンドチャートエリア（アイコン 2 ）で対応するリクエストタイプのトレンドを表示したり、サービスリストエリア（アイコン 3 ）でインターフェイスに関するより詳細な情報を表示したりできます。
クイックフィルターエリア（アイコン 1 ）では、リクエストタイプ、リクエスト先、およびインスタンスでフィルターできます。
クエリするターゲットフィールドを選択します。フィールドを選択しない場合、デフォルトですべてのフィールドのモニタリング情報がクエリされます。
トレンドチャートセクション（アイコン 2 ）では、アプリケーションが依存関係に送信したリクエストの時系列、エラーの数、および指定された期間内の平均期間を表示できます。
アイコンをクリックすると、表示されるダイアログボックスで特定の期間のメトリックデータを表示したり、異なる日付の同じ期間のメトリックデータを比較したりできます。
アイコンをクリックすると、縦棒グラフとトレンドチャートの表示を切り替えることができます。サービスリストセクション（アイコン 3 ）では、RED メソッドで定義された各リクエストの名前、タイプ、および主要なメトリック（レート、エラー、および期間）を表示できます。
サービスリストでは、次の操作を実行できます。
リクエストターゲットまたは [アクション] 列の [詳細] をクリックすると、対応するサービスの詳細情報を表示できます。詳細については、「依存サービスの詳細」をご参照ください。
[アクション] 列の [トレース] をクリックすると、依存サービス呼び出しのトレースの詳細を表示できます。詳細については、「トレースエクスプローラー」をご参照ください。
[依存サービス] の右側のドロップダウンリストをクリックすると、[データベース呼び出し]、[NoSQL 呼び出し]、[外部呼び出し]、および [メッセージパブリッシング] を表示できます。特定のメッセージについては、「依存関係の詳細」をご参照ください。
依存サービスの詳細
Python アプリケーションのメッセージ呼び出しは表示できません。
概要
[概要] タブでは、ターゲットメッセージのリクエスト数、エラー数、平均応答時間の統計と、低速呼び出しの時系列を表示できます。
アクセスパス
[アクセスパス] タブでは、ターゲットの依存関係アクセスパスのリクエスト数、エラー数、平均応答時間の統計を表示できます。
呼び出し元
[呼び出し元] タブでは、ターゲットインターフェイスのリクエスト数、エラー数、平均応答時間の統計を表示できます。
トレース分析
このページでトレース分析を直接表示することはできません。[トレース分析] タブをクリックして対応するページにジャンプし、表示できます。
よくある質問
データベース
データベース呼び出しにデータがないのはなぜですか？
考えられる原因：
データベースが ARMS でサポートされているデータベースのリストにありません。サポートされているデータベースについては、「ARMS でサポートされている Java コンポーネントとフレームワーク」をご参照ください。
v4.x より前の ARMS エージェントは、非同期に呼び出されたデータベース、またはエントリポイントのないデータベースをサポートしていません。
ARMS コンソールにデータベースサーバー側では見えない低速のデータベース呼び出しが表示されるのはなぜですか？
低速 SQL しきい値カスタム設定ARMS はクライアントの観点からモニタリングを行い、アプリケーション内でリクエストが開始されてから、ネットワーク経由でサーバーに送信され、サーバーによって処理され、応答がクライアントに返送されるまでのプロセス全体を網羅しています。そのため、ARMS によって収集されたデータベースメトリックは、ガベージコレクションやネットワーク遅延などの要因の影響を受ける可能性があり、サーバー側で観測される値よりも高い値になる可能性があります。さらに、ARMS は、 ページで設定された に基づいて呼び出しが低速かどうかを判断します。デフォルトのしきい値は 500 ミリ秒で、サーバー側の設定とは異なる場合があります。
ARMS コンソールに表示されるデータベース呼び出し量が、データベースサーバーモニタリングで観測される呼び出し量と異なるのはなぜですか？
データベースには複数のアプリケーションからアクセスされる可能性があります。ARMS コンソールには、現在のアプリケーションからの呼び出し量のみが表示され、同じデータベースにアクセスしている他のアプリケーションからの呼び出し量は表示されません。
一部の外部呼び出しが記録されないのはなぜですか？
3.x エージェントでは、原因は次のとおりです。
エントリポイントのない外部呼び出し。
デフォルトでは、3.x エージェントは、HTTP インターフェイス、RPC インターフェイス、スケジュールされたタスク、およびメッセージ消費の処理フロー内で実行される外部呼び出しのみを収集します。たとえば、データベースへのアクセスや HTTP リクエストの送信などです。スケジュールに従ってスレッドプールを介して直接実行される外部呼び出しは、収集中に無視されます。
エントリポイントのある外部呼び出しですが、実際の外部呼び出しの実行時にスレッドの切り替えが発生します。
3.x エージェントは自動非同期コンテキスト伝播をサポートしていないため、スレッドの切り替え後にトレースコンテキストがなくなり、この場合も収集は無視されます。
どちらの状況も、エージェントを 4.x にアップグレードすることで解決できます。
外部呼び出しに未定義のデータがあるのはなぜですか？
エージェントバージョン 3.1.x 以前には、Dubbo イベントトラッキングに欠陥があり、ピア IP アドレスの取得に失敗します。この問題はバージョン 3.2.x で修正されています。
Redis 呼び出しキーに文字化けが表示されるのはなぜですか？
これは、Lettuce フレームワークのイベントトラッキングの問題が原因で、キー値が正しくないことが原因です。他の部分は有効な値であるため、文字化けした部分は無視できます。
SQL 文からトレースエクスプローラーページにジャンプしたときにデータがないのはなぜですか？
トレースエクスプローラー原因：極端なシナリオで大容量のデータをレポートする際のコストとパフォーマンスのオーバーヘッドを回避するために、ARMS エージェントはデフォルトで Span 圧縮を有効にします。ParentSpan の複数の子 Span に同じ SpanName がある場合、1 つの子 Span のみが記録され、その子 Span の属性には、類似の子 Span の数、それらの期間の合計、最大期間、および最小期間が記録されます。この状況により、圧縮された Span からの情報が失われ、同様に、圧縮された Span の SQL 文は ページで直接クエリできません。
解決策：トレース圧縮を無効にします。
圧縮を無効にすると、アプリケーションインターフェイスがデータベースや Redis などのコンポーネントに対して多くの操作を実行する場合、レポートされるデータ量が増加し、ARMS のエラーおよび低速サンプリングロジックが無効になります。
メッセージパブリッシング
メッセージサブスクリプション/メッセージパブリッシングページのデータと、メッセージキューインスタンスの自己モニタリングパネルのデータの違いは何ですか？
メッセージ サブスクリプション/メッセージ パブリッシング ページのデータは、選択したアプリケーションがコンシューマーまたはプロデューサーとして機能する場合のさまざまなパフォーマンス メトリックを反映し、クライアントの観点からモニタリング データを示します。一方、メッセージ キュー インスタンスのモニタリング パネル データは、トピックに関連するパフォーマンス メトリックを示し、サーバーの観点からのデータです。
メッセージの送受信における SpanName の形式は何ですか？
メッセージタイプ | v4.x より前の ARMS エージェント | ARMS エージェント v4.x 以降 |
RocketMQ/ONS メッセージ送信 | スパンは作成されません。メソッドスタックのみが記録されます。 |
|
RocketMQ/ONS メッセージ受信 |
|
|
Kafka メッセージ送信 | スパンは作成されません。メソッドスタックのみが記録されます。 |
|
Kafka メッセージ受信 |
|
|
RabbitMQ メッセージ送信 | スパンは作成されません。メソッドスタックのみが記録されます。 |
|
RabbitMQ メッセージ受信 |
|
|
Java 用 ARMS エージェントは Spring Cloud Alibaba RocketMQ をサポートしていますか？
ARMS エージェント v4.x 以降はこのフレームワークをサポートしています。エージェントのバージョンが 4.x より前の場合は、アップグレードしてください。
メッセージキューモニタリングにおける「メッセージ遅延」メトリックの意味と単位は何ですか？
メッセージ遅延とは、メッセージが生成されてからコンシューマーによって消費されるまでの合計時間のことです。このメトリックの単位はミリ秒（ms）です。現在、このメトリックは RocketMQ Client および ONS Client による収集のみでサポートされています。
アプリケーションにコンシューマーロジックがあるのに、コンシューマーに関連付けられたトレースまたはメトリックデータがないのはなぜですか？
エージェントのバージョンが 4.x より前で、messageListener 内の消費ロジックの定義にラムダ式が使用されていたことが原因である可能性があります。
エージェントバージョン 2.x および 3.x ではラムダ式のクラス拡張に失敗するため、エージェントを v4.x にアップグレードすることでこの問題を回避できます。
Kafka Client を Java 用 ARMS エージェントに接続したときに、「Magic v1 はレコードヘッダーをサポートしていません」というエラーメッセージが表示されるのはなぜですか？
Java 用 ARMS エージェントは、Kafka メッセージの Header フィールドを使用してトレースコンテキストを渡します。ただし、0.11.0.0 より前の Kafka バージョン (クライアントとブローカーの両方) では、Kafka メッセージ本文は Header フィールドをサポートしていません。 Kafka-broker または Kafka-clients がこのバージョンより前の場合、できるだけ早くバージョン 0.11.0.0 以降に移行してください。
現時点での移行が不可能な場合、v4.x より前のエージェントでは、[カスタム設定] タブの プローブスイッチ設定 セクションで、Kafka コンポーネントの拡張 (kafka-plugin スイッチ) を無効にすることができます。 v4.x 以後のエージェントの場合は、サービスの起動時に JVM パラメーター -Dotel.instrumentation.kafka.producer-propagation.enabled=false を追加して、このような問題を回避できます。
メッセージの送受信の Span がトレースにないのはなぜですか？
プロデューサーおよびコンシューマーアプリケーションで使用されているメッセージキュー Client SDK が ARMS でサポートされている範囲内にあるかどうかを確認します。詳細については、「ARMS でサポートされている Java コンポーネントとフレームワーク」をご参照ください。
プロデューサーアプリケーションとコンシューマーアプリケーションの両方が、アプリケーションモニタリングまたは Managed Service for OpenTelemetry によってモニタリングされており、エージェントスイッチとプラグインスイッチが正しく有効になっており、同じリージョンにレポートしていることを確認します。メッセージ送信の Span はプロデューサーで生成され、メッセージ受信の Span はコンシューマーで生成されます。アプリケーションが適切にモニタリングされていない場合、対応する Span は見つかりません。
メッセージ送信の Span が表示されない場合は、プロデューサーアプリケーションのエージェントバージョンが 4.x 以降であるかどうかを確認します。4.x より前のエージェントバージョンでは、メッセージの送信は個別の Span を生成せず、親 Span のメソッドスタック内に記録されます。親 Span の右側にある
アイコンをクリックすると、実際の呼び出しメソッドスタックを表示できます。
メッセージ受信の Span が表示されない場合は、[カスタム設定] タブの [インターフェイス呼び出し設定] セクションで [無効なインターフェイスフィルター] が有効になっているかどうかを確認します。このオプションは、関係のない Span を除外します。
エージェントバージョン 4.x とそれ以前の Kafka 応答時間に大きな違いがあるのはなぜですか？
問題：応答時間が数秒から 0.x ミリ秒に変わりました。
原因：
エージェントバージョン 3.x 以前では、BatchMessageListener を処理する場合、メッセージのバッチは単一の呼び出しと見なされ、すべての期間がまとめて集計されます。
エージェントバージョン 4.x 以降では、これらの操作は分離され、各メッセージが個別の呼び出しとしてカウントされます。したがって、エージェントバージョン 3.x から 4.x にアップグレードする場合、単一の呼び出しの期間が大幅に短縮され、呼び出し数が大幅に増加することが予想されます。
バージョン 3.x の統計方法は不合理であり、バージョン 4.x で最適化されています。