当前位置: 首页 > 工具软件 > TLog > 使用案例 >

TLog和sleuth对比与选择

唐修能
2023-12-01

1.由于公司会取给其他公司做私有化部署,而标品的链路追踪在私有化部署时,并没有提供那么多资源,为了方便排查bug,需要对日志框架进行改造,经过比对,发现TLog更适合私有化部署的场景
TLog适合没有分布式追踪服务的场景,如果有分布式追踪服务了就不用TLog了;如果不用TLog单纯的用sleuth把traceid打出来也基本满足排查日志的需求,但是没分布式日志追踪系统的前提下用TLong打印出来是比较清晰好排查问题的

1.TLog配置
TLog官网
yml加上如下配置,把应用名和端口打印出来

tlog:
  pattern: "[$preApp][$preIp][$spanId][$traceId]"

3.sleuth配置参考:

<?xml version="1.0" encoding="UTF-8"?>
 
<configuration scan="true" scanPeriod="60 seconds" debug="false">
    <!-- 参考SpringBoot默认的logback配置,增加了error日志文件 -->
    <!-- org/springframework/boot/logging/logback/base.xml  -->
 
    <conversionRule conversionWord="clr" converterClass="org.springframework.boot.logging.logback.ColorConverter" />
    <conversionRule conversionWord="wex" converterClass="org.springframework.boot.logging.logback.WhitespaceThrowableProxyConverter" />
    <conversionRule conversionWord="wEx" converterClass="org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter" />
 
    <property name="LOG_PATH" value="${LOG_PATH:-${LOG_TEMP:-${java.io.tmpdir:-/tmp}}}"/>
    <property name="CONSOLE_LOG_PATTERN" value="${CONSOLE_LOG_PATTERN:-%clr(%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>
    <property name="FILE_LOG_PATTERN" value="${FILE_LOG_PATTERN:-%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}} ${LOG_LEVEL_PATTERN:-%5p} ${PID:- } --- [%t] %-40.40logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>
 
    <!-- 控制台日志 -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
        </encoder>
    </appender>
 
    <!-- 全量日志 -->
    <appender name="FILE_ALL" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <encoder>
            <pattern>${FILE_LOG_PATTERN}</pattern>
        </encoder>
        <file>${LOG_PATH}/all.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/all.log.%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
            <maxFileSize>${LOG_FILE_MAX_SIZE:-50MB}</maxFileSize>
            <maxHistory>${LOG_FILE_MAX_HISTORY:-0}</maxHistory>
        </rollingPolicy>
    </appender>
 
    <!-- 错误日志 -->
    <appender name="FILE_ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <encoder>
            <pattern>${FILE_LOG_PATTERN}</pattern>
        </encoder>
        <file>${LOG_PATH}/err.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/err.log.%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
            <maxFileSize>${LOG_FILE_MAX_SIZE:-50MB}</maxFileSize>
            <maxHistory>${LOG_FILE_MAX_HISTORY:-0}</maxHistory>
        </rollingPolicy>
        <!-- 过滤出ERROR级别的日志 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>
 
    <!-- 日志总开关 -->
    <root level="INFO">
        <appender-ref ref="CONSOLE" />
        <appender-ref ref="FILE_ALL" />
        <appender-ref ref="FILE_ERROR" />
    </root>
 
    <!-- 日志过滤 -->
    <logger name="org.apache.catalina.startup.DigesterFactory" level="ERROR"/>
    <logger name="org.apache.catalina.util.LifecycleBase" level="ERROR"/>
    <logger name="org.apache.coyote.http11.Http11NioProtocol" level="WARN"/>
    <logger name="org.apache.sshd.common.util.SecurityUtils" level="WARN"/>
    <logger name="org.apache.tomcat.util.net.NioSelectorPool" level="WARN"/>
    <logger name="org.eclipse.jetty.util.component.AbstractLifeCycle" level="ERROR"/>
    <logger name="org.hibernate.validator.internal.util.Version" level="WARN"/>
</configuration>

二、引入sleuth zipkin是怎么输出traceId的?
一直有个疑问,为什么引入sleuth+zipkin之后,日志中会输出traceId和spanId:
从上面logback的配置文件FILE_LOG_PATTERN并未发现相关配置,其中必有妖怪!
通过分析引入的sleuth依赖,终于发现在spring-cloud-sleuth-core-xxx.jar找到,请看这个类

org.springframework.cloud.sleuth.autoconfig.TraceEnvironmentPostProcessor
 
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment,
            SpringApplication application) {
        Map<String, Object> map = new HashMap<String, Object>();
        // This doesn't work with all logging systems but it's a useful default so you see
        // traces in logs without having to configure it.
        if (Boolean.parseBoolean(environment.getProperty("spring.sleuth.enabled", "true"))) {
            map.put("logging.pattern.level",
                    "%5p [${spring.zipkin.service.name:${spring.application.name:-}},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}]");
        }
        addOrReplace(environment.getPropertySources(), map);
    }

这段代码在项目启动阶段,把环境变量logging.pattern.level替换了,增加了spring.application.name、X-B3-TraceId和X-B3-SpanId。实际上就是替换了环境变量LOG_LEVEL_PATTERN,再回到logback的配置文件FILE_LOG_PATTERN:

${FILE_LOG_PATTERN:-%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}} ${LOG_LEVEL_PATTERN:-%5p} ${PID:- } --- [%t] %-40.40logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}

其中${LOG_LEVEL_PATTERN:-%5p}就是引用了这个环境变量。

到此为止,是不是就完了呢?No~~!增加的spring.application.name、X-B3-TraceId和X-B3-SpanId的值从哪里来呢?继续看代码

org.springframework.cloud.sleuth.log.Slf4jCurrentTraceContext

这个类中通过MDC ( Mapped Diagnostic Contexts )的方式把traceId、spanId插入到日志内容中。
sleu
th可参考:SpringCloud Logback日志配置

开源框架TLog核心原理架构解析:开源框架TLog核心原理架构解析

 类似资料: