TLog能解决什么痛点
随着微服务盛行,很多公司都把系统按照业务边界拆成了很多微服务,在排错查日志的时候。因为业务链路贯穿着很多微服务节点,导致定位某个请求的日志以及上下游业务的日志会变得有些困难。
这时候很多童鞋会开始考虑上SkyWalking,Pinpoint等分布式追踪系统来解决,基于OpenTracing规范,而且通常都是无侵入性的,并且有相对友好的管理界面来进行链路Span的查询。
但是搭建分布式追踪系统,熟悉以及推广到全公司的系统需要一定的时间周期,而且当中涉及到链路span节点的存储成本问题,全量采集还是部分采集?如果全量采集,就以SkyWalking的存储来举例,ES集群搭建至少需要5个节点。这就需要增加服务器成本。况且如果微服务节点多的话,一天下来产生几十G上百G的数据其实非常正常。如果想保存时间长点的话,也需要增加服务器磁盘的成本。
当然分布式追踪系统是一个最终的解决方案,如果您的公司已经上了分布式追踪系统,那TLog并不适用。
笔记
TLog提供了一种最简单的方式来解决日志追踪问题,它不收集日志,也不需要另外的存储空间,它只是自动的对你的日志进行打标签,自动生成TraceId贯穿你微服务的一整条链路。并且提供上下游节点信息。适合中小型企业以及想快速解决日志追踪问题的公司项目使用。
最佳实践
前面说了,TLog不收集日志,只在原日志上增强。那么微服务中那么多节点,如何查看日志呢?TLog为什么不做日志收集以及统一界面查看呢?
其实收集日志,业界已经有很成熟的方案了,比如ELK方案,完全可以自己搭建。要是TLog自己弄,也无非是这一套。况且有很多云日志产品可以选择,很多大型的云厂商都推出了云日志的产品。完全可以满足收集的需求。
所以,最佳实践就是,TLog+日志收集方案。作者公司就是用TLog+阿某云日志产品,TLog负责打标签,云日志产品负责收集和展现搜索。相得益彰。
为此TLog适配了三大日志框架,支持自动检测适配。支持dubbo,dubbox,spring cloud三大RPC框架,更重要的是,你的项目接入TLog,可能连十分钟就不需要 :)