人均告警减少90%—— B站告警治理与根因分析实战

如何获得讲师PPT：

扫码关注公众号，后台回复「1130」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

告警有效性是怎么定义的呢？

我们目前已经在告警侧提供了告警标记的功能，方便在告警侧进行标记，区分有效与无效告警。这部分能够部分展示高警的效率。此外，更多基于整个告警处理和跟进过程，对右侧的反馈进行一些输入。同时，可通过高警噪声来展示，若噪声放大较严重，其有效性将显而易见地降低。

这个告警治理是否主要靠人力筛选减少规则？

告警治理在前期主要涉及历史债务的治理。对于此，可以先通过头部和维度的治理来大幅度减少噪声。当治理进行到一定程度后，需要结合运营推动的机制来进行更全面的治理。当然，人力筛选也是必要的，因为整个治理过程也是运营推进的过程。举个例子，我们之前会通过主机告警关联到具体的复数挂载点来进行治理。但由于历史原因，挂载点与主机关联并不合理，导致很多主机告警的统治放大。因此，我们通过文档方式对数千个挂载点进行了确认和治理。这些历史债务是无法逃避的，因此人力必不可少。

业务侧的告警关联降噪可以举个例子吗？是在监控侧关联还是在告警侧关联？业务告警可以和基础告警关联吗？

这里面利用了部分原数据的关联及更新分析能力。例如，业务测的一个业务服务可用性告警发出后，我们在关联分析过程中，各个组件资源、容器资源、基础设施等告警也会被挖掘出来，这样业务就可以基于这些告警来发现可能的问题。这些对于业务测试用于定位的高警，组监测需要收集并处理。业务告警可以与基础设施告警进行关联，并在整个关联过程中，基于元数据的血缘关系来进行关联。

告警后有进一步的自动分析场景吗？

报警后有进一步的自动分析场景。正理分析是指它的一个定位的一个分析。我就按先按照定位温度分析来回答，如果后续还有补充的话，我们再具体看。告警之后，大部分场景是基于根因分析做自动的分析。我们在错误分析阶段会自动去监听这部分。已经介入跟音分析的去监听这部分告警触发会系统自动的做更新分析，并且带出更因业务在看到告警之后，就可以看到它的原因。同时，我们也是支持去手动触发更应分析的，对于就没有介入更。它需要在我们提供了高音卡片，一个更应分析的一个入口，它点进去之后，会主动触发一次根因分析，然后最终去做它的一个关联，上下游或者是一些变更的信息，并推荐出来它的一个根因是什么。

老师好，监控告警通知的发送状态和效果怎么管理？怎么处理通知失败或异常的情况？谢谢

这段话与我们的多活和稳定性建设有关。首先，高警计算到高警通道侧，我们实现了主备逻辑，以保持通道状态的一致性。但是，如果计算投递到通道出现异常，前置负载均衡会执行降级策略，自动切换到备用通道以完成失败的降级。另外，对于一些投递通知，如企业微信、电话或邮件，如果失败，一方面会通过重试队列进行重试。同时，对于电话投递，我们也实现了阿里云、华为云和百度云之间的互逻辑来确保通知的成功率和可靠性。

老师所讲的SLO告警和我们平时所理解的SLO有什么区别？是B站认为触发了SLO告警就是有故障，需要记录为异常事件，后续可以去做和告警的关联归因，来帮助AIOps体系的算法能力进行升级迭代？

目前有一个专门的质量稳定性保障团队SRE负责SLO平台和体系。SLO高警主要针对SLO有break风险的情况，并触发告警。然而，告警并不直接意味着故障。SLO高警并不直接代表故障。故障也有一个故障平台去管理，可以定义一些规则作为故障的触发条件，可以是SLO告警或其他。高警出发后，会进入一个异常事件，我们会基于这个异常事件来做更音。这也有助于我们整个体系的持续建设。

告警的关联、分级和过滤是重点吧，这块可以详细讲讲

报警关联分级和过滤是一个复杂的话题，可以作为专题详细讲解。简单来说，关联性是多方面的，包括不同容器实力的告警与容器实力归属宿主机的报警、容器实力对应的一些业务应用的告警等。分级更多的是前置定义，不同应用等级下，对于不同异常场景的预值和触发条件是不同的，通知优先级也有所区别。

在过滤方面，我们整个通道的降噪能力比较强大，包括微调抑制聚合等多种降噪能力。具体问题可以在后续线下沟通中详细讲解。

事前静默策略是咋实现的？在哪些场景下可以使用？

事前策略是我们预先定义的一些维度，以时间段为单位进行静默。例如，可以静默某个应用的高警，或者在机器搬迁时静默该机器下的所有高警。这些静默策略可通过我们提供的平台能力进行配置，通道会实时加载这些策略，判断策略是否在有效期内，并通过一些告警匹配策略，判断是否匹配到这个策略，做一些判断和处理。适用场景包括机器搬迁或压测等，都需要做一些事前静默。

请问下，在告警合并方面，高优告警怎么不被淹没？同时保证低优告警的质量巡检？

告警合并是将不同聚合队列区分开来。每个聚合队列都有告警等级的定义。最终队列会根据高等级来处理，例如高优告警不会与低优告警和高邮告警合并在一起。即使低优告警较多导致队列满或延迟，也不会受到影响。低优告警巡检主要是风险和隐患类的质量巡检，可以事先定义出来。这块的优先级可能不需要通知，只需要做巡检事件记录，方便后续查看和分析。

怎么优化根因分析的效率和准确性，来支持实时分析和批量处理呢？ 根因分析过程中，大量的数据和日志信息怎么管理和存储？有哪些最佳实践和经验可以分享？

优化效率和准确性。首先要建立评价体系，再基于数据去做分析优化。优化过程中，需要关注关联系数的优化和查询效率的优化，因为大多数分析耗时是数据查询。对于算法分析耗时相对较低，重点是各个数据维护方和负责人要联动合作优化数据查询性能，减少耗时，提高分析效率。准确性一方面要覆盖全，随着知识录入逐渐完备，召回和准确也会提升，另外还要考虑专家经验系数。总之，需要实时获取异常期间的指标数据、日志数据等，进行实时分析存储。

告警收敛这块，例如我的系统有Java服务和Redis集群组成，在Redis集群出问题的情况下，监控系统产生Java服务告警和Redis集群告警，类似这种情况是否需要做告警收敛？

在Java服务集群中，当规模较大时，可以建立关系，并基于依赖关系进行合并和收敛。对于B站而言，服务与平台维护团队负责跟进这些告警，但告警人群可能不同，主要面向服务用户。因此，通过关联和收敛的方式，将服务类告警投递给用户，并将Redis与之关联，而不是将所有告警一起放出。

在告警治理中，评价告警的几个维度是什么？

告警处理中，评价告警的维度包括我们确定的几个指标，其中一个是一天整体通知数量，另一个是通知中位数。整体通知数量反映了全局告警噪声的通知情况，而中位数则反映了中间大部分人群每天接收的告警数量。此外，我们希望通过标记达标能力来获取高警有效性的指标，并基于告警有效性来评价整个告警治理的效果。

请问告警通知、告警分析和告警治理这些模块，都是你们自己开发的吗？还是有购买外部的成熟软件？

告警通知、分析、治理等模块都是我们自主研发的，包括整个告警通道和告警分析平台的前后端能力和产品能力。此外，我们公司还采购了一些外部报表以扩展告警分析能力，并通过集成数仓以报表方式展示。但核心的通知分析和治理能力是我们自主研发的。

B站有没有可观测性平台？告警平台和可观测性平台的关系什么样的？

B站有可观测平台，告警平台主要负责定义异常、触发异常、排查定位以及观测巡检等相关服务。这些功能主要是通过可观测平台呈现，而告警平台可以看作是可观测平台的一个入口，用于触发报警。集成根因分析能力能够快速推荐根因，同时可以在可观测平台上定位排查具体原因。

老师能不能交流下现有监控系统与chatgpt结合后，能产生哪些新的运维能力提升？

实际上，我能够想到的最主要的是，对于我们的智能问答系统，由于我们监控整个监控系统每周都会遇到许多日常重复性的问题，因此通过结合ChatGPT的方式，我们可以更好地提升效率，并智能化地自动回答一些重复的问题，从而减少人力投入。

另外，目前业界已经有一些大模型的应用，这些大模型在各个场景中都有指标日志。我们正在探索这些大模型是否能够对整个异常发现和定位能力进行提升。