Grafana Tempo

Last reviewed Sep 13, 2026 · 768 words

You do not need S3 to run Grafana Tempo. The "object storage only" line in the marketing means it will not ask you for Cassandra or Elasticsearch the way older tracing backends did; on a homelab the local backend writes blocks to a directory and the whole thing runs as one container in about 512 MB of RAM. What you do need is Grafana, because Tempo has no UI of its own beyond a status page. If you already run Grafana with Prometheus and Loki, Tempo is the missing third leg and an afternoon of work. If you do not, it is the wrong place to start.

Where Tempo sits in a Grafana stack

Metrics tell you a service is slow; logs tell you what it printed; traces tell you which of the 9 calls inside one request took 1,800 ms. Tempo (5,500 stars, AGPL-3.0, Go, first released 2020) stores those traces and indexes only their IDs, which is why it is cheap: there is no full-text index to feed and grow. Searching by attribute uses TraceQL, which scans blocks in parallel rather than hitting an index, and on a single machine with a few hundred thousand spans a day that is instant enough.

The stack it pairs with is Grafana for viewing, Loki for logs, and Prometheus or Mimir for metrics. The payoff is the cross-links: click a trace ID in a Loki log line and land in the trace; click an exemplar on a latency histogram and land in the exact slow request. That correlation is the reason to pick Tempo over a standalone tracer, and it only exists inside Grafana.

Monolithic mode is the right mode for you

Tempo can run as distributor, ingester, querier, and compactor microservices. Do not. -target=all runs everything in one process, and this config is enough:

server:
  http_listen_port: 3200

distributor:
  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

compactor:
  compaction:
    block_retention: 168h

storage:
  trace:
    backend: local
    local:
      path: /var/tempo/blocks
    wal:
      path: /var/tempo/wal

Port 3200 is Tempo's HTTP API and the address Grafana's data source points at. Ports 4317 and 4318 are standard OTLP gRPC and HTTP, so any OpenTelemetry SDK ships traces straight in with OTEL_EXPORTER_OTLP_ENDPOINT=http://tempo:4317 and nothing else. block_retention is the knob nobody sets and then wonders why the disk filled: 7 days here, and Tempo deletes older blocks itself.

Mount /var/tempo as a volume. That directory is the entire state; backing it up is optional in most homelabs because traces are diagnostic data you can regenerate by waiting.

Send traces through a collector, not directly

Applications can export straight to Tempo, but an OpenTelemetry Collector in between earns its 100 MB. It batches, retries when Tempo restarts, adds host attributes, and lets you sample: keep 100 percent of errors and 10 percent of successes, which is the difference between a disk that fills weekly and one that fills yearly. It is also where you point one endpoint at every app and change the backend later without touching them. For AI workloads specifically, the LLM observability piece covers what to put in spans so the traces are worth reading.

Standalone UI is where Jaeger still wins

Jaeger ships its own search-and-view interface and is the more common first tracing tool for exactly that reason: install it, open port 16686, see traces. Tempo without Grafana is a write-only box. If you have no Grafana and want to look at one service's traces this week, Jaeger is simpler. If you want the all-in-one alternative to a Datadog APM subscription with metrics, logs, and traces in one place, SigNoz bundles the lot behind a single UI. Tempo is the pick when Grafana is already your window on everything and you want traces in the same window at the lowest storage cost.

What I'd do

Add Tempo as one more container next to Grafana and Loki, local backend, 7-day retention, an OpenTelemetry Collector in front with tail sampling that keeps every error. Add the data source in Grafana, enable the trace-to-logs link with the Loki source, and instrument one service end to end before touching the rest. Once you have clicked from a slow-request alert into the span that caused it, you will not want to operate without it, and the whole addition costs about half a gigabyte of RAM and no new database.