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="<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方式把时间序列数据存储到本地磁盘，这种数据存储格式是RRD格式数据库，它期望样本能够定期到达。任何时间序列在一个单独的文件中存储，一段时间后新采集的样本会覆盖老数据。
Prometheus也为每一个时间序列创建了一个本地文件，但是它允许时间序列以任意时间到达。新采集的样本被简单地追加到文件尾部，老数据可以任意长的时间保留。Prometheus对于短生命周期、且经常变化的时间序列集也可以表现得很好。
Prometheus提供了一个丰富的数据模型和查询语言，而且更加容易地运行和集成到你的环境中。如果你想要一个可以长期保留历史数据的集群解决方案，Graphite可能是一个更好的选择。
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和millisecond 只能小范围地支持。
InfluxDB使用变种的日志结构合并树结构来存储预写日志，并按时间分片。这比Prometheus的文件追加更适合事件记录 Logs and Metrics and Graphs, Oh My!描述了事件日志和度量指标记录的不同
Prometheus服务器彼此独立运行，其核心功能仅依赖于本地存储：抓取、规则处理和警报。influxDB的开源版本类似。
InfluxDB的商业版本具有存储和查询的分布式版本,存储和查询由集群中的节点同时处理。
这意味着商业版本的InfluxDB更加容易的水平扩展，同时也表示你必须从一开始就要管理分布式存储系统的复杂性。而Prometheus运行非常简单，而且在某些时候，你需要在可扩展性边界（如产品，服务，数据中心或者类似方面）明确分片服务器。单Prometheus服务也可以为您提供更好的可靠性和故障隔离。
Kapacitor对规则、警告和通知当前还没有内置/冗余选项。相反地，通过运行Prometheus的冗余副本和使用警告管理器的高可用模式提供了冗余选项。Kapacitor通过用户手动水平切分能够被缩放，这点类似于Prometheus> 本身
在两个系统之间有许多相似点。都使用标签（tags/labels）有效地支持多维度量指标。都使用使用相同的压缩算法。都可扩展集成。都允许使用第三方进行监控系统的扩展，如：统计分析工具、自动化操作
InfluxDB更好之处：
- 使用事件日志
- 商业版本提供的集群方案，对于长期的时间序列存储是非常不错的
- 复制的数据最终一致性
Prometheus更好之处：
- 主要做度量指标监控
- 更强大的查询语言，警告和通知功能
- 图表和警告的高可靠性和稳定性
InfluxDB是有一家商业公司按照开放核心模式运营，提供高级功能，如：集群是闭源的，托管和支持。Prometheus是一个完全开放和独立的项目，有许多公司和个人维护，其中也提供一些商业服务和支持。
OpenTSDB是一个基于hadoop和Hbase的分布式时间序列数据库
和Graphite vs. Prometheus的范围一样
OpenTSDB的数据模型几乎和Prometheus一样：时间序列由任意的tags键值对集合表示。所有的度量指标存放在一起，并限制度量指标的总数量大小。Prometheus和OpenTSDB有一些细微的差别，例如：Prometheus允许任意的标签字符，而OpenTSDB的tags命名有一定的限制.OpenTSDB缺乏灵活的查询语言支持，通过它提供的API只能简单地进行聚合和数学计算。
OpenTSDB的存储由Hadoop和HBase实现的。这意味着水平扩展OpenTSDB是非常容易的，但是你必须接受集群的总体复杂性
Prometheus初始运行非常简单，但是一旦超过单个节点的容量，就需要进行水平切分服务操作
Prometheus提供了一个非常灵活且丰富的查询语言，能够支持更多的度量指标数量，组成整个监控系统的一部分。如果你对hadoop非常熟悉，并且对时间序列数据有长期的存储要求，OpenTSDB是一个不错的选择
Nagios是一款产生于90s年代的监控系统
Nagios是基于脚本运行结果的警告系统，又称"运行结果检查"。有警告通知，但是没有分组、路由和重复数据删除功能。
Nagios有大量的插件。例如：perfData插件抓取数据后写入到时间序列数据库（Graphite）或者使用NRPE在远程计算机上运行检查
Nagios是基于主机的，每一台主机有一个或者多个服务。其中一个是check运行检查，但是没有标签和查询语言的概念
Nagios除了检查脚本运行状态，没有任何存储功能。有第三方插件可以存储数据，并可视化数据
除了当前的检查状态，Nagios本身没有存储空间。有些插件可以存储数据，例如可视化。
Nagios是单实例服务，所有的检查配置项统一由一个文件配置。
Nagios对于小型监控或者黑盒测试时非常有效的。如果你想要做白盒监控，或者动态地，基于云环境的数据监控，Prometheus是一个不错的选择
广义上说，Sensu是一个更加现代的Nagios。
主要不同点在于Sensu客户端注册自己，并确定从本地还是其他地方获取配置检查。Senus对perfData的数量没有限制。 还有一个客户端socket允许把任意检查结果推送到Senus
和Nagios一样
Sensu在Redis中存储数据，存储被称作stashes。主要是静默存储，同时它也存储在Senus上注册的所有客户端
Sensu有很多组件。它使用Rabbit消息队列进行数据传输，使用Redis存储当前状态，独立的服务处理数据
RabbitMQ和Redis都可以是集群的，运行多个服务器副本可是实现副本和冗余
如果已经有了Nagios服务，你希望扩展它，同时希望使用Senus的注册特性，那么Senus是一个不错的选择
如果你想要使用白盒、或者有一个动态的云环境，那么Prometheus是一个很好的选择。