写点什么

故障定位场景下的数据可视化实践

  • 2019-09-10
  • 本文字数:2697 字

    阅读完需:约 9 分钟

故障定位场景下的数据可视化实践

百度拥有上百条产品线,数十万的服务,每个服务时时刻刻都在产生着海量的监控数据,形成的监控项规模总数已达数十亿。面对如此海量的数据,在日常运维(如故障诊断、成本分析、性能优化等场景)过程中,传统的统计图表难以有效直观地展示如此庞大的数据。因此,优秀的监控数据可视化产品就呼之欲出,他既要数据准确、全面、时效性高,也需要提升用户的使用体验,使其能在茫茫数据中一眼就能发现想要观察的数据。


那么怎么做才能适应用户需求、完成精准展示,同时又能挖掘数据价值呢?下面我们从故障诊断的场景出发,来看百度智能监控平台是如何充分利用数据可视化武器来解决实际业务问题的。

故障定位可视化思路

在标准的故障处理流程中,故障定位一般可分为两个阶段:


  • 故障止损前:期望可以快速获得可用于止损决策的信息,做出相应的止损操作使得服务恢复。比如通过确定故障范围,调度流量绕过故障机房或摘除故障实例等。

  • 故障止损后:仍需要进一步找到导致故障的深层次原因,确定故障根因,将线上环境恢复到正常状态。


基于上面的需求,可以总结为以下三个定位的层次,从整体到局部逐步缩小故障范围,找到故障根因:


1.全局问题定位:快速确认线上状态,缩小故障判定范围。为可能的止损操作提供判断依据。本文会介绍如何构建一个全景分析仪表盘。


2.细分维度定位:通过分析地域、机房、模块、接口、错误码等细分维度,进一步缩小问题范围,确定需要排障的目标模块、接口等。本文会介绍如何基于多维度数据可视化解决维度数量暴增带来的定位难题。


3.故障根因确认:一些情况下,问题的根因需要借助除监控指标之外的数据进行分析。例如上线变更、运营活动导致的故障。本文针对导致故障占比最高的变更上线类故障进行分析,看如何快速找到可能导致故障的变更事件。

全景掌控缩小范围

对于一个服务乃至一条产品线而言,拥有一个布局合理、信息丰富的全景监控仪表盘(Dashboard)对于服务状态全景掌控至关重要,因此在百度智能监控平台中,我们提供了一款可定制化的、组件丰富的仪表盘服务。


用户可以根据服务的特征,自由灵活的组织仪表盘布局,配置所需要展示的数据信息。



如上图所示,我们可以按照问题定位的思路,将服务整体的服务可用性情况、分功能可用性情况、分模块的核心指标、流量的同环比对比、分 IDC 的流量对比等,依次通过丰富的可视化组件进行呈现。使得在收到报警时,可以快速将故障缩小到具体功能、模块、接入流量、机房级别。

深入数据确定根因

在故障处理过程中,全景数据仪表盘为我们缩小了故障定位的范围,但大多数的根因仍然隐藏在数据的细分维度中。由此多维度分析的重要性就体现出来了。常见的多维度分析包括如下几种场景:


  • 单维度取值对比分析:针对同一个维度的不同取值进行对比分析,例如确定流量下跌出现在哪个省份。

  • 多维度关联分析:分析两个甚至更多维度互相作用后数据的分析,例如如何确定一个下跌是机房级别还是模块级别。

  • 维度下钻分析:一些维度包含多个层级,例如省份、城市等相关联维度的逐层下钻定位。


我们针对这些场景,设计了相应的解决方案。

单维度取值对比分析

维度取值对比分析是一种最常见的细分维度定位方式。对于同一个维度下取值数量较少的情况,可以通过多维度趋势图和饼图等可视化方式进行快速的分析,查看不同维度取值的取值状态,以及占整体比例情况。而对于维度取值数量多,且不同取值数量级差距较大情况(例如分省份的流量下跌判定),使用饼图或趋势图很容易把流量较小省份的信息隐藏掉。这种场景下,我们可以通过维度取值自动展开功能,分别查看每个省份的状态。


多个维度关联分析

细分维度的故障所带来的表象可能会在多个维度均有表现,比如服务整体的访问拒绝上升,我们会发现分机房的拒绝量上升,也看到分模块的拒绝上升。那么我们如何确认故障的根因是来源于某个机房还是某个模块,还是这两者的交叉维度,即某个机房的某个模块导致的问题。


矩阵热力图可以解决这一问题。将需要做分析的两个维度分别作为横纵坐标,通过阶梯的阈值颜色将对应交叉维度的取值展现再坐标上。我们便可非常直观的看到这这两个维度对于整个业务的影响情况,如下图所示:



我们可以看到,从纵向的分模块维度,可以看到 Module 4 在多个机房都有明显的访问拒绝情况,而在横向分机房维度,则没有明显的特征。则说明是 Module 4 模块导致的问题。

嵌套维度下钻分析

类似于国家-省份-城市的行政区域划分,区域-机房-机器的服务部署划分,我们可以看到很多维度之间存在着层次嵌套的关系。我们故障定位的思路也是如此,从整体到局部逐步分层下钻定位。


我们提供了多维度展开报表功能支持这种下钻分析。



例如我们怀疑是某几台服务器导致的拒绝量上升,我们可以基于多维度统计报表,点击排序找到拒绝最大的区域,然后依次展开找到拒绝最大的机房和机器。


点击详情后,我们就可以跳转到机器对应的页面,查看对应机器的详细数据来进行定位。


找寻关联事件定位

根据历史经验,大多数的线上故障都是由于变更操作所引起的,包括程序、数据、配置等变更事件,增删机器实例、执行预案等运维事件,甚至包括可能引发流量突增的活动运营事件。对于某些体积庞大的产品线,开发和维护人员众多,以上事件的发生更是千丝万缕、错综复杂。


面对这个问题,我们设计并推出了一种可以解决这种问题的通用性组件——事件流图。



通过事件流图,可以快速筛选出故障的前后时间,发生或发生中的事件,每个事件通过色块的长短位置,展示了开始结束时间以及持续时长。我们可以快速的分析出对应时间的故障可能是由于某些操作开始或操作完成引发的。


对于部分业务线,同一时间段发生的事件可能有上百甚至上千条,我们提供便捷的筛选功能来解决这一问题。通过事件类型标签,打开或关闭某一类事件的展示,优先排查最有可能的根因。同时对于每一类事件的支持细分筛选,用户可以自定义事件筛选的条件,支持多项选择、文本模糊匹配等多种方式,使得定位范围一层层缩小,最终找到问题根因。

总结

以上我们介绍了百度智能监控平台在全局故障分析、细分维度定位、事件关联定位三个故障定位阶段中进行的数据可视化探索。当前百度智能监控平台已成为百度各大业务可用性保障必不可少的利器。


数据可视化能力的优势不仅仅在故障定位场景中由突出体现。还能应用在更多的数据分析领域。我们未来会进一步介绍百度智能监控平台在应用性能分析、商业数据分析等领域的实践成果,欢迎各位继续关注。


作者介绍:


运小炜,百度高级研发工程师,负责百度智能监控平台(赛亚平台)的设计和研发工作,在系统监控、业务监控等方向有广泛的实践经验。


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


原文链接:


https://mp.weixin.qq.com/s/C09VxmsgdKWwYkIcsgHf4Q


2019-09-10 11:073682

评论

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

ARTS-WEEK2

Allen

学习笔记-第二周

薛定谔的🐴

极客大学架构师训练营

「编程模型」C++资源引用

顿晓

c++ 智能指针 shared_ptr make_shared 资源引用

「架构师训练营」学习笔记:第 2 周

Amy

极客大学架构师训练营 作业

一文讲透SpringMVC

知春秋

spring springmvc Servlet

架构师训练营第二周作业

小树林

极客时间架构师训练营 - week2 - 作业2

jjn0703

极客大学架构师训练营

学习总结-编程本质与架构设计原则

飞雪

设计模式

张瑞浩

以“血联网”缓解“血荒” “硬科技”赋能生物安全

CECBC

区块链技术 智慧血站 物联网化

这 10 行比较字符串相等的代码给我整懵逼了,不信你也来看看

程序猿石头

性能优化 信息安全

依赖倒置原则以及week2 作业

不在调上

极客大学架构师训练营

week2 学习总结

不在调上

每周 ARTS 第 33 期

落英坠露

ARTS 打卡计划

如何更好的使用Gson

Jackey

Java Gson

架构师训练营第2周作业

风吹

设计模式原则

张瑞浩

互金总结系列(2)-- 前后端分离

互金从业者X

架构师训练营-命题作业2

水边

极客大学架构师训练营

思维模型 - 组合式创新

石云升

思维模型 组合式创新 拆解组合

极客时间架构师训练营 - week2 - 作业1

jjn0703

极客大学架构师训练营

架构师训练营-每周学习总结2

水边

极客大学架构师训练营

【省吾身】创新及其发生条件

luojiahu

创新 日常思考

ARTS-week-3

youngitachi

ARTS 打卡计划 arts

架构师训练营作业(二)

Glowry

极客大学架构师训练营

架构师训练营-学习笔记-第二周

心在飞

极客大学架构师训练营

Flink on Zeppelin (1)入门篇

Geek_8o1tcx

大数据 flink 流计算 Zeppelin

作业

飞雪

认识依赖倒置原则(DIP)

极客大学架构师训练营 第二周作业

架构师训练营——Week2作业

Shawn

ARTS-WEEK3

一周思进

ARTS 打卡计划

故障定位场景下的数据可视化实践_文化 & 方法_运小炜_InfoQ精选文章