时序数据库为什么选 Prometheus

最新推荐文章于 2024-08-18 18:03:33 发布

boonya

最新推荐文章于 2024-08-18 18:03:33 发布

阅读量989

点赞数

分类专栏： # 时序数据库 # 数据监控管理

原文链接：https://yq.aliyun.com/articles/692033

版权

时序数据库同时被 2 个专栏收录

15 篇文章 2 订阅

订阅专栏

数据监控管理

12 篇文章 0 订阅

订阅专栏

原文地址：https://yq.aliyun.com/articles/692033

Prometheus 与 Graphite

Prometheus 与 InfluxDB

Prometheus 与 OpenTSDB

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 的高可用性模式，提供了一个完全开源的冗余选项。