翻译，原文链接
Prometheus vs Graphite
Scope
Graphite是一个用Python写的web应用，是一个企业级的系统监控工具，可以在廉价机硬件上运行。它由三个软件组件组成：
- carbon 一个Twisted守护进程，监听并接收时间序列数据
- whisper 一固定大小文件的数据库，用来存储时间序列数据，在设计上类似于RRD
- graphite-web 使用Django框架实现的一个webapp，它可以从whisper数据库获取时间序列数据并且进行展示。
也就是说Graphite是一个被动接收的时间序列数据库，只不过提供数据展示的功能。数据采集agent、警报等其它的功能，需要引入第三方软件来支持。
Prometheus可是说是一个全能监控系统，它提供了基于时间序列数据的数据采集、存储、查询、画图和告警的功能。由于prometheus采用主动(pull)采集的方式，它直到被监控的系统是什么样子的(哪个endpoints应该存在，那种时间序列模式意味着出问题)，能够为问题诊断提供强力的支持。
数据模型
两者的数据模型，大体上一致。不过Prometheus提供更加丰富的metadata模型：
- Graphite的metric名称以点"."分割组件，这种方式是一种维度的编码方式，通过"."来潜在的提供分割数据标识。
- Prometheus出了提供metric名称之外，明确的通过标签键值对标识metric不同的维度。这种方式更易于通过查询语句来过滤、分组、匹配metrics。
特别是当Graphite和StatsD结合使用时，它存储的数据一般是聚合过后的数据(维度降低了)，而不是原维度数据(这些数据有不同的维度，能够根据这些数据来定位更细节的问题)。
使用Graphite/StatsD存储状态码为500、方法是POST、路径是"/tracks"、服务名称为api-server(api-server有多个实例)的http请求数，这样一个监控指标：
stats.api-server.tracks.post.500 -> 93
而Prometheus存储同样的监控指标：
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
总之，Prometheus支持更高维度的监控指标。
存储
Graphite使用Whisper格式在本地磁盘存储时间序列数据。Whisper是RRD-style database，它要求到达的采样数据间隔固定。每一个时间序列存储在一个单独的文件，在一定时间之后新的采样数据会覆盖老得数据。
Prometheus也为每一个时间序列创建一个本地文件，但是允许以任意时间间隔存储采样数据(数据采集、规则计算评估时间任意)。旧数据可以是任意长度，新的采样数据只是简单的附加在老数据的后面。Prometheus针对短生命周期、频繁更改标签集合的时间序列也能和好的支持。
总结
相比，Prometheus提供更丰富的数据模型和查询语句，除此之外，还能够很容易的运行、整合到你的环境中。如果你想要集群化的解决方案，能够存储长期的历史数据，Graphite可能是更好的选择。
Prometheus vs InfluxDB
InfluxDB是一个开源的时间序列数据库，同时提供商业的伸缩和集群化服务。InfluxDB是在Prometheus一年之后提出的，所以当时InfluxDB没有办法成为存储选择项之一。仍然，Prometheus和InfluxDB有着重大的区别，两者面向解决的问题稍微不同。
Scope
为了公平，我们必须联合考虑Kapacitor和InfluxDB。这两者组合于Prometheus和Alertmanager的组合解决同样的问题。
与Graphite相同的范围差异都是用于InfluxDB。除此之外，InfluxDB提供了连续查询，这个与Prometheus的recording rules的功能类似。
Kapacitor相当于把Prometheus的recording rules, alerting rules, and the Alertmanager的通知功能结合在一起。相比，Prometheus为画图和警报提供了一个功能更加强大的查询语言。相比，Altermanager提供了分组、去重和沉默的功能。
数据模型/存储
和Prometheus一样，InfluxDB也有标签键值对。除此之外，InfluxDB有第二等级的标签，叫做fields，不过使用上很受限制。InfluxDB支持钠秒级别的时间戳，浮点64，整型64和字符串数据类型。相比，Prometheus支持浮点64数据类型，有限的字符串和毫秒级别的时间戳。
InfluxDB使用log-structured merge tree 的变体来存储，并提前写入日志，按时间分片。和Prometheus相比，这种存储模式更适用于事件日志，而Prometheus只支持在尾部附加文件(当时间序列到来的时候)。
Logs and Metrics and Graphs, Oh My!描述了事件记录和指标记录之间的区别。
架构
Prometheus服务之间是独立的(也就是服务之间是解藕的)，核心功能(scraping, rule processing, and alerting)只依赖于本地存储。InfluxDB类似。
商业版的InfluxDB提供分布式集群存储，多节点同时支持查询（提高性能）。这也意味着，商业版本InfluxDB很容易横向扩展，同时也意味着，你必须接受维护分布式存储的复杂性。相比，Prometheus运行、维护成本更低，但在某些时候，你需要明确地沿着可扩展性边界（如产品，服务，数据中心或类似方面）对服务器进行分片。 独立服务器（可以并行运行冗余）也可以为你提供更好的可靠性和故障隔离。
Kapacitor的开源版本不支持规则、警报和通知的分发／冗余功能。开源版本支持人为的扩容，类似于Prometheus。但是，Influx提供了企业级的Kapacitor，提供一个支持HA／冗余功能的警报系统。
相比，Prometheus和Alertmanager提供一个完全开源，支持冗余（通过运行多个Prometheus，使用Alertmanager的高可用模式）。
总结
两者之间有很多相似之处。都是通过标签（lable in Prometheus, tag in InfluxDB）来支持多维度的metrics。两者使用的压缩算法基本相同。两者都提供额外的组件，来丰富本身的功能。两者都提供借口，便于我们自己对他们进行扩展，比如：使用统计工具分析数据，执行一些自动化的操作。
InfluxDB的优势：
- 如果需要处理事件类型的数据
- 商业选择，需要集群功能，需要长期存储数据
- 需要不同分片之间的数据一致性
Prometheus的优势： - 处理的数据类型是metrics
- 需要强大的查询、警报、通知功能
- Higher availability and uptime for graphing and alerting.
InfluxDB主要由一个商业公司维护，和开源版本相比，提供更多的额外功能。Prometheus是一个完全开源的、不依赖与任何商业公司的项目，有多个公司、个人维护、支持。
Prometheus vs OpenTSDB
OpenTSDB是一个基于Hadoop和Hbase的分布式时间序列数据库。
Scope
区别，参看上述和Graphite的对比
数据模型
OpenTSDB和Prometheus的数据模型几乎一致：由一组任意的标签键值对标识的时间序列。一个metric的所有数据存储在一起，限制了指标的基数。两者之间细小的差别：Prometheus标签的值允许是任意字符，而Prometheus对字符有限制；和Prometheus相比，OpenTSDB的查询功能不够强大，只支持简单的聚合和数学运算。
存储
OpenTSDB的存储依赖于Hadoop和Hbase。这意味着，OpenTSDB的横向扩缩容很容易，同时也意味着，你需要接受维护Hadoop/HBase集群的复杂性。相比，Prometheus运行、维护更简单，但是需要明确的分区，当数据量超过单点Prometheus所能够支持的上限时。
总结
Prometheus提供更加强大的查询语句，能够处理“更大集的metrics”，提供一个完整的监控系统。如果你已经有了Hadoop集群，并且需要长期存储监控数据，OpenTSDB是一个更加的选择。
Prometheus vs Nagios
Nagios是1990年出现的一个监控系统。
Scope
Nagios主要基于已经存在的脚本报警。这些脚本被称为“checks”。警报提供沉寂功能（针对单独的警报），不支持分组、路由和去重。Nagios有各种各样的插件支持。
数据模型
Nagios是基于主机的，每一个主机有一个或者多个服务，每一个服务执行一个检查。Nagios没有标签的概念、没有查询语言。
存储
Nagios没有的存储，不提供当前历史数据。不过，有插件支持存储数据。
架构
Nagios是单机版的，所有的“checks”配置都是通过文件配置。
总结
Nagios适用于小规模系统或者静态系统的基本监控（黑盒探测能够满足这种需求）。如果你需要白盒监控，或者需要监控动态的、基于云的环境，Prometheus是更好的选择。
Prometheus vs. Sensu
Sensu可以认为是Nagios的当代版本。
Scope
上述和Nagios的比较同样适用于这里。
和Nagios的主要区别是：Sensu的客户端能够自行注册，能够控制“checks”是按照中心配置运行、还是按照本地配置运行。Sensu对perfData的数量没有限制。
There is also a client socket permitting arbitrary check results to be pushed into Sensu.
数据模型
和Nagios一样。
存储
Sensu has storage in Redis called stashes. These are used primarily for storing silences. It also stores all the clients that have registered with it.
架构
Sensu有很多组件。它使用RabbitMQ传递数据，Redis存储当前状态，使用单独的服务器用于数据处理。
RabbitMQ和RabbitMQ都支持集群模式。多副本服务器能够提供扩容和数据冗余。
总结
如果你之前用的是Nagios(不想有太大的变动)，只是想使用伸缩功能，或者想使用Sensu的注册功能，那么可以选择Sensu。
如果你想要白盒监控，或者需要监控一个动态的云环境，那么拥抱Prometheus吧。
网友评论