用語

Jaegerは、OpenTracing Specification  に触発されたデータモデルでトレースデータを表現します。このデータモデルは、OpenTelemetry Traces  と論理的に非常によく似ていますが、いくつかの命名の違いがあります。

スパン

スパンは、操作名、操作の開始時刻、および期間を持つ論理的な作業単位を表します。スパンは、因果関係をモデル化するためにネストおよび順序付けできます。

トレース

トレースは、システムを通るデータまたは実行パスを表します。スパンの有向非巡回グラフとして考えることができます。

バゲージ

バゲージは、分散コンテキストにアタッチでき、トレースSDKによって伝播できる任意のユーザー定義メタデータ（キーと値のペア）です。詳細については、W3C Baggage  を参照してください。

アーキテクチャ

Jaegerは、すべてのJaegerバックエンドコンポーネントが単一のプロセスで実行されるオールインワンバイナリとして、またはスケーラブルな分散システムとしてデプロイできます。以下に、2つの主要なデプロイメントオプションについて説明します。

ストレージへ直接

このデプロイメントでは、コレクターはトレースされたアプリケーションからデータを受け取り、ストレージに直接書き込みます。ストレージは、平均トラフィックとピークトラフィックの両方を処理できる必要があります。コレクターは、短期的なトラフィックピークを緩和するためにインメモリキューを使用しますが、ストレージが追いつけない場合、持続的なトラフィック急増はデータが失われる可能性があります。

コレクターは、リモートサンプリングモードとして知られる、SDKへのサンプリング構成を集中管理できます。また、適応サンプリングとして知られる、自動サンプリング構成計算を有効にすることもできます。

Kafka経由

コレクターとストレージ間のデータ損失を防ぐために、Kafkaを仲介の永続キューとして使用できます。追加のコンポーネントであるjaeger-ingesterをデプロイして、Kafkaからデータを読み取り、データベースに保存する必要があります。複数のjaeger-ingesterをデプロイして、取り込みをスケールアップできます。それらは自動的に負荷を分割します。

OpenTelemetryコレクターを使用

OpenTelemetry Collectorを使用する必要はありません。なぜなら、jaeger-collectorは（OTLPエクスポーターを使用して）OpenTelemetry SDKから直接OpenTelemetryデータを受信できるからです。ただし、他のタイプのテレメトリの収集や、トレースデータの事前処理/拡張などのために、すでにOpenTelemetryコレクターを使用している場合は、SDKとjaeger-collectorの間に配置できます。OpenTelemetryコレクターは、アプリケーションサイドカー、ホストエージェント/デーモン、または中央クラスターとして実行できます。

OpenTelemetryコレクターはJaegerのリモートサンプリングプロトコルをサポートしており、構成ファイルから直接静的構成を提供するか、Jaegerバックエンド（たとえば、適応サンプリングを使用する場合）へのリクエストをプロキシできます。

サイドカー/ホストエージェントとしてのOpenTelemetryコレクター

メリット

• トレースエクスポートエンドポイントとサンプリング構成エンドポイントの両方をローカルホストに向け、これらのサービスがリモートで実行されている場所を気にする必要がないため、SDK構成が簡素化されます。
• コレクターは、k8sポッド名などの環境情報を追加することで、データのエンリッチメントを提供できます。
• データエンリッチメントのリソース使用量をすべてのアプリケーションホストに分散できます。

デメリット

• データのマーシャリング/アンマーシャリングの追加レイヤー。

リモートクラスターとしてのOpenTelemetryコレクター

メリット

• テールベースサンプリング  を使用する場合などの、シャーディング機能。

デメリット

• データのマーシャリング/アンマーシャリングの追加レイヤー。

コンポーネント

このセクションでは、Jaegerの構成要素とその相互関係について詳しく説明します。アプリケーションからのスパンが対話する順序で配置されています。

トレースSDK

トレーシングデータを生成するためには、アプリケーションをインストルメントする必要があります。インストルメントされたアプリケーションは、新しいリクエストを受信するとスパンを作成し、コンテキスト情報（トレースID、スパンID、およびバゲージ）を発信リクエストに付加します。リクエストとともに伝播されるのはIDとバゲージのみです。操作名、タイミング、タグ、ログなどの他のプロファイリングデータは伝播されません。代わりに、バックグラウンドで非同期的にJaegerバックエンドにプロセス外にエクスポートされます。

アプリケーションをインストルメントする方法はたくさんあります。

• トレーシングAPIを直接使用して手動で行う方法、
• 既存のさまざまなオープンソースフレームワーク向けにすでに作成されているインストルメンテーションに依存する方法、
• バイトコード操作、モンキーパッチ、eBPF、および同様の技術を介して自動的に行う方法。

インストルメンテーションは通常、特定のトレーシングSDKに依存するのではなく、OpenTelemetry APIのような抽象的なトレーシングAPIのみに依存する必要があります。トレーシングSDKはトレーシングAPIを実装し、データエクスポートを処理します。

インストルメンテーションは、本番環境で常にオンになるように設計されています。オーバーヘッドを最小限に抑えるために、SDKはさまざまなサンプリング戦略を採用しています。トレースがサンプリングされると、プロファイリングスパンデータがキャプチャされ、Jaegerバックエンドに送信されます。トレースがサンプリングされない場合、プロファイリングデータはまったく収集されず、トレーシングAPIへの呼び出しは最小限のオーバーヘッドを発生させるために短絡されます。詳細については、サンプリングのページを参照してください。

エージェント

jaeger-agentは、UDP経由で送信されたスパンをリッスンするネットワークデーモンであり、バッチ処理されてコレクターに送信されます。これは、インフラストラクチャコンポーネントとしてすべてのホストにデプロイされるように設計されています。エージェントは、クライアントからのコレクターのルーティングとディスカバリを抽象化します。jaeger-agentは必須のコンポーネントではありません。

コレクター

jaeger-collectorはトレースを受信し、検証とクリーンアップ/エンリッチメントのための処理パイプラインを実行し、ストレージバックエンドに保存します。Jaegerには、いくつかのストレージバックエンド（デプロイメントを参照）の組み込みサポートと、カスタムストレージプラグインを実装するための拡張可能なプラグインフレームワークが付属しています。

クエリ

jaeger-queryは、ストレージからトレースを取得するためのAPIを公開し、トレースを検索および分析するためのWeb UIをホストするサービスです。

インジェスター

jaeger-ingesterは、Kafkaからトレースを読み取り、ストレージバックエンドに書き込むサービスです。事実上、Kafkaを入力プロトコルとしてのみサポートするJaegerコレクターの簡略化版です。