著者: ヤハイ
これまでの記事を学習した後、ほとんどの学生は、リンク リクエストの軌跡のバックトラッキング、時間のかかるボトルネックの特定、コア インターフェイスのゴールデン 3 インジケーター アラームの設定、それらの即時検出など、分散リンク トラッキングの基本的な使用法を習得したはずです。異常; 大規模なプロモーションの前に、アプリケーションの上流と下流の主要な依存関係を整理し、関係者に連絡して準備を調整するなどします。リンク トレーシング テクノロジを徹底的に使用することで、問題を見つけて診断する能力が大幅に向上したはずです。
しかし、実際の製造プロセスでは、さらに困難な問題が発生する可能性があります。
たとえば、インターフェイスが時折タイムアウトになる場合、呼び出しチェーンはタイムアウトしたインターフェイスの名前のみを認識でき、内部メソッドは認識できないため、根本原因を特定できず、再現が困難になります。 ?
たとえば、インターフェイスの呼び出しは成功しましたが、ビジネス ステータスが異常で、予期しない結果が発生した場合、どのようにトラブルシューティングを行うか?
たとえば、大規模なプロモーションのストレス テスト中や変更のリリース後、CPU の水位が非常に高いことが判明した場合、アプリケーションのパフォーマンスのボトルネックを分析し、目標を絞った方法で最適化するにはどうすればよいでしょうか?
たとえば、同じコードをローカルで通常どおりデバッグできますが、オンライン環境にリリースするとエラーが報告されます。コードの動作が一貫しない原因を特定するにはどうすればよいでしょうか?
このような問題はリンク トラッキングのカテゴリに属していないようですが、リンク トラッキングと密接に関係しています。
リンク トラッキングは可観測性の不可分な部分です。境界を人為的に分割するのではなく、データ アイランドを破壊し、他の可観測技術を緊密に統合し、システムの安定性の向上を目指し、リンク トラッキングの関連性を最大化する必要があります。
このセクションの古典的なケースの解釈を通じて、リンク トレーシングと他の観察可能なテクノロジーを組み合わせるコツを習得し、リンク トレーシングに固有の認識を打ち破り、観察可能な分野におけるリンク トレーシングの関連する価値を深く理解できるようになります。
01 アプリケーションログの関連付け: 注文支払い失敗時のホログラフィック調査
[問題の説明]ある日、最前線の用事から顧客から苦情が届きました。注文の支払いが失敗しています。顧客は非常に不安なので、できるだけ早く返信する必要があります。苦情チケットには、支払いが失敗した注文番号 213589741238xxxx が記録されています。
[困難分析]注文支払いインターフェイスは複数の下流サービスに依存しており、インターフェイス呼び出し自体は成功しますが、ビジネス エラーにより支払い失敗が報告されます。さらに、注文番号を記録するのは注文センターのアプリケーション ログのみであり、下流のアプリケーション ログには注文番号情報がないため、注文番号からアプリケーション全体を直接スキャンすることは不可能です。
【解決策のアイデア】リンクトラッキングによる上流と下流のトレーサビリティを利用して情報連結を行います。
a. 失敗した注文番号を使用して注文センターのアプリケーション ログを取得し、ログ内で関連する TraceId を見つけます。
b. TraceId を使用してリンク全体の呼び出しトレースをクエリし、現在のリクエストが依存しているアップストリーム呼び出しとダウンストリーム呼び出しを見つけます。
c. 現在のリクエストに関連する上流および下流アプリケーションのアプリケーション ログを照会することにより、注文支払い失敗の原因が特定され、クーポンの無効化が原因であることが判明しました。
[拡張思考]上記のケースを通じて、ホログラフィック トラブルシューティングの前提は、TraceId とアプリケーション ログの双方向のバインディングを実現することであることがわかります。現在の業界の主流は、アプリケーション ログに TraceId を追加して関連付けを実現します。 。リンク多次元フィルタリングのセクションでは、ログ出力に TraceId を追加する 2 つの方法、SDK に基づいた手動埋め込みとログ テンプレートに基づいた自動埋め込みを紹介しました。興味のある学生は、関連する章の導入を詳細に読むことができます。
02 遅い呼び出しメソッド スタックの自動分析: 散発的な遅い呼び出しによって問題が発生するコード行を特定するにはどうすればよいですか?
[問題の説明]安定性を担当する学生は、このシナリオに精通している必要があります: システムは、夜間または時間ごとのプロモーション中にインターフェースがタイムアウトになることがあります。問題が見つかって確認すると、異常なシーンが失われており、困難です。回復するために さて、結局のところ、私たちはそれを手放すことしかできません。上記のシナリオは、障害が発生するまで繰り返され、その結果、巨額のビジネス損失が発生しました。
[困難さの分析]オープンソースのリンク トラッキング実装では、通常、タイムアウトしたインターフェイスのみを記録できますが、特定のメソッド スタックに絞り込むことができず、開発者はそれらを修正する方法がわかりません。時折発生する異常は不規則で再現が難しく、手動の jstack や Arthas などのオンライン診断ツールで根本原因を正確に特定することは困難です。
[解決策のアイデア]リンク追跡埋め込みポイントのコールバック関数を追加し、遅いリクエストのローカル メソッド スタックを自動的に記録し、コード実行の最初のシーンを真に復元します。以下の図に示すように、インターフェイス呼び出しが一定のしきい値（たとえば 2 秒）を超えると、遅いリクエストが存在するスレッドの監視が開始され、リクエストが終了するとすぐに監視が停止されます。リクエストのライフサイクルのスレッドは正確に予約されます スナップショットの設定と完全なメソッドのスタックの復元には時間がかかります 最終的な位置決めに時間がかかるのは主にリクエストのデータベース接続 getConnection メソッドで消費されます 応答が遅いという問題は次のようなことが考えられますデータベース接続の数を増やすことで解決できます。
[拡張された考え方]現在主流のオープンソース リンクの実装は、低速呼び出しメソッド スタックの自動分析をサポートしておらず、この機能をサポートしている商用製品はわずか (Alibaba Cloud ARMS など) です。完全なメソッド スタック情報を取得するには、従来のリンク インストルメンテーション (Instrument) はメソッド スタック モニタリングの取得には適していません。サンプリングはスタックの集約にのみ使用できます。ただし、グローバル サンプリングの高いオーバーヘッドは正規化を達成するのが難しく、自動モニタリングが必要です。リンク追跡および埋め込みポイントと組み合わせることで、スローコールのスレッドとライフサイクルを正確に特定し、低コストで正確かつ軽量のサンプリング監視を実現します。
03 高 CPU 使用率の「3 段階の調査方法」: 大規模なプロモーションの前夜に、圧力テストで CPU 水位が非常に高いことが判明しました。アプリケーション パフォーマンスのボトルネックを分析し、目標を絞った方法で最適化するにはどうすればよいですか?
【問題の内容】ダブルイレブン昇格前夜、同部門はコアアプリケーションのフルリンクストレステストを実施したが、シャオユウを担当する受注センターのCPU使用率は、初回のプロモーションで瞬く間に90％以上に上昇した。ストレス テストのトラフィック パルスの波、および多数のインターフェイス コール タイムアウトがリンク全体のパフォーマンスのボトルネックとなり、ストレス テストが急遽終了することになったため、監督者は彼女に 1 週間以内に最適化を完了するよう命じました。
[難易度分析] CPU 使用率が高くなる場合は、マシン リソースの不足や無理なコードが原因である可能性があります。基本的な CPU モニタリングでは問題を反映することしかできませんが、根本原因を特定することはできず、リソースとコード間のマッピング関係が欠如しているため、多くの学生はコードを簡単かつ直接的に最適化することができず、やみくもに容量を拡張することしかできません。
[解決策] Java アプリケーションを例に挙げると、ツールを使用して、CPU 使用率の上昇を引き起こす異常なコード部分を段階的に特定できます。主に次の 3 つのステップに分かれます。
a. CPU の基本モニタリングをチェックして、トラフィックのピークと CPU 使用率の上昇曲線が時間の経過とともに一致しているかどうか、CPU 使用率の増加の主な理由がユーザー モード CPU の増加であるかどうかを判断し、次のようなハードウェア要因を除外します。ホストの「売れすぎ」とディスク障害による干渉。
b. スレッドの分析と監視をチェックして、どのタイプのスレッド (プール) が最も多くの CPU を消費するか、またこのタイプのスレッドの CPU 時間消費曲線が CPU 使用率曲線と一致するかどうかを判断し、最初に異常なスレッド カテゴリを特定します。
c. CPU 診断ツールを使用して、異常期間中の CPU フレーム グラフを分析し、CPU 比率が最も高いメソッド コール スタックを特定し、目的の最適化を実行します。次の図に示すように、CPU の 99.7% を消費するメソッドは CPUPressure.runBusiness() メソッドです。
【拡張された思考】
- CPU 分析の難しさは、リソースとコード間のマッピング関係を示し、異常なコードの断片を直接特定し、研究開発の学生に最適化を導くことができる効果的なツールが不足していることです。さらに、診断動作は問題の発生よりも遅れることが多く、ツールには正常に実行し、異常なシーンを自動的に保存する機能が必要です。オンサイトのスナップショットの情報量とツール自体のリソースのオーバーヘッドをどのようにバランスさせるかは、製品設計と技術実装能力の試金石であり、多くの商用製品ではこの点で大きなギャップがあります。
- 特定のコア メソッドのコード ロジックが頻繁に変更され、パフォーマンスの低下を引き起こす可能性がある場合は、通常の監視用にリンク埋め込みポイントを追加することもできます。さらに、次の図に示すように、このメソッドに関連する CPU オーバーヘッドもコール チェーンに表示して、診断の効率を向上させることができます。
04 メモリ例外に対する「3 ステップのトラブルシューティング方法」: 頻繁に発生する FGC またはメモリ クラッシュの根本原因を特定し、サービスの可用性を確保するにはどうすればよいですか?
[問題の説明] FullGC は Java アプリケーションで最も一般的な問題の 1 つであり、オブジェクトの作成が速すぎる、大きなオブジェクトの割り当て、メモリ リークなどのさまざまな理由により FGC が発生します。FGC よりも深刻なのは、オフヒープ メモリ DirectBufferMemory の不当な使用などのメモリ クラッシュであり、OOM (OutOfMemoryError)、JVM クラッシュ、サービスの利用不能などの重大な結果につながる可能性があります。
【難易度分析】メモリ例外の原因は様々ですが、最も効果的な方法はメモリ例外のスナップショットを記録することです。しかし、メモリスナップショットの記録コストは非常に高く、定期的に自動的に保存することは困難です。実際に問題が発生した場合、記録するには遅すぎる可能性があり、記憶の診断が非常に困難になります。
[解決策のアイデア] Java アプリケーションを例に挙げ、ツールと組み合わせて、メモリ例外の原因を簡単なものから難しいものまで段階的に特定します。主に次の 3 つのステップに分かれます。
a. JVM 監視を確認し、新世代、旧世代、Metaspace、DirectBuffer などのメモリ変化を分析し、メモリ例外の種類を事前に特定し、メモリ リークが存在するかどうかを確認します。
b. 軽量メモリ診断により、異常時のメモリオブジェクト割り当てフレームグラフを分析し、最も多くのメモリを割り当てているメソッドを特定し、主要な分析を実行します。次の図に示すように、メモリの 99.92% は AllocMemoryAction.runBusiness() メソッドを通じて割り当てられます。
c. 大量のメモリが割り当てられても、大量の常駐メモリがあることを意味するわけではなく、ほとんどのオブジェクトは YGC によって解放される可能性があります。そのため、一部の難病では最終的な位置決めにHeapDumpを使用する必要があります。
[拡張思考]軽量メモリ診断は、JVM 監視と HeapDump の間の折衷的な方法であり、メモリ アプリケーション情報を正常に記録でき、ほとんどのシナリオで効果的に機能します。CPU 診断と同様に、コアメソッドがメモリに頻繁に適用される場合は、それにリンク埋め込みポイントを追加し、メモリアプリケーションや GC などの情報を関連付けて、コールチェーン情報の統合と診断効率を向上させることを検討できます。
05 ホワイト スクリーン オンライン診断: プログラムが期待どおりに実行されず、ローカルで正常にデバッグされたコードがオンラインでリリースされるとエラーが報告されます。
【問題の内容】ローカルデバッグを通過したコードをオンライン環境に公開すると、様々なエラーが報告されますが、何が問題なのでしょうか？開発学生はそんな悪夢を経験していると思います。この問題には多くの理由があります。たとえば、Maven は複数バージョンの競合に依存している、異なる環境の動的構成パラメータが一貫していない、異なる環境が異なるコンポーネントに依存している、ローカルでは実際のトラフィック パラメータやオンラインの圧力をシミュレートできないなどです。環境など
[難易度分析]ローカル、毎日、プレリリース、実稼働、異なる環境間では常に何らかの形で何らかの違いがあり、その結果、同じコード内で異なる動作や例外が発生するため、現在の環境で診断して特定する必要があります。従来のリモート デバッグ モードは操作が複雑で、セキュリティ リスクが高くなります。ただし、Arthas のようなスタンドアロン診断ツールは、黒い画面でのログインとコマンド ラインでの操作が必要であり、使用が面倒です。
[解決策] APM プローブにはオンライン診断モジュールが組み込まれており、コンソールを介して白画面の対話が実行され、診断シナリオに従ってコマンドがカプセル化されるため、運用コストがさらに簡素化されます。たとえば、コール チェーンを通じて異常な呼び出しのフル パス クラス名とメソッドを見つけた後、ソース コードの解析、メソッドの入口および出口パラメータのインターセプトなどの従来の診断コマンドを実行し、ソース コード、入口および出口パラメータを表示します。 、実行メソッドのスタックと時間のかかる現在のプログラムの実行状態をリアルタイムで把握し、静的オブジェクトまたは動的インスタンスの値などを確認できるため、オンライン デバッグがローカル デバッグと同じくらい便利になり、ワンクリックで遅いエラーの根本原因を特定できます。 。
【拡張思考】白い画面はオンライン診断最適化の第一歩に過ぎない 診断コストとリスクをさらに削減する方法、スタンドアロン診断からクラスター診断へ、アクティブ診断から自動トリガー診断へ、特定診断から診断へアップグレードする方法言語 (Java など) すべての言語をカバーするには、新しいテクノロジーと製品をさらに繰り返す必要があります。
06 探索的リンク分析と監視: 1 秒バトル、イングレス リクエストに対する応答が遅いという問題を正常化するにはどうすればよいですか?
[問題の説明] Ingress リクエストの応答遅延は、エンドユーザー エクスペリエンスに直接影響します。Google の統計によると、遅延が 500 ミリ秒増加するごとに、トラフィックの 20% が失われます。1% の遅延は、売上は1%減少。したがって、多くの企業 IT サービスは、エンドユーザーのアクセスにできるだけ早く応答できるようにするために、厳格なイングレス サービス応答遅延 SLA を策定します。ただし、レイテンシに影響を与える要因は数多くあります。不均一なトラフィック、スタンドアロン障害、プログラム例外、依存コンポーネントのボトルネックは、受信リクエストのレイテンシに大きな影響を与えます。低コストで正規化して管理するにはどうすればよいでしょうか?
【分析の難しさ】企業やサービスの種類ごとにレイテンシに対する要件が異なり、レイテンシに影響を与える次元特性も多岐にわたるため、オープンソースや商用製品に組み込まれている基本的な監視だけでは遅いリクエストを選別して分析することは困難です。詳細なデータに基づく分析は柔軟性が高いものの、完全取得のコストが比較的高く、分析ルールが多い場合、正規化された監視や警報には適しておらず、遅延劣化のリスクを積極的に通知することができません。
[解決策]ユーザー定義のクエリと分析の要求に柔軟に対応できるだけでなく、ユーザー分析ルールを強化し、カスタム リンク インジケーターを生成し、正規化を実現できるリンク分析と監視機能を組み合わせる必要があります。
a. TraceExplorerを利用してリンク詳細データのオンラインスクリーニング・分析を行うと、図のように特定のポータルアプリケーションの3秒を超える低速リクエストがどのインターフェースに分散しているかを確認するなど、ビジネスニーズに応じてさまざまな条件を柔軟に設定できます。下の図のとおりです。
b. セットアップしたばかりのクエリ分析ルールを保存すると、その後のワンクリックでの迅速な分析に便利です。ただし、このステップはまだリンクの詳細データに基づいており、分析コストが比較的高く、結果の精度はリンク データのサンプリング レートに大きく依存するため、通常の監視や警報には適していません。
c. 低コストで正規化された監視と警報を実現するために、クエリ分析ルールをプッシュダウンして、データ処理側で新しいカスタム リンク インジケーター (事前集計) を生成することもできます。
[拡張思考]実際の運用環境では、サービスは通常標準化されていますが、サービスは分類され、等級付けされる必要があります。同じ注文サービスでも、カテゴリ、チャネル、ユーザーなどの次元に応じて分類してカウントし、洗練されたオペレーションを実現する必要があります。たとえば、オフライン小売チャネルの場合、すべての注文とすべての POS マシンの安定性が世論を引き起こす可能性があり、オフライン チャネルの SLA 要件はオンライン チャネルの SLA 要件よりもはるかに高くなります。では、一般的な電子商取引サービス システムにおけるオフライン小売リンクのトラフィック状況とサービス品質を正確に監視するにはどうすればよいでしょうか? 答えは、リンク データのカスタム タグ属性にあります。たとえば、オフライン注文の Ingress サービスに {"attributes.channel": "offline"} タグを配置し、さまざまな店舗、ユーザー グループ、製品カテゴリをターゲットにします。別々にマークされています。最後に、attributs.channel = offline をフィルタリングし、さまざまなビジネス タグをグループ化して通話数、時間のかかるエラー率、その他の指標をカウントすることで、各タイプのビジネス シナリオのトラフィック傾向とサービスの品質を迅速に分析できます。
07 インテリジェントな根本原因の特定: 初心者が「専門家レベル」の診断機能を利用して、古典的な問題の根本原因を迅速に特定できるようにするにはどうすればよいですか?
【問題の内容】 オンライン申請のリスクは主に「間違っている」と「遅い」の2つに分類されます。「エラー」の理由は通常、JVM が間違ったバージョンのクラス インスタンスをロードしたり、コードが異常なブランチに入ったり、環境構成エラーなど、プログラムが期待どおりに実行されないことです。「遅さ」の理由は通常、リソース不足です。たとえば、突然のトラフィックによって CPU がいっぱいになったり、マイクロサービスやデータベースのスレッド プールが使い果たされたり、メモリ リークによって継続的な FGC が発生したりすることが考えられます。それが「間違った」問題であっても、「遅い」問題であっても。ユーザーの観点から見ると、ユーザーは皆、根本原因を迅速に特定し、損失を時間内に阻止し、隠れた危険を排除することを望んでいます。ただし、オンラインの問題の大部分は、リンク追跡の基本機能だけでは効果的に特定して解決することはできません。リソース監視、コード診断、その他の機能と組み合わせる必要があります。調査者の経験と能力は非常に高いです。多くの学生はすぐに「専門家レベル」の診断能力を身につけますか?
[困難分析]誤った運用および保守アクションは、広範囲にわたる可用性障害を引き起こす可能性があります。オンライン環境の低い耐障害性と高い適時性により、根本原因の特定の精度と速度に対する高い要件が求められます。したがって、多くの確率ベースの機械学習アルゴリズムは、運用および保守の分野には適していません。また、豊富な経験と能力を備えた診断士は、多くの時間の蓄積と症例の「フィード」が必要であり、インターネットの急速な普及を背景に、このような人材を育成できる企業は限られており、すぐに真似することはできません。バッチで。
[ソリューションのアイデア]オンライン アプリケーションのリスクには一定の兆候があります。一般的な古典的な問題については、ドメイン専門家の経験とより成熟したアルゴリズムを組み合わせて、根本原因の自動特定や古典的な問題の境界設定を実現し、診断効率を向上させることができます。しきい値を下げる診断のために。たとえば、最初にタイミング異常検出アルゴリズムを使用して、アプリケーション A の時間のかかるインターフェイスの突然の増加を特定し、アプリケーション A のリソースをチェックしてボトルネックが見つからないことを確認します。次に、注文インターフェイスの依存サービスをチェックします。ダウンストリーム インターフェイスの時間が突然増加していることを確認し、段階的に追跡します。最終的に、C アプリケーションの 2 台のマシンの CPU 使用率が高すぎて 95% 以上に達し、C アプリケーションの CPU 使用率が高すぎることが判明しました。緊急拡張後にアプリケーションが復旧しました。
[拡張思考]運用保守分野における古典的な問題の根本原因を特定するには、この段階では専門家の経験を主な方法として使用し、アルゴリズムを補助的な方法として使用することがより適しています。したがって、盲目的に「優れた」アルゴリズムを追求するのではなく、実用性を重視し、データの完全性と豊富さを優先する必要があります。
08 まとめ
リンク トラッキング (Trace) の最大の価値は、アプリケーション ログ (Log)、主要なイベント (Event)、パフォーマンス インジケーター (メトリクス)、または診断ツール (プロファイリング) をデータ レベルで関連付けたり、ユーザーを関連付けたりする「相関関係」にあります。システム レベルから 端末、ゲートウェイ、アプリケーション、ミドルウェア、コンテナ、およびインフラストラクチャにとって、リンク トラッキングの最大の価値はそれ自体ではなく、相関関係の文脈化されたプレゼンテーションにあります。さらに価値のある興味深い使用法を引き続き探索してみましょう。バー!