Twitter Zipkin

Zipkinは、Twitter上のすべての異種サービスのランタイムデータを収集するのに役立つ分散トレースシステムです。 CollectorサービスとQueryサービスを介したデータの収集と取得を管理します。 Google DapperのモデルでZipkinを設計しました。 @ZipkinProjectを購読して、ご@ZipkinProject 。

そして、なぜこの分散トレース？

トレースを収集することにより、開発者は分散システムで特定のクエリがどのように実行されるかについてより深い知識を得ることができます。 たとえば、タイムアウトを超えたなど、ユーザーリクエストに問題があるとします。 失敗したリクエストのトレースを表示して、Webインターフェースに表示できます。 予期せぬ応答時間の増加により、サービスの有罪をすばやく見つけることができます。 サービスに詳細な注釈が付けられている場合、問題が発生したサービスの場所を見つけることもできます。

建築

これらのコンポーネントは、完全なトレースシステムを構成します。

ツールライブラリ

トレース情報は、Zipkinを使用してノードに誘導するツールライブラリを使用して、各ノードで収集されます。 ホストが別のサービスにリクエストを行うと、リクエストとともにいくつかのトレース識別子が渡されるため、後でこのデータをリンクできます。

フィナグル

Finagleは、Java、Scala、またはJVMを使用する他の言語で非同期クライアントおよびリモートプロシージャコール（RPC）サーバーを作成するために使用できるJVMの非同期ネットワークスタックです。

Finagleは Twitter内で積極的に使用されているため、トレースサポートの明確な出発点になっています。 これまでのところ、ThriftとHTTPをサポートするクライアント/サーバーと、MemcacheとRedisのみをサポートするクライアントがあります。

ScalaでFinagleサーバーをセットアップするには、次の手順に従ってください。 トレースの追加は、 finagle-zipkin依存関係を追加し、 ServerBuilder tracerをServerBuilderです。

 ServerBuilder() .codec(ThriftServerFramedCodec()) .bindTo(serverAddr) .name("servicename") .tracer(ZipkinTracer.mk()) .build(new SomeService.FinagledService(queryService, new TBinaryProtocol.Factory())) 

クライアントのトレース設定も同様です。 上記のようにZipkinトレーサーを設定すると、ごく一部のリクエストが自動的にルーティングされます。 リクエストの開始時、終了時、およびリクエストに関係するサービスとホストを記録します。

追加情報を記録する場合は、コードにカスタムメモを追加できます。

 Trace.record("starting that extremely expensive computation"); 

上記の例では、ラインノートが実行された時点に添付されます。 キー値でメモを追加することもできます。 次のようになります。

 Trace.recordBinary("http.response.code", "500"); 

ルビースリフト

これは、リクエストをトレースするために使用するgemです。 トレーサーを埋め込み、トレースリクエスト識別子を生成するには、RackHandlerでこのgemを使用できます。 トレーサーを追跡するzipkin-webの例を参照してください。

Rubyコードからの呼び出しを追跡するには、 Ruby Thrift Twitterクライアントを使用します。 クライアントの使用方法の例を以下に示します。

 client = ThriftClient.new(SomeService::Client, "127.0.0.1:1234") client_id = FinagleThrift::ClientId.new(:name => "service_example.sample_environment") FinagleThrift.enable_tracing!(client, client_id), "service_name") 

素晴らしい

Querulousは、データベースと対話するためのScalaライブラリです。 要求のタイミングとSQLの実行の追跡が含まれます。

キャシー

Cassieは、Cassandra用のFinagleベースのクライアントライブラリです。 Cassieのトレーサーの構成はFinagleとほぼ同じですが、Cassieの場合はKeyspaceBuilderが使用されます。

 cluster.keyspace(keyspace).tracer(ZipkinTracer.mk()); 

輸送

Scribeを使用して、すべてのトレースをさまざまなサービスからZipkinおよびHadoopに転送します。 ScribeはFacebookで開発され、システム上のすべてのサーバーで実行できるデーモンで構成されています。 メッセージログをスキャンし、カテゴリに応じて正しいサービスレシーバーに送信します。

ジプキンコレクターデーモン

トレースデータがコレクタデーモンに到着するとすぐに、その正確性を確認し、検索用のインデックスを保存して構築します。

保管

Cassandraを使用してデータを保存します。 スケーラブルで柔軟性があり、Twitterで頻繁に使用されています。 このコンポーネントをモジュール化しようとしたので、他のものに置き換えるのは難しくないはずです。

リクエストデーモン

データが記録され、インデックスが作成されたら、それを取得する便利な方法が必要です。 ここではクエリデーモンが便利で、ユーザーは単純なThrift APIを使用してトレースを検索および取得できます。 Thriftファイルの例を参照してください。

ユーザーインターフェース

ユーザーのほとんどは、UIを介してデータにアクセスします。 これは、 D3を使用してトレースデータを視覚化するRailsアプリケーションです。 ユーザーインターフェイスには認証機能が組み込まれていないことに注意してください。

モジュール

設置

すぐに慣れるには、 UbuntuクイックスタートおよびMacクイックスタートチュートリアルをご覧ください 。 Zipkinを1台のコンピューターで実行して、Zipkinを試すことができます。

カスタマイズについて少し。

カサンドラ

Zipkinは、Cassandraと組み合わせて最もよく使用されます。 Redis用のプラグインもあります。他のデータベースのサポートを希望します。

1. クラスターの起動方法については、 Cassandra Webサイトにアクセスしてください。
2. Zipkinに適合した回路を使用します。 次の$ cassandra-cli -host localhost -port 9160 -f zipkin-cassandra/src/schema/cassandra-schema.txt
作成できます： $ cassandra-cli -host localhost -port 9160 -f zipkin-cassandra/src/schema/cassandra-schema.txt
$ cassandra-cli -host localhost -port 9160 -f zipkin-cassandra/src/schema/cassandra-schema.txt


飼育係

ZipkinはZooKeeperを使用して調整できます。 ここで参照値を保存し、サーバー自体を登録します。
インストール手順については、 ZooKeeper Webサイトにアクセスしてください。

スクライブ

Scribeは、Twitterでトレースデータのトランスポートとして使用するロギングフレームワークです。 Zipkinトレースデータを渡す方法は他にもいくつかあります。 特に、Zipkinを試してみたい場合は、この手順を完全にスキップして、ZipkinTracerを直接Collectorに転送できます。

ZipkinでScribeを使用するには、コレクターデーモンで指定されたネットワーク接続ストレージを作成する必要があります。 Zipkinでのストレージのセットアップは次のようになります。

 <store> category=zipkin type=network remote_host=123.123.123.123 remote_port=9410 use_conn_pool=yes default_max_msg_before_reconnect=50000 allowable_delta_before_reconnect=12500 must_succeed=no </store> 

コレクタのIPアドレスをハードコーディングしたくない場合は、いくつかのオプションがあります。 1つは、コレクタに内部DNSレコードを使用することです。そのため、コレクタを追加または削除するときにアドレスを変更する必要がある1つの場所があります。 さらに、Scribeの修正バージョンを使用できます。これは、ZooKeeperを介してコレクターのアドレスを取得します。 コレクターが起動すると、ZooKeeperに自分自身を登録し、作業が完了すると自動的に削除されます。 変更されたScribeは、コレクターで変更が発生したときに通知を受け取ります。 このモードをアクティブにするには、構成内のremote_hostに変更しますremote_host zk://zookeeper-hostname:2181/scribe/zipkinまたは同様のもの。

Zipkinサーバー

Scala 2.9.1、SBT 0.11.2およびJDK7でZipkinを開発しました。
Ubuntu QuickstartおよびMac Quickstartのマニュアルでは、CollectorおよびQueryサービスをインストールおよび実行する方法について説明しています。

ジプキンUI

UIは通常のRails 3アプリケーションです。

1. ZooKeeperサーバー構成を更新します。 Queryデーモンの検索に使用されます。
2. Railsの下に適切なアプリケーションサーバーをデプロイします。 ビルトインはテストにも適しています： $ bundle install && bundle exec rails server

Gem Zipkin-tracerは、Rack Handlerを介してRailsアプリケーションにトレースを追加します。 config.ruに追加します。

  use ZipkinTracer::RackHandler run <YOUR_APPLICATION> 

Railsアプリケーション自体が静的アセットを提供する場合、これらのリクエストのトレースは保存されます。

Hadoopでタスクを実行する

Hadoopにデータを保存するようにScribeを構成することが可能です。 これを行うと、Zipkin自体でその場で簡単に処理できないデータからさまざまなレポートを作成できます。

Scaldingというライブラリを使用して、ScalaからHadoopのタスクを構築します。

1. Hadoopでタスクを開始するには、最初にjarを作成する必要があります。 $ sbt 'project zipkin-hadoop' compile assembly
2. scald.rbで、jarのコピー先ノードの名前を変更し、タスクを実行します。
3. 必要に応じて、scald.rbのjarバージョンを更新します。
4. これで、scald.rbスクリプトを使用してタスクを実行できます。 $ ./scald.rb --hdfs com.twitter.zipkin.hadoop.[classname] --date yyyy-mm-ddThh:mm yyyy-mm-ddThh:mm --output [dir]

ライブラリを準備する方法

私たちはいくつかのライブラリとプロトコルを私たち自身に指示しましたが、それらの数を増やすのにいくらかの助けを得ることをまだ望んでいます。 始める前に、トレースデータがどのように構成されているかについていくつかのことを知る必要があります。

• 注釈-いくつかの値、タイムスタンプ、ノードアドレスが含まれます。
• スパン-特定のRPCに一致する注釈のセット。
• トレースは、単一のルートスパンを共有するスパンのセットです。

上記は、トレースデータをZipkinに送信するときに使用されます。 いくつかの詳細をここで説明します 。
トレースのもう1つの重要な部分は、サービス間で情報を転送するために使用する軽量ヘッダーです。 ヘッダーの構成は次のとおりです。

• トレースID-トレースを識別します。
• スパンID-個々のリクエストの識別子。
• オプションの親スパンID-この要求が別の要求の一部として行われた場合に追加されます。
• サンプル（ブール型フィールド）-トレースデータを保持するかどうかを示します。

データ型について少し知ったので、インストルメンテーションがどのように機能するかを段階的に見ていきましょう。 以下の例では、FinagleでHTTPトレースがどのように機能するかを説明します。 他のライブラリやプロトコルの場合、もちろんアクションは異なる場合がありますが、一般的な原則は変わりません。

サーバー側

1. 着信要求のトレースヘッダーを確認します。 その場合、このリクエストに関連付けられた識別子を受け入れます。 そうでない場合は、トレースID、スパンIDを生成し、データを保存するかどうかを決定します。 例については、 HttpServerTracingFilterを参照してください。
2. 現在のリクエストが選択に関係している場合、サービス名、ホスト名、名前Span（http get / putなど）などの情報を直接収集します。 リクエストを受け取ったときに「server received」というメモを作成し、処理が完了して結果を送信するときに「server send」というメモを作成します。 繰り返しますが、 HttpServerTracingFilterで例を見ることができます。
3. 生成されたトレースデータは、ServerBuilderで指定されたトレーサーオブジェクトに渡されます。 たとえば、ConsoleTracerの場合もありますが、この場合はZipkinTracerが使用されます。 ZipkinTracerはトレースデータを受信すると、それらをスパンIDでグループ化します。
4. ZipkinTracerは、「サーバーが受信した」メモやタイムアウトなどの「スパンの終わり」イベントを受信するとすぐに、Thrift構造の形式で集計データをScribeに送信します。 そのようなイベントが発生しない場合でも、データは送信されます。 他のデータ配信方法を追加することもできますが、ThriftとScribeは理にかなっていますが、場合によってはJSONとHttpの方がうまくいくかもしれません。

クライアント側

1. リクエストを実行する前に、すでにトレースに参加しているかどうかを確認してください。 たぶん、このクライアントはサーバー内で使用され、トレースIDはすでに割り当てられています。 このTrace idを再利用しますが、新しいリクエストに対して新しいSpan Idを作成します。 また、以前のスパンの親スパンIDがあればインストールします。 こことここのいくつかの例。
2. サーバー側のオプションと同様に、発信Http要求にトレースヘッダーを追加するHttpClientTracingFilterがあります。
3. また、リクエストの前に「クライアント送信」、サーバーから応答を受信した後に「クライアント受信」などの適切なメモを作成する必要があります。
4. サーバーバージョンと同様に、データはZipkinTracerによって送信され、Zipkinに送信されます。