- 1. 介绍
- 1.1 SkyWalking是什么
- 1.2 链路追踪框架对比
- 1.3 性能对比
- 1.4 Skywalking主要功能特性
- 2 环境部署
- 2.1 下载
- 2.2 安装文件目录结果
- 2.3 搭建Skywalking OAP服务
- 2.4 SkyWalking中三个概念
- 3.SkyWalking接入微服务
- 3.1 linux环境—通过jar包方式接入
- 3.2 windos环境—在IDEA中使用Skywalking
- 3.3 Skywalking跨多个微服务跟踪
- 4. Skywalking持久化跟踪数据
- 4.1基于mysql持久化:
- 5 自定义SkyWalking链路追踪
- 5.1 @Trace将方法加入追踪链路
- 5.2加入@Tags或@Tag
- 6 性能分析
- 7 Skywalking集成日志框架
- 8 Skywalking告警功能
- 8.1 告警功能简介
- 9 Skywalking高可用
SkyWalking：一个APM（应用程序性能监视器）系统，专门为微服务，云原生和基于容器（Docker，Kubernetes，Mesos）的体系结构而设计。
SkyWalking是一个开源APM系统，包括对Cloud Native体系结构中的分布式系统的监视，跟踪，诊断功能。核心功能如下：
- 服务，服务实例，端点指标分析
- 根本原因分析。在运行时分析代码。阅读Apache SkyWalking：使用分析来修复分布式跟踪的盲点。
- 服务拓扑图分析
- 服务，服务实例和端点依赖关系分析
- 检测到慢速服务和端点
- 性能优化
- 分布式跟踪和上下文传播
- 数据库访问指标。检测慢速数据库访问语句（包括SQL语句）。
- 报警
skywalking是一个国产开源框架，2015年由吴晟开源，2017年加入Apache孵化器。skywalking是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器(Docker、K8s、Mesos）架构而设计。它是一款优秀的APM(Application Perfomance Management)工具，包括了分布式追踪、性能指标分析、应用和服务依赖分析等。
官网
下载
文档
中文文档
- Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。
- Pinpoit是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
- skywalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，U功能较强，接入端无代码侵入。目前已加入Apache孵化器。
- CAT是大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。
skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中Pinpoint的探针对吞吐量的影响。
1.4 Skywalking主要功能特性- 多种监控手段，可以通过语言探针和service mesh获得监控的数据;
- 支持多种语言自动探针，包括Java，.NET Core和Node.JS;
- 轻量高效，无需大数据平台和大量的服务器资源;
- 模块化，UI、存储、集群管理都有多种机制可选;
- 支持告警;
- 优秀的可视化解决方案;
- skywalking agent和业务系统绑定在一起，负责收集各种监控数据
- Skywalking oapservice是负责处理监控数据的，比如接受skywalking agent的监控数据,并存储在数据库中;接受skywalking webapp的前端请求，从数据库查询数据，并返回数据给前端。Skywalking oapservice通常以集群的形式存在
- skywalking webapp，前端界面，用于展示数据
- 用于存储监控数据的数据库，比如mysql、elasticsearch等。
- 下载
- 安装的时候一定要注意安装文件夹不能有空格，否则不能启动。
- 若出现启动错误可以查看日志分析：logs/skywalking-oap-server
目录结构
- web app: Ul前端(web 监控页面)的jar包和配置文件;
- oap-libs:后台应用的jar包，以及它的依赖jar包，里边有一个server-starter-*.jar就是启动程序;
- config:启动后台应用程序的配置文件，是使用的各种配置
- bin:各种启动脚本，一般使用脚本startup.*来启动web页面和对应的后台应用;
- oapService.:默认使用的后台程序的启动脚本;(使用的是默认模式启动，还支持其他模式，各模式区别见启动模式). oapServicelnit.:使用init模式启动;在此模式下，OAP服务器启动以执行初始化工作,
然后退出 - oapServiceNoInit.*:使用no init模式启动;在此模式下，OAP服务器不进行初始化。
- webappService.*: UI前端的启动脚本;
- startup.*:组合脚本，同时启动oapService.*脚本;webappService.*脚本;
- oapService.:默认使用的后台程序的启动脚本;(使用的是默认模式启动，还支持其他模式，各模式区别见启动模式). oapServicelnit.:使用init模式启动;在此模式下，OAP服务器启动以执行初始化工作,
- agent:
- skywalking-agent.jar:代理服务jar包. config:代理服务启动时使用的配置文件
- plugins:包含多个插件，代理服务启动时会加载改目录下的所有插件（实际是各种jar包)
- optional-plugins:可选插件，当需要支持某种功能时，比如SpringCloud Gateway，则需要把对应的jar包拷贝到plugins目录下(默认不包含Gateway)；
- 启动脚本bin/startup.sh
- 日志存储在logs目录
- 启动成功后会启动两个服务，一个是skywalking-oap-server，一个是skywalking-web-ui : localhost:8080
skywalking-oap-server服务启动后会暴露11800和12800两个端口，分别为收集监控数据的端口11800和接受前端请求的端口12800。 - 修改端口可以修改config/applicaiton.yml
- skywalking-web-ui服务会占用8080端口，修改端口可以修改webapp/webapp.yml
- server.port: SkyWalking UI服务端口，默认是8080;
- collector.ribbon.listOfServers:SkyWalking OAP服务地址数组，SkyWalking UI界面的数据是通过请求SkyWalking OAP服务来获得;
- 服务(Service): 表示对请求提供相同行为的一系列或一组工作负载，在使用Agent时，可以定义服务的名字;
- 服务实例(Service Instance): 上述的一组工作负载中的每一个工作负载称为一个实例，一个服务实例实际就是操作系统上的一个真实进程;
- 端点(Endpoint): 对于特定服务所接收的请求路径,如HTTP的URI路径和gRPC服务的类名＋方法签名;
- 准备一个spingboot程序，打成可执行jar包，写一个shell脚本，在启动项目的Shel脚本上，通过-javaagent参数进行配置SkyWalking Agent来跟踪微服务;
- startup.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/local/soft/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar java $JAVA_AGENT -jar springboot-skywalking-demo-0.0.1-SNAPSHOT.jar #jar启动3.2 windos环境—在IDEA中使用Skywalking
在运行的程序配置jvm参数，如下图所示:
# skywalking-agent.jar的本地磁盘的路径 -javaagent:D:apacheapache-skywalking-apm-es7-8.4.0apache-skywalking-apm-bin-es7agentskywalking-agent.jar #在skywalking上显示的服务名 -DSW_AGENT_NAME=springboot-skywalking-demo # skywalking的collector服务的IP及端口 -DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
注意: 跟踪链路不显示gateway
拷贝agent/optional-plugins目录下的gateway插件到agent/plugins目录
- Skywalking跨多个微服务跟踪，只需要每个微服务启动时添加javaagent参数即可。
- 测试:
启动微服务mall-gateway,mall-order，mall-user，配置skywalking的jvm参数http://localhost:8888/user/findOrderByUserld/1
默认使用的H2数据库存储，configlapplication.yml
1.修改config目录下的application.yml，使用mysql作为持久化存储的仓库
2.修改mysql连接配置
3. 注意oap-libs内没有MySql驱动
需要自行复制MySql驱动jar包到该目录。
如果我们希望对项目中的业务方法，实现链路追踪，方便我们排查问题，可以使用如下的代码引入依赖:
< ! -- Skywalking工具类,和服务版本一致-->5.1 @Trace将方法加入追踪链路org.apache.skywalking apm-toolkit-trace 8.5.0
如果一个业务方法想在ui界面的跟踪链路上显示出来，只需要在业务方法上加上@Trace注解即可
我们还可以为追踪链路增加其他额外的信息，比如记录参数和返回信息。实现方式:在方法上增加@Tag或者@Tags。
@Tag注解中key =方法名，value = returnedObj表示返回值，arg[0]表示参数
skywalking的性能分析，在根据服务名称、端点名称，以及相应的规则建立了任务列表后，在调用了此任务列表的端点后。sky walking会自动记录，剖析当前端口，生成剖析结果。
1.logback官方配置
2.log4j官方配置
3.log4j2j官方配置引入依赖
这里主要介绍logback的使用
- 引入依赖
org.apache.skywalking apm-toolkit-logback-1.x 8.5.0
- 引入logback配置文件,并加入[%tid]来记录链路id
logback INFO ${CONSOLE_LOG_PATTERN} UTF-8 ${log.path}/log_info.log %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n UTF-8 ${log.path}/info/log-info-%d{yyyy-MM-dd}.%i.log 100MB 15 INFO ACCEPT DENY ${log.path}/log_warn.log %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n UTF-8 ${log.path}/warn/log-warn-%d{yyyy-MM-dd}.%i.log 100MB 15 warn ACCEPT DENY ${log.path}/log_error.log %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n UTF-8 ${log.path}/error/log-error-%d{yyyy-MM-dd}.%i.log 100MB 15 ERROR ACCEPT DENY %d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%n
- 引入gRPC reporter
%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%n
- 配置skyworking,若Skyworking不在本地
在agient/config进行配置
- Skywalking每隔一段时间根据收集到的链路追踪的数据和配置的告警规则（如服务响应时间、服务响应 时间百分比）等，判断如果达到阈值则发送相应的告警信息。
- 发送告警信息是通过调用webhook接口完成，具体的webhook接口可以使用者自行定义，从而开发者可以在指定的webhook接口中编写各种告 警方式，比如邮件、短信等。
- 告警的信息也可以在RocketBot中查看到。
文件定义了默认的4种告警规则
- 最近3分钟内服务的平均响应时间超过1秒
- 最近2分钟服务成功率低于80%
- 最近3分钟90%服务响应时间超过1秒
- 最近2分钟内服务实例的平均响应时间超过1秒 规则中的参数属性如下
以下是默认的告警规则配置，位于skywalking安装目录下的config文件夹下 alarm-settings.yml文件 中：
rules:
# Rule unique name, must be ended with `_rule`.
service_resp_time_rule:
metrics-name: service_resp_time #oal脚本中的度量名称
op: ">" # 比较操作符，可以设定>,<,=
threshold: 1000 #阈值，与metrics-name和比较符号相匹配
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/
9 Skywalking高可用
在大多数生产环境中，后端应用需要支持高吞吐量并且支持高可用来保证服务的稳定，所以你始终需要在生产环境进行集群管理。
Skywalking集群是将skywalking oap作为一个服务注册到nacos上，只要skywalking oap服务没有全部宕机，保证有一个skywalking oap在运行，就能进行跟踪。
- 搭建一个skywalking oap集群需要:
(1)至少一个Nacos (也可以是nacos集群)
(2)至少一个ElasticSearch/mysql(也可以是es/msql集群)
(3)至少2个skywalking oap服务;
(4)至少1个UI(UI也可以集群多个，用Nginx代理统一入口)
