注：本文会不定期持续更新，目前已经增加到为13个工具的对比。
推荐指数：
Cacti，最悠久的监控系统之一，2001年9月，一个名叫LanBerry的高中生，当时他还在为一家小的ISP厂商工作，为了更好地监控网络质量，开发了Cacti的第一个版本，基于RRDtool，提供更友好的使用体验。
RRDtool使用的数据存储格式，大家也常常称之为环状数据库，其工作方式有三个显著的特点：第一，RRD文件在创建的时候，其文件大小就确定下来了，随着数据的不断写入，RRD文件的大小一直保持不变；第二，数据每次更新到RRD文件的时候，都会触发RRD文件中的归档策略，也就是数据采样策略；第三，查询历史数据的时候，会自动选择最优化的采样数据，而不是全量获取数据，查询效率很高。
使用RRDtool的过程中遇到过一些问题，RRDtool的数据是以文件的形式存储在磁盘上，以单机的形式来提供服务的，这样就存在容量上限。该上限的决定因素较多，比如磁盘容量、磁盘IO、CPU等，但是最核心的制约因素就是磁盘IO，用户每push一次数据，都会转化为对相应的RRD文件的一些全量的读/写，磁盘IO会最先遇到瓶颈。在一台普通的Linux服务器上，在1分钟push数据的频率下，一般20万条的Counter上报就会跑满磁盘IO。这显然无法满足较大规模数据下的监控需求。
为了在一定程度上缓解磁盘IO压力的问题，RRDtool官方提供了一个组件rrdcached，这是一个常驻内存的后台程序，用户可以把读/写请求通过网络发送给rrdcached，而不是直接操作磁盘。rrdcached内部做了一些优化措施来减轻对磁盘的读/写压力，包括：缓存RRD文件的header部分，每次数据push上来的时候可以减少一次读取操作；对RRD文件的写入，提供了用户态的缓存，即把用户的多次写入操作合并成一次flush到磁盘上，这样有效地提高了写入效率。通过该项优化，使得单机的容量提升不少。不过上述优化，也只能解决一定程度上的问题，整体容量仍然局限于单机的容量上限。
Collectd相比Cacti、RRDtool来说，较为年轻一些，项目最早是在2005年由FlorianForster开发的，之后便蓬勃发展成为一个开源的项目，很多开发者对其做了大量的改进和扩展。Collectd的定位是收集和传输数据。在告警方面不是Collectd的设计初衷，不过它也支持一些简单的阈值判定，并发送告警信息。要支持更高级的一些告警需求，Collectd可以和Nagios配合使用，有一个名为collectd-nagios的插件可以很方便地完成这个功能。
Collectd是一个用C语言开发的常驻内存的程序，由一堆功能强大的插件组成，其架构示意图如图1所示。
Nagios可以监控各种网络服务，比如SMTP、POP3、HTTP、NTP、ICMP、FTP、SSH等，也可以监控主机资源，比如CPU、Load、磁盘使用、Syslog等。基本工作模式如图2所示。
这里介绍两个比较重要的概念：NRPE和SNMP。
NRPE的全称是NagiosRemotePluginExecutor，是Nagios的Agent，这可以让Nagios具备监控远程主机和设备的能力。Nagios服务端，通过check_nrpe插件会定期地调用运行在远程主机上的NRPE，执行具体的脚本来获取数据，比如check_load、check_disk、check_ftp等。
SNMP（SimpleNetworkManagementProtocol，简单的网络管理协议）是一种应用层协议，被路由器、交换机、服务器、工作站、打印机等网络设备广泛支持，主要用于管理和监控网络设备。SNMP的工作方式主要有三种：管理员需要向设备获取数据，SNMP提供了“读”操作；管理员需要向设备执行设置操作，SNMP提供了“写”操作；设备需要在重要状况改变的时候，向管理员通报事件的发生，SNMP提供了“Trap”操作。
SNMP的基本思想是：为不同种类的设备、不同厂家生产的设备、不同型号的设备，定义一个统一的接口和协议，使得管理员可以使用统一的方式对这些需要管理的网络设备进行管理。通过网络，管理员可以管理位于不同物理空间的设备，从而大大提高了网络管理的效率，简化了网络管理员的工作。Nagios很好地利用了SNMP的读和Trap功能，很容易地获取各种网络设备的运行数据，达到监控的目的。
Zabbix作为一款企业级分布式监控系统，功能齐全，用户体验良好，文档完善，API强大，适合于中小规模的公司或者团队使用。
Zabbix的主要特点有：
在以上特点中，尤其是API功能，完善程度很高，基本上Zabbix的大部分操作都提供了相应的API接口，方便用户编程，和现有的一些系统进行整合。比如以下一些场景。
Zabbix主要由Server、Agent、Proxy和Web-portal几个部分组成。典型的Zabbix的部署模式如下图所示。
Zabbix的数据采集，主要有两种模式：Server主动拉取数据和Agent主动上报数据。以前者为例，用户在Web-portal中，配置好机器，并给机器应用相应的模板后，Zabbix-server就会定期地去获取Agent的数据，存储到MySQL中，同时根据用户配置的策略，判定是否需要告警。用户可以在Web端，以图表的形式，查看各种指标的历史趋势。
在Zabbix中，将Server主动拉取数据的方式称之为activecheck。这种方式配置起来较为方便，但是会对Zabbix-server的性能存在影响，所以在生产环境中，一般会选择主动推送数据到Zabbix-server的方式，称之为trapper。即用户可以定时生成数据，再按照Zabbix定义的数据格式，批量发送给Zabbix-server，这样可以大大提高Server的处理能力。
Proxy是Zabbix具备分布式监控能力的一个必备条件，试想我们有一批服务器和网络设备位于防火墙之后，Zabbix-server无法直接访问这些Agent，这时候我们可以选择在防火墙的后面放置一个Zabbix-proxy，那么Proxy就会充当Server的角色，定期收集它所负责的这些Agent的数据，然后定期推送回Zabbix-server。另外，Proxy还可以分担Server的压力，代替Server定期拉取数据，再统一push给Server，这样可以有效地降低Server的开销。
在Zabbix的设计中，以下几个概念是最重要的。
Zabbix在业务处于较小规模的时候，效果还是相当不错的。但是当监控的对象超过上千台设备，并且还包括一些服务自身的业务指标也推送到Zabbix的时候，我们遇到了两个严重的问题——Zabbix的性能问题和用户的“使用效率”低下问题。
Zabbix的性能问题主要存在两个方面，一是Zabbix-server处理能力有限，尤其当activecheck模式的采集项较多的时候，会显著消耗Server的Puller线程，使得数据采集延迟，产生堆积，造成报警延迟。我们可以调大Puller的线程数，缓解这个问题，但Zabbix-server自身无法水平扩展，所以不能解决根本问题；二是Zabbix的数据存储引擎存在性能瓶颈，我们线上采用的是MySQL，当数据采集项过多的时候，比如在每分钟大概有20万采集项的规模下，MySQL的写入会达到瓶颈。
综上所述，在业务规模较小的前提下，Zabbix是一个很可靠的开源解决方案。在业务规模不断增长的情况下，需要投入较多的精力在其性能优化上。
OpenTSDB的部署结构和工作流程如下图所示。
HBase为数据存储引擎，TSD是OpenTSDB最核心的组件，和HBase的所有数据交互都通过TSD来完成。TSD是一个常驻内存的进程，是无状态的，可以水平扩展。
OpenTSDB提供了Web界面，通过HTTP的接口向TSD查询数据；我们也可以编写一些插件，比如告警插件，从TSD中获取某个指标的数据来判定是否满足阈值，以及是否需要告警。
TDengine是一款开源、云原生的时序数据库，专为物联网、工业互联网、金融、IT运维监控等场景设计并优化。它能让大量设备、数据采集器每天产生的高达TB甚至PB级的数据得到高效实时的处理，对业务的运行状态进行实时的监测、预警，从大数据中挖掘出商业价值。
此外，TDengine也可以作为Prometheus的分布式时序数据库，来解决存储的扩展性问题。Prometheus是一款流行的开源监控告警系统。Prometheus于2016年加入了CloudNativeComputingFoundation（云原生云计算基金会，简称CNCF），成为继Kubernetes之后的第二个托管项目，该项目拥有非常活跃的开发人员和用户社区。
Prometheus提供了remote_write和remote_read接口来利用其它数据库产品作为它的存储引擎。为了让Prometheus生态圈的用户能够利用TDengine的高效写入和查询，TDengine也提供了对这两个接口的支持。
通过适当的配置，Prometheus的数据可以通过remote_write接口存储到TDengine中，也可以通过remote_read接口来查询存储在TDengine中的数据，充分利用TDengine对时序数据的高效存储查询性能和集群处理能力。
vmstorage、vminsert、vmselect三者组合构成VictoriaMetrics的集群功能，三者都可以通过启动多个实例来分担承载流量，通过要在vminsert和vmselect前面架设负载均衡。
vmstorage是数据存储模块:
vminsert接收来自客户端的数据写入请求，并负责转发到选定的vmstorage:
vmselect接收来自客户端的数据查询请求，并负责转发到所有的vmstorage查询结果，最后将结果merge后返回:
Prometheus是由前Google工程师从2012年开始在Soundcloud以开源软件的形式进行研发的系统监控和告警工具包，自此以后，许多公司和组织都采用了Prometheus作为监控告警工具。Prometheus的开发者和用户社区非常活跃，它现在是一个独立的开源项目，可以独立于任何公司进行维护。为了证明这一点，Prometheus于2016年5月加入CNCF基金会，成为继Kubernetes之后的第二个CNCF托管项目。
Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。相比于传统监控系统Prometheus具有以下优点：
1.易于管理
Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。
Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。对于一些复杂的情况，还可以使用Prometheus服务发现(ServiceDiscovery)的能力动态管理监控目标。
2.监控服务的内部运行状态
Pometheus鼓励用户监控服务的内部状态，基于Prometheus丰富的Client库，用户可以轻松的在应用程序中添加对Prometheus的支持，从而让用户可以获取服务和应用内部真正的运行状态。
3.强大的数据模型
4.强大的查询语言PromQL
Prometheus内置了一个强大的数据查询语言PromQL。通过PromQL可以实现对监控数据的查询、聚合。同时PromQL也被应用于数据可视化(如Grafana)以及告警当中。
通过PromQL可以轻松回答类似于以下问题：
5.高效
对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据，对于单一PrometheusServer实例而言它可以处理：
6.可扩展
Prometheus是如此简单，因此你可以在每个数据中心、每个团队运行独立的PrometheusSevrer。Prometheus对于联邦集群的支持，可以让多个Prometheus实例产生一个逻辑集群，当单实例PrometheusServer处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。
7.易于集成
使用Prometheus可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持：Java，JMX，Python，Go，Ruby，.Net，Node.js等等语言的客户端SDK，基于这些SDK可以快速让应用程序纳入到Prometheus的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅仅支持Prometheus，还能支持Graphite这些其他的监控工具。
同时Prometheus还支持与其他的监控系统进行集成：Graphite，Statsd，Collected，Scollector，muini，Nagios等。
Prometheus社区还提供了大量第三方实现的监控数据采集支持：JMX，CloudWatch，EC2，MySQL，PostgresSQL，Haskell，Bash，SNMP，Consul，Haproxy，Mesos，Bind，CouchDB，Django，Memcached，RabbitMQ，Redis，RethinkDB，Rsyslog等等。
8.可视化
PrometheusServer中自带了一个PrometheusUI，通过这个UI可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。同时Prometheus还提供了一个独立的基于RubyOnRails的Dashboard解决方案Promdash。最新的Grafana可视化工具也已经提供了完整的Prometheus支持，基于Grafana可以创建更加精美的监控图标。基于Prometheus提供的API还可以实现自己的监控可视化UI。
9.开放性
通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持。因此应用程序会与所选择的监控系统进行绑定。为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系统的支持，要么就在外部创建单独的服务来适配不同的监控系统。
而对于Prometheus来说，使用Prometheus的clientlibrary的输出格式不止支持Prometheus的格式化数据，也可以输出支持其它监控系统的格式化数据，比如Graphite。
因此你甚至可以在不使用Prometheus的情况下，采用Prometheus的clientlibrary来让你的应用程序支持监控数据采集。
不过prometheus在落地生产环境的过程中，目前存在以下痛点：
监控系统是整个运维环节，乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供翔实的数据用于追查定位问题。监控系统作为一个成熟的运维产品，业界有很多开源的实现可供选择。当公司刚刚起步，业务规模较小，运维团队也刚刚建立的初期，选择一款开源的监控系统，是一个省时省力，效率最高的方案。之后，随着业务规模的持续快速增长，监控的对象也越来越多，越来越复杂，监控系统的使用对象也从最初少数的几个SRE，扩大为更多的DEVS，SRE。这时候，监控系统的容量和用户的“使用效率”成了最为突出的问题。
夜莺除了对接时序库，还可以对接各类采集器agent，比如telegraf、categraf、datadog-agent、各类exporter等，不同的数据库、中间件都有提供一些现成的仪表盘、告警规则，这样可以快速上手，省心不少。下面是夜莺内置的模板中心：
很多朋友不会写promql，但是promql在Prometheus生态里又极为重要，那能否让一些资深工程师提前写好，沉淀下来，普通工程师直接用呢？夜莺支持的指标视图就是干这个事的，目前已经内置沉淀了几百个promql，开箱即用。
虽然已经内置了不少仪表盘了，但是还是不如grafana那么丰富，grafana在看图这块确实无出其右，夜莺内置的那些仪表盘，如果你觉得够用了，就用，如果觉得不够用，建议还是上grafana，下图是夜莺内置的一个仪表盘样例：
Prometheus可以搞定数据采集、存储问题，并提供查询接口、查询语言，但是对于数据的展示，Prometheus本身并不是很强大，通常大家会选择使用Grafana作为展示工具。
Grafana不仅仅为Prometheus提供了很多的Dashboard模板，而且还支持多种数据源，比如InfluxDB、Elasticsearch、Loki、MySQL、PostgreSQL、CloudWatch、Zabbix等等。Grafana的可视化能力，基本就是开源领域的标杆甚至事实标准了。