Graphite 专注于成为一个具有查询语言和图形功能的被动时间序列数据库。其他任何问题均由外部组件解决。
Prometheus 是一个完整的监控和趋势系统，包括基于时间序列数据的内置时间数据库和主动扫描、存储、查询、制图和警报。它了解世界应该是什么样子（哪些端点应该存在、哪些时间序列模式意味着问题等），并积极尝试查找故障。
Graphite 为已命名的时间序列存储数字样本，这一点与 Prometheus 非常相似。不过，Prometheus 的元数据模型更为丰富：Graphite 的指标名称由点分隔组件组成，隐含地编码了维度，而 Prometheus 则将维度明确编码为键值对，称为标签，附加到指标名称上。这样就可以通过查询语言轻松地根据这些标签进行过滤、分组和匹配。
此外，特别是当 Graphite 与 StatsD 结合使用时，通常只存储所有受监控实例的汇总数据，而不是将实例作为一个维度保留下来，并能深入到单个有问题的实例。
例如，在 Graphite/StatsD 中，存储向 API 服务器发出的响应代码为 500、方法为 POST 的 /tracks 端点 HTTP 请求的数量通常会这样编码：
stats.api-server.tracks.post.500 -> 93
在 Prometheus 中，同样的数据可以这样编码（假设有三个 api 服务器实例）：
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>"} -> 31Graphite 以 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 数据模型也将键值对作为标签，称为标记。此外，InfluxDB 还有第二层标签，称为字段，但使用范围比较有限。InfluxDB 支持纳秒分辨率的时间戳，以及 float64、int64、bool 和字符串数据类型。相比之下，Prometheus 支持 float64 数据类型，但对字符串和毫秒分辨率时间戳的支持有限。
InfluxDB 使用日志结构合并树的变种来存储超前写日志，并按时间分片。这比 Prometheus 的每个时间序列只附加文件的方法更适合事件日志。
Prometheus 服务器相互独立运行，仅依靠本地存储实现核心功能：抓取、规则处理和警报。InfluxDB 的开源版本与此类似。
商业 InfluxDB 产品在设计上是一个分布式存储集群，存储和查询由多个节点同时处理。
这意味着商业 InfluxDB 将更容易横向扩展，但也意味着您必须从一开始就管理分布式存储系统的复杂性。Prometheus 运行起来会更简单，但在某些时候，您需要明确地按照可扩展性边界（如产品、服务、数据中心或类似方面）对服务器进行分片。独立服务器（可以并行冗余运行）也可以为您提供更好的可靠性和故障隔离。
Kapacitor 的开源版本没有内置规则、警报或通知的分布式/冗余选项。Kapacitor 的开源版本可以通过用户手动分片来扩展，类似于 Prometheus 本身。Influx 提供的企业 Kapacitor 支持 HA/冗余警报系统。
相比之下，Prometheus 和 Alertmanager 通过运行 Prometheus 的冗余副本和使用 Alertmanager 的高可用性模式，提供了完全开源的冗余选项。
这两个系统有许多相似之处。两者都有标签（在 InfluxDB 中称为标签），以有效支持多维度指标。两者都使用基本相同的数据压缩算法。两者都有广泛的集成，包括相互集成。两者都有钩子，允许您进一步扩展，例如在统计工具中分析数据或执行自动操作。
InfluxDB 更好的地方：
如果要进行事件日志记录。
商业选项为 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 事件有效载荷可包括一个或多个指标点，以 JSON 对象表示，其中包含名称、标签（键/值对）、时间戳和值（始终为浮点）。
存储
Sensu 将当前和最近的事件状态信息以及实时库存数据存储在嵌入式数据库（etcd）或外部 RDBMS（PostgreSQL）中。
Sensu 部署的所有组件都可以集群，以实现高可用性并提高事件处理吞吐量。
Sensu 和 Prometheus 有一些共同之处，但它们采用的监控方法却截然不同。两者都为基于云的动态环境和短暂计算平台提供可扩展的发现机制，但底层机制却大相径庭。两者都支持通过标签和注释收集多维度指标。两者都有广泛的集成，Sensu 本机支持从所有 Prometheus 输出程序收集指标。两者都能将可观测性数据转发到第三方数据平台（如事件存储或 TSDB）。Sensu 和 Prometheus 最大的不同在于它们的使用案例。
Sensu 更好的地方：
如果您正在收集和处理混合可观察性数据（包括指标和/或事件）
如果您正在整合多个监控工具，并需要支持指标和 Nagios 风格的插件或检查脚本
更强大的事件处理平台
Prometheus 的优势：
如果您主要收集和评估指标
如果您监控的是同构的 Kubernetes 基础架构（如果您监控的工作负载 100% 都在 K8s 中，Prometheus 的 K8s 集成度更高）
更强大的查询语言，以及对历史数据分析的内置支持
Sensu 由一家商业公司按照开放核心业务模式进行维护，提供闭源事件关联和聚合、联合和支持等高级功能。Prometheus 是一个完全开源的独立项目，由多家公司和个人维护，其中一些公司还提供商业服务和支持。
川公网安备51010802032098
