Dewu クラウドネイティブ フルリンク トラッキング Trace2.0 コレクション

0xcc の紹介

2020年3月、Dewu技術チームは3か月で取引システム全体の再構築を完了し、Wucai Stoneプロジェクトを納品し、ビジネスシステムはマイクロサービス時代に入りました。システム サービスが分割されると、各サービスにはそれぞれの職務を遂行する異なるチームが存在するようになりますが、サービス間の依存関係はより複雑になり、サービス ガバナンスなどの関連インフラストラクチャに対する要件も高くなります。

サービスの監視は、サービスのガバナンスと安定性の構築において重要な部分です。問題を早期に検出し、システムの水位を推定し、障害を分析することなどに役立ちます。 2019 年末から現在に至るまで、Dewu のアプリケーション サービス監視システムは 3 つの主要な進化段階を経てきました。現在、Dewu アプリケーション マイクロサービス監視システム全体が、クラウド ネイティブの可観測性テクノロジー OpenTelemetry と完全に統合されています。

過去10年を振り返ると、アプリケーションサービス監視業界の競争は熾烈で、2012年にTwitterがオープンソース化したZipkin、韓国最大の検索エンジン兼ポータルであるNaverがオープンソース化したPinpoint、近年Uberがオープンソース化したJaeger、中国のWu Shengがオープンソース化したSkyWalkingなど、関連製品が雨後の筍のように登場してきました。

実は、これらすべては、Google が社内の大規模分散リンク追跡システム Dapper の実践に基づいて 2010 年に公開した論文によるものだと言う人もいます。その設計コンセプトは、すべての分散型コール チェーン追跡システムの祖先です。しかし、実は20年前（2002年）には、当時世界最大の電子商取引プラットフォームであったeBayに、コールチェーン追跡システムCAL（Centralized Application Logging）がすでに導入されていました。 2011年、eBayの中国R&DセンターのシニアアーキテクトであるWu Qimin氏がDianping.comに移り、CALの設計コンセプトを吸収しました。彼は、CAT (Centralized Application Tracking) の開発とオープンソース化を主導しました。

中国人が主導するオープンソース システムとして、CAT はローカリゼーションにおいて非常に優れた成果を上げています。シンプルなアーキテクチャとすぐに使える機能を備えた CAT は、Dewu で使用する最初のアプリケーション監視システムでもあります。

0x01 ステージ1

0から1まで、CATに基づくリアルタイムアプリケーション監視

Dewu Colorful Stone プロジェクトが実施される前は、システムにはインフラストラクチャ レベルの監視しかありませんでした。 CAT の導入により、アプリケーション監視の盲点が効果的に解消されました。パフォーマンス監視レポート、ヘルスステータスの検出、さまざまな次元での異常統計の提供をサポートしており、トラブルシューティングに積極的な役割を果たすほか、シンプルなリアルタイムアラーム機能も提供します。

CAT には、指標の統計を分単位で集計する機能があります。豊富なレポート機能と統計機能、問題のトラブルシューティング機能を備えていることは、UI から簡単にわかります。

しかし、事業規模が徐々に拡大するにつれ、マイクロサービスの粒度は必然的に小さくなっていきました。 CAT はもはや当社の使用シナリオを満たせないことが判明しました。

• 完全なリンク ビューを直感的に表示することはできません。

トラブルシューティングや日常的なパフォーマンス分析のシナリオはますます複雑になっています。コア シナリオでは、内部呼び出しリンクは通常、複雑で変更可能です。トラフィックの観点からは、そのソース、アップストリームおよびダウンストリーム リンク、非同期呼び出しなどを完全に把握する必要があります。これは、CAT の範囲を少し超える可能性があります。

• チャートカスタマイズ機能の欠如:

CAT は多次元レポート分析を提供しますが、カスタマイズ機能は非常に限られています。当時、業界のチャートコンポーネントカスタマイズソリューションは徐々にGrafana + Prometheusへと移行しつつありましたが、CATを使用した場合、強力なチャート描画機能を享受することはできませんでした。同時に、クラウド ネイティブ コミュニティにおける可観測性プロジェクトである OpenTracing の台頭に伴い、私たちは半年足らずで CAT を徐々に廃止し、OpenTracing エコシステムへと進化しました。

0x02 ステージ2

OpenTracingに基づくフルリンクサンプリングモニタリングの作成を継続

OpenTracing は、フルリンク トレースのプロトコル標準の完全なセットをカスタマイズしますが、実装の詳細は提供しません。 OpenTracing プロトコルでは、トレースはスパンの有向非巡回グラフ (DAG) であると見なされます。当局者はまた、次の 8 つのスパンの因果関係と、それらが形成する単一のトレースの例の図を引用しています。

当時、OpenTracingに関連するオープンソースコミュニティも非常に活発でした。データ収集の問題を解決するために Jaeger が使用され、呼び出しチェーンは Gantt チャートを使用して表示されました。

OpenTracing エコシステムでは、リンク サンプリングにヘッド サンプリング戦略を使用します。 OpenTracing にはメトリックの仕様はありませんが、Google SRE ブックの「分散システムの監視」の章では、次の 4 種類のゴールデン メトリックについて説明されています。

スループット: たとえば、1 秒あたりのリクエスト数。通常の実装方法は、リクエストが完了するたびに増加するカウンターを設定することです。 1 秒あたりのスループットは、時間ウィンドウ内の変化率を計算することによって計算されます。

レイテンシ: リクエストを処理するのにかかる時間。

エラー率/エラー数: HTTP 500 エラーなど。もちろん、現在のリクエストが「エラー」リクエストであるかどうかを判断するために、特定のビジネス ロジックに基づいて HTTP 200 ステータスを区別する必要がある場合があります。

飽和度: CPU、メモリ、ネットワークなどのサーバー ハードウェア リソースの使用率に似ています。

そのため、DB および RPC コンポーネントのパフォーマンスを監視するために、Micrometer ライブラリを使用して各コンポーネントのスループット、レイテンシ、エラー率を追跡することにしました。したがって、監視の第 2 フェーズは、インジケーター監視に基づくアプリケーション パフォーマンス監視であり、コール チェーン監視によって補完されているとも言えます。

2.1 エンドポイントを使用して指標を追跡し、パフォーマンス分析を支援する

指標を追跡するプロセスで、すべての指標に「エンドポイント」ラベルを導入しました。このタグを導入することで、異なるトラフィックの入口に応じて、関連する DB、キャッシュ、メッセージ キュー、リモート呼び出しクラスの動作を区別できるようになります。トラフィックの入り口を通じて、インスタンスのすべてのコンポーネント インジケーターがカバーされ、基本的に次のシナリオの監視要件を満たします。

RPC 呼び出しのトラブルシューティングを行う場合、呼び出し元はダウンストリーム インターフェイス情報だけでなく、呼び出しをトリガーしたインターフェイスをトレースすることもできます。

インターフェースの高時間消費分析では、指標に基づいて単位時間ウィンドウの時間消費分解図を復元し、時間のかかるコンポーネントをすばやく表示できます。

2.2 モデル選択に関する質問

リンク監視用の既成の APM 製品 (Zipkin、Pinpoint、SkyWalking など) が業界に存在するのに、自分でデータを追跡するために OpenTracing + Prometheus を選んだのはなぜですか?主な要因は 2 つあります。

まず、当時、CATはフルリンク監視と一部のカスタマイズされたレポート分析の要件を満たすことができず、徳武取引リンクの五彩石プロジェクトの納品も終了に近づいていました。十分な検証を行わずに大規模な外部 APM 製品を軽率に統合すると、サービスの安定性にリスクが生じ、非常に限られた期間内では合理的な選択ではありませんでした。

次に、監視コンポーネントは統一された基本フレームワークとともにリリースされます。同時に、別のチームによって開発されたフルリンク シャドウ ライブラリ ルーティング コンポーネントは、OpenTracing データ転送メカニズムを利用し、監視コンポーネントと密接に結合されています。基本フレームワークは、監視、ストレス テスト、およびその他のモジュールを調整し、Spring Boot Starter メカニズムを使用して、すぐに使用できる機能と、ある程度のシームレスな統合を実現します。しかし、バイトコード拡張を使用する Pinpoint と SkyWalking は、基本フレームワークとうまく統合できません。並行して開発すると、基本フレームワークと Java エージェントの両方に追加の管理および保守コストが発生し、反復速度が低下します。

その後の約 2 年間で、アプリケーション サービス モニタリングは Dewu の技術部門で使用されるコンポーネントの約 70% をカバーし、2021 年に Dewu App が年間 SLA 99.97% を達成するための強力なサポートを提供しました。現在、OpenTracing + Prometheus エコシステムは、分散システムのコール チェーン モニタリングを非常にうまく解決したようです。 Grafana チャート ツールの助けを借りて、柔軟なインジケーター監視が実現され、基本的なフレームワークが統合されるため、ビジネス パーティはすぐに使用できます...ただし、第 2 段階は OpenTracing フルリンク サンプリング監視に基づいていると述べました。ビジネスの急速な発展に伴い、このアーキテクチャの欠点が徐々に明らかになってきています。

2.3 アーキテクチャの特徴

• 経験レベル

インジケーター: 広範囲なカバレッジ、詳細なディメンション、各モジュールとディメンションに基づいて統計分析を明確に実行する機能により、基本的に柔軟なチャート構成の監視ニーズを満たします。しかし、それは一種の時系列集計データであり、個人に分解することはできないことは否定できない。ある時点で時間のかかる操作が複数発生し、スループットが一定のレベルに達した場合、平均時間消費指標曲線は依然として顕著なポイントがなく安定する傾向があり、その結果、問題検出能力が低下します。

リンク: サンプリング レートが 1% の場合、ビジネス サービスでは大量のコール チェーンの送信によるパフォーマンスの問題は基本的に発生しません。しかし同時に、誤りが多く時間のかかるシナリオでは、適切なサンプリング リンクを見つけることが不可能な場合がよくあります。この期間中、ヘッド サンプリング戦略をテール サンプリングに変更することを検討しましたが、SDK 変換コストが非常に高くなり、複雑な呼び出し状況 (非同期など) でのサンプリング戦略のバックトラッキングが発生し、時間のかかる誤った操作が発生するたびに呼び出しチェーン全体を復元できるかどうかは保証できませんでした。

統合方法: ビジネス フレームワークと基本フレームワークの両方のプロジェクトの構築に Maven が使用され、Spring Boot Starter の「オールインワン」がすぐに使用できる統合に使用されます。これにより、統合コストが大幅に削減されますが、依存関係の競合による隠れた危険も生じます。

• プロジェクトの反復レベル

反復サイクルの矛盾により、当時のフルリンク監視の迅速な推進と実装には、基本フレームワークとの統合が唯一の選択肢でした。このように、Java サービスのアクセス率はかつて 100% に近かったのです。しかし、急速なビジネス発展の状況では、基本フレームワークの反復速度はビジネスの反復速度に大きく遅れており、間接的に監視システム全体の反復を制限していました。

• データガバナンスレベル

データガバナンスのコストは徐々に増加しています。基本フレームワークと業務システムの反復リズムには自然な不一致があり、また各業務システムにも独自の反復リズムがあるため、ネットワーク全体のバックエンド サービスを見ると、基本フレームワークのバージョンは不均一です。

監視システムは各反復で最大限の下位互換性を確保しようとしていますが、約 2 年の反復サイクルで異なるバージョンによって生じるデータの違いにより、監視ポータル システム Tianyan の反復が大幅に制限されています。開発者は長い間、データに関する妥協に苦労しており、多くの機能を実装するために回り道をしなければなりません。

• 安定レベル

関連するプランは、Spring フレームワーク Bean の自動アセンブリ ロジックに依存します。ビジネス側は理解コストが低く、変更が容易ですが、実行時の特定のロジックの低下などのきめ細かい計画が欠けています。

2021 年後半からは、上記の利点とリスクのバランスを完全に取るために、監視と収集の部分を基本フレームワークから切り離し、独立して反復することにしました。これに先立ち、CNCF (Cloud Native Computing Foundation) の推進により、OpenTracing も OpenCensus と統合され、新しいプロジェクト OpenTelemetry が形成されました。

0x03 ステージ3

一歩前進: OpenTelemetry に基づくフルリンク アプリケーション パフォーマンス モニタリング

OpenTelemetry は、可観測性の分野におけるテレメトリ データ収集とセマンティック仕様を統一することを目的としています。 CNCF (Cloud Native Computing Foundation) のサポートにより、過去 2 年間でより多くの人々が注目し、参加するようになり、システム全体がより成熟し、安定してきました。

実は、私たちが OpenTelemetry プロジェクトに注目し始めたのは 2020 年の終わり頃でしたが、当時はプロジェクトはまだ初期段階にあり、Trace および Metrics API はまだアルファ段階でした。不安定な要素が多かったです。できるだけ早く実稼働に導入する必要があることを考慮して、著者は 2021 年半ばから年末にかけて OpenTelemetry コミュニティでの関連問題の議論、テレメトリ モジュールの開発、基盤となるデータ プロトコルの一貫性、いくつかのバグの修正にも参加しました。この 6 か月間で、参加する人が増えるにつれて、関連する API と SDK は徐々に安定してきました。

OpenTelemetry アーキテクチャ (opentelemetry.io からの画像)

3.1 Trace2.0時代の到来

OpenTelemetry は、可観測性の 3 つの主要要素であるメトリック、トレース、ログを統合することに取り組んでいます。テレメトリ API の定式化では、SDK 実装レイヤーでの関連付け解除を容易にするために、統一されたコンテキストが提供されます。たとえば、Metrics と Trace の関係は、OpenTelemetry が Metrics の実装で OpenMetrics 標準プロトコルをサポートし、Exemplar 形式のデータが Trace と Metrics の間に橋渡しをするという事実に反映されています。

OpenMetrics は、Prometheus 形式の上に構築された仕様であり、よりきめ細かい調整が可能で、Prometheus 形式とほぼ下位互換性があります。

これまでは、メトリック インジケーター タイプのデータは、特定のトレースのリンクに正確に関連付けることができず、タイムスタンプに基づいて特定の範囲内のリンクに大まかに関連付けることしかできませんでした。このソリューションの欠陥は、インジケーター コレクター vmagent の 10 秒～ 30 秒ごとのプル モードでは、インジケーターのタイムスタンプが収集時間に依存し、トレース呼び出し時間と一致しないという事実から生じます。

サンプル データは、次のように、現在のコンテキストのトレース ID とスパン ID 情報をヒストグラム測定形式の末尾に追加します。

 shadower_virtual_field_map_operation_seconds_bucket { holder = "Filter:Factory" 、 key = "WebMvcMetricsFilter" 、 operatinotallow = "get" 、 tcl = "AppClassLoader" 、 value = "Servlet3FilterMappingResolverFactory" 、 le = "0.2" } 3949.0 1654575981.216 # { span_id = "48f29964fceff582" 、 trace_id = "c0a80355629ed36bcd8fb1c6c89dedfe" } 1.0 1654575979.751

Exemplar 形式のインジケーターを収集し、バケット ラベル「le」によって発生する高カーディナリティの問題を防ぐために、インジケーター コレクション vmagent を再開発し、Exemplar データを運ぶインジケーターをさらにフィルター処理し、このタイプのデータをバッチで非同期的に Kafka に送信します。 Flink に消費され、Clickhouse に移行した後、Tianyan 監視ポータル システムはクエリ インターフェイスと UI を提供します。

分位統計と Exemplar データをリンクするための UI の概略図

データ レポート レイヤーでは、OpenTelemetry Java SDK は Mpsc (複数のプロデューサーと単一のコンシューマー) キューを使用します。これは、JDK のネイティブ ブロッキング キューよりもパフォーマンスが優れています。多数の long 型フィールドを使用してメモリ領域を埋め、スペースを時間と交換して偽共有問題を解決し、同時実行状況での書き込み競合を減らしてパフォーマンスを向上させます。

トラフィックのピーク時には、リンク データ送信キューのパフォーマンスは、フレーム グラフに示されているように平均 CPU 使用率が 2% 未満を示し、毎日のサービスの全体的な CPU レベルと 0 サンプリングの CPU レベルの間に明らかな違いはほとんどありません。そのため、複数のストレステストと比較を経て、運用環境のクライアント側でリンクデータの完全なレポートを公開することを決定し、Dewuテクノロジー史上初めてリンク全体の100％サンプリングを実現し、サンプリング率が低いためにトラブルシューティングが困難になるという問題を解消しました。これまでのところ、第3段階では、Dewuのフルリンク追跡技術は正式にTrace2.0時代に入りました。

OpenTelemetry のプラグ可能な API 設計のおかげで、OpenTelemetry Java Instrumentation プロジェクト Shadower Java を再開発し、多くの機能を拡張しました。

3.2 クライアントコレクションを管理するためのコントロールプレーンの導入

コントロール プレーンを使用して、次のようなクライアント監視メカニズムを通じて構成項目が配信されるようにします。

• リアルタイムダイナミックサンプリング制御
• 診断ツール Arthas 行動制御
• リアルタイムグローバルダウングレードプラン
• テレメトリ コンポーネントのランタイム スイッチ
• リアルタイムRPCコンポーネントの入力および出力パラメータ収集スイッチ
• リアルタイム高カーディナリティインジケータラベルの劣化制御
• プローブバージョンによる計画管理
• 承認数に基づくグレースケールのアクセス戦略。

• ……

コントロール プレーンの導入により、ダウングレードなしのプランのギャップが埋められ、より柔軟な構成が提供され、さまざまなトラフィック シナリオでのデータ収集プランの迅速な変更がサポートされます。

3.3 独立した起動モジュール

従来、ビジネス関係者が直面してきた基本フレームワークの統合による依存関係の競合問題や、複数バージョンの共存によるデータ形式の分散と互換性の問題を解決するために、ユニバーサル Java エージェント ランチャーである Promise ツールボックスを開発しました。リモート ストレージと組み合わせることで、構成可能な任意の Java エージェントのダウンロード、更新、インストール、および起動をサポートします。

 [ plugins ] enables = shadower 、 arthas 、 pyroscope 、 chaos- agent [ shadower ] arthas_key = / javaagent / shadower- % s - final .jarboot_class = com .shizhuang .apm .javaagent .bootstrap .AgentBootStrapclassloader = systemdefault_version = 115.16 [ arthas ] arthas_key = / tools / arthas - bin zip ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​javaagent / chaos - agent .jarboot_class = com .chaos .platform .agent .DewuChaosAgentBootstrapclassloader = systemapply_envs = dev 、 test 、 local 、 pre 、 xdw

3.4 Otel APIに基づく拡張機能

3.4.1 豊富なコンポーネントメトリクス

OpenTracing の第 2 フェーズでは、エンドポイントを使用して複数のコンポーネントにわたるメトリックを追跡しました。この優れた機能は第 3 フェーズにも引き継がれました。私たちは、基盤となる Prometheus SDK に基づいてメトリック追跡 SDK の完全なセットを設計し、バイトコード インストルメンテーションの利便性を利用して、より多くのコンポーネント ライブラリを最適化および強化しました。 (現段階では、OpenTelemetry SDK のメジャー バージョンは 1.3.x であり、関連する Metrics SDK はまだアルファ段階です)

Otel の Java Instrumnetation は、非同期リンク コンテキスト データ転送とスレッド コンテキスト関連付けのコンテナーとして主に WeakConcurrentMap を使用します。 Otel は多くの一般的なコンポーネント ライブラリを強化しているため、WeakConcurrentMap が非常に頻繁に使用されます。このオブジェクトのサイズを監視すると、プローブによって発生するメモリ リークのトラブルシューティングに役立ちます。また、オブジェクトの成長率が設定したしきい値に達すると、アラームが発行され、早期に手動で介入して、オンライン障害を防ぐための関連プランを実行できるようになります。

部分的な自己監視パネル

3.4.2 拡張リンク透過伝送プロトコル

1) RPC IDの紹介

アップストリーム アプリケーションとダウンストリーム アプリケーションをより適切に関連付け、各フローに「ID」を付与するために、TextMapPropagator インターフェイスを拡張し、リンク上の各フローがリクエストのソースを認識できるようにしました。これは、クロスリージョンおよび環境コールのトラブルシューティング シナリオで重要な役割を果たします。

さらに、クロスエンド シナリオでは、Alibaba Eagle Eye コール チェーン RPCID モデルを参照して、RpcID フィールドを追加します。このフィールドの末尾の値は、クロスエンド呼び出しが発生するたびに増加します。下流のアプリケーションの場合、フィールド自体のレベルが増加します。

このフィールドには次の機能があります。

簡略化された通話リンク ビューの提供をサポートします。肥大化したリンク (スパンが 2000 を超えるキャッシュおよび DB 呼び出しを含むリンクなど) をクエリする場合は、RPC 呼び出しノードと呼び出し階層関係のみが提供されます。

リンクの忠実度: クライアント リンク データ レポート キューは無制限のキューではありません。クライアント自体が頻繁に呼び出しを行う場合、レポート キューがしきい値まで蓄積されると破棄され、リンク全体が不完全になります。もちろん、これは予想される現象ですが、RpcID フィールドがない場合、リンク ビューは失われたノードを関連付けることができず、リンク レイヤー全体の混乱と歪みが生じます。

2) トレースIDをカスタマイズする

リンク詳細ページでの効率的な検索効率を実現するために、TraceID 生成ロジックを拡張しました。 ID の最初の 8 桁はインスタンス IP を使用し、中央の 8 桁は現在のタイムスタンプを使用し、最後の 16 桁は乱数を使用して生成されます。

 32ビットカスタム トレース ID: c0a8006b62583a724327993efd1865d8

 c0a8006b 62583 a72 4327993 efd1865d8
 | | |
上位 8 ビット( IP )中間 8 ビット(タイムスタンプ)下位 16 ビット(ランダム)

これには 2 つの利点があります。

TraceID を介してタイムスタンプを逆解析し、時間範囲をロックすると、リポジトリ Clickhouse の検索効率が向上します。また、現在の Trace がホット リポジトリをクエリするかコールド リポジトリをクエリするかを決定するのにも役立ちます。

インスタンス IP をバインドすると、現在のトレース トラフィック エントリが属するインスタンスを関連付けるのに役立ちます。極端なシナリオでは、リンク上のノードを取得できない場合でも、インスタンス要素と時間要素を通じてソースをトレースできます。

3) 非同期通話識別

サービス スループットを向上させ、ハードウェア リソースを最大限に活用するために、非同期呼び出しシナリオはビジネス システムで広く使用されています。 Otel が実装した非同期リンク コンテキスト転送に基づいて、現在のノードと親ノードの呼び出し関係を識別するための「async_flag」フィールドをさらに拡張し、プレゼンテーション層で非同期呼び出しが発生するシーンをすばやく見つけられるようにしました。

3.4.3 より明確な呼び出しチェーン構造

Otel がサポートする一部のコンポーネントの中には、MVC プロセス、データベース接続の取得など、ネットワーク呼び出しを伴わない操作や、非常に頻繁に実行される操作もあります。一般的に、このようなノードは、リンク詳細のメイン ビューではあまり意味がありません。そのため、このようなノードの生成ロジックを最適化および調整し、リンクのメイン構造全体が「クロスエンド」に重点を置くようにしました。同時に、いくつかのコア コンポーネントの主要な内部メソッドの詳細を強化し、それらを「イベント」の形式で親ノードにマウントして、よりきめ細かいトラブルシューティングを容易にしました。

RPC呼び出しの主要な内部イベント

イベントを取得するためのDB呼び出し接続

3.4.4 プロファイリングのサポート

1) スレッドスタック分析の統合。 Arthas などのツールを統合することで、特定のインスタンスのスレッドのリアルタイムのスタック情報を簡単に表示したり、サンプリング間隔を制御して、業務自体のパフォーマンスに影響を与える頻繁なキャプチャを回避したりすることができます。

2) Pyroscope を統合することで、高レイテンシ パフォーマンスのトラブルシューティングの最終段階が実現します。 Pyroscope は非同期プロファイラーの二次開発を行っており、Otel 統合もサポートしています。ただし、現時点では、公式ではプロファイリング動作のライフサイクル全体が実装されておらず、プロファイリング動作はある程度パフォーマンスに影響を与えます。そのため、公式の Pyroscope ライフサイクルを拡張し、「停止」動作を実装し、タイムホイール アルゴリズムを使用して特定の操作の時間消費を検出しました。予想されるしきい値に達すると、プロファイリングが開始され、操作が終了するか最大しきい値を超えるとプロファイリングが停止します。

パフォーマンス診断に関連するアプリケーションに関しては、後続の診断トピックにご注目ください。

0xff 結論

アプリケーション監視と収集の分野における Dewu の 3 つのマイルストーン反復を見ると、CAT の最初のフェーズは 0 から 1 へのプロセスです。アプリケーション サービスが自分自身を観察する方法を提供し、ビジネス パーティが初めてサービスの運用状況を真に理解できるようにします。第 2 フェーズから、ビジネスの急速な発展に伴い、監視システムに対するビジネス パーティの要件はゼロからではなく、精度と正確さも求められます。

したがって、急速な反復のコンテキストにおける機能とアーキテクチャの進化の間の矛盾と、外部のクラウドネイティブ コンテキストでの可観測性の開発が相まって、OpenTelemetry システムに基づく進化の第 3 フェーズを実行するようになりました。機能レベルと製品レベルの両方で優れた結果が達成されました。現在、私たちはコール チェーンと関連する診断ツールを深く統合し、進化の次の段階に入ろうとしています。第3段階に基づいて、Dewuのフルリンク追跡技術は正式にパフォーマンス分析と診断の時代に入ります。

参考記事:

• Dapper、大規模分散システム トレース インフラストラクチャhttps://storage.googleapis.com/pub-tools-public-public-publication-data/pdf/36356.pdf
• Dianping のオープンソース分散監視プラットフォーム CAT の詳細な分析 - Alibaba Cloud 開発者コミュニティ https://developer.aliyun.com/article/269295
• 「分散リンクトラッキング」コンポーネントの開発の歴史に関する興味深い講演
• https://xie.infoq.cn/article/8e06e8d9e43d1768e021225cb
• Jaeger サンプリングhttps://www.jaegertracing.io/docs/1.39/sampling/
• OpenTelemetry の簡単な歴史 (これまでのところ) |クラウド ネイティブ コンピューティング ファンデーションhttps://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
• OpenMetrics プロジェクト — メトリクス データを公開するための標準の作成https://openmetrics.io/
• OpenTracing と OpenCensus の統合: 統合へのロードマップ
• 分散システムの監視