告警风暴的处理

原文名称:Understanding and Handing Alert Storm for Online Service Systems

通常当应用服务出现故障时,会伴随大量告警,告警风暴便产生了。因告警风暴的数量非常大,如果运维工程师手工检查每一条告警,系统排障过程会耗费大量的时间和精力。

需要回答如下问题:

“告警风暴中到底发生了什么故障”

“哪些告警与故障相关”

“告警风暴的核心内容是什么”

目前现状:

一,告警风暴出现的频率很高;

二,当前对告警风暴的识别方法是人工设置固定阈值,无法适应动态的在线场景;

三,告警风暴中包含有的常规告警,与故障相关的告警也存在关联,如文本和拓扑相关性。

需处理的问题:固定阈值的告警风暴检测表现不好,混杂在故障中的不相关告警影响排障,需要做告警降噪,告警之间复杂的关联关系也需要建模来精炼。

警风暴检测:需要知道什么时间发生了告警风暴。监控告警的数量,将告警风暴检测转化为一个突变点检测,使用EVT去自适应准确检测告警风暴。

告警风暴摘要:准确检测到告警风暴发生后,需要做三个步骤:基于学习的告警降噪,将告警风暴中与此次故障无关的告警全部删除;差异化的告警聚类,总结告警里有多少告警簇;代表性告警选择,在每一个簇找到代表性的告警选择,减少工程师看的数量。

最终通过告警风暴摘要,选取出与故障相关的告警集合,并且这些告警能够从多方面反映故障。

告警风暴摘要的三个步骤:

步骤一:基于机器学习的告警降噪,可将其转为异常检测的问题,因为故障不常发生,经常发生的告警和这次故障没有关系。经常发生的告警像异常检测里定义的日常情况,而不经常发生的罕见告警有像异常情况。使用isolation forest方式检测到的罕见告警,更有可能和故障相关,在这过程中对告警进行属性提取和特征统计。

步骤二:经过告警降噪过滤后,剩下的告警做告警聚类,使用DBSCAN聚类方法。对聚类的度量,也就是相似性度量,因考虑了文本相似性和拓扑相关性,所以使用Jaccard距离;拓扑相关性定义了软件层面和硬件部署层面两种拓扑,使用它们相连的最短路径去刻画拓扑相关性。

步骤三:有了告警相关性,使用聚类方法得到告警的类,每一类均代表对故障的描述,选择一个聚类中心来作为代表性的告警。

 

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
在OpenStack中,告警处理是一项重要的任务,它有助于监控和维护云环境的稳定性和可靠性。下面是一般的OpenStack告警处理流程: 1. 告警收集:OpenStack的各个组件和服务会生成各种告警事件,如资源使用率超过阈值、服务中断、硬件故障等。这些告警信息通常会被记录在相关的日志文件中或发送到监控系统。 2. 告警通知:一旦发生告警事件,系统管理员或运维团队应该及时收到通知。这可以通过邮件、短信、即时通讯工具等方式来实现。 3. 告警分类和分级:收到告警通知后,管理员需要对告警进行分类和分级,以便更好地理解和处理告警事件。根据告警的严重程度,可以将其分为不同的级别,如严重、警告、信息等。 4. 告警分析:在进行告警处理之前,需要对告警进行分析,以确定其原因和影响范围。这可能需要查看相关日志、监控指标和配置信息,以便更好地理解问题的根本原因。 5. 告警处理:根据告警的类型和严重程度,采取适当的措施来处理告警事件。这可能包括修复故障、重新配置服务、调整资源分配等。 6. 告警记录和跟踪:对每个告警事件进行记录和跟踪是重要的,以便后续分析和审查。记录包括告警的详细信息、处理步骤和结果等。 7. 告警验证和关闭:在处理告警后,需要验证问题是否得到解决,并关闭告警事件。如果问题仍然存在,需要重新评估并采取进一步的行动。 此外,OpenStack还提供了一些工具和服务来帮助进行告警处理,如Ceilometer用于收集和分析监控数据,Aodh用于告警管理,以及其他日志和监控工具。 需要根据具体的OpenStack部署和需求来制定适合的告警处理策略。希望以上信息对你有所帮助!如果还有其他问题,请随时提问。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值