前言
最近一个敌人老是和我埋怨:公司系统日志打的切实是太烂了,有用的信息很少,没用的一大堆。就连那有用的信息,在那么多节点日志之间进行追究,也是苦楚的一笔。
我问他,公司没有日志收集吗,日志收集起来看总好过一个节点一个节点日志查看。他示意,公司有接入一个免费第三方的日志产品,做了收集。然而仅仅是不便了统一化查看搜寻,然而零碎自身的日志短少一些关键性的因素。比拟乱,在很多微服务之间查看调用日志时定位很难。
演绎下来问题有以下几点:
- 并非所有的日志有关键性信息,比方订单号和 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
打印 5w 条日志(秒) | 打印 10w 条日志(秒) | |
---|---|---|
第 1 次 | 6.496249974 | 15.595447718 |
第 2 次 | 6.185712521 | 14.295489162 |
第 3 次 | 6.116123718 | 13.559289437 |
第 4 次 | 6.205771261 | 12.782565374 |
第 5 次 | 6.727208117 | 12.884360048 |
第 6 次 | 5.908489157 | 14.604699842 |
第 7 次 | 6.153151066 | 13.700609245 |
第 8 次 | 6.603960836 | 13.048889457 |
第 9 次 | 6.139718196 | 12.584335736 |
第 10 次 | 6.365920588 | 12.85222910 |
均匀 | 6.29 | 13.60 |
退出 TLog
打印 5w 条日志(秒) | 打印 10w 条日志(秒) | |
---|---|---|
第 1 次 | 5.997981416 | 12.878389572 |
第 2 次 | 6.154590093 | 14.268328625 |
第 3 次 | 6.228010581 | 12.385200456 |
第 4 次 | 6.452949788 | 15.542794904 |
第 5 次 | 6.156225995 | 12.350440713 |
第 6 次 | 6.121611887 | 12.543883453 |
第 7 次 | 6.18131273 | 12.192140225 |
第 8 次 | 6.238254682 | 12.159684042 |
第 9 次 | 6.403632588 | 12.308115127 |
第 10 次 | 5.954781153 | 12.321667925 |
均匀 | 6.19 | 12.89 |
测试后果有点出其不意,加了 TLog 后 10 次均匀下来反而比不加要快第一点。然而我揣测应该是测试环境和样本数量太少的问题,并不是说加反而比不加要快。只能说,如果进行 100 次,1000 次测试。2 者应该是差不多的。
从这个性能测试也侧面反映了,TLog 不会给零碎带来额定的开销。这点也赞一下。
总结
这次评测这款开源框架 TLog 总体上还算是个日志框架,然而集成了分布式追踪,日志标签和其余一些小性能还算是一个蛮有特色的 Java 开源我的项目,从构造上来说,它十分玲珑,而且性能也十分优越。从实用性上来说,它解决了在中小公司疾速定位日志的痛点。毛病是不收集日志,无奈做更无效的日志开掘,然而这也是 TLog 号称 10 分钟接入的起因。从主观上来剖析,这无利也有弊。心愿 TLog 在之后可能欠缺这一部分的性能。
对于我
我是一个开源作者,也是一名内容创作者。「元人部落」是一个保持做原创的技术科技分享号,会始终分享原创的技术文章,陪你一起成长。