今天整理一下Prometheus与竞品的一些比较。
Prometheus vs. Graphite
范围(Scope)
Graphite专注于成为具有查询语言和图形功能的被动时间序列数据库。任何其他问题都由外部组件解决。
Prometheus 是一个完整的监控和趋势系统，包括基于时间序列数据的内置和主动抓取、存储、查询、图形和警报。它知道世界应该是什么样子（哪些端点应该存在，什么时间序列模式意味着麻烦等），并积极尝试寻找故障。
数据模型(Data Model)
Graphite 存储命名时间序列的数字样本，就像 Prometheus 所做的那样。然而，Prometheus 的元数据模型更丰富：虽然 Graphite 度量名称由隐式编码维度的点分隔组件组成，但 Prometheus 将维度显式编码为键值对，称为标签，附加到度量名称。这允许通过查询语言通过这些标签轻松过滤、分组和匹配。
此外，特别是当 Graphite 与StatsD结合使用时，通常只存储所有受监控实例的聚合数据，而不是将实例保留为维度并能够深入到单个有问题的实例。
例如，当存储HTTP请求的数量与响应代码API服务器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
Storage
Graphite 以Whisper格式将时间序列数据存储在本地磁盘上，这 是一种 RRD 风格的数据库，期望样本定期到达。每个时间序列都存储在一个单独的文件中，新样本在一定时间后覆盖旧样本。
Prometheus 还为每个时间序列创建一个本地文件，但允许在发生刮擦或规则评估时以任意间隔存储样本。由于只是简单地附加了新样本，因此旧数据可能会保留任意长的时间。Prometheus 也适用于许多短期、频繁变化的时间序列集。
概括(Summary)
Prometheus 提供更丰富的数据模型和查询语言，此外更易于运行和集成到您的环境中。如果您想要一个可以长期保存历史数据的集群解决方案，Graphite 可能是更好的选择。
Prometheus vs. InfluxDB
InfluxDB是一个开源时间序列数据库，具有用于扩展和集群的商业选项。InfluxDB 项目是在 Prometheus 开发开始近一年后发布的，因此我们当时无法将其视为替代方案。尽管如此，Prometheus 和 InfluxDB 之间仍存在显着差异，并且两个系统都面向略有不同的用例。
范围(Scope)
为了公平比较，我们还必须将Kapacitor与 InfluxDB 一起考虑 ，因为它们结合起来解决与 Prometheus 和 Alertmanager 相同的问题空间。
与Graphite相同的范围差异适用于 InfluxDB 本身。另外 InfluxDB 提供了连续查询，相当于 Prometheus 的记录规则。
Kapacitor 的范围是 Prometheus 记录规则、警报规则和 Alertmanager 通知功能的组合。Prometheus为图形和警报提供了更强大的查询语言。Prometheus Alertmanager 还提供分组、重复数据删除和静音功能。
数据模型/存储 (Data Model / Storage)
和 Prometheus 一样，InfluxDB 数据模型有键值对作为标签，称为标签。此外，InfluxDB 还有二级标签叫做字段，使用上比较有限。InfluxDB 支持分辨率高达纳秒的时间戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 支持 float64 数据类型，但对字符串和毫秒分辨率时间戳的支持有限。
InfluxDB 使用日志结构合并树的变体来存储带有预写日志，按时间分片。这比 Prometheus 的每个时间序列的仅附加文件方法更适合事件记录。
Logs and Metrics and Graphs, Oh My! 描述了事件日志记录和指标记录之间的区别。
架构(Architecture)
Prometheus 服务器彼此独立运行，仅依赖其本地存储来实现其核心功能：抓取、规则处理和警报。InfluxDB 的开源版本也类似。
商业 InfluxDB 产品在设计上是一个分布式存储集群，其存储和查询同时由多个节点处理。
这意味着商业 InfluxDB 将更容易横向扩展，但也意味着您必须从一开始就管理分布式存储系统的复杂性。Prometheus 将更易于运行，但在某些时候，您将需要沿着可扩展性边界（如产品、服务、数据中心或类似方面）明确地对服务器进行分片。独立服务器（可以并行冗余运行）也可以为您提供更好的可靠性和故障隔离。
Kapacitor 的开源版本没有用于规则、警报或通知的内置分布式/冗余选项。Kapacitor 的开源版本可以通过用户手动分片进行扩展，类似于 Prometheus 本身。Influx提供Enterprise Kapacitor，它支持 HA/冗余警报系统。
相比之下，Prometheus 和 Alertmanager 通过运行 Prometheus 的冗余副本和使用 Alertmanager 的高可用性 模式提供了一个完全开源的冗余选项 。
概括(Summary)
系统之间有许多相似之处。两者都有标签（在 InfluxDB 中称为标签）以有效支持多维指标。两者都使用基本相同的数据压缩算法。两者都有广泛的集成，包括彼此之间的集成。两者都有钩子，允许您进一步扩展它们，例如在统计工具中分析数据或执行自动化操作。
InfluxDB 更好的地方：
- 如果您正在进行事件记录。
- 商业选项为 InfluxDB 提供集群，这也更适合长期数据存储。
- 副本之间最终一致的数据视图。
Prometheus更好的地方：
- 如果您主要做指标。
- 更强大的查询语言、警报和通知功能。
- 图形和警报的更高可用性和正常运行时间。
InfluxDB 由一家遵循开放核心模型的商业公司维护，提供闭源集群、托管和支持等高级功能。Prometheus 是一个完全开源的独立项目，由许多公司和个人维护，其中一些还提供商业服务和支持。
Prometheus vs. OpenTSDB
OpenTSDB是一个基于Hadoop和HBase的分布式时序数据库 。
范围(Scope)
与Graphite相同的范围差异 适用于此处。
数据模型(Data Model)
OpenTSDB 的数据模型几乎与 Prometheus 的相同：时间序列由一组任意键值对标识（OpenTSDB 标签是 Prometheus 标签）。指标的所有数据都 存储在一起，从而限制了指标的基数。不过也有细微的差别：Prometheus 允许在标签值中使用任意字符，而 OpenTSDB 的限制性更强。OpenTSDB 也缺乏完整的查询语言，仅允许通过其 API 进行简单的聚合和数学运算。
Storage
OpenTSDB的存储是在Hadoop和HBase之上实现的 。这意味着水平扩展 OpenTSDB 很容易，但是您必须从一开始就接受运行 Hadoop/HBase 集群的整体复杂性。
Prometheus 最初运行起来会更简单，但一旦超出单个节点的容量，将需要显式分片。
概括(Summary)
Prometheus 提供了更丰富的查询语言，可以处理更高的基数指标，并构成完整监控系统的一部分。如果您已经在运行 Hadoop 并且重视长期存储的这些好处，那么 OpenTSDB 是一个不错的选择。
Prometheus vs. Nagios
Nagios是一种监控系统，起源于 1990 年代的 NetSaint。
范围(Scope)
Nagios 主要是基于脚本的退出代码发出警报。这些被称为“检查”。有个别警报静音，但没有分组、路由或重复数据删除。
有各种各样的插件。例如，允许通过管道传输几千字节的 perfData 插件返回到时间序列数据库（例如 Graphite）或使用 NRPE在远程机器上运行检查。
数据模型(Data Model)
Nagios 是基于主机的。每个主机可以有一个或多个服务，每个服务可以执行一项检查。
没有标签或查询语言的概念。
Storage
Nagios 本身没有存储，超出当前检查状态。有一些插件可以存储数据，例如用于可视化。
架构(Architecture)
Nagios 服务器是独立的。检查的所有配置都是通过文件进行的。
概括(Summary)
Nagios 适用于黑盒探测就足够的小型和/或静态系统的基本监控。
如果你想做白盒监控，或者有一个动态或基于云的环境，那么 Prometheus 是一个不错的选择。
Prometheus vs. Sensu
Sensu是一个开源监控和可观察性管道，具有商业发行版，可提供可扩展性的附加功能。它可以重用现有的 Nagios 插件。
范围(Scope)
Sensu 是一个可观察性管道，专注于将可观察性数据作为事件流进行处理和警报。它为事件过滤、聚合、转换和处理提供了一个可扩展的框架——包括向其他系统发送警报和在第三方系统中存储事件。Sensu 的事件处理能力在范围上类似于 Prometheus 警报规则和 Alertmanager。
数据模型(Data Model)
Sensu事件以结构化数据格式表示服务健康和/或指标，由实体名称（例如服务器、云计算实例、容器或服务）、事件名称和称为“标签”或“注释”的可选键值元数据标识”。Sensu 事件有效负载可能包括一个或多个 metric points，表示为包含name、tags（键/值对）timestamp、 和value（始终为浮点数）的 JSON 对象。
Storage
Sensu 将当前和最近的事件状态信息以及实时库存数据存储在嵌入式数据库 (etcd) 或外部 RDBMS (PostgreSQL) 中。
架构(Architecture)
Sensu 部署的所有组件都可以集群化以实现高可用性和改进的事件处理吞吐量。
概括(Summary)
Sensu 和 Prometheus 有一些共同的功能，但它们采用非常不同的监控方法。两者都为基于云的动态环境和临时计算平台提供可扩展的发现机制，尽管底层机制大不相同。两者都支持通过标签和注释收集多维指标。两者都有广泛的集成，Sensu 本身支持从所有 Prometheus 导出器收集指标。两者都能够将可观察性数据转发到第三方数据平台（例如事件存储或 TSDB）。Sensu 和 Prometheus 最大的不同在于它们的用例。
Sensu 更好的地方：
- 如果您正在收集和处理混合可观察性数据（包括指标和/或事件）
- 如果您正在整合多个监控工具并需要支持指标和Nagios 风格的插件或检查脚本
- 更强大的事件处理平台
Prometheus 更好的地方：
- 如果您主要收集和评估指标
- 如果您正在监控同构 Kubernetes 基础设施（如果您监控的工作负载 100% 在 K8s 中，Prometheus 提供更好的 K8s 集成）
- 更强大的查询语言，内置支持历史数据分析
Sensu 由一家遵循开放核心业务模型的商业公司维护，提供诸如闭源事件关联和聚合、联合和支持等高级功能。Prometheus 是一个完全开源的独立项目，由许多公司和个人维护，其中一些还提供商业服务和支持。
