云南seo简单整站优化,怎么在阿里云上做网站,网络运营者不得违反法律,哈尔滨网站建设价格文章目录 一、介绍二、添加依赖三、修改日志配置1. 添加链路表示traceId2. 添加链路上下文3. 异步日志 四、收集链路日志 一、介绍
在上一篇文章skywalking全链路追踪中我们介绍了在微服务项目中使用skywalking进行服务调用链路的追踪。
本文在全链路追踪的基础上#xff0c… 文章目录 一、介绍二、添加依赖三、修改日志配置1. 添加链路表示traceId2. 添加链路上下文3. 异步日志 四、收集链路日志 一、介绍
在上一篇文章skywalking全链路追踪中我们介绍了在微服务项目中使用skywalking进行服务调用链路的追踪。
本文在全链路追踪的基础上我们介绍如何使用skywalking对一次调用链路上进行日志收集。
skywalking日志收集方式有两种 从日志文件中收集 在微服务项目中每一个微服务所产生的日志均会保存到本地日志文件或远程文件服务器中skywalking提供Filebeat、Fluentd、Fluent-bit三种方式通过kafka或http读取日志文件并将其按照调用链路进行收集。 Filebeat 此方式应用于本地日志文件场景。由使用kafka进行日志收集需要在skywalking客户端的配置文件agent.conf和服务端的配置文件application.yml中对kafka-fetcher进行配置并在skywalking客户端添加配置文件filebeat.yml。 Fluentd 此方式应用于本地日志文件场景。使用kafka进行日志收集需要在skywalking客户端的配置文件agent.conf和服务端的配置文件application.yml中对kafka-fetcher进行配置并在skywalking客户端添加配置文件fluentd.conf。 Fluent-bit 此方式应用于远程文件服务器场景。使用http进行日志收集需要在skywalking服务端的配置文件application.yml中对core或receiver-sharing-server的restHost:restPort项进行配置。并添加配置文件fluent-bit.conf。 从skywalking客户端收集 在微服务项目中每一个微服务都会有一个日志配置文件用于规范日志的输出格式。skywalking客户端提供了工具将输出的日志通过消息队列(如kafka)或http发送到skywalking服务端。此方式只需要对日志配置文件进行修改。 skywalking支持的日志框架有log4j、log4j2、logback。
我们本次的日志收集演示采用从skywalking客户端收集的方式并使用springboot推荐的日志框架logback。
二、添加依赖
在各个微服务的pom.xml中添加以下依赖
dependencygroupIdorg.apache.skywalking/groupIdartifactIdapm-toolkit-logback-1.x/artifactIdversion8.9.0/version
/dependency三、修改日志配置
在我们添加的依赖apm-toolkit-logback-1.x中包含了大量适配于logback与skywalking的Appender、Encoder以及Layout实现类。下面我们需要对日志配置文件进行修改。
在微服务系统的一次请求调用链中可能出现多个服务之间相互调用的场景(如商品服务调用订单服务订单服务调用支付服务)。而这些服务显然处于不同的进程甚至不同的服务器如何确定一个请求的调用链路中调用了哪些服务呢
1. 添加链路表示traceId
skywalking使用traceId对调用链路进行标识traceId的格式为随机字符如果没有请求链路则输出日志中的traceId为N/A。如果以羊肉串类比多个羊肉被同一个棍子串起来羊肉就类比为链路上的多个服务棍子就类比为traceId。
修改logback.xml日志配置文件 在日志的输出格式定义中添加%tid并修改对应的Layout实现类为TraceIdPatternLogbackLayout。 ?xml version1.0 encodingUTF-8?
configuration!-- 日志输出格式 --property namelog.patternvalue%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%tid]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)/!-- 控制台输出 --appender nameconsole classch.qos.logback.core.ConsoleAppenderencoder classch.qos.logback.core.encoder.LayoutWrappingEncoderlayout classorg.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayoutPattern${log.pattern}/Pattern/layout/encoder/appenderroot levelinfoappender-ref refconsole//root
/configuration没有请求链路的系统日志 当我们向接口发送请求时 请求如下 日志如下从输出的日志可以看到该请求的调用链为8012端口的商品服务调用8021端口的订单服务8021端口的订单服务调用8032端口的支付服务在该调用链上各个服务的traceId相同。 进入skywalking服务端的页面我们查看该调用链路该链路的traceId与日志中打印的traceId一致。
2. 添加链路上下文
由于traceId仅表示为随机字符可读性较差。幸运的是skywalking也认识到这一点于是又引入了一个新的概念链路上下文SW_CTX所谓链路上下文其实与traceId的作用相同但他的好处是可读性强其格式为SW_CTX[服务名, 实例名, traceId, traceSegmentId, spanId]。
同样的如果没有请求链路则输出日志中的链路上下文为SW_CTX[服务名, 实例名, N/A, N/A, -1]。
修改logback.xml日志配置文件 将日志的输出格式定义中表示traceId的%tid修改为%sw_ctx即可 ?xml version1.0 encodingUTF-8?
configuration!-- 日志输出格式 --property namelog.patternvalue%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%sw_ctx]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)/!-- 控制台输出 --appender nameconsole classch.qos.logback.core.ConsoleAppenderencoder classch.qos.logback.core.encoder.LayoutWrappingEncoderlayout classorg.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayoutPattern${log.pattern}/Pattern/layout/encoder/appenderroot levelinfoappender-ref refconsole//root
/configuration重启项目查看没有请求链路的系统日志 当我们向接口发送请求时 请求如下 日志如下由于打印出的上下文日志包含信息量过长只截取其部分日志。 进入skywalking服务端的页面我们查看该调用链路该调用链路同样是商品服务的8011端口服务调用订单服务的8022端口服务且该调用链的traceId与日志中打印的traceId一致。
3. 异步日志
skywalking客户端还支持日志的异步打印就是说业务代码与日志打印采用不同的线程执行提高接口响应速度。
修改logback.xml日志配置文件
?xml version1.0 encodingUTF-8?
configuration!-- 日志输出格式 --property namelog.patternvalue%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%tid]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)/!-- 控制台输出 --appender nameconsole classch.qos.logback.core.ConsoleAppenderencoder classch.qos.logback.core.encoder.LayoutWrappingEncoderlayout classorg.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayoutPattern${log.pattern}/Pattern/layout/encoder/appender!-- 异步输出 --appender nameconsole-async classch.qos.logback.classic.AsyncAppenderdiscardingThreshold0/discardingThresholdqueueSize1024/queueSizeneverBlocktrue/neverBlockappender-ref refconsole//appenderroot levelinfoappender-ref refconsole-async//root
/configuration四、收集链路日志
skywalking客户端通过gRpc将输出的日志发送给skywalking服务端skywalking服务端根据traceId去分析日志然后通过skywalking服务端页面可以查看指定调用链路中所有服务所输出的日志。 修改logback.xml日志配置文件只需要添加GRPCLogClientAppender即可 ?xml version1.0 encodingUTF-8?
configuration!-- 日志输出格式 --property namelog.patternvalue%black(%contextName-) %red(%d{yyyy-MM-dd HH:mm:ss}) %green([%thread]) %boldMagenta([%tid]) %highlight(%-5level) %boldMagenta(%logger{36}) - %gray(%msg%n)/!-- 控制台输出 --appender nameconsole classch.qos.logback.core.ConsoleAppenderencoder classch.qos.logback.core.encoder.LayoutWrappingEncoderlayout classorg.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayoutPattern${log.pattern}/Pattern/layout/encoder/appender!-- 异步输出 --appender nameconsole-async classch.qos.logback.classic.AsyncAppenderdiscardingThreshold0/discardingThresholdqueueSize1024/queueSizeneverBlocktrue/neverBlockappender-ref refconsole//appender!-- 使用gRpc将日志发送到skywalking服务端 --appender namegrpc-log classorg.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppenderencoder classch.qos.logback.core.encoder.LayoutWrappingEncoderlayout classorg.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayoutPattern${log.pattern}/Pattern/layout/encoder/appenderroot levelinfoappender-ref refconsole-async/appender-ref refgrpc-log//root
/configuration重启项目并向接口发送请求 查看输出的日志 进入skywalking页面查看 查看该调用链路上各服务的日志我们以商品服务的日志为例在调用链路中电击商品服务可查看对应的实例详情再点击相关的日志即可查看商品服务该实例所产生的日志列表该列表中每一行即为代码中打印的一行日志点击可查看该行完整的日志信息。 到这里skywalking的日志收集我们就介绍完了。 纸上得来终觉浅绝知此事要躬行。
————————我是万万岁我们下期再见————————
