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

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

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

本次分享的是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的角色定位,阐述了二者的关系,更引申出了日后监控系统的目的及其可持续性的成长方式。当然运维并不是脱离了这些就没法干,而是在合适的阶段选择适当的工具,保证业务的可靠性

来源:木讷大叔爱运维

人已赞赏
阅读

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

2020-12-19 22:40:56

阅读

亚马逊 CTO 预测2021:八大技术趋势改变世界

2020-12-19 22:45:56

此心远送浑河岸,斟别酒,唱阳关,临别无语空长叹,酒已阑,曲未残,人初散,心长怀去后,杳鱼雁,对遥山,当时无计锁雕鞍,去后思量悔应晚,别时容易见时难!
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索