Jaeger

Jaeger is a distributed tracing platform originally built at Uber and now hosted as a graduated project under the Cloud Native Computing Foundation. It helps engineers track requests as they move across microservices, pinpointing latency bottlenecks and failures that are hard to catch with logs or metrics alone. It's built for teams running distributed systems who need to understand request flow, debug performance issues, and analyze service dependencies.

The platform accepts traces over OpenTelemetry protocols (OTLP) via gRPC or HTTP, processes them through a collector, and stores them in a pluggable backend. A query service and web UI let you search and inspect traces after the fact. Jaeger works with multiple storage backends including Elasticsearch, OpenSearch, Cassandra, and ClickHouse, each with its own supported version range tied to the backend vendor's maintenance policy.

Key features

• OTLP-native ingestion: accepts traces via gRPC (port 4317) or HTTP (port 4318), aligning with the OpenTelemetry ecosystem rather than a proprietary wire format.
• All-in-one deployment mode: a single Docker image bundles the UI, collector, query service, and in-memory storage for quick local testing.
• Pluggable storage backends: supports Elasticsearch, OpenSearch, Cassandra, and ClickHouse, with a defined version support policy for each tied to upstream maintenance windows.
• Storage plugin architecture: collector and query service can talk to external storage plugins over gRPC instead of connecting to storage directly.
• Web UI for trace search: visualize individual traces and service dependency graphs through the Jaeger UI (separate repo, consumed by this project).
• CNCF-governed project: open governance, public maintainer list, and a documented deprecation policy for config options and CLI flags.
• Go version tracking: follows the official Go release support policy, dropping support for older Go versions as new ones ship.

Ideal use cases

Jaeger fits teams running microservice architectures where a single user request touches many services and you need to see the full call path, not just isolated logs. It's a good match if you're already instrumenting services with OpenTelemetry SDKs and want a backend that accepts OTLP directly. Production deployments typically pair the collector with a real storage backend (Elasticsearch, Cassandra, ClickHouse, or OpenSearch) rather than the in-memory all-in-one mode, which is meant for local development and demos.

It's not the right tool if you need application metrics or log aggregation; Jaeger is specifically for trace data, so you'll want it alongside a metrics system (like Prometheus) and a logging stack, not instead of them. If your system is a single monolith with no cross-service calls, distributed tracing offers limited value, plain profiling or APM tools may serve you better. Teams without the operational capacity to run and maintain a storage backend (Elasticsearch/Cassandra/ClickHouse clusters) should weigh that cost before adopting Jaeger for production, since the all-in-one in-memory setup doesn't persist data or scale.

Installation

The fastest way to try Jaeger is the all-in-one Docker image, which bundles the UI, collector, query service, and in-memory storage:

docker run --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  -p 4318:4318 \
  jaegertracing/jaeger:latest

Once running, open the UI at http://localhost:16686. Send traces from your instrumented application using OTLP: gRPC on port 4317 or HTTP on port 4318.

For production setups with a persistent storage backend (Elasticsearch, OpenSearch, Cassandra, or ClickHouse), consult the official Getting Started Guide linked from the project's documentation site, since backend configuration and version compatibility vary by storage choice. If you want to build from source or contribute code, follow the steps in the repository's CONTRIBUTING guide.