链接追踪系列-03.试验zipkin初步

最新推荐文章于 2025-03-17 09:38:55 发布

csdnfanguyinheng

最新推荐文章于 2025-03-17 09:38:55 发布

阅读量551

点赞数 10

分类专栏：链路追踪文章标签： spring cloud zipkin traceId

本文链接：https://blog.youkuaiyun.com/csdnfanguyinheng/article/details/140400368

版权

链路追踪专栏收录该内容

11 篇文章

订阅专栏

本机启动docker,以及docker中的nacos
本机启动zipkin server
使用es存储数据，并且es使用了x-pack认证
启动gateway服务

启动之前配置zipkin:
spring:
	zipkin:
      base-url: http://localhost:9411

在这里插入图片描述
日志配置：

<!--使用默认的控制台日志输出实现-->
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>

<springProperty scope="context" name="LOG_FILE_PATH" source="logging.file.path" defaultValue="logs"/>

<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}}"/>

在这里插入图片描述
上述日志配置说明：分析引入的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}就是引用了这个环境变量。
另外：增加的spring.application.name、X-B3-TraceId和X-B3-SpanId的值从哪里来呢？继续看代码
org.springframework.cloud.sleuth.log.Slf4jCurrentTraceContext
这个类中通过MDC ( Mapped Diagnostic Contexts )的方式把traceId、spanId插入到日志内容中

启动auth服务
zipkin server配置和日志配置同上述gateway
接口请求测试

在这里插入图片描述
此接口先通过gateway服务，然后转到auth服务，获取数据后，再响应回来。

auth微服务控制台也输出traceId和spanId，以及业务日志：

接下来看日志文件：

日志文件中同样有traceId,spanId以及业务日志信息输出。至此，日志打印完毕，接下来看zipkin server:
http://localhost:9411/zipkin/
根据traceId搜索下：可看到链路追踪
在这里插入图片描述
有个重要的功能点丢了：zipkin追踪数据存放在es中，看到的数据只是上述zipkin网页数据那般，咱们的业务日志打印数据没有显示出来！

如果业务响应头中包含了traceId，方便查找问题就好了
这就需要在代码响应前拿到zipkin的traceId，然后设置到http response 响应头中。
然后在es kibana中可以根据traceId查找业务日志链路
把日志文件“塑形”整理下，形成json格式的日志内容，里面包含traceId, spanId, 业务类，日志级别，打印的业务日志内容。然后存放到es中，在kibana中通过traceId搜索即可。
问题又出现了：如果把日志文件中的内容（或者说控制台的日志内容）收集起来存到es呢？这就引申出了logstash,
至此ELK组件联合出现了！

这个是后面章节探索的篇章