189 8069 5689
浅谈可量化的数据中心监控服务及运营方法
兴安盟乌兰浩特网站建设公司成都创新互联公司,兴安盟乌兰浩特网站设计制作，有大型网站制作公司丰富经验。已为兴安盟乌兰浩特成百上千提供企业网站建设服务。企业网站搭建\成都外贸网站建设公司要多少钱，请找那个售后服务好的兴安盟乌兰浩特做网站的公司定做！
经过十多年的建设和发展，不管是老的数据中心或者新建的数据中心，后期的运维管理方法及手段已经考虑的比较成熟，当然运维管理工具已经成为必备的产品。说起数据中心运维，其中的理论、方案、方法和工具会有很多很多中说法，今天主要讨论主动监控工具所面临的问题，以及解决之道。
监控系统面临的主要问题是告警量过多的问题，导致用户认为系统不可信，虽然这些告警都是用户自己配置出来的，但是用户浑然不知。第二个问题是监控系统如何使用，值班团队如何进行考核，让物尽其用，人尽其才。第三个问题是如何量化监控服务，体现监控服务的价值。
关于告警过多的问题，基于我之前项目的经验，引起告警量高的两个主因是监控策略过多和监控范围过细。解决方法主要是通过定向配置策略和限制重复告警两种方法来优化告警，这样使得严重告警信息的准确率提高到80%左右，但是对于预警类的信息还是比较多，因为不可能把阈值定制到一个恰到好处的数值、也不能能完全限制住网络中频繁发生的trap信息（trap是网络设备和各OS都会触发的信息），当然对于大多产品还是可以通过限制性策略限制无效trap的接收。而这几种手段需要长期性的系统维护来完成。
对于监控系统的考核主要是看系统功能、设备类型的覆盖率、监控频率粒度和稳定性等指标。当然对于故障的准确率这一个指标大家觉得非常重要，如果考虑工具是运维团队自身的工具后，这个指标的定义意义就不大了，看后面对于工具的持续优化说明，可能就比较好理解。准确率和运维团队的态度和能力相关，根据我做过的众多项目总结，运维团队对监控工具的重视程度，直接影响这个数据。
业内对于监控团队的考核没有明确的约定，主要还是长期运维的一个经验总结，普遍认可监控服务考核的主要指标在于响应时间，告警数量；告警数量主要是核算工作量和成本，数量会成为核算服务的基数。我们在不同的生产环境中，设备的负荷、运营时间、环境和业务系统等是千差万别的，出现故障的数量和时间是不确定的，比如在思科高端交换机较多的网络中，负载也很低，网络全年不会出现任何问题。但对于网络建设年限比较旧，设备比较陈旧的网络，出现故障的频率就比较高了。
监控服务考核指标主要定义是漏报率、误报率和上报率（15分钟内），前两个指标是考核团队对监控系统的运营能力，在下面告警质量的问题里讲。不能因有监控系统后运维团队就高枕无忧，运维团队需要不停的优化和改进监控系统，同时在网络、业务系统发生变更后，对监控持续的优化。第三个指标是考核团队的执行能力，有告警是必须及时分析上报的。这样从整个团队的工作态度和能力两个纬度进行考核。
监控服务价值统计主要是核算服务的费用，这个是量化现代化服务的一个普遍观点，不管是甲方还是乙方，数字说话是普遍认可的一个观点，根据上面提到的以告警量做为核算成本的一个基数，再根据告警的严重等级和相关业务项的等级，进行加权计算，例如同样严重等级的告警，对于不通等级的业务系统，发现该告警的的价值是不一样的。再在以上几个指标考虑的基础上，增加响应时间的计算，基本上可以计算服务的价值量。计算公式为（需要CMDB的支撑）：
M=p（w1*a1*b1*r1+w2*a2*b2*r2+……wn*an*bn*rn）+基本服务价格（验证误报、巡检等工作）
基本价格服务包括：网元数量*单价；网元是网络管理中可以监视和管理的最小单位，包括软件、硬件和应用等服务。这里就包括常规告警监控和性能报告等。
用以上两种纬度计算，主要是从服务团队的态度和能力两个纬度进行激励。
简称 | 字符描述 |
M（money） | 服务价值 |
w（work） | 告警项 |
a（alert） | 告警级别 |
b （business） | 业务系统级别 |
r（response） | 响应时间 |
p（price） | 基本价格 |
例如：
告警级别：业务系统级别：响应时间：
严重告警 | 1.5 | XX生产系统 | 1.5 | 5分钟 | 1.5 | ||
高级告警 | 1.2 | OA系统 | 1.2 | 10分钟 | 1.2 | ||
初级告警 | 1.0 | 公司门户系统 | 1.0 | 15分钟 | 1.0 | ||
警告告警 | 1.0 | XX测试系统 | 1.0 | 30分钟 | 0.9 | ||
初级告警 | 0.8 | 内部论坛 | 0.8 | 60分钟 | -1 |
在目前了解到的国内几家互联网公司中，数据中心运维的成熟度比较高，运维考核主要从五个纬度考虑，即响应时间、准备度（预防机制）、处理态度与能力、处理结果和后续措施。前三个跟监控相关，及时上报体现响应时间；对监控工具持续优化、巡检和演练等体现准备度和能力。
告警常见问题
1、监控存在局限，存在监控盲点。规避方法：在网络层、应用层、系统层建立监控策略，尽可能的扫除盲点。防止漏报。
2、告警延时，在产生告警到接受告警的过程中，系统会经过告警转换接口，邮件或短信接口，容易出现排队和阻塞。规避方法：拓宽渠道、减少拥塞，严重告警发送短信，其他预警类告警发送邮件或页面显示等。防止漏报。
3、告警质量问题。提升监控策略和质量在运维过程中会一直延续。规避方法：核心思想是运营，通过规划和统筹能力，既要全局规划告警分类、告警模型、告警策略，还要持续按业务和人的告警数量、告警分布持续优化。防止误报
告警模型
1、告警分类，便于建立告警模型、方便归纳和分析定位外，最重要的是有一个完整、系统的故障检测、告警响应机制。
2、告警模型，具备一定规则的预处理程序，比如定义一个阈值或多维度的组合条件。例如连续多次超过某个阈值后，产生告警，可以避免性能瞬时高而产生的告警。
告警优化
1、按照频率收敛告警，按照频率和次数设计告警策略
2、根据责任人、设备类型或时间来收敛告警、合并告警。
3、告警关联，让有相关关系的模块之间不要产生重复告警。（在一些互联网中心的自开发系统中有这样的功能）
4、告警分析，还是主要是讲运营过程中对告警的持续性分析，跟踪，优化策略，使得告警数量保持在一个合理范围。