监控体系建设（完整）(3)

市场上有很多APM,大体可以分为主动模拟拨测、页面插入代码监测、客户端插件采集、服务端代理收集、服务端旁路报文监听(详细的分类可以见公众号另一篇关于APM的文章).天旦的BPC采用服务端的网络层旁路抓取一份报文,通过预先定义好的解码策略,解出了一份数据格式良好的数据源.在这份数据源之上可以进行监控、运维数据分析等运维场景的使用.由于BPC报文解码配置设计比较简单,支持秒级(预计17年将有毫秒级的产品出来),且对应用服务性能无影响,用旁路报文解释的方式作为数据输入标准成为一种值得推荐的方式.

2)日志结构标准：

日志结构标准,主要分两类,一类是直接建一个日志分析平台,比如国外的splunk、国内的日志易,或者开源的ELK(日志易也是用了ELK);另一类是重构日志标准组件,比如重构java企业应用中经常使用的log4j开源包的标准输出方法,对日志结构进行整合,并通过异步消息的方式将日志发送给监控平台,再提供可视化的IDE对不同系统的日格式进行进一步整理,将需要的数据抽取整合.

3)数据库流水标准：

在监控数据库流水中,也分两类,一类是建立标准的运维流水表,监控直接读取这些流水进行监控或分析；另一类参考重构log4j的思路,对jdbc的包进行重构,将数据库执行语句,以及语句执行过程中的开始时间、结构时间、返回状态进行记录.第一类我们用得比较多,当前的交易级的监控主要采用这种方式进行,第二类目前仍处于思路阶段.

4)其它思路：

其实针对日志LOG4J、数据库JDBC这两种方式从思路看都是从节点类的模块进行,往同类扩展,可以针对标准应用中间件、WEB等模块进行处理；往大的扩展,则比如企业ESB类的应用系统可以作用标准的数据整合.这些节点类的模块进行数据整合标准往往可以有事半功倍的作用.

三、监控指标

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

1、指标分类

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)客户体验层：

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

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

2、指标权重与阀值分级

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

1)指标权重：

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

2)阀值分级与上升机制：

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

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

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

3、指标基线

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

1)基线的自我学习：

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

2)基线指标的组合：

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

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

3)性能：

（编辑：ASP站长网）