本文来自腾讯蓝鲸智云社区用户：木讷大叔爱运维
背景
在蓝鲸社区"社区问答"帖子中发现这么一个需求：
究其原因，我在《不是CMDB筑高墙，运维需要一定的开发能力！》一文中已经介绍，在此我再简单重复下：
- 蓝鲸5.1 自带"事件推送"功能，当配置信息发生变化的时候，实时通知到关联的系统中；
- 蓝鲸6.1 不再提供"事件推送"功能，而是由"监听资源变化事件"的一个 CMDB API 实现，需要我们自行查询；
CMDB 版本的迭代，或许说明老版本的"事件推送"已经不符合蓝鲸的设计理念，作为此功能的对接使用者感同深受：
- 事件推送功能全面性，基本覆盖了CMDB全场景的信息变化；
- 事件推送更类似一个图形化的API，通过界面就让开发者知道该如何使用；
- "简单的背后的逻辑复杂化"，这是在对接事件推送接口的第一感受；
- 由于功能的全面性，意味着数据格式的多样性，对接过程你懂得；
通过对事件推送功能对接过程的回顾以及对替代服务resource watch的使用对比，就非常理解蓝鲸社区推陈出新的做法了！
需求
既然是小伙伴们"插眼关注"的问题，与其等待答案，不如我们自己去寻找答案！
API分析
该 watch 功能的主要特性包括：
- 在有限的时间内（目前为 3 小时,可能会调整，请勿依赖此时间）为用户提供高可用的数据变更 watch 服务。
- 在有限时间内，用户可以根据自己上一次事件的 cursor(游标)进行事件回溯或者追数据，适用于异常数据回溯，或者系统变更进行数据补录。
- 支持根据时间点进行变更数据回溯，支持根据游标进行变更数据回溯，支持从当前时间点进行数据变更 watch。
- 支持根据事件类型进行 watch 的能力，包括增、删、改。事件中包含全量的数据。
- 支持主机与主机关系数据变化的事件 watch 能力。
- 采用短长链的设计，当用户通过游标进行事件 watch 时，如果没有事件，则会保持会话连接，在 20s 内有事件变更则直接直接将事件推回。避免用户不断请求，同时保证用户能及时的拿到变更的数据。
- 支持批量事件 watch 能力，提升系统吞吐能力。
- 支持定制关注的事件数据字段，满足用户轻量级的 watch 需求。
链接：bk.tencent.com/docs/docume...
事先先行
对接CMDB属于事件驱动，因此事件先行，先来分析通过API都能获取哪些事件：
- host 代表主机详情事件
- host_relation 代表主机的关系事件（主要使用）
- biz 代表业务详情事件
- set 代表集群详情事件
- module 代表模块详情事件
- process 代表进程详情事件
- object_instance 代表通用模型实例事件
- mainline_instance 代表主线模型实例事件
- biz_set 代表业务集事件
- biz_set_relation 代表业务集和业务的关系事件
以上事件未必都能用到，我们只要按需获取即可，这也体现了watch服务的灵活性！
动作其次
每类事件都有其相应的动作：
- create 创建
- delete 删除
- update 更新
我们的工作重点就是从事件中将增、删、改的动作分离出来，对下游系统进行事件回放，从而保证数据同步。
时间/事件回溯
虽然时间回溯最长间隔为3小时，我们还是希望对不同粒度的事件进行区分，原则如下：
- host_relation 主机关系事件，实时生效；
- module 模块事件，实时生效；
- set 集群事件、biz 业务事件等，可适当在不同时间间隔生效；
时间回溯保证我们能查到历史数据，而事件回溯的cursor游标能够保证我们避免重复的事件。 因此我们对于时间/事件回溯要有一个清醒的理解！
功能需求
通过API的分析，其实我们的功能需求也就同时梳理了出来：
- 核心目标：CMDB驱动资产同步，按业务/集群/模块/主机的结构与下游系统实现关系对应；
- 事件驱动： 1)biz 业务名同步； 2)set 集群名同步； 3)module 模块名同步； 4)host_relation 主机关系同步； 5)其他名称或关系同步；
开发框架
根据"监听资源变化事件"接口的特性，我梳理了下开发过程的几个要点：
- 对于事件的获取、与下游系统同步，这是两个步骤。不需要等待同步完成再去获取事件，要进行解耦 1)事件获取，异步执行； 2)与下游系统对接，同步执行；
- 不同事件变化的频繁度不同，我们要按需获取，因此就需要一个调度器，可自定义调度计划；
通过以上分析，我们初步确认了python + celery + rabbitmq的几个组件：
- celery 用于对不同时间回溯间隔的调度；
- rabbitmq 通过交换机、路由、队列分别保存celery调度的任务；
- python对不同事件结果封装统一的数据与其他运维系统进行资产同步；
其具体的实现流程如下图： 
具体部署
依赖组件
1.Python 3.9 2.Celery 3.Rabbitmq 保存celery调度任务
安装
1.python环境
ini
conda create -n resource-watch python=3.9
source activate resource-watch
pip install requests celery pyamqp flower kombu2.rabbitmq环境
bash
# 安装rabbitmq
yum install rabbitmq-server
systemctl start rabbitmq-server
systemctl enable rabbitmq-server
# 开启 RabbitMQ 的web管理界面
rabbitmq-plugins enable rabbitmq_management
# 创建admin用户并授权
rabbitmqctl add_user admin admin
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p '/' admin '.' '.' '.*'
rabbitmqctl list_users
rabbitmqctl list_user_permissions admin
systemctl restart rabbitmq-server
# 访问rabbitmq管理界面
http://ip:156721.路由队列
针对不同事件，使用不同的队列
| 交换机 | 路由 | 队列 | 备注 |
|---|---|---|---|
| cmdb | cmdb.host_relation | cmdb.host_relation | 主机关联关系事件 |
| cmdb | cmdb.module | cmdb.module | 模块事件 |
| cmdb | cmdb.set | cmdb.set | 集群事件 |
| cmdb | cmdb.biz | cmdb.biz | 业务事件 |
2.运行
css
cd /app/resource-watch
# 启动beat，将定时任务发送至worker
celery -A celery_cmdb beat -l INFO --detach
# 启动worker，异步执行任务，绑定相应事件队列
celery -A celery_cmdb worker -Q cmdb.host_relation -l INFO -c 1 -D
celery -A celery_cmdb worker -Q cmdb.module -l INFO -c 1 -D
celery -A celery_cmdb worker -Q cmdb.set -l INFO -c 1 -D
celery -A celery_cmdb worker -Q cmdb.biz -l INFO -c 1 -D
# 启动flower,任务查看总结
整个开发过程比较重要的是"对不同事件结果数据的封装"，除了部分开发经验外，就是要不断的试错，这样才能保证我们完成对最终的数据格式的解析，从而更好的匹配下游运维子系统！