Prometheus 与 Graphite

对比范围

Graphite 专注于成为一个被动式时间序列数据库，能够提供查询语言和图形功能。除此以外，任何其他关注点都需要通过添加外部组件来解决。

Prometheus 是一个完整的监控和变化趋势分析系统，它包括主动采集、存储、查询、图形化和基于时间序列数据的告警功能。它知道周遭的事物应该是什么样子的（哪些端点应该存在、用什么时间序列模式表示问题等），并积极地帮助你找到故障。

数据模型

Graphite 以带名字的时间序列存储数值样本，这与 Prometheus 类似。然而，Prometheus 的元数据模型更丰富：Graphite 的指标名称由分隔符连接的组件组成，这些组件隐式地编码维度。而 Prometheus 则通过称为标签的键值对明确地进行维度编码，这些标签被附加到指标名称上。这使得我们可以使用 Prometheus 查询语言轻松过滤、分组和通过这些标签匹配数据。

更进一步地，特别是当 Graphite 与 StatsD 结合使用时，它通常会存储所有被监控实例的聚合数据，而不是保留实例作为维度，这不利于我们深入到单个实例中进行故障分析。

例如，响应代码为500和POST到/tracks端点的 api-server HTTP 请求的数量数据通常在 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 的数据库，它期望每隔一定的间隔接收到样本。在 Whisper 中，每个时间序列存储在一个单独的文件中，新样本会在一定时间后会覆盖旧样本。

Prometheus 也会创建一个本地文件来存储每个时间序列，但允许在采集或规则评估发生时以任意时间间隔存储样本。由于新样本的添加是追加而不是覆盖的，所以旧数据可能被保存非常长的时间。另外，Prometheus 对于许多短暂变化频繁的时间序列集也很适用。

总结

Prometheus 提供了更丰富的数据模型和查询语言，同时更容易运行和与其他环境集成。如果你想要一个长期保存历史数据的集群化解决方案，Graphite 可能是更好的选择。

Prometheus 与 InfluxDB

InfluxDB 是一个开源的时间序列数据库，有商业选项用于伸缩和集群化。InfluxDB 项目在 Prometheus 开发开始后的接近一年后发布，因此我们当时无法将其作为替代方案进行考量。尽管如此，Prometheus 和 InfluxDB 之间存在显著差异，它们针对的使用场景略有不同。

对比范围

为了进行公平的比较，我们也必须考虑 InfluxDB 的配套工具 Kapacitor，因为它与 Prometheus 和 Alertmanager 一起解决了相同类型的问题。

InfluxDB 的对比范围差异与 Graphite 中的情况相同。此外，InfluxDB 提供连续查询，这与 Prometheus 的记录规则（recording rules）相当。

Kapacitor 的对比范围是 Prometheus 记录规则、告警规则和 Alertmanager 通知功能的组合。Prometheus 提供了更强大的图形和告警查询语言。更进一步地，Prometheus 的 Alertmanager 还提供了分组、去重和静默功能。

数据模型/存储

与 Prometheus 类似，InfluxDB 的数据模型包含以标签形式表示的键值对。此外，InfluxDB 具有称为字段的第二级标签，其用途更为有限。InfluxDB 支持纳秒级别的时间戳以及 float64、int64、bool 和字符串数据类型。相比之下，Prometheus 支持 float64 数据类型，对字符串的支持有限，同时只支持毫秒级的时间戳。

InfluxDB 使用带有写前日志的日志结构合并树（LSM）存储引擎进行存储，按时间分片。对于事件日志而言，这比 Prometheus 每个时间序列一个文件的追加方式更适合。

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

架构

Prometheus 服务器独立运行，仅依赖于其本地存储执行核心功能：采集、规则处理和告警。开源版本的 InfluxDB 与此相似。

商业版 InfluxDB 是分布式存储集群的设计，存储和查询由多个节点同时处理。这意味着商业版 InfluxDB 更容易实现水平扩展，但也意味着你需要从一开始就需要关心分布式存储系统的复杂性。Prometheus 运行起来更容易，但在某些时候，你可能会需要显式针对产品、服务、数据中心等部分进行分片（sharding）。然而，独立运行的服务器（可以在并行冗余运行）也许能为你提供更好的可靠性和故障隔离性。

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

Prometheus 和 Alertmanager 通过运行冗余副本的 Prometheus 和使用 Alertmanager 的高可用模式提供完全开源的冗余方案。

总结

两个系统之间有很多相似之处。两者都有标签（称为 InfluxDB 的标签）来高效地支持多维度指标。两者都使用基本相同的压缩算法。两者都具有广泛的集成，包括相互集成彼此。两者都允许你通过统计工具分析数据或执行自动化操作的扩展钩子（hooks）。

InfluxDB 具有优势的地方：

• 事件日志。
• 商业选项提供集群功能，这也更适合长期数据存储。
• 副本之间的数据视图最终是一致的。

Prometheus 具有优势的地方：

• 如果你主要做指标相关的工作。
• 更强大的查询语言、告警和通知功能。
• 更好的用于绘图和告警的可用性和正常运行时间。

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

Prometheus 与 OpenTSDB

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

对比范围

此处的范围差异与 Graphite 中的情况相同。

数据模型

OpenTSDB 的数据模型几乎与 Prometheus 相同：时间序列由一组任意的键值对标识（OpenTSDB 中的tags对应 Prometheus 的label）。所有指标的数据都会一起存储，这限制了指标的基数。不过除此之外，还有一些细微的差异：例如，Prometheus 允许在标签值中使用任意字符，然而在 OpenTSDB 中，限制则更为严格。此外，OpenTSDB 缺少完整的查询语言，仅通过其 API 支持简单的聚合和数学运算。

存储

OpenTSDB 的存储基于 Hadoop 和 HBase 实现。这意味着 OpenTSDB 的水平扩展非常容易，但你需要从一开始就接受运行 Hadoop/HBase 集群的整体复杂性。

Prometheus 的初始维护会比较简单，但是当超出单个节点的容量时，就需要用户显式地进行分片操作。

总结

Prometheus 提供了更为丰富的查询语言，能够处理基数更高的指标。该查询语言参与组成了以整个完整的监控系统。如果你已经在运行 Hadoop 并且更看重长期存储的价值，那么 OpenTSDB 是一个不错的选择。

Prometheus 与 Nagios 对比

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

对比范围

Nagios 主要基于脚本的退出代码进行告警。这一行为被称为“checks”。在 Nagios 中，虽然存在对单个告警的静默，但是没有分组、路由或去重功能。

Nagios 有许多插件。例如，使用 NRPE 来在远程主机上运行 checks。

数据模型

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

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

存储

目前，Nagios 没有自身的存储。但有一些 Nagios 插件可以存储数据，例如用于可视化目的的 pnp4nagios。

架构

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

总结

Nagios 适用于对使用黑盒检测就足够的小型和/或静态系统进行基本监控。

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

Prometheus 与 Sensu

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

对比范围

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

数据模型

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

存储

Sensu 将当前和最近的事件状态信息以及实时库存数据存储在 etcd 或外部关系型数据库管理系统（PostgreSQL）中。

架构

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

总结

Sensu 和 Prometheus 在一些功能上具有相似性，但它们在监控方面的策略大相径庭。两者都提供了适应动态云环境和短暂计算平台的可扩展发现机制，尽管实现机制截然不同。两者都支持通过标签和注释收集多维指标。两者都有广泛的功能集成，并且 Sensu 内建了从所有 Prometheus Exporter 收集指标的功能支持。两者都能将可观测数据转发至第三方数据平台（例如事件存储或时间序列数据库）。Sensu 和 Prometheus 最大的差异在于其应用场景。

在以下情况下，Sensu 更出色：

• 当你需要收集并处理混合可观测数据（包括指标和/或事件）时
• 当你需要整合多个监控工具并需要支持指标与 Nagios 风格的插件或检查脚本时
• 提供更强大的事件处理平台

在以下情况下，Prometheus 更出色：

• 当你主要收集和计算指标时
• 当你监控统一的 Kubernetes 基础设施（如果你监控的所有工作负载都在 K8s 中运行，Prometheus 能够提供更好的 K8s 集成）
• 提供更强大的查询语言，内置历史数据分析的支持

Sensu 由一家商业公司维护，采用开源核心业务的模式，提供额外的付费功能，如闭源事件相关性和聚合、联邦化以及支持。Prometheus 是一个完全开源且独立的项目，由多家公司和个人共同维护，其中一些个体也提供商业服务和支持。

该文档基于 Prometheus 官方文档翻译而成。