本文主要是介绍事件推送网关：让cmdb告别“花瓶”，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前言

众所周知cmdb在运维过程中的重要性，但是我们不希望它是一个“花瓶”，因此《运维思索：cmdb打通zabbix、jumpserver探索》成了我们当前面临的一个课题。而我们可以借助cmdb的事件推送来解决此问题，因此引入了事件推送网关。

事件推送网关是蓝鲸cmdb事件推送的一个目标系统，当cmdb中配置信息发生变化时，会实时通知到事件推送网关，由网关统一关联到各运维子系统，如jumpserver、zabbix等，实现配置信息的一致性同步，为上层应用做好数据支撑。

各系统的一致性同步的前提是所有的配置信息来源为cmdb，这就要求资产配置必须通过cmdb配置，由事件推送统一同步，而不是在各系统手动配置（仅指资产分组等基础配置），否则最终将打破一致性同步，此时cmdb将走上“花瓶”之路。

解决方案

在正式使用事件推送网关前，我们需要了解cmdb各种事件推送发出的HTTP请求区别，以便我们的网关做出相应的操作。

1.开发框架

事件推送网关是通过python3.9+django3.2开发，用于cmdb事件推送进行回调。

# 1.python环境
conda create -n gateway python=3.9
source activate gateway
pip install django redis 

# 2.创建项目
django-admin startproject gateway
cd gateway
python manage.py startapp gw_cmdb

# 3.settings配置
vim gateway/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # 添加app
    'gw_cmdb'
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 关闭csrf验证
    #'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

# 4.日志配置（默认在项目目录gateway下logs目录下）
cur_path = os.path.dirname(os.path.realpath(__file__))  # log_path是存放日志的路径
log_path = os.path.join(os.path.dirname(cur_path), 'logs')
if not os.path.exists(log_path): os.mkdir(log_path)  # 如果不存在这个logs文件夹，就自动创建一个 
LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'formatters': {
        # 日志格式
        'standard': {
            'format': '[%(asctime)s] [%(filename)s:%(lineno)d] [%(module)s:%(funcName)s] '
                      '[%(levelname)s]- %(message)s'},
        'simple': {  # 简单格式
            'format': '%(levelname)s %(message)s'
        },
    },
    # 过滤
    'filters': {
    },
    # 定义具体处理日志的方式
    'handlers': {
        # 默认记录所有日志
        'default': {
            'level': 'INFO',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': os.path.join(log_path, 'all-{}.log'.format(time.strftime('%Y-%m-%d'))),
            'maxBytes': 1024 * 1024 * 5,  # 文件大小
            'backupCount': 5,  # 备份数
            'formatter': 'standard',  # 输出格式
            'encoding': 'utf-8',  # 设置默认编码，否则打印出来汉字乱码
        },
        # 输出错误日志
        'error': {
            'level': 'ERROR',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': os.path.join(log_path, 'error-{}.log'.format(time.strftime('%Y-%m-%d'))),
            'maxBytes': 1024 * 1024 * 5,  # 文件大小
            'backupCount': 5,  # 备份数
            'formatter': 'standard',  # 输出格式
            'encoding': 'utf-8',  # 设置默认编码
        },
        # 控制台输出
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'standard'
        },
        # 输出info日志
        'info': {
            'level': 'INFO',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': os.path.join(log_path, 'info-{}.log'.format(time.strftime('%Y-%m-%d'))),
            'maxBytes': 1024 * 1024 * 5,
            'backupCount': 5,
            'formatter': 'standard',
            'encoding': 'utf-8',  # 设置默认编码
        },
    },
    # 配置用哪几种 handlers 来处理日志
    'loggers': {
        # 类型 为 django 处理所有类型的日志， 默认调用
        'django': {
            'handlers': ['default', 'console'],
            'level': 'INFO',
            'propagate': False
        },
        # log 调用时需要当作参数传入
        'log': {
            'handlers': ['error', 'info', 'console', 'default'],
            'level': 'INFO',
            'propagate': True
        },
    }
}

2.目录结构

D:\work\blueking>tree /f gateway
└─gateway
    │  manage.py
    │
    ├─gateway
    │  │  asgi.py
    │  │  settings.py
    │  │  urls.py
    │  │  wsgi.py
    │  │  __init__.py
    │
    └─gw_cmdb
        │  admin.py
        │  apps.py
        │  models.py
        │  urls.py
        │  views.py
        │  __init__.py
        │
        ├─common 
        │    cmdb.py
        │
        ├─jumpserver（暂未开放）
        ├─zabbix（暂未开放）

其中：

• gateway 为 项目目录；
• gw_cmdb 为app目录；
• gw_cmdb/views.py 为统一接收cmdb事件推送的http请求，并关联其他子系统的模块；
• gw_cmdb/common/cmdb.py 为解析views.py接收 http请求类型的模块目录，返回指定数据格式的参数；
• gw_cmdb/jumpserver 为网关实现jumpserver相关操作的模块总目录；
• gw_cmdb/zabbix 为网关实现zabbix相关操作的模块总目录；

3.部署

# 1.项目路由
vim gateway/urls.py
from django.contrib import admin
from django.urls import path
from django.conf.urls import include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('cmdb/',include('gw_cmdb.urls'))
]

# 2.app路由
from django.urls import path
from . import views

# 统一接收cmdb事件推送的http请求；
urlpatterns = [
    path(r'',views.cmdb_request),
]

# 3.cmdb_request
# 接收cmdb事件推送网关的http请求
vim gw_cmdb/view.py
from django.shortcuts import render
from django.http import HttpRequest,HttpResponse
from .common.cmdb import cmdb
from .zabbix.main import zabbix_main
import json
import logging

logger = logging.getLogger('log')

# Create your views here
def cmdb_request(request):
    if request.method == 'POST':
        data = json.loads(request.body)
        logger.info('cmdb发送消息：{}'.format(data))
        ## 获取指定数据格式的参数
        res=cmdb(data)
        ##是否需要联动zabbix及jumpserver
        if res['result'] == 1:
            return HttpResponse("ok")
        else:
            logger.info(res['data'])
            #zabbix
            return HttpResponse("ok")
            #jumpserver
            return HttpResponse("ok")
    else:
        logger.info('本接口只支持POST模式')
        return HttpResponse("本接口只支持POST模式")

        
# 4.启动
python manage.py runserver 0.0.0.0:8000

4.事件推送解析

事件推送网关启动后，我们在蓝鲸cmdb上的操作触发后，cmdb将回调事件推送网关，网关将打印接收的请求：

（1）将主机(10.164.193.138)从“空闲机”转移至“回收计划(集群)”-“未分类(模块)”

查看日志gateway/logs/info-2021-05-21.log

由图可知，cmdb事件推送做了以下操作：

• delete动作：将主机从“空闲机” 删除；
• create动作：在“回收计划”集群中创建主机；
• update动作：在集群中关联相关模块“未分类”，重复2次；

此时，这4个请求request_id相同，而且update动作重复了2次。

（2）将主机(10.164.193.138)追加新模块“nginx(模块)”

由图可知，cmdb事件推送做了以下操作：

• delete动作：将主机从“未分类(模块)” 删除；
• create动作：在“未分类(模块)”集群中创建主机；
• create动作：在“nginx(模块)”集群中创建主机；
• update动作：在集群中关联相关模块“未分类”、“nginx”，重复3次；

此时，这6个请求request_id相同，而且update动作重复了2次。

（3）将主机(10.164.193.138)只删除模块“nginx(模块)”

由图可知，cmdb事件推送做了以下操作：

• delete动作：将主机从“未分类(模块)” 删除；
• delete动作：将主机从“nginx(模块)” 删除；
• create动作：在“未分类(模块)”集群中创建主机；
• update动作：在集群中关联相关模块“未分类”，重复3次；

此时，这6个请求request_id相同，而且update动作重复了3次。

（4）将主机(10.164.193.138)转移至“空闲机”

由图可知，cmdb事件推送做了以下操作：

• delete动作：将主机从“未分类(模块)” 删除；
• create动作：在“空闲机(既是集群又是模块)”集群中创建主机；
• update动作：在集群中关联相关模块“未分类”，重复2次；

此时，这6个请求request_id相同，而且update动作重复了2次。

综合以上4种情况，我们可以得出以下结论：

1. 每次配置变更的流程为：删除(delete)–创建(create)–更新(update)；
2. update的次数=delete次数+create次数；
3. 我们最终关心的结果是update，而不是delete和create，但由于update重复，因此我们需要对update过滤并去重，可借助redis+request_id(后期需要再增加ip信息)作为唯一key去重；

基于update动作的结果，我们可以过滤出真正需要的参数。

参数解析

从日志打印看，update的信息有点冗余，此时就需要对结果进行解析，获取指定的数据格式。

vim gw_cmdb/common/cmdb.py
import redis
import json
import hashlib

r = redis.StrictRedis(host='127.0.0.1',port=6379,db=1)

def cmdb(data):
    ##定义数据格式
    datajson={'key':'','data':{'ip':'','group':[]}}
    ##获取本次cmdb动作id  
    ##判断是为cmdb变动操作
    if data['action'] == 'update':
        for i in data['data']:
            datajson['data']['ip'] = i['cur_data']['bk_host_innerip']
            grouplist = i['cur_data']['associations']
            for j in grouplist:
                groupname = grouplist[j]['bk_set_name']+"_"+grouplist[j]['bk_biz_name']+"_"+grouplist[j]['bk_module_name']
                datajson['data']['group'].append(groupname)
            datajson['key']= hashlib.md5((data['request_id']+ i['cur_data']['bk_host_innerip']).encode('utf-8')).hexdigest()
        rkey = r.hget('cmdb',datajson['key'])
        if rkey is None:
            r.hset('cmdb',datajson['key'],json.dumps(datajson['data']))
            result = {
                'result': 0,
                'data': datajson
            }
        else:
            result = {
                'result': 1,
                'data': datajson
            }
    else:
        result = {
                'result': 1,
                'data': datajson
            }
        return result
    return result

（1）将主机(10.164.193.138)从“空闲机”转移至“回收计划(集群)”-“未分类(模块)”

排除delete、create、update 的动作请求后，就可以得到我们定义的数据格式结果：

{'key': '3005575b6d1b681c236896a8d35d199e', 'data': {'ip': '10.164.193.138', 'group': ['回收计划_回收计划_未分类']}}

（2）将主机(10.164.193.138)追加新模块“nginx(模块)”

排除delete、create、update 的动作请求后，就可以得到我们定义的数据格式结果：

{'key': '3005575b6d1b681c236896a8d35d199e', 'data': {'ip': '10.164.193.138', 'group': ['回收计划_回收计划_未分类', '回收计划_回收计划_nginx']}}

（3）将主机(10.164.193.138)转移至“空闲机”

排除delete、create、update 的动作请求后，就可以得到我们定义的数据格式结果：

{'key': '3005575b6d1b681c236896a8d35d199e', 'data': {'ip': '10.164.193.138', 'group': ['空闲机池_回收计划_空闲机']}}

最后将根据获得指定数据格式的参数，传递给各子系统api用于主机分组配置等基础信息一致性同步，这样就保证了cmdb的统一数据源特性。

守护进程

为保证我们的网关能够自启动，我们使用supervisor进行守护，配置如下：

# 1.安装
yum install supervisor
#开机启动
systemctl enable supervisord
#查看是否开机自启动
systemctl is-enabled supervisord

# 2.配置文件
vim /etc/supervisord.d/gateway.ini
[program:gateway]
;cmdb事件推送wa男公关
;启动用户
user=root
;程序启动命令
command=/usr/local/miniconda/envs/gateway/bin/python manage.py runserver 0.0.0.0:8000
;程序启动目录
directory=/app/python/gateway
;在supervisord启动时自启动
autostart=true
;程序异常退出后自动重启,可选值：[unexpected,true,false]，默认为unexpected
autorestart=true
;启动10秒后没有异常退出，就表示进程正常启动了
startsecs=10
;启动失败自动重试次数
startretries=3

# 3.启动
supervisorctl update
supervisorctl status gateway
supervisorctl start gateway

总结

事件推送网关想法始于不断的重复维护cmdb，每次都耗费了大量的精力，投入产出比完全不匹配！虽然就cmdb来说，并不是非用不可，而是考虑到这是一种行业标准，是运维路上的基石，我们想走更远而不是满足于现状。
试想一下，维护一套数据源，节省n套关联系统的基础信息维护的时间，这难道不香吗？

这篇关于事件推送网关：让cmdb告别“花瓶”的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！