与其他替代方案的比较

Prometheus 与 Graphite

范围

Graphite 专注于成为一个被动的时间序列数据库，并提供查询语言和图形功能。任何其他问题都由外部组件解决。

Prometheus 是一个完整的监控和趋势分析系统，包括内置的主动抓取、存储、查询、图形化和基于时间序列数据的警报。它了解世界应该是什么样子（哪些端点应该存在，哪些时间序列模式意味着问题等），并主动尝试发现故障。

数据模型

Graphite 为命名的时间序列存储数值样本，与 Prometheus 非常相似。然而，Prometheus 的元数据模型更丰富：Graphite 的指标名称由点分隔的组件组成，这些组件隐式地编码了维度，而 Prometheus 则将维度显式地编码为附加到指标名称上的键值对，称为标签。这使得通过查询语言可以轻松地按这些标签进行过滤、分组和匹配。

此外，特别是当 Graphite 与 StatsD  结合使用时，通常只存储所有被监控实例的聚合数据，而不是将实例保留为一个维度，从而无法深入到单个有问题的实例中。

例如，在 Graphite/StatsD 中，存储响应码为 500、方法为 POST 且请求端点为 /tracks 的 API 服务器的 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  格式存储时间序列数据，这是一种 RRD 风格的数据库，期望样本以固定的时间间隔到达。每个时间序列都存储在一个单独的文件中，经过一定时间后，新的样本会覆盖旧的样本。

Prometheus 同样为每个时间序列创建一个本地文件，但允许在抓取或规则评估发生时以任意间隔存储样本。由于新的样本只是简单地追加，旧数据可以任意长时间地保留。Prometheus 也非常适用于许多生命周期短、频繁变化的时间序列集合。

总结

Prometheus 提供了更丰富的数据模型和查询语言，此外还更容易运行并集成到您的环境中。如果您想要一个能够长期保存历史数据的集群解决方案，Graphite 可能是更好的选择。

Prometheus 与 InfluxDB

InfluxDB  是一个开源的时间序列数据库，提供商业选项用于扩展和集群。InfluxDB 项目在 Prometheus 开发开始近一年后发布，因此我们当时无法将其作为替代方案考虑。尽管如此，Prometheus 和 InfluxDB 之间存在显著差异，并且两个系统都针对略有不同的用例。

范围

为了进行公平比较，我们还必须将 Kapacitor  与 InfluxDB 一起考虑，因为它们结合起来解决了与 Prometheus 和 Alertmanager 相同的问题领域。

与 Graphite 的情况一样，这里对于 InfluxDB 本身也存在相同的范围差异。此外，InfluxDB 提供了连续查询，这等同于 Prometheus 的记录规则。

Kapacitor 的范围是 Prometheus 记录规则、警报规则和 Alertmanager 通知功能的组合。Prometheus 提供了一个更强大的查询语言，用于图形化和警报 。Prometheus Alertmanager 还提供了分组、去重和静默功能。

数据模型 / 存储

与 Prometheus 类似，InfluxDB 的数据模型也使用键值对作为标签，称为 tags。此外，InfluxDB 还有第二级标签，称为 fields，其使用上限制更多。InfluxDB 支持高达纳秒级分辨率的时间戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 支持 float64 数据类型，对字符串的支持有限，以及毫秒级分辨率的时间戳。

InfluxDB 使用一种变体的日志结构合并树（log-structured merge tree）进行存储，并带有预写日志（write ahead log） ，按时间分片。这比 Prometheus 每个时间序列一个仅追加文件的方案更适合事件日志记录。

《Logs and Metrics and Graphs, Oh My!》  一文描述了事件日志记录和指标记录之间的区别。

架构

Prometheus 服务器彼此独立运行，其核心功能（抓取、规则处理和警报）仅依赖于本地存储。InfluxDB 的开源版本与此类似。

商业版的 InfluxDB 在设计上是一个分布式存储集群，存储和查询由多个节点同时处理。

这意味着商业版的 InfluxDB 更容易水平扩展，但同时也意味着您从一开始就必须管理分布式存储系统的复杂性。Prometheus 的运行会更简单，但在某个时刻，您将需要根据可伸缩性边界（如产品、服务、数据中心或类似方面）明确地对服务器进行分片。独立的服务器（可以并行冗余运行）也可能为您提供更好的可靠性和故障隔离。

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

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

总结

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

InfluxDB 的优势

• 如果您正在进行事件日志记录。
• 商业选项为 InfluxDB 提供集群功能，这对于长期数据存储也更好。
• 副本之间的数据最终一致性视图。

Prometheus 的优势

• 如果您主要处理指标。
• 更强大的查询语言、警报和通知功能。
• 图形化和警报的更高可用性和正常运行时间。

InfluxDB 由一家遵循开放核心模式的商业公司维护，提供闭源集群、托管和支持等高级功能。Prometheus 是一个完全开源且独立的项目，由多家公司和个人共同维护，其中一些也提供商业服务和支持。

Prometheus 与 OpenTSDB

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

范围

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

数据模型

OpenTSDB 的数据模型几乎与 Prometheus 的相同：时间序列由一组任意的键值对标识（OpenTSDB 的 tags 就是 Prometheus 的 labels）。一个指标的所有数据都存储在一起 ，这限制了指标的基数。不过也存在一些细微差异：Prometheus 允许在标签值中使用任意字符，而 OpenTSDB 则更具限制性。OpenTSDB 也缺乏完整的查询语言，只允许通过其 API 进行简单的聚合和数学运算。

存储

OpenTSDB 的存储是建立在Hadoop 和HBase 之上的。这意味着水平扩展 OpenTSDB 很方便，但您从一开始就必须接受运行 Hadoop/HBase 集群的整体复杂性。

Prometheus 最初运行起来会更简单，但一旦单个节点的容量超过限制，就需要进行显式分片。

总结

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

Prometheus 与 Nagios

Nagios  是一个起源于 1990 年代的监控系统，前身为 NetSaint。

范围

Nagios 主要基于脚本的退出码进行警报。这些被称为“检查”（checks）。它支持对单个警报进行静默，但没有分组、路由或去重功能。

它有多种插件。例如，将插件允许返回的几千字节 perfData 传输到像 Graphite 这样的时间序列数据库 ，或者使用 NRPE 在远程机器上运行检查 。

数据模型

Nagios 是基于主机的。每个主机可以有一个或多个服务，每个服务可以执行一次检查。

没有标签或查询语言的概念。

存储

Nagios 除了当前的检查状态外，本身没有存储。有一些插件可以存储数据，例如用于可视化的插件 。

架构

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

总结

Nagios 适用于对小型和/或静态系统的基本监控，在这些系统中，黑盒探测已经足够。

如果您想进行白盒监控，或者拥有动态或基于云的环境，那么 Prometheus 是一个很好的选择。

Prometheus 与 Sensu

Sensu  是一个开源的监控和可观测性管道，其商业发行版提供了额外的可伸缩性功能。它可以重用现有的 Nagios 插件。

范围

Sensu 是一个可观测性管道，专注于将可观测性数据作为事件 流进行处理和警报。它为事件的过滤 、聚合、转换 和处理 提供了一个可扩展的框架——包括向其他系统发送警报和将事件存储在第三方系统中。Sensu 的事件处理能力在范围上与 Prometheus 的警报规则和 Alertmanager 类似。

数据模型

Sensu 事件 以结构化数据格式表示服务健康状况和/或指标 ，通过实体 名称（例如服务器、云计算实例、容器或服务）、事件名称以及可选的键值元数据 （称为“标签”或“注释”）来识别。Sensu 事件负载可能包括一个或多个指标points，表示为一个 JSON 对象，其中包含 name（名称）、tags（标签，键/值对）、timestamp（时间戳）和 value（值，始终为浮点数）。

存储

Sensu 将当前和最近的事件状态信息以及实时清单数据存储在嵌入式数据库 (etcd) 或外部 RDBMS (PostgreSQL) 中。

架构

Sensu 部署的所有组件都可以集群化，以实现高可用性并提高事件处理吞吐量。

总结

Sensu 和 Prometheus 有一些共同的功能，但它们采用的监控方法却截然不同。两者都为动态的云环境和临时计算平台提供了可扩展的发现机制，尽管其底层机制大相径庭。两者都支持通过标签和注释收集多维指标。两者都有广泛的集成，Sensu 原生支持从所有 Prometheus 导出器收集指标。两者都能够将可观测性数据转发到第三方数据平台（例如事件存储或时序数据库）。Sensu 和 Prometheus 最大的不同在于它们的用例。

Sensu 的优势

• 如果您正在收集和处理混合可观测性数据（包括指标和/或事件）
• 如果您正在整合多种监控工具，并且需要同时支持指标和 Nagios 风格的插件或检查脚本
• 更强大的事件处理平台

Prometheus 的优势

• 如果您主要收集和评估指标
• 如果您正在监控同构的 Kubernetes 基础设施（如果您监控的工作负载 100% 都在 K8s 中，Prometheus 提供了更好的 K8s 集成）
• 更强大的查询语言，以及对历史数据分析的内置支持

Sensu 由一家商业公司维护，遵循开放核心的商业模式，提供闭源的事件关联和聚合、联邦以及支持等高级功能。Prometheus 是一个完全开源且独立的项目，由多家公司和个人共同维护，其中一些也提供商业服务和支持。