关于故障:vivo-故障定位平台的探索与实践

3次阅读

共计 3407 个字符,预计需要花费 9 分钟才能阅读完成。

作者:vivo 互联网服务器团队 - Liu Xin、Yu Dan

本文基于故障定位我的项目的实际,围绕根因定位算法的原理进行开展介绍。鉴于算法有肯定的复杂度,本文通过图文的形式进行阐明,心愿即便是不懂技术的同学也能了解。

一、背景介绍

1.1 程序员的困扰

作为一名 IT 从业人员,比方开发和运维,多少有过相似的经验:睡觉的时候被电话叫醒,过节的时候在值班,玩耍的时候被告诉解决故障。作为一名程序员,咱们时时刻刻都在想着使用信息技术,为他人解决问题,晋升效率,节省成本。随着微服务架构的疾速倒退,带来一系列简单的调用链路和海量的数据。对于咱们来说,排查问题是一个大挑战,寻找故障起因犹如海底捞针,须要破费大量的工夫和精力。

1.2 现状剖析

vivo 曾经建设了一套残缺的端到端监控体系,涵盖了根底监控、通用监控、调用链、日志监控、拨测监控等。这些零碎每天都会产生海量的数据,如何利用好这些数据,开掘数据背地的潜在价值,让数据更好的服务于人,成为了监控体系的摸索方向。目前行业内很多厂商都在朝 AIOps 摸索,业界有一些优良的根因剖析算法和论文,局部厂商分享了在故障定位实际中的解决方案。vivo 有较完整的监控数据,业界有较完整的剖析算法和解决方案,联合两者就能够将故障定位平台 run 起来,从而解决困扰互联网畛域的定位问题。接下来咱们看下施行的成果。

二、施行成果

目前次要针对均匀时延指标的问题,切入场景包含两种:被动查问和调用链告警。

2.1 被动查问场景

当用户反馈某个利用很慢或超时,咱们第一反馈可能是查看对应服务的响应工夫,并定位出造成问题的起因,通常这两个步骤是别离进行,须要用到一系列的监控工具,费时费力。如果应用故障定位平台,只需从 vivo 的 paas 平台上进入故障定位首页,找到故障服务和故障工夫,剩下的事件就交给零碎实现。

2.2 告警场景

当收到一条对于均匀响应工夫问题的调用链告警,只需查看告警内容下方的查看起因链接,故障定位平台就能帮忙咱们疾速定位出可能的起因。下图是调用链告警示例:

图 1 调用链告警

调用链是 vivo 服务级监控的重要伎俩,上图红框内起因链接是故障定位平台提供的根因定位能力。

2.3 剖析成果

通过以上两种形式进入故障定位平台后,首先看到的是故障现场,下图示意服务 A 的均匀响应工夫突增。

图 2 故障现场

上图红框区域,A 服务从 10:00 左右,每分钟均匀时延从 78ms 开始增长,突增到 10:03 分的 90ms 左右。

间接点击图 2 蓝色的【根因剖析】按钮,就能够剖析出下图后果:

图 3 根因剖析后果

从点击按钮到定位出起因的过程中,零碎是如何做的呢?接下来咱们看下零碎的剖析流程。

三、剖析流程

图 4 剖析流程

红色箭头各局部组成了一个递归调用

图 4 是根因剖析的次要流程,上面将通过文字详细描述:

  • 第一步:前端将异样服务名和工夫作为参数通过接口传递到后端;
  • 第二步:后端执行剖析函数,剖析函数调用检测算法,检测算法剖析后,返回一组上游数据给剖析函数(包含上游服务及组件、稳定方差及 pointType);
  • 第三步:剖析函数依据 pointType 做不同逻辑解决,如果 pointType=END\_POINT,则完结剖析,如果 pointType=RPC\_POINT,则将上游服务作为入参,继续执行剖析函数,造成递归。

    RPC_POINT 蕴含组件:HTTP、DUBBO、TARS

    END_POINT 蕴含组件:MYSQL、REDIS、ES、MONGODB、MQ

最终剖析后果展现了造成 服务 A 异样 的次要链路及起因,如下图所示:

图 5 链路及起因

在整个剖析过程中,剖析函数负责调用检测算法,并依据返回后果决定是否持续下钻剖析。而外围逻辑是在检测算法中实现的,接下来咱们看下检测算法是如何做的。

四、检测算法

4.1 算法逻辑

检测算法的大体 逻辑 是:先剖析异样服务,标记出起始工夫、稳定开始工夫、稳定完结工夫。而后依据起始工夫~稳定完结工夫,对异样服务按组件和服务名下钻,将失去的上游服务工夫线分成两个区域:失常区域 (起始工夫~ 稳定开始工夫) 和异样区域(稳定开始工夫~稳定完结工夫),最初计算出每个上游服务的稳定方差。大体过程如下图所示:

图 6 检测算法

图中异样服务 A 调用了两个上游服务 B 和 C,先标记出服务 A 的起始工夫、稳定开始工夫、稳定完结工夫。而后将上游服务按工夫线分成两个失常区域和异样区域,规范是起始工夫 到 稳定开始工夫属于失常区域,稳定开始工夫 到 稳定完结工夫属于异样区域。

那么稳定方差和异样起因之间有什么关联呢?

其实稳定方差代表以后服务稳定的一个量化值,有了这个量化值后,咱们利用 K -Means 聚类算法,将稳定方差值分类,稳定大的放一起聚成一类,稳定小的放一起聚成一类。如下图:

图 7 K-Means 聚类      

最初咱们通过聚成类的稳定方差,过滤掉稳定小的聚类,找到最可能造成异样服务的起因。以上是对算法原理的简要介绍,接下来咱们更进一步,深刻到算法实现细节。

4.2 算法实现

(1)切分工夫线:将异样工夫线从中点一分为二,如下图:

图 8 切分工夫线

(2) 计算稳定标准差:使用二级指数平滑算法对前半段进行数据预测,而后依据观测值与预测值计算出稳定标准差,如下图:

图 9 计算稳定标准差

(3)计算异样稳定范畴:后半段大于 3 倍稳定标准差的工夫线属于异样稳定,下图红线代表 3 倍稳定标准差,所以异样稳定是红线以上的工夫线,如下图:

图 10 计算异样稳定范畴

(4)工夫点标记:红线与工夫线第一次相交的工夫点是稳定开始工夫,红线与工夫线最初一次相交的工夫点是稳定完结工夫,起始工夫和稳定完结工夫对于稳定开始工夫对称,如下图:

图 11 工夫点标记

(5)服务下钻:依据起始工夫~稳定完结工夫,对异样服务按组件和服务名下钻,失去上游服务工夫线,如下图:

图 12 服务下钻

(6)计算失常区域平均值:上游服务的前半段是失常区域,后半段是异样区域,先求出失常区域的平均值,如下图:

图 13 计算失常区域平均值

(7)计算异样区域稳定方差:依据异样区域稳定点与失常区域均值之间的稳定计算稳定方差和稳定比率,如下图:

图 14 计算异样区域稳定方差

(8)工夫线过滤:过滤掉稳定方向相同、稳定比率小于总稳定比率的 1 /10 的工夫线,排除失常工夫线,如下图:

图 15 工夫线过滤

(9)对残余下钻工夫线进行 KMeans 聚类,如下图:

图 16 进行 KMeans 聚类

五、简要总结

1、一种小而美的根因定位算法,利用方差量化稳定,再通过排除法过滤掉稳定小的上游,留下可能的上游作为起因。这种算法能够利用咱们较欠缺的链路数据,可实现的成本低;

2、针对上游依赖场景的起因定位,准确率可达 85% 以上。但没有笼罩本身起因造成的故障(如 GC、变更、机器问题等);

3、剖析后果只能提供大略的线索,最初一公里还是须要人工染指;

4、故障定位算是 AI 畛域的我的项目,开发方式与传统的麻利开发有肯定的区别:

  • 角色职责:领域专家(提出问题) → AI 专家(算法预研) → 算法专家(算法实现和优化) → 利用专家(工程化开发)
  • 操作步骤:调研论文和 git(业界、学界、同行) → 交换 → 实际 → 验证
  • 我的项目施行:简单问题简单化,先做简略局部;通用问题特例化,找出具体案例,先解决具体问题。

六、将来瞻望

1、故障预测:以后咱们次要关注服务出现异常后,如何检测异样和定位根因,将来是否可能通过一些景象提前预判故障,将染指的工夫点左移,防患于未然;

2、数据品质治理:以后咱们的监控数据都有,但数据品质却参差不齐,而且数据格式的差别很大(比方日志数据和指标数据),咱们在做机器学习或 AIOps 时,想要从中找出一些有价值的法则,其实挺难的;

3、教训知识化:以后咱们的专家教训很多都在运维和开发同学的脑海中,如果将这些教训知识化,对于机器学习或 AIOps 将是一笔贵重的财产;

4、从统计算法往 AI 算法演进:咱们故障定位当初理论用的是统计算法,并没有用到 AI。统计往往是一种强关系形容,而 AI 偏差弱关系,能够以统计算法为主,而后通过 AI 算法优化的形式。

参考资料

  • [1]Dapper, a Large-Scale Distributed Systems Tracing Infrastructure[EB/OL],2010-04-01.
  • [2]Holt-Winters Forecasting for Dummies (or Developers)[EB/OL],2016-01-29.
  • [3]k-means clustering[EB/OL],2021-03-09.
正文完
 0