我给他推荐了一些分布式追踪框架,skywalking,pinpoint。他看过之后表示,很完善,但是搭建和推行成本有点大。还涉及到存储成本 ,公司已经购买了第三方的日志服务。对接起来还是有点麻烦的。恐怕上面不同意这么折腾。
近段时间,在开源社区看到这么一款开源框架,号称是轻量级的日志追踪神器,10分钟接入,于是我推荐了给了朋友。过了几日,他和我表示这个东西非常贴切他现在的痛点,现在已经上生产,初步效果来看,还是非常满意的。能给他们的日志定位减少时间成本。
受邀请,所以我打算来分析下这款框架。给大家一个直观的理解。
这个框架叫TLog,项目托管在Gitee上
gitee.com/dromara/TLo…
主页长这样,浓浓的一股暗黑系。。。
我使用下来,直白点地说,就是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进行支持。TLog支持了Dubbo,SpringCloud,Dubbox三种常用的RPC,这点还是不错的。
实际测试中,在Spring cloud这块,TLog还支持了SpringCloud的Gateway。
在接入过程中,无论是哪种RPC框架,在springboot环境下TLog也能自动适配,引入一个就能自动装配。无需额外的配置。这点很方便。
但是在原生spring环境下(非springboot),还是需要xml的额外配置的,但是也相对简单,文档也有专门的说明。
除了系统给予的标签外,我发现TLog另一大特点就是允许开发者自定义标签。接入也很简单,举个例子:
只要在方法上加一个标签,那么这个方法下面所有的日志,包括之后的N个层级,都会自动加上你定义的标签
这个功能在对日志的排版和查找上,又能增加很多个标记。这个很赞!
甚至于自定义标签还支持对信息的逻辑处理,可以自定义类去处理这些信息
这个具体效果,大家可以去试试。总之一个标签搞定所有的自定义标签。
参数&耗时打印支持:
做任何事情都要用心,要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。
当然要想成为一个技术大牛也需要一定的思想格局,思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局,未来你的路会走的更远。
更多的技术点思维导图我已经做了一个整理,涵盖了当下互联网最流行99%的技术点,在这里我将这份导图分享出来,以及为金九银十准备的一整套面试体系,上到集合,下到分布式微服务
如何获得这套优质的资料呢?
Java面试精选题、架构实战文档传送门:戳这里免费领取