Grafana is the best visualization layer in observability, and it's where most teams' dashboards, alerts and SLOs already live. ClickHouse keeps coming up as the place to store telemetry: we went through the reasons in an earlier post, and a lot of it is compression. ClickHouse's internal logging platform stores 431 PiB of raw telemetry as 27 PiB on disk, about 16x on their setup. But those dashboards are written in LogQL, PromQL and TraceQL, and ClickHouse speaks SQL.
So if you want Grafana in front and ClickHouse underneath, something has to connect the two. One route is SQL: Grafana has a ClickHouse datasource plugin, and if your team is comfortable writing telemetry queries in SQL, that works today. The other route keeps the query languages. Gigapipe is an open-source server that stores logs, metrics and traces in ClickHouse and answers the Loki, Prometheus and Tempo HTTP APIs, so Grafana's built-in datasources read from it directly.
What Gigapipe is
Gigapipe is a single Go binary (it used to be called qryn) that serves the Loki, Prometheus and Tempo APIs, plus Pyroscope's, on one port, 3100 by default. Grafana's stock datasources point straight at it, so there's no plugin to install: all three get the same base URL. On the write side it takes OTLP, Loki push and Prometheus remote_write (v1). The open-source version is AGPLv3, and there's a managed version if you'd rather not run it yourself.
You do still run ClickHouse, and at scale that's a cluster, with shards, replicas and Keeper. But it's one database for logs, metrics and traces, and if you already run ClickHouse for something else, it's a database you know.
Gigapipe isn't the first to serve an existing query language from ClickHouse. Tesla built a PromQL layer over ClickHouse for their metrics platform so that the dashboards, alerts and other tools they already had would keep working without any rewrites.
What works out of the box
Gigapipe runs PromQL on the same query engine Prometheus uses and acts as the storage underneath, so metric dashboards behave the way you'd expect. LogQL gets translated into ClickHouse SQL instead. The everyday log queries work, but some of the more advanced ones don't parse, so run your heaviest queries against it while you're evaluating.
Grafana-managed alert rules query the datasource the same way a panel does, so they run against Gigapipe with the same query support your dashboards get. Gigapipe also has a ruler for recording rules. It's off by default, evaluates recording rules only, and skips any rule group without an explicit interval:.
On the Grafana side, you add the standard Loki, Prometheus and Tempo datasources, in the UI or in a provisioning file, and give all three the same Gigapipe URL.
Getting data in
If you run the OpenTelemetry collector, the pipeline to Gigapipe is pretty short, and we built a Flow for it (Flows are the ready-made collector configs in our library). Ship OTel data to Gigapipe takes logs, metrics and traces in on an OTLP receiver, runs them through memory_limiter and batch, and sends them to Gigapipe with basic auth and a disk-backed queue. Gigapipe works with the stock collector, so the Flow uses the standard OTLP/HTTP exporter pointed at port 3100. We went through an early version with the Gigapipe team and ran it in our demo environment, shipping the OpenTelemetry demo app into a self-hosted Gigapipe with Grafana reading back out. All you fill in is GIGAPIPE_ENDPOINT, GIGAPIPE_USERNAME and GIGAPIPE_PASSWORD, and you need Gigapipe 5.3.0 or later for OTLP metrics.
Every OTLP log attribute becomes a Gigapipe label, and every unique combination of labels is a separate stream with its own rows in an index table that every query goes through. More label values mean more disk and slower queries, but nothing falls over, which is part of the point of ClickHouse underneath: you can afford to keep the labels you actually query on and drop the rest. The collector is where you make that call, and once you have a lot of collectors, it's easy for their configs to drift apart when one gets an update and the others don't.
We build Telflo, an OpenTelemetry pipeline control plane. You can open the Flow in Telflo, drop the attributes you don't want as labels, test the change against sample data and push the same config to every collector remotely.
Who this is for
This pairing makes the most sense if your team already works in Grafana and wants the storage on ClickHouse. The dashboards, the alert rules and the LogQL, PromQL and TraceQL your team writes all work against it. Teams that run ClickHouse for something else get to reuse it for telemetry too. And if nobody writes LogQL or PromQL anyway, Grafana with the ClickHouse datasource plugin and plain SQL is the simpler setup.
If you're running Grafana on Gigapipe and ClickHouse, we'd like to hear how it's going. Tell us about it.
Manage your OpenTelemetry collectors with Telflo today.
Design, test, and deploy OpenTelemetry Collectors in one platform.
Sign up now
