From 49337f471dc30fa0315bccb7da32e2b3914b77a9 Mon Sep 17 00:00:00 2001 From: Chris Smith Date: Fri, 24 Apr 2026 19:09:59 -0700 Subject: [PATCH] Update Graphana Tempo config for latest version (#10055) ## What changed? Updates the Graphana Tempo configuration used for the service when running locally. (Simply copying a more recent version of the single-binary setup.) Fixes #10053. ## Why? Previously, the Tempo container would fail on startup. Preventing any collection of OTel traces. It appeared to stem from breaking changes in the Tempo service itself, as it modified the schema of its configuration file. I'll admit I am out of my depth here. But some of the field changes are called out in their upgrade guide here: https://grafana.com/docs/tempo/latest/set-up-for-tracing/setup-tempo/upgrade/ ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] ~covered by existing tests~ - NA? - [ ] ~added new unit test(s)~ - NA? - [ ] ~added new functional test(s)~ - NA? I ran the https://github.com/temporalio/samples-go/tree/main/opentelemetry sample, and within the Graphana UI on http://localhost:3000/ I saw data showing up. image --- .../grafana/provisioning/tempo/tempo.yaml | 67 +++++-------------- 1 file changed, 16 insertions(+), 51 deletions(-) diff --git a/develop/docker-compose/grafana/provisioning/tempo/tempo.yaml b/develop/docker-compose/grafana/provisioning/tempo/tempo.yaml index e866bc9ca4..e4cbce6c83 100644 --- a/develop/docker-compose/grafana/provisioning/tempo/tempo.yaml +++ b/develop/docker-compose/grafana/provisioning/tempo/tempo.yaml @@ -1,55 +1,18 @@ -# Copied from https://github.com/grafana/tempo/blob/main/example/docker-compose/local/tempo.yaml - +# Copied from https://github.com/grafana/tempo/blob/main/example/docker-compose/single-binary/tempo.yaml stream_over_http_enabled: true + server: http_listen_port: 3200 log_level: info -cache: - background: - writeback_goroutines: 5 - caches: - - roles: - - frontend-search - memcached: - host: memcached:11211 - -query_frontend: - search: - duration_slo: 5s - throughput_bytes_slo: 1.073741824e+09 - metadata_slo: - duration_slo: 5s - throughput_bytes_slo: 1.073741824e+09 - trace_by_id: - duration_slo: 100ms - metrics: - max_duration: 120h # maximum duration of a metrics query, increase for local setups - query_backend_after: 5m - duration_slo: 5s - throughput_bytes_slo: 1.073741824e+09 - distributor: - receivers: # this configuration will listen on all ports and protocols that tempo is capable of. - jaeger: # the receives all come from the OpenTelemetry collector. more configuration information can - protocols: # be found there: https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver - thrift_http: # - grpc: # for a production deployment you should only enable the receivers you need! - thrift_binary: - thrift_compact: - zipkin: + receivers: otlp: protocols: - http: grpc: - opencensus: - -ingester: - max_block_duration: 5m # cut the headblock when this much time passes. this is being set for demo purposes and should probably be left alone normally - -compactor: - compaction: - block_retention: 24h # overall Tempo trace retention. set for demo purposes + endpoint: "tempo:4317" + http: + endpoint: "tempo:4318" metrics_generator: registry: @@ -61,16 +24,14 @@ metrics_generator: remote_write: - url: http://prometheus:9090/api/v1/write send_exemplars: true - traces_storage: - path: /var/tempo/generator/traces - processor: - local_blocks: - filter_server_spans: false - flush_to_storage: true + +query_frontend: + mcp_server: + enabled: true storage: trace: - backend: local # backend configuration to use + backend: local wal: path: /var/tempo/wal # where to store the wal locally local: @@ -79,5 +40,9 @@ storage: overrides: defaults: metrics_generator: - processors: [service-graphs, span-metrics, local-blocks] # enables metrics generator + processors: ["span-metrics", "service-graphs"] generate_native_histograms: both + + +usage_report: + reporting_enabled: false