像MIUI一样做Zabbix二次开发（5）——那些坑和优化方向

踩过的那些坑

从2011年开始玩Zabbix，踩过的坑着实不少，被研发的同事吐了无数槽，所谓“情到深度又爱又恨“。以下简述印象比较深刻的几个坑：

二次开发的方式：2011刚开始做的时候，我们直接修改Zabbix开源的源代码，实现了一些功能自以为做得还不错，但是后来Zabbix升级一个大版本，发现Zabbix做的比我们高明多了，所以之后，我们都尽量不去Zabbix的源码，动也只是做操作层面的改进，用户交互的改良。

模板：一开始我们想得很简单，网上收集一堆模板，这个事就算做完了，后来发现这只是个开始，默认的模板考虑的深度还不够，需要持续改良和积累。

不必要的Item：在做IT基础架构监控的时候，尤其是网络监控的时候，对于Item的启用对于指标收集的及时性和数据容量的控制至关重要，一开始我们几乎启用了所有Item，后来发现监控的效率和数据库日增量实在让人受不了，最后，想办法压制了一些很少被用到的Item，改进的效果非常明显。

Oracle的监控：用原生的Orabbix监控Oracle时，会有些问题，比如说常见的审计问题，需要DBA持续优化。

数据清理的问题：Zabbix默认配置了Housekeeping来清理数据，但是根据我们的经验，在执行清理的时候除了影响数据库运行，还有约15%的系统资源的损耗，因此，我们默认关闭了这个功能，将这个功能脚本页面化了。

其他问题：

监控频率无法做到秒级别

web拨测只支持get和post，中文乱码

脚本下发只支持shell，并且搭配告警等触发，无法手动

IPMI轮训存在延时

告警有时会无法自动恢复

SNMP监控请求一个监控项一个连接请求

… …

常见优化的方向

以下简单列举我们的常见优化的几个方向：

高可用部署：高可用部署依赖可预见的监控规模和组织对监控系统的重视程度渐次加强，最简单的起码做到Web和DB的分离；其次，做到数据库层面的高可用；然后，分布式代理，甚至代理层的高可用；然后，考虑Web层的负载，最后，有条件的可以加一层冷备。

数据库优化：Zabbix的数据库优化是被提到最多的，通常矛盾最突出的也是MySQL的性能，通常的解决办法是：表分区；优化Item；多采用主动方式采集；Housekeeper优化；优化触发器表达式；数据库主从，Proxy模式；Zabbix配置文件调优；分表；提高机器配置（SSD）。

数据库监控：上一节提到Oracle监控的坑，其他数据库也一样，多采用自己可控的监控方式。

链路监控：单独把链路监控提出来，对于一些有分支机构的组织来说显得尤其必要。

历史数据存档与清理：通常限定详细监控数据的保存时间，只保留趋势数据，转存或清理历史数据，我们采用脚本页面化的方式实现。

监控平台的自监控：监控Zabbix本身的状态