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

IT那活儿发布于2023-01-11 13:19 / 3327人阅读

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

点击上方“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那活儿（上海新炬王翦团队）

GPU云服务器云服务器端到端端到端测试 webrtc端到端通信 webrtc端到端延时

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129493.html

何勉：第一性原理和精益敏捷的规模化实施

摘要：摘要什么是第一性原理第一性原理如何指导我们的精益敏捷开发阿里资深解决方案架构师畅销书精益产品开发原则方法与实施作者何勉，结合实践案例，详述第一性原理和精益敏捷的规模化实施。前言今天分享的题目是第一性原理和精益敏捷的规模化实施。摘要：什么是第一性原理？第一性原理如何指导我们的精益敏捷开发？阿里资深解决方案架构师、畅销书《精益产品开发：原则、方法与实施》作者何勉，结合实践案例，详述第一...

233jl 2019-05-29 17:02 评论0 收藏0
云计算时代的网络进阶

摘要：李耀宗强调，要从根本上支持企业数字化转型，需要从基础设施和应用两个方面提高对复杂网络环境的管理监测能力，增强企业使用网络的安全性复杂性，从而才能真正消除企业云优先战略当中的盲点和障碍。互联网改变了传统PC时代IT架构的技术逻辑，带来了无限的存储空间和无穷的计算能力，同时，又借助云计算彻底颠覆了以往商业模式上的所有铁律。有89％的企业计划采用数字优先的战略；超过85％的人认为，云是数字化转型的...

gecko23 2019-04-29 15:40 评论0 收藏0
TOP100summit：【分享实录-封宇】58到家多端消息整合之路

摘要：封宇到家架构师。主要负责到家消息系统以及门户等公司战略级产品研发。消息服务器收到拉取离线消息请求，表明端已经收到之前的数据。统一消息推送通道，整合个推米推微信短信等消息推送方式，尽最大可能确保消息送达用户。本篇文章内容来自2016年TOP100summit 58到家架构师封宇的案例分享。编辑：Cynthia2017年11月9-12日北京国家会议中心第六届TOP100summit，留言...

googollee 2019-06-24 17:53 评论0 收藏0
创新赋能，筑基未来 ——“2021中国IPv6创新发展大会”在京召开

摘要：为贯彻落实关于加快推进互联网协议第六版规模部署和应用工作的通知部署要求，促进技术产业网络应用安全协同发展，搭建行业交流合作平台，年月日日，以创新赋能，筑基未来为主题的中国创新发展大会在北京举行。为贯彻落实《关于加快推进互联网协议第六版（IPv6）规模部署和应用工作的通知》部署要求，促进I...

wuyangchun 2021-10-14 09:42 评论0 收藏0
前端进阶之路: 前端架构设计(3) - 测试核心

摘要：而测试驱动开发技术并不只是单纯的测试工作。需求向来就是软件开发过程中感觉最不好明确描述易变的东西。这里说的需求不只是指用户的需求，还包括对代码可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备受重视, 早在开发工作启动之前, 他们就被邀请加入到项目中, 而且他们会跟客户讨论即将建成的平台的...

Karuru 2019-08-01 18:16 评论0 收藏0
前端进阶之路: 前端架构设计(3) - 测试核心

摘要：而测试驱动开发技术并不只是单纯的测试工作。需求向来就是软件开发过程中感觉最不好明确描述易变的东西。这里说的需求不只是指用户的需求，还包括对代码可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备受重视, 早在开发工作启动之前, 他们就被邀请加入到项目中, 而且他们会跟客户讨论即将建成的平台的...

宋华 2019-08-22 11:22 评论0 收藏0