应用SpringAOP及Tlog工具完成日志链路追踪、收集、持久化

630 阅读3分钟

「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!

❌一、痛点

目前我司各系统的日志管理比较原始,使用logback打日志到log文件,虽然有服务管理平台,但记录的日志也仅仅是前置机调用后台系统的出入参,当遇到问题时查日志较为麻烦。

登录VPN-打开服务器-找到日志目录-打开日志文件-搜索

而这个过程也仅仅是在一台服务器上的操作,一般需要看前置机、后台系统甚至服务管理平台。

当用户较少时,通过先后顺序等其他标志还能查到,但当调用量稍多后就很难判断哪个日志是哪个操作发出的。

另外,我司产品前台面向用户,后台与多家公司产品有大量互相调用,当用户遇到问题首先投诉的是我司产品,如在日志中找不到问题点,背锅的就是我们。

✔️二、解决思路

任务有2个

  1. 链路追踪,一次调用的日志,无论跨多少平台都能串起来;
  2. 日志存库,这主要是为了开发一个日志查询功能,提供给运维人员。

2.1、Tlog

经过一番考察吧,对于链路追踪,我们选用了Tlog这个日志追踪工具。主页链接:yomahub.com/tlog/

主要考虑点是:

  • 最基础的功能:日志打标签,并且支持标签模板的自定义,可通过TLogContext.getTraceId()和TLogContext.putTraceId(id)获取和设置id;
  • 业务代码无侵入

不过对HttpClient是侵入式的,需要加拦截器

这个拦截器的实现还是颇为简单

public class TLogHttpClientInterceptor implements HttpRequestInterceptor {
    
    private static final Logger log = LoggerFactory.getLogger(TLogHttpClientInterceptor.class);
    
    @Override
    public void process(final HttpRequest request, final HttpContext context) throws HttpException, IOException {
        Args.notNull(request, "HTTP request");
        String traceId = TLogContext.getTraceId();
        if(StringUtils.isNotBlank(traceId)) {
            String appName = TLogSpringAware.getProperty("spring.application.name");

            request.addHeader(TLogConstants.TLOG_TRACE_KEY, traceId);
            request.addHeader(TLogConstants.TLOG_SPANID_KEY, SpanIdGenerator.generateNextSpanId());
            request.addHeader(TLogConstants.PRE_IVK_APP_KEY, appName);
            request.addHeader(TLogConstants.PRE_IVK_APP_HOST, LocalhostUtil.getHostName());
            request.addHeader(TLogConstants.PRE_IP_KEY, LocalhostUtil.getHostIp());
        } else {
            log.debug("[TLOG]鏈湴threadLocal鍙橀噺娌℃湁姝g‘浼犻�抰raceId,鏈璋冪敤涓嶄紶閫抰raceId");
        }
    }
}

不过需要注意的点是,有一些方法使用了Hutool高版本提供的方法,注意项目中版本冲突的解决。

对Tlog的集成还有一个问题,公司使用的服务管理平台由其他部门开发管理,需要该部门协同解决,不过好在我们可以拿到源码😂😂

2.2、日志存储

日志存储自然不希望对当前业务有任何影响,考虑到系统并发量并不是很大,就采用线程池来调用日志系统存库。

2.3、日志收集

使用注解主要对出入参及异常信心进行收集处理。另外对logback进行简单封装,提供info()、error()等方法,这些方法输入的日志也进行收集、存储。 因业务特殊性,需要使用的系统都复用一套自定义注解、公共切面方法,并在切面中完成特殊业务的处理。

颇多细节就不多写了,本文主要就是介绍整体思路,对于调用量说多不多的系统还可以。