一、skywalking预览
1.1 skywalking 概述
Apache SkyWalking, 适用于分布式系统的应用程序性能监控工具,专为微服务、云原生和基于容器的 (Kubernetes) 架构而设计。官方地址: https://skywalking.apache.org/
- 适用于分布式系统的应用程序性能监控工具,
专为微服务、云原生和容器 (Kubernetes) 的架构而设计
- 多数互联网公司里面用的技术,
分布式架构下链路分析和性能定位最佳方案之一
- 微服务架构下,
链路性能和调用耗时分析
是至关重要环节,Skywalking是必杀技之一- 在多数互联网公司中,
Skywalking占有率很高
,是近几年大量流行
1.2 为什么需要链路追踪?
观察下列链路调用关系,思考一下.
- 服务调用链路出现了问题怎么快速排查?
- 服务调用链路耗时长怎么定位到是哪个服务?
分布式应用架构虽然满足了应用横向扩展的需求,但是运维和诊断的过程变得越来越复杂,例如会遇到接口诊断困难、应用性能诊断复杂、架构分析复杂等难题,传统的监控工具并无法满足,分布式链路系统由此诞生
.
1.3 APM系统
Application Performance Management 【应用程序性能管理】
, 简称APM系统
.APM系统是可以对帮助系统的行为做性能分析的工具.APM系统,它是由谷歌公开的论文提到的
,而到后面,许多的技术公司就基于这边论文的原理,开发出来很多出色的APM框架
,比如:skywalking、zipkin
等等.
skywalking
是一款国产的开源框架,在2015年开源使用,在2017年的时候加入了Apache孵化器.skywalking是分布式应用程序的性能监控工具,
专门是为了微服务(spring cloud)、云原生架构与容器架构(docker/k8s)而设计的.Skywalking
作为APM
工具,它具有分布式追踪、性能指标分析、应用和服务依赖分析等功能.
除了skywalking之外, Zipkin是由Twitter开源的链路分析分析工具
,在springcloud sleuth得到了广泛的使用,具有轻量,部署简单的特点, 在实际开发当中也有着较为广泛的应用. 此次我们主要学习skywalking的基本用法.
二、skywalking环境搭建、配置
2.1 skywalking特点
skywalking具有多种监控手段,可以通过语言探针来获取监控数据
.
- 具有多种语言的自动探针。它包括了Java、net、node等
- 具有轻量有高效的特点,不占用大量的服务器资源
- 清晰的模块化,UI、存储、集群管理都有许多种机制供选择
- 支持告警,具有优秀的可视化解决方案
- 可以在多种环境下运行,例如:像注册中心Eureka和RPC dubbo等
2.2 skywalking整体架构
- 注: 下图来源于官网
整个架构分库四个部分,上下左右,这里考虑到描述更加简单直观,所以舍弃掉了Mtrics
性能指标相关的东西,只关注Tracing
链路相关功能. - 相关概念
skywalking-agent:
主要负责从应用程序中收集链路信息,然后把链路信息发送给skywalking OAP处理
.OAP是指Observability Analysis Platform 即【可观测性分析平台】
skywalking OAP
: 负责接收从skywalking-agent
发送过来的Tracing
数据信息,然后把数据信息给Analysis Core
进行分析,把分析到的数据存储到外部的存储器当中,最后面把数据信息给Query Core
提供查询数据的功能.- skywalking ui:
负责给用户查看链路等信息.
- 上部分 Agent :负责从应用中,收集链路信息,发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是,SkyWalking Agent 收集 SkyWalking Tracing 数据,传递给服务器。
- 下部分 SkyWalking OAP :负责接收 Agent 发送的 Tracing 数据信息,然后进行分析(Analysis Core) ,存储到外部存储器( Storage ),最终提供查询( Query )功能。
- 右部分 Storage :Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。而我们目前采用的是 ES ,主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。
- 左部分 SkyWalking UI :负责提供控台,查看链路等等。
2.3 组件介绍
- 数据存储,可以使用
h2、mysql、es等
- skywalking-OAP-server, 安装到服务器
- skywalking ui
- skywalking-agent 【由项目引入】
相关操作环境为centos7
,也可以考虑使用虚拟机.
2.4 安装ES7
- centos7
- 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 rj_es7 -p 9200:9200 -p 9300:9300 \
-e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms256m -Xmx256m" \
-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启不来
安装成功之后,可以访问
http://your ip/_cat/nodes?v=true&pretty
2.5 安装skywalking-OAP-server
直接通过docker
安装即可,如下所示:
docker run --name rj_oap --restart always -d -e TZ=Asia/Shanghai -p 12800:12800 -p 11800:11800 --link rj_es7 -e SW_STORAGE=elasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODES=rj_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:rj-es7也可改为es服务器部署的Ip地址,比如ip:9200
- 对于
rj-es7
这个容器名称,如果跟本文不同,则要修改为自己的es的容器名称
2.6 安装skywalking-ui
基于docker
进行安装即可.
docker run -d --name rj_skywalking_ui \
--restart=always \
-e TZ=Asia/Shanghai \
-p 8080:8080 \
--link rj_oap \
-e SW_OAP_ADDRESS=rj_oap:12800 \
apache/skywalking-ui:8.5.0
- 这里需要注意的是容器名称, 必须跟我们安装的oap容器名称匹配上.
安装完成之后,直接访问即可: ip:8080
查看es
全部索引
http://ip:9200/_cat/indices?v=true&pretty
三、skywalking常见概念、性能指标说明
3.1 概念说明
-
服务【service】
- 就是服务,譬如说
商品微服务
- 就是服务,譬如说
-
实例【Instance】
- 就是部署微服务的机器: 192.168.200.112
-
端点【Endpoint】
- 微服务对外提供的接口:
/api/v1/user/list
就是端点
- 微服务对外提供的接口:
3.2 性能指标
-
用户的满意程度【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%
-
CPM
- 全称:
call per minutes
, 是吞吐量【throughput】指标, 每分钟请求调用的次数
- 全称:
-
RT
Response Time 表示请求响应时间
,对于用户来说,响应时间最好不要超过2秒
-
Percent Response
百分位数统计- 表示采集样本中某些值的占比,skywalking 有 “p50、p75、p90、p95、p99” 等一系列值
- 举例说明: “p99:360” 表示 99% 请求的响应时间在360ms以内
四、skywalking rocketbot ui介绍
4.1 skywalking ui控制栏
- 仪表盘:查看被监控服务的运行状态
- 拓扑图:以拓扑图的方式展现服务的关系
- 追踪:以接口的形式查看调用链路
- 性能剖析:对端点进行采样分析,分析性能瓶颈
- 日志:可查看服务日志,包括我们自己打印的日志
- 告警:触发告警的告警列表,包括了服务的失败率,超时等待
4.2 Global
- Services load:服务每分钟请求数
- Slow Services:慢响应服务,单位ms
- Un-Health services(Apdex): Apdex性能指标,1为满分
- Slow Endpoint:慢响应端点,单位是ms
- Global Response Latency:百分比响应延时,不同百分比的延时时间,单位ms
- Global Heatmap:服务响应时间热力分布图,根据时间段内不同响应时间的数量显示颜色深度
4.3 Service
Service Apdex(数字)
:当前服务的性能评分Service Apdex(折线图)
:不同时间的Apdex评分Service Avg Response Times
:平均响应延时,单位是msService Response Time Percentile
:百分比响应延时Successful Rate(数字)
:请求成功率Successful Rate(折线图)
:不同时间的请求成功率Servce Load(数字)
:每分钟请求数Servce Load(折线图)
:不同时间的每分钟请求数Servce Instances Load
:每个服务实例的每分钟请求数
4.4 Instance
- 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线程数量
监控CPU、内存等,Promethus是个更好的选择哦.
4.5 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.6 拓扑图
此页面当中,必须得有服务和数据之后才能查看到结果.
4.7 链路追踪
这里先提供数据之后才能展示出相关的结果.