最近几年一直在使用监控系统，主要使用zabbix和prometheus 两个，对于这两个监控系统都有一些感受，简单来聊聊。

使用zabbix 最近被一个接口调用的bug导致zabbix 的主机信息、模版信息、以及他们的关联关系全丢了，因为配置了自动注册，在这些数据丢失以后，zabbix agent 又把自己注册了一次，然后通过备份数据恢复的时候这两部分就发生了冲突，一个表一个表的解决问题。恢复好以后，这个事情又发生了一次。不同的是，第一次恢复紧急恢复花费了一晚上十几个小时的时间，全部恢复大概花了一周时间，第二次全部恢复花了两个小时。

另外的一个事情就是zabbix server版本升级，仅仅是从 4.4.0升级到4.4.10花费了大约一周时间，各种测试，各种升级回滚解决问题。当然这也和当前的部署结构有关系，结构不合理，负载不均衡等等。

这个月主要就耗费在这里了。

针对zabbix 总结一下，有以下的优点：

1、监控模版可以包含多个指标，在不涉及脚步等其他方式的情况下，使用snmp、zabbix agent 的情况下可以做到开箱即用。

2、指标和触发器（zabbix的告警规则叫触发器）的关联交互挺好用

3、宏和宏变量的使用可以大大的提交告警的便捷性，基本可以做到每个label 不同的阈值。

4、zabbix 的指标采集挺丰富的，包括采集间隔，是否要一直采集还是每天固定时间段来采集。

5、zabbix 的管理页面，这个不愧是企业级软件去，很大一部分的优势是靠它来体现的。

说完了优点来看看缺点：

1、zabbix 架构原生是单点，没有集群方案，官方推荐的是使用keepalived 来进行3个点的负载均衡，这个方案在现在来说太落后了。

2、zabbix 的数据存储使用关系型数据库，这是个很大的问题，当指标数量增加以后，数据的存储空间、查询时间都变成了一个恐怖的事情。当前使用了6TiB的空间来存储了每帧80万条数据，采集间隔一分钟，详细数据1个月，历史数据大概1年半的数据，prometheus 存储比这个节省多了。当然zabbix 也可以支持更大的数据收集规模，只是不知道资源会按什么比例增长。

3、升级复杂，体验了4.4.0升级到4.4.10以后，升级太麻烦，使用zabbix 你最好配一个DBA 来处理各种问题。

4、zabbix 和 grafana 的结合不太好，语句写起来挺生硬的，也能用，但是不如promrthrus 灵活。

对于prometheus 这个月我也做了例行升级，大概花了一个小时左右，我升级完了十多个实例，配套的Thanos 和存储数据的Minio。和zabbix 相比，这太让人舒服了。

prometheus 具备以下优点：

1、结构简单，但是可以水平扩展，通过和thanos 结合可以做到无缝的水平扩展。不喜欢thanos 也可以使用自带的联邦功能进行扩展，prometheus 的思想就是：我尽量简单但是好用，剩下的功能尽管放给其他人做

2、采用时序数据库，大大的节省了存储空间，并且提升了查询效率。我使用3TiB 的空间存储了每帧300万条数据，30秒采集一次，大约有120万条数据是15秒采集一次，详细数据存2个月，5分钟降准数据存半年，一小时降准数据存一年，而且我还不需要DBA 参与。

3、采集配置简单，简单配置以后就可以收取丰富的指标，不用自己一个指标一个指标的添加。

对于prometheus 的缺点，

1、当前告警规则无法快捷的支持每个label 一个阈值，要么统一阈值，要么一个label 一条规则，量大了以后真的不好管理。大家如果这方面有什么好的办法还请指导我一下。

其他感觉和zabbix 比起来没啥缺点了。

总体来说，我更偏向于prometheus ，你们呢？

2021 年 9 月 29 日 23：00 于火车上。