1.概念与设计
1.1 SkyWalking是什么
SkyWalking 是一个开源可观测平台,用于收集、分析、聚合和可视化来自服务和云原生基础设施的数据。 SkyWalking 提供了一种简单的方法来保持分布式系统的清晰视图,甚至跨云。 它是一种现代 APM(application performance monitor应用性能监控),专为云原生、基于容器的分布式系统而设计。
1.2 为什么使用SkyWalking和核心概念
SkyWalking 为在许多不同场景中观察和监控分布式系统提供解决方案。 首先,与传统方法一样,SkyWalking 为 Java、C#、Node.js、Go、PHP 和 Nginx LUA 等服务提供自动仪器代理。 在多语言、持续部署的环境中,云原生基础架构变得更加强大,但也更加复杂。 SkyWalking 的服务网格接收器允许 SkyWalking 接收来自 Istio/Envoy 和 Linkerd 等服务网格框架的遥测数据,让用户了解整个分布式系统。
SkyWalking 为服务(Service)、服务实例(Service Instance )、端点(Endpoint )提供可观察能力。 如今,Service、Instance 和 Endpoint 等术语随处可见,因此值得在 SkyWalking 的上下文中定义它们的具体含义:
- 服务。 表示为传入请求提供相同行为的一组工作负载。 您可以在使用仪器代理或 SDK 时定义服务名称。 SkyWalking 还可以使用您在 Istio 等平台中定义的名称。
- 服务实例。 服务组中的每个单独的工作负载都称为一个实例。 与 Kubernetes 中的 pod 一样,它不需要是单个 OS 进程,但是,如果您使用的是仪器代理,则实例实际上是一个真正的 OS 进程。
- 端点。 用于传入请求的服务中的路径,例如 HTTP URI 路径或 gRPC 服务类 + 方法签名。
SkyWalking 允许用户了解Services 和Endpoints 的拓扑关系,查看每个Service/Service Instance/Endpoint 的指标,并设置告警规则。
此外,您还可以集成
- 其他使用带有 Zipkin、Jaeger 和 OpenCensus 的 SkyWalking 本地代理和 SDK 的分布式跟踪工具。
- 其他监控系统,如 Prometheus、Sleuth(Micrometer)、OpenTelemetry。
1.3 架构
SkyWalking 在逻辑上分为四个部分:(探针)Probes、(平台后端)Platform backend、(存储)Storage 和 (前端UI)UI。
- 探针收集数据并根据 SkyWalking 要求重新格式化(不同的探针支持不同的来源)。
- 平台后端支持数据聚合、分析和流式处理,包括跟踪、度量和日志。
- 存储通过开放/可插入接口存储 SkyWalking 数据。 您可以选择现有的实现,例如 ElasticSearch、H2、MySQL、TiDB、InfluxDB,也可以自己实现。
- UI 是一个高度可定制的基于 Web 的界面,允许 SkyWalking 最终用户可视化和管理 SkyWalking 数据。
1.4 设计目标
本文档概述了 SkyWalking 项目的核心设计目标。
- 保持可观察性。 无论目标系统采用何种部署方式,SkyWalking 都为其提供集成解决方案以保持可观察性。 基于此,SkyWalking 提供了多种运行时表单和探针。
- 集合拓扑、度量和跟踪。了解分布式系统的第一步是拓扑图。它以易于阅读的布局可视化整个复杂系统。在拓扑下,OSS人员对服务、实例、端点、调用等指标有更高的要求。跟踪采用详细日志的形式,以了解这些指标。例如,当端点延迟变长时,您希望查看最慢的跟踪以找出原因。所以你可以看到,从大局到细节,都是需要的。 SkyWalking 集成并提供了许多功能,使这成为可能且易于理解。
- 轻量级。需要两个重量轻的部分。 (1)在probe中,我们只依赖网络通信框架,更喜欢gRPC。这样,探针应该尽可能小,以避免库冲突和VM的有效负载,例如JVM中的permsize要求。 (2) 作为一个可观察性平台,它是您项目环境中的二级和三级系统。所以我们正在使用我们自己的轻量级框架来构建后端核心。然后你不需要部署大数据技术平台和维护它们。 SkyWalking 在技术栈中应该很简单。
- 可插拔。 SkyWalking 核心团队提供了很多默认的实现,但肯定是不够的,也不适合所有场景。因此,我们提供了许多可插拔的功能。
- 可移植性。 SkyWalking 可以在多种环境中运行,包括: (1) 使用传统的注册中心,如 eureka。 (2) 使用包含服务发现的RPC框架,如Spring Cloud、Apache Dubbo。 (3) 在现代基础设施中使用 Service Mesh。 (4) 使用云服务。 (5) 跨云部署。 SkyWalking 在所有这些情况下都应该运行良好。
- 相互操作性。可观测性领域是如此广阔,以至于 SkyWalking 几乎不可能支持所有系统,即使在其社区的支持下也是如此。目前,它支持与其他 OSS 系统的互操作性,尤其是探针,如 Zipkin、Jaeger、OpenTracing 和 OpenCensus。 SkyWalking 能够接受和读取这些数据格式对最终用户来说非常重要,因为用户不需要切换他们的库。
1.5 探针Probe
主要有三种典型的探针。包括基于语言的本地代理(比如-javaagent),服务网格探针,第三方类型。
2. 搭建服务 Quick Start
2.1 SkyWalking前后端(OAP服务)
2.1.1 包组成
下载链接:https://skywalking.apache.org/downloads/
解压之后如下
- bin目录包含分别为linux和window系统而写的前端启动脚本和后端启动脚本。
- config目录包含后端的配置文件,主要有三个:application.yml,log4j.xml,alarm-settings.yml。
- oap-libs目录包含所有启动后端所需要的jar包。
- webapp 目录为前端代码,包括配置文件webapp.yml.
2.1.2 必要条件和默认配置
- 必要条件: 从JDK8到JDK17均可以,其他版本的未测试过。
- 你可以用默认配置执行bin/startup.sh(或startup.bat)来启动前端和后端
1)默认后端存储:H2
2)gRPC APIs监听端口0.0.0.0/11800,HTTP REST APIs监听端口0.0.0.0/12800 - 在 Java、.NetCore、Node.js 和 Istio 代理/探针中,您应该将 gRPC 服务地址设置为 ip/host:11800,并且 ip/host 应该是您的SkyWalking后端所在的ip。
1)UI 侦听 8080 端口并请求 127.0.0.1/12800 以运行 GraphQL 查询。
2.1.3 各个组件如何交互
- 所有原生代理和探针,无论是基于语言的还是网格探针,都使用 gRPC 服务(application.yml 中的 core/default/gRPC*)向后端报告数据。 此外,Jetty 服务支持 JSON 格式。
- UI 也使用 GraphQL (HTTP) 查询来访问 Jetty 服务中的后端(application.yml 中的 core/default/rest*)。
2.1.4 启动脚本
为适应不同的部署场景,启动模式除了默认模式,另外还提供两种模式。
-
默认模式
默认模式执行任务以根据需要进行初始化、开始监听并提供服务。
运行 /bin/oapService.sh(.bat) 以在此模式下启动。 当您使用 startup.sh(.bat) 启动时,这也适用。 -
初始化模式
在这种模式下,OAP服务器启动进行初始化,然后退出。 您可以使用此模式来初始化您的存储(例如 ElasticSearch 索引、MySQL 和 TiDB 表)以及您的数据。
运行 /bin/oapServiceInit.sh(.bat) 以在此模式下启动。 -
无初始化模式
在这种模式下,OAP 服务器无需初始化即可启动。 相反,它监视 ElasticSearch 索引、MySQL 和 TiDB 表,开始监听并提供服务。 换句话说,OAP 服务器会期望有另一个 OAP 服务器来执行初始化。
运行 /bin/oapServiceNoInit.sh(.bat) 以在此模式下启动。
2.1.5 application.yml
SkyWalking 后端启动行为由 config/application.yml 驱动。 了解设置文件将有助于您阅读本文档。 该设置文件背后的核心理念是 SkyWalking 采集器基于纯模块化设计。 最终用户可以根据自己的需求切换或组装采集器功能。
在 application.yml 中,共有三个level。
- level1:Module 名称。 这意味着该Module 在运行模式下处于活动状态。
- level2:selector 选择器。 此处列出了可用的提供程序,并带有一个选择器,以指示哪个提供程序实际生效。 如果只列出了一个提供者,则选择器是可选的,可以省略。
- level3. 提供者的设置。
例子:
storage:
selector: mysql # mysql的配置生效,h2的配置不生效
h2:
driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource}
url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db}
user: ${SW_STORAGE_H2_USER:sa}
metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000}
mysql:
properties:
jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/swtest"}
dataSource.user: ${SW_DATA_SOURCE_USER:root}
dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root@1234}
dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true}
dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250}
dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048}
dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true}
metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000}
# other configurations
receiver-browser:
selector: ${SW_RECEIVER_BROWSER:default} # SW_RECEIVER_BROWSER如果没值,默认实现default
default:
# The sample rate precision is 1/10000. 10000 means 100% sample in default.
sampleRate: ${SW_RECEIVER_BROWSER_SAMPLE_RATE:10000}
- storage是Module (模块)。
- selector选择器从下面列出的所有提供者中选择一个。 未选中的不会生效,就像被被删除一样。
- default 是核心模块的默认实现者。
- driver, url, … metadataQueryMaxSize 都是实现者的设置项。
同时,有两种类型的模块:必需的和可选的。 必需的模块提供了后端的骨架。 即使它们的模块化设计支持可插拔性,移除这些模块也无济于事。 对于可选模块,其中一些有一个称为 none 的提供程序实现,这意味着它只提供一个没有实际逻辑的 shell,通常例如遥测。 将 - 设置为选择器意味着整个模块将在运行时被排除。 我们建议不要尝试更改这些模块的 API,除非您非常了解 SkyWalking 项目及其代码。
例子:
telemetry:
selector: ${SW_TELEMETRY:none} # 注意这里的none
none:
prometheus:
host: ${SW_TELEMETRY_PROMETHEUS_HOST:0.0.0.0}
port: ${SW_TELEMETRY_PROMETHEUS_PORT:1234}
sslEnabled: ${SW_TELEMETRY_PROMETHEUS_SSL_ENABLED:false}
sslKeyPath: ${SW_TELEMETRY_PROMETHEUS_SSL_KEY_PATH:""}
sslCertChainPath: ${SW_TELEMETRY_PROMETHEUS_SSL_CERT_CHAIN_PATH:""}
receiver_jaeger:
selector: ${SW_RECEIVER_JAEGER:-} # 注意这里的 -
default:
gRPCHost: ${SW_RECEIVER_JAEGER_HOST:0.0.0.0}
gRPCPort: ${SW_RECEIVER_JAEGER_PORT:14250}
此处列出了必需的模块:
- core。 提供所有数据分析和流分发的基本和主要骨架。
- cluster。管理集群中的多个后端实例,可以提供高吞吐量的处理能力。 有关更多详细信息,请参阅集群管理。
- storage。 使分析结果持久化。 有关更多详细信息,请参阅选择存储
- query。 为 UI 提供查询接口。
- receiver 和fetcher。 将服务公开给代理和探测器,或从通道读取遥测数据。
2.1.5.1 application.yml 配置文件参数含义
具体参考官方文档:https://skywalking.apache.org/docs/main/v8.9.1/en/setup/backend/configuration-vocabulary/
2.2 Java agent (java 探针)
2.2.1 下载软件包
下载链接:https://skywalking.apache.org/downloads/
软件解压之后的目录:
2.2.2 linux启动脚本
agent.config是配置文件,里面包含默认的配置,配置含义参考官方文档:https://skywalking.apache.org/docs/skywalking-java/v8.9.0/en/setup/service-agent/java-agent/configurations/
启动脚本:
-javaagent:你的绝对路径/skywalking-agent.jar -Dskywalking_config=你的绝对路径/agent.config -Dskywalking.agent.service_name=你的应用名 -Dskywalking.collector.backend_service=Skywalking后端服务IP:11800
比如:
-javaagent:E:/SkyWalking/skywalking-agent/skywalking-agent.jar -Dskywalking_config=E:/SkyWalking/skywalking-agent/config/agent.config -Dskywalking.agent.service_name=app-demo -Dskywalking.collector.backend_service=192.168.1.2:11800
如果你想覆盖参数,可以在用-D的方式覆盖。更多参考官方文档:https://skywalking.apache.org/docs/skywalking-java/v8.9.0/en/setup/service-agent/java-agent/setting-override/
3. 高级设置
3.1 覆写配置
SkyWalking 后端支持通过系统属性和系统环境变量设置覆盖。 您可以覆盖 application.yml 中的设置
3.1.1 System properties 系统属性
例子:
core:
default:
restHost: ${SW_CORE_REST_HOST:0.0.0.0}
restPort: ${SW_CORE_REST_PORT:12800}
restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/}
gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
gRPCPort: ${SW_CORE_GRPC_PORT:11800}
通过以下命令设置restHost为172.0.4.12,如果没有,默认为0.0.0.0
-Dcore.default.restHost=172.0.4.12
3.1.2 System environment variables 系统环境变量
core:
default:
restHost: ${REST_HOST:0.0.0.0}
restPort: ${SW_CORE_REST_PORT:12800}
restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/}
gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
gRPCPort: ${SW_CORE_GRPC_PORT:11800}
如果你的操作系统有系统环境变量REST_HOST为172.0.4.12,则restHost的值将被替换,如果没有,默认为0.0.0.0。
同时支持嵌套占位符配置,比如如下配置,如果REST_HOST不存在,但是ANOTHER_REST_HOST有值172.0.4.12,则restHost的值为172.0.4.12,否则默认为127.0.0.1。
${REST_HOST:${ANOTHER_REST_HOST:127.0.0.1}}
3.2 存储配置
SkyWalking默认的存储是H2,此外支持OpenSearch,ElasticSearch 6, 7,MySQL,TiDB,InfluxDB,
PostgreSQL,IoTDB等。
以下将简要介绍MySQL的配置。
配置:
storage:
selector: ${SW_STORAGE:mysql} # 这里切换成mysql
mysql:
properties:
jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/swtest?rewriteBatchedStatements=true"}
dataSource.user: ${SW_DATA_SOURCE_USER:root}
dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root@1234}
dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true}
dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250}
dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048}
dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true}
metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000}
maxSizeOfBatchSql: ${SW_STORAGE_MAX_SIZE_OF_BATCH_SQL:2000}
asyncBatchPersistentPoolSize: ${SW_STORAGE_ASYNC_BATCH_PERSISTENT_POOL_SIZE:4}
注意:oap-libs目录没有MySQL的驱动jar,需要自行复制到oap-libs。
4.服务指标
4.1 Global全局维度
Services load:服务每分钟请求数
Slow Services:慢响应服务,单位ms
Un-Health services(Apdex):Apdex性能指标,1为满分。
- Apdex 一个由众多网络分析技术公司和测量工业组成的联盟组织,它们联合起来开发了“应用性能指数”即“Apdex”(Application Performance Index),用一句话来概括,Apdex是用户对应用性能满意度的量化值
- http://www.apdex.org/
Slow Endpoints: 慢响应端点,单位ms
Global Response Latency:百分比响应延时,不同百分比的延时时间,单位ms
Global Heatmap:服务响应时间热力分布图,根据时间段内不同响应时间的数量显示颜色深度
4.2 Service服务维度
Service Apdex(数字):当前服务的评分
Service Avg Response Times:平均响应延时,单位ms
Successful Rate(数字):请求成功率
Servce Load(数字):每分钟请求数
Service Apdex(折线图):不同时间的Apdex评分
Service Response Time Percentile:百分比响应延时
Successful Rate(折线图):不同时间的请求成功率
Servce Load(折线图):不同时间的每分钟请求数
Servce Instances Load:每个服务实例的每分钟请求数
Slow Service Instance:每个服务实例的最大延时
Service Instance Successful Rate:每个服务实例的请求成功率
4.3 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
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:当前端点每个时间段的请求成功率