InfluxDB 与 Prometheus 两个时序数据库可以说是在一个十字路口,背向而行的两个数据库。怎么这么说呢?InfluxDB 是 push 的方式获取监控指标数据, Prometheus 是 pull 的方式获取监控指标数据, promethues 的生态也很完善,比如我们可以使用 cortex 来实现 多租户的管理, influxDB ,还不清楚。这里需要简单的去看一下 influxDB 和 prometheus 两个数据库,做一个比较。

准确的说,InfluxDB 是一个数据库,Prometheus 更偏向于一种解决方案。

监控体系

InfluxDB

一般的,使用 Telegraf + InfluxDB + Grafana + Kapacitor 搭建一套监控体系

Telegraf

Telegraf 是实现 数据采集 的工具。Telegraf 具有内存占用小的特点,通过插件系统开发人员可轻松添加支持其他服务的扩展。

在平台监控系统中,可以使用 Telegraf 采集多种组件的运行信息,而不需要自己手写脚本定时采集,大大降低数据获取的难度;且 Telegraf 配置极为简单,只要有基本的 Linux 基础即可快速上手。Telegraf 按照时间序列采集数据,数据结构中包含时序信息,借助 Influxdb 可以针采集得到的数据完成各种分析计算操作。

他可以采集当前运行主机的指定监控项,也可以从第三方消费者服务(Kafka)拉取数据,然后在上报。

influxdb组合监控架构体系

Kapacitor

是 InfluxDB 从零构建的 TICK 原生数据处理引擎,支持流式处理和批处理,同时也支持自定义的功能,比如告警阈值,告警指标特征,告警统计异常特征等,以及后续支持的告警操作。

基于Kapacitor可以轻松的创建告警,运行 ETL 作业和检测异常等,为高效的进行数据处理,Kapacitor 支持以下功能:

  • 同时支持 批流数据处理
  • 支持按计划从 InfluxDB查询数据,也支持通过行协议从 InfluxDB 接收数据
  • 支持 InfluxDB 协议格式的运算
  • 支持将经过运算的数据存储到 InfluxDB 中
  • 支持新增用户自定义异常检查功能
  • 生态丰富,可灵活对接第三方系统(HipChat,OpsGenine,Alerta,Senu,Slack等)

Chronograf

是 InfluxDBData 开源的一个 WEB 应用程序,主要负责将接收的监控数据进行可视化展示和告警,也支持通过灵活强大的模块和库快速配置仪表盘,告警规则,自动化规则。功能有:

ITjichu基础设施监控
  • 查看主机机器状态
  • 查看每个主机上已配置的应用程序
  • 使用 其 预先创建的仪表盘来监视应用程序
告警管理

为 Kapacitor 提供了原生的 WEB 用户界面,Kapacitor 是 influxData 的实时数据处理框架,用于创建告警策略,运行 ETL 作业以及检测数据中的异常。

数据可视化

这个和 Grafana 一致

数据库管理

InlfuxDB 其实就是一个数据库:

  • 创建和删除数据库以及保留策略
  • 查看当前正在运行的查询并终止高消耗的查询操作以避免系统过载
  • 创建和删除用户并为其分配权限
多组织和多用户支持
  • 创建组织并将用户添加到指定的组织

  • 限制访问管理功能

  • 允许用户为其创建和维护独立的仪表盘

兼容多协议

目前 , InfluxDB 兼容的数据传输协议有: UDP协议,CollectD协议,Graphite协议,OpenTSDB协议以及Promehues协议。这一点是 Prometheus 所做不到的。

Prometheus

一般的,我们使用 Exporter+ Prometheus+ Grafana + Alertmanager 搭建一套监控体系

Prometheus重视可靠性,但是做不到准确性(100%),比如说,请求计费,Prometheus 就不是一个很好的选择,因为 Prometheus 收集到的数据存在不够详细和完整。在这种情况下,用 InfluxDB 来收集和分析数据以进行计费计算回事比较好的,使用 Prometheus 来进行其他的监控。

数据采集的方式

Prometheus 和 InfluxDB 在数据的采集上两者选择了不同的极端,前者只能 pull , 后者只能 push .

Promethues 的数据采集器,我们称之为 exporter ,每一个 exporter 会对外开放一个 端口, 供 Prometheus Server 拉取数据。

InfluxDB 的数据采集器 Telegraf, influxDB 官方宣传插件化驱动。 这玩意的默认配置文件很多,包括 push 的目的地址,以及各种插件的控制目的等等。相比之下, Prometheus 的 exporter 是不需要任何的配置的,也不需要任何的依赖关系,也就是所谓的开箱即用。

数据存储

InfluxDB 的存储引擎是基于一种叫做TSM的自研引擎,做的是本身的存储。

Prometheus 则是柔和了 leveldb 与 自研的存储引擎.

Prometheus 提供了后端的存储,比如说 Cortex ,还可以基于 Cortex 进行多租户的管理设置。同时,InfluxDB 也可以作为 Prometheus 的存储后端。

InfluxDB嘛,再看。

数据查询(1分钟内 CPU 使用率)

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

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

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

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

高可用与集群功能

目前这两者从开源的角度上来说,前者做的不是很友好。

influxDB 的集群功能是商业功能,目前开源的有一个 高可用的套件: influxdb-relay .但是这个其实就是在 influxDB 前面增加了一个代理转发,数据经过的时候会被它分发到各个数据库实例上。但是这个不支持 QUuery 的操作,也就是说,在查询上,这个代理这边的数据聚合是一件很麻烦的事情。

告警

InfluxDB

使用 Kapacitor 实现,下面有介绍

Prometheus

使用 Alertmanager 实现。

在使用 Pronetheus 实现告警时,我们需要注意两个配置文件,alertmanager.yaml 和 ruler.yaml。 前者的配置主要针对于 Alertmanager组件 告警的相关设置,ruler.yaml 针对于 告警的触发条件的配置。也就是我们的告警规则。

结论

  • 如果只考虑监控, Prometheus 是最好的选择,至少在 Prometheus 和 InfluxDB 里面。 Prometheus 是最优秀的。
  • 但是,如果除了监控,还会有其他的一些业务指标,InfluxDB 是比较合适的。
  • 最好的情况是,Promnetheus 和 InfluxDB 共存,负责不同的监控