作者：阳其凯（逸陵）、张江宇（九辩）
01
前言
Aliware
1.1 一样平常生活中的告警
任何连续稳定运行的生产系统都离不开有效的监控与报警机制。通过监控，我们可以及时掌握系统和业务的运行状态；而报警则资助我们及时发现并相应监控指标及业务中的异常情况。
在一样平常生活中，我们也常常碰到各种各样的告警。例如，在驾驶传统机动车时，仪表盘就犹如一个高效的监控面板，清晰地显示了行驶速度、发动机转速、燃油量等关键指标。此外，车辆内部还监控着更多细节指标，如水温、胎压、刹车片磨损程度和冷却液量等。一旦发现异常，如水温过高、胎压过低、刹车片磨损或冷却液不足等问题，仪表盘会立刻发出警告，确保驾驶员能够迅速察觉并采取相应措施。
1.2 告警是 IT 系统稳定性建设的基石
报警在一样平常生活中到处可见，同时起到了关键的作用。在 IT 范畴，告警同样是确保系统可靠性的基石。我们知道，没有任何一套IT系统能够达到 100% 的可靠性，因此我们的策略是不断提升服务的可靠性。为了实现这一目的并确保服务的连续性，有许多不同的路径可以选择。在深入分析这些路径之前，我们先来探讨一下 IT 系统的可用性及相关理论基础。
1.2.1 IT系统可用性
在讲解告警之前我们首先简单聊一下 IT 系统的可靠性。2017 年，ufried 在《Resilient software design in a nutshell》中，对 IT 系统可用性的定义如下：
那么，不丢脸出系统可用性的指标从 2 个方面，即 MTTF（不出故障的时间）和 MTTR（出故障后的规复时间）
- MTTF：全称是 Mean Time To Failure，均匀无故障时间。系统均匀能够正常运行多长时间，才发生一次故障。也就是说系统的可靠性越高，均匀无故障时间越长。
- MTTR：全称是 Mean Time To Repair，均匀修复时间。即系统出故障后的规复时间，MTTR 越短表示易规复性越好，系统可用性越高。
1.2.2 IT 系统稳定性建设理论
在 IT 系统稳定性建设中，稳定性建设的中心引导思想就是进步 MTTF（无故障时间）以及低沉 MTTR（故障后的规复时间）。
那么我们仔细来分析一下这个过程：
1）进步 MTTF：换言之，使用各种技能、流程机制等手段去规避故障的发生，低沉故障的发生概率，尽可能进步业务的连续性。比如：
- 技能维度：在架构设计阶段考虑高可用设计、同城/异地容灾、弹性架构等能力；在编码阶段服从相关编码规约、考虑防护编程、远程超时、资源隔离、有界队列、公道的设计模式等；测试阶段严酷考虑单元测试覆盖率、集成测试、性能测试、回归测试、故障演练等；这里暂不逐一睁开。
- 机制维度：推行变更 3 板斧-可灰度、可观测、可回滚；引入故障品级机制；赏罚机制等。
- 文化上：稳定性相关制度与文化的宣导、培训、考试等。
2）低沉 MTTR：我们知道 MTTR 越短，表明系统故障规复得越快，服务的可用性也就越高，MTTR 可以进一步细分为以下几个部分：MTTR = MTTI + MTTK + MTTF + MTTV。
- MTTI：全称 Mean Time To Identify，均匀故障发现时间，即从故障发生到被辨认的时间。
- MTTK：全称 Mean Time To Know，均匀故障认知时间，即从故障被辨认到被确认的时间。
- MTTF：全称 Mean Time To Fix，均匀故障解决时间，即从故障确认到现实解决问题的时间。
- MTTV：全称 Mean Time To Verify，均匀故障修复验证时间，即从故障解决到验证修复结果的时间。
狭义 MTTR 为 MTTR = MTTI + MTTK + MTTF。
在稳定性建设中，MTTR 的收缩是焦点目的之一。而告警能力建设可以有效收缩 MTTI，同时好的告警体系建设同样可以助力收缩 MTTK 的过程，从而加快整个 MTTR 的进程。
1.2.3 安全生产理念
在数字化转型加快的当下，企业业务不断向数字化迈进，服务用户数目激增，导致 IT 系统的复杂性日益增加。特别是在当局和金融等行业，业务连续性和稳定性已成为制约发展的关键因素。微服务架构与容器化的引入虽然进步了应用的灵活性，但也带来了庞大而复杂的系统关系，使得故障频发且难以定位。针对这一挑战，阿里云推出了云原生安全生产解决方案。该方案以故障管理为焦点，遵循“1-5-10”原则（即 1 分钟内发现问题、5 分钟内定位问题、10 分钟内规复），并围绕故障生命周期的三个阶段——事前预防、事中快速相应及规复、过后防止再发生，构建全面的应对机制。通过提供专业的技能咨询和支持，确保这些机制能够有效实行，从而保障业务连续稳定运行，并将资产丧失控制在最低限度。
个人明确 1-5-10 安全生产体系本质上是对 MTTR（均匀修复时间）的一种 SLA（服务水平协议）答应。而我们今天关注的焦点和主题是“告警”。告警在整个安全生产体系中扮演着至关重要的脚色，它是 1-5-10 理念中第一个环节——1 分钟内发现问题（即 MTTI，均匀检测时间）的具体体现。告警系统不仅能够及时发现潜在问题，还能迅速触发相应机制，确保在最短时间内定位并解决问题。因此，告警功能直接牵引着整个安全生产体系的运行，其结果直接影响到安全生产体系实行的成败。可以说，告警是保障系统稳定性和可靠性的基石。通过高效的告警机制，我们可以更早地辨认和处理故障，从而最大限度地减少业务停止和资产丧失。
今天的文章我们将围绕告警进行睁开，重点讨论企业级告警体系构建的通用思路和方法论，比如如何设置报警、如何有效地管理告警、如何与安全生产体系连合等，最后给出相关客户的实践案例和落地方案，通过这些内容，我们希望能够为企业提供一套全面且实用的告警体系建设指南。
02
告警体系建设通用流程
Aliware
首先我们分析一下完成系统监控报警的一样平常流程是什么样的？我们可以抽象为如下的几个环节：
1）监控对象梳理
首先，必须明确需要监控的对象，分析出哪些对象需要被监控。通过对系统进行分层梳理，辨认出关键组件和服务，确保全部重要部分都不会被遗漏。在此基础上，对当前的监控配置进行逐层检查，查找不足之处，以提升系统的监控覆盖率。
2）监控指标分析
其次，分析出监控这些对象的哪些维度和指标。通过监控对象分层梳理、对象的指标维度分析，综合监控的评价尺度，得到业务系统配置监控所需的「对象和指标表」，为后续的监控实行奠基基础。
3）监控指标采集
一旦确定了监控指标，接下来就是数据的采集工作。选定可靠的数据来源以及合适的采集周期，将监控指标的数据搜集至相关的可观测系统（如阿里云云监控、SLS、ARMS 等）。在此过程中，对采集到的数据进行必要的洗濯和处理，最终借助可视化工具，以图表的情势展示数据，便于对系统状态进行直观分析和明确。
4）告警规则配置
最后，公道配置告警规则与关照策略是告警建设的重要一步。通过设定统计阈值，来判断某一监控指标是否出现异常，并基于告警品级，通过即时消息工具（如钉钉）、短信或电话等方式，迅速关照相关的运维值班职员，以便他们能够及时相应和处理潜在问题。
2.1 监控对象梳理
为实现全局视角下的监控覆盖，关键在于接纳分层架构对监控对象进行全面梳理，辨认各层级的关键监控要素。一个完备的监控体系通常包罗以下层级结构：
分层
| 分层说明
| 分层重要对象
| 可用于监控的对象
| 业务层
（含终端体验层）
| 业务本身以及业务入口载体
| 业务逻辑、终端入口
| 业务逻辑、业务焦点链路，如电商场景的购物车、下单、支付等关键环节
| 应用层
| 业务的“系统”载体
| 应用（微服务）本身
| 应用本身，如进程状态、API接口
| 依赖层（服务/系统）
| 业务的服务/系统依赖
| 鄙俚微服务依赖大概中心件（云服务）
| 鄙俚依赖的微服务、中心件和基础服务，比如常见的阿里云云服务Kafka、RocketMQ、RDS、Redis等
| 基础设施层
| 业务的物理承载
| 容器、主机、网络
| 可用对象的属性大概子对象进行替代，如CPU、MEM、DISK、端口、网络等
|
通过上述层级分别可见，不同层级的监控对象对业务连续性的影响程度呈现递减趋势。举例而言，单台服务器的异常可能不会直接影响业务运行，但焦点业务流程（如订单处理）的故障必然导致业务停止。因此，在现实监控策略制定中，应依据层级重要性差异设置相应的告警级别和相应机制，将监控重点放在那些对业务影响较大的层面上。
2.2 监控指标分析
监控对象需要进行数字化权衡，那么指标是最佳的度量方式与形态，通过指标与维度从而实现监控对象的分析。那么有哪些常用的指标呢？下面列举四大类常用“黄金指标”如下：
指标范例
| 指标范例描述
| 数目和质量
| 指标示例
| 流量范例指标
| 请求对象的量级情况（单位时间）
| 次数、频率，
吞吐量、吞吐率
| 业务层如：页面大概功能的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、超时率|数、乐成率|数等
| Kafka
| 流量、耽误、错误、饱和度
| 读写QPS、消耗耽误、分区使用率、磁盘使用率等
| RDS
| 流量、耽误、错误、饱和度
| 读写QPS、慢SQL、连接数、CPU使用率、内存使用率等
| Redis
| 流量、耽误、错误、饱和度
| 读写QPS、RT、缓存命中率等
| 基础设施层
| 主机、容器、系统
| 错误、饱和度
| 错误（宕机、坏盘、文件系统错误）、饱和度（负载Load1|5|15）
| CPU
| 饱和度、错误
| 使用率、load1、load5、load15、cpu硬件错误等
| MEM
| 饱和度、错误
| 使用率(内存大概swap使用率)、内存分配失败|OOM
| DISK
| 饱和度、流量、错误
| 使用率、等待队列长度、读写磁盘次数、IO错误等
| NETWORK
| 饱和度、流量、错误
| 使用率、重传率、连接数、收发流量、网卡收发错误数|丢包数等
| 端口
| 饱和度
| 端口数
|
基于维度的分析
在指标分析中，维度分析是重要构成部分。常见的监控诉警重要接纳时间维度，即对比监控对象在时间序列上的变革。此外，属性维度也是重要的分析视角。
维度范例
| 维度范例描述
| 维度示例
| 时间维度
| 同一个对象的指标在时间前后的纵向对比
|
- 当前值和已往一分钟的环比
- 当前值和昨天同样时候的同比
- 当前值和上周同样时候的同比
- 近来N分钟X指标值
- 近来N分钟sum(X指标) 和上M分钟sum(X指标) 对比
- 近来N分钟avg(X指标)和上M分钟avg(X指标)对比
| 属性维度
| 多个对象的指标在雷同属性下的横向对比
| 这里临时不睁开
|
多维度连合分析
在监控指标分析中，虽然单一维度的分析至关重要，但仅依赖单维度配置每每容易产生误告，或增加问题根因定位的复杂度。此时，接纳多维度的告警策略显得更为公道。以应用的 QPS（每秒查询率）为例，如果仅基于固定阈值设置告警，可能会因流量颠簸或业务周期性变革而频仍触发误报。通过引入多维度分析（如联适时间趋势、业务场景、资源使用率等），可以更精准地辨认异常，减少误告率，并提升问题排查效率。
以下针对 QPS 阈值场景进行细化分析，并连合 RT（相应时间）指标设计检测机制，列举几种典型场景及其应对策略：
- 场景 1：流量上升、RT 变革不明显。表明系统当前处理能力充足，尚未达到性能瓶颈，但仍需连续监控，以防潜在风险。
- 场景 2：流量上升、RT 也同步增加。此场景提示系统性能可能接近上限，RT 与流量呈正相关关系。此时需重点关注 QPS 指标，并连合 RT 阈值设置公道的告警规则，以便及时预警性能瓶颈。
- 场景 3：流量无明显变革、RT 增加。可能由服务依赖（如网络耽误、鄙俚服务性能降落）或系统内部问题引起。需深入排查依赖服务状态，并连合其他指标进行根因分析。
- 场景 4：流量降落、RT 变革不明显。该情况可能为正常的入口流量低沉，也可能为异常场景，需要连合其他指标大概业务场景经验进行综合判断。
- 场景 5：流量降落、RT 低沉。与场景二类似，但表现为反向趋势。可能反映系统负载减轻，仍需连合上下文分析是否为正常征象或潜在问题。
2.3 监控指标采集
基于阿里云可观测产物构建有效的全栈监控体系，这里不进行睁开，具体参考文档：https://www.aliyun.com/product/arms
2.4 告警规则配置
2.4.1 告警设置基本原则
在进行告警规则配置之前，我们需要明确以下告警的基本原则。
- 告警具备真实性：告警的真实性是最为关键的原则。每一条告警都必须基于现实存在的问题或潜在风险，确保其能够真实地反映出服务当前的状态，而非偶发性颠簸或外部干扰。这样能及时预警并采取办法，避免更严峻的问题发生。
- 反模式示例：若请求失败量因临时网络抖动而触发告警，实则系统本身无故障，此类告警即丧失真实性。
- 常用最佳实践：引入异常检测算法区分正常颠簸与真实异常；对告警触发条件叠加多维度过滤（如请求来源 IP、用户举动特性、业务场景标签）等。
- 告警表述需具体：从内容上，告警要近可能具体的描述征象，包括具体的时间、所在和异常情况等，比如服务器在某个时间点具体发生了什么异常，便于快速定位和处理问题。
- 告警具备可操纵性：每当收到告警时，相关职员通常需要采取一定的措施来处理问题，对于某些无须做出操纵的告警，最好取消大概调整。告警系统设计应确保仅在确实需要执行操纵时触发关照，避免信息过载和资源浪费。
- 反模式规避：对无需人工参与的告警（如自动规复的瞬时错误），应降级为日记记录或纳入统计报表。
- 最佳实践：定义分级策略、明确报警责任归属、设置自动化联动策略（自动触发应急预案）等。
- 新告警使用保守阈值：在配置告警之初接纳保守阈值+宽覆盖策略，应尽可能扩大监控诉警覆盖面，选取保守的阈值，尽可能避免漏报，然后逐步收敛至精准状态。
以请求失败举例，如仅当请求的失败量凌驾某一阈值时告警，可能存在多种缘故原由，如一些恶意构造的请求，也触发失败量告警。这样的告警既不具备真实性，也不具备可操纵性，因为确实无需任何处理。对于此类情况，我们应该尽可能通过特性加以辨认，从而更加精准地区分不同缘故原由的告警，以进步告警的准确性和有效性。
2.4.2 告警品级定义
使用告警时，一个典型的问题就是告警信噪比低，工程师每每被海量低质量告警沉没，解决这类问题，有一个非常好的突破口就是定义告警品级尺度。告警品级定义可以参考阿里巴巴集团关于故障级别的定义。这一方法的基本思路是根据预警的影响程度和业务特性来分别告警品级，从而确定信息传播的前言、受众以及相应的尺度操纵流程（SOP）。通过这一方式，不同级别的告警可以被更公道地分类和处理，使得工程师能够迅速辨认最关键信息，集中精神应对高优先级的问题。此外，建立清晰的告警品级体系还可以促进团队之间的沟通与协作，进步团体相应效率和质量。
在阿里云可观测系统（如 ARMS）中一样平常接纳通用 P 品级进行权衡（P1、P2、P3、P4）。
1）方式 1：按照客观的尺度进行 P 级定义
如下为针对应用重要性进行分别，按照影响面进行告警的 P 级别定义参考的尺度。
2）方式 2：按照主观进行 P 级定义
品级
| 定义方式
| P4
| 需要采取办法的小问题，但是不影响客户的使用
| P3
| 需要运维职员立刻关注的稳定性问题大概影响客户使用的小问题
| P2
| 严峻言行需要客户使用的产物的关键性系统问题
| P1
| 需要立刻接洽管理/运维团队进行处理的关键性问题，如果不处理后果非常严峻
|
该方式需要相关范畴的同砚（研发/运维）参与，连合专家经验进行主观评估。在现实的执行过程中不同的报警设置职员可能在定义上存在随意的征象，所以建议进行报警品级的 review。
2.4.3 告警关照策略尺度
上面提到了告警品级，依据告警品级以及告警触发场景进行分渠道关照，保障焦点告警不被忽略，同时非焦点告警可以在一定时间窗口相应，减少工程师相应疲惫度，提升工程师幸福度。阿里云可观测产物多种关照策略（如常用的语音、短信、邮件、IM 即时消息和群组关照），每种方式都有其特定的应用场景，具体如下表所示：
关照渠道
| 适用场景
| 语音
|
- 焦点告警，一定是可能大概已经产生故障且需要告警吸收人立刻相应的场景
- 非焦点告警，一律禁绝使用语音
| 短信
|
- 焦点告警，一定要推送短信，语音通常难以辨识告警内容
- 非焦点告警，除了需要及时相应的场景除外，一律不需要推送短信
| IM消息（如钉钉）
|
- 焦点告警，推送语音、短信的同时也需要推送一份钉钉消息，方便开发者检察
- 非焦点告警，不需要推送语音、短信的，推送钉钉群的同时推送钉钉消息
| IM群（如钉群）
|
|
那么连合报警P级别的定义，建议接纳如下的关照渠道：
品级
| 定义方式
| P4
| IM关照（如钉钉）
| P3
| 短信+IM关照（如钉钉）
| P2
| 短信+IM关照（如钉钉）共同升级策略确保问题在规定的时间内得到处理
| P1
| 语音+短信+IM关照（如钉钉）共同升级策略确保问题在规定的时间内得到处理
|
03
告警的几个重要问题
Aliware
在告警系统选型以及告警体系的建设当中，如下的几个问题需要重点关注。
3.1 多平台告警问题
在云原生期间，企业 IT 基础设施的规模越来越大，越来越多的系统和服务被部署在云环境中。为了监控这些复杂的 IT 环境，企业通常会选择使用异构监控系统，例如 Prometheus、Grafana、Zabbix 等，以获取更全面的监控数据，然而，这种异构监控系统也带来了一些问题，其中最显著的是告警信息的分散。由于不同的监控系统可能会产生不同的告警信息，这些信息可能会分散在各个系统中，导致企业很难全面相识其 IT 系统的告警状况。这使得相应告警变得更加困难，同时也增加了人工管理的复杂性和工作量。如何针对这些异构的告警变乱进行管理是一个需要考虑的问题。如下是常见的几个潜在的场景：
场景一：
企业迁移上云后，云上产物的告警不统一
在一个典型的云原生业务应用部署架构中，通常会使用到如下产物 ACK、ECS、RDS，应用通过 Kubernetes 部署在阿里云的 ECS 上并访问云上的 RDS。在这个架构中通常会用到如下监控产物来对系统进行监控。
场景二：
多云、混合云架构下，异构监控系统告警不统一
场景三：
自研监控系统、自定义变乱告警接入
所以企业在构建大概选型告警系统的时候需要提前考虑这种多平台告警的问题，是否需要引入管理多源告警问题。
3.2 告警误报问题
在选择告警系统、配置告警规则的时候，告警误报是我们需要考虑的重要因素。理想中的告警，不存在误报（即本来正常的，告警为异常），出现告警就需要处理，如果误报的告警太多，处理的告警的同砚会产生困扰、造成资源的浪费，同时也容易产生“狼来了”的问题。
尽可能精细化告警设置
告警一样平常是通过“征象”来判断，而是否有问题要看产生征象的缘故原由判断。雷同的征象引起的缘故原由可能不同，这种“可能性”是导致误告警的最焦点缘故原由。如果能减少到唯一的缘故原由大概尽可能少的缘故原由，那就能很明确问题所在。
考虑告警的齐备度
齐备度是一段时间内现实采集落盘的指标样本数目占渴望网络到的样本数目的比率（%），是个时序数据，但是随着时间推移会发生变革。比如监控一千个副本的交易应用的 QPS，这个指标需要连合一千个数据进行叠加，如果没有数据齐备度的概念，若配置 QPS 相比低沉 2% 告警，由于网络颠簸，凌驾 20 个副本上报的数据耽误几秒，那就会触发误报。因此在配置告警的时候还需要连合数据齐备度数据进行综合考虑。
3.3 告警风暴问题
在告警系统的选型以及告警设置中，告警风暴问题的重要性尤为突出，每个研发/运维同砚单日处理的告警数据量是有限的，如果产生告警风暴，重要的告警将会沉没，同时也会加剧运维同砚的负担，低沉幸福感。如下为常见的一些原则：
- 告警品级分别：将不同品级的告警进行分开管理；
- 过滤无关告警：基于预设的规则过滤掉不重要的告警；
- 使用压缩、静默等手段进行告警收敛，所以在告警系统选型的时候需要重点关注是否具备该项能力；
- 基于标签压缩：当满足条件的多条变乱包罗雷同的标签时，将会自动压缩成一条告警进行关照。
- 基于时间压缩：标签雷同的告警如果开始时间和结束时间有交集，则会合并为一个告警变乱，合并后的告警变乱的开始时间和结束时间取这两个告警变乱的并集。
- 静默：将匹配到的告警变乱全部标记为静默，这意味着其他关照策略无法再匹配到这些变乱。可以进一步设置静默规则生效的时间段，任何符合条件的告警变乱都会被标记为静默变乱，并在此期间内无法被任何关照策略触发。
3.4 告警如何处置
当告警触发时，需要设计一套完备的处理机制，而不仅仅是简单的关照发送。一个完善的告警处理流程应包罗认领、屏蔽、回调、标注、升级和关闭等关键环节，以确保告警得到有效管理和快速相应。
告警认领
当告警触发后，相关职员可主动认领该告警，认领后雷同告警将仅发送给认领人。这一机制旨在避免告警被多人重复处理，同时明确责任人，提升处理效率。认领状态支持取消，以便灵活调整处理职员。
告警屏蔽
针对已知问题或特定场景（仍旧障定位期间或服务发布过程中），可设置告警屏蔽规则，屏蔽期间相关告警将不再发送。屏蔽支持按周期或时间段配置，也可随时取消。此功能有效减少无效告警对运维职员的干扰，提升告警管理的精准性。
告警回调
告警规则可配置回调接口，当告警触发时自动执行预设的规复操纵。通过自动化手段快速规复服务，收缩故障修复时间（MTTR），尤其在紧急情况下，能够显著提升系统可用性。
误告标注
用户可对告警进行误报标注，记录告警是否为误报。误告标注的重要目的是通过标注让系统开发职员知道异常检测过程中，哪些点还需要提升优化，进步告警的准确性，为用户提供真实有效的告警提供保障。
告警升级
当告警发生一定时间仍没有规复，那么系统就会根据配置自动进行告警升级处理，然后将告警升级信息通过配置发送给对应的职员。告警升级一定程度上是为了收缩 MTTA，当告警长时间未规复，可以认为故障没有及时得到相应，这时就需要更高级别的职员参与处理。
04
案例分享
Aliware
4.1 客户背景
某闻名垂直电商 A 公司现在已经进入深度用云的阶段，公司现在面对如下的问题：
- 监控覆盖不足与告警配置欠佳：公司初期重要依赖云监控工具对云资源进行监控，忽视了应用层和业务层的监控需求，导致无法全面掌握应用的现实运行状态。同时，告警阈值设置缺乏科学性，存在漏报、误报和错报征象，且告警品级分别不清晰，难以区分问题的紧急程度和优先级。
- 告警资源权责分别：公司云资源及应用分散在 30 多家供应商中，作为统一运维团队，需要在告警信息中明确标注资源归属，以便快速分别责任。同时，需将归属明确的告警信息及时传递给相应供应商，由其进行处理和相应。
4.2 设计思路与实现
方案的建设思路：
- 针对现有的监控资源进行梳理，明确需要监控的对象。
- 制定标签的尺度，针对现有的资源进行全面打标；对于新增的资源纳入开服/新增资源的 SOP 中下发到各个供应商。
- 为了防止资源打标的遗漏大概后续供应商尚未按照规范对云资源进行打标，内部建立脚本巡检步伐针对资源进行每日的检测，不符合规范的进行透出、报警、通晒治理（当前策略已经同步，正在治理中）。
- 选择、设计相应的监控指标，基于现有阿里云可观测产物的能力进行监控指标的接入与告警配置，部分不支持的监控指标接纳自研的方式进行实现。
- 使用 ITSM 进行告警策略的分发。
- 定制统一的告警管理大盘。
4.2.1 监控对象梳理
客户 A 的大部分资源都部署在阿里云上，整个的技能架构也是比较典型的电商微服架构体系，部分应用部署在阿里云容器服务 ACK 中，少部分应用由于技能大概客观缘故原由部署在阿里云 ECS 上，底层中心件/存储使用了 RDS、MongoDB、Redis、Clickhouse、Kafka、RabbitMQ、ES、OpenSearch、Flink、SLS、OSS、NAS等，接入层使用了DDos、WAF、SLB（CLB）等。
按照分层设计（自上而下）的理念，用户进行如下的分层分别：
4.2.2 定尺度
用户这里的定尺度涉及多个方面，本质上都是立足安全生产，围绕业务高效、可靠、稳定的运行睁开。
标签规范
用户之前标签规范有多个版本（但是都存在一些问题），在进行互换后最后成型，关于标签的设计与最佳实践可以参考《一文详解阿里云可观测体系下标签最佳实践》。
日记规范
用户在日记规范部分具体地介绍了输出日记的原则与尺度，这里摘录部分信息。
1、如何打印日记：
日记需接入阿里云SLS方便查询和分析，同时按照应用进行区分。
打印日记时一定要打印方便定位和排查的字段，例如用户的id，request内容等。
生产环境敏感信息进行mask打印。
手机号仅显示后四位（手机号有可能作为排查日记的唯一标记，建议保留后四位，如果有其他唯一标识，建议不打印手机号）。
用户邮箱不打印日记。
用户具体地址不打印日记。
涉及到钱账户的不打印日记，如银行卡、微信/支付宝账号。
开启日记Tracing功能，这样同一个请求会生成同样的trace，可以串联和分析整个请求链路。
调用第三方服务前，打印请求内容。
调用第三方服务后，打印原始返回结果。
操纵数据库/Redis/Kafka后打印结果。
系统出现异常时，打印错误具体信息
焦点业务计算时，打印重要步调结果，方便堕落时回溯计算流程。
常常会引起客诉的情况。
2、审计日记
敏感数据：上传、下载、检察敏感数据等动作。
敏感操纵：删除、更新等动作。
3、日记品级
现在常见的日记分为四种，生产环境一样平常开启info及以上的日记，测试环境可以开始debug级别的日记
debug: 打印一些debug信息，比如每个步调结果，重要是为了测试环境排查问题而用，生产环境一样平常只会打印info及以上。
info：通例的信息，例如吸收到的请求。
warn：代码发现异常情况但又不影响业务逻辑继承情况，如某个重要参数为空（但不影响业务逻辑往下继承）
error：影响业务逻辑的异常情况，包括但不限于以下情况如调用第三方失败、接口参数校验失败、数据库/Redis/Kafka调用失败、系统异常。
日记需要按照应用/范例进行物理区分隔离，方便日记检索与告警设置。
这里有一个焦点的点就是定义了日记接入了 SLS 的规范，按照应用进行区分，这就为后续基于日记进行报警配置供应商的分发打下的基础。
4.2.3 尺度实行
尺度实行包罗多个环节，如下为标签的实行细则，其他尺度的实行不在这里睁开。
1）存量资源进行打标的动作
标签关系的建立现在重要分为手工页面配置方式以及 API 方式，具体参考文档《一文详解阿里云可观测体系下标签最佳实践》。
2）新资源接入规范
该部分重要为客户 A 运维团队在新应用、资源申请的时候，内部 SOP 中规定的一个必要步调。为了防止有漏网之鱼，运维团队内部编写了定时脚本针对线上资源进行扫描，强制检查规范，对于不符合规范的资源进行关照以及通晒。
4.2.4 监控指标梳理
客户 A 重要使用云监控对云产物资源进行进行监控，按照分层梳理监控对象的内里重新进行监控的梳理，补齐相关缺失项，覆盖应用/前端监控（ARMS）、业务监控（使用 SLS 日记监控），如下为部分应用监控诉警梳理截图，具体配置列表样例可以提工单接洽 ARMS 服务账号。
4.2.5 报警配置
4.2.5.1 告警配置
客户 A 的报警配置重要集中在 ARMS（应用监控、Prometheus）、云监控以及日记服务上。
4.2.5.2 基于标签进行告警变乱分发
通过在云资源上进行打标，进而在告警变乱上支持相关标签，从而实现告警变乱的分发。
图中为解决方案的示意图，其中阶段1&阶段2中的绿色部分表示阿里云当前已经支持的能力，灰色部分为正在支持中。
1）ARMS 应用监控诉警配置
应用监控的告警规则需要打上这个标签 enrich_app_labels:true，这样应用标签和实例标签就会富化到对应的告警变乱内里。然后自定义的应用标签会自动加上这个前缀：arms_app_lable_{自定义应用标签key}，自定义的实例标签会自动加上这个前缀：arms_app_host_lable_{自定义实例标签key}。
2）Prometheus 告警设置
用户的场景为配置相关容器的监控诉警，Node、Service、Pod 等这些资源在部署的时候会严酷按照规范带上相关的 label。如下为用户针对节点设置节点相关的报警“容器节点内存使用率凌驾 85%”。
- 前提-针对容器节点进行打标。
在 ARMS 控制台[3]的 Prometheus 监控 > Prometheus 告警规则进行 Prometheus 告警的设置，告警名称为容器节点内存使用率凌驾 85% ，检测范例为自定义 PromQL，自定义 PromQL 语句设置为 (sum(container_memory_working_set_bytes{id!="/",container!=""}) BY (instance, name,container, pod_name , namespace) / sum(container_spec_memory_limit_bytes{id!="/"} > 0) BY (instance, name, container, pod_name , namespace) * 100) > 85，其他告警参数的配置，请拜见 Prometheus 告警规则[4]。
- 告警中使用注释对告警进行打标，相关 node 的标从 kube_node_labels 获取。
- 结果：告警变乱中会增加 node 相关的 label。
扩展案例：
通过阿里云标签（Tag）分发告警
通过Kubernetes Label分发告警
3）日记服务告警设置
日记服务 SLS 的告警设置具体参考文档：https://help.aliyun.com/zh/sls/user-guide/sls-alerting/
由于用户在规范中定义了各个微服务应用按照不同的 logstore 进行区分，所以针对 logstore 的告警设置能够明确地知道当前日记归属于哪个应用。该部分现在接纳静态标签(标注)进行设置如下所示：
4）云监控诉警设置
当前云监控侧站点拨测不支持静态与动态打标的方式、基础云监控报警不支持动态标签的方式。现在可以支持将云服务接入 Prometheus[5], 使用 Prometheus 的方式进行绕开解决。
4.2.6 对接 ITSM
客户 A 接纳 ARMS 作为统一告警管理平台[6]，首先需要集成云监控以及 SLS 中的告警（ARMS 中告警默认支持）, 最后进行关照策略的配置。
4.2.6.1 告警集成
- 创建集成并接入云监控，获取云监控集成回调地址
- 修改云监控诉警规则，将告警发送至 ARMS
- 日记服务创建 webhook 集成，在对应的 project 的告警中心创建 webhook 集成，用于告警回调
- ARMS 中配置关照策略，具体参考关照策略最佳实践
4.2.7 报警变乱统一大盘
如下为客户 A 基于 ITSM 构建的告警变乱统一大盘，通过该大盘用户能够直观将来自云监控、日记服务、ARMS 的告警变乱进行集中的展示、管理。
当前客户正在推动度量供应商的服务水平与能力，这个涉及到 SLO 相关的能力建设，该部分将在后续的文章中继承睁开探讨。
05
总结
Aliware
本文围绕告警进行睁开，重点讨论企业级告警体系构建的通用思路以及在进行告警系统选型大概建设中需要关注的重点问题，最后连合阿里云可观测产物给出线上客户的实践案例，希望能够为企业提供一套全面且实用的告警体系建设指南与参考。
参考文档：
[1] 面向多告警源，如何构建统一告警管理体系？
https://my.oschina.net/u/3874284/blog/9914048
[2] 关照策略最佳实践
https://help.aliyun.com/zh/arms/alarm-operation-center/best-practices-for-notification-policies
[3]《一文详解阿里云可观测体系下标签最佳实践》
[4] 关照策略配置流程
https://help.aliyun.com/zh/arms/alarm-operation-center/create-and-manage-notification-policies
[5] 告警关照群@指定处理人
https://help.aliyun.com/zh/arms/alarm-operation-center/mention-contacts-with-at-sign-in-single-group-chat
[6] 通过 Kubernetes Label 分发告警
https://help.aliyun.com/zh/arms/alarm-operation-center/use-k8s-labels-to-dispatch-alerts
[7] 通过阿里云标签（Tag）分发告警
https://help.aliyun.com/zh/arms/alarm-operation-center/use-alibaba-cloud-tags-to-dispatch-alerts
相关链接：
[1] TagResources
https://help.aliyun.com/zh/resource-management/tag/developer-reference/api-tag-2018-08-28-tagresources
[2] demo
https://github.com/OuyangKevin/CloudAssistantTool/tree/main
[3] ARMS 控制台
https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Farms.console.aliyun.com%2F#/home
[4] Prometheus 告警规则
https://help.aliyun.com/zh/arms/prometheus-monitoring/create-alert-rules-for-prometheus-instances?spm=a2c4g.11186623.0.0.2ad9dc86qV6dTL#task-2121615
[5] 云服务接入 Prometheus
https://help.aliyun.com/zh/arms/prometheus-monitoring/data-access-via-access-center
[6] 统一告警管理平台
https://help.aliyun.com/zh/arms/alarm-operation-center/product-overview/alarm-management-overview
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
