关于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在之后可能欠缺这一部分的性能。

对于我

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