AIOps 平台的误解,挑战及建议, AIOps背景及所应具备技术能力分析(上)
1043
2022-11-03
“告警定位”简简单单四个字,想要做好却不是一件容易的事情。每一条告警,都会包含相应的告警级别(根据程度分为critical, major, minor, warning),告警类型(根据告警源分为网络告警,专线告警,主机告警,TDSQL告警,WEMQ告警等),告警对象(具体的异常点比如主机A,数据库B),告警发生时间等信息。传统的做法是将故障时间段内的低级别的告警过滤掉,只保留高级别的告警,然后按照专家经验对剩下的告警进行优先级排序,比如说网络告警的优先级最高,优先推出;母机、子机告警同时出现,母机告警优先推出;TDSQL节点告警和TDSQL主机告警同时出现,优先推节点告警。类似这种规则还有很多很多,大多都是根据历史案例和运维人员的专家知识归纳总结出来的。这种做法存在几点问题:
规则覆盖的范围总是有限的,有时会出现误告,需要运维或开发人员对现有的规则进行修改或者添加新的判断分支,费时费力,并且随着规则库的不断扩大,维护起来也越发麻烦,新的规则和原有的规则冲突的情况也时有发生。
有时低级别的告警往往包含了更重要的信息,是更应该被推出来的根因,但是按照现在的逻辑是会被过滤掉的,从而导致信息丢失;如果放开限制,对全级别的告警进行分析,又会引入很多噪声,从而导致误判。
可解释性较差,根据规则推出的告警经常会让运维人员一头雾水,因为这种做法缺乏推理的过程,运维人员只看到最后的结果,却不清楚这个结果是怎么得到的,难以让大家信服。
好的告警定位的方法应该是一个由表及里、从大到小的过程。通过故障发生时的表象,一步步推导,过滤掉干扰项,缩小候选告警集合的范围,最后定位到关键的一条或者几条告警,再整理成方便运维人员阅读的根因话术输出。
对于微众银行而言,故障发生直接会导致一部分交易出现超时、中断等现象。因此,异常交易就成为了一个很好的故障分析切入点。而交易的超时和中断怎么判断,依赖于交易树的信息。下面,我简单介绍一下交易树的概念。一笔交易从开始到结束,会在 RMB(消息总线)上留下调用消息的日志,这里称之为“原始消息日志”;原始消息日志通过规则引擎预处理之后,得到多个消息对,每个消息对包含 request 和 response 两条 message,代表一次调用;结合 cmdb(配置管理数据库) 的数据,处理消息对,依据调用的响应方,生成多个 tree node(一个响应方,一个节点);将离散的 tree node 依据 node 的上游以及下游转换成若干条 tree chain;将若干条 chain 依据相同父链路等规则合并成树,再做一些整理,如横向合并、纵向合并就得到最后的交易树。处理流程如图 1:
图 1 交易树处理流程图
不同业务场景(借款,还款,账户查询)下的交易,结构可能会差别很大,如图 2,图 3,但是处理的流程都是一样的。
图 2 场景 A 的交易树示例
图 3 场景 B 的交易树示例
图 4 一棵具体的交易树
如图 4 所示,交易树上的每一个节点对应行内的一个子系统,包含子系统 id、所在 dcn、所在 ip、处理耗时、提供服务以及关联到的 tdsql、wemq 等信息。
故障发生时,一般会有多笔交易受到影响,对单笔交易而言,根据相应的接口日志、节点耗时、是否发生中断等信息可以快速定位到异常子系统。比如节点耗时,可以采用同环比,即比较具有相同交易树结构的异常交易和正常交易的节点耗时,耗时增幅最大的子系统即认为是异常子系统;或者采用深度学习算法例如变分自编码器 VAE 来学习每种交易树结构中不同子系统的耗时分布,这部分本文不展开介绍,感兴趣的同学可以自己查阅相关资料。考虑到有可能是上游子系统出了问题进而影响到了下游子系统,我们就把每笔异常交易定位出的异常子系统和它的上游子系统结合起来进行分析,这样既大大缩小了根因告警的范围又尽可能的覆盖到故障出现的所有位置,可谓一举两得。
定位到故障的子系统后,接下来就只需要去找故障发生时间段内这些子系统所能关联到的各种类型的告警。比如说对于主机告警,用到的信息有子系统 id、所在 dcn、所在 ip,我们采取从精确范围到模糊范围逐步扩大范围的方式去关联,先去关联该子系统该 ip 的主机告警,没有的话就去关联该子系统该 dcn 的主机告警,还是没有的话再去关联该子系统所有能关联到的主机告警,当然随着范围的不断扩大,关联到的主机告警的置信度也是不断降低的;对于 TDSQL 或者 WEMQ 告警,直接去找该子系统所能关联到的 tdset 节点 /wemq 集群上面是否存在相应的告警即可。
对于关联到的告警,我们需要对它进行打分,目前用到的打分参数是:告警等级(critical, major, minor, warning)、关联子系统类型(上游子系统,下游子系统)、关联到的交易数量等要素。通过复盘历史案例,可以得到不同参数的权重以及判定阈值。得分高于这个阈值的告警认为是引起本次故障的原因之一,加入根因告警集合;得分低于阈值的告警常常是频繁、周期性发生的,或者是提供的信息在得分较高的告警中已经包含,故可以过滤掉。目前由于异常告警的得分和正常告警的得分有比较明显的区分度,故可以直接手动确定阈值和不同参数的权重;后续随着故障案例的不断增加以及新的打分依据的出现,可以用机器学习的方式来确定阈值与参数权重,常见的算法有 LR(逻辑回归), GBDT(梯度提升迭代决策树) 等。
根因告警集合中可能包含多种类型的多条告警,可读性是较差的,所以需要我们进一步进行聚类,把相同类型的告警(常见的分类是:TDSQL、WEMQ、应用主机、网络、内部程序、TGW 等)合并在一起,每类只保留一条汇总的、可读性较强的根因告警,同时每类告警的结果我们会赋予一个置信度,最后将这些结果按置信度排序输出,方便运维人员快速、准确的定位到故障。
一个典型的案例是某业务的当前平均时延指标突增,定位到的异常子系统上也出现了大量的外部接口报错日志,从表象上来看大概率是外部合作伙伴问题。但是通过搜索异常子系统所关联到的 tdset 节点,可以发现该节点上存在多条 critical 级别的告警,且影响了多笔交易,故认为异常更有可能是由 TDSQL 引起的。后经运维人员确认当时该节点确实存在大量的慢查询,导致业务的平均时延突增,外部接口报错只是表象,数据库慢查询才是故障的根因。由此可以看出,精准的告警定位可以帮助我们找到问题的真相,让我们“拨开云雾见月明”。
当然现有做法也有一些不足:对于网络类型的告警,是无法通过交易树关联到的,改进的方法是对于每个历史案例,提取相应的告警特征,训练一个分类器(LR,SVM,GBDT 等)来帮助我们判断故障类型,这样当新的故障发生时,只需要把分类器输出的类别下相应的告警聚类即可。
除了故障根因定位以外,故障预警也是一个可以展开的方向。上文我们有提到过有一些级别较低的告警,实际上在故障大规模发生之前,往往系统会出现性能降低、可用率下降等情况,导致少量的交易流水出现问题,虽然还够不上一个异常事件,可是一旦没有及时处理,问题逐渐累积,就会引发一次故障。如果我们能够用这些异常交易来关联低级别的告警提前进行分析,也许就能够防患于未然,做到故障提前发现、提前处理。
告警根因定位怎么写
异常检测 -> 告警策略 -> 根因分析都是 AIOps 中非常关键的步骤。
告警策略模型通常和业务类型、用户偏好及应用场景等业务相关,解决不同场景下特定问题。
根因定位:定位发生异常时那些属性导致了异常;定位哪些指标的异常导致事件异常的发生;
FOCUS:《Focus: Shedding Light on the High Search Response Time in the Wild》,目标是解决在运维过程中,发现高搜索响应时间之后,使用机器学习算法发现异常的原因和规则。
FOCUS 使用系统每天产生的日志数据来训练决策树,从决策树中可以分析得到引发高搜索响应时间(HSRT)的条件,由于每天的数据会训练出一棵决策树,因此多天后会有多棵决策树产生;
在多棵决策树中挖掘出相似的会引发高搜索响应时间(HSRT)的条件,这些条件在多天中重复出现,可判断为长期的引起高搜索响应时间(HSRT)的可能条件;
最后评估挖掘出的引发高搜索响应时间(HSRT)条件中每个属性的影响,从而得出优化系统性能的方案。
HotSpot:多维根因定位
告警策略是 AIOps 流程中异常检测的下一环有着至关重要的作用,往往联动决定着在特定场景下异常检测告警模块的效果好不好:在告警触达,业界多会进行告警收敛、降噪和抑制等相关的规则和算法的探索,致力于提供精简有效的信息,减少告警风暴及干扰。而更进一步的故障定位(根因分析)方向,现主要有基于规则的定位、基于关联性分析的定位、基于知识图谱的相关探索等,通过算法和规则提升故障定位的精召率。
上述就是小编为大家整理的基于交易树的告警根因定位方法,告警根因定位怎么写
国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)睿象云智能运维平台分析、比较及推荐
发表评论
暂时没有评论,来抢沙发吧~