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

苏宁基于服务层知识图谱的真假告警判定

  • 2021-02-26
  • 本文字数:3522 字

    阅读完需:约 12 分钟

苏宁基于服务层知识图谱的真假告警判定

一、概述

在第一篇文章《苏宁基于知识图谱的大规模告警收敛和根因定位实践》中,我们详细阐述了如何构建基础设施层的知识图谱,得到了很多同行的反馈,在实际的线上环境取得了很好的告警收敛效果。但是,线上的异常事件还有另一个非常重要来源:基于 AI 的异常检测。(注:我们的 AI 异常检测复现了亚马逊诸多模型并且进行改进,通过集成算法做母模型取得了与亚马逊模型相当的水准) 异常检测虽然是通向 AIOps 的重要一环,但是由于其预测/检测的不确定性,会存在一定的误告警,当大规模使用在生产环境中时,误告警的数量开始不断叠加,很可能形成告警风暴,这是一个突出及困难的问题。本文的宗旨就是要通过可解释的知识图谱关联出现异常事件的上下文并进行真假告警的判定。此文的另一个贡献就是通过分析服务与服务间的调用关系来构建服务级的知识图谱,同时,在构建过程中,我们借鉴复现并优化了复旦与 eBay 的很有价值 Paper[3]:Graph-Based Trace Analysis for Microservice Architecture Understanding and Problem Diagnosis , 在此特别感谢他们此前做的杰出的工作。

二、痛点及对策

痛点


(1)大规模上线后异常检测形成的误告警很多

例如:某一系统的 3 天指标进行分析,3 日中告警次数为 141 次告警,而用户标记的真实告警仅发生了 7 次。


(2)告警事件中真假样本不均衡

例如:本文分析的某系统 3 天的样本标记数据来看,假告警样本为 134 个,真告警样本为 7 个,进一步分析发现真告警样本的告警类型也是 7 个,也就是每个真实告警类型 3 天内只发生了一次真实告警,进一步地,真实告警的发生频次必然不会太高这也意味着不可能获取到很多的真实告警样本数据。


(3)误告警事件种类多样

  • 抢购活动导致异常指标飙升引发异常检测系统报警

  • 检测指标经常性的在 0 点附近波动,导致异常检测系统发现指标异常触发下限而报警

  • 被检测指标本身波动性较大且无周期性规律,触发异常检测系统报警


(4)标记工作量大

  • 从用户标记的工作量来看,目前每天系统发出近百的告警信息,如果都需要用户去对每一个告警进行人工标记真假也会对用户带来巨大的工作量,影响其本来的正常工作。

  • 由于存在着真实样本较少且样本不平衡的问题,即使通过数据增强等产生真告警样本,也需要大量的工作量去验证样本质量。我们尝试了使用对抗神经网络产生真样本,但是样本质量并不理想。

对策

针对上述痛点,我们经过大量资料翻阅和讨论,决定结合业务上下文指标和历史标记过数据进行推理。技术上构建可解释的服务层知识图谱:使用切分窗口的实时调用链数据构造基于知识图谱的调用关系,并获取调用上下文的关联指标,进而与历史标记过的数据做相似性推理,从而判明真假。

三、架构

图 1 系统架构图

 

(1) 数据管道:利用消息中间件将调用链日志抽取到“日志抽取与分析”模块中。

(2) 日志抽取与分析:主要功能为将抽取的日志进行实时分析,并将分析结果写入到分析型数据库中。

(3) 异常检测系统:利用历史数据和深度学习概率性地计算未来指标波动边界,并以此边界判断指标是否异常。

(4) 知识图谱推理:主要功能是将分析好的调用关系同步至图数据库中,并提供查询分析功能,依据调用上下文的指标数据和历史数据进行告警的真伪判断。

四、流程

图 2 真假告警推理流程图

(1)抽取实时指标数据;

(2)历史实时指标数据集作为输入,通过深度学习模型对异常边界进行预测;

(3)对超出异常边界阈值进行判断,如超出阈值则先判定为“疑似”异常,请求知识图谱推理系统对当前异常的真伪性进行判定;

(4)设定分析窗口(3 分钟,可配置的超参),从分析型数据库中抽取对应的告警日志进行分析;

(5)根据告警日志中的 TraceID 分析出本次告警所在时间窗口内的调用链 PathID 的列表;

(6)依据本次告警所在时间窗口内的调用链 PathID 列表来统计在此列表中同时发生的上下文异常指标,以及指标的发生频次;

(7)对比历史上同告警事件的 PathID,以获得调用链相似度;

(8)利用本次告警与历史告警知识图谱上指标及其指标发生频次来推理出本次告警与历史告警上误告的上下文相似性;

(9)综合调用链相似性与指标上下文的相似性来判断本次告警是否为真实告警。

五、详细的知识图谱构建与分析

5.1 调用链日志数据的解析与入库


  • 设定分析窗口(3 分钟),从消息管道中抽取数据。


  • 按照日志中的 TraceID 进行聚合分析,其中调用链中服务名与操作名有缺失的部分进行丢弃处理,对没有 root 头的 Trace,多余一个 root 的 Trace 进行丢弃处理。在生成 TraceID 后按下列算法计算 PathID 并和已有的 PathID 进行对比,如果不存在则将当前调用链发给知识图谱推理系统进行保存,如果已存在则只更新当前 PathID 的相关信息。



  • 将分析后的 Trace 信息,指标信息写入到实时分析数据库中。

5.2 Trace 明细表构建


  • 以 TraceID 为粒度分析每条 Trace 明细的调用链关系,并生成 PathID。

  • 将日志抽取数据和 PathID 合并,插入到 Trace 明细表中,如下图:


图 3 Trace 表明细

5.3 图谱构建


  • 依据调用链中的引用关系,构建完整的实体树状结构,并计算该调用链的 PathID。

  • 如果 PathID 相同则认为该调用链已存在不用处理,如果不同则认为是条新的调用链关系并将之存入到图数据库中。

图 4 图谱构建

5.4 指标表构建


  • 分析调用链的结构,找到发生在窗口时间内的调用链上的相关指标。

  • 在分析窗口时间内分析相关指标的发生次数。

  • 将相关指标的统计信息记录至指标表中。


图 5 指标表明细

5.2 基于知识图谱的告警真伪分析


  • 首先依据当前告警的调用链 PathID 寻找历史上相同指标发生误报的调用链 PathID。

  • 依据调用链 PathID 搜寻发生在本次调用链上的相关指标以及该指标的发生次数。

  • 通过调用链以及调用链上的相关指标来计算本地告警与历史告警的相似度。

  • 如果相似度高于阈值则认为本次告警是误报,否则为真实告警。

 

图 6 指标图谱

六、效果及后续

效果


(1)现状分析


分析样本抽取某平台 2021 年 1 月 18 日至 2021 年 1 月 20 日 3 天的告警数据,分析结果如下:

  • 总计发生告警 141 次,其中 18 日告警发生 52 次,19 日发生告警 34 次,20 日发生告警 57 次;

  • 进一步分析发现,在这 3 日的告警中误告发生了 134 次,真实告警只发生了 7 次,误告占比非常高;


图 7 告警量现状


图 8 真实告警占比占比

(2)误报类型分析


  • 从该平台告警分析的结果来看,2021 年 1 月 18 日至 2021 年 1 月 20 日 3 天的告警情况分析,共有 59 个类型的指标发生告警;

  • 在这 59 个类型的告警中大致可分为“抢购误报类型”与“波动性误报类型”。

 

图 9 告警次数分析

(3)结果分析


  • “抢购误报类型”我们选择 CSC-32-0023 作为分析目标,从表中可以看出该指标 3 日都在同一时间发生告警,且该时段是有抢购现象。


  • “波动性误报类型”我们选择 SYS-01-0016 作为分析目标,从表中可以看出该指标每天发生在不同的时间段,且从告警现状分析该指标存在明显的波动过大而造成误报的特征。


图 10


  • 对于告警码 CSC-32-0023,18-20 号发出的告警都在每天的同一时刻,其调用链上的指标相似度较高,这三次告警得关联程度达到了 99%以上,通过初始阈值就可过滤掉该指标的误报问题。


  • 对于告警码 SYS-01-0016,18-20 发出得告警分散在每天的不同时刻,其调用链上的指标关联性较低,所以这些告警的关联程度相较前一个告警码有所降低,不同时段调用链的相似度大约在 70%,但通过历史标记数据学习合理的关联程度阈值,可以有效的避免该指标的误报问题。


图 11 结果分析

(4)最终效果


通过分析上述误告数据,在加入知识图谱推理流程后大致能够降低 80%以上的误报,误告从 134 次减少到了 25 次,而真实告警正确率达到了 100%。

后续


  1. 服务架构理解与异常传播分析:微服务架构的全面应用虽然在开发、部署、维护方面带来极大的易用性,但也带来了微服务间接口调用的复杂性以及对系统全局的清晰理解,基于调用链构建的服务级知识图谱能能够清晰地洞察服务调用的全局,以及更重要的是,当发生故障时,能够洞察故障传播的路径和影响的系统,以便更好地响应排查故障,最大程度地减轻企业的损失。


  1. 结合《苏宁基于知识图谱的大规模告警收敛和根因定位实践》,我们已经构建了多级知识图谱,基于业务领域特点做了实体的解析和关系抽取,但是并没有针对 RDF 语义规范[4]来构建语义知识图谱,并不是说一定要按照 RDF 的标准来构建,相反,如果能够遵循这套标准来构建并使用 SPARQL 以及分布式数据处理[5]等来进行分析推理,那么语义分析的能力将进一步增强,这也是下一步我们将开展的重要工作。

 

参考:


苏宁基于知识图谱的大规模告警收敛和根因定位实践

苏宁 AI 监控运维保障建设实践

Graph-Based Trace Analysis for Microservice Architecture Understanding and Problem Diagnosis

RDF 1.1 Concepts and Abstract Syntax

Distributed Semantic Analytics using the SANSA Stack


作者介绍(排名不分先后):


苏宁科技智能监控 AILab)汤泳、苏宁科技智能监控 AILab)陈延彬、苏宁科技智能监控 AILab)胡创奇、苏宁科技智能监控 AILab)张波、苏宁科技智能监控 AILab)陈松

2021-02-26 08:413819

评论 1 条评论

发布
用户头像
历史数据是固定的数据量?
2021-03-01 11:38
回复
没有更多了
发现更多内容

桌面多空间使用技巧

吴脑的键客

chrome Windows 10 fedora

存储大师班 | Linux IO 模式之 io_uring

QingStor分布式存储

Linux 文件存储 分布式存储 Linux Kenel

项目绩效考核管理有哪些方法?这7种考核方式值得一试!

优秀

低代码

北鲲云超算平台解决生物科学领域困境,探索更多可能性

北鲲云

工卡融合柔性屏,办公效率和信息安全性可能会有质的飞跃?

船医特拉法尔加

架构之路,道阻且长

長庚

数据驱动决策,可视化推动传统电力发展革命史?

一只数据鲸鱼

数据可视化 智慧能源 水力发电 智慧水利

揭秘百度微服务监控:百度游戏服务监控的演进

百度Geek说

微服务 大前端 游戏

数字人民币热度不断攀升 多地再迎大规模试点

CECBC

中国移动5G消息开发者社区强势助力,创客马拉松大赛5G消息专题赛重磅来袭!

5G消息

开发者 开发者社区 应用开发 开发者大赛 5G消息

初学汇编

若尘

汇编 汇编语言 7月日更

自学者福利!BAT常见的20道Android面试题详解

欢喜学安卓

android 程序员 面试 移动开发

(ROYOLE)全球首款柔性屏开发套件,柔宇RoKit终于来了!

Vsir·横磨剑

Git工作流中常见的三种分支策略:GitFlow、GitHubFlow和GitLabFlow

华为云开发者联盟

git 软件开发 工作流 GitFlow GitHubFlow

Serverless 时代下大规模微服务应用运维的最佳实践

阿里巴巴中间件

云计算 Serverless 微服务 云原生 中间件

通证经济最核心的价值,就是带来了流动性的质变

CECBC

mysql常用命令

阿呆

mysql命令

智汇华云 | kata container virtiofs测试和技术分析

华云数据

对标阿里水准!2021年最全Java架构面试点+技术点标准手册

Java架构追梦

Java 学习 阿里巴巴 架构 面试

JVM面试高频考点:由浅入深带你了解G1垃圾回收器!

华为云开发者联盟

Java JVM 服务端 G1垃圾回收器 Java堆

什么是 shell?

学神来啦

云计算 运维 Shell shell脚本编写

极狐 GitLab 初探(上)

极狐GitLab

ci DevOps gitlab CD 敏捷开发管理

万万没想到,低功耗也会烧毁元器件?

不脱发的程序猿

嵌入式 电路设计 低功耗 ADI 稳压器

区块链的风险与防范

CECBC

图扑软件受邀核电数字化技术大会,技术创新助力行业革新

一只数据鲸鱼

数据可视化 核电 核电站 数字大会

思购臻选系统开发|思购臻选APP软件开发

Redisson 分布式锁源码 11:Semaphore 和 CountDownLatch

程序员小航

Java redis 源码 redssion redisson 分布式锁

官宣!DataPipeline2021数据管理与创新大会将于7.29北京重装开启!

DataPipeline数见科技

大数据 数据融合 数据管理

门道APP开发|门道软件系统开发

自学编程找工作!46道面试题带你了解中高级Android面试

欢喜学安卓

android 程序员 面试 移动开发

呱呱乐园软件开发|呱呱乐园系统APP开发

苏宁基于服务层知识图谱的真假告警判定_AI&大模型_汤泳_InfoQ精选文章