怎么选择合适的时间序列数据库？
ADDOPS团队赵鹏 360云计算
女主宣言
该文章出自于ADDOPS团队，是一篇关于prometheus 的译文，前面的文章《震惊！尽然还有这种类型的数据库？》是关于时间序列数据库的简单介绍。该文是上述文章的续集，主要Prometheus 与其他的时间序列db的对比分析。希望能给大家选择时间序列db的时候提供一些启发。 PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！
前言
本文译自 COMPARISON TO ALTERNATIVES ,翻译的比较粗浅,希望能对了解 prometheus 有所帮助.
Prometheus VS Graphite
适用范围
Graphite 关注点是作为一个被动机制的时间序列数据库,有自己的查询语言和绘图方式.其他特性需要通过外部组件来实现.
prometheus 是一套完整的监控和趋势系统,在时序数据基础上内建主动抓取,搜索,绘图和报警系统.有丰富的官方和第三方贡献的监控收集工具
数据模型
Graphite 和 Prometheus 一样存储命名后的时间序列数据.当然 prometheus 的元数据模型更加丰富.Graphite 以"."作为分割符命名监控项,而promethues 在命名监控项时通过添加Key/value标签,使得在查询时更容易进行过滤,分组和匹配. 而且当 Graphite 和 StatsD 结合使用时.一般只会存储聚合后的所有监控实例的监控数据,而不是以实例为纬度,很难深入挖掘问题.
在这里有一个例子.我们要存储 /tracks 接口 POST 请求的 500 返回值的数量. 在Graphite 或 StatsD 中如下:
stats.api-server.tracks.post.500 -> 93
在 prometheus 中相同的数据如下存储(以收集三台接口服务器为例).
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31
存储方式
Graphite 以Whisper格式在本地磁盘存储时序数据,类似于 RRD 的形式(但 Whisper 可随机更新任意过去时间的数据,但周期固定,).每一个时序数据存储在不同的文件中.新监控数据在一定周期后会覆盖旧的数据.
Prometheus 也会为每个时序数据创建一个本地文件,但是允许按照抓取的任意周期或规则任务触发的时间存储数据.当新数据被添加进来后,旧数据依然能按需求保持任意时间.prometheus 也十分适合短时且经常变化的时序数据.
总结
prometheus 提供更丰富的数据类型和查询语言,并且十分易于部署和融入现有环境.如果想使用一个有集群解决方案并且希望存储长期数据,Graphite 可能是更好的选择.
Prometheus VS InfluxDB
InfluxDB 是一个开源时序数据库,并且提供商业化(需付费)的集群和扩容解决方案.Prometheus 和 InfluxDB 之间有着显著的差异,同时两者也面向不同的应用场景.
适用范围
在这里需要将 Kapacitor 和 InfluxDB 作为一个组合一起同进行对比,因为同 Prometheus 和 Alertmanager一样,这两组工具实现的功能是为了处理相同的问题.
Kapacitor 是一个混合了 prometheus 的数据处理,存储规则,报警规则,以及Alertmanager通知功能的工具.Prometheus 提供了与之相比更强大查询语言用于绘图和报警.并且Prometheus Alertmanager进一步提供了分组,去重和除噪声的功能.
数据模型和存储
和 Prometheus 相同,InfluxDB 的数据模型包含Key/Value对标签.此外 InfluxDB 还包含一个二层标签field.InfluxDB支持纳秒级的时间纬度,以及float64, int64, bool, 和字符串数据类型.Promethues 作为对比只支持 float64 和有限的字符串支持,并且时间维度为纳秒级.
InfluxDB 使用自己实现的 TSM Tree 的算法， LSM Tree(源于 bigtable 扩展阅读)，针对 InfluxDB 的场景做了特殊优化。比Prometheus向每个时序数据文件中增加数据的方式要更适合于事件日志.
Logs and Metrics and Graphs, Oh My! 描述了事件日志和监控指标记录的区别.
架构
prometheus 的服务器都独立运行,核心功能依赖于服务器的本地存储.开源版本的InfluxDB相同.
商业版本的 InfluxDB 提供通过设计一个分布式存储方案,使存储和查询能在不同节点上同时进行处理.
这就表明商业版本的 InfluxDB 更容易横向扩展,但也意味着你必须从最开始就要管理一个复杂的分布式存储系统.相对来说 Prometheus 的运行更佳简单,但是你也需要提前考虑好各个单独的 Prometheus 服务器的可扩展性.当然独立的服务器也能给你更好的可靠性和故障隔离.
Kapacitor 当前没有内建的分布式或冗余选项.作为对比Prometheus提供了冗余选项,配合运行prometheus冗余副本以并能使用Alertmanager的高可用模式.另外,Kapacitor可以同 Prometheus 一样通过用户手动分片进行扩容.
总结
两个系统之间有非常多的相似之处.都通过标签来支持多纬度监控指标.两者都使用基本相同的数据压缩算法.两者包括彼此之间都有广泛的集成.两者都有钩子以便将来进行扩展,例如在统计工具中进行数据分析或执行自动化操作.
InfluxDB 的优势:
- 进行事物日志监控.
- 商业化的InfluxDB集群方案,更加适合长期数据的存储.
- 副本间的数据一致性.
Prometheus 的优势:
- 主要用于监控指标收集.
- 更强大的搜索语言,报警,以及通知功能.
- 对于绘图和报警有更高的可用性和运行时间
Prometheus VS OpenTSDB
OpenTSDB 是一个基于 Hadoop 和 HBase 的分布式时序数据库.
适用场景
适用场景的对比与 Graphite 类似.
数据模型
OpenTSDB 的数据模型与 Prometheus 几乎相同:时序数据是由一组任意的键值对来确定的.所有指标的数据都存储在一起,同时限制指标的数量.虽然有细微的差别,例如 Prometheus 允许在标签中使用任意字符,但 OpenTSDB 有部分限制.OpenTSDB同时也缺乏完善的查询语言,只能通过 API 进行简单的聚合和数学计算.
存储
OpenTSDB 的存储在 Hadoop 和 HBase 之上实现.这说明我们可以非常容易的对 OpenTSDB 进行平行扩容.但是必须接受从最开始的时候就要维护十分复杂的 Hadoop/HBase 集群.
Prometheus 初期运行简单.但是当单个节点容量达到一定限度时要提前考虑分片的问题.
总结
Prometheus 提供更丰富的查询语言,可以处理更大基数的监控指标数量并且能形成完整监控系统的一部分.如果你已经运行了 Hadoop 集群并存储长期数据,那么 OpenTSDB 是一个比较好的选择.
Prometheus VS Nagios
Nagios 是起源于90年代名为"NetSaint"的开源监控系统
适用场景
Nagios主要是针对脚本的退出代码进行报警.能针对个别报警的停止报警功能,然而没有分组,路由和去重的功能.
Nagios 有十分多的插件.比如,perfData 插件中抽取出的几 kb 的数据可以发送到 Graphite 这样的时序数据库中,或者使用 NRPE 在远程逐级上运行检测命令.
数据模型
nagios本身没有存储,仅基于当前的状态.也有相关的插件可以存储数据,例如一些可视化插件(PNP4Nagios).
架构
Nagios 服务器都是单点运行.所有检测配置都是基于文件的.
总结
Nagios 适合那些用黑盒探测就足够的小规模或静态系统的基础监控. 如果你想做白盒监控,或者有一个动态的或者基于云计算的环境,那么Prometheus是一个好的选择.
Prometheus VS Sensu
Sensu 一般来说是一个更现代的 nagios.
适用场景
和 nagios 的大多数场景相同,这里只描述一些有区别的.
最主要的区别是 Sensu 的客户端会自行向中心节点注册,并能同时从中心节点或本地配置文件确定要运行的检测项目.Sensu 对抽取的性能检测数据的数量没有限制.
同时 Sensu 也有一个 client socket 允许将随机检测数据推送到 Sensu.
数据模型
Sensu 和 nagios 的数据模型一样稍显粗糙.
存储
Sensu 讲数据存放在 redis 中.主要用于存放被静音的报警和客户端注册信息.
架构
Sensu 包含许多组件.使用 Rabbitmq作为消息队列,redis 用于存放当前状态,以及用于处理数据的单独服务器. Rabbitmq 和 redis 都可以集群化.多个 Sensu 的副本可用作扩容和冗余.
总结
如果你已经在使用 Nagios,并希望使用 Sensu 的扩容和注册等高级功能.Sensu 是个不错的选择.
如果你想做白盒监控,或者有一个动态的或者基于云计算的环境,那么Prometheus是一个好的选择
总结
针对上述的四组对比，可能大家对当前的时间序列DB的优劣也有了大概的了解，希望能给大家之后的选型带来启发与帮助。
