西方设计网站,做外贸没有企业网站,备案域名怎么弄,宿迁网站建设公司排名一、skywalking预览
1.1 skywalking 概述
Apache SkyWalking, 适用于分布式系统的应用程序性能监控工具#xff0c;专为微服务、云原生和基于容器的 #xff08;Kubernetes#xff09; 架构而设计。官方地址: https://skywalking.apache.org/ 适用于分布式系统的应用程…一、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 uiskywalking-agent 【由项目引入】
相关操作环境为centos7,也可以考虑使用虚拟机.
2.4 安装ES7 centos7docker 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.ymldocker run -d --name rj_es7 -p 9200:9200 -p 9300:9300 \-e discovery.typesingle-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.typesingle-node 表示设置为设单节点启动-e ES_JAVA_OPTS-Xms128m -Xmx128m 设置ES的初始内存和最大内存如果云服务器内存足够大的情况下,可忽略,如果云服务器内存不宽裕,设置一下,防止ES启不来
安装成功之后,可以访问
http://your ip/_cat/nodes?vtruepretty2.5 安装skywalking-OAP-server
直接通过docker安装即可,如下所示:
docker run --name rj_oap --restart always -d -e TZAsia/Shanghai -p 12800:12800 -p 11800:11800 --link rj_es7 -e SW_STORAGEelasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODESrj_es7:9200 apache/skywalking-oap-server:8.5.0-es7参数说明 --link name or id:alias 添加到另一个容器的链接可以添加别名或者不加--link后面的参数和elasticsearch容器名一致SW_STORAGEelasticsearch7 是固定写法使用es7;SW_STORAGE_ES_CLUSTER_NODESrj-es7也可改为es服务器部署的Ip地址比如ip:9200对于rj-es7这个容器名称,如果跟本文不同,则要修改为自己的es的容器名称 2.6 安装skywalking-ui
基于docker进行安装即可.
docker run -d --name rj_skywalking_ui \
--restartalways \
-e TZAsia/Shanghai \
-p 8080:8080 \
--link rj_oap \
-e SW_OAP_ADDRESSrj_oap:12800 \
apache/skywalking-ui:8.5.0这里需要注意的是容器名称, 必须跟我们安装的oap容器名称匹配上.
安装完成之后,直接访问即可: ip:8080 查看es全部索引
http://ip:9200/_cat/indices?vtruepretty三、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秒内;【容忍】: 慢了一点但还可以接受继续这一应用过程响应时间 T4T 秒,即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慢响应服务单位msUn-Health services(Apdex): Apdex性能指标1为满分Slow Endpoint慢响应端点单位是msGlobal Response Latency百分比响应延时不同百分比的延时时间单位msGlobal 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 CPUJVM占用CPU的百分比JVM MemoryJVM内存占用大小单位MJVM GC TimeJVM垃圾回收时间包含YGC和OGCJVM GC CountJVM垃圾回收次数包含YGC和OGCJVM Thread CountJVM线程数量
监控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 链路追踪 这里先提供数据之后才能展示出相关的结果.
