ClickHouse 推出 TimeSeries 引擎，可替代 Prometheus

为什么 Prometheus 指标能从自己的查询语言中获益？

PromQL 并不是 SQL 的简写形式。PromQL 存在的原因既在于数据的形态，也在于 Prometheus 自身设计中所做的决策；并且作为一种指标规范。每一项决策都建立在一个历经十余年沉淀的设计之上，以便能够应对观察分布式系统所需的规模与协调能力。

Prometheus 始于 2012 年的 SoundCloud，由刚刚离开 Google 的工程师们构建，他们希望获得自己在 Google 内部使用过的相同特性：维度数据模型、基于拉取的采集路径，以及一种能同时理解两者的查询语言。同年，Julius Volz 编写了 PromQL 的第一种形式，作为已经能够抓取、存储和绘图的原型的一部分。公开发布于 2015 年 1 月到来。从那时起，这种语言和这些类型就一直成对出现，这就是为什么今天接触 PromQL 的读者所接触到的，是一个已有十多年历史的数据模型。

这个模型之所以传播开来是有原因的。2016 年 5 月，云原生计算基金会接受 Prometheus 作为其第二个托管项目，紧接在 Kubernetes 之后。Prometheus 是为这样一种环境而构建的：实例生命周期短暂，身份是一组标签而非主机名。而这正是 Kubernetes 后来在所有地方创造出的环境。一代平台团队同时继承了两者。这就是为什么如此多的组织运行着他们从未刻意选择的 PromQL 仪表盘和告警。

要理解为什么 Prometheus 指标能从自己的查询语言中获益，我们必须理解它们的生命周期。让我们走一遍 Prometheus 指标的生命周期：

为拉取而呈现

在 Prometheus 的设计中，应用程序不会显式地向接收方发送其指标。它在 HTTP 端点上暴露自己的当前状态并等待。该载荷中没有时间戳，没有历史记录，也不承诺会有人读取它。

这一单一决策几乎塑造了 Prometheus 数据被采集、存储和查询方式的方方面面。被插桩的服务不需要投递缓冲区，不需要后端地址，也不需要处理缓慢或不可用的监控系统。它只是暴露自己的当前状态。这通过将更困难的工作（例如采集、计时、存储和故障处理）下移到下游，使应用程序易于插桩。

代价是应用程序对时间一无所知，因此每一个关于时间的问题都由其他地方的某个东西来回答。一个起初简单的采集选择，成为了整个系统的基础。

为采集而抓取

采集器按间隔拉取每个端点，时间线就在那一刻被创建。应用程序贡献一个值。这些值要么作为计数器单调递增，要么作为仪表任意递增和递减，要么作为直方图进行分桶测量，要么作为摘要进行聚合测量。你可以在官方文档中了解更多关于四种核心 Prometheus 指标类型的信息 这里。然而，它们都没有时间戳。贡献时间戳的是采集器；具体来说是在抓取时。

拉取为你提供了目标发现、抓取本身中的健康信号，以及一种在指标系统降级时天然保护应用程序的设计。代价是它不会给你一条规则的时间线。间隔会在负载下漂移，抓取会失败并留下空缺，目标会随着每次部署而出现和消失。描述同一请求路径的两条序列，在同一时间窗口内可能持有不同数量的样本。

为存储而编码

由于一次抓取只携带当前状态，类型就必须承载其余的含义。这就是为什么 Prometheus 类型在普通的数值列旁边看起来不寻常。

仪表是直截了当的情况，按读取时的原样即有意义。计数器则不是。它只会增加，除非作为两次读取之间的差值，否则毫无意义，并且当进程重启时会回到零。直方图甚至更复杂：一次抓取无法携带一个分布，因此直方图是作为一组共享 le 标签的累积桶序列家族发布的（le 是短语“小于或等于”的缩写），而分布只有在这些兄弟序列被重新组合后才存在。

类型是一份契约。它说明这个数字允许如何被解释，并且它承载了列定义无法承载的信息。

为观察而查询

当查询运行时，前面的三项决策已经定下了它的条款。

以 irate(http_requests_total[5m]) 为例。重置必须被解读为一次重启，而不是下降了几百万。样本很少正好落在窗口边界上，因此结果必须通过外推来触及范围的两端。间隔各不相同，因此窗口不能假定样本数量固定。上述每一项都直接源于呈现、抓取和编码。

histogram_quantile(0.95, ...) 则从另一个方向继承了同样的负担。它按 le 重新分组兄弟桶序列，按顺序合并它们的计数，并在持有目标排名的桶内进行插值。

这就是为什么 Prometheus 指标能从自己的语言中获益；也是为什么 PromQL 作为一种自己的语言而存在。它承载了一个为不可预测投递而构建的数据模型所积累的知识，并将这些知识应用到每一次查询中，而无需要求键盘前的人记住其中任何一点。

在此预览之前，没有标准的方式在 ClickHouse 中用 PromQL 查询 Prometheus 指标。团队要么用 SQL 重写他们的查询，要么构建并维护自己的 PromQL 到 SQL 的转换层。

所有这些都可以用 SQL 表达，但要正确翻译它却很困难。每一个 PromQL 函数都带有边界条件，甚至重置处理上的细微差异都可能产生一个看起来合理但返回不同结果的查询。在迁移期间，这些不一致恰恰会在最糟糕的时刻削弱信心。

在 ClickHouse 内部评估 PromQL 把这个责任放到服务器端。它让我们能够保留该语言的精确语义，并产生用户已经从 Prometheus 那里期望得到的相同结果。这种一致性让团队有信心，他们可以迁移而不会悄悄改变仪表盘、告警或查询的含义。ClickHouse 如何高效地实现这一点本身就是一个独立的话题，所以我们将在另一篇文章中介绍。

我们对性能非常执着，而这种执着超越了 SQL 的边界。我们的责任不仅仅是将 PromQL 转译为 SQL，更是将 PromQL 转译为高性能的 SQL，我们乐意承担这一责任。

私有预览中包含什么？

一个 Prometheus 部署完成四项工作。有东西抓取目标，有东西存储样本，有东西回答查询，有东西评估规则。

这个预览接管了存储和查询。

采集保持不变。继续使用你已经运行的 Prometheus 服务器、代理或 OpenTelemetry Collector，并保留你调优过的抓取配置。ClickHouse 通过 Prometheus remote-write v1 协议接收它们产生的数据。

样本落入一个 TimeSeries 表，该表存储指标元数据、一组标签以及带时间戳的值。检索就是 PromQL 登场的地方。任何已经面向 Prometheus HTTP API 的工具都可以指向该服务并查询它。Prometheus 服务器可以将该表作为远程读取后端来读取。 clickhouse-client 通过其 promql 方言直接评估 PromQL。SQL 通过 prometheusQuery 和 prometheusQueryRange 表函数访问它。这四种方式都在服务器内部运行同一个 PromQL 实现，因此无论你从哪里发送查询，它的含义都相同。

最后，如果你正在寻找一个告警评估工具来将你的告警规则和记录规则带入 ClickHouse，请继续关注后续公告。

如何将指标导入？

一旦你的 ClickHouse Cloud 服务被我们的支持团队升级，就创建一个 TimeSeries 表。列清单是可选的，默认值是一个合理的起点。

1CREATE DATABASE prometheus;2CREATE TABLE prometheus.metrics ENGINE = TimeSeries;

如果你运行 Prometheus，将该端点添加为远程写入目标：

1remote_write:2-url:https://your-service.clickhouse.cloud:8443/prometheus/api/v1/write?database=prometheus&table=metrics3basic_auth:4username:default5password:<password>

如果你使用 OpenTelemetry Collector 采集指标，请使用 Prometheus 远程写入导出器：

1extensions:2basicauth/demo:3client_auth: { username:default, password:"<password>" }4...5exporters:6prometheusremotewrite:7endpoint:https://your-service.clickhouse.cloud:8443/prometheus/api/v1/write?database=prometheus&table=metrics8auth:9auth: { authenticator:basicauth/demo }

如何查询它？

查询 Prometheus 服务器有很多种方式，各有优缺点。以下是你可以使用的所有方式：

通过 Grafana

将 Grafana 的 Prometheus 数据源指向该服务。URL 止于 /api/v1 之前，表选择作为查询参数传递：

1apiVersion:12datasources:3-name:ClickHousePrometheus4type:prometheus5access:proxy6url:https://your-service.clickhouse.cloud:8443/prometheus7basicAuth:true8basicAuthUser:default9jsonData:10httpMethod:GET11customQueryParameters:database=prometheus&table=metrics

通过 Curl

1curl --user default:<password> --get \2"https://your-service.clickhouse.cloud:8443/prometheus/api/v1/query" \3  --data-urlencode "query=rate(http_requests_total[5m])" \4  --data-urlencode "database=prometheus" \5  --data-urlencode "table=metrics"

通过 clickhouse-client CLI

1clickhouse-client \2  --dialect promql \3  --promql_database prometheus \4  --promql_table metrics \5  --query 'rate(http_requests_total[5m])'

通过 ClickHouse 会话中的 SQL

1SELECT2    tags['service'] AS service,3    time_series4FROM prometheusQueryRange(5    prometheus.metrics,6'sum by (service) (rate(http_requests_total[5m]))',7    now() -INTERVAL1HOUR,8    now(),9INTERVAL1MINUTE10);

现在宣布，通过 ClickStack

作为同一私有预览的一部分，ClickStack 将 TimeSeries 表暴露为 PromQL 数据源。配置好数据源后，你在图表编辑器中编写 PromQL，ClickStack 会通过由 ClickHouse 支持的 Prometheus 兼容接口发送它。

该预览涵盖图表、仪表盘、序列查询和标量查询。ClickStack 还可以将 PromQL 代理到外部 Prometheus 兼容端点，因此存储在 ClickHouse 之外的指标也可以通过同一接口读取。

该私有预览侧重于通过图表和仪表盘探索指标。你直接在图表编辑器中编写 PromQL；尚不支持可视化 PromQL 查询构建器以及基于 PromQL 查询的告警。

ClickStack 还支持 PromQL 查询中的变量，允许你将过滤值传入表达式，并在指标、日志和追踪之间协调过滤。我们正在积极扩展这一集成。