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)拉取数据，然后在上报。
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 那样做强大的表与表之间的操作.
SELECT 100 - usage_idel FROM "autogen"."cpu" WHERE time > now() - 1m and "cpu"='cpu0'Prometheus 的查询语言也很有特点, 看起来会像 JSON , 但是通过它也可以实现各种强大的查询操作.
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 是比较合适的。
