端到端调用链监测实施案例

IT那活儿 2022-05-25

1118

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

应用背景

随着越来越多的企业将业务系统上云，实现云化部署，将后端功能沉淀和分拆成多个能力服务中心，较好地规避了烟囱式建设方式，提升了能力复用，节省了项目和新业务需求开发成本。

但同时，相比传统架构：

一方面，大幅度增加分布式程度、调用层次、依赖复杂度，调用随机分发，大幅度的提升了性能问题发现和排查定位难度；

另一方面，由于生产系统在高可用中快速切换隔离了故障源，导致故障源并不容易被迅速发现及定位，特别是当前的系统环境中大量的应用、主机、网络、中间件、数据组件等交织如网，应用间网状的调用关系导致各物理节点的故障源对于应用及业务的真实影响较难评估。

图片来源于网络

如何快速发现问题、排查影响范围，快速定位问题成为新的技术挑战。

为了能直观的体现包含系统上下游依赖信息的系统模块关系图谱，并实现问题发生初期的快速故障源定位及影响分析，我们构建了端到端调用链监控平台，以实现多维协同运维，具体包括：

系统监控清晰透明：构建包含各应用模块上下游调用依赖关系（应用包括：业务应用、中间件、数据库等）、应用模块主机网络之间相互部署依赖关系的多维度关系图谱监控大屏，实现系统从黑盒状态到透明状态的转变。
故障定位快速智能：基于动态基线对关系图谱中各模块、节点进行异常检测，分析各系统模块的问题情况，实现故障分钟级实时发现。
运维分析立体多维：通过直观可视化的方式展示应用、主机、数据库等异常，方便运维人员多维度、立体式对故障影响面进行评估。

建设实施方案

建设端到端调用链监控平台，打通各业务支撑子系统，并依托分布式调用链跟踪技术打造跨电渠、CRM、BOSS多个核心子系统的分布式全程调用链路，构建立体式多维协同的故障智能检测和可视化快速定位能力，解决庞大的分布式系统架构下的调用链路难跟踪、发生故障或问题较难快速定位和跟踪的难题。

端到端调用链监控平台架构通过适配各应用系统的底层框架，实现端到端链路数据埋点、数据生成、数据采集，运维指标生成、异常检测及告警。并融合可视化能力、实时计算能力、动态基线算法能力，在业务系统出现问题时，快速通过调用链，结合可视化，快速呈现系统异常、定位排查。

端到端调用链监控平台架构图

端到端调用链监控平台的多维度可视化监控大屏基于采集获取到的应用模块之间的调用关系进行动态构建。包含上下游应用或中间件、数据组件等模块调用关系，也包括应用模块与主机网络之间相互部署依赖关系。

系统监测可视化大屏展示如下：

每个图标代表一个应用模块集群，每个应用模块直接的带箭头的连线代表调用关系，当图标变红色时代表该模块出现了异常，可以通过下钻进一步定位诊断。

系统可视化拓扑大屏

系统拓扑监控可以通过应用集群的纵向下钻能力，体现从应用集群到应用实例再到物理节点的纵深关系，快速对发生异常的应用集群做下钻分析，进入到应用集群的物理部署层，并将原子状态的故障发生点予以告警展现，提示运维人员跟进处理。

围绕上述“立体式多维协同的故障检测和可视化快速定位能力”建设思路，一方面采用分布式调用链跟踪技术；另一方面构建关系图谱模型、多维异常指标智能生成、融合基线检测算法，助力故障检测和可视化快速定位能力构建。

1. 分布式调用链跟踪

采用分布式调用链跟踪技术方案解决跨节点事务端到端跟踪难点，从用户侧开始的调用一直追溯到调用处理完毕回调结束，调用链中的每个环节都进行统计监控，实现分布式事务全生命周期调用性能管理，可视化分布式事务调用栈。

分布式事务跟踪技术通过在远程调用发送消息时添加应用级别的标签作为消息之间的关联。

例如，在HTTP请求中的HTTP header中为消息添加一个标签信息并使用这个标签跟踪消息。在调用的header中添加应用级别标签数据以便在远程调用中跟踪分布式事务的全链路。标签数据由多个key组成，定义为TraceId。在标签中加入主机、网络IP字段，就能将主机、网络IP信息进行收集上报。

消息跟踪数据结构由Span, Trace, 和 TraceId组成。

下图描述TraceId的行为，在4个节点之间执行了3次的RPC调用：

调用链跟踪示例

在上图中，TransactionId (TxId)作为一条调用链的唯一标识ID，全局唯一，体现了三次不同的RPC作为单个事务被相互关联。通过SpanId 和 ParentSpanId (pSpanId)来标识上下游环节关系。

使用TxId，可以发现关联到n个Span，并使用SpanId和ParentSpanId将这n个span排列为继承树结构，这样就实现了调用链路的串联。

在这个消息结构体中加入更多的记录信息：比如业务编码、主机ip、入参文本、调用请求返回文本、系统错误堆栈文本等，就能获得非常丰富的调用链信息，能更加方便运维。

2. 链路数据输出要求

为了能够分析出端到端的调用层次关系，我们对业务系统的链路日志数据输出做了以下的规范要求：

基于业务链做应用拓扑需求，和应用厂商侧协商确定的业务链数据格式需求规范，每个环节可以吐出其上游的调用发起信息，以及当前环节向下游调用发起的信息，每一笔业务链日志中应包含的数据信息，包括但不限于以下内容：

定义单次业务办理所对应的业务编码
每个业务都应有业务编码，用于识别该笔业务具体是做什么的。
定义单次业务办理的用户编码
定义办理业务的用户，如手机号码、用户编码、或其他业务的办理对象编码。
定义单次业务办理的办理员工编码
办理业务的员工编码，用于业务发展统计分析。
定义单次业务办理的办理渠道编码
办理业务的渠道编码，用于业务发展统计分析。
定义单次业务办理中单次系统交互的开始时间戳
业务办理的时间戳信息，用于单位时间内的业务统计分析，以及实时计算时时间窗口的判断。
定义串联单次业务办理的唯一流水
每笔业务需定义唯一流水，使用这个流水号来串联一次业务办理的多次交互动作。
定义串联单次业务办理中单次系统交互的唯一流水
每笔业务中一次交互动作的唯一流水，用于串联这次交互动作在多个不同应用之间的流转调用。
定义每个应用的应用节点编码
每个应用实例的唯一编码，用于识别该应用实例，当系统发生异常时，应用节点用于判断系统异常的发生位置。
定义每个应用的应用节点ip和port
每个应用实例的所属主机ip和当前应用实例的端口，用于关联主机异常信息做异常影响分析。
定义每个应用节点所属应用集群的应用类型
应用集群的类型可用于构建拓扑图时划分层级结构，绘制清晰的系统架构。
定义每个进程所属应用集群的名称
应用集群名称用于在构建拓扑图时展示当前应用的名称。
定义每次系统交互中每个环节的服务类型
系统交互中的一个环节可以是一次函数调用、可以是一次接口调用，还可以是一次数据库访问。该字段应定义一个环节的服务的类型。
定义每次系统交互中每个环节的名称
系统交互中的环节名称可以是接口名、函数名、服务名等，用于构建业务链时定义该动作。
定义每次系统交互中每个环节的输入参数
接口、函数、服务的入参信息。
定义每次系统交互中每个环节的输出
接口、函数、服务的返回信息。
定义每次系统交互中每个环节的耗时
接口、函数、服务、数据库访问的耗时。
定义每次系统交互中每个环节是否失败及失败类型
用于判断该环节是否失败，以及划分失败的类型，如系统层原因的失败，或业务规则的失败等。
定义每次系统交互中每个环节的失败异常信息
用于记录失败时的异常信息。
定义每次系统交互中每个环节的上级环节应用名称（跨应用调用时）
记录调用该环节代码的上级环节应用名称。
定义每次系统交互中每个环节的上级环节的应用节点编码（跨应用调用时）
记录调用该环节代码的上级环节应用节点编码。
定义每次系统交互中每个环节的上级环节的ip和port（跨应用调用时）
记录调用该环节代码的上级环节应用节点ip和port。
定义每次系统交互中每个环节向下调用的目标应用名称（跨应用调用时）
记录该环节向下游发起调用时的目标应用名称。
定义每次系统交互中每个环节向下调用的目标地址（跨应用调用时）
记录该环节向下游发起调用时的目标应用地址。
定义每次系统交互中每个环节向下调用的目标数据库名称（数据库类调用时）
记录该环节向下游发起调用时的目标数据库名称。
定义每次系统交互中每个环节向下调用的目标数据库地址（数据库类调用时）
记录该环节向下游发起调用时的目标数据库地址。
定义系统交互中入口环节的url地址（前台交互）
记录系统交互入口环节的url地址。

3. 建立关联图谱模型

可视化监控大屏是基于关联图谱模型进行自动化绘制和每天更新。

基于每天采集到的端到端链路链路数据，构建包含各应用模块上下游调用依赖关系（包括业务应用对数据组件的访问）、应用模块主机网络之间相互部署依赖关系。

一次复杂业务的从WEB前台受理到最后为用户真正办理成功，在系统的调用链是一个跨多系统模块，分布式、异步开通的长流程调用。在没有端到端跟踪技术前，这样一次调用链路中各模块之间的交互、调用依赖是一个黑盒，对系统做健康检测需要打开这个系统黑盒。在当前复杂的分布式系统的拓扑结构中，某次调用经过了哪个应用节点，该节点目前是调度部署在哪台虚拟机上，远端调用IP、端口是多少都较难关联。而这些信息恰好是运维分析需要的信息。

使用端到端调用链路跟踪技术，跟踪这些模块之间的每笔调用流，并使用异步跟踪技术把异步调用还原合并到调用链中，得到完整的调用链路。

完整的调用链路由一个个链路环节日志组成，每个链路环节日志包含基础的链路环节信息、当前环节的程序调用请求参数和返回报文，两个链路环节中间捕获的应用主动输出的日志（包含程序错误堆栈）、主机、网络数据等。日志中很多数据为长文本、半结构化数据，所以需要先做分词处理来提取。

在这个实施案例中，我们基于flink实时计算来作为分词及链路上下游依赖关系发现模块的承载平台，执行以下的挖掘处理步骤，来构建上下游依赖信息的关系图谱自发现模型。

STEP1-明确可用的调用链环节数据：首先梳理、定义链路环节中和上下游依赖关系相关的信息关键字，通过流式处理筛选出满足关键字预选规则的链路环节日志，认为此日志为一个可用的调用链环节数据，将其提取出来。
STEP2-挖掘可调用链上下游依赖关系：从第一步得到的调用链环节数据中挖掘出此次调用链环节属于哪个调用链，归属哪个业务调用，该调用链环节目前在哪个应用模块节点（应用模块节点包括：业务应用、redis、memcache、数据库等）上、上级应用节点的信息、下级应用节点信息、执行动作信息（接口或函数，或sql语句），做去重后生成为一个该环节的上下游依赖关系键。上下游依赖关系键包含了该链路环节在整个调用流程的上下游关系。
STEP3-分析其立体式主机网络部署关系：继续分析调用链环节数据，挖掘出发生此次调用链环节的应用节点、该应用节点在调用发生当时部署在哪台主机、哪个网络IP的立体式部署关系键，此关系键命名为应用主机网络的立体式部署关系键。
STEP4-生成上下游依赖运维知识图谱：以每半天为统计周期，通过分析关联上下游依赖关系键，去重，以每个业务编码为根节点，自动生成一个完整的基于业务的调用关系链路，得出上下游依赖运维知识图谱，通过分析关联应用主机网络的立体式部署关系键，生成出纵向的立体式的运维知识图谱，构建出哪些应用模块部署在哪些物理中心的哪些主机上，相互之间的网络调用IP关系，以及每台主机上部署了多少个应用实例等信息。
模型更新频度：每半天做一次动态更新。

我们在端到端调用链监控平台中还纳管了数据库集群的内部端到端链路管理，实现了数据库的异常监测和问题快速诊断能力。对于数据库模块，单独建立了专门的端到端数据库监控大屏，用来呈现其内部的数据流向及关键组件运行状态。

大屏包含数据库节点、ADG节点、心跳延时节点、ADG延时节点四类节点、对性能异常、数据库健康度进行异常检测，大屏展示健康节点数及异常节点数、展示每套库对应的数据量、总节点数、健康节点数及异常节点数。

基于上述大屏及下钻后的副屏展现，能实现对运维知识图谱的立体化、可视化展现，结合了业务、应用、网络、主机、中间件、数据库等各维度的信息集成展现，再结合异常检测、健康度模型评分，提供运维人员快速发现异常，并定位诊断故障的能力。

4. 构建检测指标体系

在完成系统架构的大屏展现和数据库、物理部署视图、业务流程视图等各类专题副屏的基础上，为了第一时间获得系统运行的实际状态，需要通过业务链日志数据实时提取各业务、应用、实例、主机、网络等系统组成部分的各类细项指标，也需从其他系统进行数据采集，用于构建算法分析系统运行状态的自动异常检测能力。

因此一套灵活、准确、高效的数据采集、指标生成体系是必不可少的。

同样基于flume、flink开源计算框架搭建了实时指标库。由生产系统生成的调用链数据通过分词处理形成半结构化数据，再对其中的关键字段做规则统计、数值计算等处理形成指标数据，指标还可配置告警，并将告警再做复合指标计算，完整处理过程如下图如所示：

业务链日志生成指标、处理流程示意图

其中在指标生成逻辑上，融合了数值计算和逻辑判断两类规则体系，如下所示：

通过以上的数值计算及逻辑计算规则，对业务链日志数据做处理自由配置生成不同的关键指标。

这些指标数据集成在端到端可视化监控大屏中，也被各系统健康度模型所使用。系统出现告警后，运维人员往往需要各类细项指标帮助其进行分析，帮助快速做一些问题诊断，灵活高效的数据指标生成体系能帮助运维人员快速采集、展现他们关注的指标，运维人员可通过这些指标快速了解当前系统的运行负载情况，以及各业务、应用集群、网络、数据库等组件的运行状态。

应用效果

通过以上模型构建出关联图谱后，并基于该图谱和指标体系实现了对系统各维度（包含应用、主机、数据库、中间件、网络IP等信息）的异常监测和问题快速诊断，并结合异常检测、健康度模型评分，提供运维人员快速发现异常，并定位诊断故障的能力。

同时，通过自动化绘制可视化系统拓扑监控大屏直观展现系统运行时的各模块的状态。

END

本文作者：李秋霖

本文来源：IT那活儿（上海新炬王翦团队）