Jaeger (分散トレーシング・2017)（イェーガー）
Uber 2017年公開・CNCF Graduated の分散トレーシングシステム。OpenTracing 由来・Sampling・UI で マイクロサービス Request Flow 可視化。
概要
Jaeger はUber Engineering が2017年4月にオープンソース公開した分散トレーシングシステム。「Jaeger」(ドイツ語Hunter・狩猟者) 由来。Google Dapper 論文 (2010) 影響、OpenTracing (CNCF 2016) ベース・Trace ID + Span 構造でマイクロサービス間Request Flow を可視化。CNCF 加入 (2017-09)・Graduated (2019-10)。Adaptive Sampling・Cassandra / Elasticsearch / Kafka Backend・Multi-tenant UI で大規模マイクロサービス監視の主要OSS、OpenTelemetry (2019) 標準化後も継続採用。
Jaeger 主要マイルストーン
| 年月 | 出来事 |
|---|---|
| 2010-04 | Google Dapper 論文 |
| 2016-10 | OpenTracing (CNCF) |
| 2017-04 | Uber Jaeger 公開 |
| 2017-09 | CNCF Incubating |
| 2019-10 | CNCF Graduated |
| 2020 | OpenTelemetry 統合 (Jaeger Receiver) |
| 2023 | Jaeger v2 開発開始 (OTel Native) |
| 2024-08 | Jaeger v2 Beta |
分散トレーシング基本概念
[ユーザリクエスト: Trace ID = abc-123]
├── [Span 1: API Gateway (10ms)]
│ └── [Span 2: Auth Service (5ms)]
├── [Span 3: User Service (15ms)]
│ ├── [Span 4: PostgreSQL Query (3ms)]
│ └── [Span 5: Redis Cache (1ms)]
└── [Span 6: Order Service (20ms)]
└── [Span 7: Payment Service (12ms)]
└── [Span 8: External Payment API (8ms)]
各Span が「特定操作の開始 / 終了時刻 + 親子関係」を持ち、全体Trace = ユーザリクエスト1回の流れ。
Jaeger アーキテクチャ
| コンポーネント | 役割 |
|---|---|
| Client | 各サービスSDK |
| Agent | Localhost UDP Receiver (Pod別) |
| Collector | Aggregator + Storage 書込 |
| Storage | Cassandra / Elasticsearch / Kafka / Badger |
| Query | UI Backend |
| UI | Web GUI |
| Spark Dependencies | Service Graph 計算 |
主要機能
| 機能 | 内容 |
|---|---|
| Trace 検索 | Service名 / Operation / Tag |
| Trace 可視化 | Gantt Chart 形式 |
| Service Graph | Service 間依存図 |
| Tag Filter | HTTP Status / Error / Latency |
| Sampling | Adaptive Probabilistic |
| Multi-tenant | Tenant別データ分離 |
| Span Compare | 2 Trace 並列比較 |
| Service Performance | Service別Latency集計 |
| OpenTelemetry 受信 | OTLP 直接受信 |
Adaptive Sampling
大量Trace の中から重要なものを優先サンプリング:
| 戦略 | 内容 |
|---|---|
| Probabilistic | 確率Sampling (例: 1%) |
| Rate Limiting | 1秒N件まで |
| Constant | 全Sampling / 完全除外 |
| Adaptive | エラー率高Service は多めSampling |
100,000 req/sec の全Trace 保存は非現実的、Sampling で実用化。
Storage Backend
| Backend | 用途 |
|---|---|
| Cassandra | 大規模 (1日10億Span+) |
| Elasticsearch | 中規模 + 検索充実 |
| Kafka | Streaming (中間Buffer) |
| Badger | 単一ノード (Embedded) |
| ClickHouse | 分析重視 (Jaeger v2) |
| OpenSearch | Elasticsearch代替 |
大規模Uber 規模で Cassandra・中規模はElasticsearch が一般。
主要採用先
| 企業 | 用途 |
|---|---|
| Uber (起源) | 数千マイクロサービス |
| Robinhood | 取引追跡 |
| Symantec / Norton | セキュリティサービス |
| Salesforce | CRM サービス |
| Red Hat OpenShift | Kubernetes Tracing |
| GrafanaLabs | Tempo の参考実装 |
| Microsoft Azure | 一部内部利用 |
OpenTelemetry 統合
Jaeger v1 はOpenTracing ベースだが、2020年以降OpenTelemetry 統合:
- Jaeger Receiver: OTLP 直接受信
- OpenTelemetry Collector → Jaeger Exporter
- 既存Jaeger Client SDK も OTel 互換
Jaeger v2 (2024-)
OpenTelemetry Native 再設計:
- OTel Collector ベース
- ClickHouse Storage
- v1 互換性維持
- 性能改善
関連用語との違い
- vs OpenTelemetry: 規格 / 実装
- vs Zipkin: 同様分散トレース・Twitter 起源
- vs Tempo: Grafana Lab製・大規模ScaleOut
FAQ
Q1: Jaeger vs Zipkin? A: 機能性Jaeger 優位・コミュニティ規模ほぼ同等・Zipkin はTwitter 起源で2012-早期・Jaeger はUber + CNCF で現代的。
Q2: 個人プロジェクト? A: 不要。マイクロサービス10+ で実利。Single Service + Logs / Metrics で十分。
Q3: Sampling 推奨? A: 100K+ req/秒 で1%・10K req/秒 で100%可能・「エラー時必ずSampling」のTail Sampling が推奨。