从宏观到微观——天机与鹰眼联手

郑昀 创建于2015/6/23 最后更新于2015/6/25

关键词：Google Dapper、窝窝Tracing、鹰眼、天机、性能、调用链分析、散点图、瀑布图

---

本文档适用人员：技术人员

提纲：

1. Google Dapper是怎么做的
2. 天机里如何从宏观看到微观

---

0x00，Google Dapper的交互方式

    Google 的 Dapper 是淘宝鹰眼、点评CAT、京东Hydra、eBay CAL、Twitter Zipkin、窝窝Tracing的鼻祖。很多年前，Google 说，大部分用户都是通过这么个控制台来使用 Dapper 的，典型流程如下图所示：

图1 dapper

 

1. 用户输入他感兴趣的服务和时间窗口，选择相应跟踪模式(这里是 span 名称)，以及他最关心的某个度量参数(这里是服务延迟)。
2. 页面上会展示一个指定服务的所有分布式执行过程的性能摘要，用户可能会对这些执行过程根据需要进行排序，然后选择其中一个看详情。
3. 一旦用户选定了某个执行过程后，将会有一个关于该执行过程的图形化描述展现出来，用户可以点击选择自己关心的那个过程。
4. 系统根据用户在1中选择的度量参数，以及3中选择的具体过程，显示一个直方图。在这里显示的是有关 getdocs 的延迟分布的直方图，用户可以点击右侧的 example，选择具体的一个执行过程进行查看。
5. 显示关于该执行过程的具体信息，上方是一个时间轴，下方用户可以进行展开或折叠，查看该执行过程各个组成部分的开销，其中绿色代表处理时间，蓝色代表花在网络上的时间（注：即我们说的调用链瀑布图）。

 

    这就是 Google 从宏观一路看到微观的操作模式。即，服务（对应于一个或一串集群）的度量指标是宏观，真实的调用链是微观，在图形界面上即可从宏观杀入微观。

 

0x01，天机系统里如何从宏观看到微观

    窝窝也致力于从某个工程的度量指标开始看起，选择自己关心的时段，最终一路点击后，找到可疑的调用链，看到它的瀑布图。下面逐个步骤讲解一下。

Step 1.找到感兴趣的工程

由于所有的 Java 工程都接入了 Dubbo，所以有了服务的注册与发现，也因此天机系统自然而然知道某个工程有多少个节点提供服务。

所以，我们可以在天机的服务调用监控里找到感兴趣的工程。

选择好时间段，我们可以看到这个工程的所有节点调用和被调用情况，如下图所示：

图2 商品中心的调用和被调用情况

 

Step 2.关注接口响应时长

工程接口的响应时长被我们细分为不同区间：

• 0～200毫秒
• 200～500毫秒
• 500～1秒
• 1～5秒
• 5～10秒

那么，我们优先关注响应时长在 1～5秒 之间的接口，如下图所示：

图3 工程接口被调用时的响应时长统计

 

Step 3.看 时间-次数 曲线

点击对应的"图表"链接，我们进入服务调用统计图表页面。我们随后选择"1-5s"Tab页，如下图所示，可以看到商品中心 183 节点在6月24日里，接口响应时间在 1秒～5秒 之间的情况：

图4 调用统计图表

看到这里，我们只是知道某个时间点，商品中心有点不正常，但还不知道是哪一个接口不正常。

 

Step 4.看 时间-次数 曲线

点击上图中的那个红点，从而进入 10点30～10点35 之间接口响应时间在 1秒～5秒 之间的分接口曲线图：

图5 分接口曲线图

 

这样，我们发现，原来全是 sortGoods 这个方法引发的。

但这还不够。我们还是不知道为什么慢。

 

Step 5.看散点图

点上图中的那个蓝点，进入 10点30 左右的真实调用散点图，图上的每一个点都代表一个真实的调用：

图6 散点图

从上图可以看出，sortGoods 接口方法其实大多数响应时间在 500毫秒以下，最大响应时间也不超过 1.5秒。我们选中响应时间最大的那个点，点击一下。

 

Step 6.看瀑布图

点响应时间最大的那个点，进入 10点30 左右、sortGoods 方法响应时间为 1.347 秒的真实调用链的瀑布图：

图7 瀑布图

 

瀑布图一般都很长。它可视化地绘制了每一层调用，包括进程内调用，包括跨进程调用，包括对缓存、对数据库的请求。

每一层调用，都可以看到具体参数，如 HostIP、RequestIP、输入参数、SQL语句（假如访问了DB的话）、对缓存是GET还是SET，如果有异常抛出，还能看到堆栈信息。

 

假如是对 memcached 批量获取，还可以看到具体的 keys 数组，如下图所示：

图8 keys也可以展示

 

最终，我们找到了 sortGoods 这次调用花了1秒多的原因：

图9 有一个 update 接口操作花了 540 毫秒

那么接下来分析这个方法的代码即可。

 

如上所示，经过刘奎等同学的努力，天机与鹰眼联手，在没有部门经理、研发经理、工程师的帮助下，我自己就能通过天机系统从宏观看到微观，并最终明确某个性能瓶颈的 Root Cause（当然还不够接触本质）。

 

这还不够。

还有其他的调用路径分析和调用去向分析场景。以后再讲。

 

-EOF-

 

辅助阅读：

#研发解决方案介绍#Tracing（鹰眼）

#研发解决方案介绍#基于StatsD+Graphite的智能监控解决方案

 

延伸阅读：

窝窝研发哲学