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

这是我参与8月更文挑战的第3天。mysql

简述

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

所以接下来一段时间，我可能会陆续分享运维过程当中对一些问题的思考，但愿给你们带来必定的启发。sql

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

现状

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注册，这些都已经过蓝鲸标准运维打通；到监控系统，咱们只是经过自动发现添加主机基础监控，而后再经过系统上线时自动添加端口监控和业务监控，彻底忽略了业务分组，只能经过后期人工维护。tcp

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

（1）性能不足的缘由不是一次性致使，而是随着监控项不断增多而引发的连锁反应，所以咱们须要对每一个层次使用提早作好分级的模板，自动下发匹配模板，避免各级人员由于对监控理解不足致使系统性能突发性降低。此种状况只是避免了监控系统的突发性降低，并不能完全随着时间推移的性能降低。（2）zabbix虽然在必定程度上知足了咱们的大部分需求，可是咱们经过其余监控工具和zabbix的互补来分担其性能，如：工具

grafana，咱们能够将部分的告警源接入到grafana；
alertmanager，经过更高级的告警管理手段，能够有效解决咱们的一部分告警方面的问题；
Cacti，将网络层面的监控控交给更正专业的网络监控工具；
Prometheus，实现容器层面的监控；
ELK，实现应用流量方面的监控；
APM，实现链路跟踪等；

所以咱们的监控必定是一个多种监控工具融合的平台，而并不是彻底靠Zabbix覆盖全部的监控需求，这是不显示的。性能

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个客观事实

企业监控治理的目的是为了及时发现问题、解决问题、直至预测问题，不是为了整合监控系统；
企业it架构如今很复杂，将来更复杂，难以经过1-2个监控产品就解决全部监控诉求；也不存在这样的产品和厂商，必然各有所长；
新的业务、系统和场景催生新的监控需求（如：容器），企业将来监控必定是多种监控产品并存，构建功能可持续成长的监控平台势在必行；

总结

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