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

背景

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

达达 - 京东到家的 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 等）

来自：http://infoq.com/cn/articles/visualization-microservice-monitoring-system

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。