关于java:对乱糟糟的日志说再见

前言

最近一个敌人老是和我埋怨：公司系统日志打的切实是太烂了，有用的信息很少，没用的一大堆。就连那有用的信息，在那么多节点日志之间进行追究，也是苦楚的一笔。

我问他，公司没有日志收集吗，日志收集起来看总好过一个节点一个节点日志查看。他示意，公司有接入一个免费第三方的日志产品，做了收集。然而仅仅是不便了统一化查看搜寻，然而零碎自身的日志短少一些关键性的因素。比拟乱，在很多微服务之间查看调用日志时定位很难。

演绎下来问题有以下几点：

• 并非所有的日志有关键性信息，比方订单号和 SKU 信息，有些日志有，有些日志没有，导致有些日志尽管打出了解决步骤日志，然而并不知道是解决哪一个对象。
• 日志没有对立标准，导致看起来十分横七竖八
• 微服务之间同一个申请的调用链追究更加苦楚，往往只能依据工夫戳去搜寻，并发小的时候，通过工夫戳还能查到，并发一大，查问题的老本太大了。

我给他举荐了一些分布式追踪框架，skywalking，pinpoint。他看过之后示意，很欠缺，然而搭建和推广老本有点大。还波及到存储老本，公司曾经购买了第三方的日志服务。对接起来还是有点麻烦的。恐怕下面不批准这么折腾。

近段时间，在开源社区看到这么一款开源框架，号称是轻量级的日志追踪神器，10 分钟接入，于是我举荐了给了敌人。过了几日，他和我示意这个货色十分贴切他当初的痛点，当初曾经上生产，初步成果来看，还是十分称心的。能给他们的日志定位缩小工夫老本。

我的项目个性

受邀请，所以我打算来剖析下这款框架。给大家一个直观的了解。

这个框架叫 TLog，我的项目托管在 Gitee 上

https://gitee.com/dromara/TLog

主页长这样，浓浓的一股暗黑系。。。

我应用下来，直白点的说，就是 TLog 为每一行日志主动打了前缀，也就是所谓的 标签。标签分为零碎级标签和业务型标签，其中业务型标签开发者能够自定义。画了张图便于了解：

TLog 最终出现的每行日志，就如同上图所示。其中系统日志，可能展示的信息目前有 5 个，上游信息可能让你晓得是谁调用了你的零碎，链路 TraceId 则是跨微服务的全局链路惟一 ID，搜寻一个 Id，就能失去所有零碎中同一申请的日志。这个还是很香的！

对于 SpanId，官网的解释是，这是一个代表本次调用在整个调用链路树中的地位，具体演示借用下官网的图，解释的还算清晰：

集体对 SpanId 的了解是，这个货色能够让你晓得零碎在某一个调用链中的层级，如果加以收集，能够通过 spanId 生成一棵调用链路树。其实很心愿 TLog 能实现这个树的展现，惋惜当初还不反对。

“TLog 的定位是提供了一种最简略的形式来解决日志追踪问题，它不收集日志，也不须要另外的存储空间，它只是主动的对你的业务日志进行打标签，主动生成 TraceId 贯通你微服务的一整条链路。并且提供上下游节点信息。适宜中小型企业以及想疾速解决日志追踪问题的公司我的项目应用。“

这是官网的赘述，事实上我在测试的时候，TLog 所提供的日志就是日志自身，在多节点微服务当中，日志还是扩散的。只是在逻辑上给日志进行肯定水平的串联。然而同时，TLog 文档也倡议说，利用其它的计划去做日志收集。比方 ELK，阿里云日志，其它免费的日志产品等等。TLog 只是批改日志，并不生成新的日志。所以对接其它日志收集计划，也是齐全没有任何问题的，对于曾经对接日志收集计划的公司来说，也齐全不须要批改什么。

反对的日志框架

每个公司所用的日志框架不拘一格。TLog 声称反对了支流的三大日志框架：log4j，log4j2，logback

理论测试中，在这 3 个框架中，TLog 也都可能失常打印出标签。只是在接入过程中，官网给出的接入形式有 3 种

测试下来，javaagent 的形式对于有些我的项目确实不太稳固，有些简单的我的项目会呈现有效的状况。对于声称最稳固的日志适配形式，测试了一下公司的我的项目，确实能顺利接入。

接入形式，依照文档一步步来就能够了。

反对的 RPC 框架

既然是跨微服务进行日志追踪，在实现方面也要对罕用的 RPC 进行反对。TLog 反对了 Dubbo，SpringCloud，Dubbox 三种罕用的 RPC，这点还是不错的。

理论测试中，在 Spring cloud 这块，TLog 还反对了 SpringCloud 的 Gateway。

在接入过程中，无论是哪种 RPC 框架，在 springboot 环境下 TLog 也能主动适配，引入一个就能主动拆卸。无需额定的配置。这点很不便。

然而在原生 spring 环境下(非 springboot)，还是须要 xml 的额定配置的，然而也绝对简略，文档也有专门的阐明。

业务标签

除了零碎给予的标签外，我发现 TLog 另一大特点就是容许开发者自定义标签。接入也很简略，举个例子：

@TLogAspect({"str","user.name","user.userDetail.company","user.dddd"})
    public void test(String str, User user){log.info("这是自定义表白标签");
        log.info("这是业务日志 1");
        log.info("这是业务日志 2");
        log.info("这是业务日志 3");
        log.info("这是业务日志 4");
        log.info("这是业务日志 5");
    }

只有在办法上加一个标签，那么这个办法上面所有的日志，包含之后的 N 个层级，都会主动加上你定义的标签

这个性能在对日志的排版和查找上，又能减少很多个标记。这个很赞！

甚至于自定义标签还反对对信息的逻辑解决，能够自定义类去解决这些信息

@TLogAspect(convert = CustomAspectLogConvert.class)
public void demo(Person person){log.info("自定义 Convert 示例");
}

这个具体成果，大家能够去试试。总之一个标签搞定所有的自定义标签。

其余场景的反对

参数 & 耗时打印反对：

引入了 TLog 之后，发现 TLog 还附带了无论在哪种框架之下每个办法的参数打印和耗时，默认为敞开，须要的只须要配置下就能够了：

tlog.enableInvokeTimePrint=true

进去的成果如下：

异步线程 & 线程池的反对

如果你的我的项目有异步线程，对于标签传递的连贯性，也是主动反对的，没有任何问题。

然而对于线程池场景，TLog 并没有原生反对。然而提供了一个辅助类，须要大量的侵入代码。这点还有待改善。

MQ 反对

同样的，TLog 也思考到了 MQ 场景标签的传递。这个也须要大量的侵入代码。如果你什么都不改，则在 MQ 场景下无奈反对。

性能

对于性能，我对 TLog 进行了简略的测试，只在 log4j2 的环境下进行了测试，测试条件是同步打印出几 w 条日志，在原生环境下的耗时和退出 TLog 框架之后的耗时比照，每组别离测 10 次，取平均值

测试代码非常简单:

StopWatch stopWatch = new StopWatch();
stopWatch.start();
for (int i = 0; i < 100; i++) {log.info("test log {}", i+1);
}
stopWatch.stop();
log.info("耗时:{}",stopWatch.getTotalTimeSeconds());

不加 TLog

退出 TLog

测试后果有点出其不意，加了 TLog 后 10 次均匀下来反而比不加要快第一点。然而我揣测应该是测试环境和样本数量太少的问题，并不是说加反而比不加要快。只能说，如果进行 100 次，1000 次测试。2 者应该是差不多的。

从这个性能测试也侧面反映了，TLog 不会给零碎带来额定的开销。这点也赞一下。

总结

这次评测这款开源框架 TLog 总体上还算是个日志框架，然而集成了分布式追踪，日志标签和其余一些小性能还算是一个蛮有特色的 Java 开源我的项目，从构造上来说，它十分玲珑，而且性能也十分优越。从实用性上来说，它解决了在中小公司疾速定位日志的痛点。毛病是不收集日志，无奈做更无效的日志开掘，然而这也是 TLog 号称 10 分钟接入的起因。从主观上来剖析，这无利也有弊。心愿 TLog 在之后可能欠缺这一部分的性能。

对于我

我是一个开源作者，也是一名内容创作者。「元人部落」是一个保持做原创的技术科技分享号，会始终分享原创的技术文章，陪你一起成长。