分布式链路追踪-skywalking体验
分布式链路追踪-skywalkingV9体验
- 一、前言
-
- 1.1 背景
- 1.2 解决方案
- 二、Skywalking简介
-
- 2.1 APM是什么？
- 2.2 OpenTracing是什么？
-
- 1）基本概念：
- 2）链路追踪方案：
- 2.3 SkyWalking 是什么？
- 2.4 为什么要使用SkyWalking?
- 三、初体验Skywalking（V9版本）
-
- 3.1 整体架构
- 3.2 环境准备
- 3.3 工作流程
- 3.4 部署大致流程及注意事项（部署详情见网上帖子）
- 3.5 APM目录结构介绍
- 3.6 监控Java服务
-
- 1) 如何收集 Java 程序的数据？
- 2）如何使用？
- 3.7 监控Linux
- 四、Skywalking面板
-
- 4.1 服务概览
- 4.2 服务链路的拓扑图
- 4.3 具体调用链路信息
- 4.5 服务信息
- 4.6 JVM信息
- 4.7 Linux服务
- 4.8 告警
- 4.9 虚拟数据库信息
- 五、总结
- 六、参考:
一、前言
1.1 背景
随着分布式系统和微服务架构的出现，一次用户请求会经过多个系统，不同服务之间调用关系十分复杂，任何一个系统出现错误或者异常都可能影响整个请求的处理结果。迫切需要解决一些问题：
● 性能分析：服务之间关系不像PPT展示哪里界限分明，实际服务之间关系错综复杂，如果某个接口耗时突然变长了，如何快速定位耗时变长问题。
● 链路梳理：需求快速迭代，系统间调用关系变化频繁，人工很难梳理清楚系统链路拓拔，判断影响范围及梳理服务依赖并判断依赖的合理性。
● 业务瓶颈：实施容量规划，对于容器的监控，实时/准实时的了解应用部署环境（CPU、内存、进程、线程、网络、带宽）情况，以便快速扩容/缩容、流量控制、业务迁移。
● 告警：对于突发的请求也能进行异常告警和应急准备
1.2 解决方案
在这种情况下，一般都会引入APM系统，通过各种探针采集数据，收集关键指标，同时搭配数据呈现和监控告警，能够解决上述的大部分问题。然而随着RPC框架、微服务、云计算、大数据的发展，同时业务的规模和深度相比过往也都增加了很多，一次业务可能横跨多个模块/服务/容器，依赖的中间件也越来越多，其中任何一个节点出现异常，都可能导致业务出现波动或者异常，这就导致服务质量监控和异常诊断与定位变得异常复杂，于是催生了新的业务监控模式：分布式调用链跟踪。
本次只介绍Skywalking，其他相关产品对比等，见网上介绍。
二、Skywalking简介
2.1 APM是什么？
APM系统-应用性能管理系统，是对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化解决方案。可以帮助开发、运维人员以便发送故障时，能快速定位和解决问题。
2.2 OpenTracing是什么？
微服务架构普及，类似skywalking这种分布式追踪系统（分布式链路追踪最先有Google在Dapper论文中提出）大量涌现，但API互不兼容，难以整合和切换，因此提出了统一的平台无关、厂商无关的API，不同的分布式追踪系统去实现。OpenTracing调用链跟踪系统的一个事实标准，它制定了调用链跟踪的基本流程和基本的数据结构，同时也提供了各个语言的实现。
1）基本概念：
● Trace：一个事务或者流程在（分布式）系统中的执行过程，可以认为是多个span的有向无环图（DAG）。
● Span：一个span代表系统中具有开始时间和执行时长的逻辑运行单元。span之间通过嵌套或者顺序排列建立逻辑因果关系。
● Logs：每个span可以进行多次Logs操作，每一次Logs操作，都需要一个带时间戳的时间名称，以及可选的任意大小的存储结构。
● Tags：每个span可以有多个键值对（key:value）形式的Tags，Tags是没有时间戳的，支持简单的对span进行注解和补充。
● SpanContext：SpanContext代表跨越进程边界，传递到下级span的状态。(例如，包含
● References：一个span可以和一个或者多个span间存在因果关系。OpenTracing定义了两种关系：ChildOf 和 FollowsFrom。这两种引用类型代表了子节点和父节点间的直接因果关系。
● Baggage：是存储在SpanContext中的一个键值对(SpanContext)集合。它会在一条追踪链路上的所有span内全局传输，包含这些span对应的SpanContexts。
2）链路追踪方案：
● 典型的Trace案例1
在一个分布式系统中，追踪一个事务或者调用流一般如上图所示。虽然这种图对于看清各组件的组合关系是很有用的，但是，它不能很好显示组件的调用时间，是串行调用还是并行调用，如果展现更复杂的调用关系，会更加复杂，甚至无法画出这样的图。另外，这种图也无法显示调用间的时间间隔以及是否通过定时调用来启动调用。
● 典型的Trace案例2
这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，项目团队可能专注于优化路径中的关键位置，最大幅度的提升系统性能。例如：可以通过追踪一个资源定位的调用情况，明确底层的调用情况，发现哪些操作有阻塞的情况。
2.3 SkyWalking 是什么？
SkyWalking 是一个可观测性分析平台（Observability Analysis Platform简称OPA）和应用程序性能管理系统(Application Performance Management简称APM)，它是一种现代 APM，专为云原生、基于容器的分布式系统而设计。其核心功能：
● 服务、服务实例、端点（URI）指标分析。
● 用于 TCP、TCP/TLS、HTTP(s) 流量的网络分析器
● 服务拓扑图分析。
● 缓慢的服务和端点检测。
● 在内存性能监控，包括读取和写入性能。
● 数据库性能监控。检测慢速 SQL 语句。
● MQ性能和消耗延迟监控。
● 浏览器性能监控，从浏览器开始跟踪。
● 基础设施监控。Kubernetes 和 Linux（VM、网络、磁盘等）。
● 告警。
2.4 为什么要使用SkyWalking?
SkyWalking 提供了在许多不同场景中观察和监控分布式系统的解决方案：
● 为服务提供agent，例如 Java、C#、Node.js、Go、PHP 和 Nginx LUA。
● 为服务、服务实例、端点、进程提供可观察性能力。
● 了解 Services 和 Endpoints 之间的服务拓扑关系。
● 查看每个 服务、服务实例、端点的指标并设置告警规则。
● 从 v9 开始，SkyWalking 引入了新的核心概念Layer。如操作系统（OS_LINUX层）、Kubernetes（k8s层）。所有检测到的实例都属于一个层来表示这个实例的运行环境，服务会根据其实例有一个或多个层定义。
● 使用 SkyWalking 本机agent，监控SkyWalking 自身，以及集成 Zipkin、Jaeger 和 OpenCensus 的其他分布式跟踪。
● 可以集成其他指标系统，如 Prometheus、Sleuth(Micrometer)、OpenTelemetry。
三、初体验Skywalking（V9版本）
3.1 整体架构
SkyWalking v9可以称得上全栈APM，因为它涉及APM、最终用户、手机端以及基础性平台的基础设施（比如Linux、Kubernetes）。如下图所示，左侧是浏览器、语言、主流的Service Mesh、Kubernetes以及操作系统。右侧是v9的菜单，按照层级划分，从普通的General Service到自监控。
总体架构是除了基础设施从上到下的维度之外，通过数据源分成了Tracing、Metrics、Logging和Event 4个入口，不同于传统意义Tracing、Metrics、Logging 3个核心的概念，现在是4个核心的概念。因为Event是触发变更的基础，所以在这个过程中间起到了很大的作用。右侧可能是大家熟悉SkyWalking ，分为Receiver cluster、Aggregator cluster、对外提供了GUI，也就大家常见的webUI、CLI是command可视化、提供对外的告警Alarm、数据导出Exporter、以及多种多样的数据存储Storage option。
v9版本真正完成了这样的一张构想图，从最开始的浏览器到下面的操作系统，实现全栈多种数据源集成。v9版本到底更新了什么？其实从SkyWalking社区、核心团队的角度来看，只是新增了一种概念，叫做Layer，可以称之为“层”或者应用软件基础设施的抽象分类。Layer代表的是一个抽象的框架，在整个计算机科学领域里面可能是操作系统、Kubernetes，也可能是Agent安装的一个服务，或者是Service Mesh。所有收到的数据都可以归属为一个“层”，并且具有共通性。也可以简单地映射到菜单上面，不同服务可能有不同的归属。这样分是因为每一层的Metrics、Tracing或者一些核心的功能都会有些区别。
SkyWalking 在逻辑上分为四个部分：Probes、Platform backend、Storage 和 UI。
● Probe：支持不同的数据来源，Tracing、 Metrics 、Logging、 Event 负责从应用中，收集链路信息，发送给 Platform backend。Java应用通常使用Agent 收集数据。
● Platform backend：支持数据聚合、分析和流处理，涵盖跟踪、指标和日志。
● Storage ：通过开放/可插入接口存储 SkyWalking 数据。您可以选择现有的实现，例如 ElasticSearch、H2、MySQL、TiDB、InfluxDB。
● UI：是一个高度可定制的基于 Web 的界面，允许 SkyWalking 最终用户可视化和管理 SkyWalking 数据。
3.2 环境准备
| 工具 | 版本号 | 下载链接 |
|---|---|---|
| JDK | 1.8 | https://www.oracle.com/java/technologies/downloads/#java8 |
| ElasticSearch(ES) | 8.5.0 | https://www.elastic.co/cn/downloads/elasticsearch |
| Skywalking（APM） | 9.1.0 | https://skywalking.apache.org/downloads/#SkyWalkingAPM |
| Agent(Java Agent) | 8.110 | https://skywalking.apache.org/downloads/#SkyWalkingAPM |
注意：
● Skywalking在之前的旧版本中，apm与agent是在一个包中的，在9.0的版本中是需要分开下载的，agent包下载解压之后，也将其放到apm包下面维护agent包
● ES解压的时候需要注意解压路径不要在root目录下，因为elasticsearch8不允许使用root角色启动
3.3 工作流程
大多数服务通过agents和probes的方式进行数据采集，通过gRPC 上报到Skywalking服务，进行数据的聚合管理和分析，并存储在ES持久层，然后通过GraphQL 查询Skywalking服务，在UI界面进行可视化呈现。
3.4 部署大致流程及注意事项（部署详情见网上帖子）
● jdk8部署及环境变量配置
● 下载es、oap、agent的tar包上传到服务器指定目录、解压、配置环境、启动
● agent解压后将其放到apm包下面维护agent包
● 修改oap的UI服务的配置文件修改端口号（默认8080，尽量修改，避免端口冲突）
● 注意ES8不允许使用root角色启动，需要创建用户进行启动
● SpringBoot测试项目jar包上传到服务器指定目录，启动参数添加“-javaagent”参数
3.5 APM目录结构介绍
● agent：客户端需要指定的目录，其中有一个jar，就是负责和客户端整合收集日志（java应用探针）
● bin：服务端启动的脚本（startup.sh脚本可以启动oap服务和UI服务）
● config：一些配置文件的目录
● logs：oap/apm服务的日志目录
● oap-libs：oap/apm所需的依赖目录
● webapp：UI服务的目录（修改UI端口）
3.6 监控Java服务
1) 如何收集 Java 程序的数据？
SkyWalking 与SpringBoot集成，启动Java项目时被skywalking skywalking-agent.jar 代理拦截，agent代理拦截是jdk1.5提供的一种技术，可以使启动jar包时不需要引入任何依赖，agent就可以对java程序做业务增强，类似AOP技术，可以理解agent探针属于JVM级别的AOP。以javaagent的模式，通过字节码增强的技术，最终实现非侵入性的数据埋点，采集调用链数据，通信方式采用GRPC(性能较好)，上报数据给OAP/APM，支持告警，支持JVM监控，支持全局调用统计等等。
2）如何使用？
启动SpringBoot.jar包时指定agent目录下的skywalking-agent.jar，注意skywalking-agent.jar要写绝对路径。测试访问SpringBoot项目接口，然后去SkyWalking控制台查看效果。
#原来启动项目
java -jar springboot-demo.jar
#加探针启动项目，命令行加“-javaagent”
java -jar -javaagent:/{agent包绝对路径}/skywalking-agent.jar springboot-demo.jar
3.7 监控Linux
SkyWalking 利用 Prometheus 收集指标数据，并利用 OpenTelemetry Collector 将指标传输到 OpenTelemetry 接收器和Meter System。
四、Skywalking面板
官方Demo：http://demo.skywalking.apache.org/general
账密：skywalking/skywalking
4.1 服务概览
4.2 服务链路的拓扑图
了解分布式系统的第一步是拓扑图。它以易于阅读的布局可视化整个复杂系统。
4.3 具体调用链路信息
采集了请求链路上的各个节点，以及执行的耗时分析，点击相关节点可以查看详细信息，针对异常请求同样可以采集到异常信息的描述。图中端点的请求走过的每一个不同的服务，都是用了不同的颜色区分开了。而竖着的直线，就是对应着当前的服务，中间的每一个跨度都能点开查看日志，包括执行的 SQL 语句，然后只要输出了日志信息，都可以关联到对应的 log。
4.5 服务信息
服务的整体运行情况。
4.6 JVM信息
每一个实例进去，都能够看到对应的 JVM 的信息，有内存/CPU占用情况，新生代、老年代的 gc 时间和次数，各种状态的线程次数等。
4.7 Linux服务
服务器相关指标。
4.8 告警
配置文件配置阈值，达到阈值进行告警，项目可以集成webhook进行告警信息推送。
4.9 虚拟数据库信息
在虚拟数据库方面，实际是在应用探针里面探查到的数据，比如用Java做探针时，会在里面做一些数据库的调用，在客户端角度看这些数据库调用的性能，称作Virtual Service。
五、总结
Skywalking为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑分析、服务器指标实时监控、JVM指标实时监控、定位慢SQL问题及阈值告警推送等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。
六、参考:
● Skywalking（GitHub）：https://github.com/apache/skywalking
● OpenTracing文档中文版（翻译）吴晟：https://wu-sheng.gitbooks.io/opentracing-io/content/
● 分布式链路追踪-skywalking入门体验：https://blog.csdn.net/LBWNB_Java/article/details/127004321
● 基于 Kubernetes 和 SkyWalking 的 Spring 微服务监控实践：https://blog.besscroft.com/articles/2022/spring-microservice-monitoring-practice/
● SkyWalking调研与初步实践：https://skywalking.apache.org/zh/2019-03-29-introduction-of-skywalking-and-simple-practice/