1、配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。

2、CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

   蓝鲸平台日常维护中遇到的问题【摘要】在蓝鲸平台的日常维护过程中，会遇到一些平台异常的问题，这些问题有一些是常见的，例如bkdata进程异常导致监控数据未上报，有一些是特定情况下遇到的，但经过排查可以解决的，希望通过整理之前处理过的排错，对以后遇到类似的问题有帮助，能够迅速排查解决。

cmdb重启失败【问题描述】重启cmdb所在机器后，发现启动cmdb有报错，出现cmdb_adminserver：ERROR（spawn error） 【排查】查日志发现连接MongoDB失败，使用bk_cmdb用户也无法登陆到MongoDB 【解决方法】在MongoDB里重新对bk_cmdb用户进行授权，授权完之后，再重新启动cmdb1)、重新授权

# source /data/install/utils.fc

# mongo -u $MONGODB_USER -p

$MONGODB_PASS --port $MONGODB_PORT --authenticationDatabase admin

# show dbs

#进入cmdb这个库

# use cmdb

#更新bk_cmdb用户的密码（密码可以从/data/install/.app.token中查找）

# db.updateUser("bk_cmdb",{pwd:"密码"})

# cd /data/install

# ./bkeec stop cmdb

# ./bkeec status cmdb

# ./bkeec start cmdb

# ./bkeec status cmdb

cmdb访问报404【问题描述】cmdb所在机器意外重启之后，访问cmdb出现404的问题。 【排查】检查服务都是正常的，查看cmdb_adminserver的日志之后，发现无法解析zk.service.consul，检查dns后，发现首选dns不是127.0.0.1了。 【解决方法】修改/etc/resolv.conf的nameserver，确保 /etc/resolv.conf 里第一个nameserver是 127.0.0.1，而且option选项不能有rotate。     1.3、SaaS访问异常【问题描述】登录到蓝鲸后，打开SaaS均出现”应用出现异常”的报错。 【排查】1)、在出现异常的时间段内，检查蓝鲸进程运行情况，运行状态显示为RUNNING；                 2)、对CMDB服务进行排查，通过查看cmdb_apiserver.stdout.log和cmdb的nginx访问日志发现，连接cmdb的esb-api接口服务出现timeout，初步怀疑是由于api服务连接不上导致问题的出现。 【解决方法】重启cmdb服务后，该问题解决，SaaS恢复正常访问。在中控机重启cmdb

# cd /data/install

# ./bkeec stop cmdb

# ./bkeec status cmdb

# ./bkeec start cmdb

# ./bkeec status cmdb

组件监控【问题描述】配置组件监控，保存时，报用户没有权限，出现”调用接口失败 execute_platform_task：账户【test】没有该业务的操作权限” 【排查】经咨询开发人员后，确认是以下原因导致：1)、由于exporter是内置在蓝鲸业务的机器下的，下发流程涉及到跨业务分发文件，因此要求用户同时拥有源业务和目标业务的权限，目前还在确定解决方案。2)、 promtheus类型的组件会有这个问题，包括Mencache、SQLServer、Oracle、Haproxy、Weblogic、RabbitMQ、Zookeeper等。 【解决方法】目前将”蓝鲸”这个业务的运维人员加上这个账号，即可解决该问题。  2.2      

主机性能监控【问题描述】cpu5分钟负载突然显示无数据上报. 【排查】在蓝鲸自监控里检查发现，databus的etl服务有异常。 【解决方法】登录到bkdata所在机器，重启etl服务。 

# supervisorctl -c

/data/bkee/etc/supervisor-bkdata-databus.conf status databus_etl

# supervisorctl -c

/data/bkee/etc/supervisor-bkdata-databus.conf restart databus_etl

服务拨测【问题描述】打开服务拨测，出现 【模块：data】接口返回结果错误：database not found：uptimecheck_212 的报错。 【排查】旧的拨测没建库成功的，需要手动触发接口创建 【解决方法】登录到蓝鲸的任意一台机器上执行以下命令创建库。

# curl -X "POST" "http://dataapi.service.consul:10011/tool/tsdb/create_db"  -H 'Content-Type: application/json

  charset=utf-8'

        -d $'{

  "db_name": "uptimecheck_212",

  "days": "30"

   }'

执行脚本有异常【问题描述】作业平台执行脚本等操作时有问题，出现 " Execution result log always empty. " 的报错。 【排查】经检查，healthz接口正常，nfs挂载也正常，但有一台机的gse_task出现异常情况。 【解决方法】登录到出现gse_task异常的机器上重启gse_task，作业平台即可正常执行脚本等操作。

# cd /data/bkee/gse/server/bin/

# ./gsectl stop task

# ps -ef | grep gse_task

# ./gsectl start task

调整MySQL的innodb_log_file_size参数为4G

# cd /data/bkee/service/mysql/bin/

# ./mysql.sh stop

# vim /data/bkee/etc/my.cnf

# innodb_log_file_size = 4096M

# cd /data/bkee/public/mysql/

# mv ib_logfile0

ib_logfile0.20190424.back

# mv ib_logfile1

ib_logfile1.20190424.back

#启动MySQL服务

# cd /data/bkee/service/mysql/bin/

# ./mysql.sh start

蓝鲸平台部署完成后再添加gse和nginx外网ip

# cd /data/install/

# vi globals.env

         export

  AUTO_GET_WANIP=1

         export

  GSE_WAN_IP=(GSE_WAN_IP GSE_WAN_IP1)

  export NGINX_WAN_IP=(NGINX_WAN_IP NGINX_WAN_IP1)

# ./bkeec sync common

# ./bkeec render gse

# ./bkeec stop gse

# ./bkeec start gse

# ./bkeec install nginx 1

# ./bkeec stop nginx

# ./bkeec start nginx

IT运维管理发展成熟，目前较为普遍应用的为ITIL流程管理。有人将ITIL比喻成IT管理中“黑夜航行的灯塔”，这光芒万丈的词汇吸引了无数个企业或是准备、或是已经开始在IT运维服务管理中实现标准化运维。而我们知道，在ITIL强大的流程管理面前，其核心组件之一的CMDB（配置管理数据库）却往往耗费了大量的人力和时间收集各类IT基础架构信息后，竣工而成的却是一个几经失去生命力的ITIL运维管理组件CMDB。

CMDB在IT服务管理中的驱动力

面对复杂多变的业务需求与IT预算的不断紧缩，企业的IT部门在为企业整体运营目标提供可靠服务时都面临空前的挑战。想要解决这些问题就非得拥有一个良好的组织管理策略，因为我们必须要先了解环境中的各个对象的特点，才能对它们予以控制、维护和改善。为了达到动态IT运维服务所追求的目标，我们必须将ITIL指导真正落实为明显的、可衡量的，变成可以整合的实体，而这承载这些实体的容器就是CMDB。

作为ITIL实施成功的关键与保障，CMDB相当于整个“网络列车”前行的动力源泉。由于它可以代替以往手工存储和管理企业IT架构中设备的各种配置信息，因此更多的企业开始考虑采用自动获取的方式存储IT基础设备的各种配置项信息，然后将其与ITIL的所有流程都紧密相连，提供有效数据支持ITIL其他流程的运转，

CMDB配置库可以被比喻成企业网络中的“眼睛和大脑”，这个特殊的动态数据库作为ITIL标准流程里一个核心的组成部分，记录了ITIL流程运转的过程，从开始启动、发现事件、问题处理、变更管理、版本发布，到最后的关闭，中间的所有的过程都会被自动的记录到CMDB中，并实时、真实地展现出来。

错误的CMDB就如大脑记忆力出现混乱

ITIL运维管理组件CMDB存储与管理企业IT架构中设备的各种配置信息，那么如何运转、发挥配置信息的价值，就要依赖于数据的准确性了。试想如果CMDB对故障设备的关键性指标提供了错误描述，事件能够得到及时解决吗？如果没有配置管理的同类故障统计分析支持，如何实现主动的问题管理？如果没有配置管理提供CI（配置项）之间的关系作为依据，如何针对将要进行变更的CI以作风险评估？

曾经一位资深表示：“前几年，我所任职的几个企业中对于IT建设虽然重视，但当时苦于没有IT管理工具作为辅助，所以我们都是采用自下而上的方法，也就是从底层开始，利用手工把资料录入到开源的CMDB中。

这个阶段的问题可能谁都清楚，历时两、三年，不但时间长久，而且还存在录入错误的问题。而现在我更换了公司之后，已经放弃了自行建立CMDB的想法，也不想让IT人员花大力气梳理、搜集这些信息，并且在日常工作中耗费人工保持其时效性。但我考察了一些案例，这些公司采用厂商所提供的IT管理工具建立的CMDB在实施后，仍旧发现了设备配置项录入不规范、不全面的问题，资源之间的关联关系缺乏等一系列的问题，这就必然会导致领导决策人参考这些错误的信息做出错误的决定。

唯一比较让人满意的是人力资源与社会保障部，他们采用的CMDB和IT资源库进行了互联互通，底层监控工具自动采集数据汇总到IT资源库RDB，定时和ITIL运维管理组件CMDB进行审计，确保CMDB的数据库准确无误，有效保证了数据的精确性，为领导的决策提供了最基础的保障。”

那么，人力资源与社会保障部是如何保证数据质量，使系统成效发挥出来，避免功亏一篑呢？

在许多基于ITIL的ITSM项目中，实践者虽深知CMDB对于企业IT服务管理能力的重要性，但在部署过程中却往往被CMDB构建所涉及的庞大工作量所困扰，感觉困难重重，不得要领。CMDB出现问题一般会存在三种情况。首先，是由于配置信息设置过于精细，会导致数据负载压力过大，性能下降；其次，由于资源信息、配置信息设计过于粗框，没有将必要的CI信息设计进去，没有建立CI之间的相互关联关系，导致系统因配置项到期罢工之后，找不到需要的配置项以及配置项依赖影响信息，导致运维效率降低；另外，一些IT管理项目也出现了RDB（资源库）信息与CMDB配置信息未能建立良好的同步审计机制，导致故障产生时，两者信息不一致，混淆了运维人员的’眼睛’。

---