OpenTelemetry は理解しやすいです。

この投稿は、OpenTelemetry の基本的な理解を深めることを目的としています。取り上げるトピックは次のとおりです。

分散トレース
OpenTelemetry とは何ですか?
OpenTelemetry 計測 (自動および手動)
オープンテレメトリプロトコル (OTLP)
OpenTelemetry コレクター
OpenTelemetry Collectors の展開モード
OpenTelemetry バックエンド
Kubernetes 上の OpenTelemetry
OpenTelemetry オペレーター
OpenTelemetry サンプルアプリケーション

この記事を最後まで読めば、OpenTelemetry Operator を使用して、コードを変更せずにアプリケーションにトレースを実装する方法がわかります。

分散トレース

まず、分散トレースとは何か、そしてなぜそれが必要なのかを理解しましょう。

なぜ追跡が必要なのでしょうか?

分散トレースはなぜ必要なのでしょうか?なぜメトリックとログを使用できないのでしょうか?以下に示すようなマイクロサービスアーキテクチャがあると仮定します。

ここで、クライアントからのリクエストを想像してください。

上記のアーキテクチャ図から、リクエストが数十または数百のネットワーク呼び出しを経由する可能性があることがわかります。これにより、リクエストがたどるパス全体を把握することが難しくなり、ログとメトリックしかない場合はトラブルシューティングが非常に複雑になります。

アプリケーションに問題が発生した場合、多くの問題を解決する必要があります。

根本的な原因をどうやって見つけるのでしょうか?
通過するすべてのサービスをどのように監視するのでしょうか?

分散トレースは、リクエスト全体にわたるサービス間のやり取りを確認するのに役立ち、システム内のリクエストのライフサイクル全体に関する洞察を提供できます。アプリケーション内のバグ、ボトルネック、パフォーマンスの問題を見つけるのに役立ちます。

トレースはユーザーがアプリケーションと対話した瞬間から開始され、最後のレイヤーまでのリクエスト全体を確認できるはずです。

トレースデータ (スパンの形式) は、リクエストの遅延やエラーがどのように発生したか、また、それらがリクエスト全体にどのような影響を与えたかを理解するのに役立つ情報 (メタデータ) を生成します。

分散トレースについて詳しく知りたい場合は、「分散トレースの初心者向けガイド」を読んで、マイクロサービスアーキテクチャを監視する方法を学んでください。

追跡を実現するにはどうすればいいですか?

追跡を実現するには、次のことを行う必要があります。

アプリケーションをインストルメント化します。
データを収集して処理します。
クエリを実行できるようにデータを保存および視覚化します。

この目的のために、OpenTelemetry と Jaeger という 2 つのオープンソースプロジェクトを使用できます。

OpenTelemetry とは何ですか?

OpenTelemetry を使用して、アプリケーションからデータを収集できます。これは、アプリケーションのパフォーマンスと動作を分析するために、テレメトリデータ (メトリック、ログ、トレース) をインストルメント化、生成、収集、エクスポートするために使用できるツール、API、SDK のセットです。

OpenTelemetry とは:

オープンソース
可観測性の業界リーダーによって採用され、サポートされています
CNCFプロジェクト
ベンダー中立

OpenTelemetry には、トレース、メトリック、ログという可観測性の 3 つの柱が含まれます。（この記事では追跡に焦点を当てます）

分散トレースは、分散システムでサービス要求を最初から最後まで追跡する方法です。
メトリックは、システムまたはアプリケーションのパフォーマンスを理解するために、一定期間にわたってアクティビティを測定するものです。
ログは、特定の時点でシステムまたはアプリケーションで発生したイベントのテキスト記録です。

OpenTelemetryはベンダー中立です

OpenTelemetry は、トレースの生成を標準化することを目的として、ベンダー中立の観測可能性標準を提供します。 OpenTelemetry を使用すると、検出ポイントをバックエンドから分離できます。つまり、私たちはいかなるツール（またはベンダー）にも依存しません。

任意のプログラミング言語を使用できるだけでなく、互換性のあるストレージバックエンドも選択できるため、特定の商用ベンダーに縛られることがなくなります。

開発者は、データがどこに保存されるかを知らなくても、アプリケーションをインストルメント化できます。

OpenTelemetry は、トレースデータを作成するためのツールを提供します。このデータを取得するには、まずデータを収集するようにアプリケーションをインストルメント化する必要があります。これを行うには、OpenTelemetry SDK を使用する必要があります。

検出（埋設点）

アプリケーションの計測データは、自動または手動 (あるいはハイブリッド) のいずれかの方法で生成できます。 OpenTelemetry を使用してアプリケーションをインストルメント化するには、OpenTelemetry リポジトリに移動し、アプリケーションの言語を選択して、指示に従います。

自動検出

自動検出の使用はシンプルで簡単で、多くのコード変更を必要としないため、良いアプローチです。

このアプローチは、アプリケーションに合わせてトラッキングコードを作成するための必要な知識 (または時間) がない場合に適しています。

自動検出を使用すると、事前定義されたスパンのセットが作成され、関連するプロパティが入力されます。

手動検出

手動インストルメンテーションでは、アプリケーションに固有のインストルメンテーションコードを記述する必要があります。これは、アプリケーションに監視コードを追加するプロセスです。プロパティとイベントを自分で追加できるため、ニーズに応じてこの方法の方が効率的である可能性があります。この方法の欠点は、ライブラリをインポートして、すべての作業を自分で行う必要があることです。

スプレッダー

W3C tracecontext、baggage、b3 などのプロパゲータを構成に追加できます。

さまざまなプロパゲータが、プロセス境界を越えてコンテキストデータを伝播するための特定の動作を定義します。

トレースコンテキスト: トレースデータを HTTP ヘッダーにエンコードして、異なるサービス間で渡すことができるようにするのに使用されます。
Baggage: ユーザー ID、リクエスト ID など、スパン間でキーと値のペアのデータを渡すために使用されます。
B3: 異なるサービス間でデータを転送できるように、HTTP ヘッダー内のトレースデータをエンコードするために使用されます (主に Zipkin またはその互換システムで使用されます)。

サンプリング

サンプリングは、収集されてバックエンドに送信されるトレースサンプルの数を減らすことで、OpenTelemetry によって導入されるノイズとオーバーヘッドを制御するメカニズムです。

OpenTelemetry は、送信されるトレース/トラフィックの数に基づいてサンプリングを実行するように指示できます。 (たとえば、追跡データの 10% のみをサンプリングする)。

一般的なサンプリング手法には、ヘッドサンプリングとテールサンプリングの 2 つがあります。

オープンテレメトリプロトコル (OTLP)

OpenTelemetry Protocol (OTLP) 仕様は、テレメトリソース、コレクター、およびテレメトリバックエンド間のテレメトリデータのエンコード、転送、および配信メカニズムを記述します。

各言語 SDK には、OTLP を介してデータをエクスポートするように構成できる OTLP エクスポーターが用意されています。 OpenTelemetry SDK はイベントを OTLP データに変換します。

OTLP は、エージェント (エクスポーターとして構成) とコレクター (レシーバーとして構成) 間の通信です。

OpenTelemetry コレクター

アプリケーションテレメトリデータは OpenTelemetry Collectors に送信できます。

コレクターは、テレメトリデータ (スパン、メトリック、ログなど) を受信し、処理 (データの前処理) し、データをエクスポート (目的の通信バックエンドに送信) する OpenTelemetry のコンポーネントです。

受信機

レシーバーは、プッシュまたはプルによってデータがコレクターに入る方法です。 OpenTelemetry コレクターは、さまざまな形式でテレメトリデータを受信できます。

以下は、ポート 4317 (gRPC) および 4318 (http) で OTLP データを受け入れる受信機の構成例です。

 otlp: protocols: http: grpc: endpoint: "0.0.0.0:4317"

次の例でも、テレメトリデータを Jaeger Thrift HTTP プロトコルの形式で受信します。

 jaeger: # Jaeger 协议接收器protocols: # 定义接收器支持的协议thrift_http: # 通过Jaeger Thrift HTTP 协议接收数据endpoint: "0.0.0.0:14278"

プロセッサ

データが受信されると、コレクターはデータを処理できます。プロセッサは、取り込みとエクスポートの間でデータを処理します。プロセッサはオプションですが、いくつかは推奨されます。

たとえば、バッチプロセッサが強く推奨されます。バッチプロセッサは、スパン、メトリック、またはログを取得してバッチに格納します。バッチ処理により、データの圧縮率が向上し、データの転送に必要な送信接続の数を減らすことができます。このプロセッサは、サイズベースと時間ベースの両方のバッチ処理をサポートします。

 processors: batch:

プロセッサを構成しても有効にならないことに注意してください。サービスセクションのパイプラインを介して有効にする必要があります。

 service: pipelines: traces: receivers: [jaeger] processors: [batch] exporters: [zipkin]

輸出業者

テレメトリデータを視覚化して分析するには、エクスポーターも使用する必要があります。エクスポータは OpenTelemetry のコンポーネントであり、データをさまざまなシステム/バックエンドに送信する方法です。

たとえば、コンソールエクスポーターは、開発やデバッグのタスクに非常に役立つ一般的なエクスポーターです。データをコンソールに出力します。

エクスポーターセクションでは、さらに送信先を追加できます。たとえば、トレースデータを Grafana Tempo に送信する場合は、次の構成を追加するだけです。

 exporters: logging: otlp: endpoint: "<tempo_endpoint>" headers: authorization: Basic <api_token>

もちろん、有効にするには、サービス部分のパイプラインでも有効にする必要があります。

 service: pipelines: traces: receivers: [otlp] processors: [] exporters: [logging, otlp]

OpenTelemetry にはさまざまなエクスポーターが付属しており、OpenTelemetry Collectors Contrib リポジトリで見つけることができます。

拡張機能

この拡張機能は、テレメトリデータの処理を伴わないタスクに主に適しています。拡張機能の例には、ヘルスモニタリング、サービス検出、データ転送などがあります。拡張機能はオプションです。

拡張機能は主に、テレメトリデータの処理を伴わないタスクを対象としています。たとえば、ヘルスモニタリング、サービス検出、データ転送などです。拡張機能はオプションです。

 extensions: health_check: pprof: zpages: memory_ballast: size_mib: 512

OpenTelemetry Collector の展開モード/戦略

OpenTelemetry コレクターはさまざまな方法で展開できるため、展開方法を検討する必要があります。どの戦略を選択するかは、チームと組織によって異なります。

エージェントモード

この場合、OpenTelemetry によって計測されたアプリケーションは、アプリケーションに常駐する (コレクター) エージェントにデータを送信します。その後、エージェントがアプリケーションからのすべてのトレースデータを引き継いで処理します。

コレクターはサイドカーを介してプロキシとしてデプロイでき、データをストレージバックエンドに直接送信するように構成できます。

ゲートウェイモード

また、データを別の OpenTelemetry コレクターに送信し、そこからさらにデータをストレージバックエンドに送信することもできます。この構成では、自動スケーリングなどの多くの利点があるデプロイメントモードを使用してデプロイされる中央の OpenTelemetry コレクターがあります。

中央コレクターを使用する利点は次のとおりです。

チームへの依存を排除
バッチ処理、再試行、暗号化、圧縮の設定/ポリシーを適用する
中央での認証
豊富なメタデータ情報
サンプリングの決定
HPA によるスケーリング

展開モードの概要

以下に、一般的な展開戦略をいくつかまとめます。

基本 - クライアントは計測に OTLP を使用し、データを一連のコレクターに送信します。

データは複数のエクスポーターに送信できます。

Kubernetes に OpenTelemetry Collector をデプロイするときに使用できるモード。

サイドカーモード:

エージェントはサイドカーとして機能し、OpenTelemetry Collector を使用してコンテナーがワークロードポッドに追加されます。次に、インスタンスは、別の名前空間またはクラスターにある可能性のある外部コレクターにデータを送信するように構成されます。

デーモンセットモード:

エージェントは DaemonSet として使用されるため、Kubernetes ノードごとにエージェントポッドが存在します。

負荷分散 - トレース ID に基づく負荷分散:

マルチクラスタ - エージェント、ワークロード、コントロールプレーンコレクター:

マルチテナントモード

2 人のテナント、それぞれ独自のイェーガーを所有。

信号モード

2 つのコレクター (テレメトリデータの種類ごとに 1 つ)。

OpenTelemetry バックエンド

OpenTelemetry コレクターは独自のバックエンドを提供しないため、任意のベンダーまたはオープンソース製品を使用できます。

OpenTelemetry は独自のバックエンドを提供していませんが、これを使用することでベンダーに依存しないため、どのツールやベンダーにも依存しなくなります。任意のプログラミング言語を使用できるだけでなく、ストレージバックエンドを選択し、別のエクスポーターを構成するだけで別のバックエンド/ベンダーに簡単に切り替えることができます。

テレメトリデータを視覚化して分析するには、OpenTelemetry コレクターでエクスポーターを構成するだけです。

たとえば、Jaeger はデータの分析とクエリを行うための非常に人気のあるオープンソース製品です。

OpenTelemetry コレクターで Jaeger エクスポーターを設定して、データを Jaeger に送信できます。

 exporters: jaeger: endpoint: "http://localhost:14250"

Kubernetes 上の OpenTelemetry

Kubernetes で OpenTelemetry を使用するには、主に OpenTelemetry コレクターをデプロイする必要があります。 OpenTelemetry コレクターを簡単にデプロイおよび管理し、アプリケーションを自動的にインストルメント化できるため、デプロイには OpenTelemetry Operator を使用することをお勧めします。

展開する

ここでは、Helm Chart を使用して OpenTelemetry Operator をデプロイします。まず、Helm Chart リポジトリを追加します。

 $ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts $ helm repo update

デフォルトでは、OpenTelemetry Operator が正しく構成されていることを確認するために、アドミッションコントローラーがデプロイされます。 APIServer が Webhook コンポーネントと通信するには、Webhook に APIServer によって信頼されるように設定された TLS 証明書が必要です。

簡単にするために、ここでは署名証明書を自動的に生成する方法を使用します。次のコマンドを使用して、OpenTelemetry Operator をワンクリックでインストールします。

 $ helm upgrade --install --set admissionWebhooks.certManager.enabled=false --set admissionWebhooks.certManager.autoGenerateCert=true opentelemetry-operator open-telemetry/opentelemetry-operator --namespace kube-otel --create-namespace

通常のデプロイが完了すると、対応する Pod が正常に実行されていることがわかります。

 $ kubectl get pods -n kube-otel -l app.kubernetes.io/name=opentelemetry-operator NAME READY STATUS RESTARTS AGE opentelemetry-operator-6f77dc895c-4wn8z 2/2 Running 0 33s

さらに、OpenTelemetry 関連の CRD が 2 つ自動的に追加されます。

 $ kubectl get crd |grep opentelemetry instrumentations.opentelemetry.io 2023-09-05T03:23:28Z opentelemetrycollectors.opentelemetry.io 2023-09-05T03:23:28Z

この時点で、OpenTelemetry Operator がデプロイされます。

次に、ここで中央の OpenTelemetry コレクターを使用し、他の OpenTelemetry エージェントがそのコレクターにデータを送信できるようにします。エージェントから受信したデータは、このコレクターで処理され、エクスポーターを介してストレージバックエンドに送信されます。ワークフロー全体を次の図に示します。

以下に示すように、OpenTelemetryCollector インスタンスオブジェクトを作成します。

 # central-collector.yaml apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: simplest spec: config: | receivers: otlp: protocols: grpc: http: processors: memory_limiter: check_interval: 1s limit_percentage: 75 spike_limit_percentage: 15 batch: send_batch_size: 10000 timeout: 10s exporters: logging: otlp: endpoint: "<tempo_endpoint>" headers: authorization: Basic <api_token> # echo -n "<your user id>:<your api key>" | base64 service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, batch] exporters: [logging, otlp]

ここで、OpenTelemetry Collector は grpc プロトコルと http プロトコルの両方を通じてテレメトリデータを受信し、ログエクスポートと Grafana Tempo を通じてこれらのスパンを記録します。Grafana Tempo は、スパンを受信する OpenTelemetry Collector インスタンスのコンソールと Grafana Tempo バックエンドにスパンを書き込みます。

次に、Sidecar パターンを使用して OpenTelemetry エージェントをデプロイします。エージェントは、アプリケーションからのトレースを中央 (ゲートウェイ) OpenTelemetry コレクターに送信します。

 # sidecar.yaml apiVersion: opentelemetry.io/v1alpha1 kind: OpenTelemetryCollector metadata: name: sidecar spec: mode: sidecar config: | receivers: otlp: protocols: grpc: http: processors: batch: exporters: logging: otlp: endpoint: "<path_to_central_collector>.<namespace>:4317" service: telemetry: logs: level: "debug" pipelines: traces: receivers: [otlp] processors: [] exporters: [logging, otlp]

自動検出

OpenTelemetry Operator は、OpenTelemetry 自動インストルメンテーションライブラリを挿入して構成できます。現在、DotNet、Java、NodeJS、Python、Golang をサポートしています (手動で有効にする必要があります)。

自動インストルメンテーションを使用するには、SDK にインストルメンテーションリソースとインストルメンテーション構成を追加する必要があります。たとえば、Java アプリケーションの場合、構成は次のようになります。

 apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: java-instrumentation spec: propagators: - tracecontext - baggage - b3 sampler: type: always_on java:

Python アプリケーションの場合、構成は次のようになります。

 apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: python-instrumentation spec: propagators: - tracecontext - baggage - b3 sampler: type: always_on python:

検出を有効にするには、デプロイメントファイルを更新し、それに注釈を追加する必要があります。このようにして、OpenTelemetry Operator にサイドカーと Java インストルメンテーションをアプリケーションに挿入するように指示します。

 annotations: instrumentation.opentelemetry.io/inject-java: "true" sidecar.opentelemetry.io/inject: "true"

サンプルアプリケーション

ここでは、Maven または Gradle を使用して構築された Spring Boot アプリケーションである Petclinic という Java アプリケーションを使用します。アプリケーションは OpenTelemetry を使用してデータを生成します。

Java アプリケーションの場合、OpenTelemetry が提供する opentelemetry-javaagent jar パッケージをダウンロードすることで、OpenTelemetry を使用してアプリケーションを自動的に検出できます。

この jar パッケージをアプリケーションの起動コマンドに追加するだけです。次に例を示します。

 java -javaagent:opentelemetry-javaagent.jar -jar target/*.jar

Java 自動検出では、任意の Java 8+ アプリケーションに接続できる Java エージェント JAR が使用されます。多くの一般的なライブラリやフレームワークからテレメトリデータをキャプチャするためにバイトコードを動的に挿入します。これを使用すると、受信リクエスト、送信 HTTP 呼び出し、データベース呼び出しなど、アプリケーションまたはサービスの「エッジ」でテレメトリデータをキャプチャできます。上記のコマンドを実行すると、アプリケーションを変更することなく、アプリケーションをインストルメント化し、リンクデータを生成できます。

特に Kubernetes 環境では、OpenTelemetry Operator を使用して OpenTelemetry 自動検出ライブラリを挿入および構成できるため、javaagent を手動で挿入する必要さえありません。

まず、Petclinic アプリケーションをデプロイします。

 apiVersion: apps/v1 kind: Deployment metadata: name: petclinic spec: selector: matchLabels: app: petclinic template: metadata: labels: app: petclinic spec: containers: - name: app image: cnych/spring-petclinic:latest

次に、Java アプリケーションに Instrumentation リソースを追加します。

 # java-instrumentation.yaml apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: java-instrumentation spec: propagators: - tracecontext - baggage - b3 sampler: type: always_on java: image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest

自動検出を有効にするには、デプロイメントファイルを更新し、それに注釈を追加する必要があります。この方法では、OpenTelemetry Operator にサイドカーと Java インストルメンテーションをアプリケーションに挿入するように指示できます。改訂 Deployment 構成は次のとおりです。

 # petclinic.yaml apiVersion: apps/v1 kind: Deployment metadata: name: petclinic spec: selector: matchLabels: app: petclinic template: metadata: labels: app: petclinic annotations: instrumentation.opentelemetry.io/inject-java: "true" sidecar.opentelemetry.io/inject: "sidecar" spec: containers: - name: app image: cnych/spring-petclinic:latest

次に、アプリケーションを公開するために NodePort タイプのサービスを作成します。

 # petclinic-svc.yaml apiVersion: v1 kind: Service metadata: name: petclinic spec: selector: app: petclinic type: NodePort ports: - protocol: TCP port: 80 targetPort: 8080

上記のリソースリストを適用するだけです。

 $ kubectl apply -f central-collector.yaml $ kubectl apply -f sidecar.yaml $ kubectl apply -f java-instrumentation.yaml $ kubectl apply -f petclinic.yaml $ kubectl apply -f petclinic-svc.yaml

通常のデプロイが完了すると、対応する Pod が正常に実行されていることがわかります。

 $ kubectl get pods NAME READY STATUS RESTARTS AGE petclinic-6fdd56f4d7-qfff7 2/2 Running 0 62s simplest-collector-87d8bf9bf-dh8pl 1/1 Running 0 36m $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE petclinic NodePort 10.103.6.52 <none> 80:30941/TCP 46s simplest-collector ClusterIP 10.102.131.126 <none> 4317/TCP,4318/TCP 17m simplest-collector-headless ClusterIP None <none> 4317/TCP,4318/TCP 17m simplest-collector-monitoring ClusterIP 10.98.65.171 <none> 8888/TCP 17m

次に、http://<node_ip>:30941 を通じて Petclinic アプリケーションにアクセスできるようになります。

アプリケーションにアクセスすると、アプリケーションは追跡データを生成し、それを中央コレクターに送信します。 Grafana Tempo にアクセスしてトレースデータを表示できます。また、中央コレクターのコンソールにアクセスしてトレースデータを表示することもできます。中央コレクターでは、ログエクスポーターと Grafana Tempo エクスポーターの 2 つのエクスポーターを設定しているため、もちろん他のエクスポーターも設定できます。

 $ kubectl logs -f petclinic-6fdd56f4d7-qfff7 -c otc-container # ...... 2023-09-10T04:11:41.164Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 76} 2023-09-10T04:12:11.012Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 3} 2023-09-10T04:12:16.221Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 23} ^C $ kubectl logs -f simplest-collector-677f4779ff-x8h2m # ...... 2023-09-10T04:11:09.221Z info service/service.go:161 Everything is ready. Begin running and processing data. 2023-09-10T04:11:49.222Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 76} 2023-09-10T04:12:19.224Z info TracesExporter {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 2, "spans": 26}

したがって、Grafana Tempo でも対応する追跡データを確認できます。

同様に、Jaeger エクスポーターを追加すると、Jaeger で対応する追跡データも表示できます。

デプロイ中に問題が発生した場合は、アプリケーションとコンテナのログを表示してトラブルシューティングを行うことができます。

要約する

この投稿では、OpenTelemetry Operator を使用して、コードを変更せずにアプリケーションでトレースを有効にする方法を説明しました。

もちろん、OpenTelemetry で Prometheus を使用してインジケーターデータを収集する方法、OpenTelemetry で Loki を使用してログデータを収集する方法など、ここで取り上げていない内容も多数あります。また、いくつかのサンプリング戦略、プロパゲーター、バッチプロセッサ、手動検出なども含まれています。