ウクライナの旗 私たちはウクライナの友人や同僚を支持します。困難な状況にあるウクライナを支援するために、このページをご覧ください。

よくある質問

Jaeger に関するよくある質問への回答。

バージョン  1.62 最新

依存関係ページが空なのはなぜですか?

依存関係ページには、Jaeger によってトレースされたサービスとその間の接続のグラフが表示されます。インメモリストレージで all-in-one バイナリを使用している場合、グラフはメモリに格納されているすべてのトレースからオンデマンドで計算されます。ただし、Cassandra や OpenSearch/Elasticsearch などの実際の分散ストレージを使用している場合、サービスグラフを作成するためにデータベース内のすべてのデータをスキャンするのはコストがかかりすぎます。代わりに、Jaeger プロジェクトは、トレースからサービスグラフデータを抽出するために使用できる「ビッグデータ」ジョブを提供しています。

Jaeger にスパンが表示されないのはなぜですか?

トラブルシューティング ガイドを参照してください。

jaeger-agent を実行する必要がありますか?

Jaeger クライアントライブラリは 非推奨であり、OpenTelemetry SDK は Jaeger Thrift 形式のサポートを段階的に廃止しているため、jaeger-agent は不要になり、推奨されなくなりました。代替のデプロイメントオプションについては、アーキテクチャページを参照してください。

jaeger-agent は必ずしも必要ではありません。Jaeger クライアントライブラリは、トレースデータを直接 jaeger-collector にエクスポートするように構成できます。ただし、jaeger-agent の実行が推奨される理由は次のとおりです。

  • Jaeger クライアントライブラリにトレースデータを直接 jaeger-collector に送信させる場合は、HTTP エンドポイントの URL を提供する必要があります。つまり、特に複数の Jaeger インストール (たとえば、異なるアベイラビリティーゾーンまたはリージョン) で実行していて、データを近くのインストールに送信したい場合、アプリケーションにはこのパラメーターを含む追加の構成が必要です。対照的に、エージェントを使用する場合、エージェントは常に localhost を介してアクセスできるため、ライブラリに追加の構成は必要ありません。サイドカーとして機能し、適切な jaeger-collector へのリクエストをプロキシします。
  • jaeger-agent は、現在のゾーン、リージョンなど、スパンに追加のタグを追加することで、インフラストラクチャ固有のメタデータでトレースデータを強化するように構成できます。jaeger-agent がホストデーモンとして実行されている場合、同じホストで実行されているすべてのアプリケーションで共有されます。jaeger-agent が真のサイドカー、つまりアプリケーションごとに 1 つとして実行されている場合、強力な認証、マルチテナンシーなどの追加機能を提供できます (このブログ投稿 を参照してください外部リンク )、ポッド名など。
  • jaeger-agent を使用すると、jaeger-collector へのトラフィック制御を実装できます。データセンターに何千ものホストがあり、それぞれが多数のアプリケーションを実行しており、各アプリケーションがデータを直接 jaeger-collector に送信している場合、各 jaeger-collector が処理するには開いている接続が多すぎる可能性があります。エージェントは、少ない接続でこのトラフィックのロードバランシングを行うことができます。

Jaeger チームは、以下の理由により、ストレージバックエンドとして Cassandra よりも OpenSearch/Elasticsearch を推奨しています。

  • Cassandraはキーバリューデータベースであるため、トレースIDによるトレースの取得にはより効率的ですが、OpenSearchのような強力な検索機能は提供しません。実際には、Jaegerバックエンドはクライアント側でk-vストレージ上に検索機能を実装しており、これは限られており、一貫性のない結果を生み出す可能性があります(詳細については、issue-166外部リンク を参照してください)。OpenSearchにはこれらの問題がなく、より使いやすくなっています。また、OpenSearchはKibanaダッシュボードなどから直接クエリでき、有用な分析や集計を提供できます。

  • 過去のパフォーマンス実験に基づくと、単一書き込みはOpenSearchよりもCassandraの方がはるかに高速であることが観察されており、より高い書き込みスループットを維持できる可能性が示唆されます。ただし、Jaegerバックエンドはk-vストレージ上に検索機能を実装する必要があるため、Cassandraへのスパンの書き込みは実際には大きな書き込み増幅の影響を受けます。スパン自体のレコードを書き込むことに加えて、Jaegerはサービス名と操作名のインデックス作成、およびすべてのタグに対する追加のインデックス書き込みを実行します。対照的に、OpenSearchへのスパンの保存は単一の書き込みであり、すべてのインデックス作成はOpenSearchノード内で行われます。その結果、Cassandraへの全体的なスループットはOpenSearchと同程度になります。

Cassandraバックエンドの利点の1つは、データTTLのネイティブサポートによるメンテナンスの簡素化です。OpenSearchでは、データの有効期限はインデックスローテーションを通じて管理され、追加の設定が必要です(Elasticsearchのロールオーバーを参照してください)。

なぜJaegerトレースIDはKafkaとUIで異なるように見えるのですか?

内部的には、データモデルレベルで、JaegerトレースIDは16バイトのシーケンスです。ただし、これらの16バイトはさまざまな方法で表現できます。

  • UIでは、歴史的にそれらを16進数エンコードされた文字列として表現していました。例えば、7e90c0eca22784ec7e90c0eca22784ecです。これらの文字列は、128ビットID(OpenTelemetryでより一般的)を使用する場合は32文字の長さになるか、IDがレガシーの64ビットモードで生成される場合は16文字の長さになります。
  • Jaegerバックエンドコードのドメインモデル外部リンク では、トレースIDをビッグエンディアンエンコーディングを使用した符号なし64ビット整数のペアとして表現しています。これは、Goのバイトスライスには追加のメモリ割り当てが必要であるため、効率化のためです。
  • 元のThriftモデル外部リンク でも、符号なし64ビット整数のペアとして表現していました。
  • Protobufモデル外部リンク では、IDはバイトシーケンスとして表現されています。Protobufがバイナリペイロードとしてシリアル化されると、これらのバイトはそのまま送信されます。ただし、ProtobufはJSONエンコーディングもサポートしており、バイトシーケンスはbase64エンコーディングを使用してシリアル化されます。したがって、コレクター-Kafka-インジェスターパイプラインでJSONエンコーディングを使用するように設定すると、fpDA7KInhOx+kMDsoieE7A==のように見えるトレースIDが表示されます。これらは、https://base64.guru/converter/encode/hex外部リンク などのオンラインツールを使用して、UIで認識される16進数エンコードされたIDに変換できます。

複数のコレクターを実行する必要がありますか?

jaeger-collector の高可用性を持つことは、ドロップされたスパン数を減らしたり、トレース収集のダウンタイムを減らすなど、システム全体のパフォーマンスを向上させますか?推奨されますか?もしそうなら、なぜですか?

これは、複数のインスタンスを実行する理由です。

  • クライアントが非常に多くのデータを送信するため、単一の jaeger-collector では十分に高速に受け入れることができません。
  • アップグレードのために jaeger-collector のローリング再起動を行う際に、一部のインスタンスがまだ実行中で、受信データを処理できるように、より高い可用性が欲しい。

これは、複数のインスタンスを実行する理由ではありません。

  • データ損失を避けるため。 jaeger-collector は、バックエンドストレージが十分に高速に保存できない場合にデータをドロップします。 jaeger-collector の数を増やし、内部キューに割り当てるメモリを増やすことで、一時的な緩和は提供できますが、ストレージバックエンドのボトルネックは解消されません。

Jaeger UIの認証を構成するにはどうすればよいですか?

Jaeger UIはアカウントやロールの概念をサポートしていないため、ユーザーを認証する必要はありません。Jaeger UIにアクセスできるユーザーを制限するためだけに認証が必要な場合は、HAProxy、NGINX、Keycloakなどのリバースプロキシをその前に実行することをお勧めします。標準のリバースプロキシを使用する利点は、さまざまな認証およびシングルサインオンサービスとの幅広い統合をサポートしていることです。これは、Jaeger UIでは絶対に一致させることができないものです。

たとえば、KeycloakでJaeger UIを保護する外部リンク の例については、このブログ記事を参照してください。