本文旨在帮助读者了解什么是全链路追踪以及如何使用工具来分析链路中性能瓶颈。

?火焰图是什么？

火焰图（Flame Graph）是由Linux性能优化大师Brendan Gregg发明的用于分析性能瓶颈的可视化图表，它以一个全局的视野来看待时间分布，从顶部往底部列出所有可能导致性能瓶颈Span。

下面以观测云的火焰图为例，陈述其绘制逻辑：

纵轴（Y轴）代表调用Span的层级深度，用于表示程序执行片段之间的调用关系。上面的Span是下面Span的父Span。（数据上，可以通过子 Span 的parent_id等于父Span的span_id关联起来）

横轴（X轴）代表单个Trace下Span的持续时间。一个格子的宽度越大，说明该 Span 从开始到结束的持续时间越长。只要有“平顶”，则表示该函数可能存在性能问题，就可能是造成性能瓶颈的原因。

??为什么要用火焰图？

通常，我们可以通过查询日志、使用Shell等协助定位问题异常原因；再细致一点，会用到Jmap、Jstack分析堆栈跟踪等。但若需要分析至堆栈、调用链的阶段，说明很可能已经是Performance的问题了。但上述方法，或将产生海量文本无法直观分析，或缺乏汇聚型数据难以综合评判，降低了我们排查问题的效率。

因此，为了降低人工二次分析难度、提高性能数据的易懂性，火焰图便被广泛用于分析性能瓶颈问题。它纳入了线程栈的调用链和出现频率两个维度，从而可以非常方便地看到顶层的哪个函数占据的宽度最大，即性能资源都消耗在了哪里；进而，能够直观地定位程序的性能瓶颈，以进行相应地优化。

观测云的火焰图除了展示函数调用的基本性能信息之外，还在同一个可视化图表中关联了多维度数据，便于用户综合评判性能瓶颈的原因所在；同时，充满细节与温度的人性化交互设计，提升了使用体验及工作效率。

???如何巧用观测云火焰图分析链路性能？

3.1火焰图

火焰图左侧图示区：

同一种颜色的Span对应同一个服务：可直观感知当前Trace所涉及到哪些服务请求。（小提示：服务的颜色会继承到链路查看器等其他分析页面）

每一个Span块默认显示：当前Span的资源或操作、持续时间、以及是否存在错误；悬浮还可展示其整体耗时占比。

对于多线程或者异步任务：同层级或下属子Span执行时间可能会出现重叠，图中通过连线的形式来关联父子Span之间的关系。

右侧服务列表：

显示当前Trace内发生请求调用，所涉及到的服务名称和颜色、该服务执行时间占总执行时间的百分比。（注意：服务名称显示为None的情况，则表示当前trace未找到parent_id = 0的顶层Span）

3.2 Span列表

上图全收起状态，以服务视角：

显示服务类型、名称和颜色，以及当前服务下是否存在status = error的Span；还依次显示当前服务下面的Span数量、持续时间的平均值、执行时间总和，以及当前服务的执行时间占总执行时间的百分比。

下图服务行展开状态，以Span视角：

显示资源名称、对应服务颜色及当前span是否存在status = error；还依次显示当前Span持续时间、执行时间数值及占总执行时间的百分比。

3.3服务调用关系

观测云还可以显示当前Trace下服务之间的调用关系拓扑：

支持按资源名称模糊匹配，定位某个资源的上下游服务调用关系。

服务hover后，显示当前服务下的Span数量、服务执行时间及占比。

????如何开启观测云通过火焰图分析链路性能？

4.1注册与安装

建议通过电脑端，进入【 观测云 】（https://console.guance.com）平台进行实操，并参考观测云学堂【 巧用“火焰图”快速分析链路性能 】（https://www.guance.com/learning/articles/flame_graph01）的操作指引。

4.2实际链路数据分析举例

第一步：登录观测云工作空间，查看应用性能监测模块的服务列表，从服务页面已经可以看出browser服务的P90响应时间较长。

第二步：点击browser服务名称，查看该服务的概览分析视图，可以看出影响当前服务响应时间的最关键的资源是query_data这个接口，因为这个接口是观测云的一个数据查询接口，所以接下来我们看下这个接口在查询过程当中，到底是因为什么导致耗时较长。

第三步：点击资源名称，跳转到查看器，通过点击持续时间倒序查看响应时间的最大值。

第四步：点击Span数据，查看分析当前Span在整个链路里面的执行性能和其他相关信息。

第五步：点击右上角[全屏]模式按钮，放大查看火焰图相关信息。

结合整体链路查看，可以看出browser服务在整个链路中的执行时间占比高达96.26%，从Span列表也可以得出此结论。

根据火焰图的占比和对应的链路详情信息，我们可以总和得出browser的这个query_data Span在整个执行过程中可以看到resource_ttfb（资源加载请求响应时间）耗时400多毫秒，resource_first_byte（资源加载首包时间）耗时1.46秒。

再结合查看province的地理位置定位是Singapore（新加坡），而我们的站点部署在杭州节点，则可以得出是因为地理位置问题导致数据传输的时间变长从而影响了整个的耗时。

相关阅读：

【 The Flame Graph –Brendan Gregg 】（https://queue.acm.org/detail.cfm?id=2927301）

【 如何读懂火焰图？–阮一峰的网络日志 】（https://www.ruanyifeng.com/blog/2017/09/flame-graph.html）

【 关于 Traces 、Span 等链路相关概念的介绍 –OpenTracing 】（https://wu-sheng.gitbooks.io/opentracing-io/content/pages/spec.html）

【 巧用“火焰图”快速分析链路性能 】（https://www.guance.com/learning/articles/flame_graph01）