mrkeyoor.com_
Tue 01 Sept 17:42 UTC
Self-Hostedevaluationupdated 29 Aug 2026

jaeger review

Jaeger is a self-hosted distributed tracing system for following requests as they cross services. It collects OpenTelemetry traces, stores them, and gives operators a UI for finding slow paths and failures that ordinary logs can hide.

+14 / 3dstars / 7d
Verdict

Our build completed in 226 seconds, and all 273 measured tests passed, a concrete sign that Jaeger v2.20.0 is in good engineering shape. Use it when distributed tracing is operationally important and your team is prepared to own storage and upgrades. For a small service or a team that wants zero maintenance, it is more infrastructure than the problem warrants.

We ran it

Install✓ · 113s598 packages
Build✓ · 226s
Tests✓ · 116s273 passed · 0 failed of 273 (go test)
Repo2897 files~318,912 lines of source · 18.7 MB · 41 CI workflows

Answers from our run

Does jaeger build from source?

Dependencies installed in 113 seconds (598 packages), and the build succeeded in 226 seconds. We cloned commit 6b5e1a7 into a clean Debian container with 3 CPUs and no project-specific setup.

Do jaeger's tests pass?

Yes: 273 of 273 passed when we ran the project's own test command (go test). Some failures need services or credentials a bare container does not have.

Who should not use jaeger?

Small applications that can diagnose requests with logs and metrics alone

What are the alternatives to jaeger?

Grafana Tempo, Zipkin, SigNoz. Our build completed in 226 seconds, and all 273 measured tests passed, a concrete sign that Jaeger v2.

Setup4/5One-command demo, production storage still needs planning
Docs4/5Clear quick start, architecture, and compatibility policies
Community5/523k stars, recent push, CNCF governance, active releases
Maturity5/5Graduated CNCF project with explicit support policies

Discussed on

  1. hnJaeger – A Distributed Tracing System311 points
  2. hnClickHouse Storage for Jaeger Tracing31 points

Who it’s for

Platform teams operating multiple services and already using OpenTelemetry
SRE teams that want to own tracing data and storage choices
Developers who need a local all-in-one tracing environment
Organizations comfortable operating a CNCF observability component

Who it’s NOT for

Small applications that can diagnose requests with logs and metrics alone
Teams wanting a fully managed service with no storage or upgrade work
Developers seeking a stable Go library API, because importable code is internal
Operators unwilling to plan backend compatibility and configuration migrations

Setup reality

Our sandbox run installed 598 packages in 113 seconds, built successfully in 226 seconds, and completed all 273 Go tests in 116 seconds with 0 failures. That is strong evidence that the source tree is reproducible on a fresh Debian-based Go 1.24 environment, but it is more work than the README's one-command Docker quick start suggests: the repository contains 2,897 files and 41 CI workflows, while a production deployment still needs persistent storage, OpenTelemetry traffic, configuration, and lifecycle planning.

Jaeger solves the trace-correlation problem

Jaeger is infrastructure for answering a difficult operational question: where did one request spend its time as it crossed several services? Applications send OpenTelemetry trace data over HTTP or gRPC, the collector writes it to storage, and the query service feeds a browser UI. That scope is focused. Jaeger is not presented as an all-purpose monitoring suite, and it does not replace the metrics and logs that explain system-wide behavior or detailed events.

The project began at Uber and now sits under open CNCF governance. It graduated in October 2019, and the repository has 23,156 stars. Those facts do not guarantee that it suits every environment, but they reduce the institutional risk compared with adopting a tracing server maintained by one vendor or a tiny team. Jaeger v2 also builds on OpenTelemetry Collector components, which places it in the mainstream cloud-native telemetry path rather than tying instrumentation to a Jaeger-only SDK.

Our run passed every measured test

We cloned commit 6b5e1a7 into an unprivileged Debian sandbox with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image. Installation succeeded in 113 seconds and installed 598 packages. The repository is substantial: 2,897 files, roughly 318,912 lines of source, and an 18.7 MB checkout. Those figures describe build complexity, not runtime capacity, and they should not be mistaken for a throughput benchmark.

The build then succeeded in 226 seconds. Our run completed the Go tests in 116 seconds, with 273 passed and 0 failed out of 273. That clean result matters more than a badge because it came from a fresh environment we controlled. We found 41 CI workflow files, no Dockerfile, and no top-level tests directory. The latter 2 observations are repository-layout signals only, not evidence that container images or tests are absent, especially because the Go test command demonstrably found and passed tests.

The quick start is genuinely quick, but only for evaluation

The README gives a useful Docker command that starts an all-in-one instance with the UI, collector, query service, and in-memory storage. It exposes the UI on port 16686 and accepts OTLP over gRPC on 4317 or HTTP on 4318. That is an excellent evaluation path: a developer can connect an instrumented service without first assembling four separate components. The architecture diagram also makes the flow from SDK to collector, storage, query service, and UI unusually easy to understand.

Production is a different proposition. In-memory storage is not durable, so operators must select and manage a supported backend, capacity, retention, access controls, and backup behavior. The README names policies for Elasticsearch 9.x, OpenSearch, Cassandra, and ClickHouse LTS releases, rather than pretending every historical backend version receives equal care. This is responsible documentation, but it also exposes the ongoing work: Jaeger becomes part of the platform, with its own storage compatibility and upgrade schedule.

Compatibility promises are specific enough to plan around

Jaeger's deprecation policy is one of its strongest operational features. A deprecated configuration option receives a grace period of at least 3 months or 2 minor releases, whichever is later, and notices are expected to identify a date or version. That does not eliminate migration work, especially because Jaeger inherits moving parts from the OpenTelemetry Collector, but it gives platform teams a concrete window for change management instead of vague assurances about stability.

There is an important limit for Go developers: all importable code has moved into internal packages. Jaeger should therefore be treated as deployed infrastructure, not as a convenient public Go toolkit around which to build another product. Its Go support policy also tracks the language team's supported releases and may drop N-1 soon after version N arrives. That approach keeps the project current, but organizations pinned to older compilers need to account for it before upgrading Jaeger.

Healthy activity does not erase operational rough edges

The latest listed release, v2.20.0, arrived on July 20, 2026, and the repository was pushed on August 28, 2026, one day before this review. Combined with 41 workflow files and a perfect measured test result, that looks like active maintenance. The 554 open issues are a meaningful queue, but issue volume alone is not neglect in a widely deployed infrastructure project. It is better read as evidence of a large surface area that deserves release-note and issue searches before each upgrade.

The main weakness is not build quality, it is ownership cost. A trace system only becomes useful after services emit consistent spans, sampling preserves the right requests, storage remains affordable, and operators can connect trace findings to logs and metrics. Jaeger supplies the tracing path and UI, but the README evidence does not promise automatic instrumentation, effortless security, or a managed backend. Teams that expect the Docker demo to become production by changing one flag will encounter substantially more design work.

It belongs beside metrics and logs in an existing platform

In a real stack, OpenTelemetry SDKs sit inside applications and send OTLP to Jaeger's collector. Jaeger then writes to the selected storage system, while its query service and UI support incident investigation. Put authentication and network policy around the exposed services according to your environment, and keep metrics and centralized logs alongside it. This division lets Jaeger answer request-path questions without forcing it to become the only observability interface.

Jaeger is an easy recommendation for platform teams that need self-hosted tracing and can operate stateful dependencies. Its v2 architecture, explicit compatibility windows, recent activity, and our 273-of-273 test result all support that conclusion. It is a poor default for a small monolith with occasional debugging needs, and it is not the lowest-effort choice for teams willing to buy a managed service. The deciding question is less whether Jaeger works, and more whether tracing is valuable enough to justify owning the pipeline.

Alternatives

ProjectWhat it isPick it when
Grafana Tempo gh↗A tracing backend designed around object storage and Grafana.pick this instead when Grafana is already your main observability interface and object-storage economics are central.
ZipkinA long-running distributed tracing system with a straightforward model and UI.pick this instead when you want a simpler tracing deployment or already emit Zipkin-compatible data.
SigNozA self-hosted observability platform combining traces, metrics, and logs.pick this instead when you want one product to cover several observability signals rather than a focused tracing system.

What people are saying

  1. [velocity-scout] jaegertracing/jaeger

Sources

  1. Jaeger GitHub repository
  2. Jaeger official website

More self-hosted reviews

v2 · OpenShell · wigolo · Mindwtr · club-3090 · reclip · the whole board →