监控系统改造

因为害怕被人误解,你把自己过得很卑微。

先说说我们遇到的主要几个大问题

  • 监控系统收集设置的 trigger 过多,同一时间触发的很多
  • 触发 trigger 后的 action 就算是设置的报警分层明细,也耐不住数量级过大,所以收到的短信或者微信巨多,根本没法处理,报警处理不及时
  • 升级 zabbix 3.0+ 后没有对应的 zatree 展示控件对应新版本,没法查看更加人性化或可定制化的展示界面

当然还有其他小问题,但是都没有上述列出来的需求迫切,所以围绕着这几个需求我们罗列了几个我们认为重要的可备选方案

监控系统改进

1.1 数据收集

  这部分我们还是选择 zabbix 的的收集机制,毕竟我们这里的环境虽不是特别大的量,但是不同的云厂商,国内外的环境都包含在内,所以 zabbix server、zabbix proxy、zabbix agent 的机制能很好的解决网络上的问题,且丰富的配置参数和简单的界面操作,相比自己实现,要容易也稳定许多,我们仍旧打算采用 zabbix 来收集数据到 mysql

1.2 告警

  这部分是我们的重灾区,报警开始需要分级发送机制,所以设定了很多发送 action 的条件,但是仍旧是不能解决问题过多的情况,所以针对这个情况,我们放弃了 zabbix 自身的触发 action 的机制,不再设置 action。换做我们自己进行读 zabbix 库,取出我们需要的数据在另一个系统里进行筛选,合并,过滤,最后只发送一条信息,后续出现相同问题,不再重复发送,这称之为报警收敛,这部分目前打算先以仍旧以 python 程序读取 mysql 的内容再次进行处理

1.3 数据展现

  这部分一个没有告警重要但是可以让监控系统更加人性化的组成部分,在性能方面需要大量的历史数据进行对比,目前的情况 zabbix 的原生 graph 和 screen 是满足不了更多的定制需求,鉴于之前使用过 grafana 的缘故,grafana 更新到 3.0 后对我的吸引力也更大,所以暂定展现使用 grafana 来提升一下监控系统的逼格,毕竟目前我们对展现和前端自己完全自定义不具备条件和技术能力

1.4 项目遇到的问题和难点

  • 首先对 zabbix 的 mysql 库了解并不深刻,大致看过表结构,但是了解并不够透彻,需要加深了解,因为取出对应的数据就得能写出对应的 sql;
  • 对 zabbix mysql 里捞出来的数据进行分组处理,从未做过相关的项目,缺乏具体细节的实现;
  • 展现层 grafana 算是一个独立的知识点了,包括安装,进阶使用,优化,API,到最后的自动部署等,得需要一段时间来熟悉;

上述苦难点一个个的克服,但是昨天无意玩 zabbix 3.0 有个意外收获

zabbix 3.0 的 debug 模式下,可以看到了查询数据的 sql 语句,这对我们现在想捞数据来说帮了大忙了

  
项目的后期实现思路我会陆续更新,愿和小伙伴一起学习一起进步

参考阅读