ConfigGenerator

Tempo Config Generator

Generate production-ready Grafana Tempo configuration files. Configure OTLP, Jaeger, and Zipkin receivers with S3, Azure, GCS, or local storage backends and metrics generation.

Output:A ready-to-use configuration file for Tempo Config with best practices applied.

Tempo Configuration

tempo.yaml
1server:
2  http_listen_port: 3200
3  grpc_listen_port: 9095
4  log_level: info
5

6distributor:
7  receivers:
8    otlp:
9      protocols:
10        grpc:
11          endpoint: 0.0.0.0:4317
12        http:
13          endpoint: 0.0.0.0:4318
14    jaeger:
15      protocols:
16        thrift_http:
17          endpoint: 0.0.0.0:14268
18        grpc:
19          endpoint: 0.0.0.0:14250
20    zipkin:
21      endpoint: 0.0.0.0:9411
22

23ingester:
24  trace_idle_period: 30s
25  max_block_bytes: 1048576
26  max_block_duration: 1h
27

28compactor:
29  compaction:
30    compaction_window: 1h
31    max_block_bytes: 104857600
32    block_retention: 48h
33    compacted_block_retention: 168h
34

35storage:
36  trace:
37    backend: local
38    local:
39      path: /var/tempo/traces
40

41overrides:
42  defaults:
43    max_bytes_per_trace: 5242880
44    max_search_bytes_per_trace: 1048576
45

46search:
47  max_bytes_per_tag_values_query: 5242880
Not generated yet

What is this tool?

The Tempo Config Generator helps you build production-ready Grafana Tempo configuration files in YAML format. Tempo is a distributed tracing backend from Grafana Labs, designed to ingest and store trace data at scale with minimal resource overhead. It is fully compatible with OpenTelemetry, Jaeger, Zipkin, and OpenCensus instrumentation libraries.

Unlike monolithic tracing solutions, Tempo follows a disaggregated architecture with distinct components for distribution, ingestion, compaction, and querying. This generator produces syntactically correct tempo.yaml files with all major subsystems configurable, including storage backends, metrics generation, compaction policies, search settings, and authentication. Whether you are running Tempo locally for development or in production on Kubernetes, this tool streamlines your configuration workflow.

How to Use This Tool

1. Configure Receivers: Enable trace ingestion endpoints for OTLP (gRPC and HTTP), Jaeger (Thrift HTTP, gRPC, Thrift Compact), Zipkin, and OpenCensus. Each receiver binds to a specific port on the distributor and handles protocol-specific deserialization.

2. Select Storage Backend: Choose between local filesystem, Amazon S3, Azure Blob Storage, or Google Cloud Storage. Each backend type requires specific authentication and connection parameters. The storage configuration is central to Tempo and affects both ingester WAL and backend block storage.

3. Set Compaction Policies: Configure how Tempo compacts small trace blocks into larger ones. The compaction window, maximum block size, and retention periods determine how long trace data is available and how efficiently it is stored.

4. Enable Metrics Generation: Tempo can derive RED metrics (Rate, Errors, Duration) from incoming traces using the service graphs and span metrics processors. Generated metrics are stored in a Prometheus-compatible TSDB and can be scraped by Prometheus or Grafana Mimir.

5. Configure Overrides: Set per-tenant limits for maximum bytes per trace and maximum search bytes. These controls prevent individual tenants from consuming excessive resources in multi-tenant deployments.

Best Practices

  • Use S3 or GCS as the storage backend in production for durability and scalability rather than local filesystem storage.
  • Set block_retention to match your compliance and debugging requirements, typically 48h to 7d for active debugging or 30d for auditing.
  • Enable the service_graphs processor to automatically generate RED metrics from traces without any instrumentation changes.
  • Configure max_block_duration between 1h and 2h to balance between compaction efficiency and query latency.
  • Use the metrics_generator to derive span-level metrics for visibility into trace-derived performance signals.

Common Mistakes

  • Using local storage in production environments, which provides no durability guarantees and cannot scale horizontally.
  • Setting block_retention to 0, which causes immediate data deletion after compaction and makes traces unqueryable.
  • Forgetting to configure overrides.max_bytes_per_trace, which can lead to OOM kills in the ingester under high cardinality.
  • Not exposing the metrics_generator registry to Prometheus, causing generated RED metrics to be silently discarded.

Security Notes

  • Enable multi-tenancy with X-Scope-OrgID headers to isolate trace data between tenants in shared deployments.
  • Use basic or OAuth2 authentication on gRPC and HTTP endpoints when exposing Tempo to untrusted networks.
  • Configure TLS on the gRPC listener for encrypting trace data in transit between distributors and ingesters.
  • Store S3 or GCS credentials in environment variables or Kubernetes secrets rather than hardcoding them in tempo.yaml.
  • Restrict the distributor's ingestion endpoints to internal networks and use an API gateway for external access.

Production Tips

  • Deploy Tempo with a microservices architecture using separate distributor, ingester, compactor, and querier deployments in Kubernetes.
  • Use the metrics_generator storage path on fast local SSDs for WAL durability and high write throughput.
  • Scale the compactor to a single instance per tenant to avoid race conditions during block compaction.
  • Monitor Tempo's internal metrics via the Prometheus metrics endpoint on port 3200 at /metrics.
  • Use Grafana's Tempo datasource with TraceQL for expressive trace queries and dashboard integration.

Frequently Asked Questions

What is Grafana Tempo and how does it work?
Grafana Tempo is a distributed tracing backend from Grafana Labs. It stores traces without indexing by service name or trace ID, relying instead on external indexes (Prometheus, Loki) for trace discovery. This makes Tempo extremely cost-effective and operationally simple at scale, as it only needs object storage with no heavy indexing layer.
What trace formats does Tempo support?
Tempo supports OpenTelemetry (OTLP over gRPC and HTTP), Jaeger (Thrift HTTP, gRPC, and Thrift Compact protocols), Zipkin (JSON and Protobuf), and OpenCensus formats. All formats are natively supported through the distributor's receiver configuration.
How does Tempo's storage backend work?
Tempo stores trace data as compressed blocks in the configured backend. It supports local filesystem (for development), Amazon S3, Azure Blob Storage, and Google Cloud Storage. The ingester receives spans, writes them to a WAL for durability, and flushes complete blocks to the backend storage.
What is the Tempo metrics_generator?
The metrics_generator is an optional component that derives Prometheus-compatible metrics from incoming traces. It supports two processors: service_graphs (generates RED metrics for service-to-service communication) and span_metrics (generates per-operation RED metrics). Generated metrics are stored in a local Prometheus TSDB and can be scraped by external Prometheus instances.
How does multi-tenancy work in Tempo?
Tempo uses the X-Scope-OrgID header for tenant isolation. Each incoming request must include this header, and the configured overrides apply per-tenant. The distributor enforces tenant isolation across all operations including ingestion, compaction, and query.
What is the recommended compaction configuration for production?
For production workloads, set compaction_window to 1h, max_block_bytes to 104857600 (100MB), and block_retention to 48h or higher. Use compacted_block_retention for long-term storage. Run exactly one compactor instance to avoid race conditions, and ensure adequate disk space for temporary compaction work.

How We Keep Your Configs Safe & Valid

Built-in Error Checking

Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.

100% Private & Local

All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.

Secure Settings by Default

Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.

Ready for CI/CD & Git

Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.

Infrastructure as Code

Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.

Monitoring & Tracing

Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.

Container & Docker Safety

Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.

Multiple Output Formats

Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.

Related Tools

Fluentd Config Generator

Configure Fluentd log collection pipelines alongside Tempo traces.

Docker Compose Generator

Deploy Tempo as part of a Docker Compose observability stack.