需求

当我们费劲千辛万苦走完CMDB选型、资产纳管、流程规范的制定后，是否以为基础设施的管理就高枕无忧了?

当然不是啦!大多数情况下，运维平台是不具备CMDB、多套监控系统、堡垒机共享一套ESB的，因此我们接下来要面临的是在不同运维基础平台间不断切换，以保证所有的资产都要和CMDB中保持同步，来进一步维护CMDB的权威性!

想想这个场景是不是头都大了?而此时CMDB也不会有现成的解决方案提供给你，这时就需要我们根据CMDB的API 去主动探索!

在此，我们以蓝鲸CMDB为例来分析下，其他CMDB产品我们也可按照这种思路去深入了解下!

解决方案

蓝鲸5.1-事件推送

官网：事件推送功能能够实现当配置信息发生变化的时候，实时通知到关联的系统中，目前支持 HTTP 的推送方式。支持创建事件推送和事件推送状态查询等。

通过对事件推送功能，我们梳理出：

事件推送，通过业务、模块、资产的一些列动作触发调用回调接口。我们可以获得cmdb变更的相关信息，如：资产ip、业务、模块等信息。

事件推送依赖一个目标系统，用于接收HTTP请求的接口，我们将此接口定位为事件推送网关，需要自行开发。通过事件推送网关，然后接受cmdb推送的资产、业务、模块信息在zabbix、jumpserver创建相关的分组，并将资产ip分配到关联分组中，此时就可以保证和cmdb的业务拓扑一致。

最终我们的解决思路：

配置cmdb事件推送，定义触发动作及回调接口;

自行开发事件推送网关，用于接收cmdb的推送信息，实现与监控系统、堡垒机等运维管理工具进行同步;

其中自行开发的事件推送网关通过python3.9+django3.2+redis来实现。

具体的思路历程大家可参考以下文章：

《事件推送网关：让cmdb告别“花瓶”》

《事件推送网关: “让基础设施建设动起来”》

《运维思索：cmdb打通zabbix、jumpserver探索》

蓝鲸6.1-监听资源变化事件

蓝鲸6.1版本中取消了对事件推送的功能，但是API文档中新增加”监听资源变化事件“接口， 可监听系统资源变化产生的事件。

「该 watch 功能的主要特性包括：」

在有限的时间内(目前为 3 小时,可能会调整，请勿依赖此时间)为用户提供高可用的数据变更 watch 服务。

在有限时间内，用户可以根据自己上一次事件的 cursor(游标)进行事件回溯或者追数据，适用于异常数据回溯，或者系统变更进行数据补录。

支持根据时间点进行变更数据回溯，支持根据游标进行变更数据回溯，支持从当前时间点进行数据变更 watch。

支持根据事件类型进行 watch 的能力，包括增、删、改。事件中包含全量的数据。

支持主机与主机关系数据变化的事件 watch 能力。

采用短长链的设计，当用户通过游标进行事件 watch 时，如果没有事件，则会保持会话连接，在 20s 内有事件变更则直接直接将事件推回。避免用户不断请求，同时保证用户能及时的拿到变更的数据。

支持批量事件 watch 能力，提升系统吞吐能力。

支持定制关注的事件数据字段，满足用户轻量级的 watch 需求。

链接：https://bk.tencent.com/docs/document/6.1/190/14399

通过对以上功能的分析，我们梳理出：

监控的资源类型，包括：业务、集群、模块、主机关联等事件;

以上每种事件动作类型，又分为create(新增)/update(更新)/delete(删除) ;

相较于蓝鲸5.1的事件主动推送，蓝鲸6.1需要「依赖外部自定义的服务来获取不同事件的动作」，进而封装统一的数据格式来和其他工具集成。最终我们的解决思路：

开发框架python3.9+celery+rabbitmq;

celery实现按不同定时间隔需求，执行对业务、集群、模块、主机关联等事件的监控;

rabbitmq通过交换机、路由、队列分别保存celery调度的任务;

封装统一的数据与其他运维系统进行资产同步;

难点：celery默认的日志格式很不友好，无法有效定位调试过程中的报错。因此我们需要重新定义celery的日志打印格式，满足程序运行错误的定位。

总结

要想实现真正的资产流动，光有CMDB是远远不够的，而是要基于CMDB的开放式API去和运维系统、基础架构支撑系统不断的去融合，形成一个良性的闭环，才能够发挥CMDB的真正价值。而在此过程中我们要做的是什么呢?

通过服务的使用而不是维护，来保证CMDB的权威性;

运维要有一定的开发能力去融合，来保证资产流动的持续接入;

最好懂一点架构的东西，可以让我们开发过程事半功倍;

看到这大家或许会明白，CMDB的建设其实并不是要高谈阔论、高瞻远瞩，而是要有“兵来将挡，水来土掩”的信念将需求一点点解决好，成功没有捷径!