Jaeger — CNCF Distributed Tracing Platform

What Jaeger Does

• Trace collection — receive spans via OTLP, Jaeger protocol, Zipkin
• Storage backends — Elasticsearch, Cassandra, Kafka, Badger, memory
• Query API — search traces by service, operation, tags, duration
• UI — waterfall view of spans, service dependencies graph
• Sampling — adaptive, probabilistic, rate-limited
• Service Performance Monitoring (SPM) — RED metrics from traces
• Critical Path — highlight bottleneck spans

Architecture

Jaeger components:

• Agent (deprecated, use OTLP) — local daemon
• Collector — receives spans, writes to storage
• Query — serves UI and API, reads from storage
• Ingester — for Kafka async pipeline
• All-in-one — dev container bundling everything
• OpenTelemetry Collector — modern ingestion preferred

Self-Hosting

# Production deployment
components:
  - Collector (multi-replica, behind LB)
  - Elasticsearch cluster (storage)
  - Query service (multi-replica)
  - OTel Collector (ingestion)

Kubernetes: use the official Jaeger Operator or Helm charts.

Key Features

• OpenTelemetry native ingestion
• Multiple storage backends
• Service dependency graph
• Adaptive sampling
• Trace search and filtering
• RED metrics (SPM)
• Zipkin compatibility
• gRPC and HTTP APIs
• Kubernetes operator

Comparison

FAQ

Q: Jaeger vs Tempo? A: Jaeger has its own UI and a mature ecosystem; Tempo stores traces on object storage (cheap), uses Grafana for viewing, and integrates better with Loki/Prometheus.

Q: Sampling strategy? A: Do not sample 100% in production (wastes storage). Use probabilistic 1% + tag-based force-keep (always keep errors and slow requests).

Q: Relationship with OpenTelemetry? A: OTel is the standard (API + SDK + Collector); Jaeger is the backend. New projects should use OTel for instrumentation + Jaeger for storage and query.

Sources

• Docs: https://www.jaegertracing.io/docs
• GitHub: https://github.com/jaegertracing/jaeger
• License: Apache 2.0