Application Real-Time Monitoring Service:提供されるサービス

インターフェイス詳細ページの [アップストリーム] タブには何が表示されますか？

インターフェイス詳細ページの [アップストリーム] タブには、現在のアプリケーションを呼び出し、ARMS エージェントによって監視されているアップストリームサービスに関する詳細が表示されます。アプリケーションが自身を呼び出す場合、[アップストリーム] タブにもアップストリームサービスとして表示されます。

一部のインターフェイスのアップストリームサービスが [アップストリーム] タブに表示されないのはなぜですか？

アップストリームサービスが ARMS エージェントによって監視されていない場合、[アップストリーム] タブには表示されません。

アップストリームおよびダウンストリームのサービスデータが乱れているのはなぜですか？

デフォルトでは、トレースに SkyWalking コンポーネントがインストールされている場合、SkyWalking はトレース全体のトレースプロトコルと見なされます。v4.2.x より前の ARMS エージェントは SkyWalking プロトコルと完全には互換性がないため、アップストリームおよびダウンストリームサービスの認識エラーが発生します。エージェントを v4.2.x 以降にアップグレードするか、[カスタム構成] ページの [コールチェーンパススループロトコル設定] セクションで伝播用のプロトコルを構成できます。詳細については、「トレースコンテキスト伝播プロトコル設定」をご参照ください。

エラー呼び出しのトレースが欠落しているのはなぜですか？

v3.2.x より前の ARMS エージェントは、Dubbo トレースのステータスコードを正しく記録しない場合があります。ARMS エージェント 3.2.x 以降ではこの問題が修正されています。

異常な呼び出しのトレースが欠落しているのはなぜですか？

v4.1.x より前の ARMS エージェントは、エラー呼び出しと低速呼び出しのトレースのみを記録し、異常な呼び出しのトレースは記録しません。一方、ARMS エージェント v4.1.x 以降は、低速、異常、およびエラー呼び出しのトレースを記録します。

インターフェイスのトラフィックが減少したのはなぜですか？

インターフェイスのトラフィックが実際に減少したかどうかを判断します。これは、報告された減少が発生する前後に CPU 使用率やネットワーク I/O などのメトリックで同時に変更が発生するかどうかを調べることで評価できます。

• インターフェイスのトラフィックが実際に減少した場合、それはサービストラフィックの減少が原因です。

• インターフェイスのトラフィックが減少しなかった場合、ARMS サーバーでエラーが発生した可能性があります。チケットを送信することをお勧めします。

Spring Cloud Gateway のトラフィックデータが正しくないのはなぜですか？

v4.x より前の ARMS エージェントには、Spring Cloud Gateway のイベントトラッキングに不備があります。エージェントを v4.x にアップグレードすることをお勧めします。

インターフェイスの低速 SQL 文をクエリするにはどうすればよいですか？

次の操作を実行します。

古いコンソールの [インターフェイス呼び出し] ページにある 2 つのインターフェイス間の黄色のドットは何を意味しますか？

ポインターをドットの上に移動してプロンプトを確認します。

• 黄色のドットは低速呼び出しを示します。デフォルトでは、500 ミリ秒以上かかる呼び出しは低速呼び出しとして識別されます。[カスタム構成] ページの [インターフェイス呼び出し構成] セクションで期間のしきい値を変更できます。

• 赤いドットはエラー呼び出しを示します。

一部の 5xx ステータスコードデータが収集されないのはなぜですか？

RFC7231 によると、502 や 504 などのステータスコードはゲートウェイによって発行されるエラーコードです。これらのステータスコードは、それが呼び出すサービスの実際の応答コードを反映していない可能性があります。ゲートウェイに接続されているサービスのみが ARMS エージェントによって監視され、ゲートウェイ自体は監視されていないシナリオでは、ゲートウェイによって生成された 5xx 応答は追跡も報告もされません。

「NetWork And Dubbo Response Decode」とは何ですか？

これは、Dubbo トランスポートレイヤーでの逆シリアル化にかかる時間をカウントするために使用されるスパンです。

インターフェイス名に * や ARMS キーワードなどの文字が含まれるのはなぜですか？

インターフェイス名は発散するため、ARMS は類似のインターフェイスの異なる部分を置き換えることでそれらを収束させます。詳細については、「ARMS 収束ポリシー」をご参照ください。

外部インターフェイスの呼び出し期間とダウンストリームサービスの期間が異なるのはなぜですか？

サーバー側の処理時間とは、インターフェイスがリクエストを受信してからサーバーがリクエストを処理するまでにかかる期間を指します。一方、クライアント側の処理時間は、リクエストが開始された時点から測定され、接続確立とネットワーク遅延のための追加時間を含みます。ARMS コンソールは、リクエストを処理するためのサーバー側の処理時間と、リクエストが開始された時点からの合計クライアント側時間を個別に表示します。ただし、ネットワーク関連の遅延を正確に特定することはできません。

通常のインターフェイス呼び出しの例外数が 0 より大きいのはなぜですか？

例外は、特定のフレームワーク (OkHttp3 など) によって内部的にスローされ、フレームワーク自体によって外部的にキャッチされました。したがって、ビジネスロジックは影響を受けませんでした。ARMS はこのフレームワークにイベントトラッキングを実装しているため、これらの例外の詳細も記録しました。これは、ビジネス運用に実際の問題があることを示すものではありません。これらの例外に何らかのアクションや修正が必要かどうかを評価できます。例外統計では、例外のメッセージ情報は無視されます。特定の例外のメッセージ情報を表示したい場合は、対応するトレースをクリックし、インターフェイスの右側にある アイコンをクリックして、メソッドスタック内の例外情報を表示できます。

一部のインターフェイス名が /error、/404、/*、/** となるのはなぜですか？

これは、ARMS が次の予期しないリクエストに対して適切なルートを見つけられなかったためです。

• 存在しない URL がリクエストされました。

• リクエストヘッダーが無効であったため、リクエスト検証に失敗した場合にエラーが報告されます。たとえば、ヘッダーに無効な文字が含まれていた場合などです。

• Netty などのルーティング構成のない HTTP サーバーが使用されました。

[提供されるサービス] タブに表示される呼び出し数が [トレースエクスプローラー] タブに表示される数と異なるのはなぜですか？

トレースエクスプローラーによって提供されるデータは、サンプリングされたトレースデータに基づいて計算され、サンプリングレートによって異なります。

[提供されるサービス] タブに表示される期間の分位数と [トレースエクスプローラー] タブに表示される分位数が異なるのはなぜですか？

提供サービスタブの分位数は、バケット化に基づいてマシンごとに計算されます。一方、Trace Explorer が提供する分位数は、サンプリング後のインターフェイスに関連するスパンの期間に基づいて計算されます。詳細については、「ARMS メトリック分位数の計算」をご参照ください。

インターフェイスの呼び出しが約 2 倍に増加したのはなぜですか？

これは、一部のインターフェイス呼び出しが呼び出されたときに、ARMS エージェント v3.x と ARMS エージェント v4.x の両方がアプリケーションにインストールされていたためです。[アプリケーション構成] > [エージェント管理] ページに移動し、任意のエージェントを選択して [詳細を表示] をクリックすると、JVM パラメーターを表示できます。

次の図に示すように、2 つの -javaagent パラメーターが存在します。これは、ARMS エージェント v3.x と ARMS エージェント v4.x の両方がインストールされていることを示します。

ARMS コンソールでの呼び出し数がサードパーティの可観測性ツールによって提供される数と一致しないのはなぜですか？

これはさまざまなシナリオで発生する可能性があります。例:

• ARMS によって計算されたアプリケーションの 1 分あたりのインターフェイス呼び出し数が 500 で、NGINX によって計算された数が 200 であるとします。一般に、これはトラフィックが NGINX をバイパスしてアプリケーションに直接アクセスすることが原因である可能性が最も高いです。

• アプリケーションが 1 分あたりにデータベースにアクセスする回数が 400 回で、データベースでの 1 分あたりの実行回数が 1,000 回であるとします。通常、データベースは複数のアプリケーションからアクセスされます。ARMS コンソールでは、特定のアプリケーションのページビューしか表示できません。

ARMS は Spring WebFlux をどのようにサポートしますか？

v4.x より前の ARMS エージェントは、ネイティブの Spring WebFlux と Spring Cloud Gateway のみをサポートします。Apache ShenYu など、カスタム Web ハンドラを使用して変更された WebFlux 関連のプラグインはサポートされていません。

アップストリームに自分のものではないアプリケーションが表示され、詳細情報を表示するためにナビゲートできないのはなぜですか？

アプリケーションが外部にサービスを提供している場合、これは正常です。アップストリームアプリケーションは別のユーザーに属しており、ユーザー間の呼び出し関係があることを意味します。この場合、ARMS はアップストリームアプリケーションのアプリケーション名とこのインターフェイスへの呼び出し数を記録しますが、ユーザー情報の隔離制限により、別のユーザーのアプリケーションの詳細を表示することはできません。

アプリケーション間に明確なアップストリームとダウンストリームの呼び出し関係があるのに、インターフェイスのアップストリームとダウンストリームで期待されるデータが表示されないのはなぜですか？

ARMS はまずユーザーの呼び出しトレースをランダムにチェックし、LocalRootSpan に記録されている trace.protocol.type フィールドに注目します。フィールド値が Jager の場合、大文字と小文字の変換の問題により、アップストリームとダウンストリームの認識に失敗します。この問題が発生した場合は、「別のプロトコルに切り替える」か、チケットを送信して解決してください。