企业随着业务的发展以及新IT技术的不断引入，应用系统的IT资源规模是越来越大，IT架构的复杂性也与日俱增。这种情况下，需要通过多种监控系统，不同的途径来感知业务系统活没活，活的好不好，用户体验怎样。常见的监控系统类型就包括：基础环境监控、网络监控、系统监控、数据库监控、应用监控、用户体验监控等等。
监控是常见的运维手段，一般是指以观测系统的外部资源使用情况和接口表现来推测系统运行状态，即感知到“正在发生什么”。
在这种场景下，就需要一个统一的监控中台来对下管理多个告警源，中间进行告警数据的处理，对上提供可消费的监控数据。
1、CMDB需要为监控系统提供必要的支撑数据，来收敛、立体化、标准化告警信息。
2、CMDB也需要打通到监控系统的通道，在新的对象加入CMDB的时候能够自动将该对象加入监控系统；同时在配置数据发生变化的时候，能够通过监控系统发出必要的告警信息。
监控系统，在某个对象的某个监控指标达到阈值时候，会出发告警：XX对象的XX指标告警和详情信息等。并且可以在监控系统中配置监控项之间的依赖关系，实现告警的收敛和关联。
设想一个场景：你是一家大型2C公司的DBA，冬夜凌晨3点钟，有告警信息提示应用系统A数据库节点01出现连接异常告警。告警信息提示内容有限，此时的你是否要起来打开电脑做进一步的处理呢？
其实作为管理员，收到这条告警信息的时候，除了需要知道这个数据库有问题，其实还想知道更多的信息，比如：这个数据库属于什么应用系统、位于什么环境、是否是高可用的集群、应用负责人是谁、哪些应用系统需要依赖这个应用系统、这个数据库最新是否有配置变更发生等等，以便做出进一步的判断和安排下一步的操作：比如在大冬天的凌晨，要不要起来打开电脑。那么这个时候，我们就需要一个系统能够提供：应用层次拓扑、集群信息、模块信息、资源实例、关联关系等信息，这个系统就是CMDB。
有了CMDB之后，在告警发生的时候呢，我们就可以让告警系统前往CMDB中查询跟这一告警对象有关的综合配置信息，以便提供最为准确、丰富和标准的告警信息。举例来说，上个场景中，如果我们知道数据库实例01是属于应用系统A的测试环境的，并且有高可用集群，当前理论上是没有用户访问这个数据库的。
如果发现这个数据库是系统A的生产环境的数据库，并且由于最近在升级，当前是单点模式，同时还有系统B和C需要依赖系统A，那就赶紧麻溜的起来处理故障，并通知B和C启动相应的预案机制以尽可能降低影响。这里，就需要CMDB具备提供数据给监控系统的能力，需要具备相应的数据查询、读取的接口信息，并且能够方便的集成。
另外，如果CMDB通过扫描发现某个主机的实际配置信息与当前CMDB库中存储的信息不一致，是不是也应该通过监控系统告警出来，通知到管理员进一步处理呢？
所以，监控系统与CMDB之间是紧密关联的。而更要命的是企业里面往往监控系统不只一个，如果每个监控系统都要与CMDB做一遍集成，非累死不可。这里面就需要有监控中台和统一告警管理的概念，我们不需要每个监控系统直接与CMDB集成，只需要把所有的监控系统接入到统一告警中心模块中来，由统一告警模块来与CMDB监控对接，共享信息。这样，我们的每一条告警在发出的时候，都可以依据CMDB中的信息，变成标准化、立体化的告警，而不是扁平的告警。这样的告警才能真正凸显价值。
网强将IT网络管理资源一体化监控与可视化展示，通过异常一览可以根据资源类型、异常等级、恢复状态、确认状态和时间范围查看网络管理软件管理的资源异常信息，支持当前关注即显示IT运维管理人员所关注的IT网络设备、服务器等网络管理软件监控资源的当前运行情况。
上一条：企业如何做好业务监控？
下一条：桌面安全管理软件，功能真心强大！
