与其他方案的比较

Prometheus vs. Graphite

范围

Graphite  专注于作为具有查询语言和绘图功能的被动式时间序列数据库。其他问题则由外部组件解决。

Prometheus 是一个完整的监控和趋势系统，它包括内置的主动抓取、存储、查询、绘图和基于时间序列数据的告警功能。它了解世界的应有状态（哪些端点应该存在，什么时间序列模式意味着麻烦等等），并积极地寻找故障。

数据模型

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

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

例如，存储 API 服务器的 HTTP 请求次数，响应代码为 500，方法为 POST，端点为 /tracks，在 Graphite/StatsD 中通常会这样编码：

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 vs. 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 的每个时间序列的追加式文件方法更适合事件日志记录。

日志、指标和图表，哦天哪！  描述了事件日志记录和指标记录之间的区别。

架构

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

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

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

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

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

总结

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

InfluxDB 表现更好的方面

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

Prometheus 表现更好的方面

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

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

Prometheus vs. 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 vs. Nagios

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

范围

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

有各种各样的插件。例如，可以将插件返回的少量（几KB）性能数据（perfData）通过管道传输到 如 Graphite 这样的时间序列数据库 ，或者使用 NRPE 来 在远程计算机上运行检查 。

数据模型

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

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

存储

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

架构

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

总结

Nagios 适用于对小型和/或静态系统的基本监控，其中黑盒探测就足够了。

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

Prometheus vs. Sensu

Sensu  是一个开源的监控和可观测性管道，提供商业版本，其中包含增强的可扩展性功能。它可以重用现有的 Nagios 插件。

范围

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

数据模型

Sensu 的 事件  代表服务健康和/或 指标 ，以结构化数据格式表示，该格式由 实体  名称（例如服务器、云计算实例、容器或服务）、事件名称以及可选的 键值元数据 （称为“标签”或“注解”）进行标识。Sensu 事件载荷可能包含一个或多个指标 点，表示为包含 名称、标签（键/值对）、时间戳 和 值（始终为浮点数）的 JSON 对象。

存储

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

架构

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

总结

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

Sensu 更适合

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

Prometheus 表现更好的方面

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

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