低速コールチェーン診断ツール - ARMS コードのホットスポット

著者：チェン・プー、イー・ボー

目に見える技術背景

「Dapper、大規模分散システムトレースインフラストラクチャ」と呼ばれる Google によって発行された最初の論文から始まり、その後、メトリクス (インジケーター)、トレーシング (リンクトラッキング)、ロギング (ログ) という 3 つの主要な方向に進化しました。徐々に業界に受け入れられ、事実上の標準になりつつあります。

上記のフルスタックの監視可能なソリューションテクノロジに基づいて、問題の診断は、開始できない、またはログのみに依存するものから、次の手順に変わりました。

メトリクス/ログによって提供されるさまざまな事前設定アラームを通じて、アプリケーションの異常情報を検出し、異常なモジュールを特定します。
例外モジュールと関連ログ (ログ) をクエリおよび分析して、コアエラー情報を見つけます。
詳細なコールチェーンデータ (トレース) を通じて、問題の原因となっているコードフラグメントを特定します。

前述の一連の観察可能なソリューションに基づいて、問題が発生した後に問題を迅速に特定し、損失をタイムリーに削減できるだけでなく、多くの場合、重大な障害が発生する前に問題を発見し、事前に修復することができます。

死角の監視

上記の一連の観察可能なソリューションに基づいて、すべてのオンライン監視の問題を完全に解決できるでしょうか? 実際、これは、特にトレースの点では当てはまりません。これは、一般に、HTTP サービス、RPC サービス、データベース、分散メッセージなどの主流のソフトウェア開発フレームワークからコールチェーンモニタリングデータを収集する Java エージェント/SDK 技術ソリューションに基づいているためです。その後、後続のコールチェーンデータ復元処理ロジックによって監視情報が特定のリクエストに関連付けられるため、リクエストで例外が発生したときに、収集された監視データを通じて関連するコール情報を確認できるようになります。リクエストが通過するコアリンクメソッドを提供することに加えて、コールチェーンには、コールチェーン内で遅くて時間のかかる場所を特定し、コードの最適化を支援する別のコア機能もあります。次の図に示すように、特定のトラブルシューティングプロセスを使用すると、呼び出しチェーンの詳細情報を通じて、呼び出しチェーン内の時間のかかるボトルネックロジックを診断できます。

上の図に示すように、呼び出しチェーンはトレースとして機能し、一意の TraceId を持ちます。トレースには複数のスパンが含まれており、それぞれが複数のダウンストリームサービスへの呼び出しを表し、それぞれに対応する SpanId 情報があります。上図から、リクエストが通過する複数のサービスで発生する時間のかかる状況を知ることができます (1 つのダウンストリームサービスが 1 つのスパンに対応すると想定されており、一部のリンク追跡システムは異なる場合があります)。それによってアプリケーション時間に影響します。 -消費ボトルネックを特定し、対応するパフォーマンスの最適化を実行します。

ただし、分散マイクロサービスの分野では、クロスマシンまたはクロスマシンルームを含む呼び出しリンクの複雑さのため、一般的なトレースシステムは主流のオープンソースソフトウェアフレームワークにコアメソッドしか埋め込むことができないため、時間のかかる箇所がトレースに表示される埋め込みポイントが見つからないユーザービジネスロジックを使用する場合、最終的な呼び出しチェーンに特定のコードの実行方法に対応できない時間がかかり、正確に判断できなくなります。ビジネスロジックには時間がかかります。

特定のケースは次のコードで見ることができます。

public String demo() throws SQLException {

    // 此处耗时1000ms，模拟其他业务耗时逻辑
    take1000ms(1000);
    // SQL 查询执行操作
    stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery("SELECT * FROM table");

    return "Hello ARMS!";
}

private void take1000ms(long time) {
  try {
    Thread.sleep(time);
  } catch (InterruptedException e) {
    e.printStackTrace();
  }
}

上記のコードロジックの 6 行目から 7 行目は、データベース接続に関連する実行ロジックです。このタイプのロジックは、一般に主流のトレースシステムでカバーされています。ただし、4 行目の特定の顧客の営業時間は、通常、欠落している部分に対応します。監視ポイントは次のとおりです。埋め込まれているため、消費時間は最終的に前のレイヤーエントリの Spring Boot メソッドデモでカウントされます。

トレーシング呼び出しチェーンの対応する最終表示形式は、次の図のようになります。トレーシング呼び出しチェーンを通じて、最初の層の外部インターフェイスの消費時間と、よく知られたソフトウェアフレームワークの実行ロジックの消費時間のみが含まれます。その中で、グレーの網掛け部分は、トレースシステムでカバーされていないユーザーのビジネスロジックコードが監視の盲点として使用されていることがわかりますが、実際にどのくらいの時間がかかるかは不明であり、オンラインのトラブルシューティングに多くの障害を引き起こしています。パフォーマンスの問題:

上記の問題は企業ユーザーの間で非常に一般的であり、多くの場合、ため息をつき、無力感を覚えるだけです。

解決

トレースシステムが欠落している場合の低速コールチェーンの診断に時間がかかるという問題については、著者の知る限り、現在、業界には関連するソリューションがほとんどありません。Arthas に詳しい学生なら、trace コマンドについて言及するかもしれません[ 1]。安定して再現できるいくつかの単純なシーンの低速コールチェーンにおいて、低速コールチェーンの時間のかかる特定の場所を手動で確認することは、ある程度可能です。しかし、その限界も明らかです。

限られた範囲

安定した再現可能なシナリオでのみ低速呼び出しの診断をサポートします。ガベージコレクション、リソースの競合、ネットワークの問題など、再現が困難なシナリオでの低速呼び出しの問題のトラブルシューティングは困難です。
使用の敷居が高い

実際の運用シナリオでは、呼び出しチェーンは非常に複雑になる可能性があります。ビジネスコードに精通している必要がある場合は、特定のビジネスメソッドでトレースコマンドを手動で実行して、リクエスト時間を監視できます。ビジネスメソッドに精通していない場合は、一部の複雑な非同期呼び出しシナリオのトラブルシューティングにこのツールを使用するのは困難です。
高額な調査費用

確かに、このツールは単純なシングルホップビジネスシナリオでは遅い呼び出しのトラブルシューティングに使用できますが、複雑なアプリケーション間マルチホップビジネスシナリオでは、トラブルシューティングプロセスが非常に面倒になります。特定の遅い呼び出しが存在するアプリケーションインスタンスを見つけるためにいくつかの APM ツールを使用する必要があるだけでなく、ビジネスコールメソッドスタックが非常に深いシナリオでは、関連するコマンドをレイヤーごとに実行し、段階的に監視する必要があります。問題の原因を見つけるステップ。

要約すると、Arthas のトレースコマンドは、一部の単純な低速呼び出しシナリオでは使用できますが、複雑なシナリオで低速呼び出しチェーンのトラブルシューティングを行うには不十分です。

この目的を達成するために、Alibaba Cloud ARMS チームと Alibaba Dragonwell チームは、ユーザーが継続分析テクノロジーを通じてコールチェーンメソッドスタック情報をより適切に復元し、この種のトレース監視の盲点問題をより適切に解決できるよう支援します。

ARMSの継続分析機能

中国でよく知られた APM ツールとして、ARMS は、トレース、メトリクス、ロギング関連ビジネス向けに主流の監視可能なソリューションを提供するだけでなく、すぐに使える継続的プロファイリングソリューション (継続的プロファイリング、CP) も提供します。継続的プロファイリングは、CPU/メモリやその他のリソースなどのアプリケーションのスタック情報をリアルタイムで動的に収集することで、アプリケーションのパフォーマンスのボトルネックを監視し、特定するのに役立ちます。ARMS が現在提供している継続分析機能のアーキテクチャを次の図に示します。

クライアント側では、Java エージェントテクノロジにより、他の監視可能な機能に基づいて継続的な分析およびデータ収集機能が非侵襲的に提供されます。次に、収集されたデータはサーバー側で分析および処理され、最終的にコンソールは、CPU 診断、メモリ診断、コードホットスポット機能などのすぐに使用できる機能をユーザーに提供します。

CPUとメモリの診断

フレームグラフは、アプリケーションのパフォーマンス問題のトラブルシューティングを行ったことのある多くの読者にはよく知られているもので、フレームグラフの上部に広い部分があるかどうかを観察することで、アプリケーションのパフォーマンスの問題を特定できます。多くの開発者にとって、上記のフレームグラフは通常、CPU ホットスポットのフレームグラフを指します。これは、一定期間内にアプリケーションの CPU によって実行されたメソッドの時間のかかる状況を表します。ARMSが提供するCPU&メモリ診断機能は、オープンソースの継続プロファイリングAsync Profiler [ 2]をベースとしており、アプリケーションのCPUやメモリのアプリケーションメソッドスタック情報を低オーバーヘッド条件で正常に収集し、簡易かつ効率的な通常監視をサポートします。本番シナリオのアプリケーションの CPU とメモリアプリケーションのステータス、オープンソースツールを使用してアプリケーションを定期的に開くことが困難で、再現が容易ではない問題シナリオを見逃しがちな状況に別れを告げます。

コードのホットスポット

CPU とメモリの診断について話した後、読者の中には、CPU 診断に対応するメソッドスタックフレームグラフを使用して、システム監視の盲点を追跡する問題を解決したり、遅いコールチェーンのトラブルシューティングに役立てることができるのではないかと疑問に思う人もいるかもしれません。答えは否定的です！CPU診断とは、CPU上で実行される実行スレッドのメソッドスタック情報を定期的に取得し、フレームグラフに変換するものだからです。

ソフトウェアプログラムのスレッドステータスには、CPU 上で実行される実行状態 (オン CPU とも呼ばれます) に加えて、ブロック状態や待機中 (総称してオフ CPU と呼ばれます) などの他の状態もあり、低速な呼び出しチェーンには複数の状態が存在することがよくあります。オーバーレイにより、最終的なプレゼンテーションに時間がかかります。したがって、CPU フレームグラフは、呼び出しチェーンが遅いシナリオに対しては限定的な影響を与えます。

では、オン CPU だけでなくオフ CPU コンテンツも含めることができるフレームグラフテクノロジはあるのでしょうか? 次に、壁掛け時計のフレームチャート (Wall Clock) について触れなければなりません。実装原理は複雑ではなく、アプリケーションの全スレッドの中から一定の頻度でスレッド群を選択し、現時点でのメソッドスタック情報を収集し、集計処理により対応するフレームグラフを描画するというものです。Async Profiler は関連機能も提供します。

この記事のメインコードホットスポットは、オープンソースの Async Profiler のウォールクロック機能に基づいており、呼び出しチェーン内の TraceId と SpanId 情報を関連付けることにより、呼び出しチェーンレベルでオン CPU およびオフ CPU のフレームグラフを提供します。 Tracing の盲点の詳細を効果的に監視し、一般的な遅いコールチェーンのさまざまな問題を復元し、ユーザーが診断できるようにします。具体的な処理は下図のとおりで、スレッド作成Spanの開始時と終了時にTraceIdとSpanId情報の関連付けまたは解除を行うことで、最終的に生成されるウォールクロックメソッドスタックのスナップショットサンプルに関連情報が含まれ、その後最終的な連続データの分析対応するコールチェーンに関連するウォールクロックフレームグラフを処理および分析し、復元して、コールチェーンが遅い問題を特定するのに役立ちます。

コア機能

ARMS によって現在提供されている継続分析機能には、他の低速コールチェーン診断ツールやオープンソースの継続分析ツールと比較して、次の特徴があります。

低いオーバーヘッド

Trace プロセスに基づく自動サンプリングや、関連するサンプリングレートに基づく実時間分析などの手段により、ARMS が提供する現在の継続分析製品の機能は、CPU オーバーヘッドが 5%、オフヒープメモリオーバーヘッドが約 50M です。追加のオーバーヘッドは明らかではないため、運用環境では通常どおり使用できます。
細かい粒度

アプリケーションレベルの CPU とメモリのホットスポットに加えて、TraceId と SpanId 情報を関連付けることにより、コールチェーンレベルのメソッドスタック情報も提供します。これは、遅いコールチェーンの問題の診断に効果的に役立ちます。
安全、信頼性が高く、シンプルかつ効率的

Arthas を使用して CPU フレームグラフを生成する (最下層も Async Profiler に依存する) など、一部のオープンソースの連続プロファイリングテクノロジは、通常、使用後にオンまたはオフになるため、技術的なリスクがあったとしても、それらを見つけるのは簡単ではありません。。製品開発プロセス中に、継続的なプロファイリングプロセスでの Async Profiler などのオープンソーステクノロジの使用における多くのリスクの問題が依然として見つかりました。たとえば、メモリプロファイリングはアプリケーションのクラッシュを引き起こす可能性があります #694 [ 3]、壁時計のフレームグラフはスレッドが長時間ブロックされる可能性があります #769 [ 4]など。これらの問題を解決することで、当社の製品機能の安全性と信頼性が向上します。セキュリティに加えて、ARMS が提供する継続分析機能は、通常にオンになってから 7 日間データを自動的に保存するため、ユーザーはあらゆる低速コールチェーンの診断サイトを見逃すことがありません。

コードホットスポットを使用して遅い呼び出しチェーンをトラブルシューティングする

コードホットスポットをオンにする

ARMS コンソールにログインし、左側のナビゲーションバーで [アプリケーション監視] > [アプリケーションリスト] を選択します。
アプリケーションリストページの上部で対象のリージョンを選択し、対象のアプリケーション名をクリックします。
左側のナビゲーションバーで[アプリケーション設定]をクリックし、[カスタム構成]タブをクリックします。
CPU およびメモリホットスポットマスタースイッチをオンにした後、コードホットスポットスイッチをオンにし、有効にするアプリケーションインスタンスの IP アドレス、またはインスタンスのグループが属するネットワークセグメントアドレスを構成します。
ページの下部にある「保存」をクリックします。

インターフェイス呼び出しを通じてコードホットスポットデータを表示する

ARMS コンソールにログインし、左側のナビゲーションバーで [アプリケーション監視] > [アプリケーションリスト] を選択します。
アプリケーションリストページの上部で対象のリージョンを選択し、対象のアプリケーション名をクリックします。
左側のナビゲーションバーで[インターフェイスコール]をクリックし、ページの右側でターゲットインターフェイスを選択して、[コールチェーンクエリ]タブをクリックします。
コールチェーンクエリタブでターゲットの TraceId リンクをクリックします。
詳細列の虫眼鏡アイコンをクリックします。まず、メソッドスタックタブをクリックして、トレースツールを使用して表示されるメソッドスタック情報を確認します。これには、MariaDB 関連の実行ロジックのみが含まれていることがわかります。 -end business 経過時間は記録されません。

次に、[コードホットスポット]タブをクリックすると、右側のフレームグラフに、MariaDB 関連のメソッドスタック (下図の右側のフレームグラフの右端の鋭いフレームに相当します) に加えて、 Thread.sleep() に関連する 990 ミリ秒の時間消費 (サンプリングに基づいてスレッドメソッドスタックを取得するための継続的な分析のため、多少の誤差が生じる可能性があります)。

図の左側は、この呼び出しに関与するすべてのメソッドの時間のかかるリストであり、右側は、対応するメソッドのすべてのメソッドスタック情報を使用して描画されたフレームグラフです。このうち、Self 列には、メソッド自体の消費時間が表示されます。特定のホットコードロジックのトラブルシューティングを行うには、[自己] 列に焦点を当てるか、右側のフレームグラフの下部にある広範囲のフレームを直接確認することで、非常に時間のかかるビジネスメソッドを特定できます。上の図の java.lang.Thread.sleep() メソッドなど、上位層での高い時間の消費、一般にシステムパフォーマンスのボトルネック。使用法の詳細については、この機能に関連するユーザードキュメントを参照してください[ 5]。

関連リンク：

[1] トレースコマンド

https://arthas.aliyun.com/en/doc/trace.html

[2] 非同期プロファイラー

https://github.com/async-profiler/async-profiler

[3] #694

https://github.com/async-profiler/async-profiler/issues/694

[4]#769

https://github.com/async-profiler/async-profiler/issues/769

[5] ユーザードキュメント

https://help.aliyun.com/zh/arms/application-monitoring/user-guide/use-code-hotspots-to-diagnose-code-level-problems?spm=a2c4g.11186623.0.i3