如何通过链路追踪进行定时任务诊断

背景简介

什么是定时任务

定时任务是业务应用系统中存在定时周期性运行的业务逻辑。由于其运行于后端进程中往往存在执行状态和执行链路的不可见性《常见定时任务技术方案》。

什么是链路追踪

随着分布式微服务化架构在企业中大规模运用，业务运行的应用平台是一个由各个业务研发团队不同业务应用组合而成的庞杂系统工程，相互之间存在各种形式的访问交互。'

面对上述如此复杂的系统结构，对于业务入口端应用而言所有的下游服务状态都是黑盒不可知的存在。相应的运维问题也随之而来：

入口服务不可用时，如何快速定位具体是哪个服务节点不可用及原因？
如何快速定位分析业务链路中性能瓶颈点？
如何掌控业务链路完整执行过程？

面对上述问题，从Google分布式链路追踪系统的Dapper论文开启了各类分布式链路追踪的实现，出现了很多相关系统，如：Zipkin、Skywalking、Pinpoint。所有这些其核心逻辑就是在一次业务请求开始时构建相应请求的链路上下文信息，并在服务调用过程中透传完善相应的链路节点信息，最终通过该请求TraceId（本次请求的链路标识）和每个节点父子依赖关系构建出一个完整的调用链数据结构。

整个分布式全链路追踪平台各项主要分工：

应用侧完成服务调用埋点，常见方式：手动调用SDK埋点、java agent模式自动埋点
服务之间通信交互，相应通信协议上需要添加Trace信息进行传递，保证在整个调用链中Trace信息共享
Trace信息上报至全链路追踪平台进行存储展现

基于上述几个主要环节，各个开源方案分别实现了各自在采集、传输、存储环节的不同数据结构。为实现链路追踪领域范围内数据结构统一，出现了OpenTracing和OpenTelemetry来定义相应的规范和协议。

为什么定时任务需要链路追踪

分析任务为什么执行失败

当业务不断发展，业务开发的定时任务也会越来越趋于复杂化，定时任务执行过程中会发展出如下各种形态：

会调用其他业务方各类下游应用服务
会调用其他中间件服务（如：redis、mq等）
会切分出N个子任务分发给不同机器进行分布式并行批处理，每个子任务处理又是一整套复杂组合

当面对此类复杂定时任务场景下任务执行如果出现异常，相应的问题定位将变得很复杂。在完整的全链路追踪能力支持下，问题将能被快速定位处理。

分析任务为什么执行慢

一般场景下离线任务往往承担着大批量数据处理的业务场景，因而很多定时离线任务有运行耗时长的特征，往往在这些耗时长的任务上存在着巨大的性能优化空间，性能提升能直接优化基础资源使用效率并节省业务成本

在任务调度平台上我们可通任务执行超时报警，再结合任务执行链路追踪能力可有效地锁定业务处理的耗时瓶颈点供进一步业务性能优化作为参考。

全链路流量控制

在全链路追踪体系下，可以进行后续其他能力拓展：

灰度发布：定时任务应用发布过程中的任务全链路灰度能力
全链路压测：定时任务通过业务测试标签参与全链路压测
流量隔离：定时任务调用下游服务，下游服务根据流量来源进行隔离处理

定时任务链路追踪解决方案

开源解决方案

从开源定时任务平台看，目前常见开源方案都未支持任务执行链路可视化查询，对复杂任务或分片任务执行异常下的问题分析会比较困难。

另外在开源链路追踪平台，对应开源方案中部分采集端agent集成了定时任务框架执行入口埋点采集，但该模式下与任务调度平台侧较为割裂，从负责定时任务运维的视角出发想具体锁定某一次任务执行链路，需要通过日志或根据执行时间检索匹配相应的执行记录，当链路追踪平台上数据繁多想快速唯一锁定目标链路存在很多不便。

阿里解决方案

阿里分布式任务调度平台SchedulerX提供了一站式的链路追踪解决方案，可以将任务执行信息与链路追踪Trace信息绑定，用户可以很方便的从任务调度侧，查看某个任务、某次执行、某个分片的完整调用链。

阿里SchedulerX方案优势：

精准定位任务执行Trace信息：常见链路追踪平台只负责任务执行的时候生成traceId，不提供和具体任务的绑定关系，想要从成千上万的traceId中分析某个任务的调用链变得非常复杂；SchedulerX无论是单机任务还是分布式任务的某个分片，每一次调度都能快速定位到调用链。
调度侧支持控制采样率：手动运行一次支持必采样、动态配置采样率。
免运维低成本：通过EDAS部署的Java业务应用天然支持定时任务Trace能力，无需自建链路追踪服务端平台和agent采集，降低业务成本，并且可以从任务调度侧一键跳转到调用链。

定时任务链路追踪客户案例

某电商业务定位任务执行慢

用户案例：目前电商业务场景下都基于微服务架构体系，定时任务运行涉及的应用较多且链路较深，用户对某个任务运行慢时，希望能快速定位哪个业务应用方哪个业务功能是执行链路瓶颈点。

以下将展示如何分析任务的执行耗时，任务触发执行后会调用多次下游业务应用服务以完成整个业务逻辑，整个任务执行耗时较长。

如上图所示，常规情况下一次执行<5秒，但最近两次次执行耗时>15s，通过任务配置超时报警可监测到该执行记录超过预期执行时间，对该执行记录的调用链路进入下一步分析。

如上图所示，通过链路追踪自动跳转获取完整调用链（同样自建平台者可拷贝TraceId查询锁定），从上图可分析获得执行耗时占比较高的业务应用和IP，可锁定在下游业务应用ServiceApplication的保存用户信息服务出现明显耗时。

某金融账户批处理定位执行异常

用户案例：某金融机构对老业务系统升级，需将所有客户账户信息进行定期批量迁移升级处理至新系统，每天会从老系统中加载一批次账户信息在业务集群中分发处理，完成每个账户信息升级迁移；当某个账户出现异常时，需要能快速定位执行异常的位置和原因。

通过SchedulerX的MapReduce模型进行分布式跑批，每个子任务对应一个客户账户信息业务处理，可展示每个子任务的执行列表，并提供链路追踪、重跑、日志查看等功能。

如上图所示，当整个任务执行出现异常失败，进入子任务列表锁定失败的子任务（如：账号1000002处理失败）。

如上图所示，通过链路追踪自动调整至该子任务的完整执行调用链（自建平台可拷贝TraceId查询锁定），可快速定位业务处理异常位置所在的业务应用和IP。

如上图所示，展开失败节点详情即可进一步获取失败内容信息（如案例：账号1000002在更新名称信息时字段超长），至此一个分布式批处理任务且存在多方服务调用的业务执行异常即可被快速定位。

某游戏业务分析Http执行链路

用户案例：某游戏业务系统中其内部采用了C++、Go等技术栈，SchedulerX未提供相应语言SDK直接接入，用户则通过暴露http服务方式接入SchedulerX定时触发运行，并支持其实现http任务执行完整调用链查看。

以下展示一个http服务被定时调度后，其内部还会进行下游多个应用业务服务调用。

通过上述执行链路即可获得一个http定时任务在整个业务集群中完整的执行链路。如果单纯在链路追踪平台上来查询该http服务的调用链路时，往往会罗列一堆请求记录且无法快速区分是否是某个定时任务触发而来的。因此对比上述方式，对任务调度平台侧运维定时任务执行状况的场景下，SchedulerX提供了更为清晰的任务执行链路追踪分析入口。