企业随着业务的发展以及新IT技术的不断引入，应用系统的IT资源规模是越来越大，IT架构的复杂性也与日俱增。这种情况下，需要通过多种监控系统，不同的途径来感知业务系统活没活，活的好不好，用户体验怎样。常见的监控系统类型就包括：基础环境监控、网络监控、系统监控、数据库监控、应用监控、用户体验监控等等。
在这种场景下，我们在之前的文章《如何改善监控问题，试试打造企业统一监控平台体系！》
一文中探讨过，就需要一个统一的监控中台来对下管理多个告警源，中间进行告警数据的处理，对上提供可消费的监控数据。整体架构图如下所示：
▲统一监控能力架构
这里就会存在一个问题，监控和企业的CMDB之间是怎样的关系呢？
我们的理解有如下两层关系：
CMDB需要为监控系统提供必要的支撑数据，来收敛、立体化、标准化告警信息。
CMDB也需要打通到监控系统的通道，在新的对象加入CMDB的时候能够自动将该对象加入监控系统；同时在配置数据发生变化的时候，能够通过监控系统发出必要的告警信息。
我们先展开聊下第一层关系。监控系统，比如zabbix，在某个对象的某个监控指标达到阈值时候，会出发告警：XX对象的XX指标告警和详情信息等。并且可以在zabbix中配置监控项之间的依赖关系，实现告警的收敛和关联。
但是这里有一个问题，我们设想一个场景：你是一家大型2C公司的DBA，冬夜凌晨3点钟，外面西北风凛冽，突然手机铃声大作，有告警信息提示应用系统A数据库节点01出现连接异常告警。告警信息提示内容有限，此时的你是否要起来打开电脑做进一步的处理呢？
很纠结，对吧。其实作为管理员，收到这条告警信息的时候，除了需要知道这个数据库有问题，其实还想知道更多的信息，比如：这个数据库属于什么应用系统、位于什么环境、是否是高可用的集群、应用负责人是谁、哪些应用系统需要依赖这个应用系统、这个数据库最新是否有配置变更发生等等，以便做出进一步的判断和安排下一步的操作：比如在大冬天的凌晨，要不要起来打开电脑。那么这个时候，我们就需要一个系统能够提供：应用层次拓扑、集群信息、模块信息、资源实例、关联关系等信息，这个系统就是CMDB。
▲CMDB配置管理
有了CMDB之后，在告警发生的时候呢，我们就可以让告警系统前往CMDB中查询跟这一告警对象有关的综合配置信息，以便提供最为准确、丰富和标准的告警信息。举例来说，上个场景中，如果我们知道数据库实例01是属于应用系统A的测试环境的，并且有高可用集群，当前理论上是没有用户访问这个数据库的，管理员又何苦受冻起床开电脑呢？
反过来讲，如果发现这个数据库是系统A的生产环境的数据库，并且由于最近在升级，当前是单点模式，同时还有系统B和C需要依赖系统A，那就赶紧麻溜的起来处理故障，并通知B和C启动相应的预案机制以尽可能降低影响。
这里，就需要CMDB具备提供数据给监控系统的能力，需要具备相应的数据查询、读取的接口信息，并且能够方便的集成。
▲蓝鲸API网关&CMDB的API接口列表
另外一方面，CMDB也需要主动同步自己的数据到监控系统中。举个例子，我们上线了某个系统的一批新的虚拟机节点，提完工单，录完CMDB配置信息，再手动到监控里面配置一遍吗？显然不是很合理，对吧？这个时候就需要CMDB能够主动将新的对象信息推送给监控系统，监控系统按照既有监控模板，下发agent、配置监控协议、启动监控等。
另外，如果CMDB通过扫描发现某个主机的实际配置信息与当前CMDB库中存储的信息不一致，是不是也应该通过监控系统告警出来，通知到管理员进一步处理呢？
所以这里你看，监控系统与CMDB之间是紧密关联的。而更要命的是企业里面往往监控系统不只一个，如果每个监控系统都要与CMDB做一遍集成，非累死不可。这里面就需要有监控中台和统一告警管理的概念，我们不需要每个监控系统直接与CMDB集成，只需要把所有的监控系统接入到统一告警中心模块中来，由统一告警模块来与CMDB监控对接，共享信息。这样，我们的每一条告警在发出的时候，都可以依据CMDB中的信息，变成标准化、立体化的告警，而不是扁平的告警。这样的告警才能真正凸显价值。
作者：赵海兵
—END—
【干货】4种Oracle DBaaS部署模式，你在使用哪一种？
如何改善监控问题，试试打造企业统一监控平台体系！
云计算 | 数据在云上安全吗？DDoS***怎么办？
如何基于TAPD实践Scrum的敏捷开发？
嘉为出席GOPS全球运维大会：运维巅峰时代，研运中台或是唯一选择
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
