前言
Prometheus是CNCF的毕业项目，其生态已成为云原生监控领域的事实标准。Kubernetes集群的指标通过Prometheus格式暴露，很多新项目也直接选择Prometheus格式暴露指标数据，传统应用（比如MySQL, MongoDB，Redis等)在开源社区都有Prometheus Exporter来接入Prometheus生态。
Prometheus内置的tsdb适合存储短期数据，很多用户将InfluxDB可以作为Prometheus的长期存储方案，但是目前该架构的查询性能还不够高效，阿里云InfluxDB为了解决查询痛点，实现了PromQL查询接口，为用户提供更好的Prometheus查询体验。
Prometheus和PromQL
Prometheus是基于Pull模式的指标(metircs)系统，由开源社区管理维护，其设计秉承了传统的Unix设计哲学：Do one thing and do it well, 专注核心功能，其他的功能比如用户认证，TLS加密等则通过成熟的第三方组件比如nginx来实现。Prometheus明确定位为metrics监控系统，不适用于Logs，events，tracing等场景。 对于高可用，虽然Prometheus自身是单机系统，但是社区中有Thanos和Cortex这些开源项目提供集群和扩展能力。这几个开源社区之间有着良好的合作关系，比如部分开发者是两个项目的maintainer。 Prometheus的架构如下图所示：
PromQL是Prometheus 提供的查询语言，简单易用的同时具有丰富的功能，比如时间线过滤和各种聚合函数，支持subquery。PromQL通过标准的HTTP接口实现，Grafana等可视化工具都使用PromQL进行数据查询。下面的简单例子就可以返回最近5分钟内的http请求速率(一秒为单位):
rate(http_requests_total[5m])远端存储的查询痛点
从存储看，Prometheus内置的tsdb适合存储短期数据；对于长期存储，Prometheus提供了开放的生态，通过Remote API方式支持其他存储系统。InfluxDB作为当今流行度最高的时序数据库，也实现了Prometheus Remote API，被很多用户选择作为Prometheus的长期存储方案。典型使用场景如下图所示：
Prometheus配置远端写入后，会从本地TSDB的WAL日志文件中读取数据，放到内存队列中进行发送。同时为了提升发送效率，数据会分片到多个队列并行传输，而分片数量(即并发度）是可以配置的。如下图所示：
对于数据查询，Prometheus会基于时间范围和label过滤从远端拉取全部的原始数据点，然后在本地进行PromQL计算。这意味着，当需要计算的数据量较大时，数据传输量也会很大；另一方面，因为remote read协议要求一个查询的结果通过一个http response返回，服务端和客户端都需要在内存中缓存大量数据，造成很大的内存压力。实践中我们也遇到了大量并发查询导致的OOM问题。
集成的PromQL查询功能
为了解决Prometheus查询的性能问题，阿里云InfluxDB集成了PromQL查询功能，实现了与Prometheus完全兼容的PromQL Query API，用户可以直接将InfluxDB作为Prometheus来查询。
对于Grafana用户，仅需要修改下数据源的URL地址，就可以无缝切换到InfluxDB，原有dashboard不需要任何改动，就可以使用更快的查询链路。除了PromQL查询，InfluxDB也实现了PromQL的metadata API，Grafana中的自动提示补全功能也不会受到到影响。
集成PromQL之后的查询链路如下图所示：
首先可以看到，查询链路更短了，节省了数据传输带宽以及数据压缩等时间消耗。
从InfluxDB内部看，PromQL查询直接对接TSM存储引擎，以iterator方式访问本地数据，极大降低了查询耗时。
实现方式如下图所示：
- PromQL的查询通过HTTP API到达InfluxDB后，会解析为AST，这些处理逻辑同Prometheus是没有区别的。
- 核心工作是实现PromQL与InfluxDB的TSM存储引擎之间的交互，这通过实现querier接口来对接。querier接口是PromQL访问存储层的接口，提供了时间线过滤和时间范围过滤功能，返回数据以时间线方式组织，每条时间线内以iterator方式遍历每个数据点(时间戳+值的组合)。
- 查询处理层通过iterator方式(即火山模型)从存储引擎中读取数据，如果每个数据点都去底层文件中去读显然是不高效的。事实上，InfluxDB的TSM引擎是也是基于时间线来存储数据的，每条时间线的数据划分为block，每个block存储1000个数据点，所以以block为单位批量读取数据是十分高效的，将IO消耗降到了最低。这对应了实现了prometheus的block iterator接口。
- 因为InfluxDB支持灵活的数据分片，数据可能存储在多个shard中，所以中间需要增加一个抽象的merge层，将多个shard中的数据进行合并，也就是将多个iterator合并排序为一个iterator。这里的实现其实是深度优化的，性能远远高于社区版原始的merge iterator实现；具体的优化思路这里不详述，大家可以参考已经合并到社区的代码(https://github.com/influxdata/influxdb/pull/17596)
除了查询性能，这个架构也为Prometheus用户带来其他功能增强：
- InfluxDB支持用户认证，具有更好的安全性；而Prometheus如前文提到的，需要配置nginx等额外组件来实现认证。
- 多个Prometheus实例可以将数据写入同一个InfluxDB数据库，这就实现了Federation功能，自动完成了查询的聚合。Fedoration功能是Thanos和Cortex这些项目的目标之一，因为Prometheus一般部署在多个环境(比如多个region)，拥有一个global view来查询数据是十分有价值的。
- 使用单个InfluxDB实例，不同Prometheus的数据可以写入不同的数据库，相当于实现多租户功能，一个实例服务多个Prometheus系统，可以降低用户的部署成本。
如何使用InfluxDB提供的PomQL查询功能呢？ 如果你是Grafana用户，阿里云可以作为Prometheus的drop-in replacement来使用，仅仅需要修改(或者新建)Prometheus数据源即可无缝切换，之前创建的dashboard无需任何修改。
配置方式参考下图：
总结和展望
通过集成Prometheus查询API，InfluxDB可以更好的服务Prometheus生态，提供低成本的长期存储以及高性能的查询体验。
Prometheus和InfluxDB都是开源项目，我们会以开放的心态回馈开源社区，推进InfluxDB与Prometheus生态的融合。对于Prometheus Remote Read API，社区已经在实现stream方式返回数据，阿里云InfluxDB会及时同步这些功能，进一步提升用户的查询体验。
