监控体系建设（二）：监控指标

（接监控体系建设（一）监控体系分层与整合）

三、 监控指标

如前一章提到，监控有赖于运维各专业条线协同完善，通过将监控体系进行分层、分类，各专业条线再去有重点的丰富监控指标。

（一）指标分类

1、基础设施层：

-环境动力：暖通系统（如空调、新风系统、机房环境、漏水等）、电力系统（如配电柜、UPS、ATS等）、安防系统（如防雷、消防、门禁等）等

-网络设备：路由器、二三层网络交换机、多层交换机、负载均衡设备等

-安全设备：防火墙、入侵检测、防病毒、加密机等

2、服务器层：

-虚拟化：虚拟网络资源、虚拟主机、虚拟存储资源等

-存储设备：磁盘阵列、虚拟带库、物理磁带库、SAN、NAS等

-服务器：大中小型机、X86服务器

3、系统软件层：

-操作系统：AIX、LINUX、WINDOWS等

-数据库：ORACLE、DB2、SQL SERVER、MYSQL等

-中间件：WEBSPHERE、WEBLOGIC、MQ、IHS、TOMCAT、AD、REDIS等

-其它系统软件：备份软件

4、应用服务层：

-服务可用性：服务状态、日志刷新、端口监听、网络连通性等

-应用交易：交易整体情况、应用性能（重要交易或整个节点的交易量、耗时、成功率、响应率）、开业情况、批量交易状态等

5、客户体验层：

-客户访问速度：页面响应时间、拨测登录、普通页面渲染时间、重要接口响应时间等

具体的监控指标内容与阀值参考的明细不同的行业，不同的系统会有不同的认识，这里不细列。

（二）指标权重与阀值分级

在分解具体指标前，需要重点强调一下监控指标的指标权重、阀值分级与上升机制问题，做监控的人知道“监”的最重要目标是不漏报，为了不漏报在实际实施过程中会出现监控告警过多的困难。如何让运维人员在不漏处理监控事件，又能快速解决风险最高的事件，则需要监控的指标需要进行指标权重、阀值分级与上升机制：

-指标权重：

监控指标的权重是为了定义此项监控指标是否为必须配置，比如应用软件服务、端口监听是一个应用可用性的重要指标，权重定义为一级指标；对于批量状态，则由于不少应用系统并没有批量状态，则定义为二级指标。通常来说一级指标将作为监控覆盖面的底线，通过设置好权重，一是为了让运维人员知道哪些监控指标必须确保覆盖，同时加以引入KPI考核；二是为了让监控平台建设人员有侧重的优化，实现一级指标的自动配置，无需运维人员手工配置。

-阀值分级与上升机制：

有监控指标，就需要针对监控指标定义阀值，监控阀值的设立需要有分级机制，以分通知、预警、告警三级为例：通知需要运维人员关注，比如“交易系统登录数2000，登录成功率95%，平时登录数基线500，登录成功率96%”，由于登录成功率并未明显下降，可能是由于业务作了业务推广，运维人员只需关注当前应用运行状态再做判断；预警代表监控事件需要运维人员处理，但重要性略低，比如“CPU使用率71%，增长趋势非突增”，管理员受理到这个预警可以先设置为一个维护期，待当天找个时间集中处理；告警则必须马上处理的事件，比如“交易成功率为10%，平时为90%”这类监控事件己反映出交易运行问题。

对于升级，是指一个预警当长时间未处理时，需要有一个上升机制，转化为告警，以督办运维人员完成监控事件的处理。

阀值的分级需通过流程管理加以落实。

（三）指标基线

当前运行状况是否正常需要用运行情况与阀值作比较，但实际实施过程中会发现一个固定的阀值会导致不少监控误报，比如业务运营大促与非运营活动日、非工作日与工作日、白天与晚上的运行值都会有不小的差异，所以需要建立一个动态的指标基线，当前运行值与动态基线的偏离度大小来判断是否为监控事件。指标基线的建设过程中有几个方面需要关注：

-基线的自我学习：

前面己提到指标的基线是动态的，基线动态就需要对系统运行的情况按一个指定的时间间隔粒度进行学习，理论上运行学习的时间越长，基线越准确（但如果业务做了推广，历史的基线数据则需要降低权重）。

-基线指标的组合：

有些情况判断一个监控指标是否是事件，需要将多个指标放在一起看才能判断。比如WINDOWS集群下的SQL SERVER进程内存长期都占95%以上，如果将内存作为基线画线，就会是一条高负载的线，所以可以考虑将CPU、内存两个指标合并作为一个基线指标。

另外，还可以用不同时间段与指标组合的方式，比如按节假日与非节假日、按星期几、按白天与晚上设计不同的基线。

-性能：

基线是由指定时间段的大量历史数据不断迭加组合，间隔的时间越短需要的性能越高，尤其是当基线的组合类型丰富的情况下，需要大量的计算资源，选用一个合理的计算方案就显得很重要。我们原来采用单库跑基线，只能做到30分钟一个点，目前采用分布式数据库结合缓存方式设计性能，未来根据基线运行的情况再考虑是否选用大数据流计算等技术框架。

-基线的人工调整：

系统运行过程中难免会因为业务运营推广等导致历史基线不能反映指标是否合理，这时候需要有一个人工调整基线的入口，运维人员可以重新绘制基线、减少对历史数据的参考权重等。

另外，人工智能这么火，也提一点通过机器学习来实现监控基线的思路（思路还不成熟，仅供参考）：

将应用运行健康与不健康的样本数据汇总，样本中不同指标的指标数据作为不同的变量，结合不同的算法，通过调参学习后，得到运行状态好坏的基线。这样，就可以将基线做一个监控运行状态的服务，把实际运行的多个监控指标数据关给基线服务，基线服务返回当前服务运行好坏。

监控指标先总结到这。