【云原生系列之SkyWalking的部署】

1、分布式链路追踪

1.1概念

在较大的web集群和微服务环境中，客户端的一次请求需要经过不同的模块，多个不同中间件，多个不同机器一起相互协作才能处理完成客户端的请求，而在这一系列的请求过程之中,处理流程可能是串行执行,也可能是并行执行.那么如何确定客户端的一次请求到结束背后究竟调用了哪些应用以及哪些模块并经过了哪些节点,并且每个模块的调用先后顺序是怎么样的,每个模块的处理响应性能如何?后期随着业务系统的不断增多,业务处理逻辑会越来越复杂,而分布式系统中急需要一套链路追踪(Trace)系统来解决这个问题,从而让运维人员对整个业务系统一目了然,了如指掌。
分布式服务追踪系统是整个分布式系统中跟踪一个用户请求的完整过程，包括数据采集，数据传输，数据存储，数据分析和数据可视化，获取并存储和分享此类追踪可以让运维清晰了解用户请求与业务系统交互背后的整个调用关系，链路追踪是针对调试和监控微服务不可或缺的帮手
Dapper是Google 2008年开始内部使用的链路追踪系统。

1.2 Dapper采集

1.2.1 分布式追踪方法

下图中展现的是一个有5台服务器相关的一个服务，包括：前端（A），两个中间层（B和C），以及两个后端（D和E）。
当一个用户（这个用例的发起人）发起一个请求时，首先到达前端（A），然后发送两个RPC到服务器B和C，B收到请求后会马上做出响应，但是C需要和后端的D和E交互之后再返还给A，由A来响应最初的客户请求，对于这样一个请求，简单实用的分布式跟踪的实现，就是为服务器上每一次发送和接收动作来收集跟踪标识符(message identifiers)和时间戳(timestamped events)。

1. 黑盒法（black-box)

   无需任何侵入代码，它的优势在于无需修改代码，缺点在于记录不精确，且需要大量的数据才能推导出服务间的关系
   

2. 标记法(annotation-based)

   需要为每个请求打标记，并通过一个全局标识符将请求途径的所有服务信息串联，复盘整个链路，标记法记录准备，但缺点是需要将标记代码注入到每个服务中
   

Span代表系统中具有开始时间和执行时长的请求跨度,span之间通过嵌入或者顺序排列建立逻辑因果关系.
任何一个Span可以包含来自不同的主机信息,这些也要记录下来.事实上每一个RPC Span可以包含客户端和服务器两个过程注释.由于客户端和服务器上的时间戳来自不同主机,还必须考虑到时间偏差,在分析工具就利用了时间偏差,即RPC客户端发送一个请求之后服务端才能收到,对应响应也是一样的.这样一来服务器的RPC就有一个时间戳的一个开始和结束,然后就计算出时间消耗.

RPC是远程调用的意思

1.2.2 Dapper跟踪记录和收集管道的过程

1. span数据写入本地日志文件中
2. Dapper守护进程和收集组件把这些数据从生产环境的主机中进行读取
3. 最终写入Dapper的数据仓库中

一个跟踪被设计成Bigtable中的一行，每一列相关于Span Bigtable的支持稀疏表格布局正适合这种情况，因为每一次跟踪可以有任意多个spac

1.2.3 Dapper的特点

1. Dapper资源占用很小
2. Dapper守护进程CPU使用率从来没超过0.3%单核CPU。而且只有少量的内存使用，另外还限制了Dapper守护进程内核scheduler最低的优先级，以防在一台高负载的服务器上发生cpu竞争。一个span在仓库传输中占用平均426byte

1.2.4 Dapper应用场景

1. 性能分析：对请求延迟的目标进行跟踪，并对容易优化的地方进行定位
2. 正确性分析：发现一些只读器请求，应该是访问从库但却访问了主库等类似业务场景
3. 理解系统：全局优化系统，理解每个查询的整体代价
4. 测试新版本：发现新版本的bug和性能问题
5. 解决依赖关系：找到服务之间的依赖关系

1.3APM的特点

APM系统（Application Performance Management）性能管理系统

早起APM功能主要在监控CPU,内存,IO,网络等资源上
微服务兴起后,系统功能被模块化,再加上k8s与容器化的兴起及应用数据量的爆炸式增长,各模块和服务之间的调用链路,响应时间,负载等越来越不好通过传统的工具进行监控和统计,此时APM系统诞生了.

2、skywalking

2.1特点

1. 实现从请求跟踪，指标收集和日志记录的完整信息记录
2. 多语言自动探针，支持java,go,python,php,nodejs,Lua,Rust等客户端
3. 内置服务器网络可观察性，支持从Istio+Envoy Service Mesh收集和分析数据
4. 模块化架构，存储，集群管理，使用插件集合都可以进行自由选择
5. 支持告警
6. 优秀的可视化效果

2.2 Skywalking组件

OAP平台(Observability Analysis Platform,可观测性分析平台)或OAP Server,它是一个高度组件化的轻量级分析程序,由兼容各种探针Receiver,流式分析内核和查询内核三部分构成.

探针：基于无侵入式的收集，并通过HTTP或者gRPC方式发送数据到OAP Server

存储实现(Sotrage Implementors)：SkyWalking OAP Server支持多种存储实现并提供了标准接口，可支持不同的存储后端

UI模块：Skywalking通过标准的GraphQL协议进行统计数据查询和展示

面相协议设计：面相协议设计时Skywalking从5.x开始严格遵守的首要设计原则，组件之间使用标准协议进行数据交互

2.3SkyWalking协议

2.3.1探针协议:

探针上报协议: 协议包括语言探针的注册,Metrics数据上报,Tracing数据上报等标准,Java,Go等探针都需要严格遵守此协议的标准.

探针交互协议:因为分布式追踪环境,探针间需要借助HTTP Header,MQ Header在应用之间进行通信和交互,探针交互协议就定义了交互的数据格式

Service Mesh 协议: 是SkyWalking对Service Mesh抽象的专有协议,任何Mesh类的服务都可以通过此协议直接上传指标数据,用于计算服务的指标数据和绘制拓扑图.

第三方协议: 对大型的第三方开源项目尤其是Service Mesh核心平台Istio和Envoy,提供核心协议适配,支持针对Istio+Envoy Service Mesh进行无缝对接.

2.3.2查询协议:

元数据查询: 查询在skywalking注册的服务,服务实例,Endpoint等元数据信息.

拓扑关系查询: 查询全局,或单个服务,Endpoint的拓扑图及依赖关系.

Metrics指标查询:区间范围均值查询及Top N排名查询等.

Trace查询: 追踪数据的明细查询.

告警查询: 基于表达式,判断指标数据是否超出阈值.

2.4 Skywalking模块

1、探针负责收集数据
2、前端负责展示数据
3、OAP Server负责从后端存储读写数据
4、后端存储负责持久化数据

2.5SkyWalking优势

1. 兼容性好: 支持传统的分布式部署架构dubbo和spring cloud,也支持云原生中的Istio和Envoy
2. 易于部署和后期维护:组件化,可自定义部署,后期横向扩容简单.
3. 高性能:每天数T的数据无压力
4. 易于二次开发:标准的http和grpc协议,开源的项目,企业可以自主二次开发.

2、SkyWalked部署

由于是测试环境，这里的es就不做集群了

2.1创建目录并下载安装包

1、安装java环境
apt install openjdk-11-jdk -y
root@sk:/apps/apache-skywalking-apm-bin/config# java --version
openjdk 11.0.24 2024-07-16
OpenJDK Runtime Environment (build 11.0.24+8-post-Ubuntu-1ubuntu320.04)
OpenJDK 64-Bit Server VM (build 11.0.24+8-post-Ubuntu-1ubuntu320.04, mixed mode, sharing)

2、下载SkyWalk安装包
mkdir /apps && cd /apps
wget https://dlcdn.apache.org/skywalking/9.2.0/apache-skywalking-apm-9.2.0.tar.gz
tar xf apache-skywalking-apm-9.2.0.tar.gz

2.2 修改配置文件

root@sk:/apps/apache-skywalking-apm-bin/config# pwd
/apps/apache-skywalking-apm-bin/config
#修改133行和136行,指定elasticsearch为数据库及elasticsearch的集群地址
root@sk:/apps/apache-skywalking-apm-bin/config# vim application.yml
storage:
  selector: ${SW_STORAGE:elasticsearch}
  elasticsearch:
    namespace: ${SW_NAMESPACE:""}
    ## 单机ES
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:172.17.1.61:9200}
    ## ES集群多个ip用逗号,分割
    ## clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:172.17.1.61:9200,172.17.1.62:9200,172.17.1.63:9200}

#其他几个重要的参数
#存储最多7天的内容，过期数据将会清理。因此请根据实际需求进行调整 
recordDataTTL: ${SW_STORAGE_ES_RECORD_DATA_TTL:7} # Unit is day 
# 每10秒刷新数据到收集器中
flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10}
# 提供2个并发请求，如果系统业务量大，日志产生的非常快，请根据实况调整
concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2}

2.3 配置SkyWaing启动文件

root@sk:~# cat /etc/systemd/system/skywalking.service
[Unit]
Description=Apache Skywalking
After=network.target
[Service]
Type=oneshot
User=root
WorkingDirectory=/apps/apache-skywalking-apm-bin/bin
ExecStart=/bin/bash /apps/apache-skywalking-apm-bin/bin/startup.sh
RemainAfterExit=yes
RestartSec=5
[Install]
WantedBy=multi-user.target

root@sk:~# systemctl daemon-reload
root@sk:~# systemctl restart skywalking.service

2.4 验证

服务起来后es上应该会自动创建skywalking所需要的库

root@sk:~# ss -ntl|grep 8080
LISTEN  0        4096                   *:8080                 *:*
root@sk:~# ss -ntl|grep 11800
LISTEN  0        4096                   *:11800                *:*
root@sk:~# ss -ntl|grep 12800
LISTEN  0        4096                   *:12800                *:*

2.5 报错

原因：es库的地址配错了，提示库不存在，无法自动创建

解决方案：修改为正确的es库IP

原因：es库的地址配错了，提示库不存在，无法自动创建

解决方案：修改为正确的es库IP