機能
高スケーラビリティ
Jaeger バックエンドは、単一障害点を排除し、ビジネスニーズに合わせてスケーリングするように設計されています。たとえば、Uber の特定の Jaeger インストールでは、通常、1 日に数十億の span を処理しています。
OpenTracing と OpenTelemetry のネイティブサポート
Jaeger バックエンド、Web UI、およびインストルメンテーションライブラリは、OpenTracing 標準をサポートするようにゼロから設計されています。
- span 参照 を介してトレースを有向非巡回グラフ(単なるツリーではない)として表現します。
- 厳密に型付けされた span の *タグ* と *構造化ログ* をサポート
v1.35 以降、Jaeger バックエンドは、ネイティブの OpenTelemetry プロトコル (OTLP) で OpenTelemetry SDK からトレースデータを受信できます。ただし、内部データ表現と UI は、OpenTracing 仕様のモデルに従っています。
複数のストレージバックエンド
Jaeger は、増加する数のストレージバックエンドで使用できます。
- トレースストレージバックエンドとして、Cassandra 3.4+、Elasticsearch 7.x/8.x、OpenSearch 1.0+などの一般的なオープンソース NoSQL データベースをネイティブにサポートしています。
- Jaeger と互換性があると認定された他のよく知られたデータベースとは、gRPC API を介して統合されています。 ClickHouse など。
- Badger を使用した埋め込みデータベースサポートと、テスト設定のためのシンプルなインメモリストレージがあります。
- 他のデータベースを使用したコミュニティによる実験が進行中です。詳細は このissue をご覧ください。
最新のWeb UI
Jaeger Web UI は、React などの一般的なオープンソースフレームワークを使用して Javascript で実装されています。v1.0 では、大量のデータに対処し、数万個の span を持つトレースを表示できるようにするためのいくつかのパフォーマンスの改善がリリースされています(例:80,000 span のトレースを試してみました)。
クラウドネイティブデプロイ
Jaeger バックエンドは、Docker イメージのコレクションとして配布されます。バイナリは、コマンドラインオプション、環境変数、および複数の形式(yaml、toml など)の構成ファイルを含む、さまざまな構成方法をサポートしています。Kubernetes クラスタへのデプロイは、Kubernetes オペレーター とHelm チャート によって支援されています。
可観測性
すべての Jaeger バックエンドコンポーネントは、デフォルトで Prometheus メトリクスを公開します。ログは、zap 構造化ロギングライブラリを使用して stdout に書き込まれます。
Zipkin との下位互換性
OpenTelemetryを用いたアプリケーションのインストルメンテーションを推奨しますが、組織が既にZipkinライブラリを使用してインストルメンテーションに投資している場合、すべてのコードを書き直す必要はありません。Jaegerは、HTTP経由でZipkin形式(Thrift、JSON v1/v2、Protobuf)のスパンを受け入れることで、Zipkinとの下位互換性を提供します。Zipkinバックエンドからの切り替えは、ZipkinライブラリからのトラフィックをJaegerバックエンドにルーティングするだけです。
トポロジグラフ
Jaeger UIは、システムアーキテクチャと深層依存関係グラフの2種類のサービスグラフをサポートしています。
システムアーキテクチャ
アーキテクチャで観測されたすべてのサービスに関する「従来の」サービス依存関係グラフです。このグラフは、サービス間の1ホップ依存関係のみを表し、サービスメッシュによって生成されるテレメトリから得られるものと同様です。たとえば、グラフA - B - C
は、A
とB
の間のネットワーク呼び出しを含むトレースと、B
とC
の間の呼び出しを含むトレースが存在することを意味します。ただし、完全なチェーンA - B - C
を含むトレースが存在するという意味ではありません。つまり、A
がC
に依存しているとは言えません。
このグラフのノード粒度は、サービスエンドポイントではなくサービスのみです。
システムアーキテクチャグラフは、インメモリストレージからオンザフライで構築することも、分散ストレージを使用する場合はSparkまたはFlinkジョブを使用して構築することもできます。
深層依存関係グラフ
「推移的依存関係グラフ」とも呼ばれ、チェーンA -> B -> C
は、A
がC
に推移的な依存関係を持つことを意味します。単一のグラフには「焦点」サービス(ピンクで表示)が必要であり、そのサービスを通過するパスのみを表示します。通常、このタイプのグラフは、すべてに接続されたサービス(例:APIゲートウェイ)が存在し、それが焦点サービスとして選択されない限り、システム全体のアーキテクチャを表すものではありません。
このグラフのノード粒度は、サービスとサービスエンドポイントの間で変更できます。後者のモードでは、同じサービス内の異なるエンドポイントが別々のノードとして表示されます(例:A::op1
とA::op2
)。
現時点では、推移的グラフは検索結果のトレースからしか構築できません。将来は、すべてのトレースを集約することでグラフを計算するFlinkジョブが提供される予定です。
サービスパフォーマンスモニタリング(SPM)
RED(リクエスト、エラー、期間)メトリクスの形式で集約されたスパンデータを視覚化して、統計的に有意なリクエスト/エラー率またはレイテンシを持つサービスや操作を強調表示し、Jaegerのトレース検索機能を利用して、これらのサービス/操作に属する特定のトレースを特定します。
詳細については、サービスパフォーマンスモニタリング(SPM)を参照してください。