不少团队在可观测性上走到后面，都会遇到一个很具体的账：metrics、logs、traces 分别放在 Prometheus、Loki、Tempo，查询语法和 Grafana dashboard 虽然已经熟悉，存储、retention、备份和运维却变成三套。把三种 OpenTelemetry 信号收进 ClickHouse 是一种常见的收敛思路，但真正难替换的常常不是写入，而是已经被 Grafana、alerting 和 CLI 固化下来的读取接口。

今天看的是 tsouza/cerberus。它是一个只读 HTTP gateway：PromQL、LogQL、TraceQL 进入后，被解析、优化并翻译为 ClickHouse SQL；返回的仍是 Prometheus、Loki、Tempo 各自的 wire format。Grafana 可以把它配置成三个普通 datasource，既有 dashboard 和 query 不必先重写。它不接收 telemetry，也不保存 telemetry；写入端仍由 OpenTelemetry Collector 直接写入 ClickHouse。

按 GitHub repository API、README、LICENSE、main 分支 commit API 和 Releases API 在 2026-09-16 18:05 Asia/Shanghai 可核验的信息，tsouza/cerberus 当前有 68 stars、3 forks，主要语言为 Go，license 为 Apache-2.0。仓库创建于 2026-05-05 21:29:01 UTC，latest push 是 2026-09-16 09:59:04 UTC。最新 main commit 是 26450b5，提交时间 2026-09-16 09:59:02 UTC，主要增加给开发者与 agent 使用的 compact semantic guide。最新 GitHub Release 是 v1.20.0，发布于 2026-09-07 16:39:22 UTC。

项目概览

属性详情
仓库tsouza/cerberus
定位Prometheus / Loki / Tempo HTTP API 到 ClickHouse 的只读查询网关
Stars / Forks68 / 3
主要语言Go
许可证Apache-2.0
创建时间2026-05-05 21:29:01 UTC
Latest push2026-09-16 09:59:04 UTC
最新 commit26450b5，新增 compact semantic guide 文档
最新 Releasev1.20.0，2026-09-07 16:39:22 UTC
最低 ClickHouse 版本24.8
数据前提标准 OpenTelemetry ClickHouse schema

关键不是替换 Grafana，而是保留查询习惯

Cerberus 的边界很清楚。它不是一个新的 telemetry backend，更不是 exporter 或 rule engine；它只负责读。OTel Collector 继续把 metrics、logs、traces 写入 ClickHouse 的标准表结构，Cerberus 在另一侧暴露 /api/v1/query_range、/loki/api/v1/query_range、/api/search 等兼容入口。这样迁移时的第一步可以只是替换 datasource URL，而不是让所有 dashboard owner 学一门新查询语言。

这对已经积累了大量 PromQL recording rule、Loki log panel 或 Tempo trace drill-down 的团队尤其实际。它并不承诺“迁过去一定正确”；项目专门提供 migrate 命令，用来收集 rule 与导出的 dashboard query，预览 SQL，并同时向原 backend 与 Cerberus 重放查询、比对结果。这个顺序很值得借鉴：先用真实 query 证明兼容性，再谈 cutover。

三种语言，一个优化管线

README 描述的执行路径是：parse → shared plan → optimize → ClickHouse SQL → upstream wire format。PromQL 使用上游 prometheus/promql/parser；LogQL 与 TraceQL 则是根据公开 grammar 实现并用真实 Grafana parser 做差分测试的 Apache 许可实现。无论具体兼容度如何，这个设计至少避免了三种信号分别造三套 query engine。

对使用者来说，最有意思的不是“能跑 SQL”，而是可以继续从 Grafana 的同一套浏览、告警和探索工作流进入数据。对 ClickHouse 来说，它得到的是经过解析与优化的 SQL，而不是让每个 dashboard 用户各自手写查询。项目还说明 rate() 的 range query 默认追求和 Prometheus 一致；面向大规模数据的原生 ClickHouse 快路径则被明确标为实验性，保留了精度与资源使用之间的取舍。

先用附带的本地栈验证

项目的最短试用方式并不需要先接入自己的 ClickHouse。README 给出的 compose 会启动单节点 ClickHouse、带预置 datasource 的 Grafana、Cerberus，以及确定性的 OTel fixture：

git clone https://github.com/tsouza/cerberus.git
cd cerberus
docker compose up --wait

# Grafana: http://localhost:3000
# Cerberus: http://localhost:8080

这比直接拿生产 dashboard 做第一轮验证更稳妥。先观察 metrics、logs、traces 的常见 query 是否都有预期结果，再选一份真实但可控的 dashboard export 交给 cerberus migrate。确认差分结果、延迟和资源使用后，才值得将 Grafana datasource 指向实际环境。

前提与边界比安装命令更重要

Cerberus 支持的底座是 ClickHouse 24.8+，并假定数据符合 OpenTelemetry Collector ClickHouse exporter 的标准 schema：trace、log 和不同类型的 metric 各自有表。已有表结构不同并不必然无法用，但需要通过 CERBERUS_SCHEMA_* 设置显式映射；不要把“都在 ClickHouse”误解为天然兼容。

它也不会替代所有组件。README 明确指出它不 ingest、不存储，也没有 rule engine；recording 与 alerting rule 仍由原有 evaluator 或其他系统负责。虽然对 Grafana 的 query side 做了兼容性工作，年轻项目仍在快速变化，尤其是复杂 LogQL、TraceQL、版本差异、基数极高或大范围 rate() query，都应该用自己的数据与原 backend 做差分验证。README 所说的 stable wire API，不等于每个部署都已证明适合生产。

总结

tsouza/cerberus 有价值的地方，是把“统一存储”和“保留已有观测习惯”之间的断层补了起来。它不要求团队把 PromQL、LogQL、TraceQL 全部改写成 ClickHouse SQL，而是把迁移风险收敛到可测试的 gateway 与 datasource 切换。若你正考虑让 OpenTelemetry 数据更多地落在 ClickHouse，同时不想一次性推翻 Grafana 里的多年积累，这个小项目值得先在隔离环境跑一轮真实 query 的差分测试。

项目地址：https://github.com/tsouza/cerberus