在监控系统的实践中发现，现在开源软件中针对网络设备的监控系统使用比较广泛的有 cacti 和 zabbix。其中cacti 的功能比较单一，主要针对网络设备。而 zabbix 监控可以覆盖到设备层、系统层、中间件层等。但是这两款监控系统都存在架构设计上造成的一些短板。比如 cacti 高可用性比较差，zabbix 对一些协议的采集过于复杂，配置繁琐等。

cacti

cacti 使用的 RDDTool 时序数据库提供数据存储，但是RDDTool 并不能作为分布式，数据只能存放在单一节点上。所以我们只能对一台主机进行纵向扩展来提高数据的存储量与查询性能。

所以现在 Cacti 只对公司的网络设备进行流量采集作为与客户结算费用使用，并不对设备性能与流量进行报警。

常见计费方式多为 95 计费：

95计费

zabbix

zabbix 提供了丰富的模版，并且 SNMP 协议也可以使用自动发现机制对网络设备进行监控，从效率上大大提高了网络设备指标的采集。zabbix 对分布式有非常好的支持，zabbix proxy 可以让我们在不同的网域进行数据采集，最终在汇集到 zabbix-server 中。zabbix 的数据存储使用的是 mysql 或 DB2，从扩展性上也是非常强大的。但是mysql 属于关系型数据库，并非时序数据库，所以在针对线性时间数据存储的方面，需要运维人员对数据库的维护格外小心，因为数据表与表之间的耦合性非常高。

所在zabbix监控与 cacti 监控并存，主要作用为报警，对数据的存储时间周期要求并不高。

解决方案

我曾考虑替换 zabbix 后端存储数据库，因为在 zabbix 4.0+ 版本后，zabbix 已经支持对接 elasticsearch。当zabbix的历史数据存储到 elasticsearch 后，zabbix 的历史检索性相比之前使用 mysql 确实有很大的提高，但是整体架构却变得更加复杂，因为我使用了 10 台主机去单独作为 elasticsearch 集群。

elasticsearch 集群节点

替换了elasticsearch之后确实性能有了很大的提高，但是elasticsearch 属于倒排数据库，每个文本为了记录一个指标的数据，附带了很多其他额外的数据。虽然这样提高的检索的速度，但在存储以时间为索引的海量数据上并不合适。

对于一个IDC或者一个运营网络的企业来说，我们并不需要定制自己监控系统。但现有我们可用的开源监控系统都各有千秋，我们很难顾此失彼去做一个抉择，因为一旦监控系统上线运行，替换监控系统是一件非常危险非常复杂的事情。

按照套路先贬后仰，后面我一定会抛出一套我认为更加优秀的监控系统。但是我想在此之前仔说明一下，并不是 zabbix 与 cacti 不优秀、有缺陷，而是我们应该去了解更多不同的产品，根据自己的业务选择合适监控系统。