エンタープライズ主流のフルリンク監視システム理論

エンタープライズ主流のフルリンク監視システム

1. 問題の背景

マイクロサービスアーキテクチャの人気により、サービスはさまざまな次元に応じて分割され、1 つのリクエストに複数のサービスが関与することがよくあります。インターネットアプリケーションは、さまざまなソフトウェアモジュールのセットに基づいて構築されています。これらのソフトウェアモジュールは、さまざまなチームによって開発されたり、さまざまなプログラミング言語を使用して実装されたり、複数の異なるデータセンターにわたる数千台のサーバーに分散されたりすることがあります。したがって、障害が発生したときに問題を迅速に特定して解決できるように、システムの動作を理解し、パフォーマンスの問題を分析できるツールが必要です。

全链路监控组件そうした問題が背景にあった。最も有名なものは、Google の公開論文で言及されているGoogle Dapperです。このコンテキストにおける分散システムの動作を理解するには、さまざまなアプリケーションおよびさまざまなサーバーにわたる相関アクションを監視する必要があります。

したがって、複雑なマイクロサービスアーキテクチャシステムでは、ほぼすべてのフロントエンドリクエストが複雑な分散サービス呼び出しリンクを形成します。リクエストの完全なコールチェーンは、次の図に示すようになります。
ここに画像の説明を挿入します
ビジネス規模が拡大し続け、サービスが増加し続け、頻繁に変更が発生するにつれて、複雑なコールリンクに直面すると、一連の問題が発生します。

問題を素早く見つけるにはどうすればよいでしょうか?
障害の影響範囲をどのように判断するか?
サービスの依存関係と依存関係の合理性をどのように整理するか?
リンクのパフォーマンスの問題とリアルタイムの容量計画を分析するにはどうすればよいですか?

同時に、スループット (TPS)、応答時間、エラー記録など、リクエスト処理中の各呼び出しのさまざまなパフォーマンス指標に注意を払います。

スループット、対応するコンポーネント、プラットフォーム、物理デバイスのリアルタイムスループットは、トポロジに基づいて計算できます。
応答時間。通話全体の応答時間と各サービスの応答時間を含みます。
単位時間あたりの例外数のサービス戻り統計に基づくエラーレコード。

フルリンクパフォーマンスモニタリングは、全体的な次元からローカルな次元までのさまざまな指標を表示し、アプリケーション全体にわたるすべてのコールチェーンのパフォーマンス情報を一元的に表示し、全体的なパフォーマンスとローカルなパフォーマンスを簡単に測定し、障害の原因を簡単に見つけることができます。生産を短縮し、トラブルシューティングの時間を短縮します。

フルリンク監視ツールを使用すると、次のことを実現できます。

リクエストリンクの追跡と迅速な障害位置特定: ビジネスログと組み合わせたコールチェーンを通じて、エラー情報を迅速に特定できます。
視覚化: 各ステージには時間がかかり、パフォーマンス分析が実行されます。
依存関係の最適化: 各呼び出しリンクの可用性、サービスの依存関係を整理して最適化します。
データ分析、リンクの最適化: ユーザーの行動経路を取得でき、概要分析は多くのビジネスシナリオに適用されます。

2. 対象要件

上で述べたように、フルリンク監視コンポーネントを選択する場合のターゲット要件は何ですか? Google Dapper でも言及されており、要約すると次のようになります。

1. プローブの消費パフォーマンス

APM コンポーネントサービスの影響は十分に小さいはずです。

サービスコールの埋め込み自体はパフォーマンスの損失を引き起こすため、コール追跡の損失を低く抑える必要がありますが、実際には、サンプリングレートを構成することでリクエストの一部を選択してリクエストパスを分析します。高度に最適化された一部のサービスでは、小さな損失でもすぐに目立ち、オンラインサービスの展開チームが追跡システムの停止を余儀なくされる場合があります。

2. コードの侵入性

つまり、ビジネスコンポーネントとして、他のビジネスシステムへの侵入を可能な限り最小限またはまったくなくし、ユーザーに対して透過的であり、開発者の負担を軽減する必要があります。

アプリケーションプログラマにとって、追跡システムの存在を知る必要はありません。追跡システムを効果的にしたい場合は、アプリケーション開発者の積極的な協力に依存する必要があります。そうすると、この追跡システムは脆弱すぎます。アプリケーションの問題は、多くの場合、追跡システムによってアプリケーションに埋め込まれたコードのバグや過失によって引き起こされます。このため、追跡システム「」の无所不在的部署ニーズ。

3. スケーラビリティ

優れた通話追跡システムは、分散展開をサポートし、優れたスケーラビリティを備えている必要があります。サポートできるコンポーネントが多ければ多いほど良いです。または、便利なプラグイン開発 API を提供し、監視されていない一部のコンポーネントについては、アプリケーション開発者が独自に拡張することもできます。

4. データ分析

データ分析は高速である必要があり、分析ディメンションはできるだけ多くなければなりません。追跡システムは、実稼働環境の異常な状況に迅速に対応するのに十分な速さで情報フィードバックを提供できます。包括的な分析により、二次開発を回避できます。

3. 機能モジュール

一般的なフルリンク監視システムは、次の 4 つの機能モジュールに大別できます。

1. 埋められたポイントと生成されたログ

埋め込みポイントは、現在のノードにおけるシステムのコンテキスト情報であり、次のように分類できます。

クライアント埋設ポイント
サーバー側の埋め込みポイント
クライアントとサーバー間の双方向の埋め込みポイント

埋められたログには通常、次の内容が含まれます。

トレースID
スパンID
通話の開始時刻
契約の種類
発信者のIPとポート
要求されたサービス名
電話には時間がかかります
通話結果
例外情報など

同時に、次の拡張に備えてスケーラブルフィールドが予約されます。

パフォーマンスに負担を与えることはできません。検証されていないもののパフォーマンスに影響を与えるものを社内で推進するのは困難です。

ログを書き込む必要があるため、ビジネス QPS が高いほど、パフォーマンスへの影響も大きくなります。サンプリングと非同期ログによって解決されました。

2. ログを収集して保存する

主に分散ログ収集ソリューションをサポートしますが、バッファとして MQ を追加します。

各マシンにはログを収集するデーモンがあり、ビジネスプロセスは自身のトレースをデーモンに送信し、デーモンは収集したトレースを上位に送信します。
パブリッシュ/サブスクライブアーキテクチャと同様に、マルチレベルコレクターは負荷分散が可能です。
リアルタイム分析と集約データのオフライン保存を実行します。
オフライン分析では、同じ呼び出しチェーンのログを要約する必要があります。

3. 通話リンクデータと適時性に関する統計を分析および収集する

コールチェーントラッキング分析: 同じ TraceID を持つスパンを収集し、時間順に並べ替えてタイムラインを作成します。ParentID をまとめて文字列化するのがコールスタックです。
例外をスローするかタイムアウトし、TraceID をログに出力します。TraceID を使用して呼び出しチェーンをクエリし、問題を特定します。
依存関係のメトリクス:
- 強い依存性: 呼び出しに失敗すると、メインプロセスが直接中断されます。
- 高い依存関係: リンク内の特定の依存関係を呼び出す可能性が高くなります。
- 頻繁な依存関係: リンクは同じ依存関係を何度も呼び出します。
オフライン分析: TraceID によって要約し、Span ID と ParentID を通じて呼び出し関係を復元し、リンク形状を分析します。
リアルタイム分析: 単一のログを要約したり再構成したりせずに直接分析します。現在の QPS を取得し、遅延します。

4. プレゼンテーションと意思決定のサポート

4. Google ダッパー

1. スパン

基本作業単位

リンク呼び出し (特定の制限なしで RPC、DB など) はスパンを作成し、64 ビット ID でそれを識別します。Uuid の方が便利です。スパンには説明情報、タイムスタンプ、キーなどの他のデータがあります-value 正しい (注釈) タグ情報、parent_id など。parent-id はスパンコールリンクのソースを表すことができます。
ここに画像の説明を挿入します
上の画像は、大規模なトレース中にスパンがどのように見えるかを示しています。Dapper は、トレース中に異なるスパン間の関係を再構築するために、スパン名に加えて各スパンの ID と親 ID を記録します。スパンに親 ID がない場合は、と呼ばれますroot span。すべてのスパンは特定のトレースに関連付けられており、同じトレースを共有します跟踪id。

スパンデータ構造:

type Span struct {
    
    
    TraceID    int64 // 用于标示一次完整的请求id
    Name       string
    ID         int64 // 当前这次调用span_id
    ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
    Annotation []Annotation // 用于标记的时间戳
    Debug      bool
}

2. トレース

ツリー構造に似たSpan コレクションは、サーバーへのリクエストから始まりサーバーが応答を返すまでの完全な追跡を表し、各 RPC 呼び出しの消費時間を追跡し、一意の ID を持ちますtrace_id。たとえば、実行する分散ビッグデータストレージのトレースは、リクエストの 1 つで構成されます。
ここに画像の説明を挿入します
各カラーノートはスパンでマークされ、リンクは TraceId によって一意に識別され、スパンは開始された要求情報を識別します。ツリーノードはアーキテクチャ全体の基本単位であり、各ノードはスパンへの参照です。ノード間の接続は、スパンとその親スパンの間の直接の関係を表します。ログファイル内のスパンは、単にスパンの開始時刻と終了時刻を表しますが、ツリー構造全体では比較的独立しています。

3. 注釈

注釈は、特定のイベント (時間など) のリクエストに関連する情報を記録するために使用され、1 つのスパン内に複数の注釈の説明が存在します。通常、次の 4 つの注釈情報が含まれます。

cs: Client Start。クライアントがリクエストを開始することを示します。
sr: Server Receive。サーバーがリクエストを受信したことを示します。
ss: サーバー送信。サーバーが処理を完了し、結果をクライアントに送信したことを示します。
cr: Client Received。クライアントがサーバーから返された情報を受信したことを示します。

注釈データ構造:

type Annotation struct {
    
    
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32			#持续时间
}

4. 呼び出し例

リクエストコールの例

ユーザーがリクエストを開始すると、最初にフロントエンドサービス A に到達し、次にサービス B とサービス C に対してそれぞれ RPC 呼び出しを行います。
サービス B は処理後に A に応答しますが、サービス C はサービス A に戻る前にバックエンドサービス D および E と対話する必要があります。最後に、サービス A がユーザーのリクエストに応答します。

ここに画像の説明を挿入します

通話プロセスの追跡

リクエストが到着すると、グローバル TraceID が生成されます。呼び出しチェーン全体は TraceID を通じて接続できます。1 つの TraceID がリクエストを表します。
呼び出し元の親子関係を記録するには、TraceID に加えてSpanID も必要です。各サービスは親 ID とスパン ID を記録し、これによって完全な呼び出しチェーンの親子関係を整理できます。
親 ID のないスパンはルートスパンとなり、コールチェーンエントリとみなすことができます。
これらすべての ID は、グローバルに一意な 64 ビット整数で表すことができます。
TraceID と SpanID は、呼び出しプロセス全体を通じてリクエストごとに透過的に送信される必要があります。
各サービスは、リクエストに添付された TraceID と SpanID を親 ID として記録するほか、自身が生成した SpanID も記録します。
完全な通話を表示するには、TraceID に基づいてすべての通話レコードを検索し、親 ID とスパン ID を使用して通話全体の親子関係を整理するだけです。

ここに画像の説明を挿入します

コールチェーンのコア作業

コールチェーンデータを生成し、すべてのアプリケーションをコールプロセス全体に埋め込み、ログを出力します。
チェーンデータ収集を呼び出して、各アプリケーションのログデータを収集します。
収集したデータを保存するためのチェーンデータストレージとクエリを呼び出します。ログデータの量は一般的に大きいため、保存できるだけでなく、高速なクエリも提供する必要があります。
指標の計算、保存、クエリは、収集されたログデータに対してさまざまな指標の計算を実行し、計算結果を保存します。
アラーム機能では、さまざまな閾値警告機能を提供します。

全体的な導入アーキテクチャ

AGENT を通じてコールチェーンログを生成します。
logstash を通じて kafka にログを収集します。
Kafka は、下流の消費者にデータを提供する責任があります。
storm は集計されたインジケーターの結果を計算し、es に分類されます。
Storm はトレースデータを抽出し、それを es にドロップして、より複雑なクエリを提供します。たとえば、時間ディメンションを通じて呼び出しチェーンをクエリすると、一致するすべての TraceID をすばやくクエリし、Hbase に移動してこれらの TraceID に基づいてデータを確認できます。
Logstash は、kafka の生データを hbase にプルします。hbase の行キーは traceID であり、traceID に基づくクエリは非常に高速です。

AGENT の非侵入型導入
AGENT エージェントの非侵入型導入により、パフォーマンス測定とビジネスロジックが完全に分離され、あらゆるクラスのメソッドの実行時間を測定できるため、収集効率が大幅に向上し、運用保守コストが削減されます。サービススパンに応じて、エージェントは主に 2 つのカテゴリに分類されます。

インサービスエージェント。このメソッドは、Java のエージェントメカニズムを使用して、メソッド呼び出し時間、入力パラメーター、出力パラメーター、その他の情報など、サービス内のメソッド呼び出しレベル情報に関するデータを収集します。
クロスサービスエージェント、この状況では、プラグインの形式で主流の RPC フレームワークをシームレスにサポートする必要があります。また、カスタム RPC フレームワークに適応する標準データ仕様を提供することで、次のようになります。

(1) Dubbo サポート、
(2) REST サポート、
(3) カスタム RPC サポート、(3) カスタム RPC サポート。

コールチェーン監視の利点

最前線の本番アプリケーションの導入状況を正確に把握します。
コールチェーンプロセス全体のパフォーマンスの観点から、主要なコールチェーンを特定し、それらを最適化します。
IT 運用および保守部門のビジネス価値を定量化するために、追跡可能なパフォーマンスデータを提供します。
コードのパフォーマンスの問題を迅速に特定し、開発者がコードを継続的に最適化できるように支援します。
開発者がホワイトボックステストを実施し、システムのオンライン安定期間を短縮できるように支援します。

5. プラン比較

市場にあるフルリンクモニタリングの理論モデルのほとんどは、Google Dapper の論文、つまり百花が咲く分散追跡に基づいています。

Zipkin は、もともと Twitter によって開発され、2012 年にオープンソース化されたオープンソース追跡システムです。Zipkin は広く使用されており、後の多くの世代に影響を与えています。トランスミッションヘッドはX-B3です
Skywalking は中国人によって開発され、その後 Apache Foundation のオープンソースプロジェクトに寄付されました。これは現在、Apache Foundation のトップレベルのプロジェクトです。
Pinpoint は 2012 年に Naver によって開発され、2015 年にオープンソース化されました。Pinpoint は Java、php、Python で動作します。
Yeter は最初に Uber によって開発され、2017 年にオープンソース化され、その後 CNCF 財団に寄贈されました。
OpenCensus は Google によって開始され、当初は Google の内部追跡プラットフォームでしたが、後にオープンソースになりました。
OpenTracing は CNCF によってホストされており、比較的完全なインストルメンテーションライブラリを備えています。

zipkin
github アドレス: https://github.com/openzipkin/zipkin

zipkin は、サービスアーキテクチャの問題を解決するのにかかる時間に関するデータの収集に役立つ分散追跡システムであり、その機能には、このデータの収集と検索が含まれます。ログファイルにトレース ID がある場合は、そこに直接ジャンプできます。それ以外の場合、クエリはサービス、操作名、タグ、期間などのプロパティに基づいて行うことができます。たとえば、サービスに費やされた時間の割合や、操作のどの側面が失敗したかなどです。軽量で使用と展開が簡単であることが特徴です。

zipkin は、各アプリケーションを通過したトレースリクエストの数を表示する UI インターフェイスも提供します。これは、不正なパスや非推奨のサービスへの呼び出しなど、集合的な動作を特定するのに役立ちます。

アプリケーションには、追跡データを Zipkin に報告するための「計測」が必要です。これは通常、トレースと検出用のライブラリを構成することを意味します。Zipkin にデータをレポートする最も一般的な方法は http または Kafka を介したものですが、Apache、ActiveMQ、gRPC、RabbitMQ など、他にも多くのオプションがあります。UI のデータを保存するには、メモリに保存する方法や、Apache Cassandra や Elasticsearch などのサポートされているバックエンドを使用して保存する方法など、さまざまな方法があります。
スカイウォーキング
github アドレス: https://github.com/apache/incubator-skywalking

skywalking は、モニタリング、追跡、および診断機能を含む、ローカルのオープンソースコールチェーントラッキングシステムです。Apache インキュベーターに加わり、マイクロサービス、クラウドローカル、およびコンテナベース (Docker、Kubernetes、Mesos) アーキテクチャ向けに特別に設計されています。

主な機能は次のとおりです。
```
 1）服务、服务实例、端点指标数据分析
 2）根本原因分析，在运行时评测代码
 3）服务拓扑图分析
 4）服务、服务实例和端点依赖性分析
 5）检测到慢速服务和终结点
 6）性能优化
 7）分布式跟踪和上下文传播
 8）数据库访问度量。检测慢速数据库访问语句（包括SQL语句）。
 9）报警
 10）浏览器性能监视
```
ピンポイント

Githubアドレス: https://github.com/naver/pinpoint

Pinpoint は、バイトコードインジェクションに基づく韓国のオープンソースコールチェーン分析およびアプリケーション監視分析ツールです。Pinpoint は、分散アプリケーション内のトランザクションを追跡することによって、システムの全体的な構造とそのコンポーネントが相互にどのように接続されているかを分析するのに役立つソリューションを提供します。

機能は次のとおりです。
```
 1）一目了然地了解应用程序拓扑
 2）实时监视应用程序
 3）获得每个事务的代码级可见性
 4）安装APM代理程序，无需更改一行代码
 5）对性能的影响最小（资源使用量增加约3%）
```
Pinpoint のビジュアル UI インターフェイス:
OpenTelemetry
OpenTelemetry は、CNCF が主導するクラウドネイティブの可観測性のための標準プロトコルのセットです。正式名は、OpenTelemetry Protocol、略して OTLP です。テレメトリデータの生成と収集を標準化することを目的としています。テレメトリデータには、ログ、メトリック、トレースが含まれます。

これは、アプリケーションコードからテレメトリデータを生成するための API、SDK、およびクライアントライブラリのコレクションです。OpenTelemetry を使用して収集したデータはベンダー中立であり、さまざまな形式でエクスポートできます。

OpenTelemetry を使用する最大の利点は、バックエンドを自由に選択できることです。ベンダーに縛られず、エンジニアリングチームは単一のテクノロジーを使用してテレメトリデータを生成できます。

OpenTelemetry をアプリケーションコードと統合するには、目的のプログラミング言語の OpenTelemetry クライアントライブラリを使用できます。OpenTelemetry は、テレメトリデータを複数の形式で処理およびエクスポートするために使用できる OTel (OpenTelemetry) コレクターと呼ばれるコレクターも提供します。

フルリンク監視ソリューションの主な参考資料:

プローブのパフォーマンス: 主にサービスのスループット、CPU、メモリに対するエージェントの影響。マイクロサービスの規模とダイナミクスにより、データ収集のコストが大幅に増加します。
コレクターのスケーラビリティ: 大規模なサーバークラスターをサポートするために水平方向に拡張する機能。
包括的なコールリンクデータ分析: コードレベルの可視性を提供して、障害点やボトルネックを簡単に特定します。
開発にとって透過的で、切り替えが簡単: コードを変更せずに新しい機能を追加でき、有効化または無効化も簡単です。
完全なコールチェーンアプリケーショントポロジ: アプリケーショントポロジを自動的に検出して、アプリケーションアーキテクチャを把握するのに役立ちます。

1. プローブの性能

結論: skywalking のプローブがスループットに与える影響は最も小さく、zipkin のスループットは中間です。ピンポイントプローブはスループットに大きな影響を与えます

プローブのパフォーマンスにもっと注意してください。結局のところ、APM 測位は依然としてツールです。リンク監視コンポーネントを有効にした後にスループットが半分以上低下する場合、それは許容できません。スカイウォーキング、ジップキン、ピンポイントでストレステストを実施し、ベースラインと比較しました (プローブは使用しません)。

Spring Boot、Spring MVC、redis クライアント、mysql などの一般的な Spring ベースのアプリケーションが選択されました。このアプリケーションを監視すると、トレースごとに、プローブは 5 つのスパン (Tomcat 1 つ、SpringMVC 1 つ、Jedis 2 つ、Mysql 1 つ) をキャプチャします。これは、skywalkingtest のテストアプリケーションと基本的に同じです。

500、750、1000 の 3 種類の同時ユーザーがシミュレートされました。jmeter を使用してテストし、各スレッドが 30 リクエストを送信し、思考時間を 10 ミリ秒に設定します。使用されるサンプリングレートは 1、つまり 100% であり、実稼働環境とは異なる場合があります。Pinpoint のデフォルトのサンプリングレートは 20 (50%) ですが、エージェントの設定ファイルを設定することで 100% に変更できます。zipkin のデフォルト値も 1 です。全部で12種類あります。以下の概要表を見てみましょう。
ここに画像の説明を挿入します上の表からわかるように、3 つのリンク監視コンポーネントのうち、skywalking のプローブがスループットに与える影響が最も小さく、zipkin のスループットは中間にあります。ピンポイントプローブがスループットに与える影響は明らかで、同時ユーザー数が 500 人の場合、テストサービスのスループットは 1385 から 774 に低下し、大きな影響があります。次に、CPUとメモリへの影響を見てみますが、社内サーバーで実施したストレステストでは、CPUとメモリへの影響はほぼ10%以内でした。

2. コレクタの拡張性

結論: コレクターのスケーラビリティは水平方向に拡張できるため
、大規模なサーバークラスターをサポートするための水平方向の拡張が可能になります。

zipkin は
zipkin-Server を開発します (実際にはすぐに使えるパッケージです) zipkin-agent は http または mq を介して zipkin-Server と通信します http 通信は通常のアクセスに影響を与えるため、mq に基づいて非同期通信することをお勧めします. zipkin-Server は、特定のトピックをサブスクライブすることで消費されます。もちろん、これはスケーラブルであり、複数の zipkin-Server インスタンスが mq 内の監視情報を非同期的に消費します。
skywalking
skywalking のコレクターは、スタンドアロンモードとクラスターモードという 2 つの展開方法をサポートしています。コレクターとエージェント間の通信には gRPC が使用されます。
pinpointと同様に
、 pinpoint もクラスターおよびスタンドアロン展開をサポートします。ピンポイントエージェントは、リサイクル通信フレームワークを通じてリンク情報をコレクターに送信します。

3. 包括的なコールリンクデータ分析

結論: 詳細レベルのピンポイント > スカイウォーキング > zipkin の
包括的なコールリンクデータ分析により、コードレベルの可視性が提供され、障害点やボトルネックを簡単に特定できます。

zipkin
zipkin のリンク監視の粒度はそれほど細かくありませんが、上の図から、呼び出しチェーンがインターフェイスレベルに固有であり、それ以上の呼び出し情報は関与していないことがわかります。
skywalking
skywalking は、DB やメッセージミドルウェアだけでなく、メインストリームの dubbo、Okhttp など、20 以上のミドルウェア、フレームワーク、クラスライブラリもサポートしています。上図のスカイウォーキングリンク呼び出し分析は比較的単純です。ゲートウェイはユーザーサービスを呼び出します。多くのミドルウェアをサポートしているため、スカイウォーキングリンク呼び出し分析は zipkin よりも完全です。
pinpoint
pinpoint は、これら 3 つの APM コンポーネントの中で最も完全なデータ分析コンポーネントです。コードレベルの可視性を提供し、障害点やボトルネックを簡単に特定します。上図からわかるように、実行されたすべての SQL ステートメントが記録されます。アラームルールなどを設定し、アプリケーションごとに担当者を設定し、設定したルールに従ってアラームを鳴らすこともでき、サポートするミドルウェアやフレームワークも比較的充実しています。

4. 開発が透過的で切り替えが簡単

結論: スカイウォーキング ≈ ピンポイント > Zipkin
は開発に対して透過的であり、オンとオフの切り替えが簡単で、コードを変更せずに新しい機能を追加し、有効または無効にするのも簡単です。私たちはコードを変更せずに機能が動作することを期待しており、コードレベルの可視性を求めています。

このため、Zipkin は変更されたクラスライブラリと独自のコンテナ (Finagle) を使用して、分散トランザクション追跡機能を提供します。ただし、必要に応じてコードを変更する必要があります。スカイウォーキングとピンポイントはどちらもバイトコード拡張手法に基づいており、開発者はコードを変更する必要がなく、バイトコードにより多くの情報が含まれるため、より正確なデータを収集できます。

5. 完全なコールチェーンアプリケーショントポロジ

結論: pinpoint > skywalking > zipkin は
アプリケーショントポロジを自動的に検出し、アプリケーションアーキテクチャを把握するのに役立ちます。

ピンポイントリンクトポロジ
スカイウォーキングリンクトポロジ
上の 3 つのzipkin リンクトポロジの図は、それぞれ APM コンポーネントの呼び出しトポロジを示しており、完全な呼び出しチェーンアプリケーショントポロジを実現できます。比較的言えば、ピンポイントインターフェイスは、特に呼び出された DB の名前をより豊富に表示しますが、zipkin のトポロジはサービスの提供に限定されています。

6. Pinpoint と Zipkin のリファインメントの比較

ピンポイントとジップキンの違い

Pinpoint は完全なパフォーマンス監視ソリューションです: プローブ、コレクター、ストレージから Web インターフェイスまでの完全なシステムを備えていますが、Zipkin はコレクターとストレージサービスのみに焦点を当てており、ユーザーインターフェイスもありますが、その機能は Pinpoint と同じではありません。。それどころか、Zipkin は、より強力なユーザーインターフェイスとシステム統合機能を備えた Query インターフェイスを提供し、このインターフェイスに基づいて開発および実装できます。
Zipkin は Finagle フレームワーク (Scala 言語) に基づいたインターフェイスを公式に提供していますが、他のフレームワークのインターフェイスはコミュニティによって提供されており、現在 Java、Scala、Node、Go、Python、 Ruby と C#; ただし、現在 Pinpoint のみが公式に提供されており、その他のプローブはコミュニティサポートの要請中です (#1759 および #1760 を参照)。
Pinpoint は、バイトコードインジェクションによる通話インターセプトとデータ収集を実装する Java エージェントプローブを提供します。実際のコードの非侵入を実現できます。サーバーの起動時にいくつかのパラメータを追加するだけで、プローブの展開を完了できます。Zipkin の Java インターフェイス実装 Brave基本的な操作 API のみを提供します。フレームワークまたはプロジェクトと統合する必要がある場合は、構成ファイルを手動で追加するか、コードを追加する必要があります。
Pinpoint のバックエンドストレージは HBase に基づいていますが、Zipkin は Cassandra に基づいています。

Pinpoint と Zipkin の類似点
Pinpoint と Zipkin はどちらも Google Dapper 論文に基づいているため、理論的根拠はほぼ同じです。どちらもサービス呼び出しをカスケード関係を持つ複数のスパンに分割し、SpanId と ParentSpanId を通じて呼び出し関係をカスケードします。最終的に、呼び出しチェーン全体を流れるすべてのスパンが Trace に収集され、サービスに報告されます。末端のコレクターが収集を実行し、ストレージ。

現時点でも、ピンポイントが採用した概念はその論文と完全に一致しているわけではありません。たとえば、彼は TransactionId を使用して TraceId を置き換えます。実際の TraceId は、TransactionId、SpanId、および ParentSpanId を含む構造です。さらに、Pinpoint は Span の下に SpanEvent 構造を追加して、Span の内部呼び出しの詳細 (特定のメソッド呼び出しなど) を記録します。そのため、Pinpoint はデフォルトで Zipkin よりも多くの追跡データを記録します。

ただし、理論的には、Span の粒度に制限はないため、サービス呼び出しを Span にすることができ、各サービスのメソッド呼び出しも Span にすることができます。この場合、Brave は実際にメソッド呼び出しレベルを追跡できます。、しかし、具体的な実装は単にそれをしなかっただけではありません。
バイトコードインジェクションと API 呼び出し
Pinpoint はバイトコードインジェクションに基づいて Java エージェントプローブを実装しますが、Zipkin の Brave フレームワークはアプリケーションレベルの API のみを提供しますが、よく考えてみると問題は単純ではありません。バイトコードインジェクションはシンプルかつ粗雑な解決策です。理論的には、コードをインジェクトすることで、あらゆるメソッド呼び出しをインターセプトできます。言い換えれば、実装できないものは何もなく、実装できないものだけです。

しかし、Brave は異なり、Brave が提供するアプリケーションレベルの API では、インターセプトを実現するためにフレームワークの基礎となるドライバーのサポートも必要とします。たとえば、MySQL の JDBC ドライバーはインターセプターを挿入するためのメソッドを提供するため、StatementInterceptor インターフェイスを実装し、接続文字列で構成するだけで、関連するインターセプトを簡単に実装できます。対照的に、MongoDB の下位バージョンのドライバーまたは Spring の実装は、 Data MongoDB にはそのようなインターフェースがないため、クエリ文をインターセプトする機能を実装するのはさらに困難です。

したがって、現時点では、Brave は欠陥であり、バイトコードインジェクションを使用することがどんなに難しくても、少なくとも実現可能ですが、Brave では、どのように始めればよいのか、どこまでインジェクションできるのかがわからない可能性があります。注入できる範囲などは、フレームワーク自体の機能ではなく、フレームワークの API に依存します。
難易度とコスト
Pinpoint プラグインと Brave プラグインのコードをざっと読んでみると、2 つのプラグインの実装難易度が大きく異なることがわかります。Brave は、開発ドキュメントのサポートがない Pinpoint よりも使いやすいです。Brave のコード量は非常に少なく、コア機能は Brave-core モジュールに集中しているため、中級レベルの開発者であれば 1 日以内に内容を理解し、API の構造を非常に明確に理解できます。

Pinpoint のコードカプセル化も非常に優れており、特にバイトコードインジェクションのための上位 API のカプセル化は非常に優れていますが、コードをインジェクションするためのコア API はあまり理解していませんが、それでも読者はバイトコードインジェクションについてある程度の理解を必要とします。徹底的に理解したい場合は、おそらく Agent の関連コードを詳しく調べる必要があります。たとえば、addInterceptor と addScopedInterceptor の違いを明確に理解することは困難ですが、これら 2 つのメソッドは関連する種類の Agent にあります。

Brave のインジェクションは、関連するインターフェイスを提供する基礎となるフレームワークに依存しているため、フレームワークを包括的に理解する必要はなく、どこにインジェクションできるか、またインジェクション中にどのようなデータが取得できるかを知っていれば十分です。上の例と同様に、SQL をインターセプトする機能を実現するために MySQL の JDBC ドライバーがどのように実装されているかを知る必要はありません。しかし、これは Pinpoint には当てはまりません。Pinpoint はほぼどこにでもコードを挿入できるため、開発者は挿入する必要があるライブラリのコード実装を非常に深く理解する必要があります。もちろん、これは別のレベルから見ても、Pinpoint の機能が実際に非常に強力であり、デフォルトのプラグインの多くがすでに非常にきめ細かいインターセプトを実現していることを示しています。

基盤となるフレームワークにパブリック API がない場合、Brave は実際には完全に無力ではありません。AOP を使用して、関連するインターセプトを指定されたコードに挿入できます。明らかに、AOP のアプリケーションはバイトコードインジェクションよりもはるかに簡単です。

上記はモニタリングの導入コストに直接関係するもので、Pinpoint の公式技術文書には参考データが記載されています。システムを統合する場合、Pinpoint プラグインの開発コストは 100、プラグインをシステムに統合するコストは 0 ですが、Brave の場合、プラグインの開発コストは 20 のみで、統合はコストは10です。この点から、公式のコスト参照データは 5:1 であることがわかります。しかし、同関係者は、統合する必要があるシステムが 10 個ある場合、総コストは 10 * 10 + 20 = 120 となり、Pinpoint の開発コスト 100 を超え、統合する必要があるサービスが多ければ多いほどコストがかかると強調しました。ギャップ。
汎用性とスケーラビリティコミュニティ
によって開発された統合インターフェイスからわかるように、明らかに、Pinpoint はこの点で完全に不利な状況にあります。

Pinpoint のデータインターフェイスにはドキュメントがなく、あまり標準的ではありません (フォーラムのディスカッションスレッドを参照してください) 独自のプローブ (ノードや PHP など) を実装するには大量のコードを読む必要があります。さらに、チームはパフォーマンス上の理由からデータ送信プロトコル標準として Thrift を使用しましたが、これは HTTP や JSON よりもはるかに困難です。
コミュニティサポート
言うまでもなく、Zipkin は Twitter によって開発されたスターチームと見なすことができますが、Naver のチームは (#1759 の議論からもわかるように) 知られていない小規模なチームにすぎません。このプロジェクトが短期的に消滅したり更新が停止したりする可能性は低いですが、前者ほど安全ではありません。そして、コミュニティによって開発されたプラグインがさらになければ、Pinpoint がチーム自身の力だけに頼って多くのフレームワークの統合を完了することは非常に困難であり、現在の焦点は依然としてパフォーマンスと安定性の向上にあります。
他の
Pinpoint は実装の開始時にパフォーマンスの問題を考慮しており、www.naver.com ウェブサイトの一部のバックエンドサービスは毎日 200 億件以上のリクエストを処理するため、Thrift のバイナリ可変長エンコーディング形式を選択し、 UDP を送信リンクとして使用し、定数を渡すときにデータ参照ディクショナリを使用する、文字列を直接渡す代わりに数値を渡す、などを試みます。これらの最適化により、Thrift インターフェイスの使用の難しさ、UDP データ送信の問題、データ定数辞書の登録の問題など、システムの複雑さも増加します。

これに対し、Zipkin は使い慣れた Restful インターフェイスと JSON を使用するため、学習コストや統合の難易度がほとんどなく、データ送信の構造さえ理解していれば、新しいフレームワークに対応するインターフェイスを簡単に開発できます。

さらに、Pinpoint にはリクエストをサンプリングする機能がありません。明らかに、大規模なトラフィックの実稼働環境では、すべてのリクエストを記録することは不可能です。そのためには、どのような種類のリクエストを記録する必要があるかを判断するために、リクエストのサンプリングが必要になります。Pinpoint と Brave はどちらも、リクエストの何パーセントが記録されるかというサンプリングパーセンテージをサポートしています。ただし、Brave はさらに、サンプリング戦略をカスタマイズできるサンプラーインターフェイスも提供しており、特に A/B テストを実施する場合、この機能は非常に有意義です。
要約する

短期的な目標の観点から見ると、Pinpoint には圧倒的な利点があります。プロジェクトコードを変更せずにプローブをデプロイできること、メソッド呼び出しレベルまで詳細にデータを追跡できること、強力なユーザーインターフェイス、およびほぼ包括的な Java フレームワークサポートなどです。しかし、長期的には、Pinpoint の開発インターフェイスを学習し、将来さまざまなフレームワークのインターフェイスを実装するコストはまだ不明です。

それどころか、Brave をマスターするのは比較的簡単で、Zipkin のコミュニティはより強力であり、将来的にはさらに多くのインターフェイスが開発される可能性が高くなります。最悪の場合、新しい技術や概念をあまり導入せずに、AOP を通じて自分たちに適した監視コードを追加することもできます。また、将来的に業務が変化した場合、ピンポイントが公式に提供するレポートが要件を満たしているかは分かりにくく、新たなレポートを追加することにより、予測できない作業の難しさや負荷が発生します。

6. トレースとモニターの違い

監視はシステム監視とアプリケーション監視に分けられます。システム監視には、CPU、メモリ、ネットワーク、ディスクなどのシステム全体の負荷データが含まれ、各プロセスの関連データまで詳細に監視できます。このタイプの情報はシステムから直接取得できます。アプリケーションの監視にはアプリケーションのサポートが必要であり、対応するデータが公開されます。たとえば、アプリケーション内の内部リクエストの QPS、リクエスト処理の遅延、リクエスト処理のエラー数、メッセージキューのキュー長、クラッシュ状況、プロセスのガベージコレクション情報などです。Monitor の主な目的は、異常を検出し、時間内に警察に通報することです。
Tracing の基礎および核となるのは呼び出しチェーンです。関連するメトリクスのほとんどは、コールチェーン分析に基づいて取得されます。トレーシングの主な目的はシステム分析です。問題が発生してから解決するよりも、事前に問題を発見する方が良いでしょう。

トレースとアプリケーションレベルの監視テクノロジスタックには多くの共通点があります。データの収集、分析、保存、プレゼンテーションがあります。収集されるデータの具体的な次元が異なり、分析プロセスが異なるだけです。