Jaeger Distributed Tracing Stack
The Jaeger stack provides CNCF-standard distributed tracing: OpenTelemetry instrumentation feeds Jaeger, which stores spans in Elasticsearch or Cassandra and visualizes request flows and service dependencies. Mature and vendor-neutral, though storage scaling adds operational weight.
The Jaeger distributed tracing stack traces requests as they flow through microservices to pinpoint latency and failures. Jaeger is a mature, CNCF-graduated tracing project that collects, stores, and visualizes spans. Paired with OpenTelemetry for instrumentation and a backing store such as Elasticsearch or Cassandra, it gives teams end-to-end visibility into distributed request paths and service dependencies.
Components
- OpenTelemetry instrumentation: SDKs and auto-instrumentation generate spans and propagate trace context across service boundaries; Jaeger natively ingests the OTLP protocol.
- Jaeger Collector: receives spans, validates, processes, and (optionally) samples them, then writes them to the storage backend.
- Storage backend (Elasticsearch, Cassandra, OpenSearch): persists spans for querying and retention, scaling with trace volume.
- Jaeger Query & UI: searches traces and renders span timelines, service dependency graphs, and detailed span attributes for analysis.
- Sampling: head-based or tail-based sampling controls how many traces are kept, balancing visibility against storage cost.
Strengths
Jaeger is a battle-tested, CNCF-graduated tracing system with broad adoption and Kubernetes-friendly deployment. Its UI clearly visualizes span timelines and service dependency graphs, which speeds root-cause analysis of cross-service latency and error propagation. Native OpenTelemetry and OTLP support means vendor-neutral instrumentation — you can instrument once and switch backends later. Pluggable storage lets teams reuse existing Elasticsearch or Cassandra clusters rather than running yet another datastore, and the whole stack is open source with no licensing cost.
Trade-offs
Trace storage in Elasticsearch or Cassandra adds operational weight, and at high span volumes those stores become the scaling bottleneck and primary cost driver. Sampling must be tuned carefully to balance visibility against volume, and aggressive sampling can drop the traces you most need. Jaeger covers tracing only, so it must be paired with metrics and logs systems for complete observability. Its search is less rich than some commercial APMs, and self-hosting the full pipeline — collector, storage, and query — takes ongoing effort.
When to Use It
Choose the Jaeger stack when you run microservices and want an open-source, CNCF-standard distributed tracing system, especially on Kubernetes and with OpenTelemetry instrumentation. It suits teams that already operate Elasticsearch or Cassandra and want to reuse that investment for span storage. Combine it with Prometheus and a logging stack for full observability; for object-storage-cheap trace retention without a heavy datastore, evaluate Grafana Tempo as an alternative tracing backend. It suits teams that want a proven, self-hostable tracing system with no vendor dependency, particularly those already invested in the storage backends it supports and the CNCF observability ecosystem around it. Sizing the storage backend for peak span volume and tuning sampling deliberately are the two decisions that most determine whether the deployment stays healthy and useful. For most teams the practical decision is whether to keep traces in a familiar search store like Elasticsearch or to move toward cheaper object-storage backends as trace volume climbs over time.