蓝鲸6.1 CMDB 事件推送的开源替代方案

本文来自腾讯蓝鲸智云社区用户：木讷大叔爱运维

背景

在蓝鲸社区“社区问答”帖子中发现这么一个需求：

究其原因，我在《不是CMDB筑高墙，运维需要一定的开发能力！》一文中已经介绍，在此我再简单重复下：

• 蓝鲸5.1 自带“事件推送”功能，当配置信息发生变化的时候，实时通知到关联的系统中；
• 蓝鲸6.1 不再提供“事件推送”功能，而是由“监听资源变化事件”的一个 CMDB API 实现，需要我们自行查询；

CMDB 版本的迭代，或许说明老版本的“事件推送”已经不符合蓝鲸的设计理念，作为此功能的对接使用者感同深受：

• 事件推送功能全面性，基本覆盖了CMDB全场景的信息变化；
• 事件推送更类似一个图形化的API，通过界面就让开发者知道该如何使用；
• “简单的背后的逻辑复杂化”，这是在对接事件推送接口的第一感受；
• 由于功能的全面性，意味着数据格式的多样性，对接过程你懂得；

通过对事件推送功能对接过程的回顾以及对替代服务resource watch的使用对比，就非常理解蓝鲸社区推陈出新的做法了！

需求

既然是小伙伴们“插眼关注”的问题，与其等待答案，不如我们自己去寻找答案！

API分析

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

• 在有限的时间内（目前为 3 小时,可能会调整，请勿依赖此时间）为用户提供高可用的数据变更 watch 服务。
• 在有限时间内，用户可以根据自己上一次事件的 cursor(游标)进行事件回溯或者追数据，适用于异常数据回溯，或者系统变更进行数据补录。
• 支持根据时间点进行变更数据回溯，支持根据游标进行变更数据回溯，支持从当前时间点进行数据变更 watch。
• 支持根据事件类型进行 watch 的能力，包括增、删、改。事件中包含全量的数据。
• 支持主机与主机关系数据变化的事件 watch 能力。
• 采用短长链的设计，当用户通过游标进行事件 watch 时，如果没有事件，则会保持会话连接，在 20s 内有事件变更则直接直接将事件推回。避免用户不断请求，同时保证用户能及时的拿到变更的数据。
• 支持批量事件 watch 能力，提升系统吞吐能力。
• 支持定制关注的事件数据字段，满足用户轻量级的 watch 需求。

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

事先先行

对接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环境

conda create -n resource-watch python=3.9
source activate resource-watch
pip install  requests celery pyamqp flower kombu
1
2
3

2.rabbitmq环境

# 安装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:15672
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

1.路由队列

针对不同事件，使用不同的队列

2.运行

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,任务查看
1
2
3
4
5
6
7
8
9
10
11

总结

整个开发过程比较重要的是“对不同事件结果数据的封装”，除了部分开发经验外，就是要不断的试错，这样才能保证我们完成对最终的数据格式的解析，从而更好的匹配下游运维子系统！