与替代方案的比较

Prometheus 与 Graphite

范围

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

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

数据模型

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

此外，特别是当 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 相同的问题空间。

在 InfluxDB 本身上，适用与 Graphite 同样的范畴差异。此外，InfluxDB 还提供连续查询（Continuous Queries），这等同于 Prometheus 的记录规则。

Kapacitor 的范畴是 Prometheus 记录规则、告警规则和 Alertmanager 通知功能的结合。Prometheus 提供了 用于绘图和告警的更强大的查询语言 。Prometheus 的 Alertmanager 另外提供了分组、去重和静默功能。

数据模型 / 存储

像 Prometheus 一样，InfluxDB 的数据模型具有作为标签的键值对，被称为标签（tags）。此外，InfluxDB 还有第二层标签称为字段（fields），其使用范围更受限。InfluxDB 支持高达纳秒级分辨率的时间戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 支持 float64 数据类型，对字符串的支持有限，并提供毫秒级时间戳。

InfluxDB 使用一种 带有预写日志（WAL）的日志结构合并树（LSM tree）的变体进行存储 ，按时间分片。这比 Prometheus 每个时间序列一个追加写入文件的做法更适合事件日志记录。

日志、指标与图表，天哪！  一文描述了事件日志与指标记录之间的差异。

架构

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

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

这意味着商业版 InfluxDB 更容易实现水平扩展，但也意味着您必须从一开始就管理一个分布式存储系统的复杂性。Prometheus 运行起来更简单，但当达到一定程度时，您需要按照产品、服务、数据中心或类似界限显式地进行服务器分片。独立的服务器（可以并行冗余运行）也可能为您提供更好的可靠性和故障隔离。

Kapacitor 的开源版本没有内置用于规则、告警或通知的分布式/冗余选项。开源版 Kapacitor 可以像 Prometheus 本身一样通过手动分片进行扩展。Influx 提供 企业版 Kapacitor ，它支持 HA/冗余告警系统。

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

总结

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

InfluxDB 的优势

• 如果您主要进行事件日志记录。
• 商业版为 InfluxDB 提供了集群功能，这也更适合长期数据存储。
• 副本之间数据的最终一致性视图。

Prometheus 的优势

• 如果您主要进行指标监控。
• 更强大的查询语言、告警和通知功能。
• 对于绘图和告警具有更高的可用性和正常运行时间。

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

Prometheus 与 OpenTSDB

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

范畴

适用与 Graphite 同样的范畴差异。

数据模型

OpenTSDB 的数据模型几乎与 Prometheus 相同：时间序列由一组任意的键值对标识（OpenTSDB 标签即 Prometheus 标签）。所有指标数据都被 存储在一起 ，这限制了指标的基数（cardinality）。但也存在微小差异：Prometheus 允许标签值中使用任意字符，而 OpenTSDB 限制较多。OpenTSDB 也缺乏完整的查询语言，仅允许通过其 API 进行简单的聚合和数学运算。

存储

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

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

总结

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

Prometheus 与 Nagios

Nagios  是一个起源于 20 世纪 90 年代作为 NetSaint 的监控系统。

范畴

Nagios 主要关注基于脚本退出代码的告警。这些被称为“检查”（checks）。虽然可以静默单个告警，但没有分组、路由或去重功能。

Nagios 有各种插件。例如，将插件返回的几千字节的 perfData 管道传输至 Graphite 等时序数据库 ，或者使用 NRPE 在 远程机器上运行检查 。

数据模型

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

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

存储

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

架构

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

总结

Nagios 适用于小型和/或静态系统的基础监控，其中黑盒探测（blackbox probing）已经足够。

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

Prometheus 与 Sensu

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

范畴

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

数据模型

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

存储

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

架构

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

总结

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

Sensu 的优势所在

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

Prometheus 的优势

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

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