目录
三、Apache Skywalking特点和整体架构组件介绍
四.Apache SkyWalking环境安装实战和界面指标讲解
4.1 Skywalking部署实战之ElasticSearch7.X
4.2 Skywalking部署实战之OapServer和UI界面安装
4.3 Apache Skywalking常见概念和指标说明
4.4 Skywalking RocketBot整体界面的介绍(上)
4.4.4 展示栏（Instance服务维度，不过对于监控CPU、内存等，Promethus 是个更好的选择）
4.5 Skywalking RocketBot整体界面的介绍(下)
本篇简单介绍SkyWalking是什么，特点和整体架构组成，使用docker安装部署，页面指标项的介绍
具体SkyWalking和Springboot整合、告警推送见以下2篇博文
Springboot整合分布式链路追踪SkyWalking之探针使用和链路采集实战(二)_这是王姑娘的微博的博客-CSDN博客本篇主要展示SkyWalking和Springboot项目的整合以及探针链路采集展示
https://blog.csdn.net/wnn654321/article/details/128594365分布式链路追踪SkyWalking进阶实战之RPC上报和WebHook通知(三)_这是王姑娘的微博的博客-CSDN博客本篇主要介绍SkyWalking性能剖析，慢业务代码定位以及通知告警https://blog.csdn.net/wnn654321/article/details/128594388
一、先抛几个分布式常见的问题
服务调用链出现了问题怎么快速排查？
服务调用链路耗时长怎么定位是哪个服务？
链路追踪系统的背景：
分布式应用架构虽然满足了应用横向扩展的需求，但是运维和诊断的过程变得越来越复杂，例如会遇到接口诊断困难、应用性能诊断复杂、架构分析复杂等难题，传统的监控工具并无法满足，分布式链路系统由此诞生
核心：将一次请求分布式调用，使用GPS定位串起来，记录每个调用的耗时、性能等日志，并通过可视化工具展示出来
二、分布式链路追踪Skywalking介绍
2.1 Skywalking是什么
skywalkings是一款国产的开源框架，在2015年开源使用，在2017年的时候加入了Apache孵化器
skywalking是分布式应用程序的性能监控工具，专门是为了微服务（spring cloud）、云原生架构与容器架构（docker/k8s）而设计的是一款APM工具，它具有分布式追踪、性能指标分析、应用和服务依赖分析等功能
官网：http://skywalking.apache.org/
下载：http://skywalking.apache.org/downloads/
Github：https://github.com/apache/skywalking
官方文档：https://skywalking.apache.org/docs/main/v8.5.0/readme/
中文文档：https://skyapm.github.io/document-cn-translation-of-skywalking/
2.2 市场上同类解决方案
Zipkin是由Twitter开源的链路分析分析工具，在springcloud sleuth得到了广泛的使用，具有轻量，部署简单的特点
Pinpoint是由韩国人开发的链路追踪应用监控分析工具，基于字节码方式注入。具有支持多种插件，UI功能强大，接入端没有代码侵入
Skywalking是由国人开发的链路追踪应用监控分析工具，基于字节码方式注入。具有支持多种插件，UI功能强大，接入端没有代码侵入，现已加入Apache孵化器
CAT是大众点评开源的链路追踪分析工具，具有对应用监控的分析、日志的采集、监控报警一系列的监控平台
2.3 skywalking的性能对比
在下面的图标中可以清晰的看到skywalking在各项当中，是比较好的
三、Apache Skywalking特点和整体架构组件介绍
3.1 Skywalking特点
具有多种监控手段，可以通过语言探针来获取监控数据
具有多种语言的自动探针。它包括了Java、.net、node.js等
清晰的模块化，UI、存储、集群管理都有许多种机制供选择
支持告警，具有优秀的可视化解决方案
可以在多种环境下运行，例如：像注册中心，Eureka和RPC框架springcloud dubbo
3.2 Skywalking整体架构
可以分为：上、下、左、右四个部分
上部分（skywalking-agent）：这一部分负责从应用程序中收集链路信息，然后把链路信息发送给skywalking OAP处理器
下部分（skywalking OAP）：负责接收从skywalking-agent发送过来的Tracing数据信息，然后把数据信息给Analysis Core进行分析，把分析到的数据存储到外部的存储器当中，最后面把数据信息给Query Core提供查询数据的功能
左部分（Skywalking UI）:负责给用户查看链路等信息
3.3 部署组件介绍
数据存储（H2/mysql/ElasticSearch(本博文数据放在es中)）
Skywalking-OAP-Server
Skywalking UI
Skywalking-Agent（项目引入）
四.Apache SkyWalking环境安装实战和界面指标讲解
4.1 Skywalking部署实战之ElasticSearch7.X
docker容器化部署-单节点:
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 wnn_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
访问验证:http://112.xx.xx.xxx:9200/_cat/nodes?v=true&prettyDemo:
docker ps -a 查看启动的容器
访问验证:
4.2 Skywalking部署实战之OapServer和UI界面安装
Skywalking-OAP-Server安装
--安装oap
docker run --name wnn_oap --restart always -d -e TZ=Asia/Shanghai -p
12800:12800 -p 11800:11800 --link wnn_es7 -e SW_STORAGE=elasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODES=wnn_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:wnn_es7也可改为es服务器部署的Ip地址，比如ip:9200Demo:
然后继续进行 Skywalking-UI的安装
--安装ui
docker run -d --name wnn_skywalking-ui \
--restart=always \
-e TZ=Asia/Shanghai \
-p 8080:8080 \
--link wnn_oap \
-e SW_OAP_ADDRESS=wnn_oap:12800 \
apache/skywalking-ui:8.5.0
--link <name or id>:alias ，添加到另一个容器的链接.此处的UI需要连接OAP，所以名称需要和OAP的对应上Demo:
SkyWalking UI界面访问地址 ip:8080
查看ElasticSearch全部索引
http://112.74.xx.xxx:9200/_cat/indices?v=true&pretty
出现这些索引表明UI和OAP和ES是串联起来的~
4.3 Apache Skywalking常见概念和指标说明
服务(Service) 比如订单微服务
实例(Instance) 比如 机器一:192.168.1.12
端点(Endpoint) 比如订单微服务对外提供的接口 /api/v1/order/add，就是端点
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以内
4.4 Skywalking RocketBot整体界面的介绍(上)
4.4.1 Skywalking ui控制栏
仪表盘：查看被监控服务的运行状态
拓扑图：以拓扑图的方式展现服务的关系
追踪：以接口的列表方式展现
性能剖析：对端点进行采样分析
日志：可查看服务日志
告警：触发告警的告警列表，包括了服务的失败率，超时等待
4.4.2 展示栏（Global全局维度）
Global、Service、Instance、Endpoint不同展示面板
Services load：服务每分钟请求数
Slow Services：慢响应服务，单位ms
Un-Health services(Apdex): Apdex性能指标，1为满分
Slow Endpoint：慢响应端点，单位ms
Global Response Latency：百分比响应延时，不同百分比的延时时间，单位ms
Global Heatmap：服务响应时间热力分布图，根据时间段内不同响应时间的数量显示颜色深度；
底部栏：展示数据的时间区间，点击可以调整
4.4.3 展示栏（Service服务维度）
Service Apdex（数字）:当前服务的评分
Service Apdex（折线图）：不同时间的Apdex评分
Service Avg Response Times：平均响应延时，单位ms
Service Response Time Percentile：百分比响应延时
Successful Rate（数字）：请求成功率
Successful Rate（折线图）：不同时间的请求成功率
Servce Load（数字）：每分钟请求数
Servce Load（折线图）：不同时间的每分钟请求数
Servce Instances Load：每个服务实例的每分钟请求数
4.4.4 展示栏（Instance服务维度，不过对于监控CPU、内存等，Promethus 是个更好的选择）
Service instance load：当前实例的每分钟请求数
Service Instance Successful Rate：当前实例的请求成功率
Service Instance Latency：当前实例的响应延时
JVM CPU：jvm占用CPU的百分比
JVM Memory：JVM内存占用大小，单位m
JVM GC Time：JVM垃圾回收时间，包含YGC和OGC
JVM GC Count：JVM垃圾回收次数，包含YGC和OGC
JVM Thread Count：JVM线程数
4.4.展示栏（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：当前端点每个时间段的请求成功率
4.5 Skywalking RocketBot整体界面的介绍(下)
拓扑图：
通过拓扑图可以发现服务调用的链路，比如下图 用户请求-->Wnnshop服务-->mysql服务
追踪：
左侧：接口列表，请求为红色表示异常，蓝色表示正常
右侧：追踪列表，api的各个连接点按照端点的先后顺序和时间排序 可以看到每个步骤的耗时
性能剖析
新建任务：新建需要分析的端点
左侧列表：对任务进行采样
右侧：每个端点的链路信息
新建任务后开始请求接口，然后等待几秒刷新性能剖析列表，就会出来接口对应的分析结果
扫一扫
988
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
