阿里QA导读：作为一个测试开发同学，我们日常中充斥着各种监控报警，但似乎还从未真正完整地总结过该如何分析、设计、布置这些五花八门的风险“吹哨人”。今天，就让这篇干货满满的万字长文，带大家一起看一看如何系统地构建监控报警。
前言
系统故障和业务资损时有发生，监控报警作为事中发现的主要手段被大家熟知。但就像是熟悉的陌生人，对于监控报警有种知道却又说不出所以然的感觉，很少进行总结思考：面对五花八门的监控报警实现方式，没有进行总结和抽象；时常没有事先分析、整体设计、提前布置监控报警，往往发生血泪故障后，才后悔之前没想到要加相关监控。
趁着做了一段时间的稳定性保障工作，这次就来简单掰扯掰扯、尝试整体的观摩一下监控报警：尝试分析监控报警的业务流程，梳理监控报警的各个环节的关键问题，以及总结关键问题对应的解决方案。
最终目的是：
通过分析、抽象、总结，对监控报警有整体上的认识；
能演绎使用，能实际调整生产环境的监控报警，使其更完善、合理、有效；
解决诸如如何构建完善监控报警、如何设计监控大盘等等日常问题；
第一章 监控报警是什么？
★首先，先明确一下什么是监控报警？
1. 什么是监控报警
监控报警是对现实或者虚拟的对象进行「指标测量」和「异常检测」。「指标测量」能可视化地展示对象的数值状态，「异常检测」则通过报警通告对象出现异常状态。
1）监控：对现实的或虚拟的对象进行「指标测量」，并通过可视化的方式呈现输出
其中「指标测量」是：持续性的对指标进行数值采样，然后对数据进行聚合、计算等处理。
2）报警：对现实的或者虚拟的对象进行「异常检测」，报警就是对一些异常事件进行通告
其中「异常检测」指：监控数据按一定的规则分布，当数据分布不符合规则或者满足了另一些规则，则认为发生了某些异常。计算机系统的异常检测一般是基于时序，检测出明显差别与其他数据点的数据。
第二章 目的、作用和评价
1. 目的
★我们知道，监控报警的目的是「提升系统的稳定性」。如图，监控报警在稳定性建设中，是「事中发现和定位问题」的主要手段。
2. 作用
★监控报警在稳定性建设中的作用：「实时观测系统服务的状况和可用性，及时发现、通报和定位问题」
包括但不限于：
实时观测，了解服务的状况
故障检测，发现服务的异常
性能分析，通过观测数据变化趋势、量化业务和系统运行状态，评估服务性能
容量规划，结合需求（流量等变化）和供给（CPU、MEM、IO等资源）的变化，评估规划系统容量
3. 评价
★要想建设好监控报警，首先需要知道如何评价监控报警的好坏。评价监控报警，一般可以从「质量、成本、效率」三个方面来考量。
1）质量。包括监控质量和报警质量
●监控质量关注：对象的「覆盖率」和对象指标的「齐全度」
○覆盖率是站在全局视角，考量监控覆盖哪些对象。对于覆盖率，可以通过分层梳理对象来提高。
○齐全度是站在对象视角，考量监控对象的哪些指标维度。对于齐全度，可以结合黄金指标（延迟、错误、流量和饱和度）来分析。
●报警质量关注：「误报率」和「漏报率」，即准确率(1-误报率)和召回率(1-漏报率)
○实际往往在漏报率和误报率之间作出折衷，用大量的误报来换取少量的漏报 。
2）效率。包括使用效率和即时性
●使用效率关注：监控数据和报警信息被人「接受利用的效率」
通过提升覆盖率和齐全度、进而降低漏报率，但是往往在故障发生时、会造成报警风暴，降低监控报警的效率。
●时效性、即时性关注：监控数据的「实时展示」和报警信息的「即时反馈」
通过提升监控报警的即时性，往往会降低报警的质量、降低报警的准确率。
因为即时性提升，意味着每次处理的数据少、数据的扰动大，通过数据趋势的判断故障也更不准确，导致报警准确率的降低。
3）成本。包括系统成本和人力成本
●监控成本：数据生成、存储、计算等的「系统成本」，监控配置维护的「人工成本」
●报警成本：短信、钉钉、电话外呼等的「系统成本」，报警响应处理的「人工成本」
★了解了监控报警的目的、作用和评价标准，然后开始分析监控报警的「业务流程和关键环节」
只有整体的了解清楚业务流程、关键步骤和要素，才能了解其中的问题、进而分析总结出对应的解决方法。
第三章 监控报警的实现流程和关键环节
★分析完成系统监控报警的一般流程是什么样的？
1. 业务流程和关键环节
1）业务流程
基于对监控报警是什么的理解，也容易得到监控报警的简化的业务流程：
-> 监控对象：梳理出要监控对象
-> 指标维度：对监控对象进行数值表征，即对对象进行指标和维度分析
-> 处理数据（监控）：
-> 数据采集：采集、上报指标数据
-> 存储计算：存储、计算指标数据
-> 数据呈现：呈现、输出指标数据
-> 检测异常（报警）：
-> 报警规则：指标数据异常检测规则定义
-> 异常检测：指标数据检测异常
-> 报警通告：发出报警信息
2）关键环节
简化归纳后，有如下几个关键环节：
●监控对象梳理
●指标和维度分析
●监控呈现
●异常报警
从上面业务流程分析，可以很容易的得出如何设计一个质量、效率和成本更优的监控报警：
★【方法论初探】
首先，分析出哪些对象需要被监控
其次，分析出监控这些对象的哪些维度和指标
再次，选择综合较优的指标采集方式、以及合适的监控呈现方式
最后，设置合理的报警策略和通知规则
下面，就一步步的看如何做好这些环节。
第四章 关键环节分析
1. 监控对象梳理
★首先，分析出哪些对象需要被监控 —> 需要回答如何梳理监控对象的合集？
1）如何梳理监控对象合集？
问题：即如何站在全局视角，全面分析监控哪些对象、进而提升监控覆盖率
回答：分层。分析构成该系统的“所有”层级的关键对象
一般比较完善、体系化的监控会涵盖这几层
分层 |
分层说明 |
分层主要对象 |
分层可用于监控对象 |
业务层 |
业务本身 |
业务逻辑 |
业务逻辑、业务核心链路。如：电商场景的添加购物车、下单、支付等关键环节 |
应用层 |
业务的“系统”承载 |
应用本身 |
应用本身。如：进程本身状态和API接口 |
服务依赖层 |
业务的服务依赖 |
下游依赖 |
下游依赖的服务。如：圈人平台，风控服务 |
系统依赖层 |
业务的系统依赖 |
中间件、基础服务 |
中间件和基础服务。如：HSF、TDDL、Tair、MetaQ |
物理层 |
业务的“物理”承载 |
集群、主机、容器、系统 |
可以用对象的子对象来替代。如：CPU、MEM、DISK-IO、网络、端口、容器CPU等 |
也容易看出，不同分层的监控对象，对业务稳定性的影响也是分层的。从业务层到物理层，对业务影响的相关性是依次降低，如：某台服务器异常了、并不代表业务一定受损，但是业务层逻辑（如下单）异常，业务一定是受影响的。基于分层，可以对应调整报警和响应的级别。
通过分层的方式对监控对象进行梳理，可以得到第一个关键要素「监控对象」：
即分层的对象合集，一个能表征业务健康状况的实体“全集”，并且是分层、体系化的实体全集。
【补充一点】
监控对象分层与黑白盒监控
【黑盒监控】一般对应「业务层」。即关注业务层指标来判断系统是否异常了
●站在用户角度、系统之外来看系统，关注“系统出问题了吗？”
●观测系统在用户视角的数据和现象。通过上帝视角关注现象、判断系统是否发生异常
●常用外部探活、端到端功能监控、数据核对等方法来实现
如：一个人的精气神差（人体系统之外观测到异常）-> 系统内部原因是头疼
如：观测用户下单数
【白盒监控】一般对应「应用层、依赖层、物理层」。即关注系统内部指标来判断哪里出问题了
●站在系统内部来观测系统，关注“系统哪里出问题了？”
●通过关注系统内部的组成部分是否异常，判断系统哪里出了异常
●常用日志、主动上报指标数据等方法来实现
如：一个人的头疼（人体系统之内观测到异常） -> 系统外部表现是精气神差
如：观测下单流程的各环节是否有异常和超时（进一步定位超时是因为数据库负载过高导致的）
2）如何使用分层对象？
问题：如何使用梳理出的分层对象？
回答：通过分层对象，对当前监控配置逐层检查、查缺补漏，进而提升监控覆盖率
结合实际，以 sunfire 监控平台为例，根据梳理的分层对象，逐层核对、分析和调整需要监控的对象
●物理层&中间件层
○物理层：通过梳理知道，监控对象就是主机的CPU、MEM、DISK-IO、网络等，应用接入sunfire，就支持对物理层的监控报警。
○中间件层：监控对象就是服务依赖的基础中间件。同样的，集团的sunfire支持HSF、TDDL、TAIR、NOTIFY、METAQ等中间件的监控报警。
●下游依赖层
○监控对象就是：应用依赖的下游服务。可以根据应用的实现，逐个梳理出来，然后结合该下游依赖对外承诺的SLA进行监控报警设置。具体监控报警指标，详见 2. 对象指标维度分析。
●应用层
○应用本身的存活状况，对象包括：服务进程、监听端口等
○应用对上游提供服务的状况，对象包括：对外提供的接口API
●业务层
○关注业务的核心环节，需要根据不同的业务场景梳理监控对象和指标
2. 对象指标维度分析
★其次，分析出监控这些对象的哪些维度和指标 —> 需要分析如何表征监控对象、以及关注监控对象的哪些属性数据？
1）如何表征监控对象？
问题1：如何表征监控对象？
回答1：通过数字化表征监控对象，即通过指标和维度，来实现监控对象的分析和可视化。
何为数字化：通过数据对实体进行描述。数字化能更好的细分、量化、分析和管理被表征的实体。
如何数字化：对实体进行维度+指标的分析
● 指标（度量, Metrics）：指量化的数值，用于衡量事物发展程度。指标可评估水平层次、可以进行比较。
如网页浏览次数（PV）。
● 维度（角度, Dimension)：指看事物的角度，用于对比发展程度的好坏。维度有成员值、可枚举、且会维持一定的稳定性。
如网站浏览次数（PV），可以从不同时间去看，也可以从来源、从新老用户分群去看。
2）需要关注监控对象的哪些维度和指标？
问题2：站在监控对象的局部视角，如何分析添加哪些指标和维度、进而提升监控的齐全度？
回答2：可以通过“黄金指标” 进行指标和维度分析。
具体方法：
●首先，整理出四大类常用“黄金指标”，如下：
指标类型 |
指标类型描述 |
数量和质量 |
指标示例 |
流量类型指标 |
请求对象的量级情况（单位时间） |
次数、频率， 吞吐量、吞吐率 |
业务层， 如：页面或者功能的QPS、PV、UV 应用层， 如：QPS、PV和UV 服务依赖层，如：请求下游服务QPS 系统依赖层，如：Redis读写QPS 物理层， 如：磁盘和网卡IO |
错误类型指标 |
对象发生错误情况 |
错误数、错误率 |
业务层， 如：核心功能错误 应用层， 如：端口挂掉、进程假死 服务依赖层， 如：请求下游服务错误 系统依赖层， 如：写DB错误 物理层， 如：宕机数、网络丢包率等 |
延迟类型指标 |
请求对象所需时间情况 |
RT、超时数、超时率 |
业务层， 如：核心功能响应时长 应用层， 如：接口RT 服务依赖层， 如：请求下游服务RT 系统依赖层， 如：读DB RT 物理层， 如：IO wait |
饱和度类型指标 |
对象被利用的情况（总量有限） |
利用数、利用率 |
业务层， 如：业务能处理的阈值，如发券总数 应用层， 如：流量占比接口限流阈值等 服务依赖层， 如：请求量占比下游服务限流阈值 系统依赖层， 如：DB实例连接数、MQ消息堆积数 物理层， 如：CPU、内存、磁盘和网络利用率、文件句柄数 |
●其次，结合分层对象和四类指标，分析出各个分层对象的“具体指标”。例如下表：
分层 |
对象 |
四大类指标分析 |
具体指标示例 |
业务层 |
业务本身(链路) |
流量、延迟、错误 |
基础指标，如：流量（业务接口的出入流量等）、延迟（业务接口RT、超时率等），错误（业务错误码、业务链路是否可用等） 链路指标，如：交易线（购物车数量/成功率，订单数量/成功率，支付数量/成功率） |
应用层 |
进程本身 |
错误、饱和度 |
错误（端口、应用存活、panic、GC次数等）、饱和度（线程&协程数等） |
API接口 |
流量、延迟、错误 |
流量（QPS等），延迟（RT、超时数|率等），错误（成功数|率等）、tracing链路 |
|
服务依赖层 |
上下游依赖的系统 |
流量、延迟、错误、饱和度 |
QPS、RT、超时率|数、成功率|数等 |
系统依赖层 |
HSF |
流量、延迟、错误、饱和度 |
（生产消费）QPS、RT、成功率、线程数 |
TDDL |
流量、延迟、错误、饱和度 |
（读写）QPS、RT、成功率、连接数 |
|
Tair |
流量、延迟、错误、饱和度 |
（读写）QPS、RT、成功率、缓存命中率 |
|
MetaQ |
流量、延迟、错误、饱和度 |
（收发）QPS、RT、成功率、消息堆积数 |
|
物理层 |
主机、容器、系统 |
错误、饱和度 |
错误（宕机、坏盘、文件系统错误），饱和度（负载Load1|5|15） |
CPU |
饱和度、错误 |
使用率、运行队列长度(load1|5|15)、cpu硬件错误 |
|
MEM |
饱和度、错误 |
使用率(内存或者swap使用率)、内存分配失败|OOM |
|
DISK-IO |
饱和度、流量、错误 |
使用率、等待队列长度、读写磁盘次数（count）、IO错误 |
|
NETWORK |
饱和度、流量、错误 |
使用率(带宽使用率)、重传率、连接数、收发流量（rx|tx）、网卡收发错误数|丢包数 |
|
端口 |
饱和度 |
端口数 |
|
容器CPU |
饱和度 |
压制时间、次数 |
●最后，关于维度分析梳理：
监控报警一般采用时间维度，即比较监控对象的指标在时间序列前后的差异。
关于维度，异常检测和报警规则里会进行介绍。这里先简单介绍一下时间维度，如下表所示：
维度类型 |
维度类型说明 |
维度示例 |
时间维度 |
「同一个对象」的指标在「时间前后」的「纵比」 |
●单点值 * 环比 | 同比 ○当前值和过去一分钟的环比 ○当前值和昨天同样时刻的同比 ○当前值和上周同样时刻的同比 ○当前值和过去一段时间的中位数对比 ●窗口值 * 环比 | 同比 ○最近N分钟X指标值 ○最近N分钟sum(X指标) 和上M分钟sum(X指标) 对比 ○最近N分钟avg(X指标)和上M分钟avg(X指标)对比 |
属性维度 |
「多个对象」的指标在「相同属性下」的「横比」 |
（略） |
通过分析监控对象的维度和指标，可以得到：
分层对象合集、以及这些对象的「维度和指标」，一个以不同角度、不同指标数据去描述的分层对象的合集。
3）监控对象的指标和维度使用
结合实际以 sunfire 监控平台、以「下游依赖层和应用层」为例，看看如何根据分层对象和黄金指标进行监控配置。
●下游依赖层
○监控对象：即依赖的下游服务
○监控指标：结合黄金指标，我们可以关注流量（请求总量、QPS、QPM）、RT、成功率|数等。
最终获得的监控如下：
●应用层
○应用对上游提供服务的状况
■监控对象：对象是对外提供的接口API
■监控指标：结合黄金指标进行配置。配置过程和效果和下游依赖层的相同，只需要调整日志路径即可
○应用本身的存活状况
■监控对象：对象包括服务进程、监听端口等
■监控指标：服务进程探活，可以基于supervisord.log，监控应用重启情况下，supervisor输出日志的exited、gave up等关键字
●关于错误的监控，可以区分系统错误和业务错误（如下游依赖和应用本身的错误监控）。
○系统错误：通过上述的「服务指标监控」可以实现
○业务错误：则可以添加「自定义监控」来实现
errcode：即access log里打印的业务状态码（如业务状态码errcode=1代表成功，系统状态码status=200）
最终获得的监控如下：
4）总结：「分层*对象*黄金指标*具体指标」就是梳理分析监控对象和指标的方法
通过监控对象分层梳理、对象的指标维度分析，综合监控的评价标准，可以分析得到业务系统配置监控所需的「对象和指标表」。
举例，营销运营线上实际使用的「对象和指标表」如下：
分层 |
对象 |
黄金指标（流量|延迟|错误|饱和度） |
具体指标示例 |
物理层 |
CPU |
饱和度 |
CPU利用率 |
MEM |
饱和度 |
MEM使用率 |
|
磁盘 |
饱和度 |
磁盘利用率 |
|
机器 |
饱和度 |
负载 |
|
网络 |
错误 |
重传率 |
|
中间件层 |
MetaQ |
流量、延迟、错误 |
流量控制、消息堆积、panic日志 |
ScheduleX |
错误 |
任务失败 |
|
redis |
饱和度 |
CPU使用率、MEM使用率、网络带宽使用率 |
|
db |
饱和度 |
磁盘使用率 |
|
下游依赖服务 |
系统依赖的下游服务 |
流量 |
访问量、分组访问量、IDC访问量 |
延迟 |
RT、分组和IDC RT |
||
TP95-TP99 |
|||
错误 |
成功率、分组成功率、IDC成功率 |
||
业务码 |
下游依赖服务业务code |
||
应用层 |
服务进程 |
端口探活 |
HTTP端口探活监测 |
TCP端口探活监测 |
|||
进程监测 |
进程重启次数监控(crash发生) |
||
进程重启失败次数监控(不断crash) |
|||
服务API |
流量 |
访问量监控、分组和IDC访问量 |
|
限流熔断监控 |
|||
延迟 |
RT、分组和IDC RT |
||
TP95-TP99 |
|||
错误 |
成功率监控、分组和IDC成功率 |
||
业务码 |
业务成功率 |
||
核心网关http code错误码监控 |
nginx code、nginx error code |
||
业务层 |
业务链路和逻辑 |
暂略 |
暂略 |
3. 指标采集和监控呈现
★再次，选择综合较优的指标采集方式、以及合适的监控呈现方式 —> 需要回答如何进行指标采集、如何以更好的方式呈现监控？
1）指标采集
问题：如何持续的获取数据、并进行存储？
回答：一般情况，公司的基础服务能够支持指标数据的采集。关于指标数据采集，可以考虑以下几点：
●周期和频率。如：分钟级、秒级，权衡时效性和成本
●数据的来源。如：系统日志、业务日志、主动上报数据等
●数据格式与要素：可以采用「SPM指标模型」
○即在日志打印中包含两个要素：响应时间 和 是否成功
○根据一定时间窗口日志，可以统计出该业务点的: 总量/成功量/失败量/成功率/平均相应时间等指标
常用指标采集和统计方式：（sunfire为例）
●常用服务指标：统计单业务或N个维度的N个Key业务的总量、成功量、失败量、成功率、平均耗时 5 个统计项。如统计某个接口的总量、成功量、失败量、成功率、平均耗时
●分钟统计/无 Key：统计单业务量每分钟的数据。如统计单个接口每分钟被调用的总量
●分钟统计/多 Key：统计N个Key业务量每分钟的数据。如统计系统各个接口分别被调用的总量
●秒级统计/无 Key：统计单业务量每秒的数据。如统计单个接口每秒被调用的总量
●秒级统计/多 Key：统计N个Key业务量每秒的数据。如统计系统各个接口分别被调用的总量
●分钟统计Top：统计维度的多个Key的数值，并对数值排序，展现前 N 个最高数值的 Key。如统计平均耗时前 10 的错误码
●单笔数据Top：对单条日志的数值维度进行排序，查看最高 N 个单笔业务。如统计耗时前 10 的单笔订单
●归档统计：对一个秒级数据源，按小时、天、周、月统计数值
2）监控呈现
问题：如何输出、呈现监控数据？
回答：分层、分对象、分维度指标，使用图、表等方式进行展示
监控呈现方式？
●表格 vs 图（曲线、直方图、饼图等）
●单图单表 vs 大盘（各个层级的监控进行汇总、友好展现）
一个好的监控大盘，应该是涵盖各个分层的核心对象的核心指标（参见：分层对象常用指标表）
如何看监控？
●when？系统有变更（如上线、回滚）、系统有异常报警、常规巡检
●what？看各个层级监控对象的、多个维度的、多个指标的图表
●how？从顶层到底层，依次看图表发生的变化（特殊波动、毛刺）
4. 异常检测和报警规则
★最后，设置合理的报警策略和通知规则 —> 需要回答如何设置报警策略和通知规则？
1）基于时序的异常检测
针对计算机系统的异常检测（监控报警）是基于时序的异常检测，通常最终会拆解为单个指标的异常检测、并且采用设置阈值的方式来判断该指标是否异常：
将多指标异常检测（即监控某个对象）-> 拆分转化为 -> 单指标的异常检测（即将监控对象的多个指标拆分为单个指标来监控）；然后，单指标的异常检测 -> 采用统计的方法（即通过设置阈值来判断是否异常）
总结来说：计算机监控报警的异常检测，一般都转为了「通过设置统计阈值来判断某个对象的某个单指标是否异常」。为了方便进行统计阈值的设置，监控系统的设计实现一般都提出了检测窗口、异常事件、问题等的系统设计模型。
我们理解了这个转化过程和监控系统设计的模型，对于后续理解和熟练使用各种监控系统都大有裨益。
2）异常检测规则和配置过程
问题1：如何检测监控对象是否发生了变化？
回答1：时间维度下、指标是否产生变化（即指标在时间序列前后的差值是否大于0）。
问题2：如何判断监控对象发生的变化是否是异常？
回答2：通过设置变化幅度的阈值（即异常阈值）来判断发生异常（即指标在时间序列前后的差值是否大于N）。
通过上述分析，异常检测原理是：基于时间维度指标的变化和阈值比较，故可以得出基于时间序列的异常检测规则的设置过程：
1.选择指标
2.选择指标的统计窗口和聚合计算方法
3.选择同比|环比|当前值（即选择维度）
4.设置阈值
●选择X指标
●统计窗口1分钟（单点值）
○当前值， 如：当前值 > 阈值N
○环比 ， 如：当前值和过去一分钟的环比值 > 阈值N
○同比， 如：当前值和昨天同时刻的同比值 > 阈值N
●统计窗口N分钟（窗口值）
○当前值， 如：最近N分钟X值 > 阈值K%
○环比， 如：最近N分钟sum(X) 和上M分钟sum(X) 涨幅 > 阈值K%
○同比， 如：最近N分钟sum(X)和昨天同比涨幅 > 阈值K%
举例：需要检测系统响应时间是否发生异常，则可以通过上述方法进行配置报警规则：
1.选择指标：RT。
2.统计窗口：5分钟，计算方式：指标求和
3.选择维度：环比，即和上个统计窗口环比
4.设置阈值：50%
得出报警规则：最近5分钟sum(RT) 和上5分钟sum(RT) 涨幅>50%，则认为系统发生了延迟的异常
3）报警策略优化方案
前面简单介绍了基于时序的异常检测、以及对应的报警策略的配置方法和过程。
还有一个关键问题是会直接影响到报警的准确性和即时性，即「报警策略的选择和优化」。
下面简单介绍一下报警策略的一些优化方法
a. 报警策略和优化方法
●首先，区分系统错误（瞬时值出现立即报）、非法业务访问（出现上升、下降等变化才报）、用户不当操作（不报）
○系统异常：系统的异常导致的接口返回错误、导致用户使用服务异常，需要立即响应处理。报警策略的设置上，只要出现异常点，应该立即进行报警，即「瞬时值出现异常，则立即报警，对应报警配置：当前值>0」，如：系统错误500、panic等
○非法业务访问：违反业务规则、非法访问。小规模不管、异常上升需进行风险排除。即「持续值出现异常、且有上升趋势，则进行报警，对应报警配置：最近N分钟持续>M && 最近N分钟均值环比增长>N 」，如：业务码异常（活动状态未开启、用户非法访问活动首页）
○用户不当操作：符合业务规则、操作不当的业务异常。不需要处理，可以作为业务优化。用户操作姿势不正确或不准确导致的业务指标异常抖动。如：用户登陆时输错密码
●其次，灵活选择单、多指标，灵活选择瞬时值和窗口值
○单指标：通过【多维度组合】进行优化，可以减少单指标受业务正常波动的影响。如：环比和上周同比的组合
○多指标：通过【多指标组合】，可以减少单类指标受业务波动的影响。如：失败量(绝对值)和成功率(相对值)的组合
○瞬时值：一般用于严重错误，只要出现立即报警。单点值容易受异常数据扰动
○窗口值：即对时间窗口内的数据进行求和、平均等。一般用于流量摊平，使瞬时流量平滑减少抖动，进而减少误报
○选择顺序：瞬时值 -> 【多指标 * 多维度】 * 瞬时值 -> 【多指标 * 多维度】* 【打平的窗口值】
●第三，避免将不同级别的监控信息配置到一起
○流量最上层入口监控以“成功率、失败量绝对值阈值为主，成功量总量环比同比波动为辅”，因为上层业务数据波动较大，通过波动来报警容易误报
○底层应用采集监控以“成功量总量环比同比波动为主，成功率、失败量绝对值阈值为辅”，因为底层相对稳定，成功率、失败量等绝对值属性相对稳定，不容易发现异常
●第四，区分业务量级大小情况、业务量高低峰时间段，合理【分量级、分时间段】配置报警规则
b. 误报处理优化示例
➢服务指标报警优化示例
❏目标：检测流量持续快速上升或者持续快速下降
优化：屏蔽瞬时下跌或者上涨
规则：因为小抖动多，所以采用窗口值。上升下降采用环比
❏目标：检测成功率低于某阈值
优化：屏蔽瞬时
规则：持续窗口时间小于某阈值
❏目标：检测失败数持续大于某阈值、且在上升
优化：屏蔽瞬时
规则：持续大于某阈值 && 环比上涨
❏目标：检测RT超过某阈值、且持续上升
优化：屏蔽极小流量接口
规则：窗口值上涨超200% && 持续大于80 &&（总量>5 ）
➢优化方法论示例
●【阈值不合理优化】
原因：对业务的特性没有经过观察，初期的拍下的报警指标不符合实际业务特性
优化：通过较长一段时间观测，总结业务波动特性，校准报警阈值
●【瞬时脉冲误报优化】
原因：因为活动、定时任务等在短时间内冲高（然后回落）、而报警策略为【瞬时值环比】导致误报警而实际业务正常
优化：用【最近n分钟求和、均值环比】摊平冲高回落造成的下跌对报警的影响
●【业务周期性波动误报】
优化：针对工作日和非工作日以日为单位的监控，根据周期特性配置【同比】报警策略，减少环比的报警
●【频繁脉冲误报优化】
原因：整体的业务量较小，同时振幅较大，导致通过正常的环比、同比进行配置预警时，误报量较大
优化：更改监控指标，从【业务量】改用【成功率或者失败率】的方式进行监控；同时通过【业务量>多少时报警生效作为报警生效开关】&&【当且仅当多个条件都生效时】报警生效
5. 报警通知
1）报警通知
问题1：如何通知异常？
回答1：
1）报警有哪些分级？
warning、critical、urgent
2）报警有哪些渠道？
邮件、钉钉、短信、电话等
2）报警泛滥问题
问题2：报警有哪些筛滤策略？报警泛滥问题解决思路？
回答2：
●告警收敛
○等待，当一个异常产生之后不立即告警，而是等待一定时间再次发生才去做告警
○间隔，问题在没有恢复前，根据告警间隔配置、每隔一段时间发送一条告警信息
○合并，将同个维度下的异常合并在一起
●告警认领
○当出现告警后如果有人认领了该告警，后续相同告警只发送给告警认领人
●告警屏蔽
○对于同一个问题，可以设置告警屏蔽，后续如果有该问题对应的告警产生，那么将不会被发送出去
●告警升级
○告警发生一定时间仍没有恢复，系统就会根据配置自动进行告警升级处理，然后将告警升级信息发送给对应的人员
最后
本文不是一篇实操手册，而是希望引起研发同学通过对监控报警的系统性的学习思考，能够对监控报警有一套自己的“屠龙术”，能轻松使用各种监控报警系统，举重若轻的建设监控报警、提升业务和系统的稳定性，而不是盲目的、打一枪放一炮的配置监控报警。
最后，愿各位心中有道、线上永无事故。
关注「阿里巴巴技术质量」阅读更多
本文分享自微信公众号 - 阿里巴巴技术质量（AlibabaTechQA）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
