skywalking性能监控，基本docker项目部署

前言

做性能测试的时候，一般工具只能监控到服务器资源使用情况，如果某个接口超时或报错了，无法追踪到具体超时或报错的原因，Skywalking可以更详细的跟踪接口调用链路，定位具体问题。

介绍

整体架构包含如下三个组成部分：

1. 探针(agent) 负责进行数据的收集，包含了 Tracing 和 Metrics 的数据，agent 会被安装到服务所在的服务器上，以方便数据的获取。
2. 可观测性分析平台 OAP(Observability Analysis Platform)，接收探针发送的数据，并在内存中使用分析引擎(Analysis Core)进行数据的整合运算，然后将数据存储到对应的存储介质上，比如 Elasticsearch、MySQL 数据库、H2 数据库等。同时 OAP 还使用查询引擎(Query Core)提供 HTTP 查询接口。
3. Skywalking提供单独的 UI进行数据的查看，此时 UI 会调用 OAP 提供的接口，获取对应的数据，然后进行展示。

部署

下载Skywalking的安装包

https://archive.apache.org/dist/skywalking/
以V8.2.0 非es版本为例，安装包分es版和非es版，区别在于存储的方式不同
解压后，修改agent\config\agent.config文件

然后，把agent文件夹一起全部打包进docker项目中

启动容器，为项目配置skywalking探针

docker run -d --name 容器名称 --net host -v /etc/localtime:/etc/localtime:ro  --restart=always -v /home/nfs-data/tiji-logs-pvc:/tiji/system/logs -e SPRING_PROFILES_ACTIVE=dev -e JAVA_OPTS="-Xmx512m -Xms512m"  xxx

-v /etc/localtime:/etc/localtime:ro 同步容器和宿主机时间
–restart=always 启动docker后自启
docker打包镜像方式不同，命令也会有差异
docker整合agent参考：https://blog.csdn.net/kingwinstar/article/details/115323617

linux部署监控平台

把skywalking安装包拷贝到linux,可修改/apache-skywalking-apm-bin-es7/webapp/webapp.yml文件，不必须

启动监控平台

bin/startup.sh

或者

bin/oapService.sh
bin/webappService.sh

输入ip:8080可访问监控平台

补充：11800 12800 两个默认端口都是OPA服务的端口，SkyWalking启动之后，会启动两个Java服务：skywalking-oap-server、skywalking-web-ui

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

Skywalking-Collector
​ 1. 追踪信息收集器，通过gRPC/Http收集客户端的采集信息。默认采用gRPC。
​ 2. gRPC默认端口11800，Http默认端口12800

UI管理端图形界面使用说明

仪表盘

Global

• Services Load：服务每分钟请求数

• Slow Services：慢响应服务，单位ms

• Un-Health Services (Apdex)：不健康服务

• Slow Endpoints：慢端点，单位ms

• Global Response Latency：百分比响应延时，不同百分比的延时时间，单位ms

• Global Heatmap：服务响应时间热力分布图，根据时间段内不同响应时间的数量显示颜色深度

Service

• Service Apdex（数字）：当前服务的评分

• Service Apdex（折线图）：不同时间的Apdex评分

• Service Avg Response Time：服务平均响应时间

• Successful Rate（数字）：请求成功率

• Successful Rate（折线图）：不同时间的请求成功率

• Service Response Time Percentile：百分比响应延时

• Service Load（数字）：每分钟请求数

• Servce Load（折线图）：不同时间的每分钟请求数

• Service Instances Load：每个服务实例的每分钟请求数

• Slow Service Instance：每个服务实例的最大延时

• Service Instance Successful Rate：每个服务实例的请求成功率

Instance

• Service Instance Load：当前实例的每分钟请求数

• Service Instance Throughput：实例吞吐量

• Service Instance Successful Rate：当前实例的请求成功率

• Service Instance Latency：当前实例的响应延时

• JVM CPU (Java Service)：jvm占用CPU的百分比

• JVM Memory (Java Service)：JVM内存占用大小，单位m

• JVM GC Time：JVM垃圾回收时间，包含YGC和OGC

• JVM GC Count：JVM垃圾回收次数，包含YGC和OGC

• JVM Thread Count (Java Service)：JVM线程数

• JVM Thread State Count (Java Service)

• JVM Class Count (Java Service)

EndPoint

• Endpoint Load in Current Service：每个端点的每分钟请求数

• Slow Endpoints in Current Service：每个端点的最慢请求时间，单位ms

• Successful Rate in Current Service：每个端点的请求成功率

• Endpoint Load：当前端点每个时间段的请求数据

• Endpoint Avg Response Time：当前端点每个时间段的请求行响应时间

• Endpoint Response Time Percentile：当前端点每个时间段的响应时间占比

• Endpoint Successful Rate：当前端点每个时间段的请求成功率

拓扑图

追踪

• 左侧：api接口列表，红色-异常请求，蓝色-正常请求；
• 右侧：api追踪列表，api请求连接各端点的先后顺序和时间；

性能剖析

日志

告警

后三个模块待补充