背景介绍
SkyWalking是一个开源的APM系统，包括分布式系统的监控、跟踪、诊断功能 在云原生架构中。
- 分布式跟踪
端到端分布式跟踪。服务拓扑分析、以服务为中心的可观测性和 API 仪表板。 - 堆栈的代理
Java，.Net Core，PHP，NodeJS，Golang，LUA，Rust，C++，Client JavaScript和Python代理具有积极的开发和维护。 - eBPF早期采用
Rover 代理充当由 eBPF 提供支持的指标收集器和分析器，以诊断 CPU 和网络性能。 - 缩放
可以从一个SkyWalking集群收集和分析100+十亿遥测数据。 - 支持成熟的遥测生态系统
支持来自成熟生态系统的指标、跟踪和日志，例如 Zipkin、OpenTelemetry、Prometheus、Zabbix、Fluentd - 原生 APM 数据库
BanyanDB 是一个可观测性数据库，创建于 2022 年，旨在摄取、分析和存储遥测/可观测性数据。 - 一致的指标聚合
SkyWalking原生仪表格式和广为人知的度量格式（OpenTelemetry，Telegraf，Zabbix等）通过相同的脚本管道进行处理。 - 日志管理管道
通过脚本流水线支持日志格式化、提取指标、各种采样策略，性能高。 - 警报和遥测管道
支持以服务为中心、以部署为中心、以API为中心的告警规则设置。支持将告警和所有遥测数据转发给第三方。
原理
SkyWalking整体分为4个部分：探针采集层、数据传输和逻辑处理层、数据存储层、数据展示层。
1.2、探针采集层
所谓探针，实际上是一种动态代理技术，只不过不是我们常用的Java代理类，而是在类加载时，就生成了增强过的代理类的字节码，增强了数据拦截和采集上报的功能。
探针技术是在项目启动时通过字节码技术（比如JavaAgent、ByteBuddy）进行类加载和替换，生成新的增强过的Class文件，对性能的影响是一次性的。
探针技术，因为在类加载时进行转换，增强了部分功能，所以会增加项目启动时间，同时也会增加内存占用量和线程数量。但是对性能影响不大，官方介绍在5% ~ 10%之间。
探针层在类转换时，通过各种插件对原有的类进行增强，之后在运行时拦截请求，然后将拦截的数据上报给Skywalking服务端。同时再加上一些定时任务，去采集应用服务器的基础数据，比如JVM信息等。
1.3、数据传输和逻辑处理层
SkyWalking探针层使用了GRPC作为数据传输框架，将采集的数据上报到SkyWalking服务端。
SkyWalking服务端接收数据后，利用各种插件来进行数据的分析和逻辑处理。比如：JVM相关插件，主要用于处理上报上来的JVM信息，数据库插件用来分析访问数据库的信息。然后在将数据存入到数据存储层。
1.4、数据存储层
SkyWalking的数据存储层支持多种主流数据库，可以自行到配置文件里查阅。我推荐使用ElasticSearch，存储量大，搜索性能又好。
1.5、数据展示层
SkyWalking 通过 Rocketbot 进行页面UI展示。可以在页面的左上角看到这个可爱的Rocketbot。
实战总结
使用大盘
服务（Service）：某个微服务，或者某个应用。
服务实例（Instance）：某个微服务或者某个应用集群的一台实例或者一台负载。
端点（Endpoint）：某个Http请求的接口，或者 某个接口名+方法名。
全局拓扑结构
链路详情
使用总结
SkyWalking：APM（应用程序性能监视器）系统，专为 微服务、云原生和基于容器的架构。
SkyWalking其实就4部分组成：探针采集上报 、 数据分析和逻辑处理、数据存储 、 数据展示 。安装使用简单、易上手。探针技术是SkyWalking的基石，说白了就是：在类加载时进行 字节码转换增强 ，然后去拦截请求，采集上报数据。UI页面的使用 ，多用用就熟悉了。
