作者：程璞、易波。
从 Google 发布的第一篇文章《Dapper， A Large-Scale Distributed Systems Tracing Infrastructure》开始，在指标、追踪、日志三个方向上相辅相成的可观测性解决方案，逐渐被业界接受，成为事实上的标准。
基于上述全栈可观测性解决方案技术，诊断问题从不知道从哪里开始，或者只依靠日志，变成了以下步骤：
1.通过Metrics Logs提供的各种预置告警，发现异常信息，利用异常信息判断异常模块。
2.查询分析异常模块及关联日志，查找核心错误信息。
3.通过详细跟踪找到导致问题的 ** 片段。
基于上述一套可观察的解决方案，不仅可以在问题发生后及时快速定位和缓解，而且在许多情况下，甚至可以在重大故障发生之前提前发现、解决和修复问题。
基于上述一组可观察的解决方案，是否有可能一劳永逸地解决任何在线监控问题？其实不是，尤其是在追踪方面，因为它一般都是基于J**A代理SDK技术方案，对HTTP服务、RPC服务、数据库、分布式消息MQ等主流软件开发框架进行掩埋调用链监控数据的采集，然后通过后续的调用链数据恢复处理逻辑，将监控信息与具体请求关联， 这样，当请求异常时，可以通过采集到的监控数据查看相关的呼叫信息。除了提供请求通过的核心链路方式外，调用链的另一个核心功能是帮助排查调用链中耗时慢的位置，并帮助优化。 故障排除过程可用于使用跟踪的详细信息来诊断跟踪中耗时的瓶颈逻辑，如下图所示
如上图所示，一个调用链就是一个 trace，并且有一个唯一的 traceId，它包含多个 span，它们表示多个被调用的下游服务，每个服务都有对应的 spanid 信息。 从上图中可以知道请求经过的多个服务所经历的耗时情况（假设下游服务对应一个跨度，部分链路追踪系统可能不同），从而定位应用耗时瓶颈，优化相应的性能。
然而，在分布式微服务领域，由于调用链路的复杂性，涉及跨机甚至跨机房，因为一般的链路追踪系统只能将核心方法埋在主流的开源软件框架中，当耗时的位置出现在用户业务逻辑中缺少追踪埋点时， 最终的调用链中会有很长的时间，无法对应具体的执行方式，导致无法准确判断业务逻辑的耗时情况。
具体案例如下**
public string demo() throws sqlexception private void take1000ms(long time) catch (interruptedexception e) }追踪调用链中对应的最终显示形式可能如下图所示，通过追踪调用链，只能知道第一层的外部接口时间以及其中包含的知名软件框架的执行逻辑，其中灰色阴影部分是未被追踪系统埋点覆盖的用户业务逻辑**部分， 作为监控盲区，其实际耗时未知，给在线性能排查造成诸多障碍
以上问题在企业用户中非常普遍，很多时候只能感叹无奈！
针对上述追踪系统漏跟踪点情况下慢调用链的诊断问题，据笔者了解，目前业界相关解决方案较少，熟悉Arthas的同学可能会提到其中的追踪命令确实，在一定程度上，它可以在一些可以稳定复现的简单场景中，手动检查相关慢调用链的具体耗时位置。 但它的局限性也比较明显：
作用范围有限稳定场景恢复仅支持慢调用诊断，在触发垃圾**、资源争用、网络问题等难以恢复的场景下，很难排查慢调用问题。 使用门槛高在实际生产场景中，调用链可能非常复杂，如果不熟悉业务方法的执行或者一些复杂的异步调用场景，就需要在特定的业务方法上手动执行trace命令来监控请求时间消耗。 故障排除成本很高该工具确实可以用于排查单跳简单业务场景下调用慢的问题，但在跨应用多跳复杂业务场景中，排查过程变得繁琐。 不仅需要使用一些APM工具来定位特定慢调用所在的应用实例，而且在业务调用方法栈很深的场景下，需要逐层执行相关命令，并逐步监控，找到问题的根源。 综上所述，arthas的trace命令可以在一些简单的慢调用场景中使用，但在复杂场景下还不足以排除慢调用链的故障
为此，阿里云ARMS团队和阿里巴巴龙井团队可以通过连续分析技术，帮助用户更好地恢复调用链方法栈信息，从而更好地解决这类链路追踪监控盲点问题。
ARMS持续性能分析能力
作为国内知名的APM工具，ARMS不仅为链路追踪、指标和日志相关业务提供主流的可观测性解决方案，还提供开箱即用的持续分析（CP）解决方案。 持续分析是动态实时收集有关资源请求（如 CPU 内存）的堆栈信息，以帮助监控和定位应用程序性能瓶颈。 ARMS目前提供的持续性能分析能力架构如下图所示：
在设备端，J**a Agent 技术以非侵入式方式提供连续分析数据收集功能以及其他可观测性功能。 然后，在服务器端对采集到的数据进行分析和处理，最后控制台为用户提供开箱即用的功能，包括：CPU诊断、内存诊断和热点功能。
CPU 和内存诊断
火焰图对于很多困扰过应用性能问题的读者来说当然并不陌生，可以通过观察火焰图中是否有宽顶来定位应用的性能问题。 对于很多研发人员来说，上面提到的火焰图一般是指CPU热点火焰图。 它表示方法在一段时间内在应用中执行 CPU 所需的时间。 ARMS 提供的 CPU 和内存诊断功能继续在开源中剖析异步分析器在低开销的条件下受支持规范化收集CPU & 内存应用栈信息可用于简单高效地监控生产场景中的 CPU & 内存应用，杜绝了使用开源工具难以定期打开、容易遗漏和重现问题场景的情况。
热点
说完CPU&内存诊断，可能会有读者问，CPU诊断对应的方法栈火焰图能不能帮助解决跟踪系统监控中的盲区问题，帮助排查慢调用链？答案是否定的！这是因为 CPU 诊断是一个方法堆栈，它定期抓取在 CPU 上执行的执行线程，然后将其转换为火焰图。
除了在 CPU 上执行的运行状态（也称为 on-cpu）外，还有其他状态，例如阻塞和等待（统称为 off-cpu），并且由于多个线程状态的叠加，慢调用链通常呈现时间较长。 因此，CPU 火焰图在慢速调用链场景中的用途有限。
有没有一种火焰图技术不仅可以用于描述CPU上的内容，还可以用于描述CPU外的内容？然后我们不得不提到挂钟。 实现原理并不复杂，即在应用的所有线程中以固定频率选择一组线程，采集当前时刻的方法栈信息，通过聚合处理绘制出对应的火焰图。 异步探查器等功能也提供了相关功能。
本文的主题基于开源异步探查器挂钟功能通过关联调用链中的 traceId 和 spanid 信息，提供调用链级别的 On & Off-CPU 火焰图可以有效还原链路追踪盲区的细节，帮助用户诊断各种常见的慢调用链问题。 具体过程如下图所示，通过**程序创建span开始时间和结束时间来关联或取消traceid&spanid信息，使最终生成的挂钟方法栈快照样本包含相关信息，然后通过最终的连续分析数据处理，还原挂钟火焰图中对应的调用链，帮助定位调用链慢的问题
核心功能：
与其他慢调用链诊断工具或开源持续分析工具相比，ARMS提供的持续分析能力具有以下特点：
低开销通过基于Trace过程的自动采样和挂钟性能分析的关联采样率等措施，ARMS提供的连续性能分析产品能力的CPU开销为5%，堆外内存开销约为50M。 粒径细除了应用级的CPU和内存热点外，它还通过关联traceid和spanid信息，为调用链级别提供方法栈信息，可以有效地帮助诊断慢调用链问题。 安全可靠，简单高效一些开源的持续分析技术，例如使用Arthas生成CPU火焰图（底层也依赖于Async Profiler），即使存在技术风险也不容易找到。 在产品研发过程中，我们还是发现了很多开源技术，比如异步分析器，不断分析流程使用的风险。 例如，内存分析可能会导致应用程序崩溃，挂钟火焰图会导致线程长时间堵塞等。 通过解决这些问题，我们的产品功能更加安全可靠。 除了安全性之外，ARMS提供的持续分析能力在数据定时开启后会自动存储7天，让用户不会错过每一个慢呼叫链的诊断站点。 打开热点
1.登录ARMS控制台，在左侧导航栏选择应用监控>应用列表。
2.在应用清单在页面顶部，选择地域，单击应用名称。
3.在左侧导航栏，单击应用设置，然后单击自定义配置标签。
4.开CPU 和内存热点主开关后，开机热点切换并配置待开启应用实例的IP地址或实例组的网段。
5.点击页面底部救
您可以调用API查看热点数据
1.登录ARMS控制台，在左侧导航栏选择应用监控>应用列表。
2.在应用清单在页面顶部，选择地域，单击应用名称。
3.在左侧导航栏，单击API 调用，选择页面右侧的目标界面，然后单击跟踪查询标签。
4.在跟踪查询选项卡上，单击 traceid 链接。
5.在详点击栏中的放大镜图标，首先可以点击方法栈选项卡，看一下追踪工具展示的方法栈信息，可以看到它只包含了 MariaDB 相关的执行逻辑，没有记录前面的业务时间。
6.接下来，单击热点选项卡，在右侧的火焰图中可以看到，除了 MariaDB 相关的方法栈（对应下图右侧火焰图中右侧最尖锐的火焰）之外，还包括 j**a.lang.thread.sleep（） 相关的 990ms（由于连续分析以获得基于采样的线程堆栈，可能会有轻微的偏差）。
图左边是调用中涉及的所有方法所花费的时间列表，右边是对应方法的所有方法栈的火焰图。 self 列显示方法本身所需的时间。 作为具体的热点逻辑，可以通过聚焦自列或者直接看右边火焰图底部较宽的火焰来定位耗时的业务方式，这是上层耗时高的根本原因，一般是系统性能的瓶颈，如上图中的j**a.lang.thread.sleep（） 方法。 有关更多详细信息，请参阅此功能的用户文档
相关链接：
1] trace 命令。
2] async profiler
#694/issues/694
#769/issues/769
5] 用户文档。