与替代方案的比较

Prometheus 与 Graphite

范围

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

Prometheus 是一个完整的监控和趋势系统，包含基于时间序列数据的主动抓取、存储、查询、绘图和告警功能。它了解系统的预期状态（例如，哪些端点应该存在，哪些时间序列模式意味着问题等），并主动尝试发现故障。

数据模型

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

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

例如，在 Graphite/StatsD 中，将 API 服务器 HTTP 请求的数量（响应码为 500，方法为 POST，到 /tracks 端点）通常编码如下：

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 的数据模型也使用键值对作为标签（在 InfluxDB 中称为 tags）。此外，InfluxDB 还有第二层标签，称为字段，其使用更受限制。InfluxDB 支持高达纳秒分辨率的时间戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 支持 float64 数据类型（对字符串支持有限），以及毫秒分辨率的时间戳。

InfluxDB 使用一种基于时间分片的 日志结构合并树变体作为存储，并带有预写日志。这比 Prometheus 每个时间序列一个仅追加文件的方案更适合事件日志记录。

《日志、度量和图表，天啊！》 描述了事件日志记录和度量记录之间的差异。

架构

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 标签即 Prometheus 标签）进行标识。度量的所有数据都 存储在一起，限制了度量的基数。然而，也存在细微差异：Prometheus 允许标签值中包含任意字符，而 OpenTSDB 则更为严格。OpenTSDB 也缺少完整的查询语言，仅允许通过其 API 进行简单的聚合和数学运算。

存储

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

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

总结

Prometheus 提供更丰富的查询语言，可以处理更高基数的度量，并且是完整监控系统的一部分。如果您已经在运行 Hadoop 并且看重长期存储而非这些优势，OpenTSDB 是一个不错的选择。

Prometheus 与 Nagios

Nagios 是一个监控系统，起源于 1990 年代，最初名为 NetSaint。

范围

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

有各种插件可用。例如，可以将 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 基础设施（如果您监控的所有工作负载都在 K8s 中，Prometheus 提供了更好的 K8s 集成）
• 更强大的查询语言，并内置支持历史数据分析

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