--- title: "OpenTelemetryを使ったエンドツーエンドトレーシング - API7.ai" description: "この記事では、Observability（可観測性）の世界への第一歩を踏み出す方法と、OpenTelemetryを使用したエンドツーエンドのトレーシングの活用について説明します。" url: "https://api7.ai/ja/blog/end-to-end-tracing-opentelemetry" --- [Blog](https://api7.ai/ja/blog) [Products](https://api7.ai/ja/category/products)[Technology](https://api7.ai/ja/category/technology)[Ecosystem](https://api7.ai/ja/category/ecosystem)[Case Study](https://api7.ai/ja/category/usercase)[Team & Community](https://api7.ai/ja/category/community) Search ⌘ + K [Blog](https://api7.ai/blog) Ecosystem # OpenTelemetryを使ったエンドツーエンドトレーシング [![Nicolas Fränkel](https://avatars.githubusercontent.com/u/752258?v=4)](https://github.com/nfrankel) [Nicolas Fränkel](https://github.com/nfrankel) August 31, 2022 [Ecosystem](https://api7.ai/category/ecosystem) マイクロサービスを実装するかどうか（そしておそらく実装すべきではない）に関わらず、あなたのシステムはおそらく複数のコンポーネントで構成されています。最もシンプルなシステムは、リバースプロキシ、アプリケーション、データベースで構成されているでしょう。この場合、監視は良いアイデアであるだけでなく、必須です。リクエストが通過するコンポーネントの数が多ければ多いほど、その必要性は高まります。 しかし、監視は旅の始まりに過ぎません。リクエストが大量に失敗し始めたとき、すべてのコンポーネントにわたる集約されたビューが必要です。これは**トレーシング**と呼ばれ、\_オブザーバビリティ\_の柱の一つです。他の2つはメトリクスとログです。 この記事では、トレースに焦点を当て、オブザーバビリティへの旅を始める方法について説明します。 ## W3C Trace Context仕様 トレーシングソリューションは、異なる技術スタック間で動作する標準フォーマットを提供するべきです。そのようなフォーマットは、正式な仕様またはデファクトスタンダードに準拠する必要があります。 仕様が突然現れることは稀であることを理解する必要があります。一般的に、市場にはすでにいくつかの異なる実装が存在しています。ほとんどの場合、新しい仕様は追加の実装を引き起こします。有名なXKCDコミックがそれを描いています： ![the famous XKCD comic describes](https://static.api7.ai/2022/10/03/633a3d1d1acbc.png?imageMogr2/format/webp) しかし、時には奇跡が起こります：市場が新しい仕様に従うことがあります。ここで、Trace ContextはW3Cの仕様であり、それがうまくいったようです： > この仕様は、分散トレーシングシナリオを可能にするコンテキスト情報を伝播するための標準HTTPヘッダーと値のフォーマットを定義します。この仕様は、サービス間でコンテキスト情報がどのように送信され、変更されるかを標準化します。コンテキスト情報は、分散システム内の個々のリクエストを一意に識別し、プロバイダー固有のコンテキスト情報を追加および伝播する手段も定義します。 -- このドキュメントから2つの重要な概念が浮かび上がります： - **トレース**は、複数のコンポーネントにまたがるリクエストのパスを追跡します - **スパン**は単一のコンポーネントにバインドされ、親子関係によって別のスパンにリンクされます !\[トレースとスパン]\( "トレースとスパン" "トレースとスパン") この記事を書いている時点で、この仕様はW3Cの推奨事項であり、これは**最終**段階です。 Trace Contextにはすでに[多くの実装](https://github.com/w3c/trace-context/blob/main/implementations.md)があります。そのうちの一つがOpenTelemetryです。 ## OpenTelemetryをゴールデンスタンダードとして ITの運用部分に近ければ近いほど、OpenTelemetryについて聞いたことがある可能性が高くなります： > OpenTelemetryは、ツール、API、SDKのコレクションです。これを使用して、ソフトウェアのパフォーマンスと動作を分析するためのテレメトリデータ（メトリクス、ログ、トレース）を計測、生成、収集、エクスポートします。OpenTelemetryは、いくつかの言語で一般的に利用可能であり、使用に適しています。 -- OpenTelemetryはCNCFが管理するプロジェクトです。OpenTelemetryの前には2つのプロジェクトがありました： - OpenTracing：その名の通り、トレースに焦点を当てていました - OpenCensus：メトリクスとトレースを管理することを目的としていました 両プロジェクトが統合され、ログが追加されました。OpenTelemetryは現在、オブザーバビリティに焦点を当てた一連の「レイヤー」を提供しています： - さまざまな言語での計測API - さまざまな言語での正規の実装 - コレクターなどのインフラストラクチャコンポーネント - W3CのTrace Contextなどの相互運用性フォーマット OpenTelemetryはTrace Contextの実装ですが、それ以上のことを行います。Trace ContextはHTTPに限定されていますが、OpenTelemetryはKafkaなどの非Webコンポーネントをまたがるスパンを許可します。これはこのブログ記事の範囲外です。 ## ユースケース 私のお気に入りのユースケースはeコマースショップなので、それを変更しないことにしましょう。この場合、ショップはマイクロサービスを中心に設計されており、それぞれがREST APIを介してアクセス可能で、APIゲートウェイの背後で保護されています。ブログ記事のためのアーキテクチャを簡素化するために、2つのマイクロサービスのみを使用します：`catalog`は製品を管理し、`pricing`は製品の価格を処理します。 ユーザーがアプリに到着すると、ホームページがすべての製品を取得し、それぞれの価格を取得して表示します。 ![複数のコンポーネントをまたがるリクエストフローの例](https://static.api7.ai/2022/10/03/633a3d1d29f7e.png?imageMogr2/format/webp) さらに興味深くするために、`catalog`はKotlinでコーディングされたSpring Bootアプリケーションであり、`pricing`はPython Flaskアプリケーションです。 トレーシングにより、リクエストのパスをゲートウェイ、両方のマイクロサービス、そして可能であればデータベースをまたがって追跡できるようにする必要があります。 ## ゲートウェイでのトレース エントリーポイントはトレーシングの最も興味深い部分です。なぜなら、トレースIDを生成するべきだからです：この場合、エントリーポイントはゲートウェイです。デモを実装するためにApache APISIXを使用します： > Apache APISIXは、ロードバランシング、ダイナミックアップストリーム、カナリアリリース、サーキットブレーカー、認証、オブザーバビリティなどの豊富なトラフィック管理機能を提供します。-- Apache APISIXはプラグインアーキテクチャに基づいており、OpenTelemetryプラグインを提供します： > `opentelemetry`プラグインは、OpenTelemetry仕様に従ってトレーシングデータを報告するために使用できます。このプラグインは、HTTPを介したバイナリエンコードされたOLTPのみをサポートします。-- `opentelemetry`プラグインを設定しましょう： ``` apisix: enable_admin: false #1 config_center: yaml #1 plugins: - opentelemetry #2 plugin_attr: opentelemetry: resource: service.name: APISIX #3 collector: address: jaeger:4318 #4 ``` 1. デモを簡単に追跡できるように、Apache APISIXをスタンドアロンモードで実行します。これは本番環境でも良いプラクティスです 2. `opentelemetry`をグローバルプラグインとして設定します 3. サービスの名前を設定します。これはトレース表示コンポーネントに表示される名前です 4. トレースを`jaeger`サービスに送信します。次のセクションで説明します。 すべてのルートをトレースしたいので、各ルートにプラグインを追加する代わりに、プラグインをグローバルに設定するべきです： ``` global_rules: - id: 1 plugins: opentelemetry: sampler: name: always_on #1 ``` 1. トレーシングはパフォーマンスに影響を与えます。トレースするほど、パフォーマンスへの影響が大きくなります。したがって、パフォーマンスへの影響とオブザーバビリティの利点を慎重にバランスを取るべきです。しかし、デモではすべてのリクエストをトレースしたいと思います。 ## トレースの収集、保存、表示 Trace ContextはW3Cの仕様であり、OpenTelemetryはデファクトスタンダードですが、市場にはトレースを収集、保存、表示するための多くのソリューションが存在します。各ソリューションは、これら3つの機能のすべてを提供する場合もあれば、一部のみを提供する場合もあります。例えば、Elasticスタックは保存と表示を処理しますが、収集には他のものに頼る必要があります。一方、[Jaeger](https://www.jaegertracing.io/docs/1.18/opentelemetry/)と[Zipkin](https://zipkin.io/)は、これら3つの機能をすべて満たす完全なスイートを提供します。 JaegerとZipkinはOpenTelemetryよりも前から存在しているため、それぞれ独自のトレーストランスポートフォーマットを持っています。ただし、OpenTelemetryフォーマットとの統合も提供しています。 このブログ記事の範囲では、正確なソリューションは重要ではありません。必要なのは機能だけです。私はJaegerを選択しました。なぜなら、すべての機能を1つのDockerイメージに含むオールインワンイメージを提供しているからです。すべての機能にはそれぞれのコンポーネントがありますが、同じイメージに組み込まれているため、設定がはるかに簡単になります。 イメージの[関連ポート](https://www.jaegertracing.io/docs/1.37/getting-started/#all-in-one)は次のとおりです： | ポート | プロトコル | コンポーネント | 機能 | | ------- | ----- | ------- | ---------------------------------------------------- | | `16686` | HTTP | クエリ | フロントエンドを提供 | | `4317` | HTTP | コレクター | OpenTelemetry Protocol (OTLP) over gRPCを受け入れる（有効な場合） | | `4318` | HTTP | コレクター | OpenTelemetry Protocol (OTLP) over HTTPを受け入れる（有効な場合） | Docker Composeの設定は次のようになります： ``` services: jaeger: image: jaegertracing/all-in-one:1.37 #1 environment: - COLLECTOR_OTLP_ENABLED=true #2 ports: - "16686:16686" #3 ``` 1. `all-in-one`イメージを使用します 2. 非常に重要：OpenTelemetryフォーマットでコレクターを有効にします 3. UIポートを公開します インフラストラクチャを設定したので、アプリケーションでトレースを有効にすることに集中できます。 ## Flaskアプリでのトレース `pricing`サービスはシンプルな[Flask](https://flask.palletsprojects.com/)アプリケーションです。データベースから単一の製品の価格を取得するための単一のエンドポイントを提供します。 ``` @app.route('/price/') #1-2 def price(product_str: str) -> Dict[str, object]: product_id = int(product_str) price: Price = Price.query.get(product_id) #3 if price is None: return jsonify({'error': 'Product not found'}), 404 else: low: float = price.value - price.jitter #4 high: float = price.value + price.jitter #4 return { 'product_id': product_id, 'price': round(uniform(low, high), 2) #4 } ``` 1. エンドポイント 2. ルートは製品のIDを必要とします 3. SQLAlchemyを使用してデータベースからデータを取得します 4. 実際の価格エンジンは時間とともに同じ価格を返すことはありません。楽しみのために価格を少しランダム化しましょう 警告：1回の呼び出しで単一の価格を取得することは非常に非効率的です。製品の数だけ呼び出しが必要ですが、トレースをより興味深くするために行っています。実際の運用では、ルートは複数の製品IDを受け入れ、1つのリクエスト-レスポンスで関連するすべての価格を取得できるべきです。 次に、アプリケーションを計測する時が来ました。2つのオプションがあります：自動計測と手動計測です。自動計測は低労力で即効性がありますが、手動計測は開発時間を集中させる必要があります。私は、まず自動計測から始め、必要に応じて手動計測を追加することをお勧めします。 いくつかのPythonパッケージを追加する必要があります： ``` opentelemetry-distro[otlp]==0.33b0 opentelemetry-instrumentation opentelemetry-instrumentation-flask ``` いくつかのパラメータを設定する必要があります： ``` pricing: build: ./pricing environment: OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4317 #1 OTEL_RESOURCE_ATTRIBUTES: service.name=pricing #2 OTEL_METRICS_EXPORTER: none #3 OTEL_LOGS_EXPORTER: none #3 ``` 1. トレースをJaegerに送信します 2. サービスの名前を設定します。これはトレース表示コンポーネントに表示される名前です 3. ログやメトリクスには興味がありません 次に、標準の`flask run`コマンドの代わりに、それをラップします： ``` opentelemetry-instrument flask run ``` これだけで、メソッド呼び出しやFlaskルートからのスパンを収集できます。 必要に応じて、手動で追加のスパンを追加することもできます。例えば： ``` from opentelemetry import trace @app.route('/price/') def price(product_str: str) -> Dict[str, object]: product_id = int(product_str) with tracer.start_as_current_span("SELECT * FROM PRICE WHERE ID=:id", attributes={":id": product_id}) as span: #1 price: Price = Price.query.get(product_id) # ... ``` 1. 設定されたラベルと属性を持つ追加のスパンを追加します ## Spring Bootアプリでのトレース `catalog`サービスは、Kotlinで開発されたReactiveな[Spring Boot](https://spring.io/projects/spring-boot)アプリケーションです。2つのエンドポイントを提供します： - 1つは単一の製品を取得するため - もう1つはすべての製品を取得するため 両方とも、まず製品データベースを参照し、その後、上記の`pricing`サービスに価格を問い合わせます。 Pythonと同様に、自動計測と手動計測を活用できます。まず、低いハードルの自動計測から始めましょう。JVMでは、エージェントを介してこれを実現します： ``` java -javaagent:opentelemetry-javaagent.jar -jar catalog.jar ``` Pythonと同様に、すべてのメソッド呼び出しとHTTPエントリーポイントのスパンを作成します。また、JDBC呼び出しも計測しますが、Reactiveスタックを使用しているため、R2DBCを使用します。記録のために、サポートを追加するための[GitHub issue](https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/2515)が開かれています。 デフォルトの動作を設定する必要があります： ``` catalog: build: ./catalog environment: APP_PRICING_ENDPOINT: http://pricing:5000/price OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4317 #1 OTEL_RESOURCE_ATTRIBUTES: service.name=orders #2 OTEL_METRICS_EXPORTER: none #3 OTEL_LOGS_EXPORTER: none #3 ``` 1. トレースをJaegerに送信します 2. サービスの名前を設定します。これはトレース表示コンポーネントに表示される名前です 3. ログやメトリクスには興味がありません Pythonと同様に、手動計測を追加することでゲームを上げることができます。2つのオプションがあります：プログラムによるものとアノテーションベースのものです。前者は少し複雑ですが、Spring Cloud Sleuthを導入しない限りは少し手間がかかります。アノテーションを追加しましょう。 追加の依存関係が必要です： ``` io.opentelemetry.instrumentation opentelemetry-instrumentation-annotations 1.17.0-alpha ``` 注意：このアーティファクトは最近`io.opentelemetry:opentelemetry-extension-annotations`から移動されました。 これで、コードにアノテーションを追加できます： ``` @WithSpan("ProductHandler.fetch") //1 suspend fun fetch(@SpanAttribute("id") id: Long): Result { //2 val product = repository.findById(id) return if (product == null) Result.failure(IllegalArgumentException("Product $id not found")) else Result.success(product) } ``` 1. 設定されたラベルを持つ追加のスパンを追加します 2. パラメータを属性として使用し、キーを`id`に設定し、値はパラメータの実行時値です ## 結果 これで、シンプルなデモを操作して結果を見ることができます： ``` curl localhost:9080/products curl localhost:9080/products/1 ``` レスポンスは興味深いものではありませんが、Jaeger UIを見てみましょう。両方のトレースが見つかります。1つは呼び出しごとです： ![Jaeger UIでのトレースのリスト](https://static.api7.ai/2022/10/03/633a3b371df19.jpg?imageMogr2/format/webp) 単一のトレースのスパンを詳しく見ることができます： ![単一のトレースを構成するすべてのスパン](https://static.api7.ai/2022/10/03/633a3d1cac655.jpg?imageMogr2/format/webp) 上記のUML図がなくても、シーケンスフローを推測できることに注意してください。さらに良いことに、シーケンスはコンポーネント内部の呼び出しを表示します。 各スパンには、自動計測によって追加された属性と、手動で追加した属性が含まれています： ![スパンの属性](https://static.api7.ai/uploads/2023/08/02/c9716Cc1_span-attributes.jpg?imageMogr2/format/webp) ## 結論 この記事では、APIゲートウェイ、異なる技術スタックに基づく2つのアプリケーション、およびそれぞれのデータベースをまたがるリクエストを追跡することで、トレーシングを紹介しました。トレーシングの表面だけをかすめました：実際の世界では、トレーシングにはKafkaやメッセージキューなどのHTTPに関連しないコンポーネントが含まれる可能性があります。 それでも、ほとんどのシステムは何らかの形でHTTPに依存しています。設定は簡単ではありませんが、それほど難しくもありません。コンポーネントをまたがるHTTPリクエストをトレースすることは、システムのオブザーバビリティへの旅を始める良いスタートです。 この記事の完全なソースコードは[GitHub](https://github.com/nfrankel/opentelemetry-tracing)にあります。 **さらに進むために：** - [W3C Trace Context仕様](https://www.w3.org/TR/trace-context/) - [Trace Contextの実装](https://github.com/w3c/trace-context/blob/main/implementations.md) - [OpenTelemetryの初心者向けガイド](https://medium.com/@magstherdev/opentelemetry-d71d369c83d7) - [Python自動計測](https://opentelemetry.io/docs/instrumentation/python/automatic/) - [Python Distro](https://opentelemetry.io/docs/instrumentation/python/distro/) - [Jaeger Getting Started](https://www.jaegertracing.io/docs/next-release/getting-started/) Tags: [OpenTelemetry](https://api7.ai/tags/opentelemetry) [API Gateway Concept](https://api7.ai/tags/api-gateway-concept) Share article link Share Related Posts [![API GatewayとConsulを統合する方法](https://static.api7.ai/apisix-webp/2022/blog/0818/ecosystem/HashiCorp%20Consul.webp)](https://api7.ai/blog/integrate-consul-kv-with-apache-apisix) ## [API GatewayとConsulを統合する方法](https://api7.ai/blog/integrate-consul-kv-with-apache-apisix) [![実世界におけるAPIゲートウェイの選定：技術評価プロセスの内側](https://static.api7.ai/uploads/2025/06/03/E7OqOddo_api-gateway-decision.webp)](https://api7.ai/blog/api-gateway-decision-inside-technical-evaluation) ## [実世界におけるAPIゲートウェイの選定：技術評価プロセスの内側](https://api7.ai/blog/api-gateway-decision-inside-technical-evaluation) Table of Contents - [W3C Trace Context仕様](#w3c-trace-context%E4%BB%95%E6%A7%98) - [OpenTelemetryをゴールデンスタンダードとして](#opentelemetry%E3%82%92%E3%82%B4%E3%83%BC%E3%83%AB%E3%83%87%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89%E3%81%A8%E3%81%97%E3%81%A6) - [ユースケース](#%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9) - [ゲートウェイでのトレース](#%E3%82%B2%E3%83%BC%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A4%E3%81%A7%E3%81%AE%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9) - [トレースの収集、保存、表示](#%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%81%AE%E5%8F%8E%E9%9B%86%E4%BF%9D%E5%AD%98%E8%A1%A8%E7%A4%BA) - [Flaskアプリでのトレース](#flask%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7%E3%81%AE%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9) - [Spring Bootアプリでのトレース](#spring-boot%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7%E3%81%AE%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9) - [結果](#%E7%B5%90%E6%9E%9C) - [結論](#%E7%B5%90%E8%AB%96) ## Related Posts [![Amazonを活用したApache APISIXのエコシステムと成長](https://static.api7.ai/uploads/2023/01/12/I6dWwBSn_aws.png)](https://api7.ai/ja/blog/leverage-amazon-for-apisix-ecosystem-and-growth) Ecosystem October 26, 2022 #### [Amazonを活用したApache APISIXのエコシステムと成長](https://api7.ai/ja/blog/leverage-amazon-for-apisix-ecosystem-and-growth) 本記事では、Apache APISIXとそのAWS向けプラグイン、APISIXがAWSプロセッサを使用してどのように動作するか、そしてAPI7 CloudがAmazonを活用して急速な成長を実現する方法について紹介します。 [APISIX Basics](https://api7.ai/tags/apisix-basics) [API Gateway Concept](https://api7.ai/tags/api-gateway-concept) [API7 Cloud](https://api7.ai/tags/api7-cloud) [![gRPCとは何か？APISIXとの連携方法](https://static.api7.ai/uploads/2023/01/12/uMWcrTdz_grpc.png)](https://api7.ai/ja/blog/what-is-grpc-and-how-to-work-with-apisix) Ecosystem September 28, 2022 #### [gRPCとは何か？APISIXとの連携方法](https://api7.ai/ja/blog/what-is-grpc-and-how-to-work-with-apisix) gRPC 是一种现代的开源高性能远程过程调用（RPC）框架，可以在任何环境中运行。我们在 OpenResty 生态系统中实现了一个 gRPC 客户端。 [APISIX Basics](https://api7.ai/tags/apisix-basics) [API Gateway Concept](https://api7.ai/tags/api-gateway-concept) [gRPC](https://api7.ai/tags/grpc) [![GCP、AWS、AzureのARMベースサーバーパフォーマンス比較](https://static.api7.ai/2022/11/18/6377328aa91b2.png)](https://api7.ai/ja/blog/arm-performance-google-aws-azure-with-apisix) Ecosystem August 12, 2022 #### [GCP、AWS、AzureのARMベースサーバーパフォーマンス比較](https://api7.ai/ja/blog/arm-performance-google-aws-azure-with-apisix) This article uses Apache APISIX to compare the performance of Google, AWS, and Azure ARM-based servers in network IO-intensive scenarios. [API Gateway Concept](https://api7.ai/tags/api-gateway-concept) [Comparison to Competitors](https://api7.ai/tags/comparison-to-competitors)