---

《ZABBIX全栈级监控实践》系列将由浅入深探讨如何实现ZABBIX全栈级别的监控。

本文是《ZABBIX全栈级监控实践》的第六篇：主要讨论IT监控产品的选型以及Zabbix在该领域的优势。

---

一、概述

很抱歉，由于种种原因，很久没有更新这一系列了。

本章讨论的是如何在企业中选择一个合适的IT监控产品和Zabbix在监控产品中的优势。原本的写作计划中，并没有想到写这一主题。之所以想到写这篇与技术面关系不是特别大的“软文"，主要是因为身边有越来越多的人在问我类似的问题：你为什么用Zabbix？有没有Zabbix和其他产品的比较？诸如此类……

在2017年11月24日的Zabbix Conference上海站里，和Zabbix SIA公司的CEO Alexei先生，以及商务总监Sergey先生畅所欲言，更让我觉得用必要为正在进行IT监控产品选型，或者刚入门Zabbix的同学们分享下。本文会以一个中立的角度进行阐述，欢迎拍砖。

先问问大家，下列监控中类似的痛点是否遇见过？

1、一个系统挂了，发现没有监控，原来是因为人工一个个遗漏了。（监控人工添加导致遗漏）

2、有100台服务器，每台上有5-10个磁盘都要监控他们的磁盘空间、读写速度等指标，需要一个个加入到监控系统中。（同一类的监控对象需要重复添加）

3、一台服务器挂了，结果虚拟机、网络、宿主机都报故障。（无法定位root cause）

4、希望监控一些业务指标，却发现没有方法可以监控。（无法实现个性化监控）

…… …… ……

二、监控解决方案的分类和比较

市场上各种各样的厂商提供着自己的监控解决方案，基本上可以分为三类：

第一类为针对专业平台的解决方案，如微软的System Center Operations Manager，IBM的Tivoli，VMware的vRealize Operations Manager等。

优点1：这一类的解决方案一般由对应平台的厂商直接提供。因此对于自己所属的平台监控无微不至。

优点2：企业级支持，原厂提供服务。一般都是久经考验的监控平台，稳定性较高。

劣势1：对于其他平台的监控，也许或多或少能够做一些，但可能存在各种限制甚至无法实现：如使用微软的SCOM监控linux。

劣势2：存在license费用，各种各样的收费规则（按CPU核数，按用户数，按设备数，按流量）。

劣势3：由于是商业软件，源码不公开，个性化定制较差。

第二类为开源的解决方案，如Zabbix，Nagios，Cacti等。这一类的监控解决方案由公司或者社区提供开发及支持。

优点1：免费！不要钱！一般而言都是license-free。

优点2：开源，自主可控。可以进行源码定制，已满足企业需求。

优点3：相对原厂的监控平台，功能相对更为全面。同时也提供一些标准的API。

劣势1：对部署和运维的IT人员要求较高。可能存在各种坑，大多数情况下需要自行解决。

劣势2：可能没有商业支持。随着时间演进，该产品可能没有社区进行进一步维护。

劣势3：文档少，中文文档更少。对英语要求略高。

另外，部分厂商会在这一类产品的基础上，包装自己的WEB前端UI，而底层仍然使用该平台原有的功能，以新瓶装旧酒的方式提供自己的解决方案，也可以归纳为此类。

第三类为自研的解决方案，如小米的Open Falcon，大众点评的Central Application Tracking等。这一类的监控更多的诞生于互联网企业，部分后续进行了开源。

优点1：符合当前最新的互联网架构和监控需求。

优点2：开源免费。

劣势1：同上述第二类开源软件的所有劣势。

劣势2：由于并没有进行过长期的时间运行，稳定性有待考证。

三、寻找最合适的监控解决方案

所有的厂商都会推介自己的解决方案。那么如何在种类繁多的解决方案中选择最符合自身企业的解决方案呢？

本系列的第一章中提到监控的深度和广度。选择方案时可以从这两个角度进行权衡。

单就深度而言，可能Zabbix无法和其他解决方案相抗衡。比如很多外企会使用全套的微软平台，从Exchange邮箱，Lync通信，Sharepoint协作，SQL数据库，Windows桌面和服务器操作系统……如果此时用Zabbix去监控，未必是最合适的。微软的System Center Operations Manager有着强大的经验沉淀和知识库支持，会更加适合这些企业的监控环境。

一些监控解决方案深度与广度的比较

而在现在越来越多的企业的IT环境中，异构的情况越来越明显。同时存在多个平台，多个品牌的情况越来越多。当然，我们可以使用多套监控平台进行监控。对Ｗindows使用SCOM来进行监控，对VMware使用VRops进行监控，对网络用Solarwinds监控，诸如此类。但使用多个平台进行监控，势必会导致监控重复、监控遗漏等状况的出现，从而使得监控噪音或者监控缺失等等。

Zabbix正是解决这一问题的利器。它在确保一定监控深度的同时，有着非常好的广度和延展性。可以作为一个统一监控平台的解决方案。

四、为什么选择Zabbix？

开源：社区支持，模板分享

免费：无商业版和社区版之分，无license授权费用

全栈级：从上层应用，到操作系统，以及底层硬件都可实现统一监控；支持Agent，WMI，SNMP，IPMI，JMX等监控方式

可扩展：用户可自定义监控项、丰富的API接口可被其他平台调用

分布式：通过Proxy以支持跨区域、跨地域的分布式监控

企业级：每秒可以收集上万个指标，未来的4.0版本在极限的情况下每秒可以收集40万个指标。

Zabbix的一些特性，也大大提升了系统监控的效率。

我们先看看对于文章开始提到的一些监控痛点，Zabbix如何解决？

监控人工添加导致遗漏：

Zabbix提供网络发现功能，结合网络发现功能和网络发现行为，可以自动为网络上存在的Host添加监控，并套用对应模板。

同一类的监控对象需要重复添加：

Zabbix提供低级别发现（LLD）功能，自动发现Host上同一类的对象（如所有的磁盘，所有的网卡等），并套用统一的监控项和触发器，无需人工重复添加。

无法定位root cause：

Zabbix可以进行Trigger依赖性关联，减少故障时候关联报警，较为快速的定位root cause。

无法实现个性化监控：

Zabbix除了提供传统的Agent，IPMI，SNMP，JMX，WMI等方式的监控，还可以使用用户自定义参数（User Parameter）来实现个性化监控。

除此之外，Zabbix提供如Dashboard，分布式，标准化API等特性和功能，在此不再赘述。详细介绍可参考Zabbix官网 。

五、写在最后

没有最好的监控解决方案，只有最合适的。

Zabbix的广度可以覆盖80-90%的监控需求，剩余的10-20%（如数据库调优、内核故障定位等）还是需要依赖于一些专业的监控工具趋势线。

如果你的企业内部只有单一的一两个平台，那么并不推荐使用Zabbix。但如果存在越来越多的异构环境，可以尝试一些Zabbix。

除了本文提到的一些因素以外，对于学习使用Zabbix的成本（比如需要英语阅读能力，需要掌握基础的脚本语言）、后期运维成本等方面，也需要一并在监控产品选型中进行考虑。

抛砖引玉，希望对大家了解Zabbix和进行监控产品选型有所帮助：）