云环境下商业银行应用系统的故障实时检测与根因定位

2021 AIOps 挑战赛

626支参赛队伍竞赛剩余时间71奖金¥260000
  • 描述
  • 评估
  • 奖金
  • 时间线

本届挑战赛以“云环境下商业银行应用系统的故障实时检测与根因定位”为主题,采用两家大型商业银行真实应用模拟,将根据真实环境中常见的故障类型重放故障。比赛中,主办方将提供建行云作为云服务器,参赛团队在报名成功后可获悉云服务器申请方式和数据获取方式。


每支参赛队伍需采用同一套代码,对两家银行的数据进行实时的故障检测,并准确定位出反映故障的指标或日志。参赛队伍需在发生异常后的规定时间内输出结果,系统会从平均故障检测时间、定位精度和查全率等指标评判参赛队伍的算法效果。系统会记录历次故障注入的评测分数,并更新榜单排名。



报名通道已开放,请参照【规则】信息进行报名。有意参赛者可以扫描下方二维码添加微信,赛事详情会在微信群中通知。




描述

本届挑战赛的数据来源于大型商业银行真实应用模拟,将根据真实环境中常见的故障类型重放故障。比赛中,主办方提供建行云作为云服务器,参赛团队在报名成功后,将由工作人员说明云服务器申请方式和数据获取方式。

预赛阶段第一批数据已经释放,已报名的队伍请注意查收邮件。

数据:

- 应用服务静态拓扑

- 实时调用链数据

- 实时业务黄金指标

- 实时性能指标(操作系统、应用组件、中间件和数据库等)

实时日志(操作系统、应用组件、中间件和数据库等)



关联数据集

数据集名称 文件名称 文件描述 上传时间 操作
6979 请等待数据集公开 readme.zip 数据集暂未公开 2021-01-20 14:41:13 登录后,可下载
还可以输入200个字符loadding评论

我的评论

锤子哥刚刚

相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

总共0条评论

排序
  • 所有
  • 锤子哥一天前

    相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • 还可以输入200个字符回复
  • 锤子哥一天前

    相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • 还可以输入200个字符回复
  • 锤子哥一天前 作者

    相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

      还可以输入200个字符回复
  • 锤子哥一天前

    相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • 还可以输入200个字符回复
  • 锤子哥一天前

    相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • Jia.xu一天前

      蓝鲸的产品肯定Nice

      @他
    • 还可以输入200个字符回复
  • 锤子哥一天前 作者

    相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!相当的Nice,对工作很有用,帮助我减轻了很多不必要的杂活儿,给作者赞一个!有了它,排查系统负载高的进程一目了然,赞!

      还可以输入200个字符回复

参赛规则

参赛对象

面向全社会开放,年满13周岁的个人、高等院校、科研单位、企业、创客团队等人员均可报名参赛。数据集建立及维护过程中能接触到数据的相关人员不得参赛。

报名方式

报名时间:即日起至2021年2月20日。

每支参赛队伍需完成以下两步:

1. 请所有参赛选手在报名网站(http://iops.ai/competition_list/ )注册账号并报名:访问网站–>点击页面中的“云环境下商业银行应用系统的故障实时检测与根因定位”–>注册登录账号–>点击“我要报名”按钮;

2. 每支队伍自行选出1位领队,由领队将成员信息同时发送到以下两个邮箱: netman_iops@126.com 和 aiops@niisa.cn 。待工作人员审核邮箱报名信息无误后,会回复邮件,提示报名成功并说明云服务器申请方式和数据获取方式。

邮件格式示例

邮件标题:2021国际AIOps挑战赛报名-队伍名称 

邮件内容:   

队伍名称: *** 注册邮箱: *** (领队注册邮箱)  

领队 姓名: *** 身份证号: *** 手机号: *** 所在单位及部门: ***

队员1 姓名: *** 身份证号: *** 手机号: *** 所在单位及部门: ***

队员2 姓名: *** 身份证号: *** 手机号: *** 所在单位及部门: ***

请注明是否参加过往届国际AIOps挑战赛或相关相关算法竞赛,如KDDCup,Kaggle等:(如是请注明赛事名称)        

……

(说明:参赛队伍若为学生,所在单位及部分填写所在学校及院系、年级)

注意事项

1. 参赛队伍不限制参赛人数。

2. 为保证大赛的公平性,请每支参赛团队的领队严格按照邮件格式,将组队信息发送至指定邮箱,方可报名成功。如果未按要求填写,很可能无法通过审核。

3、云服务器使用方面,主办方原则上将为每支队伍分配不超过3个账号,如参赛队伍人数超过3人,则优先按照报名邮件中的队员顺序分配。

4. 比赛过程中手机号请勿更换,后续云服务器使用需与报名信息中手机号保持一致。

5. 如果一个人参加多个队伍,与该人员关联的所有队伍都将被取消资格。

6. 参赛队员必须遵守并签署《AIOps挑战赛选手报名协议》。

赛程安排

本届挑战赛分为预赛、复赛和决赛分为三个阶段:

1. 预赛阶段:

· 2021年1月21日,开放网站报名;

· 2021年1月底,离线开放第一批数据(不包含故障),选手可以分析正常数据的特点并进行建模;

· 2021年2月初,离线开放第二批数据(包含故障),选手可以尝试从数据中检测故障并定位根因,从而更新模型;

· 同期线上召开宣讲会,进行赛题解读;

· 2021年2月下旬,开放评测,实时发布第三批数据并循环发布多轮,选手可以进行模型调优;

· 2021年3月下旬,预赛结束,按照第三批数据最后一轮的选手提交结果进行排名,选手需提交代码。

2. 复赛阶段:

· 2021年3月下旬,不多于20支队伍受邀进入复赛;

· 2021年4月中旬,复赛评测,实时发布一轮评测数据,期间选手代码不可调优;

· 2021年4月下旬,复赛结束,选手需提交代码。

3. 决赛阶段:

· 2021年5月13日举办决赛答辩,邀请不多于10支队伍进入答辩,对测试结果和答辩效果加权计算总成绩,决出最终的大奖。

4. 比赛具体时间以组委会通知为准。

评分规则及队伍审核

1. 评分规则:参赛队伍在两家大型商业银行实时检测异常并根因定位,按照平均故障检测时间、定位精度和查全率等指标计算积分。

2. 比赛机制:本届挑战赛数据来源于两家大型商业银行真实应用模拟,具有相同的数据结构。参赛队伍在挑战赛阶段需对两家银行的数据采用同一套代码,体现出检测和定位算法的通用性。预赛阶段和复赛阶段的代码可进行调优,提交的代码需能分别复现出挑战赛两个阶段的结果。

3. 为保证比赛的公平性,主办方会检查每个复赛队伍的代码中是否有作弊行为以及硬编码的故障检测和定位规则。

4. 复赛名额确定:预赛成绩不超过20支队伍将进入复赛。为了保证公平性,我们将对不超过20支队伍进行代码检查,避免作弊行为。

5. 决赛名额确定:复赛成绩不超过10支队伍将进入决赛。为了保证公平性,我们将对不超过10支队伍进行代码检查,避免作弊行为。

6. 代码审核:预赛、复赛结束前各队伍将代码按要求放在指定目录,写一键运行脚本,主办方将登陆选手机器进行结果复现和代码检查。

奖项设置

以下提及金额为税前金额

一等奖 1名:100,000人民币,颁发获奖证书

二等奖 2名:50,000人民币,颁发获奖证书

三等奖 3名:20,000人民币,颁发获奖证书

QA整理:

关于赛制

Q:最终比赛代码必须开源吗?提交的代码等后续会要求开放给比赛主办协办方吗?

A:欢迎报名参赛。代码不要求开源,代码在初赛和复赛结束由组委会封闭审核。此外,代码的知识产权属于选手,不会开放给比赛的主办、协办方,但进入决赛的选手要求在答辩时介绍自己参赛的方案。

Q:赛制有没有文档?

A:在iops.ai上已有发布参赛规则,而评测等详细赛制会在微信公众号 智能运维前沿,官方微信群通知大家

Q:第一批数据说没有注入故障数据, 那第一批数据中是否是说所有的数据都是正常形态的数据,不包含任何业务故障的数据?

A:第一批发布的数据是没有注入故障的,业务实际运行也会有波动、噪声等,属于正常形态。

Q:第二批带有注入故障的数据发布后, 回提供里面包含故障的信息么? 比如总共注入多少个故障?

A:第二批注入故障的数据会提供注入故障的时间,数据发布时候会有更详细的说明。

Q:有哪些可用的docker镜像源?

A:现在只提供清华镜像源(https://mirrors.tuna.tsinghua.edu.cn)的访问权限,需要安装软件的话可以考虑。不开放其他镜像源的访问权限。

Q:云服务器可以访问外网吗?可以通过ssh客户端登陆吗?

A:现在只提供清华镜像源的访问权限,不能访问其他外网,并且不能通过ssh客户端登陆。

Q:如何确定自己已经报名成功了?

A:请通过邮件报名,并以邮件回复为准。

Q:请问团队人员需要变化,比如增加,减少,该如何操作?

A:将最新的队员信息发送至组委会邮箱,主题请标注为“队员变更”。

Q:云服务器为什么不能进行数据的上传?

A:上传和下载的权限暂未开放,后续会进行通知。

Q:堡垒机账号的静态密码是共享的吗?一个人改密码会影响其他人吗?

A:不会影响。

关于赛题

Q:trace数据中的spanID,traceID代表什么呢?

A:traceID代表一个完整的调用链,spanID代表调用链中的一次调用,其中,一次调用的duration为该调用从出发到完全结束(遍历完整个子树)所耗的时间。

Q:挑战赛的初试复试的Trace结构是一样的吧?初赛和复赛的数据区别只是时间不同是吗?

A:初赛复赛的Trace结构是一样的,初赛复赛的数据格式标准是一样的。初赛和复赛的流程不同,初赛第三阶段数据会循环发布多次供选手优化模型,而复赛阶段数据只发布一次。

Q:请问比赛数据是否提供不同指标的正常取值范围?

A:  取值范围建议指标的参考单位,而正常的取值范围不会提供。因为正常取值很难给出,这也是指标异常检测的挑战所在。

Q:故障定位的入口是黄金指标异常?

A:  不局限于黄金指标,定位故障的入口可以通过黄金指标、业务指标、调用链或日志。

Q:“业务指标”中的tc(交易码)是什么含义,与调用链中的trace_id是否有关联?

A:  交易码可以理解为交易的状态码,和trace_id没有关联,是否用于异常检测需要自行判断。

Q:分析调用链时,发现存在断链,找不到调用链起点或中间部分,这种在初赛和复赛都会出现吗? 

A:  在生产上确实会有这么一个问题,后续我们会保证数据真实的条件下,尽量让数据完整的

Q:调用链的span_id,例如:369-bcou-in-way1-c514cf35-96938-202101291847-188,这种格式有什么含义吗?

A:  span_id在数据说明上不会包含具体的含义的

Q:请问KPI里面交易码(tc)有什么含义,为什么在a里面是哈希值的形式,在b里面是服务名的形式呢?这样非数值形式的KPI故障会以关键字形式出现吗?

A:交易码可以理解为一个接口,两边的表达方式不太一致,所以会有不同,system-a里可能涉及到一些保密信息所以做了脱敏处理

Q:Redis是高可用的吗?其他服务呢,做了心跳检测和负载均衡了吗?

A:感谢您的提问,但该问题涉及业务的具体实现,业务其实对选手来说可以视为一个黑盒。因为赛题的目的是做业务无关的检测定位系统,同时能处理两个不同的系统。但为了给选手一个系统正常状态的参考,我们给出了第一批正常的数据,之后发布了第二批带有故障的数据,可以对比发现正常和故障异常时候的区别,而无需关注业务本身实现的细节。

Q:能否把两个系统的部署清单,按业务处理的功能举例做一下讲解?

A:  该问题涉及业务的具体实现,业务的实现对选手来说可以看作一个黑盒。因为赛题的目的是做业务无关的检测定位系统,同时能处理两个不同的系统。但为了给选手一个系统正常状态的参考,我们给出了第一批正常的数据,之后发布了第二批带有故障的数据,可以对比发现正常和故障异常时候的区别,而无需关注业务本身实现的细节。

Q:请问一下,关于硬编码这个有什么说明吗,我看到system b采集了gc数据,这个数据的分析和计算方式比较成熟,算throughput,latency ,以及gc耗时都需要硬编码

A:  挑战赛不鼓励硬编码的检测方式,因为实践中也有KPI用固定阈值做检测的方式,固定阈值就属于硬编码,但是硬编码可能很难适用于两个系统。最终决赛的成绩我们会综合考虑选手最终得分以及选手的方案实现。

Q:第一批数据中的时区是哪里?

A:目前日志数据中存在UTC+0的时间戳,其余为北京时间,之后批次的数据会保证时间列均为北京时间。

Q:什么是多个根因同时出现的情况?是指调用链的多个叶子节点出现问题吗?

A:多根因出现有两种情况,第一种情况是两个指标异常都属于故障导致的可观测到的最接近的根因的指标或者日志,第二种情况是故障发生在两个不同的节点上,出现多灾的情况(这种故障会少一些)。后续在对外放出故障数据的时候会给出相应的标签,以供参考。

Q:根因定位前系统会给出问题时段吗?

A:在预赛与复赛中,异常都需要选手自行检测与定位。

Q:关于trace数据,目前存在spanID不唯一的情况,是怎么一回事?

A:这属于脏数据,需要自己处理,同样的,确定一条trace是否已经消费完毕也需要选手自行解决。

Q:第二批数据会提供丰富的标签数据吗?

A:为保证赛题的难度,不会提供每一个对象的全量故障标签。

Q:竞赛过程中可以人工干预程序产生的结果吗?

A:不可以。

Q:从收到第二批故障数据到在线评测大概会有多长时间?

A:大约有一周时间,第二批故障数据会尽快发布。

关于系统-a

Q:为什么system-a 中 kpi_0127.csv 的时间戳是1月25日的?

A:目前我们已经修复system-a数据处理中的问题,数据下载链接不变。另外第一批数据提供数据格式的参考,也可以忽略时间戳不匹配的问题,之后发布的时间戳将为北京时间。

Q:system-a两天数据的traceID,子节点ID、父节点ID没有一条是重复的。每次调用都重新生成这些id吗?

A:  目前是只有一个节点,后续在拓展之后会有新的,节点接入。

Q:A数据存在的疑问: 1、“部署清单”中缺少主机和Redis的对象关系,是否会提供; 2、“性能指标”清单中缺少Haproxy指标数据,是否会提供; 3、“部署清单”中cmdb_id=gjjcoreap01~gjjcoreap03,对应的类型是“weblogic, zookeeper”,是否可以明确是weblogic还是zookeeper?

A:  1和2之后都会提供,3是同时包括weblogic和zookeeper两个组件

Q:下载 system-a 里面 现在只有28号的数据吗?

A:是的,我们在尽力准备更多的数据出来,大家持续关注一下群消息

Q:system-a/system-b在后续数据中会将cmdb_id扩容吗?

A:system-a因为节点数量较少后续会做相应扩容,这个部分的部署架构很快就会出来。

Q:为什么有一些cmdb_id在部署清单中不存在?

A:这是第一批数据存在的问题,在后续数据中将不会出现。

关于系统-b

Q:B数据存在的疑问: 1、“部署清单”中缺少主机、F5对象关系,是否会提供; 2、“性能指标”清单中缺少Apache、Docker、F5的指标数据,是否会提供;

A:  F5的对应关系不会提供,Apache在日志中体现,Docker的数据会补充,F5的指标数据不会提供。

Q:system-b调用链1~55条都有,system-a调用链均为1条,这种情况是正常的吗?

A:  第一个问题是正常的,因为目前的system-a在后续的过程中会进一步扩展,节点会相应增加,因为两套系统的架构有一些区别

Q:system-b调用链不同cmdb_id的timestamp相差3分钟,是不是os的系统时钟不同步吗,后续数据还会存在这种情况吗?

A:  我们留意到这一个问题,后续会处理这个问题的。

Q:目前的指标中没有docker01-03的数据,请问是为什么?

A:后续数据会发布。

关于评测

Q:请问开放评测之后,每支队伍有提交代码次数限制吗?

A:首先代码提交只是在初赛、复赛结束提交一次。我理解选手更多关心检测到答案的提交,会给选手设置登录建行云的开放期和封闭期,具体时间请看后续的通知。 在开放期选手可以挑优模型,提交答案。具体来说初赛和复赛是不一样的,初赛数据重放多轮,比如重放5轮,选手就可以提交5次,以最后一次结果当作初赛的成绩,排名靠前的可以进入复赛。复赛的提交只有一次。

Q:两个系统是独立的吗?独立定位?实时检测的时候会随时切换系统吗?

A:两个系统是独立的,所以要独立的检测和定位,相当于选手的代码开两个进程处理数据,检测定位故障,实时提交答案。

Q:最后答案的输出格式是怎样的?

A:宣讲会提到过是[[cmdb_id, root cause1],  [cmdb_id, root cause2], ...]的格式,后续会发宣讲会的文字版请注意查看,具体提交说明也会在预赛第三阶段前通知。

联系我们

报名通道已开放,有意参赛者可以扫描下方二维码添加微信,赛事详情会在微信中通知。


          


上传的结果文件

刷新
文件名称 文件描述 上传时间 文件大小 分数 计算状态 错误信息 操作

注册

请输入正确的邮件格式

密码长度6-20位

两次输入密码不匹配,请重新输入

昵称已被占用,请重新输入

点击[注册],即代表你同意 《iOps注册协议》
注册

注册协议

【首部及导言】

为有效利用QQ号码资源,维护用户合法权益,特制订《QQ号码规则》(以下简称“本规则”)。请您务必审慎阅读、充分理解各条款内容,特别是免除或者限制责任的条款,以及开通或使用某项服务的单独协议,并选择接受或不接受。限制、免责条款可能以加粗形式提示您注意。

除非您已阅读并接受本规则所有条款,否则您无权申请或使用QQ号码。您申请或使用QQ号码的行为即视为您已阅读并同意受本规则的约束

一、【规则的范围】

1.1 本规则是腾讯制定的关于获取和使用QQ号码的相关规则。本规则适用于腾讯提供的需要注册或使用QQ号码的全部软件和服务。

1.2 本规则属于腾讯的业务规则,是《腾讯服务协议》不可分割的组成部分。

1.3 您通过QQ号码使用腾讯的软件和服务时,须同时遵守各项服务的单独协议。

二、【QQ号码的性质】

QQ号码是腾讯创设的用于识别用户身份的数字标识。QQ号码的所有权属于腾讯。

三、【QQ号码的获取】