运维思索：cmdb与zabbix监控系统的融合

读完需 9 分钟

速读需 4 分钟 

各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。

因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。

本次分享的是cmdb与zabbix监控系统的融合。

现状

1

维护不足

（1）当前运维环境下，监控系统比较独立，需要手动进行分组、创建模板、添加监控等一系列操作；而且随着主机、业务不断增多，分组已经严重脱离当前业务分组、架构分组等；
（2）部门多人协作，沟通协调不足，导致监控系统混乱，虽然当前监控系统指定了一些列维护规范，如：命名、监控间隔、故障分级等；但是监控仍然混乱；

2

性能不足

（1）随着server越来越多，监控覆盖基础监控、网络监控、业务监控、日志监控等；监控的细节需要不断放大，势必会导致监控的性能下降；因此需要通过调整被动为主动、监控分级、监控间隔等一些优化；
（2）网络抖动或其他因素导致的告警泛滥、误报警，给运维人员带来不必要的麻烦，因此需要告警收敛来避免；

3

融合不足

（1）目前通过蓝鲸标准运维实现虚拟机到jumpserver、cmdb的交付；到zabbix监控系统的交付依靠zabbix的自动发现主机，即主机的基础监控；cmdb没有和zabbix打通；
（2）端口监控和业务监控是通过“系统上线流水线”来自动添加到监控系统；业务无法映射到zabbix；
（3）zabbix和蓝鲸故障自愈打通，可以基于cmdb进行自愈；

思考

1.维护不足的问题为何发生？

从server的上架流程出发，在server上架前我们已经确定此server部署什么业务、此业务的端口及url。在上架过程中我们需要经过操作系统安装、jumpserver添加、cmdb注册，这些都已通过蓝鲸标准运维打通；到监控系统，我们只是通过自动发现添加主机基础监控，然后再通过系统上线时自动添加端口监控和业务监控，完全忽略了业务分组，只能通过后期人工维护。

2.性能不足问题为何发生？

（1）性能不足的原因不是一次性导致，而是随着监控项不断增多而引起的连锁反应，因此我们需要对每个层次使用提前做好分级的模板，自动下发匹配模板，避免各级人员因为对监控理解不足导致系统性能突发性下降。此种情况只是避免了监控系统的突发性下降，并不能彻底随着时间推移的性能下降。
（2）zabbix虽然在一定程度上满足了我们的大部分需求，但是我们通过其他监控工具和zabbix的互补来分担其性能，如：

• grafana，我们可以将部分的告警源接入到grafana；

• alertmanager，通过更高级的告警管理手段，可以有效解决我们的一部分告警方面的问题；

• Cacti，将网络层面的监控交给更正专业的网络监控工具；

• Prometheus，实现容器层面的监控；

• ELK，实现应用流量方面的监控；

• APM，实现链路跟踪等；

因此我们的监控一定是一个多种监控工具融合的平台，而并非完全靠Zabbix覆盖所有的监控需求，这是不显示的。

3.cmdb和zabbix的融合不足为何发生？
cmdb在监控系统中扮演的角色是什么？如果只是资产管理，那cmdb在企业中的角色将会不断弱化，最终成为鸡肋。因此我们需要将cmdb作为一切运维系统的数据支撑，当然也包括监控系统。那么融合不足的问题也就找到了，就是cmdb没有在监控系统中起到数据支撑的作用。

展望

1.融合cmdb

cmdb打通到监控系统的通道，在新的对象加入CMDB的时候能够自动将该对象加入监控系统；同时在配置数据发生变化的时候，能够通过监控系统发出必要的告警信息；
如机器上线，则自动注册到cmdb；业务变更，自动注册到cmdb；角色变更、停机维护也要变成cmdb。此时监控系统只需要维护好相应的规则，即可让监控自主添加，从而弥补自动发现的不足；同时灵活性大大增强，只要cmdb获取到设备的相关信息和状态，然后主动更新监控系统，并且纠正以前添加好的但没有持续更新的监控。

2.cmdb数据支撑

cmdb需要为监控系统提供必要的支撑数据，来立体化、标准化告警信息；
这个怎么理解？通常情况下我们收到zabbix监控系统的信息只是“XX对象的XX指标告警和详情信息等”，但是我们不知道这条告警信息属于应用系统、哪个环境、是否高可用、应用负责人是谁、哪些系统依赖它、是否进行过变更，以便运维能够做出进一步的判断和安排。那么这个时候，我们就需要一个系统能够提供：应用层次拓扑、集群信息、模块信息、资源实例、关联关系等信息，这个系统就是CMDB。

通过以上两者的结合在告警发生的时候呢，我们就可以让告警系统前往CMDB中查询跟这一告警对象有关的综合配置信息，以便提供最为准确、丰富和标准的告警信息。

解决思路

1.蓝鲸监控、zabbix、grafana多监控系统互补运行

• a.蓝鲸监控有融合cmdb的天然优势，而且已经内存tcp监控、nginx、mysql等各组件监控，覆盖了目前生产环境使用的开源工具；因此可以用来实现业务监控、部分基础监控；

• b.zabbix作为基础监控、网络监控、硬件监控、vsphere监控等蓝鲸监控不具备的；

• c.grafana+elk+alertmanager用来作为可视化监控工具，利用其收敛的特点进行应用运行状态方面的监控；

2.统一数据源
顾名思义，监控需要cmdb作为统一的数据源，但是在多套系统共存的情况下，就需要我们有强大的API整合能力。此时需要在系统内部选择一个具有良好整合能力的切入点，例如蓝鲸的标准运维，实现不同平台的API调用。

延伸

关于监控系统的3个客观事实：

1. 企业监控治理的目的是为了及时发现问题、解决问题、直至预测问题，不是为了整合监控系统；

2. 企业it架构现在很复杂，未来更复杂，难以通过1-2个监控产品就解决所有监控诉求；也不存在这样的产品和厂商，必然各有所长；

3. 新的业务、系统和场景催生新的监控需求（如：容器），企业未来监控一定是多种监控产品并存，构建功能可持续成长的监控平台势在必行；

总结

本文从zabbix监控的现状及cmdb的角色定位，阐述了二者的关系，更引申出了日后监控系统的目的及其可持续性的成长方式。当然运维并不是脱离了这些就没法干，而是在合适的阶段选择适当的工具，保证业务的可靠性 。

参考：
# 1.当cmdb遇上zabbix，工程师的幸福感提升？
https://yq.aliyun.com/articles/426766
# 2.如何改善监控，试试打造企业一体化监控平台体系
https://mp.weixin.qq.com/s?__biz=MzI4MDE2OTU1OA==&mid=2649528696&idx=1&sn=b07bf715608a7bebdf6302ac8f0ae2c6&chksm=f3a4a441c4d32d575637352a2e9e0de159f1bf6ffce5dc1f5523a3958e8fe5f27de88565d67a&token=1567794534&lang=zh_CN&scene=21#wechat_redirect
# 3.运维思考：你知道cmdb与监控是什么关系吗？
https://mp.weixin.qq.com/s?__biz=MjM5NTcxMTE2Nw==&mid=2653118841&idx=1&sn=4d6e1721be3fbe7fbf0c121eea7ac3dd&chksm=bd2390a98a5419bfa18e444a0d57ec9c06c6918cd5e5e9343d2fdc88a646c477ec93b53c93c7&mpshare=1&scene=1&srcid=&sharer_sharetime=1576718962737&sharer_shareid=5d7a84a63006a403569777456f05a0b4#rd

关注我们