告警平台：给告警一个胶带

给告警一个胶带，是“胶带”，也是“交代”。“胶带”，是因为告警是质量管理的关键工具和手段，需要粘合研发与运维、基架与业务，齐心并力；“交代”，是因为历史各种因素导致告警噪音大，今年经过地推式治理后，告警体验大为改善，在这个时间点给大家一个交代。

告警是指当监控数据发生异常并触发告警策略的时候，系统按照通知策略发送通知。告警平台是落实告警功能的基础平台，是互联网公司的必备的基础设施之一。在熟悉告警平台之前，我们先了解下告警的必要性和复杂性。

1）告警的必要性在于：研发几乎不可能对系统存在的风险有100%的认知；即使做到了100%的认知，也不可能对所有风险环节做了容错；有效预警可以帮助研发及时发现代码中潜在的bug，提高应用系统的可用性；稳定性1-5-10目标中的1分钟发现问题的目标达成离不开告警。

2）告警的复杂性：

• 覆盖多业务多地域：包括但不限于系统与网络监控、服务端应用与中间件监控、PaaS平台监控、边缘（视频云）监控、离线作业与进线服务（推广搜、AI平台、数平）监控、云监控（游戏）、移动端监控等；支持第三方平台或服务产生的告警统一通知，比如coredump、日志异常告警、云组件监控、业务异常告警等。既有内部告警集成，也有外部告警集成；外部集成方式既有平台成熟的情况，也有无平台的情况。这些场景都需要告警覆盖。

• 覆盖多种用户角色：每种角色关注的内容范围、功能范围不尽相同，平台都需要兼顾。

• 业务研发同学需要知晓自己负责业务的状态，若有异常能第一时间收到告警通知，可自定义业务的告警规则与告警接收人员，可配置告警升级与安排值班；部分业务同学还需要知晓依赖组件和资源的告警。

• 组件研发同学需要知晓组件发生异常和业务影响范围，高优告警需要立即处理，低优告警可用于质量巡检。支持告警合并，不能把高优的告警淹没掉了。

• SRE同学希望收到BP部分业务及其关键资源的告警，能够区分优先级，不接受告警风暴，希望告警中携带尽可能多的信息支持定位、告警能升级、有协同能力、有问题跟进复盘的能力；

• 老板们希望能掌握稳定性全局情况，知晓当前的告警处理进度，按照不同纬度查看告警数据。

• 告警召回与准确率的矛盾。用户对告警的需求首先是有总比没有好，但是太细粒度或太多的告警又很容易被吐槽。

• 告警覆盖的滞后性与需求支持的迫切性的矛盾。大多数告警是在case出现后才去加的，但是为了快速支持业务迭代，往往是直接让告警平台兜底。

这些复杂性除了需要技术手段去解决之外，还需要一些非技术手段的配合，本文两部分都会介绍。

ARMS告警管理提供了告警集成、告警收敛、告警通知、自动升级、告警协同与处理等功能，帮助您快速检测和修复业务告警。

其它商用告警产品，基本都支持接入各类告警信息，通过自动去重、规则压缩、算法降噪，实现告警降噪，帮助运维团队减少告警，避免告警风暴；同时通过分派、排班、通知等功能；支持告警处理流程化、智能降噪、根因定位与知识管理。

云平台因为是多租户形态，租户间的数据和配置进行隔离，告警量较少、责任人单一（大多数是运维同学进行配置），告警管理比较偏向质量管理。产品重心在告警生产后的阶段，比如告警集成、告警通知、告警协同、告警或问题复盘等，告警策略与通知策略分别配置。功能强大，但配置效率不高，因为只面向特定的同学，所有这也是能接受的。

在告警规则配置的时候指定告警策略和通知策略，一次搞定告警配置；并且在一些标准化场景，需要将告警进行封装，研发只需要几次点击就可以完成告警配置或调整。标准化的告警跟服务实体在一起，自定义告警使用监控告警平台通用的告警规则配置能力进行告警配置。

B站从研发效率考虑，既要兼顾IDC业务，又要兼顾云上业务；要考虑告警的标准化场景交付能力，又要能集成云告警，支持自定义告警。结合投入成本和整体运作效率，我们做如下设计。

告警是稳定性问题发现的主要来源，告警的召回与准确性对于业务稳定性非常重要。告警召回需要告警平台提供工具能力，业务和基架进行事前的告警覆盖；告警准确性同样需要告警平台提供工具能力、业务和基架根据告警反馈与告警操作数据、历史告警的看板和报表数据进行告警治理。

一个设计良好的平台，应该是有个一个闭环模型存在，让关联方都能够积极参与，推进目标的持续改善。对于告警系统来说，它的闭环模型如下：

^{（告警能力闭环模型图）}

其中，告警定义与告警治理两阶段非常关键，决定性地影响了告警的召回率和准确性。这两阶段需要与人的惰性进行对抗，需要一些标准和机制去支持落地。

告警分级标准：比如各SaaS/PaaS/IaaS场景平台根据服务对象提供告警分级标准，包括服务对象的告警项、告警级别、告警阈值、告警通知人和通道等，要考虑对象的服务级别，定义分级标准；按照标准分级、有序、有章法地推进告警覆盖。告警定义需要按照分级标准执行。合理的告警分级标准，可以让告警噪音先天性地处于较低水位。

告警运营机制：告警平台出具告警报表后，有明确的运营主体来跟进告警处理和治理，持续优化告警的准确率。告警运营治理，是告警系统形成闭环的核心环节。

告警平台需要对各阶段提供稳定且高效率的平台能力支持。

告警平台，向上服务于场景平台，支持场景上的分级告警策略落地；同时支持SLO平台进行核心告警的定义与覆盖，对接故障平台进行故障应急与复盘，推进稳定性建设。其中场景平台的职责包括：定义告警分级标准；定义与管理场景内的告警模版；提供场景内用户友好的告警配置界面；推进场景内告警覆盖；基于历史告警进行告警与质量运营。

告警平台向下对接监控数据进行告警检测，将历史告警事件存储到事件存储，将告警存储到数据库。

^{（告警平台架构图）}

其中，平台层提供高效率的产品能力，支持告警规则集成与配置、告警集成、告警通知策略配置、告警处理、告警降噪、告警分析与运营。引擎层提供稳定的告警计算引擎、告警通道等技术能力。

结合业界方案和公司自身情况，我们对告警平台的功能做如下设计：

^{（告警平台功能树）}

ToB场景：支持场景平台按照标准流程将告警规则集成到告警平台，告警平台基于具体的规则定义进行告警计算和通知。

场景平台将告警项跟服务对象放在一起，对用户配置更加友好。场景平台对告警项、告警分级标准、告警通知策略有专业且准确的定义，能基于历史告警进行稳定性治理，可以对业务提供更加高效服务。

^{（消息队列平台的告警规则新增界面）}

ToC场景：业务研发也可以自定义告警规则，满足业务自定义监控等多样化告警配置需求。

^{（用户在告警平台自定义告警规则）}

分布式告警计算引擎实现了告警规则的调度和计算，支持PromQL规则计算引擎。全局调度器将告警规则调度到对应的可用区，未指定对象可用区的全局规则会被调度到默认的可用区。本地调度根据计算节点负载进行均衡调度，产生的告警发送到告警通道。

^{（分布式告警计算架构图）}

分布式告警上线后，完成IDC SLO告警和大部分基础组件告警的迁移。告警计算节点容器化，服务发布、扩容与观测效率得到大幅提升。结合监控数据本地化、告警计算本地化、告警通道的主备通道建设，告警的容灾能力得到进一步提升。同时，告警计算性能得到优化，SLO告警30s的计算间隔，能保证告警在一分钟内检测到并触达到业务。

支持第三方平台或服务产生的告警集成，比如云监控告警、日志平台告警、Coredump告警等。支持告警分派，将匹配到特定标签的告警分配到提前配置好的告警组。告警集成功能为各场景的告警触达提供了统一的告警通知、处理与分析运营的能力。

告警组是告警通知策略，对告警触达的对象进行管理，提供了告警接收人员/通道组合配置，并支持通知升级能力。

• 人员配置：提供静态人员/值班人员/群机器人/服务树角色人员多种类型分组。

• 通道配置：提供企微/电话/邮件类型通道配置。

• 升级配置：一段时间内未处理/恢复的告警升级到特定的人员及通道。

由于不同场景业务告警通知的样式需求不同，平台侧支持了定制配置告警通知的样式/展示的内容/交互的功能等。并支持文本通知和卡片通知两种类型。

同一时间很多告警内容相似或者指向同一问题，此时需要将此类告警合并来提高信噪比，减少频繁告警通知的干扰。告警平台支持了按告警场景+告警规则+指定维度配置聚合策略，支持指定窗口内的告警匹配到聚合策略，按策略里配置的维度合并一起通知。

很多场景告警间存在主次/传导关系，如同一监控项可能存在多个不同阈值的告警，或者机房故障告警必然伴随机房内设备告警，因此需要支持告警抑制策略，即在某些告警触发后，其次要或者伴随告警可以不再通知。

告警平台提供抑制规则配置能力，支持配置源告警和目标告警匹配条件， 告警通道侧源告警触发后一段时间内目标告警将会被抑制不生成告警通知。

在一些压测演练、机房搬迁等场景需要提前静默相关告警来减少已知操作产生通知干扰，告警平台支持配置事前静默策略：包括静默时间条件（指定时间段/周期性时间范围）和匹配告警的标签等。命中了事前静默策略的告警将会被拦截不通知到用户。

开放接口，支持第三方平台对接。

对于无人处理、持续触发的告警，为减小此类告警噪声，当告警持续通知超过特定时长，通知间隔会自动调大。

提供个人/全公司维度的告警免打扰能力，避免大范围故障导致的频繁电话告警干扰故障应急。

告警处理第一步，确认告警已经触达。接警即立即处理，此告警在恢复前不会再发送通知。静默即延后一段时间处理，在静默到期后告警将继续通知。除了进行告警纬度的静默外，还可以按照规则纬度进行告警静默。

用户可以在告警通知卡片上点击“一键拉群”，自动创建企业微信群，默认将所有告警接收人加到群里，并在群里自动同步告警信息状态。用户可以自行拉相关的同学进群，进行告警协同。

监控预览：告警卡片展示告警指标从触发前到当前触发的变化趋势，帮助判断指标的走向和严重程度。

监控大盘：在告警规则配置的时候可以指定监控大盘链接，发生告警时可以跳转链接，进行告警纬度下钻以及更多相关监控数据的查看。

对于部分重要告警，告警通知卡片会提供根因分析信息。根因分析推荐导致告警的可能原因，并简述推导路径，同时可以跳转平台查看详细推导过程及关联的定位信息。

基本实现为：以告警来触发根因计算，通过指标多维下钻定位到异常的具体模块或接口，通过trace信息进行链路下钻，串联上下游服务的metrics/logs来定位可能的根因节点，通过知识图谱串联与之相关的组件和资源的告警与变更， 结合关联评分和因果分析算法，对告警的根因进行排序输出。

上图是近期某次线上电商核心接口报错，根因分析准确定位到是由下游es服务限流导致的。

用户常常需要查询历史的告警记录或者正在触发的告警等，从企微告警通知里很难准确地找到对应的告警，告警平台这里提供了历史告警的检索，支持检索个人/全公司告警，支持按条件查询告警列表，并可查看告警标签/监控/处理/通知等详细信息。

面向告警运营，告警统计分析能力必不可少，告警平台支持了从不同个人/业务/部门/公司视角展示告警数据的变化趋势，多维度统计分析告警分布情况，并提供快速检索和治理的能力。同时通过告警数据落仓，配置bi面板来提供更灵活更详细的告警看板。

告警平台提供告警数据统计分析、告警看板、告警报表订阅的能力，SRE同学跟进公司整体和各部门的告警数、处理率等情况，研发同学也可以按照业务订阅服务告警，以此为依据推进告警覆盖、告警降噪，进行稳定性治理。

支持研发按照指定标签组订阅告警事件，进行告警加工处理，比如执行故障自愈（磁盘异常自动报修）等。

告警通知泛滥，已是困扰b站三年之久的问题。一方面各场景各业务在不断接入新告警，另外告警缺乏有效的运营治理机制和能力，告警通知越来越多，大部分业务不会主动治理告警，而是选择通知免打扰，很多真实的风险预警和异常都被淹没了导致未能第一时间感知到。

太多告警 = 没有告警， 告警团队需要站出来跨出这一步把告警量治理到合理范围内，同时提供一些运营和分析的能力，让业务/SRE与告警团队一起完成后续长期的告警治理。

导致告警噪音大的原因有很多，主要分为以下几种原因：

• 默认告警项设计不合理。比如默认开启服务器load告警，绝大部分研发同学收到后不会处理。

• 告警通知人数放大。服务树上应用的研发角色因多种原因导致人员放大，关联的告警会发送给很多同学，部分业务的应用节点下挂载研发人数超过100人。

• 告警通知人不准。随着研发组织调整，应用相关的研发同学并不会做调整。

• 无有效的告警运营机制。告警发出后，无有效机制去驱动人去持续改进告警规则，对抗人的惰性。

• 告警处理工具不完整。不支持规则静默、免打扰、拒绝告警操作。

• 场景平台对于基于告警的服务稳定性治理参与不足。

治理前的数据：中位数告警1000次/周。我们给自己制定了一开始几乎所有人都认为不可能完成的目标：中位数告警80次/周。

• 告警数据分析：基于数据驱动的基本思路，首先完成告警数据入仓，配置了多场景多视角的告警分析视图，整理了TopN告警数量的规则、持续触发的告警规则、反复抖动的告警规则、TopN告警数据的应用、TopN告警数量的场景平台等，抓重点、拆分子任务。

• 告警处理与告警降噪能力支持：支持了按照规则纬度来静默告警，解决一条大规则触发多条告警，按照告警纬度接警或静默效率低的问题；支持个人拒绝告警，来解决告警接收人不准的问题；支持多阈值告警抑制，来解决同一场景同时触发严重和预警级别告警，只通知严重告警的诉求；支持告警通知动态间隔，来降低持续触发并且无人处理的告警噪音；支持场景平台告警订阅，调动场景平台的告警治理参与度；上线告警检索、看板功能，支持个人/业务告警的分析与治理。

• 优化告警项：部分场景的默认告警项设计不合理，我们与SRE、组件研发同学一起重新审视默认告警项。对于系统告警，关闭了存量的load告警，默认关闭新增应用的服务器告警，但保留用户自行开启的能力。对于容器告警，优化了容器cpu、内存、磁盘等饱和度告警默认阈值。对于应用告警，优化了20+应用告警模版表达式及告警阈值。

• 优化告警接收人：深度参与服务树角色治理，推进服务树研发与负责人校准；支持告警组对接值班平台，告警发送值班人；支持业务自定义告警接收人。

• 服务器挂载点治理：处理一机多挂的场景，找业务确认并关闭无效、无用的机器挂载点。

经过将近半年地推式的告警治理，告警数据得到显著改善：

• 中位数告警1000次/周减少到74次/周，减少到原来的7.4%；

• 整体告警通知数从治理前300w+减少到30w+，减少到原来的10%；

• 人均告警通知数从1600+减少到200，减少到原来的12.5%；

1）落实告警集成的准入要求：场景平台对接，必须提供经过评审的告警分级标准；必须提供标准的产品能力，支持用户进行告警规则调整。对于研发同学自定义的告警规则，对可能导致告警噪音的大规则进行提示与拦截。

2）落实常态化的告警运营机制：提供面向公司整体、部门和业务的告警报表，包括告警量、处理率、未结束态告警等统计，支持报表订阅；公司级和部门级的告警运营跟进需要有专人来执行。

3）继续提升告警配置效率：支持从grafana发起告警规则配置；支持自定义告警模版，支持告警模版动态绑定和去绑定。

4）持续提升告警处理效率：集成告警关联信息汇总及根因分析能力，加快告警定位，降低MTTR，跟可观测平台联动进行问题处理。

5）告警智能降噪：基于服务调用关系与资源依赖关系、告警语义相似度的告警合并。

6）告警规则微调：对一个告警规则支持多个微调规则，不同微调规则区分优先级、告警阈值、告警时间段和通知策略等，满足场景平台更多的告警配置诉求。

7）告警的可靠性与性能：

• 可靠性保障：对于指定了告警对象可用区的告警规则，需要调度到对应可用区进行告警计算，推进告警计算本地化的覆盖。

• 告警计算性能、端到端延迟优化，强化相关的SLA定义。

[1] vivo统一告警平台建设与实践

[2] 监控治理报警有效性评价指标

[3] 阿里巴巴稳定性指标1-5-10调研

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，欢迎点个“在看”吧！