Apache SkyWalking入门学习笔记

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 必要条件和默认配置

1. 必要条件： 从JDK8到JDK17均可以，其他版本的未测试过。
2. 你可以用默认配置执行bin/startup.sh（或startup.bat）来启动前端和后端
   1)默认后端存储：H2
   2)gRPC APIs监听端口0.0.0.0/11800，HTTP REST APIs监听端口0.0.0.0/12800
3. 在 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：当前端点每个时间段的请求成功率