像MIUI一样做Zabbix二次开发（1）——MIUI之于Android，乐维监控之于Zabbix

摘要

文章主要介绍：7年做Zabbix二次开发，讲述那些从技术方向的选择，到开发、架构设计、深度定制，到我们的更多前瞻性想法。

关于MIUI

“专注、极致、口碑、快“成了雷布斯的口头禅，根植于这样的产品文化，小米的MIUI基于Android开源系统实现的贴近中国用户使用习惯的手机操作系统，简单总结MIUI的做法：

1. 替代Google服务体系的小米云服务体系，这些云服务体系更全面，更好用，更接地气，更符合中国普通消费者使用习惯；

2. 以周为单位的快速迭代；

3. 以论坛为中心的粉丝交流社群

4. 界面更美观；

5. 细节更人性化。

总之，用MIUI你会发现，你能想到的能用到的，它已经很好地躺在那里了，你有一种被无微不至地呵护着的感觉。在国内用原生的Android系统都属于一些玩主，技术极客，我曾经也是，试过各种Rom，MIUI是其中的佼佼者，甚至，在xda-developers上发现国外还有一批忠实米粉。

是的！我们正在一步步学习着MIUI，在此，向小米，向雷军献上我们的膝盖！

为什么选择Zabbix

为什么要做监控

运维的正确姿势肯定不是从处理故障开始，一定是从监控开始的。

从军事的角度出发，监控是一种积极防御战略，是未战之战，有效的监控可以拓宽战略纵深，可以更积极地保护我重点军事目标。以下是我们要求运维团队时时牢记的两句话。

1. 出了任何故障，其他环节都可能有问题，唯独监控环节一定有问题！

2. 海恩法则：每1起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。

 

IT服务成熟度模型中，监控手段是转被动运维为主动运维的必然“预防“和”度量“手段。因此，在这么多年的重大故障分析会议上，监控问题总是在会议前期和后期都拿出来重点讨论的，

会议一开始就要问“为什么故障没有被监控出来”或者”在故障发生的前后都监控出来什么异样“。

会议结束前的总结通常是“对于漏掉的监控项一定要被加入“或者是”对于监控到的指标或阀值一定要被优化“。

如果这四个问题都被很好地回答并改善，我想下次类似的故障是不可能出现的，因此，做监控需要有一个PDCA持续改进的过程，当然，改进的核心有且只有两个“覆盖率“和”准确率“。

当然，对于一个更优秀的监控系统，他还可以有如下价值：

对组织：

1. 全局监控帮助组织制定IT管理战略

2. 从IT资源到组织业务的直接对接

3. 制定IT资源、IT组织工作管理的基础

4. 组织与内外部IT组织的沟通枢纽

对IT管理者

1. IT管理者工作价值体现

2. 帮助IT管理者全面了解IT现状

3. 方便IT管理者管理IT组织的工作绩效

4. 搞高IT部门的工作效率，减少企业成本

5. 降低业务系统宕机风险

对IT操作者

1. 及时发现业务系统各个单元故障

2. 深度定位系统的故障根源，及时解决

3. 拉近IT操作者与组织业务的距离

4. 直接体现具体IT操作者的工作业绩

5. 帮助从IT的角度提高促进业务高效稳定

为什么是Zabbix

前不久看到一则路边社报道，在中国有80%的企业在使用Zabbix做监控，不知道统计的方法和口径是怎样的，不过，80%这个数值也感性地传达了他的热度。

统计数据

在Zabbix的官网上找到一个清单，一堆国外知名公司都是他的合作伙伴，就最近的交流沟通中，但凡有计划做监控的组织无不试用Zabbix的，如果有网友有更值得参考的统计数据，可以回复本文，并注明数据来源。

目前，从IT Central Station的官网找到一份统计信息，这份统计数据是由加入这个网站的企业CIO反馈的信息实时得到，以下这份数据是2017年11月18日生成的。

 

 

 

这份统计数据主要来自北美的参与者，在国内没有代表性，不过，我相信在国内的数据会比这个更高，国内对于免费和开源的被教育程度显然是更高，这个得益于红衣教主周鸿祎，更被一堆互联网公司的推高和强化，至于背后的商业伦理和其他成本问题姑且不论。