1.3 时序数据库为什么选 Prometheus

Prometheus 与 Graphite

范围

Graphite 专注于成为一个具有查询语言和绘图功能的被动时间序列数据库。任何其他问题都由外部组件处理。

Prometheus 是一个完整的监控和趋势系统,包括内置和活动的抓取、存储、查询、绘图和基于时间序列数据的报警。它知道监控应该是什么样子(监控点应该存在,时间序列模式意味着什么问题,等等),并积极地寻找错误。

数据模型

Graphite 存储命名时间序列的数字样本和 Prometheus 所做的一样。然而,Prometheus 的元数据模型更丰富。

Graphite metric 名称由点分隔的编码组成,这些编码较为隐藏。而 Prometheus 将显式地编码为 key-value 对称为 label,附加到 metric 名称上。这允许通过查询语言对这些 label 进行简单的筛选、分组和匹配。

此外,特别是当使用 Graphite 与 StatsD 结合使用时,通常只在所有被监视的实例上存储聚合数据,而不是将实例作为维度保存,并能够深入到各个有问题的实例中。

例如,Graphite / StatsD 存储 api-server 返回值为 500 的 HTTP 请求的数据会像下面一样

stats.api-server.tracks.post.500 -> 93

在 Prometheus 中,相同的数据会被编码成如下的样子,(假设有三个 api-server 实例)

api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31

数据存储

Graphite 将时间序列数据以 Whisper 格式存储在本地磁盘上,Whisper 格式是一种期望样本定期到达 RRD-style 数据库。 每个时间序列都存储在一个单独的文件中,新的采样数据会在一段时间后覆盖旧的采样数据。

Prometheus 也为每个时间序列数据创建一个本地文件,允许在发生剪贴或规则评估时以任意间隔存储数据。 由于新数据只是简单地追加,旧数据可以任意地保持较长时间。 Prometheus 也适用于许多短暂的、频繁变化的时间序列。

总结

Prometheus 提供了更丰富的数据模型和查询语句,并且更易于运行和集成到您的环境中。如果您想要能够长期保存历史数据的集群解决方案,那么 Graphite 可能是更好的选择。

Prometheus 与 InfluxDB

InfluxDB 是一个开放源码的时间序列数据库,具有可伸缩和集群的商业选项。 在 Prometheus 开发项目开始将近一年后,InfluxDB 项目发布了,因此我们当时无法考虑将其作为替代方案。 尽管如此,Prometheus 和 InfluxDB 之间仍然存在显著的差异,而且这两个系统都针对稍微不同的用例。

范围

为了进行公平的比较,我们还必须将 Kapacitor 和 InfluxDB 一起考虑,因为它们结合起来处理与 Prometheus 和 Alertmanager 相同的问题场景。

InfluxDB 提供连续查询,这相当于 Prometheus 记录规则。

Kapacitor 的场景是 Prometheus 记录规则、警报规则和 Alertmanager 通知功能的组合。 Prometheus 提供了一种更强大的查询语言,用于绘图和警报。 Prometheus 的 Alertmanager 还提供了分组,去重功能和静默功能。

数据模型和存储

与 Prometheus 一样,InfluxDB 数据模型也有 key-value 作为 labels ,称为 tag。 此外,InfluxDB 还有一个二级 labels 称为 field ,在使用上更加有限。 InfluxDB 支持纳秒级的时间戳,以及float64、int64、bool和字符串数据类型。 相比之下,Prometheus 支持 float64 数据类型,但对字符串和毫秒级分辨率时间戳的支持有限。

InfluxDB 使用了用于存储的一个变种 具有写前日志的日志结构合并树 (Storage Engine),用时间分片。 这比 Prometheus 的 “每个时间序列只添加一个文件” 方法更适合于事件日志记录。

Logs and Metrics and Graphs, Oh My! 这篇文章描述了事件日志记录和指标记录之间的差异。

体系结构

Prometheus 的服务器彼此独立运行,仅依赖本地存储实现核心功能:抓取、规则处理和警报。开源版本的 InfluxDB 也是类似的。

根据设计,商业的 InfluxDB 产品是一个分布式存储集群,存储和查询由多个节点同时处理。

这意味着商业的 InfluxDB 将更容易横向扩展,但也意味着您必须从一开始就管理分布式存储系统的复杂性。 Prometheus 将更易于运行,但在某些时候,您将需要根据可伸缩性边界(如产品、服务、数据中心或类似方面)显式地对服务器进行切分。独立服务器(可以冗余地并行运行)还可以提供更好的可靠性和故障隔离。

Kapacitor 的开源版本没有用于规则、警报或通知的内置的分布式/冗余选项,。 Kapacitor 的开源版本可以通过用户手工分片进行扩展,类似于 Prometheus 本身。 Influx 提供企业级的 Kapacitor,支持HA/冗余警报系统。

相比之下,Prometheus 和 Alertmanager 通过运行 Prometheus 的冗余副本并使用Alertmanager 的高可用性模式,提供了一个完全开源的冗余选项。

总结

这两个系统有许多相似之处。 它们都有 labels (在 InfluxDB 中称为 tag)来有效地支持多维 metric 。 两者使用的数据压缩算法基本相同。 两者都有广泛的集成,包括彼此之间的集成。 它们都有钩子,允许您进一步扩展它们,例如在统计工具中分析数据或执行自动化操作。

InfluxDB 的优点

  • 存储事件日志
  • 商业版本提供集群功能,对于存储长期数据是有帮助的。
  • 数据副本之间的视图是一致的

Prometheus 的优点

  • 存储指标数据。
  • 更强大的查询语言、警报和通知功能。
  • 高可用、很好的绘图功能、警报功能。

InfluxDB 由一个单一的商业公司遵循开放核心模型,提供高级功能,如闭源集群、托管和支持。 Prometheus 是一个完全开源和独立的项目,由许多公司和个人维护,其中一些还提供商业服务和支持。

Prometheus 与 OpenTSDB

OpenTSDB 是基于 Hadoop 和 HBase 的分布式时间序列数据库。

范围

这里适用的一般范围差异与 Graphite 的情况相同。

数据模型

OpenTSDB 的数据模型几乎与 Prometheus 的数据模型相同:时间序列由一组任意的 key-value 对(OpenTSDB 是 tag 而 Prometheus 是 label )。

所有 metric 数据存储在一起,限制了 metric 的基数。但是有一些细微的区别: Prometheus 允许在label 值中使用任意字符,而 OpenTSDB 的限制更严格。

OpenTSDB 也缺乏完整的查询语言,只允许通过其 API 进行简单的聚合和数学运算。

数据存储

OpenTSDB 的存储是在 Hadoop 和 HBase 上实现的。这意味着很容易横向扩展 OpenTSDB,但是您必须从一开始就接受运行 Hadoop/HBase 集群的总体复杂性。

Prometheus 最初运行起来会更简单,但一旦超过单个节点的容量,就需要手动的分开。

总结

Prometheus 提供了更丰富的查询语言,可以处理更高的基数指标,并构成一个完整监控系统的一部分。 如果您已经在运行 Hadoop,并且看重长期存储而不是这些好处,那么 OpenTSDB 是一个不错的选择。

Prometheus 与 Nagios

Nagios 是一种起源于20世纪90年代的监视系统,名为 NetSaint。

范围

Nagios 主要是基于脚本的退出代码发出警报。这些被称为“check”。有个别报警会静默,但没有分组,路由或重复数据删除。 Nagios 有各种各样的插件。例如,允许通过管道将几千字节的插件数据返回到时间序列数据库,如 Graphite ,或者使用 NRPE 在远程机器上运行检查。

数据模型

Nagios是基于主机的。每个主机可以有一个或多个服务,每个服务可以执行一个检查。 没有标签或查询语言的概念

数据存储

除了当前的检查状态外,Nagios本身没有存储。有一些插件可以存储数据,比如 visualisation。

结构体系

Nagios服务器是独立的。所有检查的配置都是通过文件进行的。

总结

Nagios 适用于基本监视小型系统或者静态系统,在这些系统中,黑盒探测就足够了。 如果您想进行白盒监控,或者拥有一个动态或基于云的环境,那么 Prometheus 是一个不错的选择。

Prometheus 与 Sensu

Sensu 是一个可组合的监视工作流,可以复用现有的 Nagios 检查。

范围

这里适用的一般范围差异与 Nagios 的情况相同。

还有一个客户端套接字允许将特别的检查结果推送到Sensu中。

数据模型

Sensu 拥有与 Nagios 相同的粗略数据模型。

数据存储

Sensu使用Redis持久化监控数据,包括Sensu客户端注册表、检查结果、检查执行历史和当前事件数据。

体系结构

Sensu有许多组件。它使用RabbitMQ作为传输,使用Redis表示当前状态,使用单独的服务器进行处理和API访问。 可以对Sensu部署的所有组件(RabbitMQ、Redis和Sensu服务器/API)进行集群,以实现高可用性和冗余配置。

总结

如果您希望按原样扩展现有 Nagios 设置,或者希望利用 Sensu 的自动注册特性,那么 Sensu 是一个不错的选择。 如果您想进行白盒监控,或者拥有一个非常动态的或基于云的环境,那么 Prometheus 是一个不错的选择。

results matching ""

    No results matching ""