3つのオープンソース分散トレースツール

[[246529]]

これらのツールは、複雑なソフトウェア システム内のリアルタイム イベントを視覚化し、パフォーマンスの問題を迅速に特定するのに役立ちます。

分散トレース システムは、複数のアプリケーション、サービス、データベース、プロキシなどのミドルウェアなどの分散ソフトウェアにわたって、リクエストを最初から最後まで追跡できます。システム内で実際に何が起こっているかをより深く理解するのに役立ちます。トレース システムは、既知の各ステップと、各ステップでリクエストにかかる時間をグラフィカルに表示します。

ユーザーはこれらの表示を使用して、システムのどの部分に遅延または障害があるかを判断できます。リクエストが失敗した場合、運用担当者と開発担当者は、バイナリ検索ツリーを使用して問題を特定するなど、システム全体をテストすることなく、問題の正確な原因を確認できます。開発の反復プロセス中に、追跡システムはパフォーマンスの変化を引き起こす可能性のあるリンクも表示できます。顧客から指摘されるよりも、異常な動作のアラートを通じてパフォーマンスの低下を自動的に認識する方が常に優れています。

この追跡はどのように機能しますか?各リクエストには一意の ID が割り当てられ、通常はリクエスト ヘッダーに挿入されます。対応するトランザクションを一意に識別します。一般的に、取引はトレーストレース「トレース」はトランザクション全体の抽象的な概念です。それぞれの「痕跡」はユニットスパン「ユニット」は、サービス呼び出し、データベース要求など、要求で実行される実際の操作を表します。各「ユニット」には、独自の一意の ID もあります。 「ユニット」の下にサブユニットを作成することもできます。また、サブユニットには複数の親「ユニット」を設定できます。

トランザクション (またはトレース) が実行されると、トレース システムのプレゼンテーション層で検索できるようになります。プレゼンテーション レイヤーとして使用できるツールはいくつかありますが、それらについては後ほど説明します。まず、Istio ウォークスルー ビデオ チュートリアルで説明した Jaeger インターフェースで、1 つのトレースに複数のユニットが表示されている次の図を見てみましょう。明らかに、この図を見れば、一目で取引をより深く理解することができます。

このデモでは、Istio の組み込み OpenTracing 実装を使用しているため、トレース データを取得するためにアプリケーション コードを変更する必要さえありません。 OpenTracing と互換性のある Jaeger も使用しました。

では、OpenTracing とは何でしょうか?見てみましょう。

オープントレーシングAPI

OpenTracing は、クロスプラットフォームの互換性を提供するために Zipkin から派生した仕様です。アプリケーションにトレース機能を追加し、トレース データを分散トレース システムに送信するためのベンダー中立の API を提供します。 OpenTracing 仕様に従って作成されたライブラリは、OpenTracing 互換のあらゆるシステムで使用できます。このオープン スタンダードを使用するオープン ソース ツールには、Zipkin、Jaeger、Appdash などがあります。 Datadog や Instana などの有料ツールでも採用されています。 OpenTracing は現在では普及しているため、この傾向は今後も続くと予想されます。

オープンセンサス

OpenTracing についてはすでに説明しましたが、OpenCensus とは何でしょうか?検索結果に表示され続けます。これは OpenTracing と完全に異なる、または補完的な競合標準ですか?

この質問に対する答えは、誰に尋ねるかによって異なります。まず、私が理解している限り、できるだけ違いを説明します。OpenCensus はより包括的で、すべてをカバーしています。 OpenTracing は、あらゆる開発言語やトレース システムにオープンな実装を提供するのではなく、オープン API と仕様を確立することに重点を置いています。 OpenCensus は仕様を提供するだけでなく、開発言語や接続プロトコルでの実装も提供します。さらに、トレースを実行するだけでなく、通常は分散トレース システムの範囲外である追加のメトリックも導入します。

OpenCensus を使用すると、アプリケーションが実行されているホスト上のトレース データを表示できますが、中央のアグリゲータにデータをエクスポートするためのプラグ可能なエクスポータ システムも備えています。現在、OpenCensus チームは Zipkin、Prometheus、Jaeger、Stackdriver、Datadog、SignalFx 用のエクスポーターを提供していますが、誰でもエクスポーターを作成できます。

両者には多くの重複点があり、どちらかが他方より優れているというわけではありませんが、それぞれが何を行い、何を行わないかを知ることは重要です。 OpenTracing は主に仕様であり、特定の実装と任意の設計は他者に委ねられています。 OpenCensus は、より自由にローカル コンポーネントに包括的なソリューションを提供しますが、リモート集約を行うには他のシステムも必要です。

オプションツール

ジプキン

Zipkin はそのようなツールの最初の 1 つでした。 Twitter は、Google が 2010 年に発表した社内追跡システム Dapper を紹介する論文に基づいて Zipkin を開発した。 Zipkin は Java で開発されており、スケーラブルなストレージ バックエンドとして Cassandra または ElasticSearch を使用しているため、ほとんどの企業のニーズを満たすことができます。 Zipkin がサポートする最新の Java バージョンは Java 6 であり、Twitter のシステムで人気があり、現在は Apache プロジェクトとしてホストされている Thrift バイナリ通信プロトコルも使用します。

システムには、レポーター (クライアント)、データ コレクター、クエリ サービス、および Web インターフェイスが含まれます。 Zipkin は、トレース プロセスを受信者に通知するために、トランザクション コンテキストとともにトレース ID のみを送信するため、実稼働環境でも安全です。各クライアントによって収集されたデータは、データ コレクターに非同期的に送信されます。コレクターはこれらのユニットからのデータをデータベースに保存し、Web インターフェイスは、このデータを使用可能な形式でユーザーに提示する役割を担います。クライアントがコレクターにデータを送信する方法は、HTTP、Kafka、Scribe の 3 つあります。

Zipkin コミュニティは、Zipkin と互換性のある Java クライアント実装である Brave も提供しています。 Brave には依存関係がないため、プロジェクトの負担が重くなったり、会社の標準と互換性のないライブラリで混乱したりすることはありません。 Brave 以外にも、Zipkin クライアントの実装は数多くあります。 Zipkin と OpenTracing 標準は互換性があるため、これらの実装は他の分散トレース システムでも使用できます。人気の Spring フレームワークには、Zipkin と互換性のある Spring Cloud Sleuth と呼ばれる分散トレース コンポーネントが含まれています。

イェーガー

Jaeger は Uber 発の比較的新しいプロジェクトです。 CNCF (Cloud Native Computing Foundation) は、Jaeger をインキュベーション プロジェクトとしてホストしています。 Jaeger は Golang で開発されているため、サーバーに依存関係をインストールする必要はなく、開発言語のインタープリターや仮想マシンのオーバーヘッドを心配する必要もありません。 Zipkin と同様に、Jaeger もスケーラブルなストレージ バックエンドとして Cassandra と ElasticSearch をサポートしています。 Jaeger は OpenTracing 標準とも完全に互換性があります。

Jaeger のアーキテクチャは、クライアント (レポーター)、データ コレクター、クエリ サービス、Web インターフェイスを備え、Zipkin と非常によく似ていますが、各サーバー上で実行されるエージェントもあり、サーバー上でローカルにデータ集約を行います。エージェントは UDP 接続を介してデータを受信し、それをバッチで処理して、データ コレクターに送信します。コレクターが受信したデータは Thrift プロトコルの形式であり、Cassandra または ElasticSearch に保存されます。クエリ サービスはデータベースに直接アクセスし、必要な情報を Web インターフェイスに提供できます。

デフォルトでは、Jaeger クライアントはすべてのトレース データを収集するのではなく、トレース データの 0.1% (1000 分の 1) のみをサンプリングします。ほとんどのシステムでは、すべての追跡データを保存して送信するのは、単純にやりすぎです。ただし、この値はプロキシを構成することによって調整でき、クライアントはプロキシから構成を取得します。このサンプリングは完全にランダムなものではなく、改善されつつあります。 Jaeger は確率的サンプリングを使用して、新しいトレースをサンプリングする必要があるかどうかについて、根拠のある推測を試みます。適応サンプリングはロードマップ上にあり、意思決定に役立つ追加のコンテキストを追加することでサンプリング アルゴリズムを改善します。

アプリダッシュ

Appdash も、Jaeger と同様に Golang で書かれた分散トレース システムです。 Appdash は、Google の Dapper と Twitter の Zipkin をベースに Sourcegraph によって開発されました。同様に、Opentracing 標準もサポートしていますが、これは後から追加されたもので、デフォルトとは異なるコンポーネントに依存するため、リスクと複雑さが増します。

大まかに言えば、Appdash のアーキテクチャには、クライアント、ローカル コレクター、リモート コレクターという 3 つの主要な部分があります。ドキュメントがあまりないため、このアーキテクチャの説明はシステムのテストとソースコードの確認に基づいています。コードを書くときにAppdashクライアントを追加する必要があります。 Appdash は Python、Golang、Ruby の実装を提供していますが、OpenTracing ライブラリは Appdash の OpenTracing 実装で使用できます。クライアントはセル データを収集し、ローカル コレクターに送信します。次に、ローカル コレクターはデータを中央の Appdash サーバーに送信します。中央の Appdash サーバーは独自のローカル コレクターを実行し、それが他のすべてのノードのリモート コレクターになります。