1.3 时序数据库为什么选 Prometheus
Prometheus 与 Graphite
范围
Graphite 专注于成为一个具有查询语言和绘图功能的被动时间序列数据库。任何其他问题都由外部组件处理。
Prometheus 是一个完整的监控和趋势系统，包括内置和活动的抓取、存储、查询、绘图和基于时间序列数据的报警。它知道监控应该是什么样子(监控点应该存在，时间序列模式意味着什么问题，等等)，并积极地寻找错误。
数据模型
Graphite 存储命名时间序列的数字样本和 Prometheus 所做的一样。然而，Prometheus 的元数据模型更丰富。
Graphite metric 名称由点分隔的编码组成，这些编码较为隐藏。而 Prometheus 将显式地编码为 key-value 对称为 label，附加到 metric 名称上。这允许通过查询语言对这些 label 进行简单的筛选、分组和匹配。
此外，特别是当使用 Graphite 与 StatsD 结合使用时，通常只在所有被监视的实例上存储聚合数据，而不是将实例作为维度保存，并能够深入到各个有问题的实例中。
例如，Graphite / StatsD 存储 api-server 返回值为 500 的 HTTP 请求的数据会像下面一样
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 格式存储在本地磁盘上，Whisper 格式是一种期望样本定期到达 RRD-style 数据库。 每个时间序列都存储在一个单独的文件中，新的采样数据会在一段时间后覆盖旧的采样数据。
Prometheus 也为每个时间序列数据创建一个本地文件，允许在发生剪贴或规则评估时以任意间隔存储数据。 由于新数据只是简单地追加，旧数据可以任意地保持较长时间。 Prometheus 也适用于许多短暂的、频繁变化的时间序列。
总结
Prometheus 提供了更丰富的数据模型和查询语句，并且更易于运行和集成到您的环境中。如果您想要能够长期保存历史数据的集群解决方案，那么 Graphite 可能是更好的选择。
Prometheus 与 InfluxDB
InfluxDB 是一个开放源码的时间序列数据库，具有可伸缩和集群的商业选项。 在 Prometheus 开发项目开始将近一年后，InfluxDB 项目发布了，因此我们当时无法考虑将其作为替代方案。 尽管如此，Prometheus 和 InfluxDB 之间仍然存在显著的差异，而且这两个系统都针对稍微不同的用例。
范围
为了进行公平的比较，我们还必须将 Kapacitor 和 InfluxDB 一起考虑，因为它们结合起来处理与 Prometheus 和 Alertmanager 相同的问题场景。
InfluxDB 提供连续查询，这相当于 Prometheus 记录规则。
Kapacitor 的场景是 Prometheus 记录规则、警报规则和 Alertmanager 通知功能的组合。 Prometheus 提供了一种更强大的查询语言，用于绘图和警报。 Prometheus 的 Alertmanager 还提供了分组，去重功能和静默功能。
数据模型和存储
与 Prometheus 一样，InfluxDB 数据模型也有 key-value 作为 labels ，称为 tag。 此外，InfluxDB 还有一个二级 labels 称为 field ，在使用上更加有限。 InfluxDB 支持纳秒级的时间戳，以及float64、int64、bool和字符串数据类型。 相比之下，Prometheus 支持 float64 数据类型，但对字符串和毫秒级分辨率时间戳的支持有限。
InfluxDB 使用了用于存储的一个变种 具有写前日志的日志结构合并树 （Storage Engine），用时间分片。 这比 Prometheus 的 “每个时间序列只添加一个文件” 方法更适合于事件日志记录。
Logs and Metrics and Graphs, Oh My! 这篇文章描述了事件日志记录和指标记录之间的差异。
体系结构
Prometheus 的服务器彼此独立运行，仅依赖本地存储实现核心功能:抓取、规则处理和警报。开源版本的 InfluxDB 也是类似的。
根据设计，商业的 InfluxDB 产品是一个分布式存储集群，存储和查询由多个节点同时处理。
这意味着商业的 InfluxDB 将更容易横向扩展，但也意味着您必须从一开始就管理分布式存储系统的复杂性。 Prometheus 将更易于运行，但在某些时候，您将需要根据可伸缩性边界(如产品、服务、数据中心或类似方面)显式地对服务器进行切分。独立服务器(可以冗余地并行运行)还可以提供更好的可靠性和故障隔离。
Kapacitor 的开源版本没有用于规则、警报或通知的内置的分布式/冗余选项，。 Kapacitor 的开源版本可以通过用户手工分片进行扩展，类似于 Prometheus 本身。 Influx 提供企业级的 Kapacitor，支持HA/冗余警报系统。
相比之下，Prometheus 和 Alertmanager 通过运行 Prometheus 的冗余副本并使用Alertmanager 的高可用性模式，提供了一个完全开源的冗余选项。
总结
这两个系统有许多相似之处。 它们都有 labels (在 InfluxDB 中称为 tag)来有效地支持多维 metric 。 两者使用的数据压缩算法基本相同。 两者都有广泛的集成，包括彼此之间的集成。 它们都有钩子，允许您进一步扩展它们，例如在统计工具中分析数据或执行自动化操作。
InfluxDB 的优点
- 存储事件日志
- 商业版本提供集群功能，对于存储长期数据是有帮助的。
- 数据副本之间的视图是一致的
Prometheus 的优点
- 存储指标数据。
- 更强大的查询语言、警报和通知功能。
- 高可用、很好的绘图功能、警报功能。
InfluxDB 由一个单一的商业公司遵循开放核心模型，提供高级功能，如闭源集群、托管和支持。 Prometheus 是一个完全开源和独立的项目，由许多公司和个人维护，其中一些还提供商业服务和支持。
Prometheus 与 OpenTSDB
OpenTSDB 是基于 Hadoop 和 HBase 的分布式时间序列数据库。
范围
这里适用的一般范围差异与 Graphite 的情况相同。
数据模型
OpenTSDB 的数据模型几乎与 Prometheus 的数据模型相同:时间序列由一组任意的 key-value 对(OpenTSDB 是 tag 而 Prometheus 是 label )。
所有 metric 数据存储在一起，限制了 metric 的基数。但是有一些细微的区别: Prometheus 允许在label 值中使用任意字符，而 OpenTSDB 的限制更严格。
OpenTSDB 也缺乏完整的查询语言，只允许通过其 API 进行简单的聚合和数学运算。
数据存储
OpenTSDB 的存储是在 Hadoop 和 HBase 上实现的。这意味着很容易横向扩展 OpenTSDB，但是您必须从一开始就接受运行 Hadoop/HBase 集群的总体复杂性。
Prometheus 最初运行起来会更简单，但一旦超过单个节点的容量，就需要手动的分开。
总结
Prometheus 提供了更丰富的查询语言，可以处理更高的基数指标，并构成一个完整监控系统的一部分。 如果您已经在运行 Hadoop，并且看重长期存储而不是这些好处，那么 OpenTSDB 是一个不错的选择。
Prometheus 与 Nagios
Nagios 是一种起源于20世纪90年代的监视系统，名为 NetSaint。
范围
Nagios 主要是基于脚本的退出代码发出警报。这些被称为“check”。有个别报警会静默，但没有分组，路由或重复数据删除。 Nagios 有各种各样的插件。例如，允许通过管道将几千字节的插件数据返回到时间序列数据库，如 Graphite ，或者使用 NRPE 在远程机器上运行检查。
数据模型
Nagios是基于主机的。每个主机可以有一个或多个服务，每个服务可以执行一个检查。 没有标签或查询语言的概念
数据存储
除了当前的检查状态外，Nagios本身没有存储。有一些插件可以存储数据，比如 visualisation。
结构体系
Nagios服务器是独立的。所有检查的配置都是通过文件进行的。
总结
Nagios 适用于基本监视小型系统或者静态系统，在这些系统中，黑盒探测就足够了。 如果您想进行白盒监控，或者拥有一个动态或基于云的环境，那么 Prometheus 是一个不错的选择。
Prometheus 与 Sensu
Sensu 是一个可组合的监视工作流，可以复用现有的 Nagios 检查。
范围
这里适用的一般范围差异与 Nagios 的情况相同。
还有一个客户端套接字允许将特别的检查结果推送到Sensu中。
数据模型
Sensu 拥有与 Nagios 相同的粗略数据模型。
数据存储
Sensu使用Redis持久化监控数据，包括Sensu客户端注册表、检查结果、检查执行历史和当前事件数据。
体系结构
Sensu有许多组件。它使用RabbitMQ作为传输，使用Redis表示当前状态，使用单独的服务器进行处理和API访问。 可以对Sensu部署的所有组件(RabbitMQ、Redis和Sensu服务器/API)进行集群，以实现高可用性和冗余配置。
总结
如果您希望按原样扩展现有 Nagios 设置，或者希望利用 Sensu 的自动注册特性，那么 Sensu 是一个不错的选择。 如果您想进行白盒监控，或者拥有一个非常动态的或基于云的环境，那么 Prometheus 是一个不错的选择。