监控系统产品比较：Prometheus vs. Graphite、InfluxDB、OpenTSDB等

Prometheus vs. Graphite

范围

Graphite专注于查询语言和图表特征的时间序列数据库。其他都需要依赖外部组件实现。

Prometheus是一个基于时间序列数据的完整监控系统和趋势系统，包括内置和主动抓取、存储、查询、图表展示和报警功能。它懂得监控系统和趋势系统应该是什么样的（哪些目标机应该存在，哪些时间序列模型存在问题等等），并积极地试着找出故障

数据模型

Graphite和Prometheus一样，存储时间序列数值样本。但是Prometheus的元数据模型更加丰富：Graphite的度量指标名称是由"."分隔符，隐式地编码多维度。而Prometheus度量指标是可以自定义名称的，并以key-value键值对的标签形式，成为度量指标的标签属性列表。并在此基础上，使用Prometheus查询语言可以轻松地进行过滤，分组和匹配操作。

进一步地，当Graphite与StatsD结合使用时，Graphite就只是对一个聚合数据的存储系统了，而不是把目标实例作为一个维度，并深入分析目标实例出现的各种问题。

例如：我们用Graphite/StatsD统计HTTP请求api-server服务的数量，前置条件：返回码是500，请求方法是POST，访问URL为/tracks , key如下所示：

stats.api-server.tracks.post.500 -> 93

但是在Prometheus中同样的数据存储可能像下面一样(假设有三个api-server)：

api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance=""} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance=""} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance=""} -> 31

由上可以看到，三个api-server各自的度量指标数据，Prometheus把api-server也作为了一个维度，便于分析api-server服务出现的各种问题。

存储

Graphite存储以Whisper方式把时间序列数据存储到本地磁盘，这种数据存储格式是RRD格式数据库，它期望样本能够定期到达。 任何时间序列在一个单独的文件中存储，一段时间后新采集的样本会覆盖老数据

Prometheus也为每一个时间序列创建了一个本地文件，但是它允许时间序列以任意时间到达。新采集的样本被简单地追加到文件尾部，老数据可以任意长的时间保留。Prometheus对于短生命周期、且经常变化的时间序列集也可以表现得很好

总结

Prometheus提供了一个丰富的数据模型和查询语言，而且更加容易地运行和集成到你的环境中。如果你想要一个可以长期保留历史数据的集群解决方案，Graphite可能是一个更好的选择。

Prometheus vs. InfluxDB

InfluxDB是一个开源的时间序列数据库，它的商业版本具有可扩展和集群化的特性。在Prometheus刚刚开始开发时，InfluxDB项目已经发布了近一年时间。但是这两款产品还是有很大的不同之处，这两个系统也有一些略有不同的应用小场景。

范围

公平起见，我们必须把InfluxDB和Kapacitor结合起来，与Prometheus和Prometheus的报警管理工具比较。

Graphite与Prometheus的范围差异，同样适用于InfluxDB本身。此外InfluxDB提供了连续查询，和Prometheus的记录规则一样。

Kapacitor的作用范围相当于，Prometheus的记录规则、告警规则和警告通知功能的结合。Prometheus提供了一个更加丰富地用于图表化和警告的查询语言，Prometheus告警器还提供了分组、重复数据删除和静默功能(silencing functionality)。

数据模型/存储

和Prometheus一样，InfluxDB数据模型采用的标签也是键值对形式，被称为tags。而且InfluxDB有第二级标签，被称为fields，它被更多地限制使用。InfluxDB支持高达纳秒级的时间戳，以及float64、int64、bool和string的数据类型。相反地，Prometheus仅仅支持float64的数据类型，strings和毫秒只能小范围地支持

InfluxDB使用变种的日志结构合并树结构来存储预写日志，并按时间分片。这比Prometheus的文件追加更适合事件记录
Logs and Metrics and Graphs, Oh My描述了事件日志和度量指标记录的不同

框架

Prometheus服务独立运行，没有集群架构，它仅仅依赖于本地存储。Prometheus有四个核心的功能：抓取、规则处理和警告。InfluxDB的开源版本也是类似的。
InfluxDB的商业版本具有存储和查询的分布式版本, 存储和查询由集群中的节点同时处理。
这意味着商业版本的InfluxDB更加容易的水平扩展，同时也表示你必须从一开始就要管理分布式存储系统的复杂性。而Prometheus运行非常简单，而且在某些时候，你需要在可扩展性边界（如产品，服务，数据中心或者类似方面）明确分片服务器。单Prometheus服务也可以为您提供更好的可靠性和故障隔离。

Kapacitor对规则、警告和通知当前还没有内置/冗余选项。相反地，通过运行Prometheus的冗余副本和使用警告管理器的高可用模式提供了冗余选项。Kapacitor通过用户手动水平切分能够被缩放，这点类似于Prometheus本身

总结

在两个系统之间有许多相似点。1. 利用标签（tags/labels）有效地支持多维度量指标。2. 使用相同的压缩算法。3.都可扩展集成。4.允许使用第三方进行监控系统的扩展，如：统计分析工具、自动化操作

InfluxDB更好之处：

• 使用事件日志
• 商业版本提供的集群方案，对于长期的时间序列存储是非常不错的
• 复制的数据最终一致性
  Prometheus更好之处：
• 主要做度量指标监控
• 更强大的查询语言，警告和通知功能
• 图表和警告的高可靠性和稳定性
  InfluxDB是有一家商业公司按照开放核心模式运营，提供高级功能，如：集群是闭源的，托管和支持。Prometheus是一个完全开放和独立的项目，有许多公司和个人维护，其中也提供一些商业服务和支持。

Prometheus vs. OpenTSDB

OpenTSDB是一个基于hadoop和Hbase的分布式时间序列数据库

范围

和Graphite vs. Prometheus的范围一样

数据模型

OpenTSDB的数据模型几乎和Prometheus一样：时间序列由任意的tags键值对集合表示。所有的度量指标存放在一起，并限制度量指标的总数量大小。Prometheus和OpenTSDB有一些细微的差别，例如：Prometheus允许任意的标签字符，而OpenTSDB的tags命名有一定的限制.OpenTSDB缺乏灵活的查询语言支持，通过它提供的API只能简单地进行聚合和数学计算

存储

OpenTSDB的存储由Hadoop和HBase实现的。这意味着水平扩展OpenTSDB是非常容易的，但是你必须接受集群的总体复杂性

Prometheus初始运行非常简单，但是一旦超过单个节点的容量，就需要进行水平切分服务操作

总结

Prometheus提供了一个非常灵活且丰富的查询语言，能够支持更多的度量指标数量，组成整个监控系统的一部分。如果你对hadoop非常熟悉，并且对时间序列数据有长期的存储要求，OpenTSDB是一个不错的选择

Prometheus vs. Nagios

Nagios是一款产生于90s年代的监控系统

范围

Nagios是基于脚本运行结果的警告系统，又称"运行结果检查"。有警告通知，但是没有分组、路由和重复数据删除功能。

Nagios有大量的插件。例如：perfData插件抓取数据后写入到时间序列数据库（Graphite）或者使用NRPE在远程计算机上运行检查

数据模型

Nagios是基于主机的，每一台主机有一个或者多个服务。其中一个是check运行检查，但是没有标签和查询语言的概念

Nagios除了检查脚本运行状态，没有任何存储功能。有第三方插件可以存储数据，并可视化数据

架构

Nagios是单实例服务，所有的检查配置项统一由一个文件配置。

总结

Nagios对于小型监控或者黑盒测试时非常有效的。如果你想要做白盒监控，或者动态地，基于云环境的数据监控，Prometheus是一个不错的选择

Prometheus vs. Sensu

广义上说，Sensu是一个更加现代的Nagios。

范围

主要不同点在于Sensu客户端注册自己，并确定从本地还是其他地方获取配置检查。Senus对perfData的数量没有限制。 还有一个客户端socket允许把任意检查结果推送到Senus

数据模型

和Nagios一样

存储

Sensu在Redis中存储数据，存储被称作stashes。主要是静默存储，同时它也存储在Senus上注册的所有客户端

架构

Sensu有很多组件。它使用Rabbit消息队列进行数据传输，使用Redis存储当前状态，独立的服务处理数据

RabbitMQ和Redis都可以是集群的，运行多个服务器副本可是实现副本和冗余

总结

如果已经有了Nagios服务，你希望扩展它，同时希望使用Senus的注册特性，那么Senus是一个不错的选择

如果你想要使用白盒、或者有一个动态的云环境，那么Prometheus是一个很好的选择。