业务实时监控服务ARMS 全息排查功能全新上线

摘要：作为鹰眼的商业化产品，用于全链路APM监控的阿里云业务实时监控服务 (ARMS) ，基于鹰眼的全息排查沉淀，近日推出了基于分布式调用链监控技术的全息排查功能，将该功能提供给广大用户。

作为鹰眼的商业化产品，用于全链路APM监控的阿里云业务实时监控服务 (ARMS) ，基于鹰眼的全息排查沉淀，近日推出了基于分布式调用链监控技术的全息排查功能，将该功能提供给广大用户。至此，ARMS链路的分布式链路追踪功能结合周边的本地堆栈排查，性能Metrics统计，业务全息排查三大附加功能，形成了完整的链路监控解决方案。

为方便用户了解ARMS 基于分布式链路追踪技术的全息排查功能解决的问题和主要的使用场景，下文在这方面简单展开做一下介绍。

分布式链路追踪概要介绍和其面临的主要问题
分布式调用链是微服务时代下的监控必备利器。该技术理论基础建立在Google Dapper论文基础之上，主要运用于分布式微服务场景下的链路诊断场景，用户可快速的定位分布式环境下的调用问题诊断。国内外常见的这方面技术的互联网产品已有很多，其中：

在开源领域有Zipkin, Skywalking, Pinpoint,
国内外互联网公司比较著名的是阿里的淘宝鹰眼(国内大厂最早的分布式调用链监控的实现)和阿里云ARMS (鹰眼商用版)，Facebook的OpenZipkin，还有其他如京东，网易等一些对应的实现。
分布式调用链在分布式调用的链路入口和出口通常会记录调用时差，返回状态，以及对应的机器或应用的元信息状态，因此应用的常规场景通常是某段时间和某个应用入口的情况下，查询错误异常或者超时的调用链。如Zipkin调用链查询如下图所示。

但是针对包含业务语义的特定故障诊断却稍显乏力。试脑补以下场景，如下图。

以上场景如果不将分布式调用链和业务内容进行关联，通常是很难定位到具体的问题调用链的。显然，常规的分布式调用链监控技术是无法胜任以上情况。

带全息排查功能的分布式调用链查询
作为国内互联网大厂的老牌链路监控工具，鹰眼于2014年左右就推出了全息排查功能，可以在调用链中关联业务信息(BizID)进行链路查询。鹰眼全息排查的关键在于：业务事件id与分布式调用链元信息TraceId的双向绑定，从而在技术上解决了业务信息(BizID)和调用链信息(TraceID)的关联问题。

业务全息排查的场景有很多，这里试举一例。例如一个交易订单（2135897412389123）发现存在问题，我们可以根据订单号查到与之绑定的TraceId，根据TraceId不仅可以查看系统调用的事件，还可以看到与业务相关的事件，如用户下单、当前库存情况等，也就是说根据交易ID可以在调用链上查看交易、商品库存以及支付等信息，大大提升错误排查速度。相关排查如下图所示。

用于全链路APM监控的阿里云业务实时监控服务 (ARMS) ，推出的基于分布式调用链监控技术的全息排查功能，则是基于鹰眼的全息排查沉淀，解决的问题和上文一致。下面我们看看ARMS全息排查的使用细节。

三步走使用ARMS带全息排查功能的分布式调用链查询
和鹰眼类似，ARMS全息排查解决问题的核心思路是将用户的业务内容 (简称BizID) 和相关调用链的TraceID做关联，来支持通过业务属性来查询对应的问题调用链。以下简单介绍如何上手ARMS全息排查功能。其操作的基本场景架构如下图。

以下简单叙述每步含义。关于全息排查的更多使用详解可参见全息排查最佳实践。

第一步，开发者在程序中通过ARMS提供的获取Trace信息的SDK来打印包含Trace信息的业务日志。
SDK使用示例如下：
Span span = Tracer.builder().getSpan();
String traceId = span.getTraceId();
String rpcId = span.getRpcId();

打印的日志参考内容如下：
2018-07-12 >11:37:40|1e057c4015313666599651005d1201|0|username=xiao,age=22,action=login
2018-07-12 >11:37:40|1e057c4015313666599651005d1201|0|username=xiao,age=22,action=search
2018-07-12 >11:37:40|1e057c4015313666599651005d1201|0|username=xiao,age=22,action=cart

第二步，运维人员在ARMS控制台上配置抓取、清洗业务日志的任务，将其关联到对应的链路追踪系统。配置的参考示例如下：

第三步，在ARMS上开启应用监控，开始全息排查。
ARMS的全息排查入口和以往的应用调用链即系查询入口保持一致。但是对比以往用户除了根据应用名，调用入口，响应时长进行查询意外，还可以根据业务信息(BizID)进行问题调用链的查询，从而指数级的提高了问题诊断查询效率。如查询username为kevin.yang的链路信息，查询示例如下：