当前位置：首页 > news >正文

成都招聘网站制作/自己可以做网站吗

news 文章来源：https://blog.csdn.net/ldcigame/article/details/142450575 2025/3/15 12:42:52

成都招聘网站制作,自己可以做网站吗,无锡网站排名公司,十大素材网站一、skywalking预览 1.1 skywalking 概述 Apache SkyWalking, 适用于分布式系统的应用程序性能监控工具，专为微服务、云原生和基于容器的 （Kubernetes） 架构而设计。官方地址: https://skywalking.apache.org/ 适用于分布式系统的应用程…

一、skywalking预览

1.1 skywalking 概述

Apache SkyWalking, 适用于分布式系统的应用程序性能监控工具，专为微服务、云原生和基于容器的（Kubernetes）架构而设计。官方地址: https://skywalking.apache.org/
SkyWalking功能预览

适用于分布式系统的应用程序性能监控工具，专为微服务、云原生和容器 (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.ymldocker 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
skywalking-ui
查看es全部索引

http://ip:9200/_cat/indices?v=true&pretty

es索引

三、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

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

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 Instance

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

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 链路追踪

链路追踪

这里先提供数据之后才能展示出相关的结果.