开源CMDB｜企业级通用CMDB设计最佳实践

由于企业运维场景各异，开源CMDB 要能满足运维的需求，通用灵活、简单易用是必要条件。

因此，要实现一个尽可能通用、灵活、可扩展的运维资源数据的配置和管理系统，系统至少要满足:

运维人员能根据企业的运维场景和需求，自己去构建存储的数据模型，以及模型之间的关系
提供极简API，尤其是在数据和关系检索要做到通用，便于数据消费
有丰富的图表展示，满足个性化的定制需求
数据的自动发现，确保数据权威性
细粒度的权限控制，满足安全合规的要求

以下从总体架构、模型配置、数据可视化、自动发现、权限管理这5个方面来介绍。

01总体架构

CMDB总体架构

如图可见CMDB的总体架构，CMDB自下而上被划分为4层: 存储层、数据层、API、UI ，图中的CIType 可以理解为数据模型，例如物理机、虚拟机、应用、网卡、软件等。CI是配置项，即CIType的实例, 例如具体的1台物理机就是1个CI。下面概要介绍一下这4层。

存储层：主要用来存储CIType和CI，以及它们之间的关系。

Mysql: 所有数据的持久化存储
Redis: 数据缓存，主要是用户、属性、CIType、权限等的数据缓存，减少Mysql访问压力，提升API的响应速度
Elasticsearch: 主要存储CI的实例数据，用来检索CI。实际上ES是一个可选的方案，CI数据的检索默认是通过Mysql+Redis来实现的，当然CI的实例数若超过一定数量级，考虑到查询效率，建议使用ES。

数据层：描述了模型数据和实例数据，以及它们之间的关系。在这一层首先需要运维按照具体的应用场景来完成模型的构建。模型包括属性，属性有不同的值的类型，且有一些检验规则，比如唯一、必须等的校验，在系统层面避免脏数据的录入。总结下来，运维CMDB实际上主要包括下面4种类型的数据：

硬件数据：物理机、宿主机、机柜、网络设备、网卡、硬盘、内存等等
软件数据：docker、mysql、redis、tomcat等等
业务数据：应用、产品线、事业部等等
关系数据：上面3种类型数据之间的关系

当然，每个公司的运维场景各异，用户都可以按照自己的需求来设计数据模型。

API层: 对UI提供一套统一、透明的调用接口，对下层各数据模块实行接口抽象与封装。要尽可能实现通用，要求CI和CI relation的查询API必须做到通用和灵活，要考虑到用户各种各样的查询需求，本系统实现了对应的2个API，基本上满足了前端对数据查询的所有需求。

UI层: 实际上就是web portal，用户直接访问CMDB的门户。核心功能主要包括：模型配置、资源视图、关系视图、资源层级和权限管理这5个核心模块。 02 模型配置

动态建模

除非是大型的成熟的企业，否则很难在开始就完全能够定义清楚运维的数据模型。因为企业在不断成长和发展的过程中，运维的场景和需求也是在不断的变化的，所以，通用的CMDB一定要能够让管理员方便对CIType进行动态的修改。如图2所示, 要完成动态建模，至少要能增删改CIType，给CIType定义属性，也可以从属性库直接复用已存在的属性，属性可以有校验规则，以便尽可能保证数据的准确性。属性值的类型支持以下5种：

整数类型
浮点数
日期类型: date, datetime, time
文本类型
JSON类型

此外，还可以构建CIType之间的关系，比如事业部包含产品线，产品线包含应用，应用部署在物理机，应用部署在docker上。

模型增删改

模型属性的定义

图3和图4分别是对CIType的增删改和CIType的属性进行定义。下图5则是对关系视图进行定义，比如构建服务树，这个将在下面关系视图进行详细的阐述。

图5. 关系视图的定义面板

03数据可视化

3.1 资源视图

资源视图即CI数据的检索。为了保证系统的通用、灵活，CI数据检索的API要能按照CI的属性进行各种条件过滤查询，而且这个API要尽可能覆盖用户不同的查询需求。CI的通用查询API实现了搜索表达式的查询，表达式支持AND、OR、NOT、IN、RANGE、COMPARISON的组合查询，如图6所示。

图6. CI通用搜索

如图7，用户能够订阅自己关心的资源视图，比如物理机、应用等。图8则是用户订阅的资源视图的数据展示，我们可以根据属性字段查询，另外也提供了批量修改、下载、删除等操作，也可以查看CI的生命周期，以及它的关联CI。

图7. 用户订阅关心的资源视图

图8. 资源视图

3.2 资源层级

资源层级视图实际上是资源视图按照树形目录的方式来进行展示。用户可以订阅某一个CIType按照不同属性分level来展示，比如物理机，我们可以定义: IDC -> 环境 -> 状态 3个属性分层的视图，如图9所示，用树形展示。这样方便了不同角色的用户可以按需来设计资源的统计展示方式，树形视图是单类CI实例数据的展示，不涉及到CI之间关系。

图9. 资源层级视图

3.3 关系视图

关系视图是CI之间的关系，并用树形的方式来进行呈现。同样为了保证系统的通用性，CI关系查询和CI实例的查询API一样要灵活且通用，本系统实现的CI关系查询API是使用方法类似于上文提到的CI的查询API，只不过多了2个参数：root_id 搜索的根节点的ci_id和level搜索的层级，也就是说可以从某一个CI出发，去查询离该CI任一level的CI，如图10所示。从根节点root出发可以搜索level=1的关系节点，也可以直接搜索level=2或者n的任一一层节点。

图10. 关系查询

关系视图是由管理员根据需求来进行定义，然后授权给不同的角色来使用。举个例子: 事业部 -> 产品线 -> 应用定义这样的一个关系视图,我们命名为服务树, 树的节点是这3层CI, 具体的数据展示是应用下面的所有资源，可以是物理机，也可以是docker，如图11所示。

图11. 关系视图-服务树

04自动发现

自动发现正如其字面意思，就是自动的去发现各种各样的运维资源，资源的变更能及时的反馈到CMDB里，降低了人力维护数据的成本。自动发现的建设一般分为3步: **创建自动发现规则、模型关联自动发现规则、执行自动发现。**接下来我们对这3步进行简要的阐述。

4.1 自动发现规则

维易开源CMDB的自动发现规则主要包括3大类:

4.1.1 内置插件和自定义插件

内置插件是把物理机、虚拟机、硬盘、网卡的发现内置到了OneAgent(注：维易统一运维探针OneAgent，可在官网免费申请veops.cn)里。点开内置插件的自动发现规则，呈现的是采集的属性列表，如下图所示：%25E9%2587%258C%25E3%2580%2582%25E7%2582%25B9%25E5%25BC%2580%25E5%2586%2585%25E7%25BD%25AE%25E6%258F%2592%25E4%25BB%25B6%25E7%259A%2584%25E8%2587%25AA%25E5%258A%25A8%25E5%258F%2591%25E7%258E%25B0%25E8%25A7%2584%25E5%2588%2599%25EF%25BC%258C%25E5%2591%2588%25E7%258E%25B0%25E7%259A%2584%25E6%2598%25AF%25E9%2587%2587%25E9%259B%2586%25E7%259A%2584%25E5%25B1%259E%25E6%2580%25A7%25E5%2588%2597%25E8%25A1%25A8%25EF%25BC%258C%25E5%25A6%2582%25E4%25B8%258B%25E5%259B%25BE%25E6%2589%2580%25E7%25A4%25BA%25EF%25BC%259A "https://veops.cn)%E9%87%8C%E3%80%82%E7%82%B9%E5%BC%80%E5%86%85%E7%BD%AE%E6%8F%92%E4%BB%B6%E7%9A%84%E8%87%AA%E5%8A%A8%E5%8F%91%E7%8E%B0%E8%A7%84%E5%88%99%EF%BC%8C%E5%91%88%E7%8E%B0%E7%9A%84%E6%98%AF%E9%87%87%E9%9B%86%E7%9A%84%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8%EF%BC%8C%E5%A6%82%E4%B8%8B%E5%9B%BE%E6%89%80%E7%A4%BA%EF%BC%9A")

图12.内置插件

自定义插件实际上是可以实现其他所有采集需求的，比如MySQL、Nginx、Tomcat等常用的一些软件自动发现，实现一个自定义的插件很简单，就是一段python脚本:

python 复制代码

import json


class AutoDiscovery(object):

    @property
    def unique_key(self):
        """

        :return: 返回唯一属性的名字
        """
        return

    @staticmethod
    def attributes():
        """
        定义属性字段
        :return: 返回属性字段列表, 列表项是(名称, 类型, 描述), 名称必须是英文
        类型: String Integer Float Date DateTime Time JSON
        例如:
        return [
            ("ci_type", "String", "模型名称"),
            ("private_ip", "String", "内网IP, 多值逗号分隔")
        ]
        """
        return []

    @staticmethod
    def run():
        """
        执行入口, 返回采集的属性值
        :return: 返回一个列表, 列表项是字典, 字典key是属性名称, value是属性值
        例如:
        return [dict(ci_type="server", private_ip="192.168.1.1")]
        """
        return []


if __name__ == "__main__":
    result = AutoDiscovery().run()
    if isinstance(result, list):
        print("AutoDiscovery::Result::{}".format(json.dumps(result)))
    else:
        print("ERROR: 采集返回必须是列表")

4.1.2 网络设备的自动发现

这个发现能力同样内置在OneAgent里，通过SNMP等网络协议去采集网络设备，目前实现的主要包括交换机、路由器、防火墙、打印机。

图14. 网络设备自动发现

4.1.3 公有云资源的发现

通过对接公有云厂商的开放API，主动定时轮训的方式去获取公有云资源，目前集成了阿里云、腾讯云、华为云、AWS的云主机的自动发现，后续会扩充云资源的发现。当然如果本身在云主机上部署了OneAgent，实际上也是可以用内置的虚拟机的自动发现插件来进行采集。

4.2 模型关联自动发现规则

4.2.1 模型属性自动发现

以网卡为例进行说明，主要包括属性映射和执行配置:

1) 属性映射

关联上内置的网卡自动发现规则后，模型的属性名和自动发现规则的属性名会进行自动匹配，如果名字不一样则需要人工来匹配。实际上每个模型可以应用多个自动发现规则，每个规则里可能采集了模型的部分属性。

2) 执行配置

首先指定自动发现规则执行的目标机器，可以的选项有：

所有节点，比如物理机、虚拟机等，但是必须管理员才能配置为所有节点。
具体的某个节点，比如公有云资源的自动发现或者网络设备的自动发现，都是指定具体的某个节点去执行的。
从CMDB里选择，比如网卡，可以选择CMDB里所有的物理机去执行。

图15. 网卡属性自动发现

其次可选择是否自动入库，一般来说自动发现的准确率如果接近100%，那么可以直接选择自动入库，即自动发现的实例会直接入库为CI。如果选择不自动入库，实例会先进入自动发现资源池，然后需要人工批量入库为CI。

4.2.2 关系自动发现

关系自动发现配置极其简单，还是以网卡为例进行说明：

如下图所示，只需配置网卡采集的属性sn(物理机的序列号，实际上对网卡模型来说是冗余字段)和物理机模型的序列号建立关系即可，当采集上来的网卡入库CMDB时，会用字段来建立和物理机之间的关系。

图16. 网卡关系自动发现

4.3 执行自动发现

模型关联好自动发现规则之后，OneAgent会自动定时同步其所在节点的自动发现规则，然后执行自动发现规则，如果采集的数据和上一次采集有异同，则推送数据到服务端。

05权限管理

权限管理对运维系统来说是极其重要的，因为运维人员是拥有比较高权限的角色，所以运维系统的权限严格管控是至关重要的。比如自动化运维系统要从执行作业、执行目标机器、执行用户3个方面同时去控制权限。

如下图所示，在每个模型配置的页面里有权限设置的tab，这个页面里明显可以看到分为:

1.模型权限

配置权限表示的是模型可以被编辑，授权权限则是这个模型和实例可以被授权，一般是给管理员才会分配授权的权限。

2.实例权限

包括查看字段 ，即上面所讲的属性级别的控制；查看实例是指实例的权限控制，增删改这个比较容易理解。

添加图片注释，不超过 140 字（可选）

查看字段的权限设置如下图所示，默认是全部字段可以被查看，当然可以自定义字段给用户授权，图中授权了8个字段给demo用户角色。

添加图片注释，不超过 140 字（可选）

查看实例的权限如下图所示，默认也是可以查看所有的CI实例，当然也可以自定义，比如定义物理机里开发负责人是用户自己的，我们可以用双大括号来引用变量，目前支持的变量有user对象。

{{引用变量}}

添加图片注释，不超过 140 字（可选）

3.关系权限

在模型关联里可以对CI关系进行授权，主要包括新增、删除和授权的权限控制，这里很容易理解，就不再赘述了。

添加图片注释，不超过 140 字（可选）

经过上面的权限设置，以demo用户登录CMDB系统，在资源数据视图里查看物理机，结果呈现如下图所示。首先CI列表仅包含了开发负责人是demo的实例，字段仅展示了上面定义的8个属性。

添加图片注释，不超过 140 字（可选）

结语

设计和实践一个通用的运维CMDB需要时间、资源和不断地改进。一个成功的CMDB可以为组织提供更好的可见性、管理配置项的效率以及支持监控、ITSM流程的能力。然而，关键是要记住，CMDB不仅仅是一个工具，还需要与组织的文化和流程相结合，以实现最大的价值。在设计和实践CMDB时，持续的合作和反馈是成功的关键因素。

基于此设计我们开源了一个CMDB，希望能帮助到更多企业，并得到大家的积极反馈，系统将持续不断的改进，也欢迎您的加入。

makefile 复制代码

在线体验
在线Demo: https://cmdb.veops.cn
用户名: demo 或者 admin 
密码: 123456

开源地址

GitHub开源地址为：
github.com/veops/cmdb

大家如果觉得有用，麻烦GitHub上点个⭐️以示鼓励。