Prometheus 与 Graphite
适用范围
Graphite 专注于作为一个被动的时间序列数据库，提供查询语言和图形功能。其他方面的需求由外部组件来解决。
Prometheus 是一个完整的监控和趋势分析系统，包括内置的主动抓取、存储、查询、图形展示和基于时间序列数据的告警功能。它了解系统应该是什么样子的（哪些端点应该存在、哪些时间序列模式意味着问题等），并主动尝试发现故障。
数据模型
Graphite 存储命名时间序列的数值样本，这与 Prometheus 类似。然而，Prometheus 的元数据模型更加丰富：Graphite 的指标名称由点分隔的组件组成，隐式地编码维度，而 Prometheus 将维度显式编码为键值对（称为标签），附加到指标名称上。这使得通过查询语言可以轻松地按这些标签进行过滤、分组和匹配。
此外，特别是当 Graphite 与 StatsD 结合使用时，通常只存储所有被监控实例的聚合数据，而不是将实例作为一个维度保留，从而无法深入到个别问题实例。
例如，存储 API 服务器中响应码为 500、方法为 POST、路径为 /tracks 端点的 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 风格的数据库，期望样本以固定间隔到达。每个时间序列存储在一个单独的文件中，超过一定时间后新样本会覆盖旧样本。
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 中称为 tag。此外，InfluxDB 还有第二级标签称为 field，其使用方式更受限制。InfluxDB 支持高达纳秒分辨率的时间戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 支持 float64 数据类型，对字符串的支持有限，时间戳精度为毫秒。
InfluxDB 使用日志结构合并树的变体进行存储，并带有预写日志，按时间分片。这比 Prometheus 的每个时间序列追加文件的方式更适合事件日志记录。
日志、指标和图表，天呐！这篇文章描述了事件日志记录和指标记录之间的区别。
架构
Prometheus 服务器彼此独立运行，仅依赖本地存储来实现其核心功能：抓取、规则处理和告警。InfluxDB 的开源版本与此类似。
InfluxDB 的商业版本在设计上是一个分布式存储集群，存储和查询由多个节点同时处理。
这意味着商业版 InfluxDB 更容易水平扩展，但这也意味着你从一开始就必须管理分布式存储系统的复杂性。Prometheus 运行起来更简单，但在某些时候你需要沿着可扩展性边界（如产品、服务、数据中心或类似方面）显式地对服务器进行分片。独立的服务器（可以冗余并行运行）也可能为你提供更好的可靠性和故障隔离。
Kapacitor 的开源版本没有针对规则、告警或通知的内置分布式/冗余选项。Kapacitor 的开源版本可以通过用户手动分片来扩展，类似于 Prometheus 本身。Influx 提供了 Enterprise Kapacitor，支持高可用/冗余告警系统。
相比之下，Prometheus 和 Alertmanager 通过运行冗余的 Prometheus 副本并使用 Alertmanager 的高可用模式，提供了完全开源的冗余选项。
总结
两个系统之间有许多相似之处。两者都有标签（在 InfluxDB 中称为 tag）来高效支持多维指标。两者基本上使用相同的数据压缩算法。两者都有广泛的集成，包括彼此之间的集成。两者都有钩子允许你进一步扩展，例如在统计工具中分析数据或执行自动化操作。
InfluxDB 更好的方面：
- 如果你在做事件日志记录。
- 商业选项为 InfluxDB 提供集群，这对于长期数据存储也更好。
- 副本之间的数据最终一致性视图。
Prometheus 更好的方面：
- 如果你主要做指标监控。
- 更强大的查询语言、告警和通知功能。
- 图形展示和告警的更高可用性和正常运行时间。
InfluxDB 由一家商业公司维护，遵循开放核心模式，提供闭源集群、托管和支持等高级功能。Prometheus 是一个完全开源和独立的项目，由多家公司和个人维护，其中一些也提供商业服务和支持。
Prometheus 与 OpenTSDB
OpenTSDB 是一个基于 Hadoop 和 HBase 的分布式时间序列数据库。
适用范围
与 Graphite 的情况相同的适用范围差异在此也适用。
数据模型
OpenTSDB 的数据模型与 Prometheus 几乎相同：时间序列由一组任意的键值对标识（OpenTSDB 的 tag 就是 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 事件以结构化数据格式表示服务健康状况和/或指标，通过实体名称（例如服务器、云计算实例、容器或服务）、事件名称和可选的键值元数据（称为 "labels" 或 "annotations"）来标识。Sensu 事件负载可以包含一个或多个指标points，表示为包含 name、tags（键/值对）、timestamp 和 value（始终为浮点数）的 JSON 对象。
存储
Sensu 将当前和近期的事件状态信息及实时清单数据存储在嵌入式数据库（etcd）或外部关系数据库（PostgreSQL）中。
架构
Sensu 部署的所有组件都可以进行集群化，以实现高可用性和提高事件处理吞吐量。
总结
Sensu 和 Prometheus 有一些共同的能力，但它们采用了非常不同的监控方法。两者都提供可扩展的发现机制，用于动态的云环境和临时计算平台，尽管底层机制相当不同。两者都支持通过标签和注解收集多维指标。两者都有广泛的集成，Sensu 原生支持从所有 Prometheus 导出器收集指标。两者都能够将可观测性数据转发到第三方数据平台（例如事件存储或时间序列数据库）。Sensu 和 Prometheus 最大的差异在于它们的使用场景。
Sensu 更好的方面：
- 如果你在收集和处理混合可观测性数据（包括指标和/或事件）
- 如果你在整合多个监控工具并需要支持指标和 Nagios 风格的插件或检查脚本
- 更强大的事件处理平台
Prometheus 更好的方面：
- 如果你主要收集和评估指标
- 如果你监控同质的 Kubernetes 基础设施（如果你监控的工作负载 100% 在 K8s 中，Prometheus 提供更好的 K8s 集成）
- 更强大的查询语言，以及对历史数据分析的内置支持
Sensu 由一家商业公司维护，遵循开放核心商业模式，提供闭源的事件关联和聚合、联邦以及支持等高级功能。Prometheus 是一个完全开源和独立的项目，由多家公司和个人维护，其中一些也提供商业服务和支持。