主要な Jaeger バックエンドコンポーネントは、Docker Hub  と Quay  で Docker イメージとしてリリースされています。

上記にリストされているイメージは、主要なリリースバージョンです。ほとんどのコンポーネントには、追加で公開されているイメージがあります。

• ${component}-debug イメージには、Delve デバッガーが含まれています。
• ${component}-snapshot イメージは、メインブランチの先端からすべてのコミットに対して公開され、未リリースバージョンのテストを可能にします。
• ${component}-debug-snapshot は、Delve デバッガーを含むスナップショットイメージです。

Jaeger を実行するためのオーケストレーションテンプレートがあります。

• Kubernetes: github.com/jaegertracing/jaeger-kubernetes 、
• OpenShift: github.com/jaegertracing/jaeger-openshift 。

設定オプション

Jaeger バイナリは、いくつかの方法で設定できます（優先順位の高い順）。

• コマンドライン引数、
• 環境変数、
• JSON、TOML、YAML、HCL、または Java プロパティ形式の設定ファイル。

オプションの完全なリストを確認するには、helpコマンドを使用してバイナリを実行するか、詳細についてはCLI フラグページを参照してください。特定のストレージバックエンドに固有のオプションは、ストレージタイプが選択されている場合にのみ表示されます。たとえば、Cassandra ストレージを使用するコレクターですべての利用可能なオプションを確認するには

$ docker run --rm \
    -e SPAN_STORAGE_TYPE=cassandra \
    jaegertracing/jaeger-collector:1.62.0 \
    help

環境変数を介して設定パラメーターを提供するには、それぞれのコマンドラインオプションを見つけ、その名前を UPPER_SNAKE_CASE に変換します。たとえば

オールインワン

Jaeger オールインワンは、3 つの Jaeger コンポーネントである agent、collector、およびクエリサービス/UI を単一のバイナリまたはコンテナーイメージに組み合わせた特殊なディストリビューションです。単一ノードのデプロイメントで、トレースボリュームが単一インスタンスで処理できるほど少ない場合に便利です。デフォルトでは、オールインワンはmemoryストレージで開始されます。つまり、再起動時にすべてのデータが失われます。その他のspan ストレージバックエンドもオールインワンで使用できますが、memoryとbadgerはインスタンス間で共有できないため、オールインワン専用です。

オールインワンは、管理ポートを除き、含まれているコンポーネントと同じポートをリッスンします（下記参照）。

## make sure to expose only the ports you use in your deployment scenario!
docker run -d --name jaeger \
  -e COLLECTOR_OTLP_ENABLED=true \
  -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14250:14250 \
  -p 14268:14268 \
  -p 14269:14269 \
  -p 4317:4317 \
  -p 4318:4318 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.62.0

http://localhost:16686 にアクセスして Jaeger UI に移動できます。

Agent

jaeger-agent は、UDP 経由で Thrift 形式のトレースデータを受信し、ホストエージェント/デーモンとして、またはアプリケーションサイドカーとして、各ホストでローカルに実行するように設計されています。jaeger-agent は次のポートを公開します。

ホストで直接、または次のように Docker を介して実行できます。

## make sure to expose only the ports you use in your deployment scenario!
docker run \
  --rm \
  -p6831:6831/udp \
  -p6832:6832/udp \
  -p5778:5778/tcp \
  -p5775:5775/udp \
  jaegertracing/jaeger-agent:1.62.0

ディスカバリシステムとの統合

jaeger-agent は、単一のjaeger-collectorアドレスにポイントツーポイントで接続できます。これは、他のインフラストラクチャコンポーネント（例：DNS）によって複数のjaeger-collector間でロードバランスされる可能性があります。jaeger-agent は、jaeger-collector アドレスの静的リストで設定することもできます。

Docker では、次のようなコマンドを使用できます。

docker run \
  --rm \
  -p5775:5775/udp \
  -p6831:6831/udp \
  -p6832:6832/udp \
  -p5778:5778/tcp \
  jaegertracing/jaeger-agent:1.62.0 \
  --reporter.grpc.host-port=jaeger-collector.jaeger-infra.svc:14250

gRPC を使用する場合、ロードバランシングと名前解決にはいくつかのオプションがあります。

• 単一接続とロードバランシングなし。単一のhost:portを指定した場合のデフォルトです。（例：--reporter.grpc.host-port=jaeger-collector.jaeger-infra.svc:14250）
• ホスト名の静的リストとラウンドロビンロードバランシング。これは、コンマ区切りのアドレスリストを使用した場合に得られるものです。（例：reporter.grpc.host-port=jaeger-collector1:14250,jaeger-collector2:14250,jaeger-collector3:14250）
• 動的DNS解決とラウンドロビン負荷分散。この動作を得るには、アドレスの前にdns:///を付けます。そうすると、gRPCはSRVレコード（外部負荷分散 ）、TXTレコード（サービス設定 ）、およびAレコードを使用してホスト名を解決しようとします。詳細については、gRPC名前解決ドキュメント とdns_resolver.goの実装 を参照してください。（例：--reporter.grpc.host-port=dns:///jaeger-collector.jaeger-infra.svc:14250）

エージェントレベルのタグ

Jaegerは、**jaeger-agent**を通過するすべてのspanのプロセスタグに追加できる、エージェントレベルのタグをサポートしています。これは、コマンドラインフラグ--agent.tags=key1=value1,key2=value2,...,keyn=valuenによってサポートされています。タグは環境変数フラグを使用して次のように設定することもできます - --agent.tags=key=${envFlag:defaultValue} - タグの値は、envFlag環境変数の値に設定され、設定されていない場合はdefaultValueが使用されます。

コレクタ

**jaeger-collector**はステートレスであるため、**jaeger-collector**の複数のインスタンスを並列に実行できます。**jaeger-collector**は、--cassandra.keyspaceや--cassandra.serversオプションなどのストレージの場所、または指定されたストレージに応じて--es.server-urlsによるElasticsearchクラスタの場所を除いて、ほとんど設定を必要としません。すべてのコマンドラインオプションについては、CLIフラグを参照してください。

デフォルト設定では、**jaeger-collector**は次のポートを公開します。

インジェスタ

**jaeger-ingester**は、Kafkaトピックからspanデータを読み取り、別のストレージバックエンド（ElasticsearchまたはCassandra）に書き込むサービスです。

公開されているすべての設定オプションを表示するには、次のコマンドを実行します。

docker run \
  -e SPAN_STORAGE_TYPE=cassandra \
  jaegertracing/jaeger-ingester:1.62.0
  --help

クエリサービスとUI

**jaeger-query**は、APIエンドポイントとReact/Javascript UIを提供します。このサービスはステートレスであり、通常は**NGINX** などのロードバランサの背後で実行されます。

デフォルト設定では、**jaeger-query**サービスは次のポートを公開します。

最小限のデプロイメント例（Elasticsearchバックエンド）

docker run -d --rm \
  -p 16685:16685 \
  -p 16686:16686 \
  -p 16687:16687 \
  -e SPAN_STORAGE_TYPE=elasticsearch \
  -e ES_SERVER_URLS=http://<ES_SERVER_IP>:<ES_SERVER_PORT> \
  jaegertracing/jaeger-query:1.62.0

クロックスキュー調整

Jaegerバックエンドは、通常は異なるホスト上で実行されているアプリケーションからのトレースデータを組み合わせます。ホストのハードウェアクロックは、クロックスキュー効果 として知られる相対的なずれを経験することがよくあります。クロックスキューにより、たとえば、サーバーのspanがクライアントのspanよりも早く開始されているように見える場合（ありえないことですが）トレースの解釈が困難になる可能性があります。**jaeger-query**サービスは、span間の因果関係に関する知識を使用して、クロックドリフトを修正するためのクロックスキュー調整アルゴリズム（コード ）を実装しています。調整されたすべてのspanには、適用されたクロックスキューのデルタを示す警告がUIに表示されます。

場合によっては、これらの調整自体がトレースの理解を困難にすることがあります。たとえば、サーバーのspanを親spanの範囲内に再配置する場合、Jaegerは要求と応答の待ち時間間の正確な関係を知らないため、それらが等しいと仮定し、子spanを親spanの中央に配置します（issue #961 を参照）。

jaeger-query サービスは、許容されるクロックスキュー調整の量を制御する構成フラグ--query.max-clock-skew-adjustmentをサポートしています。このパラメーターをゼロ（0s）に設定すると、クロックスキュー調整が完全に無効になります。この設定は、指定されたクエリサービスから取得されたすべてのトレースに適用されます。UIで直接調整のオンオフを切り替えるための対応を行うための未解決のチケット #197 があります。

UIベースパス

すべてのjaeger-query HTTPルートのベースパスは、ルート以外の値（例：/jaeger）に設定できます。これにより、すべてのUI URLが/jaegerで始まるようになります。これは、リバースプロキシの背後でjaeger-queryを実行する場合に役立ちます。

ベースパスは、コマンドラインパラメーター--query.base-pathまたは環境変数QUERY_BASE_PATHで設定できます。

UIのカスタマイズと埋め込み

専用のフロントエンド/UIページ を参照してください。

リモートストレージ（コンポーネント）

jaeger-remote-storageは、リモートストレージgRPC API を実装し、通常のJaegerバックエンドのいずれかにプロキシします。これは、コレクターとクエリサービスなどのJaegerコンポーネントの完全な展開を実行するが、メモリストアやBadgerなどの単一ノードストレージバックエンドを使用する場合に役立ちます。リモートストレージがない場合、単一ノードバックエンドは、複数のプロセス間で共有できないため、オールインワンでのみ使用できます。

デフォルト設定では、サービスは以下のポートでリスンします。

Spanストレージバックエンド

Jaegerは永続的なストレージバックエンドを必要とします。CassandraとElasticsearch/OpenSearchは、主要なサポート対象の分散ストレージバックエンドです。その他のバックエンドについてはこちら で説明されています。

ストレージタイプは、SPAN_STORAGE_TYPE環境変数で指定できます。有効な値はcassandra、elasticsearch、kafka（バッファとしてのみ）、badger、memoryです。

バージョン1.6.0以降、SPAN_STORAGE_TYPE環境変数に有効なタイプのカンマ区切りのリストを提供することで、複数のストレージタイプを同時に使用できます。リストされているすべてのストレージタイプは書き込みに使用されますが、リストの先頭にあるタイプのみが読み取りとアーカイブに使用されることに注意してください。

大規模な本番環境の展開では、JaegerチームはCassandraよりもOpenSearchバックエンドを推奨しています。

メモリ

インメモリストレージは、本番ワークロード向けではありません。迅速に開始するための簡単なソリューションとして意図されており、プロセスが終了するとデータは失われます。

デフォルトでは、メモリに保存されるトレースの量に制限はありませんが、--memory.max-tracesを介して整数の値を渡すことで制限を設定できます。

Badger - ローカルストレージ

• Jaeger v1.9以降

Badger は、オールインワン配布でのみ利用可能な埋め込みローカルストレージです。デフォルトでは、一時ファイルシステムを使用して一時ストレージとして機能します。これは、--badger.ephemeral=falseオプションを使用してオーバーライドできます。

docker run \
  -e SPAN_STORAGE_TYPE=badger \
  -e BADGER_EPHEMERAL=false \
  -e BADGER_DIRECTORY_VALUE=/badger/data \
  -e BADGER_DIRECTORY_KEY=/badger/key \
  -v <storage_dir_on_host>:/badger \
  -p 16686:16686 \
  jaegertracing/all-in-one:1.62.0

• Badger v1からv3へのアップグレード 
• 非ルートサービスとしてのBadgerファイルの権限 

Cassandra

• サポートされているバージョン: 4.x、5.x

Cassandra自体のデプロイは、このドキュメントの範囲外です。良いドキュメントのソースの1つはApache Cassandra Docs です。

設定

最小限

docker run \
  -e SPAN_STORAGE_TYPE=cassandra \
  -e CASSANDRA_SERVERS=<...> \
  jaegertracing/jaeger-collector:1.62.0

注: CASSANDRA_SERVERSでは空白文字が許可されます。例: サーバーは、可読性を向上させるために `CASSANDRA_SERVERS="1.2.3.4, 5.6.7.8"` のように渡すことができます。

すべてのオプション

設定オプションの完全なリストを表示するには、次のコマンドを実行します。

docker run \
  -e SPAN_STORAGE_TYPE=cassandra  \
  jaegertracing/jaeger-collector:1.62.0 \
  --help

スキーマスクリプト

Cassandraのインタラクティブシェルcqlsh を使用してCassandraのkeyspaceとスキーマを初期化するスクリプトが提供されています。

MODE=test sh ./plugin/storage/cassandra/schema/create.sh | cqlsh

または、公開されているDockerイメージを使用します（正しいIPアドレスを指定してください）。

docker run \
  -e CQLSH_HOST={server IP address}  \
  jaegertracing/jaeger-cassandra-schema:1.62.0

本番環境への展開では、MODE=prod DATACENTER={datacenter}引数をスクリプトに渡します。ここで、{datacenter}はCassandraの設定/ネットワークトポロジで使用される名前です。

このスクリプトでは、TTL、keyspace名、レプリケーションファクターなどを上書きすることもできます。引数なしでスクリプトを実行すると、認識されるパラメーターの完全なリストが表示されます。

注: Cassandraスキーマ管理の詳細については、README を参照してください。

TLSサポート

Cassandraクラスタを正しく設定していれば、JaegerはノードへのTLSクライアント接続をサポートします。cqlshなどで検証した後、コレクターとクエリを次のように設定できます。

docker run \
  -e CASSANDRA_SERVERS=<...> \
  -e CASSANDRA_TLS=true \
  -e CASSANDRA_TLS_SERVER_NAME="CN-in-certificate" \
  -e CASSANDRA_TLS_KEY=<path to client key file> \
  -e CASSANDRA_TLS_CERT=<path to client cert file> \
  -e CASSANDRA_TLS_CA=<path to your CA cert file> \
  jaegertracing/jaeger-collector:1.62.0

スキーマツールもTLSをサポートしています。次のようなカスタムcqlshrcファイルを作成する必要があります。

# Creating schema in a cassandra cluster requiring client TLS certificates.
#
# Create a volume for the schema docker container containing four files:
# cqlshrc: this file
# ca-cert: the cert authority for your keys
# client-key: the keyfile for your client
# client-cert: the cert file matching client-key
#
# if there is any sort of DNS mismatch and you want to ignore server validation
# issues, then uncomment validate = false below.
#
# When running the container, map this volume to /root/.cassandra and set the
# environment variable CQLSH_SSL=--ssl
[ssl]
certfile = ~/.cassandra/ca-cert
userkey = ~/.cassandra/client-key
usercert = ~/.cassandra/client-cert
# validate = false

互換性のあるバックエンド

• ScyllaDBは、同じデータモデルとクエリ言語を使用しているため、Cassandraの代替として使用できます。詳細はこちら 

Elasticsearch

• Jaeger v0.6.0以降サポート
• サポートされているESバージョン: 7.x、8.x（Jaeger v1.52.0以降）

Elasticsearchのバージョンは、root/pingエンドポイントから自動的に取得されます。このバージョンに基づいて、Jaegerは互換性のあるインデックスマッピングとElasticsearch REST APIを使用します。バージョンは、--es.version=フラグで明示的に指定できます。

Elasticsearchは、Elasticsearchのインストールと実行 以外に初期化を必要としません。実行したら、正しい設定値をjaeger-collectorとjaeger-queryに渡します。

設定

最小限

docker run \
  -e SPAN_STORAGE_TYPE=elasticsearch \
  -e ES_SERVER_URLS=<...> \
  jaegertracing/jaeger-collector:1.62.0

すべてのオプション

設定オプションの完全なリストを表示するには、次のコマンドを実行します。

docker run \
  -e SPAN_STORAGE_TYPE=elasticsearch \
  jaegertracing/jaeger-collector:1.62.0 \
  --help

Elasticsearchインデックスのシャードとレプリカ

シャードとレプリカは、インデックス作成時に決定されるため、特に注意が必要な構成値です。 この記事 では、最適化のために選択するべきシャード数の詳細について説明しています。

Elasticsearchロールオーバー

Elasticsearchロールオーバー は、インデックスに割り当てられたリソースの使用を最適化するインデックス管理戦略です。例えば、データを含まないインデックスでもシャードを割り当て、逆に、単一のインデックスが他のインデックスよりもはるかに多くのデータを含む場合があります。Jaegerはデフォルトでデータを日次インデックスに格納しますが、これはリソースを最適に使用しているとは限りません。ロールオーバー機能は、`--es.use-aliases=true`で有効にできます。

ロールオーバーを使用すると、次の基準の1つ以上に基づいて、新しいインデックスにロールオーバーするタイミングを構成できます。

• `max_age` - インデックスの最大経過時間。時間単位 を使用します：`d`、`h`、`m`。
• `max_docs` - インデックス内の最大ドキュメント数。
• `max_size` - プライマリシャードの最大推定サイズ（Elasticsearch 6.x以降）。バイトサイズ単位 `tb`、`gb`、`mb`を使用します。

ロールオーバーインデックス管理戦略は、デフォルトの日次インデックスを使用するよりも複雑であり、ストレージの準備のための初期化ジョブと、インデックスを管理するための2つのcronジョブが必要です。

Jaegerでのロールオーバーインデックス管理の詳細については、この記事 を参照してください。

自動ロールオーバーの詳細については、Elasticsearch ILMサポートを参照してください。

初期化

次のコマンドは、インデックスエイリアス、インデックス、インデックステンプレートを作成することで、Elasticsearchをロールオーバー展開の準備をします。

docker run -it --rm --net=host jaegertracing/jaeger-es-rollover:latest init http://localhost:9200 # <1>

アーカイブストレージを初期化する必要がある場合は、`-e ARCHIVE=true`を追加します。

初期化後、Jaegerは`--es.use-aliases=true`でデプロイできます。

新しいインデックスへのロールオーバー

次のステップでは、指定された条件に基づいて書き込みエイリアスを新しいインデックスにロールオーバーするロールオーバーAPIを定期的に実行します。このコマンドは、新しいデータを検索で使用できるように、読み取りエイリアスに新しいインデックスも追加します。

docker run -it --rm --net=host -e CONDITIONS='{"max_age": "2d"}' jaegertracing/jaeger-es-rollover:latest rollover  http://localhost:9200 # <1>

<1> このコマンドは、現在の書き込みインデックスの経過時間が2日より古い場合、エイリアスを新しいインデックスにロールオーバーします。その他の条件については、Elasticsearchドキュメント を参照してください。

次のステップでは、読み取りエイリアスから古いインデックスを削除します。つまり、古いデータは検索で使用できなくなります。これは、デフォルトの1日1インデックス展開で使用されている`--es.max-span-age`フラグの動作を模倣しています。このステップは省略可能であり、古いインデックスは次のステップでインデックスクリーナーによって単純に削除できます。

docker run -it --rm --net=host -e UNIT=days -e UNIT_COUNT=7 jaegertracing/jaeger-es-rollover:latest lookback  http://localhost:9200 # <1>

<1> 読み取りエイリアスから7日より古いインデックスを削除します。

古いデータの削除

履歴データは、日次インデックスにも使用される`jaeger-es-index-cleaner`で削除できます。

docker run -it --rm --net=host -e ROLLOVER=true jaegertracing/jaeger-es-index-cleaner:latest 14 http://localhost:9200 # <1>

<1> 14日より古いインデックスを削除します。

Elasticsearch ILMサポート

例えば

• サイズ（バイト数またはドキュメント数）または経過時間によって新しいインデックスにロールオーバーし、以前のインデックスをアーカイブする
• 古いインデックスを削除してデータ保持基準を適用する

ILMサポートの有効化

• jaeger-ilm-policyという名前のILMポリシーをElasticsearchで作成します。

  例えば、次のポリシーは、「active」インデックスが1分より古い場合にロールオーバーし、2分より古いインデックスを削除します。

  curl -X PUT http://localhost:9200/_ilm/policy/jaeger-ilm-policy \
  -H 'Content-Type: application/json; charset=utf-8' \
  --data-binary @- << EOF
  {
    "policy": {
      "phases": {
        "hot": {
          "min_age": "0ms",
          "actions": {
            "rollover": {
              "max_age": "1m"
            },
            "set_priority": {
              "priority": 100
            }
          }
        },
        "delete": {
          "min_age": "2m",
          "actions": {
            "delete": {}
          }
        }
      }
    }
  }
  EOF
  

• `ES_USE_ILM=true`でElasticsearch初期化を実行します。

  docker run -it --rm --net=host -e ES_USE_ILM=true jaegertracing/jaeger-es-rollover:latest init http://localhost:9200 # <1>
  

  <1> アーカイブストレージを初期化する必要がある場合は、`-e ARCHIVE=true`を追加します。

  ILMサポートで初期化する場合、事前にElasticsearchに`jaeger-ilm-policy`という名前のILMポリシーが作成されていることを確認してください（前のステップを参照）。そうでない場合、次のエラーメッセージが表示されます。

  「ILMポリシーjaeger-ilm-policyはElasticsearchに存在しません。作成してinitを再実行してください」

  初期化後、`--es.use-ilm=true`と`--es.use-aliases=true`でJaegerをデプロイします。

Elasticsearchバージョンのアップグレード

Elasticsearchは、ワイヤとインデックスの互換性バージョンを定義します。インデックスの互換性は、ノードがデータを読み取ることができる最小バージョンを定義します。例えば、Elasticsearch 8はElasticsearch 7によって作成されたインデックスを読み取ることができますが、同じインデックスマッピングを使用している場合でも、Elasticsearch 6によって作成されたインデックスを読み取ることができません。したがって、Elasticsearch 7から8へのアップグレードでは、データの移行は必要ありません。ただし、Elasticsearch 6から8へのアップグレードは、Elasticsearch 7を介して行う必要があり、ES 6.xによって作成されたインデックスが削除されるか、明示的に再インデックスされるまで待つ必要があります。

ワイヤとインデックスの互換性バージョンについては、Elasticsearchのドキュメント を参照してください。一般的に、この情報はroot/ping RESTエンドポイントから取得できます。

再インデックス

Elasticsearch 6によって作成されたインデックスが削除されるまで待たずに、Elasticsearch 6から8（Elasticsearch 7を介して）にアップグレードする場合、手動再インデックスを使用できます。

1. すべてのspanインデックスを、サフィックス`-1`付きの新しいインデックスに再インデックスします。

   curl -ivX POST -H "Content-Type: application/json" http://localhost:9200/_reindex -d @reindex.json
   {
     "source": {
       "index": "jaeger-span-*"
     },
     "dest": {
       "index": "jaeger-span"
     },
     "script": {
       "lang": "painless",
       "source": "ctx._index = 'jaeger-span-' + (ctx._index.substring('jaeger-span-'.length(), ctx._index.length())) + '-1'"
     }
   }
   

2. 古いマッピングを持つインデックスを削除します。

   curl -ivX DELETE -H "Content-Type: application/json" http://localhost:9200/jaeger-span-\*,-\*-1
   

3. `-1`サフィックスのないインデックスを作成します。

   curl -ivX POST -H "Content-Type: application/json" http://localhost:9200/_reindex -d @reindex.json
   {
     "source": {
       "index": "jaeger-span-*"
     },
     "dest": {
       "index": "jaeger-span"
     },
     "script": {
       "lang": "painless",
       "source": "ctx._index = 'jaeger-span-' + (ctx._index.substring('jaeger-span-'.length(), ctx._index.length() - 2))"
     }
   }
   

4. サフィックス付きインデックスを削除します。

   curl -ivX DELETE -H "Content-Type: application/json" http://localhost:9200/jaeger-span-\*-1
   

他のJaegerインデックスについても、同様のコマンドを実行します。

より効果的な移行手順が存在する可能性があります。コミュニティに発見した情報を共有してください。

Kafka

• Jaeger 1.6.0以降でサポートされています。
• サポートされているKafkaバージョン：0.9+

Kafkaは、コレクターと実際のストレージ間の仲介バッファとして使用できます。`SPAN_STORAGE_TYPE=kafka`で**jaeger-collector**を構成すると、受信したすべてのspanがKafkaトピックに書き込まれます。**jaeger-ingester**を使用してKafkaから読み取り、spanを別のストレージバックエンド（ElasticsearchまたはCassandra）に格納します。

Kafkaへの書き込みは、ポストプロセッシングデータパイプラインの構築に特に役立ちます。

設定

最小限

docker run \
  -e SPAN_STORAGE_TYPE=kafka \
  -e KAFKA_PRODUCER_BROKERS=<...> \
  -e KAFKA_TOPIC=<...> \
  jaegertracing/jaeger-collector:1.62.0

すべてのオプション

設定オプションの完全なリストを表示するには、次のコマンドを実行します。

docker run \
  -e SPAN_STORAGE_TYPE=kafka \
  jaegertracing/jaeger-collector:1.62.0 \
  --help

トピックとパーティション

Kafkaクラスタがトピックを自動的に作成するように構成されていない限り、事前に作成する必要があります。Kafkaクイックスタートドキュメント  を参照して、方法を学習してください。

トピックとパーティションに関する詳細情報は、公式ドキュメント  にあります。この記事 では、パーティション数の選択方法について詳しく説明しています。

リモートストレージ

Jaegerは、gRPCベースのリモートストレージAPI  をサポートしており、プロジェクトで直接サポートされていないカスタムストレージバックエンドをJaegerエコシステムに拡張することができます。これらのストレージバックエンドは、リモートgRPCサーバーとしてデプロイできます（Jaeger v1.30以降）。サイドカープラグインとしての古いデプロイモードは、v1.58以降サポートされません。

Jaegerのストレージバックエンドとしてリモートストレージを使用するには、ストレージタイプとしてgrpcを使用し、リモートgRPCサーバーアドレスを指定します。詳細については、jaeger/plugin/storage/grpc  を参照してください。

例

docker run \
  -e SPAN_STORAGE_TYPE=grpc \
  -e GRPC_STORAGE_SERVER=<...> \
  jaegertracing/all-in-one:1.62.0

既知のリモートストレージバックエンド

• robbert229によるPostgreSQL 

メトリクスストレージバックエンド

Jaegerクエリは、ストレージバックエンドから集計されたR.E.Dメトリクスをクエリし、モニタータブに表示できます。構成されたメトリクスストレージタイプは読み取り専用であるため、Jaegerクエリコンポーネント（およびJaegerクエリを含むオールインワン）のみに適用されることに注意してください。

ストレージタイプは、METRICS_STORAGE_TYPE環境変数で渡すことができます。有効な値はprometheusです。

Prometheus

PromQLと互換性のあるバックエンドは、Jaegerクエリでサポートされています。これらの一覧は、Julius Volzによって以下にまとめられています。https://promlabs.com/blog/2020/11/26/an-update-on-promql-compatibility-across-vendors 

設定

最小限

docker run \
  -e METRICS_STORAGE_TYPE=prometheus \
  jaegertracing/jaeger-query:1.62.0

すべてのオプション

設定オプションの完全なリストを表示するには、次のコマンドを実行します。

docker run \
  -e METRICS_STORAGE_TYPE=prometheus \
  jaegertracing/jaeger-query:1.62.0 \
  --help

TLSサポート

Prometheusサーバーへの接続にTLSクライアントをサポートしています。Prometheusサーバーを正しく構成して ください。jaeger-queryは次のように構成できます。

docker run \
  -e METRICS_STORAGE_TYPE=prometheus \
  -e PROMETHEUS_SERVER_URL=<...> \
  -e PROMETHEUS_TLS_ENABLED=true \
  -e PROMETHEUS_TLS_CA=<path to your CA cert file> \
  jaegertracing/jaeger-query:1.62.0

サービス依存関係の集約ジョブ

本番環境のデプロイメントでは、データを収集し、サービス間の依存関係リンクを作成する外部プロセスが必要です。プロジェクトspark-dependencies は、依存関係リンクを導出し、ストレージに直接書き込むSparkジョブです。