ApiBoot Logging会为每一个请求都对应创建链路编号（TraceID）以及单元编号（SpanID），用于归类每一次请求日志，通过一个链路下日志单元的Parent SpanID可以进行上下级关系的梳理。

通过ApiBoot Logging可以将每一条请求的详细信息获取到，在分布式部署方式中，一个请求可能会经过多个服务，如果是每个服务都独立保存请求日志信息，我们没有办法做到统一的控制，而且还会存在日志数据库与业务数据库不一致的情况出现（可能会用到多数据源配置），正因为这个问题ApiBoot Logging提供了一个Admin的概念，将客户端采集到的的每一条日志都进行上报到Admin，由Admin进行分析、保存等操作。

ApiBoot Logging通过集成minbox-logging来进行管理每一次请求的日志信息，包含头信息、参数、主体内容、路径、发生的服务器相关信息等，根据接口的响应状态还可以记录响应的头信息、响应的内容以及发生异常时的堆栈信息。

在新版本的SpringBoot2.0发布后，急迫尝鲜的我将相关的项目已经更换为最新版本，在SpringBoot源码GitHub看到更新日志，表明了针对Quartz新版本进行了 AutoConfiguration自动化配置，省去了很多繁琐的配置。

在上一章中我们已经完成了任务的持久化，当我们创建一个任务时任务会被quartz定时任务框架自动持久化到数据库，我们采用的是SpringBoot项目托管的dataSource来完成的数据源提供，当然也可以使用quartz内部配置数据源方式，我们的标题既然是提到了定时任务的分布式多节点，那么怎么才算是多节点呢？当有节点故障或者手动停止运行后是否可以自动漂移任务到可用的分布式节点呢？

定时任务在企业项目比较常用到，几乎所有的项目都会牵扯该功能模块，定时任务一般会处理指定时间点执行某一些业务逻辑、间隔时间执行某一些业务逻辑等。