如何分析CMDB软件

这篇文章将为大家详细讲解有关如何分析CMDB软件，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

前述:

    0.硬件CMDB,即面向设备资源的资产管理,面向运维人员钟情于此.

     软件CMDB,面向业务资源的配置管理,类似业务信息管理平台, 开发、PE和测试人员更加关心此处.

    1.硬件CMDB各个公司都在建设(程度不一),软件CMDB(业务信息管理平台)系统化管理维护更少.

    2.运维人员钟情硬件CMDB,对业务信息管理也只是笼统维护,远远没有到达基于应用项目的业务维护,监控力度只是系统和服务层面).

    3.开发人员开发任务繁重,没有精力提交应用业务信息,结果.....大家都很忙,可是开发出什么鬼呀,经常被市场同事投诉(真实经历).

    4. 当然开发肯定有需求分析和项目规划, 可是必须让维护人员(运维)了解和维护相关的业务应用项目.

    5. 沟通很重要, 运维人员不单单被动的维护, 以运营的手段对待项目.

困惑:

    1.涉及到微服务的开发需要了解服务部署在哪时,当前实例数和资源调度情况,更别说相关应用的日志和监控数据.

    2.运维人员进行报警巡检或性能分析或添加监控,某些服务出现问题(访问出错|服务报警|应用上线和下线回收),不知道找

        哪些相关开发和测试人员进行沟通处理, 尤其优化某个子项目服务组, 确认影响故障域和风险评估.

    3.大量应用上线,特别是容器和微服务化, 导致业务项目更加复杂, 系统<->服务<->应用数据串更新频繁,传统手段无法维护.

    4.对于某些爆发性(广告秒投项目)或者弹性伸缩应用项目,应用业务资源使用情况更加需不同人员知晓.

        最近TW业务推广,此项目资源是否充足,以便进行扩充; 结果突发专线跑满,影响到其它业务,原来就是推广业务造成, 临时追加带宽.

    5.反正很多都是口口相传,只有专门人员知晓,人员沟通成本非常高,知情度低也会影响工作效率.能不能提供一个便捷平台,让开发、

        运维、测试人员更加高效处理应用项目业务.

应用业务配置管理-大图

应用业务配置管理系统相关资源(系统层、宿主、容器、服务、服务组、应用项目)关联,以及对应监控系统关系.

部分成果展示:

1. 面向业务资源配置管理, 全部隶属于'应用及服务'下.

2.服务器系统管理,  OS系统作为应用及服务的基础资源.

3. 基于硬件服务器维护(类似硬件CMDB)， 基于服务器系统维护, 基于应用项目维护, 大约这三个阶段.暂时到达服务器系统到应用项目之间, 监控系统也是基于服务器系统, 作为运维人员更加需要此切点.

4. docker宿主节点, 专门拆分出来.

5. 宿主节点和容器实例拓扑图.

适用场景和环境: (https://github.com/tm-roamer/ctopo/)

(1)适用于监控网络ip节点互联关系的场景

(2)适用于社交网络的群组互联访问关系

6. 容器实例.

7. 应用项目

8. 有些服务组模块被多应用调用, 反正需要量化区分服务资源,在应用和服务间增加服务组层.

微服务项目也可以在此处添加, 定义为应用则太大, 定义为服务又太小, 暂时此处.

9. 应用服务

暂时不写. 服务注册和服务发现, 类似服务治理吧.

容器服务 基于 consul+register 作为 服务注册 发现及健康检查中心.

10. 我的小目标.

只知道这些服务器系统资源正常, 服务也正常, 这些数据都太片面, 独立无法关联起来.

监控需求(贴近业务,告警合并压缩), 非常需要此业务配置管理系统.

告警合并压缩, 某个项目故障,可能多方位报警, 需要挑选出更加上层报警上报, 需要知道关系链.

####################################################################

如何标识资源:

硬件设备-Asset(X86服务器、小型机、交换路由设备、防火墙、机架等)最终选用SN进行唯一标识,device_id用于存放设备编码(条形码/二维码标签),

name则为设备名称(X86服务器则为主机名, 交换设备则为设备名).  服务器业务IP和管理IP会存放在Asset-server,  交换机管理IP存放在Asset-switch.

####硬件设备不一定有OS系统,特别是购买腾讯云和阿里云VM主机,硬件设备肯定就不用提供, 所以造成Asset-AgentInfo拆分.

主机信息-AgentInfo(kvm、vm、hwvm、X86服务器系统)必须存在OS(linux|windows|unix),安装系统初始化同时需要安装agent.  最终使用hostname

作为唯一标识, agent_ip使用映射IP(hostname -i). 刚开始使用IP标识, 居然有些系统居然有四种IP(私网|公网)且没有合法(hostname -i), 最后用回hostname.

####遇到过硬件服务器系统同时安装KVM和Docker,kvm宿主机和依附vm都存放在AgentInfo(可以安

####装agent), 可是主机系统和宿主节点属性不一致, DockerNode引擎版本、network、storage、

####image,反正就要拆. 有时购买云供应商容器服务,无法提供AgentInfo,对接加入维护使用,也是拆分

####的原因之一;  对接授权和监控和代码发布应用, 方便以后松散对接.

宿主节点-DockerNode, node_id用于主健(用于它用); host_on为可选,用于对接主机系统; 最终使用docker_name作为唯一标识.

####

容器实例-Container, node_id用于主健(用于它用); node_on和name最终作为唯一标识.

####不同宿主节点的容器实例name有可能一致(反正当前情况是这样);生命周期特别短,标识ID和IP地

####址经常变,暂时选用node_on和name联合识别.

资源收集方式和更改通知.

服务器管理信息收集:

        手动录入: 通过网页进行手动填写信息.

        Agent自动汇报: 在系统OS同时安装Agent代理,进行数据收集和汇报.

        中继自动汇报:  例如华为fushion cute私有云, 可以通过相关API读取VM相关信息, 直接入库.

宿主节点和容器实例:

        Agent自动汇报: 主要在宿主机器通过docker info|docker inspect进行数据收集和录入.

        中继自动汇报:  某个第三方平台,通过API进行信息入库.

服务管理:

        手工录入:  非常不推荐, 针对非规范化和量少的服务.

        Agent录入: 服务必须规范化, 服务安装部署时进行服务自动添加, 一般针对传统服务.

        consul服务发现: 特别是针对consul和register服务,对容器服务非常有用.

服务组管理:

        一般通过nginx和haproxy进行分发管理, 或者其它方式.

        haproxy可以通过状态API页面读取service_cluster和相关服务, 方便自动入库.

更改通知:

    以上资源变动, 最好能对接到监控系统, 让相关人员了解, 解放我们双手.

关于如何分析CMDB软件就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。