拥抱开源生态:阿里云InfluxDB集成Prometheus查询-阿里云开发者社区

开发者社区> 开发与运维> 正文

拥抱开源生态:阿里云InfluxDB集成Prometheus查询

简介: 前言 Prometheus是CNCF的毕业项目,其生态已成为云原生监控领域的事实标准。Kubernetes集群的指标通过Prometheus格式暴露,很多新项目也直接选择Prometheus格式暴露指标数据,传统应用(比如MySQL, MongoDB,Redis等)在开源社区都有Prometheus Exporter来接入Prometheus生态。 Prometheus内置的tsdb适合存储短

前言

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用户带来其他功能增强:

  1. InfluxDB支持用户认证,具有更好的安全性;而Prometheus如前文提到的,需要配置nginx等额外组件来实现认证。
  2. 多个Prometheus实例可以将数据写入同一个InfluxDB数据库,这就实现了Federation功能,自动完成了查询的聚合。Fedoration功能是Thanos和Cortex这些项目的目标之一,因为Prometheus一般部署在多个环境(比如多个region),拥有一个global view来查询数据是十分有价值的。
  3. 使用单个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会及时同步这些功能,进一步提升用户的查询体验。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章