【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

新思路设计可视化大型微服务监控系统

  • 2018-01-10
  • 本文字数:3724 字

    阅读完需:约 12 分钟

背景

随着微服务在生产实践中被大量使用,后台系统中的服务系统数量暴增,挑战也随之产生。当系统出现问题时,如何在上百个相关的、依赖错综复杂的服务系统之中快速定位到出错的系统?

达达 - 京东到家的 Overwatch 系统已经在线上运行了一年有余,采用了创新性的可视化监控设计,并成功帮助达达 - 京东到家的系统渡过了“双十一”的挑战,设计思想值得分享。

“双十一”期间,系统承载了京东商城每天几百万单的压力,“双十一”当天单量即突破 600 万单,第二天的单量更是超过了 800 万单。对于大型微服务系统来说,任何一个服务系统出现问题,都可能导致大面积的系统故障。当配送员在配送过程中操作 APP 然后发现操作失败时,究竟是订单系统出现了问题?还是用户系统出现了问题?还是某个第三方服务出现了问题?导致这些问题的是数据库的慢查询?还是系统本身的 GC?又或者仅仅是一次网络波动?

在没有 Overwatch 之前,每当线上系统出现报警,我们的工程师都要登上相应系统的某台机器查看日志。然而这样的工作收效甚微,因为可能出现问题的原因真的有很多:

  • 该系统响应失败是因为调用其他系统失败,报出错误的系统本身并没有问题。
  • 调用其他系统失败是由于网络问题,请求并没有到达目标系统,所以在目标系统的日志中看不到任何异常。
  • 被调用的系统响应超时,导致调用方主动断开连接,在被调用方的日志中只能看到连接意外中止的异常信息。
  • 调用其他系统存在一条很长的调用链,无法快速追踪到源头。

为了达到京东商城对配送时效的高标准,我们必须快速响应、定位并解决系统故障。通过 Overwatch 系统,我们便可以做到这一点。

Overwatch 监控系统

简介

Overwatch 是一个远程调用监控系统,通过对系统调用外部系统的监控,并以可视化图形的方式展现,实现对大型微服务系统可用性的监控。

Overwatch 能够实时监控系统中所有的 RPC(广义上的 RPC),及时发现所有 RPC 调用失败情况。通过一个有向图进行数据展现,让工程师可以在多个系统同时异常时快速定位到异常的根源。

Figure 1 Overwatch 主界面截图

数据采集

为了能够发现 RPC 调用失败的所有情况(包括业务问题、系统问题、网络问题),我们讨论如下两种监控方案:

1、从服务提供方监控

对服务提供方应用容器的访问日志(如 Tomcat 的 access.log)进行监控,将所有应用的这些日志文件通过公司现有的日志收集 - 分析系统进行统一收集分析。这样的方案可以快速实施且无需修改现有代码,开发量也较少。

Figure 2 日志收集 - 分析架构图

然而这样做的问题也很明显:

  • 无法监控到网络问题,因为请求会由于网络原因没有到达服务提供方(Connect Timeout)。
  • 请求响应超时(Read Timeout),这样的请求不会展现在访问日志中(一些版本的 Tomcat 存在该问题,包括我们正在使用的版本)。
  • 无法监控到异常的响应请求,即虽然返回了 HTTP 200 状态码,但是实际上是请求失败(如返回 JSON 字符串{“status”: “failed”})。

我们不能从服务提供方进行“主观”的监控。服务是给服务消费方使用的,服务提供方所认为的“正确”是不够“客观”的,只有服务消费方认为请求成功,才是“客观”的请求成功。

2、从服务消费方监控

从服务消费方可以实现上述“客观”的监控。

Figure 3 从服务消费方监控

但是我们需要自己实现信息的收集和聚合,同时我们需要一个在服务进程中的 Agent 去收集 RPC 信息。我们采用了 Kafka 进行数据的收集,Storm 进行数据的聚合,最后将数据交给 Overwatch 服务进程进行存储和展现。这样我们可以做到一个延迟在秒级的实时监控系统。

数据展现

至此,我们还需要解决一个问题:如何能够在多个系统同时异常时,快速定位到异常的根源。传统的监控多以柱状图、折线图的形式展现信息。

Figure 4 传统监控图表

这样的信息展现显然不能满足我们的需求,Overwatch 在信息的展现方式上需要作出改变,我们采用了有向图的方式展现监控数据。有向图展现 RPC 监控数据有如下优点:

  • 可以在一张图表中完整展现所有系统的状态。
  • 由于 RPC 是有向的(从消费方向提供方),使用有向图可以完美表达出该信息。
  • 图可以表达系统之间的依赖关系,当多个系统同时异常时,可以通过观察图中的依赖关系来找到异常的根源。

Figure 5 有向图概念示意图

使用有向图也存在一些问题:传统图表可以展现“监控统计值 - 时间”这样的二维关系,而在有向图中展现这些数据并没有那么简单,我们在之后的章节讨论中会讨论展现的方法。

在 Overwatch 中,我们会展现系统最近一分钟、最近 5 分钟平均、最近 15 分钟平均的统计值(类似于 Linux 中的 uptime 所展示的信息)。要展现这些数据,Overwatch 必须取最近 15 分钟的所有监控数据,并进行相应的聚合计算,这是开销特别大的操作,显然不可能对于每次用户的查看监控请求都进行一次这样的操作。对于这部分的实现,我们采用了 CQRS 的模式。

CQRS(Command Query Responsibility Segregation)是指对于数据的修改、更新操作(Command)和读取(Query)操作分别使用不同的 Model。这对于普通的 CRUD 业务需求来说只会增加系统复杂度,但是在 Overwatch 这样复杂查询、简单写入的场景下,是一种非常合适的模式。

由于 Overwatch 的服务端由 Node.js 实现,所以可以完美实现一个事件驱动的、从服务器到浏览器的 CQRS 架构。架构设计如下:

Figure 6 CQRS 模式架构图

显示器的第三个维度

上文提到了有向图的问题,即难以展现一个时间轴。显示器都是二维的,传统的柱状图用一维表示统计值,另一维表示时间,二者形成的坐标点和二维显示器上的点对应。而有向图需要展现一个“方向”,节点需要在一个平面内展现,所以显示器上的两个维度已经被用完了。为了展示时间维度的信息,我们采用了显示器的第三个维度——颜色。

我们使用三个同心圆表示一个节点,每个圆的颜色根据该系统所有 RPC 调用的成功率从蓝(100%)到黄(<99.9%)到红(<99%)。最内侧的圆表示最近一分钟的成功率;中间的圆表示最近 5 分钟的成功率;最外侧的圆表示最近 15 分钟的成功率。通过这三个同心圆,我们就可以直观了解到该系统当前的状态以及最近 15 分钟的变化。

Figure 7 数据节点三色环示意图

除此之外我们使用节点的大小表示节点最近一分钟的访问量,用边的颜色表示两个系统之间的 RPC 调用的成功率。

当多个系统同时异常时,通过系统间的依赖关系,我们可以迅速找到异常的根源,也可以评估异常的影响范围。

在大促期间,一旦 APP 接口开始报警,我们仅需打开 Overwatch 监控页面,查看有向图中的异常信息。

Figure 8 异常定位

根据上图的异常信息(非真实数据),我们可以立刻得知是订单系统在调用用户系统时出现了异常,且异常为 ReadTimeout,那么用户系统就是问题的根源。接下去,我们就可以通过应用日志分析、系统硬件监控等工具对这个系统的异常进行分析以及排查。

优势:直接

与传统的调用链监控系统,即 Google Dapper 的各种实现系统如淘宝的 EagleEye、Twitter 的 Zipkin,或者 APM(Application Performance Management,应用性能管理)工具如 Pinpoint 相比,Overwatch 的设计思想更加“直接”。

使用调用链监控系统来进行问题排查,工程师首先需要定位到一个异常的请求,然后需要在一条调用链中查找异常,这是非常耗时且繁琐的工作。

Figure 9 传统调用链监控系统

传统的调用链监控系统是从“请求”的维度进行监控数据的收集和展现,将一个“请求”的完整链路展现出来。这样的监控系统更适合用来作为细致的性能分析和优化工具,并不适合作为一个快速定位异常的工具使用。

而 Overwatch 是从系统的维度进行监控数据的收集和展现,并不关心一个请求的完整链路。Overwatch 可以在一张监控图中完成系统异常的发现和定位,通过有向图的展示,工程师不需要做任何数据分析,仅凭“感觉”便可确定异常位置。

系统展示

Figure 10 节点信息,包括 5 分钟、10 分钟、15 分钟统计

Figure 11 单系统信息快速展示,包括最近一小时统计图表以及错误日志

Figure 12 单系统历史信息查询

Figure 13 有向图布局设置

未来展望

Overwatch 是一个相对年轻的系统,是一次对大型微服务系统可视化监控现的尝试。同时,我们也在不断优化、加强 Overwatch 的功能。Overwatch 有着极大的扩展潜力,我们正在努力实现以下功能:

  • 对于数据源、中间件的监控(如 MySQL、Redis、消息队列),在有向图中加入基础组件,全面监控所有系统间的依赖以及调用情况。
  • 支持更多 RPC 协议 (如 Thrift、gRPC)。
  • 更多的 metric,实现精确到 API 的监控和展现。
  • 使用智能算法自动发现异常(如系统访问量突变)。
  • 更多的展现方式(如形状、动画)。

我们也对 Overwatch 进行了开源, 目前仅对监控数据的展现部分进行了开源,数据收集以及分析部分由于依赖多种内部基础设施,暂时没有开源。接下去的开源计划:

  • 各语言的监控数据收集 Agent(Java、Python 等)
  • 各协议、中间件的监控 Agent
  • 监控数据收集 Agent 的无感知接入
  • 监控数据的多样化存储(支持 OpenTSDB 等)

欢迎各位感兴趣的同学加入 Overwatch 的开源工作。

地址:

https://github.com/imdada/overwatch

作者介绍

张玄,达达 - 京东到家基础架构研发工程师,毕业于南京大学,高中参与上海计算机竞赛,荣获第一名。毕业后就职于达达 - 京东到家基础架构团队,从事基础组件、系统监控等开发工作。

感谢雨多田光对本文的审校。

2018-01-10 17:016411

评论

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

中国消费级AR行业分析2023

易观分析

AR 消费级 眼镜

IDO代币合约质押流动性挖矿分红系统开发(开发逻辑及源码)

系统开发咨询1357O98O718

​在行 | AI赋能,为行业发展创造全新可能

用友BIP

贼全!一举通关的Spring+SpringBoot+SpringCloud全攻略,是真香啊

程序知音

Java spring 编程语言 springboot SpringCloud

如何建设私有云原生 Serverless 平台

北京好雨科技有限公司

Serverless 云原生 #Kubernetes#

加速数据要素价值释放,用友打造高性能时序数据库

用友BIP

数据分析

一文吃透什么是低代码开发?

这我可不懂

低代码 低代码平台 JNPF

接近8000字的Spring/Spring常用注解总结!安排!

Java你猿哥

spring Spring Boot ssm java

云运维过程注意事项简单讲解-行云管家

行云管家

云计算 企业上云 云管理 云运维

云算力挖矿开发正式版丨云算力挖矿系统开发(APP开发案例)

系统开发咨询1357O98O718

自动化软件开发工具有什么用?该如何选择?

SoFlu软件机器人

腾讯前端一面常考面试题

loveX001

JavaScript 前端

80%的前端开发都答不上来的js异步面试题

loveX001

JavaScript 前端

国内大型战略咨询企业都是怎么解决数字化转型难题的?

优秀

数字化转型

经典神作!SpringBoot系列从入门到进阶,彻底搞懂SpringBoot

小小怪下士

Java spring 程序员 后端 springboot

JS模块化—CJS&AMD&CMD&ES6-前端面试知识点查漏补缺

loveX001

JavaScript 前端

上海堡垒机采购注意事项以及堡垒机厂商推荐

行云管家

信息安全 堡垒机 上海

观测云产品更新|数据存储策略变更优化;新增支持创建重名的仪表板、笔记、自定义查看器;DQL 参数生效优先级调整等

观测云

数据存储 可观测 产品更新 观测云 可观测性用观测云

flutter系列之:创建一个内嵌的navigation

程序那些事

flutter 架构 大前端 程序那些事

2023我的前端面试小结

loveX001

JavaScript 前端

美团面试全流程详解:一面 + 二面

Java你猿哥

ssm Java 面试 面经 java

waf全称是什么?是干什么的?

行云管家

防火墙 waf

云算力质押挖矿开发详细丨云算力质押挖矿系统开发(案例及功能))

系统开发咨询1357O98O718

企业软件开发成本高,该如何解决?

SoFlu软件机器人

【新版】使用 go-cqhttp 扫码登录,一键接入 ChatGPT 机器人到 QQ 群 | 社区征文

极客飞兔

人工智能 聊天机器人 科技革命 openai ChatGPT

卓越工作的4个特征

凌晞

项目管理 技术管理 构架

OCR文字识别工具:OCRKit Pro 中文激活版

真大的脸盆

Mac 文字识别 OCR Mac 软件

NFT数字藏品系统开发(开发及流程)丨数字藏品NFT系统开发(源码及功能)

系统开发咨询1357O98O718

昇腾 AI 机器人发布,12 家企业、5 家高校签约,昇腾 AI 开发者创享日全国巡展沈阳首站成功举办

科技热闻

6大奖项揭晓!40+优秀白帽齐聚百度安全BSRC年度盛典

百度安全

漏洞 SRC

代币质押流动性挖矿分红开发案例丨代币质押流动性质押挖矿分红系统开发(案例及详细)

系统开发咨询1357O98O718

新思路设计可视化大型微服务监控系统_架构_张玄_InfoQ精选文章