アプリケーションの依存関係を表示する

アプリケーションに Application Real-Time Monitoring Service (ARMS) エージェントをインストールすると、ARMS はアプリケーションのモニタリングを開始します。[依存関係] ページで、外部呼び出し、データベース呼び出し、メッセージキューなど、アプリケーションの依存関係に関する情報を表示できます。

前提条件

ARMS エージェントがアプリケーションにインストールされていること。

重要

アプリケーションモニタリングは、新しい課金モードを有効にしたユーザーに、新しいアプリケーション詳細ページを提供します。

新しい課金モードを有効にしていない場合、Application List ページで Switch to New Version をクリックすると、新しいアプリケーション詳細ページを表示できます。

ARMS コンソールにログインします。左側のナビゲーションウィンドウで、[Application Monitoring] > [アプリケーションリスト] を選択します。
上部のナビゲーションバーで、[依存関係] をクリックします。
- 「クイックフィルター」セクション (アイコン 1) では、[リクエストタイプ]、[リクエスト先]、および[ホスト]でチャートと依存関係をクエリできます。
- トレンドチャートセクション (アイコン 2) では、指定した期間内にアプリケーションから依存関係に送信されたリクエストの時系列、エラー数、平均期間を表示できます。
  アイコンをクリックします。表示されるダイアログボックスで、特定の期間のメトリックデータを表示したり、異なる日付の同じ期間のメトリックデータを比較したりできます。アイコンをクリックすると、データを縦棒グラフまたはトレンドチャートで表示できます。
- サービスリストセクション (アイコン 3) では、RED メソッドで定義された各リクエストの名前、タイプ、および主要なメトリック (レート、エラー、期間) を表示できます。
  サービスリストでは、次の操作を実行できます。
  - 依存関係の名前をクリックするか、[アクション] 列で [詳細]、[SQL 分析]、または [例外] をクリックして、依存関係の詳細を表示します。詳細については、「依存関係の詳細」をご参照ください。
  - [アクション] 列の[トレース]をクリックして、依存関係のトレース詳細を表示します。詳細については、「トレースエクスプローラー」をご参照ください。

サポートされるフレームワーク

依存関係の詳細

外部呼び出し

概要

[概要] タブでは、リクエスト数、エラー数、エンドポイントまたはサービスの平均所要時間、および低速呼び出しの時系列を表示できます。

トレースエクスプローラー

トレースエクスプローラーを使用すると、フィルター条件と集約ディメンションを組み合わせて、保存されている完全なトレースデータに基づいてリアルタイム分析を行うことができます。これにより、さまざまなシナリオでのカスタム診断要件を満たすことができます。詳細については、「トレースエクスプローラー」をご参照ください。 Span数据信息

メッセージの公開

説明

Python アプリケーションのメッセージ公開は表示できません。

概要

[概要] タブでは、リクエスト数、エラー数、メッセージの平均所要時間、および低速な呼び出しの時系列を表示できます。

配信統計

[配信統計] タブでは、メッセージ送信者の視点から、リクエスト数、エラー数、所要時間など、Topic へのメッセージ送信の詳細を表示できます。

トレースエクスプローラー

データベース呼び出し

説明

Python アプリケーションのデータベース呼び出しは表示できません。

概要

[概要] タブでは、アプリケーションが呼び出すデータベースインスタンスのリクエスト数、エラー数、平均所要時間、および低速な呼び出しの時系列を表示できます。

SQL 分析

[SQL 分析] タブでは、データベースインスタンスのリクエスト数、エラー数、平均所要時間の傾向、および SQL 文の時系列を表示できます。このタブでは、サービスの応答が遅くなる原因となっている SQL 文を特定できます。

説明

[Return Size] フィールドは、MySQL v5.x でのみ利用可能であり、ARMS agent v2.7.1.3 以降でのみサポートされます。

「操作」列で[トレース]をクリックすると、SQL 文のトレースを表示できます。詳細については、「トレースエクスプローラー」をご参照ください。

例外

[例外] タブでは、指定された期間内にアプリケーションがデータベースを呼び出すときに各例外がスローされる回数、および例外の詳細を確認できます。詳細については、「例外分析」をご参照ください。

リクエストのソース

[リクエストソース] タブでは、アプリケーションがデータベースを呼び出すインターフェイスの応答時間、リクエスト数、およびエラー数の時系列を表示できます。

トレースエクスプローラー

よくある質問

データベース

データベース呼び出しにデータがないのはなぜですか？

考えられる原因：

データベースが ARMS でサポートされているデータベースのリストにない。サポートされているデータベースについては、「ARMS でサポートされる Java コンポーネントとフレームワーク」をご参照ください。
v4.x より前の ARMS エージェントは、非同期で呼び出される、またはエントリポイントのないデータベースをサポートしていません。

データベースサーバー側では見えない低速なデータベース呼び出しが ARMS コンソールに表示されるのはなぜですか？

ARMS はクライアントの視点から、リクエストがアプリケーション内で開始され、ネットワークを介してサーバーに送信され、サーバーで処理され、応答がクライアントに返されるまでのプロセス全体を監視します。したがって、ARMS によって収集されるデータベースメトリックは、GC やネットワーク遅延などの要因の影響を受けるため、サーバー側で観測される値よりも高くなる可能性があります。さらに、ARMS は [カスタム設定] ページで設定された [低速 SQL しきい値] に基づいて呼び出しが低速かどうかを判断します。このデフォルトのしきい値は 500 ms で、サーバー側の設定と異なる場合があります。

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 圧縮を有効にします。親 Span の複数の子 Span が同じ SpanName を持つ場合、1 つの子 Span のみが記録され、その子 Span の属性には同様の子 Span の数、それらの継続時間の合計、最大継続時間、および最小継続時間が記録されます。この状況により、圧縮された Span からの情報が失われ、同様に、圧縮された Span 内の SQL 文は Trace Explorer ページで直接クエリできません。

解決策: トレース圧縮を無効にします。

説明

圧縮を無効にすると、アプリケーションインターフェイスがデータベースや Redis などのコンポーネントに対して多くの操作を実行する場合、レポートされるデータ量が増加し、ARMS のエラーおよび低速サンプリングロジックが効果を失います。

メッセージの公開

メッセージサブスクリプション/メッセージ公開ページ上のデータと、メッセージキューインスタンスの自己監視パネルからのデータとの違いは何ですか？

メッセージサブスクリプション/メッセージ公開ページのデータは、選択したアプリケーションがコンシューマーまたはプロデューサーとして機能するときのさまざまなパフォーマンスメトリックを反映し、クライアントの視点からのモニタリングデータを表示します。一方、メッセージキューインスタンスのモニタリングパネルデータは、トピックに関連するパフォーマンスメトリックを示し、これはサーバーの視点からのデータです。

メッセージの送受信における SpanName のフォーマットは何ですか？

メッセージタイプ	v4.x より前の ARMS エージェント	ARMS エージェント v4.x 以降
RocketMQ/ONS メッセージ送信	Span は作成されません。メソッドスタックのみが記録されます。	`${topic} + publish`
RocketMQ/ONS メッセージ受信	`Recv Topic@${topic}`	`Recv Topic@${topic}`
Kafka メッセージ送信	Span は作成されません。メソッドスタックのみが記録されます。	`${topic} + publish`
Kafka メッセージ受信	`Kafka/topic=${topic}`	`Kafka/topic=${topic}`
RabbitMQ メッセージ送信	Span は作成されません。メソッドスタックのみが記録されます。	`${exchange} + publish`
RabbitMQ メッセージ受信	`Recv Exchange@${exchange}`	`Recv Exchange@${exchange}`

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 にアップグレードすることでこの問題を回避できます。

Java 用 ARMS エージェントに Kafka クライアントを接続したときに「Magic v1 does not support record headers」というエラーメッセージが表示されたのはなぜですか？

Java 用 ARMS エージェントは、Kafka メッセージのヘッダーフィールドを使用してトレースコンテキストを渡します。ただし、0.11.0.0 より前の Kafka バージョン (クライアントとブローカーの両方) では、Kafka メッセージ本文はヘッダーフィールドをサポートしていません。お使いの Kafka ブローカーまたは Kafka クライアントがこのバージョンより低い場合は、できるだけ早くバージョン 0.11.0.0 以降に移行してください。現時点で移行できない場合、v4.x より前のエージェントでは、[カスタム設定] タブの [プローブスイッチ設定] セクションで Kafka コンポーネントの拡張機能 (kafka-plugin スイッチ) を無効にし、v4.x 以降のエージェントでは、サービスの開始時に JVM パラメーター -Dotel.instrumentation.kafka.producer-propagation.enabled=false を追加して、このような問題を回避できます。

トレースにメッセージの受信または送信の Span がないのはなぜですか？

プロデューサーおよびコンシューマーアプリケーションで使用されているメッセージキュークライアント SDK が ARMS でサポートされている範囲内にあるかどうかを確認してください。詳細については、「ARMS でサポートされる Java コンポーネントとフレームワーク」をご参照ください。
プロデューサーとコンシューマーの両方のアプリケーションが、アプリケーションモニタリングまたは Managed Service for OpenTelemetry によってモニタリングされており、エージェントスイッチとプラグインスイッチが正しく有効になっていて、同じリージョンにレポートしていることを確認してください。メッセージ送信の Span はプロデューサーで生成され、メッセージ受信の Span はコンシューマーで生成されます。アプリケーションが適切にモニタリングされていない場合、対応する Span は欠落します。
メッセージ送信の Span が表示されない場合は、プロデューサーアプリケーションのエージェントバージョンが 4.x 以降であるかどうかを確認してください。4.x より前のエージェントバージョンでは、メッセージを送信しても別の Span は生成されず、代わりに親 Span のメソッドスタック内に記録されます。親 Span の右側にあるアイコンをクリックすると、実際の呼び出しメソッドスタックを表示できます。
メッセージ受信の Span が表示されない場合は、[カスタム設定] タブの [インターフェイス呼び出し設定] セクションで [無効なインターフェイスフィルター] が有効になっているかどうかを確認してください。このオプションは、関心のない Span を除外します。

エージェントバージョン 4.x 以前と 4.x 以降で Kafka の応答時間に大きな差があるのはなぜですか？

問題: 応答時間が数秒から 0.x ミリ秒に変化しました。

原因:

エージェントバージョン 3.x 以前では、BatchMessageListener を処理する際に、メッセージのバッチが 1 回の呼び出しと見なされ、すべての期間が集約されていました。

エージェントバージョン 4.x 以降では、これらの操作は分離され、各メッセージが個別の呼び出しとしてカウントされます。したがって、エージェントバージョン 3.x から 4.x にアップグレードすると、1 回の呼び出しの期間が大幅に短縮され、呼び出しの数が大幅に増加することが予想されます。

バージョン 3.x の統計方法は合理的ではなく、バージョン 4.x では最適化されています。