写点什么

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

  • 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:017074

评论

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

基于消息队列 RocketMQ 的大型分布式应用上云最佳实践

阿里巴巴云原生

阿里云 RocketMQ 云原生 消息队列 上云

Apache RocketMQ 荣获 2021 中国开源云联盟优秀开源项目

阿里巴巴云原生

Apache 开源 RocketMQ 资讯

CSS架构之Theme层

Augus

CSS 11月日更

论层次架构风格

lazytortoise

系统架构面临的三大挑战,看 Kubernetes 监控如何解决?

阿里巴巴云原生

阿里云 Kubernetes 云原生 系统架构

Redis 日志篇:AOF 与 RDB 让数据持久化不丢失

码哥字节

redis 后端 Redis 核心技术与实战 11月日更

架构实战营 王者荣耀商城异地多活架构设计

💤 ZZzz💤

架构实战营

新书 | 这绝对是读起来最有趣的计算机科普绘本

图灵教育

少儿编程 绘本 逻辑启蒙

☕【Java技术指南】「序列化系列」深入挖掘FST快速序列化压缩内存的利器的特性和原理

码界西柚

11月日更 FST 快速序列化

推荐学Java——初识数据库

逆锋起笔

Java MySQL 数据库 Java后端

何时适合进行自动化测试?(下)

禅道项目管理

自动化测试

NEJ Build太慢怎么办?试试MOOC NEJ吧,只需两步,提升70%构建性能!

有道技术团队

算法

JAVA Annotation详解

平凡人生

`MD`语法技巧Typora

sec01张云龙

11月日更 MD MD写法

实验室lims系统解决方案

低代码小观

实验室管理系统 企业管理 LIMS实验室信息管理系统 LIMS系统 信息管理系统

快手微服务架构技术交流会

快手中学

微服务 云原生 稳定性

尝鲜Windows 11一个月,被这3项巨变圈粉了....

Jackpop

架构训练营毕业总结

Clarke

架构实战营

web技术分享| WebRTC 实现屏幕共享

anyRTC开发者

大前端 Web 音视频 WebRTC 屏幕共享

苏丹2021年10月25政变断网事件

郑州埃文科技

工厂模式——猫粮公司的演进

蝉沐风

Java 设计模式 工厂模式 工厂方法模式

【LeetCode】有效的完全平方数Java题解

Albert

算法 LeetCode 11月日更

【设计模式】第十篇 - 外观模式 - 我来组成头部

Brave

设计模式 外观模式 11月日更

把选择题变成问答题

FunTester

Java Python 测试 FunTester

一部亚马逊4.5高分的领域经典,首次落地中国

博文视点Broadview

Python代码阅读(第52篇):返回列表的头部和尾部

Felix

Python List Code 列表 阅读代码

Apache APISIX 在腾讯云智能钛平台中的落地实践

API7.ai 技术团队

腾讯云 网关 API网关 Apache APISIX

iOS开发:用XIB拖控件关联时报错:“Could not insert new outlet connection…”解决方法

三掌柜

11月日更

【Flutter 专题】19 图解【分享页面】底部对话框

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 11月日更

时代赋机遇,双十一电商盛会神助攻——中科柏诚

联营汇聚

没有性能瓶颈的无限级菜单树应该这样设计

Tom弹架构

Java 架构 设计模式

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