微服务链路追踪组件Skywalking实战 & 持久化配置 & 高可用部署

背景:微服务中存在的问题

对于一个大型的几十个、几百个微服务构成的微服务架构系统,通常会遇到下面一些问题,比如:

1、如何串联整个调用链路,快速定位问题?
2、如何理清各个微服务之间的依赖关系?
3、如何进行各个微服务接口的性能分折?
4、如何跟踪整个业务流程的调用处理顺序?

在这里插入图片描述

调用链产品选型

1、Zipkin是Twitter开源的调用链分析工具,目前基于springcloud sleuth得到了广泛的使用,特点是轻量,使用部署简单。

2、Pinpoint是韩国人开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能强大,接入端无代码侵入。

3、SkyWalking是本土开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器。

4、CAT是大众点评开源的基于编码和配置的调用链分析,应用监控分析,日志采集,监控报警等一系列的监控平台工具。

在这里插入图片描述

探针性能对比

模拟了三种并发用户:500,750,1000。使用jmeter测试,每个线程发送30个请求,设置思考时间为10ms。使用的采样率为1,即100%,这边与生产可能有差别。pinpoint默认的采样率为20,即50%,通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来,一共有12种。下面看下汇总表:

在这里插入图片描述
从上表可以看出,在三种链路监控组件中,skywalking的探针对吞吐量的影响最小,zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显,在500并发用户时,测试服务的吞吐量从1385降低到774,影响很大。然后再看下CPU和memory的影响,在内部服务器进行的压测,对CPU和memory的影响都差不多在10%之内。

一、skywalking是什么

skywalking是一个国产开源框架,2015年由吴晟开源 , 2017年加入Apache孵化器。skywalking是分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8s、Mesos)架构而设计。SkyWalking 是观察性分析平台和应用性能管理系统,提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

官网:http://skywalking.apache.org/
下载:http://skywalking.apache.org/downloads/
Github:https://github.com/apache/skywalking
文档: https://skywalking.apache.org/docs/main/v8.4.0/readme/
中文文档: https://skyapm.github.io/document-cn-translation-of-skywalking/
版本: v8.3.0 升级到v8.4.0

谁在使用Skywalking

1.1 Skywalking主要功能特性

1、多种监控手段,可以通过语言探针和service mesh获得监控的数据;
2、支持多种语言自动探针,包括 Java,.NET Core 和 Node.JS;
3、轻量高效,无需大数据平台和大量的服务器资源;
4、模块化,UI、存储、集群管理都有多种机制可选;
5、支持告警;
6、优秀的可视化解决方案;

1.2 Skywalking整体架构

在这里插入图片描述
整个架构分成四部分:
1、上部分Agent :负责从应用中,收集链路信息,发送给 SkyWalking OAP 服务器;

2、下部分 SkyWalking OAP :负责接收Agent发送的Tracing数据信息,然后进行分析(Analysis Core),存储到外部存储器(Storage),最终提供查询(Query)功能;

3、右部分Storage:Tracing数据存储,目前支持ES、MySQL、Sharding Sphere、TiDB、H2多种存储器,目前采用较多的是ES,主要考虑是SkyWalking开发团队自己的生产环境采用ES为主;

4、左部分SkyWalking UI:负责提供控制台,查看链路等等;

SkyWalking支持三种探针:

  • Agent – 基于ByteBuddy字节码增强技术实现,通过jvm的agent参数加载,并在程序启动时拦截指定的方法来收集数据。
  • SDK – 程序中显式调用SkyWalking提供的SDK来收集数据,对应用有侵入。
  • Service Mesh – 通过Service mesh的网络代理来收集数据。

后端(Backend):
接受探针发送过来的数据,进行度量分析,调用链分析和存储。后端主要分为两部分:

  • OAP(Observability Analysis Platform)- 进行度量分析和调用链分析的后端平台,并支持将数据存储到各种数据库中,如:ElasticSearch,MySQL,InfluxDB等。
  • OAL(Observability Analysis Language)- 用来进行度量分析的DSL,类似于SQL,用于查询度量分析结果和警报。

界面(UI):

  • RocketBot UI – SkyWalking 7.0.0 的默认web UI
  • CLI – 命令行界面

这三个模块的交互流程:
在这里插入图片描述

1.3 SkyWalking 环境搭建部署

在这里插入图片描述

  • skywalking agent和业务系统绑定在一起,负责收集各种监控数据。
  • Skywalking oapservice是负责处理监控数据的,比如接受skywalking agent的监控数据,并存储在数据库中;接受skywalking webapp的前端请求,从数据库查询数据,并返回数据给前端。Skywalking oapservice通常以集群的形式存在。
  • skywalking webapp,前端界面,用于展示数据。
  • 用于存储监控数据的数据库,比如mysql、elasticsearch等。

1.3.1 下载 SkyWalking

下载:http://skywalking.apache.org/downloads/

注意下载版本,要支持ES7。

在这里插入图片描述
下载完成后上传到linux服务器上并解压:
在这里插入图片描述

目录结构:
在这里插入图片描述

1.3.2 搭建SkyWalking OAP 服务

先使用默认的H2数据库存储,不用修改配置。

config/application.yml:
在这里插入图片描述
启动脚本bin/startup.sh(这个脚本会同时启动oap和UI程序,也可根据需要单独启动)
在这里插入图片描述
日志信息存储在logs目录:
在这里插入图片描述
启动成功后会启动两个服务,一个是skywalking-oap-server,一个是skywalking-web-ui

skywalking-oap-server服务启动后会暴露11800 和 12800 两个端口,分别为收集监控数据的端口11800和接受前端请求的端口12800,修改端口可以修改config/applicaiton.yml。

tail -f logs/skywalking-oap-server.log 

在这里插入图片描述
skywalking-web-ui服务会占用 8080 端口, 修改端口可以修改webapp/webapp.yml
在这里插入图片描述

  • server.port:SkyWalking UI服务端口,默认是8080;
  • collector.ribbon.listOfServers:SkyWalking OAP服务地址数组,SkyWalking UI界面的数据是通过请求SkyWalking OAP服务来获得;

访问:http://192.168.131.172:8080/,默认端为8080:
在这里插入图片描述

页面的右下角可以中英文切换,可以切换选择要展示的时间区间的跟踪数据。

1.4 SkyWalking中三个概念

服务(Service) :表示对请求提供相同行为的一系列或一组工作负载,在使用Agent时,可以定义服务的名字;

服务实例(Service Instance) :上述的一组工作负载中的每一个工作负载称为一个实例, 一个服务实例实际就是操作系统上的一个真实进程;

端点(Endpoint) :对于特定服务所接收的请求路径, 如HTTP的URI路径和gRPC服务的类名 + 方法签名;

在这里插入图片描述

二、SkyWalking快速开始

2.1 SkyWalking Agent跟踪微服务

2.1.1 通过jar包方式接入

准备一个springboot程序,打成可执行jar包,写一个shell脚本,在启动项目的Shell脚本上,通过 -javaagent 参数进行配置SkyWalking Agent来跟踪微服务;

创建一个startup.sh脚本:

#!/bin/sh
# SkyWalking Agent配置
export SW_AGENT_NAME=springboot-skywalking-demo # Agent名字,一般使用`spring.application.name`
export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 # 配置 Collector 地址。
export SW_AGENT_SPAN_LIMIT=2000 #配置链路的最大Span数量,默认为 300。
export JAVA_AGENT=-javaagent:/usr/software/skywalking/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar
java $JAVA_AGENT -jar springboot-skywalking-demo-0.0.1-SNAPSHOT.jar #jar启动

启动日志:在这里插入图片描述
等同于:

java -javaagent:/usr/software/skywalking/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar 
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168131172:11800 
-DSW_AGENT_NAME=pringboot-skywalking-demo-0.0.1-SNAPSHOT.jar

注意,这个skywalking-agent.jar 在本地也是可以。

只需要在参数DSW_AGENT_COLLECTOR_BACKEND_SERVICES中制定远程服务上的skywalking服务地址和端口即可。

参数名对应agent/config/agent.config配置文件中的属性。
属性对应的源码:org.apache.skywalking.apm.agent.core.conf.Config.java

# The service name in UI
agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}
# Backend service addresses.
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.131.172:11800}

我们也可以使用skywalking.+配置文件中的配置名作为系统配置项来进行覆盖。 javaagent参数配置方式优先级更高。

-javaagent:/usr/software/skywalking/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar
-Dskywalking.agent.service_name=springboot-skywalking-demo
-Dskywalking.collector.backend_service=192.168.131.172:11800

测试: http://192.168.3.100:8000/user/list
在这里插入图片描述
查看skywalking界面,记得勾选自动刷新
在这里插入图片描述

在启动程序前加一个-javaagent 参数即可完成对程序的跟踪:
在这里插入图片描述

2.1.2 在IDEA中使用Skywalking(添加JVM参数)

为了方便演示,在我本机windows上也装一个skywalking。这里只会用到agent文件夹中的skywalking-agent.jar 。而我们的skywalking服务还是依然部署到远程服务器上即可。因为这个jar只是一个单纯的jar包,放在哪里都无所谓。
在这里插入图片描述
在这里插入图片描述
在运行的程序配置jvm参数,如下图所示:

# skywalking-agent.jar的本地磁盘的路径
-javaagent:D:\Tools-install\Skywalking\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
# 在skywalking上显示的服务名
-DSW_AGENT_NAME=springboot-skywalking-demo
# skywalking的collector服务的IP及端口
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.131.172:11800

在这里插入图片描述
启动微服务后测试:http://localhost:8000/user/list
因为此时用的是我windows本地的IDEA,我们只需要在-DSW_AGENT_COLLECTOR_BACKEND_SERVICES 参数中配置远程skywalking服务地址即可。
在这里插入图片描述
在这里插入图片描述

2.1.3 Skywalking跨多个微服务跟踪【常用】

Skywalking跨多个微服务跟踪,只需要每个微服务启动时添加javaagent参数即可。

测试:
启动微服务mall-gateway,mall-order,mall-user ,配置skywalking的jvm参数:

# mall-gateway
# skywalking-agent.jar的本地磁盘的路径
-javaagent:D:\Tools-install\Skywalking\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar 
# 在skywalking上显示的服务名
-DSW_AGENT_NAME=mall-gateway 
# skywalking的collector服务的IP及端口
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.131.172:11800

# mall-order
-javaagent:D:\Tools-install\Skywalking\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar 
-DSW_AGENT_NAME=mall-order 
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.131.172:11800

# mall-user
-javaagent:D:\Tools-install\Skywalking\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar 
-DSW_AGENT_NAME=mall-user 
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.131.172:11800

然后启动三个微服务:
在这里插入图片描述
通过网关测试:http://localhost:8888/user/findOrderByUserId/1
在这里插入图片描述
在这里插入图片描述
查看拓扑图:
在这里插入图片描述
查看调用链路:
在这里插入图片描述
发现BUG:此处存在bug,跟踪链路不显示gateway。

【重点Bug】解决链路不显示gateway的bug

因为skywalking的/agent/plugins目录下没有找到apm-spring-cloud-gateway相关的jar。

拷贝agent/optional-plugins目录下的gateway插件到agent/plugins目录( 注意操作的在JVM参数中配置的skywalking-agent.jar 所在的agent/optional-plugins包下的gateway的jar。我这里JVM中配置的是windows上的,所以应该操作windows本地的jar。):

如果JVM参数中指定的skywalking-agent.jar是在linux服务器上,按如下操作:

cp ./optional-plugins/apm-spring-cloud-gateway-2.1.x-plugin-8.4.0.jar ./plugins/

在这里插入图片描述
我们现在复制windows上的(因为我们指定的:-javaagent:D:\Tools-install\Skywalking\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar):

按照自己的gateway版本拷贝对应版本的jar。
在这里插入图片描述
在这里插入图片描述

然后我们重新启动skywalking和所有的微服务,再次测试:http://localhost:8888/user/findOrderByUserId/1
在这里插入图片描述
在这里插入图片描述

功能展示

拓扑图查看微服务关系

在这里插入图片描述

链路追踪在这里插入图片描述

可以切换成表格的形式来查看链路上每个API消耗的时间:
在这里插入图片描述
点击某个方法可以看到更具体的数据:
在这里插入图片描述

2.2 Skywalking告警通知

skywalking告警的核心由一组规则驱动,这些规则定义在config/alarm-settings.yml文件中,告警规则的定义分为三部分:

1、告警规则:它们定义了应该如何触发度量警报,应该考虑什么条件;
2、网络钩子(Webhook}:当警告触发时,哪些服务终端需要被通知;
3、gRPC钩子:远程gRPC方法的主机和端口,告警触发后调用;

为了方便,skywalking发行版中提供了默认的alarm-setting.yml文件,包括一些规则,每个规则有英文注释,可以根据注释得知每个规则的作用:

  • 在最近10分钟的3分钟内服务平均响应时间超过1000ms
  • 最近10分钟内,服务成功率在2分钟内低于80%
  • 服务实例的响应时间在过去10分钟的2分钟内超过1000ms
  • 数据库访问{name}的响应时间在过去10分钟的2分钟内超过1000ms

在这里插入图片描述

# Sample alarm rules.
rules:
  # Rule unique name, must be ended with `_rule`.
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 3
    silence-period: 5
    message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.
  service_sla_rule:
    # Metrics value need to be long, double or int
    metrics-name: service_sla
    op: "<"
    threshold: 8000
    # The length of time to evaluate the metrics
    period: 10
    # How many times after the metrics match the condition, will trigger alarm
    count: 2
    # How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.
    silence-period: 3
    message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes
  service_resp_time_percentile_rule:
    # Metrics value need to be long, double or int
    metrics-name: service_percentile
    op: ">"
    threshold: 1000,1000,1000,1000,1000
    period: 10
    count: 3
    silence-period: 5
    message: Percentile response time of service {name} alarm in 3 minutes of last 10 minutes, due to more than one condition of p50 > 1000, p75 > 1000, p90 > 1000, p95 > 1000, p99 > 1000
  service_instance_resp_time_rule:
    metrics-name: service_instance_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 2
    silence-period: 5
    message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes
  database_access_resp_time_rule:
    metrics-name: database_access_resp_time
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: Response time of database access {name} is more than 1000ms in 2 minutes of last 10 minutes
  endpoint_relation_resp_time_rule:
    metrics-name: endpoint_relation_resp_time
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: Response time of endpoint relation {name} is more than 1000ms in 2 minutes of last 10 minutes
#  Active endpoint related metrics alarm will cost more memory than service and service instance metrics alarm.
#  Because the number of endpoint is much more than service and instance.
#
#  endpoint_avg_rule:
#    metrics-name: endpoint_avg
#    op: ">"
#    threshold: 1000
#    period: 10
#    count: 2
#    silence-period: 5
#    message: Response time of endpoint {name} is more than 1000ms in 2 minutes of last 10 minutes

webhooks:
#  - http://127.0.0.1/notify/
#  - http://127.0.0.1/go-wechat/

只要我们的服务请求符合alarm-setting.yml文件中的某一条规则就会触发告警。

比如service_resp_time_rule规则:
在这里插入图片描述
该规则表示服务{name}的响应时间在最近10分钟的3分钟内超过1000ms;

测试:

编写接口,模拟慢查询:

@RequestMapping("/test/info/{id}")
    public Result<UserEntity> info(@PathVariable("id") Long id){

        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        UserEntity user = userService.getUserById(id);
        return Result.ok(user);
    }

回调接口:

@RequestMapping("/notify")
public String notify(@RequestBody Object obj){
    //TODO 告警信息,给技术负责人发短信,钉钉消息,邮件,微信通知等
    System.err.println(obj.toString());
    return "notify successfully";
}

注意回调接口接受的参数类型@RequestBody Object obj

config/alarm-settings.yml中配置回调接口,并重启skywalking服务:
在这里插入图片描述

注意,要确保服务器可以调用通配置的服务地址!

测试访问:http://192.168.131.1:8888/user/test/info/1:

满足告警规则后,控制台输出告警信息:
在这里插入图片描述

在这里插入图片描述

参考: https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md

对接钉钉:
在这里插入图片描述

2.3 Webhook回调通知

SkyWalking告警Webhook回调要求接收方是一个Web容器(比如tomcat服务),告警的消息会通过HTTP请求进行发送, 请求方法为POST, Content-Type为application/json, JSON格式基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage>的集合对象数据, 集合中的每个AlarmMessage包含以下信息:

1、scopeId. 所有可用的Scope,参考:org.apache.skywalking.oap.server.core.source.DefaultScopeDefine;
2、name. 目标 Scope 的实体名称;
3、id0. Scope 实体的 ID;
4、id1. 未使用;
5、ruleName. 在 alarm-settings.yml 中配置的规则名;
6、alarmMessage. 报警消息内容;
7、startTime. 告警时间, 位于当前时间与 UTC 1970/1/1 之间;

[{
	scopeId = 2,
	scope = SERVICE_INSTANCE,
	name = 98e1839 a6fdf48b0aedb0ecabb8ea5f7 @192 .168 .233 .1 of springboot - skywalking - demo,
	id0 = c3ByaW5nYm9vdC1za3l3YWxraW5nLWRlbW8 = .1 _OThlMTgzOWE2ZmRmNDhiMGFlZGIwZWNhYmI4ZWE1ZjdAMTkyLjE2OC4yMzMuMQ == ,
	id1 = ,
	ruleName = service_instance_resp_time_rule,
	alarmMessage = Response time of service instance 98e1839 a6fdf48b0aedb0ecabb8ea5f7 @192 .168 .233 .1 of springboot - skywalking - demo is more than 1000 ms in 2 minutes of last 10 minutes,
	startTime = 1613913565462
}, {
	scopeId = 6,
	scope = ENDPOINT_RELATION,
	name = User in User to / user / info / {
		id
	} in springboot - skywalking - demo,
	id0 = VXNlcg == .0 _VXNlcg == ,
	id1 = c3ByaW5nYm9vdC1za3l3YWxraW5nLWRlbW8 = .1 _L3VzZXIvaW5mby97aWR9,
	ruleName = endpoint_relation_resp_time_rule,
	alarmMessage = Response time of endpoint relation User in User to / user / info / {
		id
	} in springboot - skywalking - demo is more than 1000 ms in 2 minutes of last 10 minutes,
	startTime = 1613913565462
}]

三、Skywalking持久化跟踪数据

3.1 基于mysql持久化

1、修改config目录下的application.yml,使用mysql作为持久化存储的仓库
在这里插入图片描述
2、修改mysql连接配置在这里插入图片描述
记得创建对应的数据库!

storage:
  #选择使用mysql   默认使用h2,不会持久化,重启skyWalking之前的数据会丢失
  selector: ${SW_STORAGE:mysql}
  #使用mysql作为持久化存储的仓库
  mysql:
    properties:
      #数据库连接地址
      jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://1ocalhost:3306/swtest"}
      #用户名
      dataSource.user: ${SW_DATA_SOURCE_USER:root}
      #密码
      dataSource.password: ${SW_DATA_SOURCE_PASSWORD:123456}

注意需要添加mysql数据驱动包,因为在lib目录下是没有mysql数据驱动包的,所以修改完配置启动是会报错,启动失败的。

在这里插入图片描述
3、添加mysql数据驱动包到skywalking/oap-libs目录下(注意自己安装的mysql版本和驱动包要匹配,否则可能只会出现一部分的数据表造成持久化失败!

我的mysql版本是8.0.20,结果我引用了8.0.26,以为版本接近是可以的,并且持久化后也生成了如下截图的数据表:
在这里插入图片描述
在这里插入图片描述
但是结果发现持久化失败了!将jar包重新上传了8.0.20的之后重新启动skywalking,结果生成了如下的数据表:
在这里插入图片描述
可以看到,配置版本匹配后会生成非常多的数据表,这样才是正常的。

其实你jar包已经被包括到了skywalking/oap-libs,mysql是因为可能存在5.x或者8.x版本,所以留给使用者自己添加。其他软件类似。

4、启动Skywalking

说明启动成功了,打开配置对应的地址http://192.168.131.172:8080/,可以看到skywalking的web界面。
在这里插入图片描述

测试:重启skywalking(不调用微服务),验证跟踪数据会不会丢失:
在这里插入图片描述

3.3 基于elasticsearch持久化

1、准备好elasticsearch(7的版本,要注意ES和skywalking版本之间的匹配)环境

注意:不能使用root用户直接操作,否则后面如何切换为其他用户之后,就会没有权限。所以操作ES之前,最好新建一个用户。

启动elasticsearch服务:

su - es
cd /usr/local/soft/elasticsearch-7.6.1/
bin/elasticsearch -d

在这里插入图片描述
启动elasticsearch-head服务,访问http://192.168.3.100:9100

cd /usr/local/soft/elasticsearch-head/node_modules/grunt
nohup bin/grunt server &

在这里插入图片描述

2、修改config/application.yml配置文件:
在这里插入图片描述
修改elasticsearch7的连接配置
在这里插入图片描述
3、启动Skywalking服务
在这里插入图片描述
启动时会向elasticsearch中创建大量的index索引用于持久化数据,每天会产生一个新的索引文件。
测试:
启动应用程序,查看跟踪数据是否已经持久化到elasticsearch的索引中,然后重启skywalking,验证跟踪数据会不会丢失。
在这里插入图片描述

四、自定义SkyWalking链路追踪(业务方法追踪)

如果我们希望对项目中的业务方法,实现链路追踪(默认的是Controller中的方法),方便我们排查问题,可以使用如下的代码:

引入依赖:

<!-- SkyWalking 工具类 -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-trace</artifactId>
    <version>8.4.0</version>
</dependency>

在业务方法中可以TraceContext获取到traceId:

@RequestMapping("/list")
public List<User> list(){

    //TraceContext可以绑定key-value
    TraceContext.putCorrelation("name", "fox");
    Optional<String> op = TraceContext.getCorrelation("name");
    log.info("name = {} ", op.get());
    //获取跟踪的traceId
    String traceId = TraceContext.traceId();
    log.info("traceId = {} ", traceId);

    return userService.list();
}

测试 http://localhost:8000/user/list
在这里插入图片描述
在Skywalking UI中查询tranceId:
在这里插入图片描述

4.1 @Trace将方法加入追踪链路

如果一个业务方法想在ui界面的跟踪链路上显示出来,只需要在业务方法上加上@Trace注解即可:
在这里插入图片描述
测试:
在这里插入图片描述

4.2 加入@Tags@Tag

我们还可以为追踪链路增加其他额外的信息,比如记录参数和返回信息。实现方式:在方法上增加@Tag或者@Tags

@Trace
@Tag(key = "list", value = "returnedObj")
public List<User> list(){
    return userMapper.list();
}

@Trace
@Tags({@Tag(key = "param", value = "arg[0]"),
        @Tag(key = "user", value = "returnedObj")})
public User getById(Integer id){
    return userMapper.getById(id);
}

在这里插入图片描述

在这里插入图片描述

五、Skywalking集成日志框架

logback官方配置
log4j官方配置
log4j2j官方配置

引入依赖:

<!-- apm-toolkit-logback-1.x -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>8.4.0</version>
</dependency>

添加logback-spring.xml文件,并配置 %tid 占位符:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <!-- 引入 Spring Boot 默认的 logback XML 配置文件  -->
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

    <!-- 控制台 Appender -->
    <property name="CONSOLE_LOG_PATTERN" value="%clr(%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %tid %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>

    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <!-- 日志的格式化 -->
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <Pattern>${CONSOLE_LOG_PATTERN}</Pattern>
            </layout>
        </encoder>
    </appender>

    <!--Spring Boot 配置文件中,读取 spring.application.name 应用名 -->
    <springProperty name="applicationName" scope="context" source="spring.application.name" />

    <property name="FILE_LOG_PATTERN" value="%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}} ${LOG_LEVEL_PATTERN:-%5p} ${PID:- } %tid --- [%t] %-40.40logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>

    <!-- 日志文件的路径 -->
    <property name="LOG_FILE" value="/logs/${applicationName}.log"/>

    <!-- 日志文件 Appender -->
    <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}</file>
        <!--滚动策略,基于时间 + 大小的分包策略 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.%i.gz</fileNamePattern>
            <maxHistory>7</maxHistory>
            <maxFileSize>10MB</maxFileSize>
        </rollingPolicy>
        <!-- 日志的格式化 -->
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <Pattern>${FILE_LOG_PATTERN}</Pattern>
            </layout>
        </encoder>
    </appender>

    <!-- 设置 Appender -->
    <root level="INFO">
        <appender-ref ref="console"/>
        <appender-ref ref="file"/>
    </root>

</configuration>

在这里插入图片描述
测试:
在这里插入图片描述

Skywalking通过grpc上报日志 (需要v8.4.0)

gRPC报告程序可以将收集到的日志转发到SkyWalking OAP服务器上。

logback-spring.xml中添加:

<!-- v8.4.0提供 -->
<appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender"/>
<root level="info">
    <appender-ref ref="grpc-log" />
</root>

在这里插入图片描述
打开agent/config/agent.config配置文件,添加如下配置信息:

plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:192.168.131.172}
plugin.toolkit.log.grpc.reporter.server_port=${SW_GRPC_LOG_SERVER_PORT:11800}
plugin.toolkit.log.grpc.reporter.max_message_size=${SW_GRPC_LOG_MAX_MESSAGE_SIZE:10485760}
plugin.toolkit.log.grpc.reporter.upstream_timeout=${SW_GRPC_LOG_GRPC_UPSTREAM_TIMEOUT:30}
  • plugin.toolkit.log.grpc.reporter.server_host:skywalking的服务IP;
  • plugin.toolkit.log.grpc.reporter.server_port:skywalking的端口。

以上配置是默认配置信息,agent与oap在本地的可以不配。如果skywalking是在服务器上并且使用的skywalking-agent.jar在本地的话,则要修改本地的agent/config/agent.config文件。
在这里插入图片描述

在这里插入图片描述
agent配置信息大全

Skywalking UI效果:
在这里插入图片描述
此处日期格式存在问题
https://github.com/apache/skywalking-rocketbot-ui/pull/428
在这里插入图片描述

六、Skywalking集群部署

Skywalking集群是将skywalking oap作为一个服务注册到nacos上,只要skywalking oap服务没有全部宕机,保证有一个skywalking oap在运行,就能进行跟踪。

搭建一个skywalking oap集群需要:

(1)至少一个Nacos(也可以是nacos集群)
(2)至少一个ElasticSearch(也可以是es集群)
(3)至少2个skywalking oap服务;
(4)至少1个UI(UI也可以集群多个,用Nginx代理统一入口)

1、修改config/application.yml文件

使用nacos作为注册中心:
在这里插入图片描述
修改nacos配置:
在这里插入图片描述

可以选择性修改监听端口:
在这里插入图片描述
修改存储策略,使用elasticsearch7作为storage:
在这里插入图片描述
在这里插入图片描述
2、配置ui服务webapp.yml文件的listOfServers,写两个地址

在这里插入图片描述

3、启动服务测试
启动Skywalking服务,指定springboot应用的jvm参数:

-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.3.10:11800,192.168.3.12:11800
  • 1
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
Skywalking是一种用于微服务链路追踪的开源工具,它可以帮助开发人员分析和监控微服务架构中各个服务之间的调用关系和性能指标。 通过Skywalking,我们可以实现对微服务之间的调用链路进行追踪。它的工作原理是在每个微服务中嵌入一个Skywalking Agent,该Agent负责采集和发送调用链数据和指标信息到Skywalking Collector。 这些数据可以包括请求的来源、目标服务、请求的参数和响应时间等信息。通过收集和分析这些数据,我们可以了解到整个微服务架构中各个服务之间的调用关系和性能状况。 要实现微服务链路追踪,我们可以使用Zipkin或Skywalking这样的工具。这些工具提供了可视化界面,用于展示微服务之间的调用链路和性能指标。我们只需要在每个微服务中添加相应的Agent,并配置好Collector的地址,就可以开始进行链路追踪了。 总结起来,Skywalking是一种用于微服务链路追踪的工具,通过在每个微服务中嵌入Agent并将数据发送到Collector,可以帮助我们分析和监控微服务架构中各个服务之间的调用关系和性能指标。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* [分布式链路追踪原理详解及SkyWalking、Zipkin介绍](https://blog.csdn.net/weixin_38004638/article/details/115975798)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] - *3* [分布式链路追踪SkyWalking](https://blog.csdn.net/swimming_in_IT_/article/details/130250233)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值