Jaeger

Last reviewed Aug 26, 2026 · 850 words

The all-in-one Jaeger image that every tutorial starts with keeps traces in memory, which means the first restart erases everything you collected. That is fine for an afternoon of learning and the wrong foundation for anything you will rely on. Jaeger itself is the reference self-hosted tracing system: CNCF graduated, Apache-2.0, written in Go, 23,144 stars, and since its version 2 rebuilt on top of the OpenTelemetry Collector so the ingestion path is the same one everything else in the ecosystem speaks. Get storage right and it runs on 512 MB for a homelab's worth of services.

Send traces with OpenTelemetry, not Jaeger clients

Jaeger's own language SDKs have been retired in favour of OpenTelemetry, and that is the only instrumentation path worth learning today. Your application uses an OpenTelemetry SDK, exports OTLP, and Jaeger listens on the standard ports: 4317 for gRPC and 4318 for HTTP. For most services the configuration is 2 environment variables and no code:

OTEL_SERVICE_NAME=api
OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4318

The UI lives on port 16686. If you run a single application and want to see where a slow request spends its 800 ms, that is the entire setup. The Python, Node, Java and Go SDKs all read those variables, and the auto-instrumentation packages for the common web frameworks add spans for HTTP, database and queue calls without you writing one. It is also the reason to start with tracing before metrics: a trace tells you which of 6 downstream calls was slow, where a dashboard only tells you that something was.

Pick a storage backend before you depend on it

Jaeger stores nothing itself; the listed con "storage backend required" is the whole operational decision. In rough order of effort: in-memory (the demo default, lost on restart), Badger (an embedded key-value store on local disk, single node, the right homelab choice), then Elasticsearch or OpenSearch for multi-node retention and real search, Cassandra for the very large, and ClickHouse in the version 2 line. A durable single-node setup is small:

services:
  jaeger:
    image: jaegertracing/all-in-one:latest
    ports: ["16686:16686", "4317:4317", "4318:4318"]
    volumes: ["./jaeger-data:/badger"]
    environment:
      - COLLECTOR_OTLP_ENABLED=true
      - SPAN_STORAGE_TYPE=badger
      - BADGER_EPHEMERAL=false
      - BADGER_DIRECTORY_VALUE=/badger/data
      - BADGER_DIRECTORY_KEY=/badger/key
    restart: unless-stopped

That is the version 1 line, which is still maintained and configured through environment variables; the version 2 jaegertracing/jaeger image takes a YAML configuration file in the OpenTelemetry Collector style instead, and the same Badger settings move into that file. Traces are high-volume and low-value individually, so set a retention of days, not months, and sample. Jaeger supports probabilistic and adaptive sampling; 10 percent of requests is plenty for a hobby stack, and errors can be kept at 100 percent with a tail-sampling processor in a collector in front. Badger's data is a directory, so back it up like any other volume, or do not: traces are diagnostic exhaust, and I would rather restore 7 days of nothing than spend backup space on them. What you do want to keep is the collector configuration and the sampling policy, which are the parts that took thought.

Traces only, by design

Jaeger does one thing. There are no metrics, no logs, no alerting, and the "focused only on traces" con is really a description of its place in a stack. The standard trio is Prometheus for metrics, Loki for logs, and Jaeger for traces, with Grafana on top: Grafana has a first-class Jaeger data source, so a trace ID in a log line becomes a clickable link into the span view. If you are new to monitoring, start with the Grafana and Prometheus pair and add Jaeger the first time a slow request cannot be explained from graphs. For an application that calls language models, the same tracing pattern is the backbone of the LLM observability approach, with prompt and token attributes on the spans.

Tempo and SigNoz are the honest alternatives

Tempo is Grafana's own trace store: object storage only, no Elasticsearch to run, cheaper at scale, and a natural fit if you are already all-in on the Grafana stack; it has a less capable standalone UI, because it expects Grafana to be the UI. SigNoz is the opposite bet: traces, metrics and logs in one product with one interface, on ClickHouse, for people who want a self-hosted Datadog rather than assembling 4 tools. Jaeger wins on maturity, on being the neutral reference implementation, and on running in 512 MB when the others need more.

What I'd do

Jaeger with Badger on local disk, 7-day retention, 10 percent sampling, behind the same reverse proxy as Grafana with the Jaeger data source wired in. Instrument through OpenTelemetry environment variables only. When trace volume outgrows one disk, move to OpenSearch if you already run it for logs, or to Tempo if you do not. Never run the in-memory mode past the day you learned on it.