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 可能是更好的选择。
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 使用 日志结构合并树的变体进行存储，并带有预写日志，按时间分片。这比 Prometheus 每个时间序列的仅追加文件方法更适合事件日志记录。
日志、指标和图表，天哪！ 描述了事件日志记录和指标记录之间的差异。
Prometheus 服务器彼此独立运行，并且仅依赖其本地存储来实现其核心功能：抓取、规则处理和警报。开源版本的 InfluxDB 类似。
商业 InfluxDB 产品在设计上是一个分布式存储集群，存储和查询由多个节点同时处理。
这意味着商业 InfluxDB 将更容易水平扩展，但也意味着您必须从一开始就管理分布式存储系统的复杂性。Prometheus 将更易于运行，但在某些时候，您将需要沿着可扩展性边界（如产品、服务、数据中心或类似方面）显式分片服务器。独立的服务器（可以并行冗余运行）也可能为您提供更好的可靠性和故障隔离。
Kapacitor 的开源版本没有用于规则、警报或通知的内置分布式/冗余选项。Kapacitor 的开源版本可以通过用户手动分片来扩展，类似于 Prometheus 本身。Influx 提供 Enterprise Kapacitor，它支持 HA/冗余警报系统。
相比之下，Prometheus 和 Alertmanager 通过运行 Prometheus 的冗余副本并使用 Alertmanager 的 高可用性 模式，提供了完全开源的冗余选项。
系统之间有很多相似之处。两者都具有标签（在 InfluxDB 中称为 tags）以有效地支持多维指标。两者都基本上使用相同的数据压缩算法。两者都具有广泛的集成，包括彼此之间的集成。两者都具有允许您进一步扩展它们的 hooks，例如在统计工具中分析数据或执行自动化操作。
InfluxDB 更好的地方
Prometheus 更好的地方
InfluxDB 由一家商业公司维护，遵循开源核心模式，提供高级功能，如闭源集群、托管和支持。Prometheus 是一个 完全开源和独立的项目，由多家公司和个人维护，其中一些公司和个人也提供商业服务和支持。
OpenTSDB 是一个基于 Hadoop 和 HBase 的分布式时间序列数据库。
与 Graphite 情况相同的范围差异也适用于此处。
OpenTSDB 的数据模型几乎与 Prometheus 的相同：时间序列由一组任意的键值对（OpenTSDB 标签是 Prometheus 标签）标识。指标的所有数据都 存储在一起，限制了指标的基数。但也有细微的差异：Prometheus 允许在标签值中使用任意字符，而 OpenTSDB 则更严格。OpenTSDB 也缺少完整的查询语言，仅允许通过其 API 进行简单的聚合和数学运算。
OpenTSDB 的存储在 Hadoop 和 HBase 之上实现。这意味着可以轻松地水平扩展 OpenTSDB，但您必须从一开始就接受运行 Hadoop/HBase 集群的总体复杂性。
Prometheus 最初将更易于运行，但一旦单个节点的容量超出，就需要显式分片。
Prometheus 提供了更丰富的查询语言，可以处理更高基数的指标，并且构成完整监控系统的一部分。如果您已经运行 Hadoop 并且重视长期存储胜过这些优势，那么 OpenTSDB 是一个不错的选择。
Nagios 是一个监控系统，起源于 1990 年代的 NetSaint。
Nagios 主要关注基于脚本退出代码的警报。这些被称为“检查”。有单个警报的静默，但没有分组、路由或去重。
有各种插件。例如，将允许 perfData 插件返回的几千字节数据管道传输 到时间序列数据库（如 Graphite），或使用 NRPE 在远程机器上运行检查。
Nagios 是基于主机的。每个主机可以有一个或多个服务，每个服务可以执行一个检查。
没有标签或查询语言的概念。
Nagios 本身没有存储，超出当前检查状态。有一些插件可以存储数据，例如 用于可视化。
Nagios 服务器是独立的。所有检查的配置都通过文件进行。
Nagios 适用于对小型和/或静态系统进行基本监控，其中黑盒探测就足够了。
如果您想进行白盒监控，或者拥有动态或基于云的环境，那么 Prometheus 是一个不错的选择。
Sensu 是一个开源监控和可观测性管道，其商业发行版提供了额外的可扩展性功能。它可以重用现有的 Nagios 插件。
Sensu 是一个可观测性管道，专注于处理和警报可观测性数据流，作为 事件 流。它为事件 过滤、聚合、转换 和 处理 – 提供了一个可扩展的框架，包括将警报发送到其他系统以及将事件存储在第三方系统中。Sensu 的事件处理能力在范围上类似于 Prometheus 警报规则和 Alertmanager。
Sensu 事件 以结构化数据格式表示服务运行状况和/或 指标，由 实体 名称（例如服务器、云计算实例、容器或服务）、事件名称和可选的 键值元数据（称为“标签”或“注释”）标识。Sensu 事件负载可以包括一个或多个指标 points，表示为包含 name、tags（键/值对）、timestamp 和 value（始终为浮点数）的 JSON 对象。
Sensu 将当前和最近的事件状态信息和实时库存数据存储在嵌入式数据库 (etcd) 或外部 RDBMS (PostgreSQL) 中。
Sensu 部署的所有组件都可以集群化，以实现高可用性和更高的事件处理吞吐量。
Sensu 和 Prometheus 有一些共同的功能，但它们采用非常不同的监控方法。两者都为动态的基于云的环境和短暂的计算平台提供了可扩展的发现机制，尽管底层机制截然不同。两者都支持通过标签和注释收集多维指标。两者都具有广泛的集成，Sensu 本身支持从所有 Prometheus 导出器收集指标。两者都能够将可观测性数据转发到第三方数据平台（例如，事件存储或 TSDB）。Sensu 和 Prometheus 最大的区别在于它们的用例。
Sensu 更好的地方
Prometheus 更好的地方
Sensu 由一家商业公司维护，遵循开源核心商业模式，提供高级功能，如闭源事件关联和聚合、联邦和支持。Prometheus 是一个完全开源和独立的项目，由多家公司和个人维护，其中一些公司和个人也提供商业服务和支持。
此文档是 开源的。请通过提交问题或拉取请求来帮助改进它。