近年来，随着计算机技术的飞速发展，以及行业信息的共享，传统企业的运维己不再固步自封，日新月异的计算技术发展推动着企业云平台的建设，云平台的计算能力为大数据分析提供了基础，而云平台与大数据分析又将推动运维人工智能的发展。放眼云、大数据、人工智能的运维发展方向的同时，作为运维的生命线，安全生产保障的生命线仍需强调。作为传统企业的安全生产保障，主要以“监、管、控”为核心，其中“监”则主要指的是监控。

本文将把笔者在工作过程中积累的监控体系建设知识进行总结，梳理成体系，思维导图如下：

监控体系分层

概述

传统企业的运维经过多年的积累，往往己沉淀下来不少监控工具，有不同专业条的工具，如基础设施、硬件、软件、安全等；也有不同类型的工具，如基于日志、数据库、中间件、操作系统、网络报文等。对于这些工具，我们采用以下方式处理：

建立集中监控平台：在一体化运维体系中，监控平台贯穿所有环节，它起到了生产系统涉及的软硬件环境实时运行状况的“监”，监控平台事件驱动的特性也为一体化运维体系起到神经网络驱动的作用，进而进行了“控”，另外，监控平台优质的运维数据可以作为运维大数据分析的数据源，实现运维数据采集的角色。为了提高投入效率，减少重复投入，需要建立集中监控平台实现统一展示、统一管理，支持两地三中心建设，具备灵活的扩展性，支持运维大数据分析。

原有的监控工具保留为主：当前并没有哪一个监控工具可以覆盖所有生产系统的运行指标，己沉淀下来的监控工具往往是当前生产系统深度定制的工具，具有存在价值。另外，虽然监控平台从WEB、APP、到DB均采用了多中心双活分布式架构部署，但为了保证监控覆盖能力，部份重要的环节仍建议不仅限一套监控工具。

各专业条线对各条线的监控负责：各专业条线是最清楚自己需要什么监控的团队，各专业条线对监控覆盖率负责，监控平台的建设方负责平台体系的建设，提供基础技术支撑。

工具间整合：不同的专业条线、不同的分析技术可以有不同的监控工具，采用这种多点开花的建设方式更有助于监控面与深度的完善，所有的工具最终需要进行标准化的整合。

基于上面4个处理思路，为防止监控建设失控，减少重复建设、明确主要的建设目标，我们需要对监控工具进行体系化管理，体系化管理首先要做的就是进行监控体系分层。

分层方式

相信每家企业对于监控分层体系都会有各自的划分方式，以下是以专业条线方式分层：

基础设施层：包括运营商专线、机房（机房内的设施，比如制冷、安防等）、网络设备，基础设施层的监控分为状态、性能、质量、容量、架构、流量分析等几个层面。

系统服务器层：包括系统服务器、存储等服务器的可用性状态。

系统及网络服务层：主要是指操作系统、系统软件、网络软件的使用情况。

应用服务层：主要是针对应用服务可用性、应用营业状态、应用性能、应用交易量分析几方面。

客户体验层：包括两块，一是客户访问速度；二是功能是否正常，具体指的是全部、局部、个别用户或终端访问情况，不仅包括业务系统是否能访问，访问的速度是否快，还包括业务逻辑的验证功能是否正常。

各层职责

基础设施

状态监控：包括机房供电、空调、网络设备的软硬件状态，如设备状态等；

性能监控：包括设备的性能情况，比如CPU、内存大小、session数量、端口流量包量、内存溢出监控、内存使用率等；

网络监控：包括设备错包、丢包率，针对网络设备以及网络链路的探测延时、丢包率监控等；

容量监控：包括设备负载使用率、专线带宽使用率、出口流量分布等；

由于基础设施硬件往往己有设备健康性的检测机制，建议向这类厂商提要求，将设备的运行事件主动送到监控平台整合。

服务器层

存储：包括存储设备，以及设备上的硬盘读写错误、读写超时、硬盘掉线、硬盘介质错误；

服务器：内存（内存缺失、内存配置错误、内存不可用、内存校验）、网卡（网卡速率；电源：电源电压、电源模块是否失效）、风扇（风扇转速等）、Raid卡（Raid卡电池状态、电池老化、电池和缓存是否在位、缓存策略）；

虚拟机：vcenter等

容器：Docker等

存储、物理设备、虚拟机等建议参考基础设施层由厂商主动汇总事件到监控平台，由于容器方面的监控工具并不多，则需根据实际情况选择是否借鉴开源的工具进行自研。

系统服务层

系统服务层的数据主要包括操作系统、中间件、数据库，以及其它开源分布式中间件等工具，这方面包括很多，以操作系统为例，包括：CPU（CPU整体使用率、CPU各核使用率、CPU Load负载）、内存（应用内存、整体内存、Swap等）、磁盘IO（读写速率、IOPS、平均等待延时、平均服务延时等）、网络IO（流量、包量、错包、丢包）、连接（各种状态的TCP连接数等）、进程端口存活、文件句柄数、进程数、内网探测延时、丢包率等。

在分析系统服务层的数据消费情况时，可以通过分析系统性能情况，客观衡量业务负载高低情况，并结合扩缩容调度，实现业务的负载和成本间的平衡。可以根据服务器所在业务层级（接入层、逻辑层还是数据层）的不同，设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则，设置业务模块（由相同功能的多个服务器构成的业务集群）的扩缩容规则；由系统计算出服务器、业务模块的负载情况，决策出是否需要扩容或缩容，触发业务模块的扩缩容操作。

这一层的工具主要采用引入成熟工具或自研的方式，可选的空间比较大，只要覆盖面够广、支持灵活的二次定制开发，应该问题都不大，建设过程中，我认为中间件与数据库两块是值得让DBA、中间件管理员深度挖掘监控指标覆盖面。另外，在互联网分布式架构的推动下，传统企业也逐步使用一些分布式中间件，比如分布式数据库中间件，内存数据库、消息队列等。由于对于这类开源中间件，传统企业在技术上弱于互联网企业，且监控工具并不多，需要重点投入资源进行相关监控指标的开发。

应用服务层

服务可用性监控：如服务、端口是否存在，是否假死等；

应用营业状态监控：指应用的状态是否满足业务开业状态；

应用性能：应用处理能力，比如交易量、成功率、失败率、响应率、耗时；

应用交易：比如交易主动埋点、交易流水、ESB等；

应用服务层监控可扩展的面与深入的度都有很大空间，以下是部分应用监控点：

客户体验层

比如测速系统以及模拟用户访问的方式：

以模拟用户访问为例，通过模拟用户访问业务并校验返回数据结果，监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统。不仅仅是接入层（网站类业务是否能访问，访问的速度是否快），业务逻辑的验证就涉及到登录鉴权、关系数据自动化获取等。

监控整合

监控的分层方式促进了每一个专业层的监控覆盖面与深度，防止建设失控，但也带来一个管理上的副作用，所以需要在事件、可视化、子系统、数据的整合，以减少管理成本。

在监控整合上，主要从事件汇总、统一可视化、监控数据汇总三方面进行梳理。

事件汇总

Google SRE解密一书中提过（大体意思如下）：监控应该尽可能简单地把需要人介入或关注的信息展示给运维团队，能通过自动化自愈解决、分析定位过程则不在一级视图提供。当前，能实现自愈的企业还比较少，或还在摸索建设过程中，所以我先讲讲如何让每天产生上亿条流水，触发上万次告警条件（同一告警如未解除会持续不断触发告警条件），来自各种不同工具、不同格式的的告警事件以尽可能简单的方式展示给一线监控团队。

第一部分监控分层中提到，原有的监控工具以保留为主思路，这些工具在运营过程中每天都会产生大量事件，为了实现监控集中展示，集中管理，需要建设一个事件汇总的模块实现事件统一汇总，并对不同层面、不同专业角度的事件进行收敛，关联分析，更全面的感知系统运行状况。

可能上面讲得还不够清楚，举几个例子：

Example01：从可视化角度看，不同的工具有不同的监控事件展示界面，多个运维视图增加了运维技能要求，需要更多的人力去管理生产；

Example02：缺少对各类事件进行汇总与数据分析，无法反映生产系统整体的运行状况，如能将这些事件数据汇总起来，比如物理层的拓扑，则可以直观地管控应用状况；

Example03：同一个生产问题往往会带来多个维度的生产运行问题，比如一台物理机宕机，在这台物理机上的虚拟机都会出现网络、操作系统层面可用性、应用可用性、交易级状况、应用性能、客户体验的告警，如果监控指标足够丰富往往会有上百条以上，不能准确、快速定位问题根源。

Example04：每天能触发阀值的告警很多，以经验的方式很难让一线监控团队无时无刻能准确的定位哪些是高优先级的告警，比如磁盘空间到了70%的确需要有人去关注，评估是否进行数据清理、扩容，但这类告警属于低优先级的事件。

从上面4个例子可以看到，事件汇总模块需要有几个基本要求：

事件汇总：汇总不同层次、不同专业条线、不同类型事件是监控集中管理的基础。

事件收敛：前面提到同一个故障会触发多类指标的告警，同一个指标在故障未解除前也会重复产生大量的告警事件，如果将全部事件都展示出来，那对于监控处理人员将是灾难性的，所以需要进行事件收敛。

事件分级：对于不同的事件需要有适当层次的事件分级，事件升级的策略。事件分级是将事件当前紧急程度进行标识显示，事件升级是对于低级的事件当达到一定的程度，比如处理时间过长，则需要进行升级。

事件分析：事件分析是建立事件的关联关系，关联分析可以从纵向和横向关系进行分析，纵向是指从底层的基础设施、网络、服务器硬件、虚拟机/容器、操作系统、中间件、应用域、应用、交易；横向是指从当前的应用节点、上游服务器节点、下游服务器节点的交易关系。事件分析是形成故障树，自愈的基础。

对于事件分析重点在于关系模型的建立，互联网公司有不少标准化的方案，但我个人认为需要开发团队介入改造的标准化不可控，所以另外一方向是针对企业内部特点，以CMDB、应用配置库为中心，或以节点型的系统为中心去建立关系模型，具体介绍见后面第三部分。

高性能：为了实现实时监控，需要事件汇总模块具备高性能。

对外提供采集事件数据接口：监控作为一体化运维体系的一部份，需要对外提供服务化接口，支持事件数据的采集。

统一可视化

不同监控工具有着不同界面，不同的操作方法，对工具的掌握程度依赖于运维人员的经验，监控管理很难形成标准化，不利于监控的集中管理、释放人力成本。所以，监控事件汇总后，需要有一个统一的可视化，支持统一展示、多类型展示形式、多维用户视角、支持按需订阅的特点。具体包括：

支持事件的统一展示：支持不同角色用户管理不同的事件，包括事件的受理、分派、督办、升级、解除、转工单等闭环操作，无需在不同工具上多次操作。

多类型的展现形式：PC电脑的web端，移动手持端，大屏展示，为了支持可视化的快速开发，以及低成本的过渡到移动手持端，建议采用H5的技术选型。

多维用户：根据不同机构、不同用户的关注点，比如一线运维主要关注实时告警，二线运维主要关注事件丰富与故障树等辅助定位，值班经理主要关注当天监控事件处理情况，团队管理者主要关注团队内监控事件与重要业务系统运行状况，主管经理主要关注整合的运行情况与人员处理情况，开发人员需要有协助处理的视角数据等。

支持用户订阅展示：针对不同的业务运营场景、不同的用户进行布局、推送数据、监控指标的订阅式展示，比如，双十一或秒杀的运营活动，需要关注几十个OS的资源情况，各个OS上的交易、性能情况，如果每一个指标一个窗口，需要看几十个窗口；如果只看告警信息，又无法观察到趋势；所以，需要支持多指标合并在一个视图页面的订阅功能。

数据整合标准

关于数据整合，这里不再复述不同监控工具事件数据的整合，主要从报文、日志、数据库流水几个角度分析：

1）报文解释

报文解释标准，以天旦BPC为例做个介绍：

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

2）日志结构标准

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

3）数据库流水标准

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

4）其它思路

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

监控指标

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

指标分类

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

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

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

指标权重与阀值分级

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

1）指标权重

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

2）阀值分级与上升机制

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

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

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

指标基线

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

1）基线的自我学习

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

2）基线指标的组合

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

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

3）性能

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

4）基线的人工调整

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

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

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

监控事件

监控事件

监控事件反映的是IT基础设施、中间件、应用程序、业务流程等运行过程中发生的问题。监控系统通过采集运行数据，通过数据判断规则生成事件，监控事件还涉及事件的处理（比如事件丰富、收敛等）、事件的关联分析，并驱动事件的解决。

以下是监控事件处理的一般流程图：

前面提到了事件整合，下面主要讲讲事件关联、事件应急、事件分析、智能处理方面的建设思路。

事件标准

事件数据模型

事件数据主要包含数据头信息、静态丰富信息、事件现场信息、知识库信息、关联信息。

静态丰富信息：包含描述丰富信息、拓扑丰富信息，描述丰富信息主要包含相关人员描述信息、服务器描述信息、工单信息等，这块丰富数据可以通过CMDB消费获取，这部份丰富数据有助于事件处理过程中关联分析。

事件现场信息：包含指标信息、性能信息、系统资源信息等，这部份信息主要是反映事件的现场数据。

知识库信息：主要指相似历史事件及其处理方式等信息，比如“建议如何做，己自动进行了什么动作”等。关联信息主要包含从属事件信息、关联影响信息。

事件分级标准

前面提到了事件分级的问题，分级是将事件当前紧急程度进行标识显示，事件升级是对于低级的事件当达到一定的程度，比如处理时间过长，则需要进行升级。我们将监控事件等级事件级别分为通知、预警、故障三种：

通知：指一般的通知信息类事件。

预警：指已经出现异常，即将要引起生产故障的事件。

故障：指已经发生问题，并且已经影响到生产流程的事件，如果需要进一步细化故障级别，可以分为一般故障和紧急故障：一般故障不需要紧急处理的故障，紧急故障需要管理员紧急处理的故障。

事件细分的粒度需根据各企业团队的管理要求而定。

事件关联

事件压缩及收敛

事件压缩及收敛就是为了减少事件数量，提高事件定位能力。

监控采集数据后，根据具体的单指标或多指标的规则判断是否触发事件，如触发事件，则发送事件接收器。为什么不直接通过可视化方式马上将匹配到的事件信息呈现给监控人员呢？那是由于监控数据采集是实时采集，但事件的解决可能并非马上解决，为了减少重复性的告警数量，需要由事件处理引擎进一步压缩处理。比如每2分钟采集一次文件系统容器数据，当某个文件系统容量超过70%后，触发了预警阀值，但这个文件系统是缓慢增长，计划在当周的扩容窗口集中变更，如果不对事件进行处理，那每2分钟就会有一个预警，产生预警泛滥，所以这时需要对事件进行压缩，比如针对事件来源、关键字组合等规则进行压缩，并记录事件发生次数。

有了事件压缩还不够，因为触发事件的指标往往是相互关联的，这就需要对多项指标关系进行分析，减少相同问题产生的事件。比如这个应用场景：

NAS监控：NAS文件系统在各OS上都会有监控，一个NAS文件系统出问题时，每个服务器的NAS文件系统监控都会报警。如能对NAS进行挂载关系梳理，同一NAS的报警可以大量收敛。

进程、端口、通讯检测：一个进程宕掉时，该进程启动的端口、关联系统与该进程端口的通讯等都会同时报警。如能对进程、端口、通讯关系进行梳理，同一个进程引发的进程、端口、通讯监控事件也能收敛明显。

事件丰富

事件丰富包括事件描述丰富（通过CMDB丰富、拓扑丰富）、事件现场丰富（指标信息丰富、APM信息丰富、系统资源信息丰富）、知识库丰富，提高运维人员分析问题的能力。

事件主要丰富方法如下：

与第三方监控系统对接，获取事件相关信息进行丰富。如与CMDB系统对接，获取服务器等相关配置信息进行CMDB数据丰富；

根据拓扑关系模型，进行拓扑丰富；

指标信息丰富：获取事件发生前后一段时间内的相关指标信息数据（如CPU/内存等），进行指标信息丰富；

相关事件丰富：根据拓扑关系模型、应用关系关联模型、交易流行关联模型将相近事件时间范围内的事件进行丰富展示；

知识库丰富：建立事件处理方案知识库，记录事件处理的方法和流程，为事件处理人提供参考依据，以及为后续自动化运维提供理论支撑。

下面这个是我们做的一个事件丰富，主要包括几块内容：

事件涉及的软硬件的基本配置信息、人员信息，这一块是基本CMDB的数据消费；

事件报警的主体信息，包括时间、事件描述、事件可能原因、事件处理情况等；

事件应急处理及流程工单链接；

事件主体信息的具体指标数据展示，以及指标变化趋势；

最近30分钟的事件情况，以备分析是否受其它事件关联影响；

该事件所在OS的CPU、内存、IO的信息；

事件涉及的性能信息，比如交易量、成功率、交易耗时；

事件处理进展。

image.png

事件扩散

事件发生之后，监控系统需要能自动分析事件的关联信息，帮助运维人员尽可能的还原事件现场，提高分析问题的能力，关联信息主要有纵向和横向的关系，其中纵向的关联是把基础设施、网络、系统、应用域、应用、交易关联起来，任何一个环节出问题，向上计算出波及范围和受影响系统；横向的关联是以交易为中心，计算上下游的交易节点。下面分别是两个关联：

纵向关系：

image.png

横向关系：

image.png

事件触发

系统在设置报警策略时，可针对指标进行触发条件设置，触发条件按照类型分为阈值触发、基线触发、智能预测。系统根据不同的触发类型设置，采用的判断方式也不一样。具体明细如下：

阈值触发

系统支持指标的阈值触发设置，当指标值达到设置的阈值时即可进行报警。

阈值的设置范围只能在该指标的数值范围内进行设置。

阈值在设置时需要指定数值单位，防止数值因单位不同出现判断错误。

在设置阈值时系统支持实时查看指标当日折现图和历史基线，帮助运维人员正确判断阈值的设置范围。

基线触发

系统支持指标的基线触发设置，当指标值达到设置的基线时即可进行报警。

基线设置可按照昨日基线、月基线、周基线进行设置。

系统支持在选定的基线基础上进行上浮或下沉幅度的设置。

在设置基线时系统支持实时查看指标当日折现图和历史基线，帮助运维人员正确判断基线的设置范围。

系统支持按照平均基线进行设置。

基线设置时需要有一定的历史数据作为依据。

智能预测

智能预测主要是通过历史数据的分析，通过人工智能算法预测未来可能出现的问题，这一块是未来监控事件优化的一个方向。

事件应急

应急恢复

运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。通常来讲应急恢复的方法有不少，比如：

服务整体性能下降或异常，可以考虑重启服务；

应用做过变更，可以考虑是否需要回切变更；

资源不足，可以考虑应急扩容；

应用性能问题，可以考虑调整应用参数、日志参数；

数据库繁忙，可以考虑通过数据库快照分析，优化SQL；

应用功能设计有误，可以考虑紧急关闭功能菜单；

还有很多……

监控系统的事件丰富过程中需要尽可能关联上述的一些应急手段，供运维人员快速应急，比如服务启停工具、切换工具、程序回切工作等，比如下面这个应用服务启停工具例子：

image.png

现场保护

故障处理中，理论上应该在应急前进行现场保护以备问题原因排查的跟进。现场信息主要包含进程内部状态信息、日志信息。实际应用过程中可以结合工具进行现场保护，仍以服务启停工具为例，支持获取进程线程镜像信息、进程内存镜像信息及GC日志信息。

image.png

问题排查

是否为偶发性、是否可重现

故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。

但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。

是否进行过相关变更

大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

是否可缩小范围

一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

关联方配合分析问题

与第3小点结合避免各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。

是否有足够的日志

定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。

是否有core或dump等文件

故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如COREDUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。

应急文档

故障的表现虽然形式很多，但实际的故障处理过程中，应急措施往往重复使用几个常用的步骤，所以应急文档首先要针对这些常用的场景，过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。以下是我觉得应用系统应急方案应该有的内容：

系统级

能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。

服务级

能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。

交易级

能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。

沟通方案

沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。

另外，有了应急方案，如何让运维人员持续去更新是难点。我认为要解决这个难点，需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。

持续优化

整体思路

监控系统建设目标是完善“监”能力，增加“控”的能力，这章提到的持续优化主要是针对“监”能力的落实，归纳起来就是“不漏报，少误报”，可以针对不同的阶段量化目标，比如60%告警即故障，80%故障来自监控。

措施

目标分解

不漏报

漏报可以从两个层面看，一个是监控工具不具备某一方面的监控能力；一个是监控工具具备监控能力，但因为使用者使用问题导致未覆盖监控。前者需要完善监控能力，比如针对生产故障举一反三式的优化，或由不同专业条线主动增加监控能力，后者则需要考虑几个问题：

管理上有没有要求指标的100%覆盖率；

覆盖率的要求是否确实可以落地，或功能上是否设计极不友好；

100%的覆盖率是否从技术默认设置，如果技术无法默认设置，能否从技术上主动发现；

前面两个问题需要从管理手段上解决，最后一个问题需要在监控系统中解决，即尽可能让需要覆盖的监控指标从技术上落地，减少对运维人员主动性上的依靠，同时监控系统要快速从技术上响应新的监控指标的落地。

减少误报

误报带来的问题也很大，大量、反复的误报告警会让运维人员麻木，进而忽视监控报警，错过了真正的监控事件的处理，所以监控误报情况也需要重视。

心得

以下是在监控优化上的一些措施心得供参考：

第一阶段：减少监控报警数量

目标：每周报警总量上下降60%

主要工作：

抓突出的报警指标，调整阀值，比如CPU、内存、空间、应用性能这几块大头，如果阀值不合理将带来大量告警，对这几类指标阀值做优化会有事半功倍的效果；

抓每个指标突出的组、系统进行针对性整改，可能就是某个团队或某些管理员不重视监控，解决刺头的成效也很明显；

针对重复性的告警，优化监控系统，减少重复报警。

第二阶段：减少监控误报率

目标：60%告警即故障（排除磁盘、表空间类）

主要工作：

区分监控级别，告警即故障：分析确认哪类监控报警必须作为事件处理，并将交易量监控设置为告警，非故障调整为预警；

所有预警即关联工单，对预警工单阀值进行分析调整；

优化监控短信内容，提高短信对事件定位；

完成动态基线的监控功能上线功能，提高监控准确率；

完成应用部署与监控维护期关联，减少未设置维护期导致的监控报警；

完成应用启停集中处理，减少应用启停带来的维护期报警。

第三阶段：提高监控对故障的覆盖率

目标：80%故障来自监控

主要工作：

每周分析生产事件的发现环节，对于非监控发现的故障进行专项分析；

其它方案（针对第一、二阶段实施情况完善）

第四阶段：提高监控事件处理效率

目标：监控告警1小时内关闭

主要工作：

对监控报警耗时进行分析，并通报

针对无法快速恢复的监控报警优化功能处理

其它方案（待定）

团队

因为有持续优化的工作，所以最好能够有一个横向的监控优化团队，区分于监控系统工具建设团队，作为监控的使用角色，这个团队有几个目标：

将持续优化的工作进行落地；

作好数据分析，比如监控的事件量是否突增，某些系统的事件是否陡增，误报量是否过多，故障哪些不是通过监控发现，未通过监控发现的故障是否完成监控覆盖面整改，监控功能有哪些不友好等等。