skywalking 分布式链路追踪

最新推荐文章于 2024-08-04 16:43:53 发布

sl_w

最新推荐文章于 2024-08-04 16:43:53 发布

阅读量1.1k

点赞数 16

文章标签： skywalking 分布式

本文链接：https://blog.csdn.net/Stitch12/article/details/135553326

版权

一、介绍

Skywalking是什么
- skywalkings是一款国产的开源框架，在2015年开源使用，在2017年的时候加入了Apache孵化器
- skywalking是分布式应用程序的性能监控工具，专门是为了微服务（spring cloud）、云原生架构与容器架构（docker/k8s）而设计的
- 是一款APM工具，它具有分布式追踪、性能指标分析、应用和服务依赖分析等功能
- 官网：Apache SkyWalking
- 下载：Downloads | Apache SkyWalking
- Github：GitHub - apache/skywalking: APM, Application Performance Monitoring System
- 官方文档：https://skywalking.apache.org/docs/main/v8.5.0/readme/
- 中文文档：SkyWalking 文档中文版（社区提供）
市场上同类解决方案
- Zipkin是由Twitter开源的链路分析分析工具，在springcloud sleuth得到了广泛的使用，具有轻量，部署简单的特点
- Pinpoint是由韩国人开发的链路追踪应用监控分析工具，基于字节码方式注入。具有支持多种插件，UI功能强大，接入端没有代码侵入
- Skywalking是由国人开发的链路追踪应用监控分析工具，基于字节码方式注入。具有支持多种插件，UI功能强大，接入端没有代码侵入，现已加入Apache孵化器
- CAT是大众点评开源的链路追踪分析工具，具有对应用监控的分析、日志的采集、监控报警一系列的监控平台

Skywalking特点
- 具有多种监控手段，可以通过语言探针来获取监控数据
  - 具有多种语言的自动探针。它包括了Java、.net、node.js等
  - 具有轻量有高效的特点，不占用大量的服务器资源
  - 清晰的模块化，UI、存储、集群管理都有许多种机制供选择
  - 支持告警，具有优秀的可视化解决方案
  - 可以在多种环境下运行，例如：像注册中心，Eureka和RPC框架springcloud dubbo
Skywalking整体架构
- 可以分为：上、下、左、右四个部分
- 上部分（skywalking-agent）：这一部分负责从应用程序中收集链路信息，然后把链路信息发送给skywalking OAP处理器
- 下部分（skywalking OAp）：负责接收从skywalking-agent发送过来的Tracing数据信息，然后把数据信息给Analysis Core进行分析，把分析到的数据存储到外部的存储器当中，最后面把数据信息给Query Core提供查询数据的功能
- 左部分（Skywalking UI）:负责给用户查看链路等信息

部署组件介绍
- 数据存储（H2/mysql/ElasticSearch）
- Skywalking-OAP-Server
- Skywalking UI
- Skywalking-Agent（项目引入）

二、部署

数据存储ElasticSearch 7.6.2部署

mkdir -p /mydata/es/config
mkdir -p /mydata/es/data
chmod 777 -R /mydata/es
echo "http.host: 0.0.0.0" >> /mydata/es/config/elasticsearch.yml

#启动运行
docker run -d --name es7 -p 9200:9200 -p 9300:9300 \
  -e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms128m -Xmx128m" \
  -v /mydata/es/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \
  -v /mydata/es/data:/usr/share/elasticsearch/data \
  -v /mydata/es/plugins:/usr/share/elasticsearch/plugins elasticsearch:7.6.2

#参数说明
#-e "discovery.type=single-node" 设置为单节点
#-e ES_JAVA_OPTS="-Xms128m -Xmx128m" 设置ES的初始内存和最大内存，否则过大启动不了ES

#注意：这时候会提示权限不够需要开启权限：chmod 777 -R /mydata/es
     #登录http://ip:9200/_cat/nodes?v=true&pretty
     #记得开放网络安全组 9200 9300

Skywalking部署

docker部署

Skywalking-OAP-Server部署

#--安装oap
docker run --name skywalking-oap --restart always -d -e TZ=Asia/Shanghai -p 12800:12800 -p 11800:11800 --link es7 -e SW_STORAGE=elasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODES=es7:9200 apache/skywalking-oap-server:8.5.0-es7

#参数：
#--link <name or id>:alias ，添加到另一个容器的链接，可以添加别名或者不加

#–link后面的参数和elasticsearch容器名一致;

#SW_STORAGE=elasticsearch7 是固定的，使用es7;

#SW_STORAGE_ES_CLUSTER_NODES：es7也可改为es服务器部署的Ip地址，比如ip:9200

Skywalking-UI安装

#--安装ui
docker run -d --name skywalking-ui \
--restart=always \
-e TZ=Asia/Shanghai \
-p 8080:8080 \
--link xd_oap \
-e SW_OAP_ADDRESS=xd_oap:12800 \
apache/skywalking-ui:8.5.0

#SkyWalking UI界面访问地址 ip:8080

源码部署

config配置文件 application.yml配置修改

本地部署SkyWalking

方式一：直接启动（ui和oap）
```
#源码bin目录下
bin/startup.sh
```

方式二：分别依次启动

#端口 11800
bin/oapService.sh

#端口8080
bin/webappService.sh

查看日志

#oap日志
skywalking-oap-server.log
#ui界面日志
webapp.log

访问
- ip:8080

三、skywalking常见概念、ui界面、Skywalking-Agent 探针介绍

常见概念

服务(Service)
- 比如商品微服务
实例(Instance)
- 比如机器1（192.12.41.4）
端点(Endpoint)
- 比如商品微服务对外提供的接口 /api/v1/product/list，就是端点
用户的满意程度 Service Apdex
- 全称 Application Performance Index，最大值就是 1，是一个不断优化的方向
- 分3个指标，T 值代表着用户对应用性能满意的响应时间界限或者说是“门槛”，假如T是0.5秒
  - 满意：这样的响应时间让用户感到很愉快，响应时间少于 T 秒钟； 0.5秒内
  - 容忍：慢了一点，但还可以接受，继续这一应用过程，响应时间 T～4T 秒； 0.5~2秒内
  - 失望：太慢了，受不了了，用户决定放弃这个应用，响应时间超过 4T 秒；多于2秒

SLA

服务等级协议，全称：service level agreement，为保障服务的性能和可用性，
9越多代表全年服务可用时间越长服务更可靠，停机时间越短

1年 = 365天 = 8760小时

99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时

99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

从以上看来，全年停机5.26分钟才能做到99.999%，即5个9

CPM
- 全称 call per minutes，是吞吐量(Throughput)指标，每分钟请求调用的次数
RT
- Response Time 表示请求响应时间，对于人来说，响应时间最好不要超过2秒
Percent Response 百分位数统计
- 表示采集样本中某些值的占比，Skywalking 有 “p50、p75、p90、p95、p99” 一些列值
- 比如 “p99:360” 表示 99% 请求的响应时间在360ms以内

ui界面介绍

展示栏（Instance服务维度，不过对于监控CPU、内存等，Promethus 是个更好的选择）

Skywalking-Agent探针

什么SkyWalking探针
- 探针表示集成到目标系统中的代理或 SDK 库,即收集并格式化数据, 并发送到后端包括链路追踪和性能指标
Skywalking-Agent的安装和使用
- 下载skywalking
  - 地址：Downloads | Apache SkyWalking

skywalking-agen目录文件的介绍
- logs：skywalking agent的相关运行日志
- bootstrap-plugins：插件包
- optional-plugins：插件包（可供选择的插件包，如果需要生效则需要拷贝到plugins包下）
- plugins：插件包（生效的插件包，支持多个框架链路追踪）
- optional-reporter-plugins：插件包
- activations：插件包
- config: 配置文件
- skywalking-agent.jar：agent代理的jar包（主要是这个！）

skywalking-agent的使用方式

优先级：探针-> JVM配置-> 环境变量配置 -> agent.config（优先级低）

第一种-javaagent:/path/to/skywalking-agent.jar={config1}={value1},{config2}={value2}

#- agent.service_name：客户端服务名，在apm系统中显示的服务名称
#- collector.backend_service：SW上传的服务地址
-javaagent:../skywalking-agent.jar=agent.service_name=customName,collector.backend_service=127.0.0.1:11800

第二种：-Dskywalking.[option1]=[value2]

#- agent.service_name：客户端服务名，在apm系统中显示的服务名称
#- collector.backend_service：SW上传的服务地址
-javaagent: ../skywalking-agent.jar -Dskywalking.agent.service_name=customName -Dskywalking.collector.backend_service=127.0.0.1:11800

四、springboot整合skywalking

整合skywalking链路追踪

#- agent.service_name：客户端服务名，在apm系统中显示的服务名称
#- collector.backend_service：SW上传的服务地址
-javaagent: ../skywalking-agent.jar -Dskywalking.agent.service_name=customName -Dskywalking.collector.backend_service=127.0.0.1:11800

直接在启动时 JVM配置
- 优点是无侵入性
- 缺点是只能看到简单得节点耗时信息，不能明确到各个方法层

自定义 SkyWalking链路追踪配置实战

什么是TraceId
- 用来标识一条请求链路，一条请求链路中包含一个Trace ID，多个Span ID
背景
- 对业务代码进行链路追踪，方便排查问题
- 比如，某个接口请求耗时慢，想对业务接口方法进行追踪
- controller->service 方法，记录业务方法加入到链路中，记录入参、返回值等

编码

添加依赖

<dependency>
            <groupId>org.apache.skywalking</groupId>
            <artifactId>apm-toolkit-trace</artifactId>
            <version>8.5.0</version>
</dependency>

业务方法添加注解
- @Trace

记录入参和返回值

POJO记得重写toString方法

#第一个入参就是arg[0],第二个就是arg[1],以此类推
#返回参数 returnedObj 固定写法
@Tags(
	{@Tag(key = "方法名-input", value = "arg[0]"), 
	@Tag(key = "方法名-output", value = "returnedObj")
	}
)

缺点
- 代码有侵入性

SkyWalking链路追踪-日志和RPC上报实战

背景
- 用户请求接口，怎么在我们日志中找到traceId来跟踪系统调用链路
- 需要在系统日志打印出traceId
- 注意（重要）
  - 由于阿里云选择的的服务器和带宽不高，安装了多个组件 oap、ui、es7等
  - 所以测试的时候有时数据有延迟、或者服务器压力过高，有时数据出不来，刷新页面几次才出来数据
  - 如果本地有docker环境和机器配置高，也可以本地进行安装skywalking相关组件
  - 后续也有源码安装

整合

添加依赖

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

配置logback打印日志并上传（SpringBoot默认使用Logback），配置文件名 logback.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>　　
    <!-- 控制台输出 -->
    <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>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
            </layout>
        </encoder>
    </appender>

<!-- skywalking grpc 日志收集上报服务端 8.4.0版本后支持 -->
    <appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
            </layout>
        </encoder>
    </appender>

    <!--系统操作日志-->
    <root level="INFO">　　
        <appender-ref ref="console"/>　
        <appender-ref ref="grpc-log"/>
    </root>
</configuration>

注意

skywaling agent 默认是上传到本地的oap，如果oap server地址不是本地，则需要单独配置oap server地址

agent文件夹里面config配置

#日志数据的grpc服务器的主机
plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:120.79.150.146} 
#日志数据的grpc服务器的端口
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=${SW_GRPC_LOG_SERVER_HOST:120.79.150.146}
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}

SkyWalking链路追踪-告警模块和WebHook

功能
- 监控业务相关接口性能，超过阈值则触发告警功能
- 通过调用webhook接口进行触发，具体的webhook接口地址可以自行定义路径
  - 注意：要OAP Server的网络可以触发的webhook接口
- 开发人员可以在webhook接口中编写告警方式，比如邮件、短信等，就是一个http接口

Apache Skywalking默认的告警规则配置
- 安装目录下的conﬁg文件夹下 alarm-settings.yml文件
- 默认内置多个规则
  - 最近3分钟内服务的平均响应时间超过1秒
  - 最近2分钟服务成功率低于80%
  - 最近3分钟90%服务响应时间超过1秒
  - 最近2分钟内服务实例的平均响应时间超过1秒
- 配置讲解
  - metrics-name 脚本中的度量名称
  - threshold 阈值
  - op 比较操作符，可以设定>,<,=
  - period 多久检查一次当前的指标数据是否符合告警规则，单位分钟
  - count 达到多少次后，触发告警消息
  - silence-period 在多久时间之内，忽略相同的告警消息，在时间T触发了某告警，那么在(T+10)这个时间段，不会再次触发相同告警
  - message 告警消息内容
  - webhooks 配置告警产生时的触发的调用地址，配置之后一定要重启
    
    alarm-settings.yml
编码

//实体类 接收警告参数
public class AlarmMessage  {
    private int scopeId;
    private String scope;
    private String name;
    private String id0;
    private String id1;
    private String ruleName;
    private String alarmMessage;
    private long startTime;
    private transient int period;
    private transient boolean onlyAsCondition;
    
    //set get方法
}


@RestController
public class CallbackController {

    private List<AlarmMessage> messageList = new ArrayList<>();

    //接收接口
    @PostMapping("/webhook")
    public void  webhook(@RequestBody List<AlarmMessage> alarmMessageList){
        System.out.println("收到消息:" +alarmMessageList);
        messageList = alarmMessageList;
    }

    @GetMapping("/show")
    public List<AlarmMessage> show(){
        return messageList;
    }
}

sl_w

关注

16
点赞
踩
20

收藏

觉得还不错? 一键收藏
0
评论
skywalking 分布式链路追踪

服务(Service)比如商品微服务实例(Instance)比如机器1（192.12.41.4）端点(Endpoint)比如商品微服务对外提供的接口 /api/v1/product/list，就是端点用户的满意程度 Service Apdex全称 Application Performance Index，最大值就是 1，是一个不断优化的方向分3个指标，T 值代表着用户对应用性能满意的响应时间界限或者说是“门槛”，假如T是0.5秒。
复制链接

扫一扫