今天专家巡检了我们的基础监控平台，对于我们的监控覆盖度和CMDB提出了一些建议。
监控覆盖率的问题
监控要做到全面覆盖才有效，这个大家都是知道。专家比较系统的分析了这方面的问题，一个角度是多层，也就是把系统分成很多层，主要按照这几个层次进行分析与排查
互联网入口层->业务服务层->应用层->中间件->主机（虚拟机）->硬件
专家发现例如业务系统层、主机层做的不错，但是在中间件层上监控覆盖低。
我想：这可能是因为业务系统层有专门的业务运维管理员，而主机层有专门的基础系统运维管理员，中间存在管理上的盲区，所以才会出现这个问题。
监控是否覆盖了CMDB的监控对象
专家提出一个问题，监控是否完整覆盖CMDB中的监控对象？
我想：这个我们在日常做监控的时候，由于CMDB与监控处于分别管理状态，所以，虽然监控对象很多，但是好像没有与CMDB的对象做到完整一对一。
在排障时是否要求根据关系查看指标
这个也是专家提出的问题，他的意思是，CMDB应该记录了所有对象的关系，在发生故障时，目前已经可以看到告警与监控对象的日志、指标，但是也应该看到与监控对象存在上下游关系的对象的指标、告警，这个排查动作也是必要的（甚至是规定的），而这个关系应该是存在CMDB中的。
我想：首先CMDB目前存储的关系可能不全，并且已有的关系颗粒度比较粗，仅仅知道A机器承载了B应用，再具体往下的明细可能没有。其次，多个对象监控目前都存在监控指标，这个我们做的比较多，但是在实际分析的时候，更多的关系分析依赖运维管理员对系统的理解，而非CMDB，最后是，对于问题的排查步骤，每次排查都不太一样，并未有明确的排查要求。有时候比较大的故障，全员乱哄哄的排查。
针对关系的排查，我的理解是横向+纵向。横向就是相关对象的排查，例如A机器存在问题，那么与A机器连接的BC机器也要查看指标是否正常。纵向是指向下排查，例如A应用存在问题，那么承载A应用的A1中间件是否正常（此处和可以继续横向），承载A1中间件的C1机器是否正常。
关于关系的排查既然是必须的也是基于CMDB的，那么理论上应该可以做到自动化了。
结合主动巡检的设计理念，应该可以这样实现：
发生告警后，运维人员手动触发【主动巡检功能】，主动巡检功能通过告警关联到监控对象A，然后根据CMDB关系 ，进行横向巡检和纵向巡检，深度自定义
网友评论