LiteFlow特性：日志打印

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

目录

一、打印组件执行日志

二、不打印组件执行日志

三、打印组件链路信息

四、组件执行日志的实战用途

总结

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、打印组件执行日志

[ea1af4810cc849d58948d091d858b29a]:[O]start component[ACmp] execution
[ea1af4810cc849d58948d091d858b29a]:[O]start component[BCmp] execution
[ea1af4810cc849d58948d091d858b29a]:[X]start component[CCmp] execution
[ea1af4810cc849d58948d091d858b29a]:[O]start component[DCmp] execution

ea1af4810cc849d58948d091d858b29a：代表这个请求的请求ID

[O]：代表了执行了这个组件的主要逻辑

[X]：代表因为isAccess()返回了false所以没进入这个组件的主要逻辑

二、不打印组件执行日志

liteflow.print-execution-log=false

三、打印组件链路信息

a<100>==>c<10>==>m<0>==>q<200>==>p<300>==>p1<0>==>g<305>

这里的表达形式为：组件ID<耗时毫秒>

如果你希望在打印流程链的时候增加别名描述，那你需要在定义组件的时候设置name属性

增加了别名之后，执行步骤信息的打印会变成以下样子

a[组件A]<100>==>b[组件B]<0>==>m[组件M]<256>

这里的表达形式为：组件ID[组件别名]<耗时毫秒>

四、组件执行日志的实战用途

下边说一个案例，来讲一下这个组件执行日志的妙用。

案例背景：

有个定时任务，需要处理一批数据，每一条数据都有很长的逻辑处理过程，过程中各个关键位置都会有日志输出。并且日志输出格式中，就有traceId，通常我们是通过关键信息，拿到traceId，然后再分析整个执行过程的日志，但是当日志特别多的时候，要集中展示某一条数据处理过程中相关的日志，就显得比较困难，除非在每个处理的逻辑日志中，均添加这一条数据相关的关键字。这个又不合适。

LiteFlow组件日志输出为我们提供了一个新的思路。

traceId的使用仍然不变，我们可以在每一条数据处理时，自定义一个请求ID，然后伴随着这一条数据的组件执行，进行输出，这样既不会影响traceId的使用，又能达到我们想要的区分效果。

话不多说，上例子：

首先，我们定义一个类，实现RequestIdGenerator接口

public class CustomRequestIdGenerator implements RequestIdGenerator {

    @Override
    public String generate() {
        return System.nanoTime();
    }
}

然后，在LiteFlow的配置文件里声明下你这个类

liteflow.request-id-generator-class=com.yomahub.liteflow.test.requestId.config.CustomRequestIdGenerator

看到这里了，是不是我们可以把生成规则定义为每条数据的关键字。

最后通过traceId+关键字，就可以查出来这次定时任务执行过程中，某一条数据的全部组件执行过程了。

---

总结

每天进步一点点！