报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

我在百度对抗报警风暴(二)

  • 2019-09-30
  • 本文字数:2678 字

    阅读完需:约 9 分钟

我在百度对抗报警风暴(二)

在本系列上一篇文章《我在百度对抗报警风暴(一)》中,百度高级研发工程师运小博介绍了报警风暴的成因及简单的报警合并策略。本篇文章中,运小博将介绍关联策略的报警合并策略、基于报警数据挖掘的机房故障分析、报警关注度分析、值班与逐级通告机制和报警回调等技术。

报警合并策略

关联策略的报警合并

某个模块的出现问题的时候,往往会引发上游或者下游模块也一并报警。假设模块 A 调用了模块 B,当模块 B 出现问题的时候,很显然模块 A 和模块 B 都会产生报警。为了解决这个问题,我们尝试从历史报警数据中挖掘关联的报警策略列表,然后就可以使用《我在百度对抗报警风暴(一)》提到的报警合并机制对跨模块的相关报警进行合并。


历史上每次 B 模块出现同样的问题的时候都会导致 A 模块有类似的报警,换言之,若历史上 A 模块的策略 rule1 和 B 模块的 rule2 经常同时报警,那么 A 模块的策略 rule1 和 B 模块的策略 rule2 就可能存在关联。因此我们可以挖掘历史报警数据中的关联关系,即关联的报警策略列表。



如上图横轴为时间轴,每一个位置都产生报警的时间,比如最开始的报警是 A 模块的 rule1,然后是 B 模块的 rule2 等等。然后使用挖掘窗口(上图中的大括号为一个挖掘窗口)进行滑动,把位于同一个窗口内的报警归结为一个事务。


接下来我们就可以使用常见关联分析算法挖掘频繁项集(历史上经常在一起出现的报警策略)和关联规则(报警策略之间存在很强的关系)了。我们先要回答一个问题,怎么样定义报警策略的频繁出现?或者说,两个报警策略是否存在关联?


一个项集的支持度计数被定义为该项集出现的次数,这里没有用传统的支持度是因为历史报警数据产生的数据往往较多,而实际项集数据出现的比较稀疏,意味着支持度的分母巨大,分子却很小。


置信度是针对一条关联规则 X:rulem->Y:rulen 而言定义的,代表了 X:rulem 导致 Y:rulen 发生的可能的概率。


支持度计数 S_count(X:rulem)=以 X:rulem 开头的 transaction 的数量


支持度计数 S_count(X:rulem->Y:rulen)=以 X:rulem 开头,并且包含 Y:rulen 的 transaction 的数量


置信度 c(X→Y)计算公式如下:



支持度和置信度超过一定数值即为所需的关联规则。按照这样的规则,在等待发送队列中当某个报警发送时在报警策略关联表中查找等待队列中是否包含关联策略,如果包含就合并成一条报警信息发送。

机房故障期间的报警合并

机房故障(网络中断、机房断电等)会导致部署在该机房的模块异常,引发大规模的报警风暴。报警风暴不但会对报警的处理造成打扰,而且可能会增大报警系统压力,严重时可能导致后续报警延迟送达。因此,如果能快速准确地感知机房故障,并将相关报警进行合并,将会有利于运维人员快速捕捉故障根因,还能减少报警系统压力。


一个机房往往部署有多个业务系统,而一个业务系统也会把自己的模块部署在多个机房中以提高可用性。当某个业务的运维工程师发现单个机房的多个模块出现故障,就会怀疑是机房故障,但很难直接确认。所以,他们一般都会找其它业务的运维工程师寻求确认。如果多个业务都在这个机房出现问题,就基本能够确定是机房的基础设施出了故障。


通常,我们会想使用每个机房的报警数量来表征这个机房的状态,但百度部分产品的体量庞大,当这些业务故障的时候,会导致报警量突升,从而影响对机房的判断,因此最终我们选择了异常策略比例 RuleRatio 和异常业务比例 ProductRatio 两个特征。


为了寻找如何用上面的两个特征确定是否有机房故障,我们抽取了历史一段时间各个机房的特征,并利用散点图来训练。如下图所示,横坐标是 RuleRatio,纵坐标是 ProductRatio,每个点代表某个时段的某个机房。图中红色为机房有故障的样本,蓝色为无故障的样本。



从上图看,线性分类器就能区分故障和非故障的样本。



对历史数据进行回溯,上图横轴是时间,纵轴是按上述指标计算的异常评分,每一条曲线代表了一个机房,几个异常点分别是某一次机房的故障。

报警关注度

报警关注度是指报警发送后有实际处理的比例,但系统运维一段时间后都会发现部分报警的关注度并非 100%,大多数情况下并非是值班工程师不尽责,而是部分报警策略随着系统的演化已经失效而又没有及时删除,因此需要我们有一种方法识别无效报警。

夜间关注度分析

我们观察了一条报警的处理过程。收到一条有效的短信报警后,值班工程师会登录运维系统(包括监控系统、预案系统等)对报警进行定位、处理,这些行为会体现在各种运维系统的访问日志中。通过收集这些日志,就可以对每条报警的处理情况进行分析:如果在收到报警后的一段时间内访问过运维系统,可以认为该报警得到了关注,反之就认为该报警没有得到关注。汇总一段时间后,就能够筛选出关注度较低的报警策略,即为无效报警策略。

报警值班与逐级通告机制

百度监控系统(Argus)报警通路帮助运维团队建立值班机制,支持配置值班表,并设定交接班时间、值班周期等,值班系统会按周期自动轮转,并以短信、邮件等形式在交接班前通知接班值班人。为了保证核心报警得到及时有效的处理,Argus 中还建立有逐级通告机制,支持配置多个通报升级时间和通报方式(电话、短信等)。报警发出后,值班人必需及时认领报警,超时未认领会按照配置升级并通告。下图就是一个值班和逐级通告配置的例子。


报警自愈机制

很多报警都有明确的处理预案,报警发生后,值班工程师登录机器或者中控机执行预案(脚本)就可以完成这类故障的处理。比如,清理磁盘这类操作,可能就是一个简单的删除日志和 tmp 目录的脚本。如果这类报警可以完全自动处理,无需人工干预,就能够大量节省人工成本,同时减少报警量。因此,Argus 报警系统提供了报警回调机制,在报警发生时可以回调预案处理脚本。


上面介绍的这类自愈场景比较简单,这类预案往往对于程序没有任何干扰,可以“无脑”执行预案脚本即可。对于更复杂的场景,值班工程师往往需要根据服务的整体情况来调整预案。例如当某个实例异常需要重启的时候,需要综合判断其他实例的状态才能确定是否以及何时可以重启该实例,如果无脑重启可能会给服务造成损失。这种场景的自愈操作可能是有损的,需要对服务整体情况有一个判断才可以执行预案,Argus 报警系统为此提供了另外一种回调机制。在发生报警时,报警系统会把相关的报警策略、实例的状态都统一发送给一个中枢决策服务,由中枢决策服务统一做出判断。


作者介绍:


运小博,百度高级研发工程师,从事有关运维数据分析相关的工作,负责异常检测系统和报警收敛等工作,重点关注时序数据分析、故障诊断等相关领域技术。


本文转载自公众号 AIOps 智能运维(ID:AI_Ops)。


原文链接:


https://mp.weixin.qq.com/s/vODNelOyTwyciI-6sYBUtA


2019-09-30 08:002599

评论

发布
暂无评论
发现更多内容

阿里巴巴拍立淘API返回值:商品关联推荐与交叉销售

技术冰糖葫芦

API Explorer api 货币化 API 接口 API 测试

按需扩展,成本优化:灵活的服务配置

可观测技术

成本优化

解锁企业成功密码—商品计划的神奇力量

第七在线

JNPF快速开发平台赋能数字办公方式转变

不在线第一只蜗牛

低代码 数字化转型 数字化办公

14点自动化经验

FunTester

远程访问内网设备:对比IPsec VPN,SD-WAN异地组网更具优势

贝锐

运维 SD-WAN 远程运维 组网

IoTDB 单机/双活/集群部署的区别和适用场景

Apache IoTDB

Qwen2-Math 开源 AI 模型发布;阿里云推出首个域名 AI 大模型应用丨 RTE 开发者日报

声网

XIAOJUSURVEY重磅升级,推出图形化逻辑编排能力

XIAOJUSURVEY

开源 规则引擎 可视化编排 图形化编排 问卷逻辑

易点天下KreadoAI爆款视频生成功能上新 解锁出海营销新路径

新消费日报

相聚中国香港,共赢智能未来!华为云邀您共赴 KubeCon China 2024

华为云原生团队

云计算 云原生 KubeCON AI 人工智能

某个国外的真实XSS漏洞利用探寻

我再BUG界嘎嘎乱杀

黑客 网络安全 信息安全 XSS 漏洞

Pinterest:从 Druid 到 StarRocks,实现 6 倍成本效益比提升

StarRocks

Druid Pinterest

畅捷通基于Flink的实时数仓落地实践

Apache Flink

大数据 flink 实时数仓

API可观察性对于现代应用程序的最大好处

幂简集成

API API 接口

Kubernetes 监控:观测云与 Prometheus CRD 的集成

可观测技术

Kubernetes

就一次!带你彻底搞懂CSRF攻击与防御

我再BUG界嘎嘎乱杀

黑客 网络安全 信息安全 CSRF 网安

vue前端自适应布局,一步到位所有自适应

不在线第一只蜗牛

Vue 前端

实用指南|在多云环境中部署向量数据库

Zilliz

大数据 向量数据库 LLM 大语言模型 AICG

亚信安慧AntDB-T:使用Brin索引提升OLAP查询性能以及节省磁盘空间

亚信AntDB数据库

AntDB

数据分析与决策支持:京东商品详情API的商业价值

技术冰糖葫芦

API Explorer api 货币化 API 接口 API 测试

京东面试:说说CMS工作原理?

王磊

智源未来选择 TDengine Cloud,解锁高效能源管理

TDengine

观测云突变告警,精准预测云原生的系统异常

观测云

云原生 监控告警

邀请函 I 松下信息和望繁信科技邀您参加「数智时代下大数据应用的“道”与“术”」闭门会议

望繁信科技

大数据 数字化转型 解决方案 流程挖掘 流程智能

我在百度对抗报警风暴(二)_文化 & 方法_运小博_InfoQ精选文章