3 つのオープン ソース分散トレース システム、すべて良好です。

分散トレース システムを使用すると、ユーザーは、複数のアプリケーション、サービス、データベース、およびプロキシなどの仲介者に分散されたソフトウェア システムを通じてリクエストを追跡できます。これにより、ソフトウェア システムで何が起こっているかをより深く理解できるようになります。これらのシステムは、リクエストが各ステップで費やした時間を示し、既知の各ステップをリストするグラフィカルな表現を生成します。

ユーザーは、システムで遅延や混雑が発生している場所を特定できます。リクエストが失敗し始めると、オペレーターと開発者は、バイナリ検索ツリーなどを使用してシステムをテストするのではなく、問題がどこで発生したかを正確に確認できます。これにより、展開ごとに発生する可能性のあるパフォーマンスの変動も明らかになります。 *** 顧客から指摘を受けるのではなく、異常な動作を警告することで自動的に回帰を検出します。

追跡イベントはどのように機能しますか?各リクエストには特別な ID が付与され、通常はヘッダーに挿入されます。この ID はトランザクションを一意に識別します。このトランザクションは、多くの場合、トレースと呼ばれます。追跡は、トランザクション全体を抽象化したものです。各トレースはスパンで構成されます。これらのスパンは、サービス呼び出しやデータベース要求など、実際に実行される作業です。各スパンには一意の ID もあります。スパンは子スパンと呼ばれる後続のスパンを作成することができ、子スパンは複数の親を持つことができます。

[[245045]]

オープントレーシングAPI

OpenTracing は、クロスプラットフォームの互換性を提供することを目的とした Zipkin から派生した仕様です。アプリケーションにトレースを追加し、分散トレース システムにデータを配信するためのベンダー中立の API を提供します。 OpenTracing 仕様用に作成されたライブラリは、OpenTracing 準拠のあ​​らゆるシステムで使用できます。 Zipkin、Jaeger、Appdash はオープン スタンダードを取り入れたオープン ソース ツールの例ですが、Datadog や Instana などの独自のツールでもオープン スタンダードを取り入れています。 OpenTracing が普及するにつれて、この傾向は続くと予想されます。

オープンセンサス

OpenTracing はありますが、OpenCensus はどうでしょうか?それは競合する標準ですか、まったく異なるもの、あるいは補完的なものですか?

OpenTracing は、すべての言語とトレース システムのオープン実装ではなく、オープン API と仕様の確立に重点を置いています。 OpenCensus は仕様だけでなく、言語実装とワイヤ プロトコルも提供します。また、通常は分散トレース システムの範囲外である追加のメトリックを含めることでトレースもカバーします。

OpenCensus では、アプリケーションが実行されているホスト上のデータを表示できますが、中央のアグリゲータにデータをエクスポートするためのプラグ可能なエクスポート システムも備えています。

両者の間には重複があります。どちらかが他方より優れているとは限りませんが、それぞれが何を実行し、何が実行できないかを知っておくことは重要です。 OpenTracing は主に仕様です。 OpenCensus は、より多くの視点からローカル コンポーネントに総合的なアプローチを提供しますが、リモート集約には他のシステムも必要です。

ジプキン

これは、この種のシステムとしては最も初期のものの一つです。これは、Google が使用する社内システムに関する Google Dapper 論文に基づいて Twitter によって開発されました。 Zipkin は Java で記述されており、スケーラブルなバックエンドとして Cassandra または ElasticSearch を使用できます。ほとんどの企業は、これらのオプションのいずれかで満足するはずです。 *** をサポートする Java バージョンは Java 6 です。また、Twitter スタックで人気があり、Apache プロジェクトとしてホストされている Thrift バイナリ通信プロトコルも使用します。

システムは、レポーター (クライアント)、コレクター、クエリ サービス、および Web UI で構成されます。 Zipkin は、トランザクション コンテキスト内のトレース ID のみを送信して、トレースが進行中であることを受信者に通知することで、運用時の安全性を確保します。各レポーターで収集されたデータは、コレクターに非同期的に転送されます。コレクターはこれらのスパンをデータベースに保存し、Web UI はこのデータを使用可能な形式でエンド ユーザーに提示します。コレクターへのデータの配信は、HTTP、Kafka、Scribe の 3 つの異なる方法で行うことができます。

Zipkin は OpenTracing 標準と互換性があり、人気の Spring Framework には Zipkin と互換性のある Spring Cloud Sleuth というコンポーネントがあります。

イェーガー

Jaeger は、CNCF がインキュベーション プロジェクトとして採用した Uber Technologies の新しいプロジェクトです。これは Golang で記述されているため、ホストへの依存関係のインストールや、インタープリターや言語 VM のオーバーヘッドを心配する必要はありません。 Zipkin と同様に、Jaeger もスケーラブルなストレージ バックエンドとして Cassandra と ElasticSearch をサポートしています。 Jaeger は OpenTracing 標準とも完全に互換性があります。

Jaeger のアーキテクチャは Zipkin に似ており、クライアント (レポーター)、コレクター、クエリ サービス、Web UI が含まれますが、各ホストにデータを集約するローカル エージェントがあります。エージェントは UDP 接続を介してデータを受信し、それをバッチ処理してコレクターに送信します。コレクターは Thrift プロトコルの形式でこのデータを受信し、このデータを Cassandra または ElasticSearch に保存します。クエリ サービスはデータ ストアに直接アクセスし、その情報を Web UI に提供できます。

デフォルトでは、ユーザーは Jaeger クライアントからすべてのトレースを取得しません。システムは、各クライアントを通過するトレースの 0.1% (1/1000) をサンプリングします。すべてのトレースを保存して転送するのは、ほとんどのシステムにとって少々大変な作業です。ただし、クライアントが使用するように構成されているプロキシを構成することで、この値を増減できます。ただし、このサンプリングは完全にランダムなわけではなく、改善されつつあります。 Jaeger は確率的サンプリングを使用して、新しいトレースをサンプリングする必要があるかどうかについて、根拠のある推測を試みます。適応サンプリングはロードマップに含まれており、意思決定のためのコンテキストを追加することでサンプリング アルゴリズムが改善されます。

アプリダッシュ

Appdash は、Jaeger と同様に Golang で書かれた分散トレース システムです。これは、Google の Dapper と Twitter の Zipkin をベースに Sourcegraph によって作成されました。 Jaeger や Zipkin と同様に、Appdash は OpenTracing 標準をサポートしています。

Appdash のアーキテクチャは、主にクライアント、ローカル コレクター、リモート コレクターの 3 つの部分で構成されます。ドキュメントは多くないので、この説明はシステムをテストし、コードを確認した結果に基づいています。 Appdash のクライアントがコードに追加されます。 Appdash は Python、Golang、Ruby の実装を提供していますが、OpenTracing ライブラリは Appdash の OpenTracing 実装で使用できます。クライアントはスパンを収集し、ローカル コレクターに送信します。次に、ローカル コレクターは、独自のローカル コレクターを実行している集中型の Appdash サーバーにデータを送信します。このローカル コレクターは、システム内の他のすべてのノードのリモート コレクターです。