Keep clickhouse integration tempo queryable
Blog post from Tinybird
Grafana Tempo and ClickHouse are presented as complementary trace-data systems: Tempo stores OpenTelemetry traces efficiently in object storage for Grafana-based trace investigation and TraceQL queries, while ClickHouse stores denormalized span records and rollups for long-term SQL analytics, cross-signal joins, SLO calculations, and product-facing APIs. Because Tempo does not natively export spans to ClickHouse, the recommended architecture uses an OpenTelemetry Collector or Grafana Alloy to fan out incoming OTLP data to both backends after applying memory limits, attribute normalization and secret redaction, tail sampling, and batching. The guidance emphasizes centralized sampling before dual writes to control cost, retaining errors and slow traces while sampling successful traffic and accounting for sampling rates in dashboard metrics. It recommends a ClickHouse schema ordered around service, operation, and timestamp, with high-cardinality values in attributes, plus minute-level materialized rollups to avoid expensive raw-span scans. Teams are advised to assign ownership of each KPI between Tempo-generated metrics and ClickHouse rollups, backfill historical data from Tempo blocks with deduplication, and validate metric parity across systems. Tinybird is described as an optional managed ClickHouse layer for ingestion, SQL endpoints, real-time APIs, scoped access, and testing data-model changes.
No tracked trend matches for this post yet.
Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.