Graphite 主要作为一个被动的时间序列数据库，提供查询语言和绘图功能。任何其他方面的需求都由外部组件解决。
Prometheus 是一个完整的监控和趋势系统，包含基于时间序列数据的内置、主动抓取、存储、查询、绘图和告警功能。它了解系统应该是什么样子（应该存在哪些端点，哪些时间序列模式意味着有问题等等），并主动尝试发现故障。
Graphite 存储具有名称的时间序列的数值样本，这与 Prometheus 很相似。然而，Prometheus 的元数据模型更丰富：Graphite 指标名称由点分隔的组件组成，隐式编码维度，而 Prometheus 则将维度显式编码为附加到指标名称的键值对，称为标签（labels）。这使得通过查询语言可以轻松地根据这些标签进行过滤、分组和匹配。
此外，尤其当 Graphite 与 StatsD 结合使用时，通常只存储所有被监控实例的聚合数据，而不是保留实例作为一个维度，以便深入分析单个有问题的实例。
例如，存储响应码为 500、方法为 POST、指向 /tracks 端点的 API 服务器的 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 可能是一个更好的选择。
InfluxDB 是一个开源的时间序列数据库，提供用于扩展和集群的商业选项。InfluxDB 项目在 Prometheus 开发开始后近一年才发布，所以当时我们无法将其视为替代方案。尽管如此，Prometheus 和 InfluxDB 之间仍存在显著差异，并且两个系统都针对略微不同的用例。
为了进行公平比较，我们必须同时考虑 Kapacitor 和 InfluxDB，因为它们组合在一起可以解决与 Prometheus 和 Alertmanager 相同的问题领域。
与 Graphite 的情况一样，这里也存在同样的范围差异。此外，InfluxDB 提供了持续查询，这与 Prometheus 的记录规则等效。
Kapacitor 的范围结合了 Prometheus 的记录规则、告警规则和 Alertmanager 的通知功能。Prometheus 提供了更强大的查询语言用于绘图和告警。Prometheus Alertmanager 此外还提供了分组、去重和静默功能。
与 Prometheus 一样，InfluxDB 数据模型也有键值对作为标签（在 InfluxDB 中称为 tags）。此外，InfluxDB 还有第二级的标签，称为字段（fields），其使用范围更受限。InfluxDB 支持高达纳秒分辨率的时间戳以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 支持 float64 数据类型（有限支持 string）和毫秒分辨率的时间戳。
InfluxDB 使用一种 日志结构合并树的变体进行存储，带有预写日志，按时间分片。这比 Prometheus 的每个时间序列一个追加文件的方案更适合事件日志记录。
Logs and Metrics and Graphs, Oh My! 描述了事件日志记录和指标记录之间的差异。
Prometheus 服务器彼此独立运行，并且其核心功能（抓取、规则处理和告警）仅依赖于其本地存储。开源版本的 InfluxDB 也类似。
商业版本的 InfluxDB 在设计上是一个分布式存储集群，由许多节点同时处理存储和查询。
这意味着商业版本的 InfluxDB 更容易水平扩展，但这也意味着你必须从一开始就管理分布式存储系统的复杂性。Prometheus 运行起来会更简单，但在某个时候，你需要根据产品、服务、数据中心或类似方面的可伸缩性边界明确地对服务器进行分片。独立的服务器（可以并行冗余运行）也可能为你提供更好的可靠性和故障隔离。
Kapacitor 的开源版本没有内置的分布式/冗余选项用于规则、告警或通知。Kapacitor 的开源版本可以通过用户手动分片来扩展，类似于 Prometheus 本身。Influx 提供 Enterprise Kapacitor，支持高可用/冗余的告警系统。
相比之下，Prometheus 和 Alertmanager 通过运行 Prometheus 的冗余副本并使用 Alertmanager 的 高可用模式，提供了一个完全开源的冗余选项。
这两个系统有很多相似之处。两者都有标签（InfluxDB 中称为 tags）来有效地支持多维度指标。两者基本使用相同的数据压缩算法。两者都有广泛的集成，包括彼此之间的集成。两者都提供了钩子，允许你进一步扩展它们，例如在统计工具中分析数据或执行自动化操作。
InfluxDB 更优之处
Prometheus 更优之处
InfluxDB 由一家遵循开放核心模式的商业公司维护，提供闭源集群、托管和支持等高级功能。Prometheus 是一个完全开源和独立的项目，由多家公司和个人维护，其中一些也提供商业服务和支持。
OpenTSDB 是一个基于 Hadoop 和 HBase 的分布式时间序列数据库。
这里也存在与 Graphite 情况相同的范围差异。
OpenTSDB 的数据模型几乎与 Prometheus 的相同：时间序列由一组任意键值对标识（OpenTSDB 的标签是 Prometheus 的 labels）。指标的所有数据存储在一起，限制了指标的基数（cardinality）。但仍有一些微小差异：Prometheus 允许标签值中使用任意字符，而 OpenTSDB 则更严格。OpenTSDB 也缺乏完整的查询语言，只允许通过其 API 进行简单的聚合和计算。
OpenTSDB 的存储基于 Hadoop 和 HBase 实现。这意味着很容易水平扩展 OpenTSDB，但你必须从一开始就接受运行 Hadoop/HBase 集群的整体复杂性。
Prometheus 初始运行起来会更简单，但一旦单个节点的容量超出限制，则需要明确进行分片。
Prometheus 提供了更丰富的查询语言，可以处理更高基数的指标，并且是完整监控系统的一部分。如果你已经运行 Hadoop，并且重视长期存储而不是这些优势，那么 OpenTSDB 是一个不错的选择。
Nagios 是一个监控系统，起源于 20 世纪 90 年代的 NetSaint。
Nagios 主要关注基于脚本退出代码的告警。这些称为“检查”（checks）。可以静默单个告警，但没有分组、路由或去重功能。
有各种插件。例如，可以将插件允许返回的几 KB perfData 管道传输到 Graphite 等时间序列数据库，或使用 NRPE 在远程机器上运行检查。
Nagios 是基于主机的。每台主机可以有一个或多个服务，每个服务可以执行一个检查。
没有标签或查询语言的概念。
除了当前的检查状态外，Nagios 本身没有存储功能。有一些插件可以存储数据，例如用于可视化。
Nagios 服务器是独立的。所有检查配置都通过文件进行。
Nagios 适用于对小型和/或静态系统进行基本监控，其中黑盒探测就已足够。
如果你想进行白盒监控，或者拥有动态或基于云的环境，那么 Prometheus 是一个不错的选择。
Sensu 是一个开源的监控和可观测性管道，提供商业发行版，为可扩展性提供额外功能。它可以重用现有的 Nagios 插件。
Sensu 是一个可观测性管道，专注于将可观测性数据作为事件流进行处理和告警。它提供了一个可扩展的框架，用于事件过滤、聚合、转换和处理，包括向其他系统发送告警以及将事件存储在第三方系统中。Sensu 的事件处理能力在范围上类似于 Prometheus 的告警规则和 Alertmanager。
Sensu 事件 以结构化数据格式表示服务健康和/或指标，由实体名称（例如服务器、云计算实例、容器或服务）、事件名称以及可选的键值元数据（称为“labels”或“annotations”）标识。Sensu 事件载荷可以包含一个或多个指标点，表示为 JSON 对象，包含 name、tags（键/值对）、timestamp 和 value（始终为浮点数）。
Sensu 将当前和最近的事件状态信息以及实时库存数据存储在嵌入式数据库 (etcd) 或外部 RDBMS (PostgreSQL) 中。
Sensu 部署的所有组件都可以集群化以实现高可用性和提高事件处理吞吐量。
Sensu 和 Prometheus 具有一些共同的能力，但在监控方法上截然不同。两者都为动态的云环境和临时计算平台提供了可扩展的发现机制，尽管底层机制有很大差异。两者都支持通过标签和注解收集多维度指标。两者都有广泛的集成，并且 Sensu 原生支持从所有 Prometheus 导出器收集指标。两者都能将可观测性数据转发到第三方数据平台（例如事件存储或 TSDB）。Sensu 和 Prometheus 最大的区别在于它们的用例。
Sensu 更优之处
Prometheus 更优之处
Sensu 由一家遵循开放核心商业模式的商业公司维护，提供闭源事件关联和聚合、联邦和支持等高级功能。Prometheus 是一个完全开源和独立的项目，由多家公司和个人维护，其中一些也提供商业服务和支持。
本文档为开源。请通过提交问题或拉取请求来帮助改进它。