总览

首先要明白, Prometheus 提供的是一整套监控体系, 包括数据的采集,数据存储,报警, 甚至是绘图(只不过很烂,官方也推荐使用 grafana).
而 InfluxDB 只是一个时序数据库, 使用它做监控系统的话, 还需要物色数据采集器,如 telegraf, collectd 等. 甚至连报警模块, 也需要使用同为 Influxdata 公司出的 Kapacitor.从这个角度来说, Prometheus 会有运维上的优势, 因为它用起来确实很省事.

数据的采集

Prometheus 和 InfluxDB 在数据的采集上两者就选择了不同的极端, 前者只能 pull, 后者只能 push, 关于 pull 和 push 的对比,这里暂不多述.

Prometheus 把 数据的采集器叫做 exporter, xxx-exporter 运行之后会在机器上占用一个端口, 等待 Prometheus server 拉取数据.

InfluxDB 的数据采集器我们使用了 telegraf, 官方宣传插件化驱动, 其实也就那么回事, 编译的时候把很多东西的采集功能包进去压在一个二进制里面, 再用配置文件控制插件是否开启. 功能其实是蛮强大了. 也是 Go 编写, 部署算不上困难, 但用起来总会觉得多了一点什么东西.

存在感.

没错, 多了一种存在感, 对于数据采集 agent 这种东西, 存在感越低越好.

Telegraf 的默认配置文件就多达2000多行, 里面包括 push 的目的地址, 各种插件的控制目等等.相比之下, Prometheus 的 exporter 不需要任何配置文件, 不需要任何依赖, 真正的开箱即用.

但 Telgraf 有一个很吸引人的功能, 就是它能够作为一个转发代理接受来自不同程序的消息

比如可以运行一段脚本, 将结果按照一定的格式输出给 telegraf 默认的8186端口, telegraf 再写进 InfluxDB, 这样就把一个特殊的第三方业务的数据采集起来了, 不需要重启 Telegraf, 也不需要重启 InfluxDB.

如果换用 Prometheus 要怎么做呢? 我们需要引入 prometheus 的 SDK 自己编写 exporter, 而且 prometheus 会有四种指标类型,编写完之后需要去 Prometheus server 重新配置要抓取的目标, 整个下来是比 Telegraf 那一套要麻烦的.

如果你的需求很特殊, 要监控的很多第三方特殊的指标, 而对于常见的资源如硬件,数据库等监控需求不大, 那么 Telegraf + InfluxDB 会是一个不错的组合.

数据的存储

单单比较数据存储的那一部分, 它们两者之间也有很多不同.

InfluxDB 的存储引擎是基于一种叫做TSM的自研引擎, Prometheus 则是柔和了 leveldb 与 自研的存储引擎.

总的趋势都是基于时序数据进行优化, 不仅要照顾读写性能, 还要照顾删除性能与稳定性.

不过不管怎样,性能与数据的压缩对于使用者来说都不是第一要考虑的因素, 不是不重要,而是因为他们两者都做得很棒, 对于一个监控系统来说.

在使用的灵活性方面, InfluxDB 是优于 Prometheus 的,这是由于他们的产品定位决定的: InfluxDB 是一个时序数据库, Prometheus 是一个附带数据库的监控系统.举个例子, InfluxDB 有类似 Mysql 中数据库, 表的概念, 而且可以针对每个数据库设置不同的存储策略, 不得不说这些功能对于一个专门存放数据的软件系统来说还是很有吸引力的.

数据的查询

在数据查询上面, InfluxDB 的查询语言 InfluxQL 与 SQL 类似, 但是不能像 SQL 那样做强大的表与表之间的操作.

Prometheus 的查询语言也很有特点, 看起来会像 JSON , 但是通过它也可以实现各种强大的查询操作.

下面分别是 InfluxDB 和 Prometheus 查询1分钟内 CPU 使用率的语句

SELECT 100 - usage_idel FROM "autogen"."cpu" WHERE time > now() - 1m and "cpu"='cpu0'

100 - (node_cpu{job="node",mode="idle"}[1m]) 

如果硬要在查询语言上分个高低的话,我会选择 Prometheus, 原因很简单, 我觉得它更有友好与简单

高可用与集群功能

最后还要说一下集群和高可用性这块.很遗憾他们两个现在都做得不是很好,至少从免费的角度来说:)

InfluxDB 的集群功能是商业功能, 但是有一个高可用的套件叫做 Influxdb-relay, 这个一个跑在 InfluxDB 实例前面的一个转发代理, 数据经过它的时候会被分发到各个数据库实例上. 还凑合着能用吧,不过不支持 query 操作, 如果有需要的话可以参考这个fork https://github.com/shanexu/influxdb-relay

Prometheus 到目前为止还没有看到集群功能的消息, 高可用也是仅仅通过部署多个实例来实现, 这个方案是有局限性的, 就算不考虑资源的占用, 也会让系统的架构变得复杂.

笔者一直都在等待他们能一个高可用和集群部署的功能, 尤其是 Prometheus.因为毕竟总有公司需要数据有可靠性的保证的, 尤其是面向政企客户的公司.

有一段时间笔者学了 Raft 协议的后想要自己实现 InfluxDB 的集群功能, 但总是怕自己做不好, 花的时间打了水漂, 毕竟对于笔者这样的新手来选择把精力花在打实计算机基础以及扩充自己的知识面上面会更有性价比. 但是如果有哪位读者也有实现 InfluxDB 集群功能的想法, 请告诉我, 我很愿意一起协助...

报警

如果说在前面那两个方面 InfluxDB 和 Prometheus 还各有特点的话, 那么在报警这方面 InfluxDB 简直就是被 Prometheus 按在地上摩擦.

InfluxDB 官方出了一个叫做 Kapacitor 的软件, 官方说可以用它实现报警.
但是这货明明是拿来对 InfluxDB 做数据处理的, 用在监控系统的报警功能上面真的很差.

一方面是因为效率的原因, 它的工作原理是定时得去从 InfluxDB 取数据出来进行运算来检查是否触发报警条件, 而且万一数据库挂了的话岂不是报警也失效了 ? 一方面是它的 DSL 使用起来体验真心差, 谁用谁知道 !

总结

几个月体验下来, 笔者认为对于监控系统的选择来说, Prometheus 是不二之选,市场的反应也摆在我们面前了, 这就是趋势.

另外一方面, 如果你的业务不单单是监控系统, 还需要使用到一些时序数据库的特性用来存储其他数据, 那么也别纠结了, InfluxDB就是最适合的.