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/

调用链选型

  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主要功能特性

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

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 – 命令行界面

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

SkyWalking 环境搭建部署

在这里插入图片描述

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

下载 SkyWalking

下载：http://skywalking.apache.org/downloads/
在这里插入图片描述
目录结构

tree -d -L 1
.
├── agent
├── bin
├── config
├── config-examples
├── licenses
├── logs
├── oap-libs
├── tools
└── webapp

9 directories

挑几个重要目录说明下

  • agent
    • skywalking-agent.jar：代理agent的 jar包
    • config：代理服务启动时使用的配置文件
    • plugins：包含多个插件，代理服务启动时会加载该目录下所有的插件（实际是各种jar包）
    • optional-plugins：可选插件，当需要支持某种功能时，比如SpringCloud Gateway，则需要把对应的jar包拷贝到该目录下。
  • bin：各种启动脚本
    • oapService.*：后台程序的启动脚本
    • oapServiceInit.*：使用init模式启动，OAP服务器初始化，然后在退出
    • oapServiceNoInit.*：使用no init模式启动，在此模式下，OAP服务器不进行初始化
    • startup.*：组合脚本
    • webappService.*：UI前端的启动脚本。
  • config：后台服务的配置文件
  • oap-libs：后台应用的jar包以及依赖的jar包
  • webapp：UI前端页面的jar包和配置文件

搭建SkyWalking OAP 服务

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

vim config/application.yml

在这里插入图片描述
启动脚本

bin/startup.sh

日志信息存储在logs目录
在这里插入图片描述
启动成功后会启动两个服务，
一个是skywalking-oap-server，
一个是skywalking-web-ui
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服务来获得；

访问：http://IP:8080/
在这里插入图片描述
页面的右下角可以中英文切换，可以切换选择要展示的时间区间的跟踪数据。

SkyWalking中三个概念

  • 服务(Service) ：表示对请求提供相同行为的一系列或一组工作负载，在使用Agent时，可以定义服务的名字；
  • 服务实例(Service Instance) ：上述的一组工作负载中的每一个工作负载称为一个实例， 一个服务实例实际就是操作系 统上的一个真实进程
  • 端点(Endpoint) ：对于特定服务所接收的请求路径, 如HTTP的URI路径和gRPC服务的类名 + 方法签名；
    在这里插入图片描述

SkyWalking快速开始

SkyWalking Agent跟踪微服务

通过jar包方式接入

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

#!/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:/opt/apache-skywalking-apm-bin/agent/skywalking‐agent.jar 
java $JAVA_AGENT ‐jar springboot‐skywalking‐demo‐0.0.1‐SNAPSHOT.jar #启动jar包

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

java ‐javaagent:/opt/apache-skywalking-apm-bin/agent/skywalking‐agent.jar‐DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 ‐DSW_AGENT_NAME=springboot‐skywalking‐demo ‐jar springboot‐skywalking‐demo‐0.0.1‐SNAPSHOT.jar

参数名对应 agent/config/agent.config 配置文件中的属性。

# The service name in UI
agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}

# Backend service addresses.
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}

属性对应的源码：org.apache.skywalking.apm.agent.core.conf.Config.java

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

‐javaagent:/opt/apache-skywalking-apm-bin/agent/skywalking‐agent.jar‐Dskywalking.agent.service_name=springboot‐skywalking‐demo ‐Dskywalking.collector.backend_service=127.0.0.1:11800

测试启动程序的url： http://IP:8000/user/list
在启动程序前加一个-javaagent 参数即可完成对程序的跟踪
在这里插入图片描述

在IDEA中使用Skywalking

在运行的程序配置jvm参数，如下图所示：
在这里插入图片描述
Skywalking跨多个微服务跟踪，只需要每个微服务启动时添加javaagent参数即可。

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
    只要我们的服务请求符合alarm-setting.yml文件中的某一条规则就会触发告警。
    比如service_resp_time_rule规则：
    在这里插入图片描述
    该规则表示服务的响应时间在最近10分钟的3分钟内超过1000ms 则告警；
    告警规则配置项的说明：
  • Rule name：规则名称，也是在告警信息中显示的唯一名称。必须以_rule结尾，前缀可自定义
  • OP： 操作符，目前支持 >、<、=
  • Period：多久告警规则需要被核实一下。这是一个时间窗口，与后端部署环境时间相匹配
  • Count：在一个Period窗口中，如果values超过Threshold值（按op），达到Count值，需要发送警报
  • Silence period：在时间N中触发报警后，在TN -> TN + period这个阶段不告警。 默认情况下，它和Period一样，这意味着相同的告警（在同一个Metrics name拥有相同的Id）在同一个Period内只会触发一次
  • message：告警消息

测试一下，编写接口，模拟慢查询：

@RequestMapping("/info/{id}") 
public User info(@PathVariable("id") Integer id){ 

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

return  userService.getById(id);
}

回调接口

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

在config/alarm-settings.yml中配置回调接口，并重启skywalking服务
在这里插入图片描述
测试访问：http://localhost:8000/user/info/1，满足告警规则后，SkyWalking UI显示告警信息
在这里插入图片描述
参考： https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md 对接钉钉
在这里插入图片描述
Webhook回调通知
Webhook可以简单理解为是一种Web层面的回调机制，通常由一些事件触发，与代码中的事件回调类似，只不过是Web层面的。由于是Web层面的，所以当事件发生时，回调的不再是代码中的方法或函数，而是服务接口。例如，在告警这个场景，告警就是一个事件。当该事件发生时，SkyWalking就会主动去调用一个配置好的接口，该接口就是所谓的Webhook。
SkyWalking的告警消息会通过 HTTP 请求进行发送，请求方法为 POST，Content-Type 为 application/json，其JSON 数据实基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage进行序列化的。JSON数据示例：

[{
    "scopeId": 1,
    "scope": "SERVICE",
    "name": "serviceA",
    "id0": 12,
    "id1": 0,
    "ruleName": "service_resp_time_rule",
    "alarmMessage": "alarmMessage xxxx",
    "startTime": 1560524171000
}, {
    "scopeId": 1,
    "scope": "SERVICE",
    "name": "serviceB",
    "id0": 23,
    "id1": 0,
    "ruleName": "service_resp_time_rule",
    "alarmMessage": "alarmMessage yyy",
    "startTime": 1560524171000
}]

字段说明：

  • scopeId、scope：所有可用的 Scope 详见 org.apache.skywalking.oap.server.core.source.DefaultScopeDefine
  • name：目标 Scope 的实体名称
  • id0：Scope 实体的 ID
  • id1：保留字段，目前暂未使用
  • ruleName：告警规则名称
  • alarmMessage：告警消息内容
  • startTime：告警时间，格式为时间戳

Skywalking持久化跟踪数据

基于mysql持久化

  1. 修改config目录下的application.yml，使用mysql作为持久化存储的仓库
  2. 修改mysql连接配置
    在这里插入图片描述
    在这里插入图片描述
#配置数据库连接地址 
jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://1ocalhost:3306/swtest"} 
#用户名 
dataSource.user: ${SW_DATA_SOURCE_USER:root} 
#密码 
dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root}

注意：需要添加mysql数据驱动包，因为在lib目录下是没有mysql数据驱动包的，所以修改完配置启动是会报错，启动失败的。驱动包可从mysql官网网站下载
在这里插入图片描述
启动Skywalking，可以查看数据库表，可以看到生成了很多表。
说明启动成功了，打开配置对应的地址http://IP:8080/，可以看到skywalking的web界面。
测试：重启skywalking，验证跟踪数据会不会丢失
在这里插入图片描述

基于elasticsearch持久化

准备好elasticsearch环境 启动elasticsearch服务 1

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

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

自定义SkyWalking链路追踪

如果我们希望对项目中的业务方法，实现链路追踪，方便我们排查问题，可以使用如下的代码 引入依赖

<!‐‐ 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
在这里插入图片描述
在这里插入图片描述

@Trace将方法加入追踪链路

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

加入@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集成日志框架

log4j官方配置
log4j2j官方配置
Spirngboot+Logback集成Skywalking日志系统

引入依赖
<dependency>
            <groupId>org.apache.skywalking</groupId>
            <artifactId>apm-toolkit-logback-1.x</artifactId>
            <version>8.4.0</version>
        </dependency>

添加logback-spring.xml文件，并配置 %tid 占位符在这里插入图片描述
在这里插入图片描述
Skywalking通过grpc上报日志 （需要v8.4.0） gRPC报告程序可以将收集到的日志转发到SkyWalking OAP服务器上
logback-spring.xml中添加

<!‐‐ v8.4.0提供 ‐‐>
 <appender name="grpc‐log" class="org.apache.skywalking.apm.too
 <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.3.100} 
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}

以上配置是默认配置信息,agent与oap在本地的可以不配
agent配置信息大全

Skywalking UI效果
在这里插入图片描述

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代理统一入口）

修改config/application.yml文件
使用nacos作为注册中心
在这里插入图片描述
修改nacos配置
在这里插入图片描述
修改存储策略，使用elasticsearch7作为storage
在这里插入图片描述
在这里插入图片描述
配置ui服务webapp.yml文件的listOfServers，写两个地址
在这里插入图片描述
启动服务测试，启动Skywalking服务，指定应用的jvm参数

 skywalking.collector.backend_service=192.168.3.10:11800,192.168.3.12:11800
# 微服务 # apache # skywalking
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes