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 还有第二级标签，称为字段，其用途更为有限。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 中称为 tag）来有效地支持多维指标。两者都基本使用相同的数据压缩算法。两者都有广泛的集成，包括彼此之间的集成。两者都具有允许您进一步扩展它们的钩子，例如在统计工具中分析数据或执行自动化操作。
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 是一个监控系统，起源于 20 世纪 90 年代的 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 是一个完全开源且独立的项目，由多家公司和个人维护，其中一些人也提供商业服务和支持。
此文档是开源的。请通过提交问题或拉取请求来帮助改进它。