首页 > 学院 > 开发设计 > 正文

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

2019-11-15 00:53:20
字体:
来源:转载
供稿:网友
从宏观到微观——天机与鹰眼联手郑昀 创建于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 数组,如下图所示:keys也可以展示图8 keys也可以展示最终,我们找到了 sortGoods 这次调用花了1秒多的原因:有一个 update 操作花了 540 毫秒图9 有一个 update 接口操作花了 540 毫秒那么接下来分析这个方法的代码即可。如上所示,经过刘奎等同学的努力,天机与鹰眼联手,在没有部门经理、研发经理、工程师的帮助下,我自己就能通过天机系统从宏观看到微观,并最终明确某个性能瓶颈的 Root Cause(当然还不够接触本质)。这还不够。还有其他的调用路径分析和调用去向分析场景。以后再讲。-EOF-辅助阅读:#研发解决方案介绍#Tracing(鹰眼)#研发解决方案介绍#基于StatsD+Graphite的智能监控解决方案延伸阅读:窝窝研发哲学
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表