时序数据库为什么选 Prometheus

野性酷女 2023-07-21 05:49 9阅读 0赞

原文地址：[https://yq.aliyun.com/articles/692033][https_yq.aliyun.com_articles_692033]

**目录**

Prometheus 与 Graphite

范围

数据模型

数据存储

总结

Prometheus 与 InfluxDB

范围

数据模型和存储

体系结构

总结

Prometheus 与 OpenTSDB

范围

数据模型

数据存储

总结

Prometheus 与 Nagios

范围

数据模型

数据存储

结构体系

总结

Prometheus 与 Sensu

范围

数据模型

数据存储

体系结构

总结

原文链接

--------------------

# 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! ][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 与 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 是一个不错的选择。

# 原文链接 #

*  [https://prometheus.io/docs/introduction/comparison/][https_prometheus.io_docs_introduction_comparison] ， by Prometheus

**其他阅读：**

[Grafana + Prometheus 监控PostgreSQL][Grafana _ Prometheus _PostgreSQL]

[利用prometheus, Grafana, postgres\_exporter 搭建简单简单监控][prometheus_ Grafana_ postgres_exporter]

[Prometheus 系统监控方案 一][Prometheus _]

[Prometheus 系统监控方案 二 安装与配置][Prometheus _ _]

[Prometheus 监控 Nginx 流量 (三）][Prometheus _ Nginx _]

[剖析Prometheus的内部存储机制][Prometheus]

[Prometheus 应用监控 ][Prometheus 1]

[https_yq.aliyun.com_articles_692033]: https://yq.aliyun.com/articles/692033
[Storage Engine]: https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fdocs.influxdata.com%2Finfluxdb%2Fv1.2%2Fconcepts%2Fstorage_engine%2F
[Logs and Metrics and Graphs_ Oh My]: https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgrafana.com%2Fblog%2F2016%2F01%2F05%2Flogs-and-metrics-and-graphs-oh-my%2F
[https_prometheus.io_docs_introduction_comparison]: https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fprometheus.io%2Fdocs%2Fintroduction%2Fcomparison%2F
[Grafana _ Prometheus _PostgreSQL]: https://blog.csdn.net/weixin_30537391/article/details/95286751
[prometheus_ Grafana_ postgres_exporter]: https://my.oschina.net/innovation/blog/829707
[Prometheus _]: https://www.cnblogs.com/vovlie/p/Prometheus_CONCEPTS.html
[Prometheus _ _]: https://www.cnblogs.com/vovlie/p/Prometheus_install.html
[Prometheus _ Nginx _]: https://www.cnblogs.com/vovlie/p/Nginx_monitoring.html
[Prometheus]: https://www.cnblogs.com/vovlie/p/7709312.html
[Prometheus 1]: http://www.mamicode.com/info-detail-2869523.html