分散トレースに Spring Cloud Sleuth と Zipkin を使用するためのガイド

分散トレースを使用すると、分散システム内のリクエストをトレースできます。この記事では、Spring Cloud Sleuth と Zipkin の使用方法を説明します。

あらゆることを実行する 1 つの大規模なアプリケーション (通常はモノリシック アプリケーションと呼ばれます) を使用すると、アプリケーション内で受信する要求を簡単に追跡できます。ログをトレースして、リクエストがどのように処理されたかを把握できます。アプリケーション ログ自体以外は何も確認する必要はありません。

時間が経つにつれて、コードベースのサイズが拡大し続けるにつれて、モノリシック アプリケーションは拡張したり、大量のリクエストを処理したり、顧客に新しい機能を提供したりすることが難しくなります。これにより、モノリシック アーキテクチャがマイクロサービスに分割され、個々のコンポーネントのスケーリングと配信の高速化に役立ちます。

しかし、光り輝くものがすべて金であるとは限らないですよね？マイクロサービスでも同様です。モノリシック システム全体をマイクロサービスに分割し、ローカル関数呼び出しのセットによって処理されていた各リクエストを、分散サービスのセットへの呼び出しに置き換えました。この方法では、モノリシック アプリケーションでは簡単に実行できるリクエストの追跡などの機能が失われます。現時点では、すべてのリクエストを追跡するには、各サービスのログを確認する必要があり、相関関係を把握するのは困難です。

したがって、分散システムの場合、分散トレースの概念はリクエストの追跡に役立ちます。

分散トレースとは何ですか?

分散トレースは、分散システム全体で特定のリクエストを追跡するために使用できるメカニズムです。これにより、ユーザーのリクエストを完了するために、リクエストが 1 つのシステムから別のシステムにどのように進行するかを追跡できます。

分散トレースの主要概念

分散トレースは、次の 2 つの主要な概念で構成されます。

• 追跡ID
• スパン数

トレース ID は、受信リクエストを追跡し、リクエストを満たすためにすべての複合サービスにわたってトレースするために使用されます。スパンの ID はサービス呼び出しにまたがり、受信したすべての要求と送信した応答を追跡します。

チャートを見てみましょう。

受信リクエストには追跡 ID がありません。通話を傍受する最初のサービスは、トレース ID「ID1」とそのスパン ID「A」を生成します。スパン ID「B」は、サーバー 1 のクライアントが要求を送信してから、サーバー 2 が応答を受信し、処理して送信するまでの時間をカバーします。

Spring Cloud Sleuth を使用した Spring Boot の例

Spring Cloud Sleuth を統合したアプリケーションを作成しましょう。まず、https://start.spring.io/ にアクセスし、「Spring Web」と「Spring Cloud Sleuth」の依存関係を持つアプリケーションを作成しましょう。

次に、2 つのリクエスト マッピングを持つシンプルなコントローラーを作成しましょう。

 パブリッククラスコントローラ{

 プライベート静的最終Logger logger = LoggerFactory 。 getLogger ( コントローラー. クラス);
 プライベートRestTemplate 残りのテンプレート;

 @値( "${spring.application.name}" )
 プライベート文字列applicationName ;

 パブリックコントローラー( RestTemplaterestTemplate ) {
 この.restTemplate = restTemplate ;
 }

 @GetMapping ( "/path1" )
 パブリックレスポンスエンティティパス1 （）{

 ロガー。 info ( "リクエスト /path1 の {} でのリクエスト " 、 applicationName );
 文字列応答= restTemplate 。 getForObject ( "http://localhost:8090/service/path2 " 、 String 。 クラス);
 ResponseEntity を返します。 ok ( "/path1からの応答 + " + 応答);
 }

 @GetMapping ( "/path2" )
 パブリックレスポンスエンティティパス2 （）{
 ロガー。 info ( "/path2 の {} でのリクエスト" 、 applicationName );
 ResponseEntity .ok ( "/path2 からの応答 " ) を返します。
 }

ここでは、2 つのパスを作成しました。Path1 は Path2 の固定ポート 8090 を呼び出します。ここでの考え方は、同じアプリケーションの 2 つの個別のインスタンスを実行することです。

ここで、Detective が送信リクエストにヘッダーを挿入できるようにするには、RestTemplate を直接初期化するのではなく、Bean として挿入する必要があります。これにより、Detective は RestTemplate にインターセプターを追加して、トレース ID とスパン ID を含むヘッダーを送信リクエストに挿入できるようになります。

 @ビーン
public RestTemplaterestTemplate ( RestTemplateBuilder ビルダー) {
 builder.build () を返します。
 }

それでは、2つのインスタンスを起動してみましょう。これを行うには、まずアプリケーションをビルドし、mvn clean verify を実行してから、次のコマンドを実行して「service 1」を開始します。

 java - jar \
 ターゲット/ 分散- サービス- 0.0.1 - SNAPSHOT.jar \
 - 春。 応用。 名前= サービス- 1 \
 --server.port = 8080

次に、別のターミナルで次のように「service 2」を実行します。

 java - jar \
 ターゲット/ 分散- サービス- 0.0.1 - SNAPSHOT.jar \
 - 春。 応用。 名前= サービス- 2 \
 --server.port = 8090

アプリケーションが起動すると、以下に示すように「Service 1」、/path1 が呼び出されます。

 curl -i http : //localhost:8080/service/path1 を実行します。

それでは、「サービス 1」のログを見てみましょう。

 情報[ サービス- 1 、 222f 3 b00a283c75c 、 222f 3 b00a283c75c ] 41114 --- [ nio - 8080 - exec - 1 ] c 。 。 p . 分散サービス。 コントローラ: サービスでの受信リクエスト- リクエスト/ パス1 の1

ログには、3 つの部分 [サービス名、トレース ID、スパン ID] を含む角括弧が含まれます。最初の受信リクエストでは、受信トレース ID がないため、スパン ID はトレース ID と同じになります。

「サービス 2」のログを見ると、このリクエストに新しいスパン ID があることがわかります。

 情報[ サービス- 2 、 222f 3 b00a283c75c 、 13194 db963293a22 ] 41052 --- [ nio - 8090 - exec - 1 ] c 。 。 p . 分散サービス。 コントローラー: サービス2 の/ path2 で受信リクエスト

「サービス 1」から「サービス 2」に送信されたリクエストを傍受したところ、送信リクエストに次のヘッダーがすでに存在していることがわかりました。

 x - b3 - トレースID : "222f3b00a283c75c" 、
 x - b3 - スパID : "13194db963293a22" 、
 x - b3 - 親spanid : "222f3b00a283c75c

ここでは、次の操作 (「サービス 2」への呼び出し) のスパンがヘッダーに挿入されていることがわかります。これらは、クライアントがリクエストを行うときに「サービス 1」によって挿入されます。これは、「サービス 1」のクライアントから「サービス 2」への次の呼び出しの範囲がすでに開始されていることを意味します。上記のタイトルでは、「Service 1」のスパン ID が次のスパンの親スパン ID になっています。

理解しやすくするために、Zipkin と呼ばれるインターセプター ツールを使用してトレースを視覚的に表示することができます。

Zipkin でトレースを視覚化する

Zipkin をアプリケーションに統合するには、アプリケーションに Zipkin クライアント依存関係を追加する必要があります。

 < 依存関係>
 < グループ ID > 組織。 スプリングフレームワーク。 クラウド</ groupId >
 <artifactId> スプリング- クラウド- スルース- ジプキン</artifactId>
 </ 依存関係>

この依存関係を追加すると、Zipkin クライアントはデフォルトで Zipkin サーバーのポート 9411 にトレースを送信します。 Docker イメージを使用して Zipkin サーバーを起動しましょう。このために簡単な docker-compose ファイルを作成しました。

 バージョン: "3.1"
 サービス:
 ジプキン:
 画像: openzipkin / zipkin : 2
 ポート:
 - 「9411:9411」

これで、docker-compose up コマンドを使用してサーバーを起動できるようになりました。その後、http://localhost:9411/ で UI にアクセスできます。

デフォルトのポートを使用しているため、プロパティを指定する必要はありませんが、別のポートを使用する場合は、次のプロパティを追加する必要があります。

 春：
 ジプキン:
 ベースURL : http : //localhost:9411

完了したら、上記と同じコマンドを使用して両方のアプリケーションを起動しましょう。パス /path1 の「サービス 1」にリクエストを行うと、次のトレースが取得されます。

ここでは 2 つのサービスの範囲が表示されます。スパンを調べることで、さらに深く掘り下げることができます。

「サービス 1」の範囲は、応答が返される要求をカバーする通常の範囲です。興味深いのは2番目のスパンです。

ここでは、スパンに 4 つのポイントがあります。

• 最初のポイントは、「サービス 1」のクライアントがリクエストを開始するタイミングを指します。
• 2 番目のポイントは、「サービス 2」がリクエストの処理を開始する時間です。
• 3 番目のポイントは、「サーバー 1」上のクライアントが応答の受信を完了した時間です。
• 最後に、「サーバー 2」の最後の部分が完成しました。

そこで、分散トレースを Spring Cloud Sleuth と統合し、Zipkin を使用してトレースを視覚化する方法を確認しました。