背景介绍

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页面的使用 ，多用用就熟悉了。