导读：作为一个测试开发同学，我们日常中充斥着各种监控报警，但似乎还从未真正完整地总结过该如何分析、设计、布置这些五花八门的风险“吹哨人”。今天，就让这篇干货满满的万字长文，带大家一起看一看如何系统地构建监控报警。

前言

系统故障和业务资损时有发生，监控报警作为事中发现的主要手段被大家熟知。但就像是熟悉的陌生人，对于监控报警有种知道却又说不出所以然的感觉，很少进行总结思考：面对五花八门的监控报警实现方式，没有进行总结和抽象；时常没有事先分析、整体设计、提前布置监控报警，往往发生血泪故障后，才后悔之前没想到要加相关监控。

趁着做了一段时间的稳定性保障工作，这次就来简单掰扯掰扯、尝试整体的观摩一下监控报警：尝试分析监控报警的业务流程，梳理监控报警的各个环节的关键问题，以及总结关键问题对应的解决方案。

最终目的是：

通过分析、抽象、总结，对监控报警有整体上的认识；能演绎使用，能实际调整生产环境的监控报警，使其更完善、合理、有效；解决诸如如何构建完善监控报警、如何设计监控大盘等等日常问题；第一章 监控报警是什么？

★首先，先明确一下什么是监控报警？

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：

●告警收敛

○等待，当一个异常产生之后不立即告警，而是等待一定时间再次发生才去做告警

○间隔，问题在没有恢复前，根据告警间隔配置、每隔一段时间发送一条告警信息

○合并，将同个维度下的异常合并在一起

●告警认领

○当出现告警后如果有人认领了该告警，后续相同告警只发送给告警认领人

●告警屏蔽

○对于同一个问题，可以设置告警屏蔽，后续如果有该问题对应的告警产生，那么将不会被发送出去

●告警升级

○告警发生一定时间仍没有恢复，系统就会根据配置自动进行告警升级处理，然后将告警升级信息发送给对应的人员

最后

本文不是一篇实操手册，而是希望引起研发同学通过对监控报警的系统性的学习思考，能够对监控报警有一套自己的“屠龙术”，能轻松使用各种监控报警系统，举重若轻的建设监控报警、提升业务和系统的稳定性，而不是盲目的、打一枪放一炮的配置监控报警。

作者:李必忠(澈达)

来源:微信公众号:阿里巴巴技术质量

出处: