SkyWalking

发表于 更新于 分类于 本文字数： 3.1k 阅读时长 ≈ 3 分钟

做微服务或者分布式系统时，最容易遇到的一类问题不是“功能有没有写出来”，而是“问题出了以后到底该去哪里看”。接口慢了、某个服务超时了、数据库抖了、链路中间断了，单靠日志一层一层翻，很多时候会很难排查。

这时候就会用到像 SkyWalking 这样的观测平台。它最常见的用途当然是链路追踪，但它实际上不只做 tracing，还把指标、日志、拓扑、性能分析这些内容放到了同一套系统里。

为什么会用到 SkyWalking

系统只有一个服务的时候，排查问题通常不复杂。请求进来，打几个日志，看一下接口耗时，基本就能定位。

但服务一旦多起来，情况就会变得不一样：

  • 一个请求可能会经过网关、应用服务、缓存、消息队列和数据库。
  • 某个接口变慢，不一定是当前服务本身的问题。
  • 某个异常可能已经跨了好几个服务，单看一份日志很难拼完整。

也就是说，系统复杂度上来以后，问题不再只是“有没有日志”，而是“能不能把这次请求完整地串起来看”。

SkyWalking 解决的就是这一类问题。它把分布式系统里的调用链、服务拓扑、运行指标和部分日志信息组织到一起，让排查问题的时候不用再完全靠手工拼接。

SkyWalking 是什么

按照 Apache SkyWalking 官方文档的定义，它是一个开源的可观测性平台，用来收集、分析、聚合和可视化服务以及云原生基础设施的遥测数据。

如果把这句话说得直白一点，可以把它理解成一个偏分布式系统场景的 APM 平台。它能帮助你看清楚：

  • 一个请求经过了哪些服务
  • 每一段调用花了多长时间
  • 哪个服务、实例或者接口最慢
  • 当前系统的依赖拓扑是什么样
  • 某些日志能不能和具体 trace 对上

所以 SkyWalking 不只是一个“看链路”的工具，它更接近一套完整的观测系统。

SkyWalking 能看什么

根据官方文档，SkyWalking 覆盖的不只是 tracing，还包括 metrics、logging、profiling 和 event。

链路追踪

这是大多数人第一次接触 SkyWalking 的入口。一个请求从网关进入，再经过多个服务、RPC 调用、数据库访问，最后返回给用户，这条链路可以在 SkyWalking 里完整展示出来。

对于排查超时、慢接口、调用失败这类问题，链路追踪通常是最好用的能力之一。

指标监控

SkyWalking 也会聚合服务、实例、接口等维度的指标数据，比如响应时间、吞吐量、错误率这些常见内容。

这部分数据更适合回答“最近这个服务整体状态怎么样”这种问题，而不是只看某一次请求。

日志关联

SkyWalking 本身不是传统意义上的日志平台，但它可以把日志和 trace 关联起来。这样在排查问题的时候，不需要先找到日志，再反推是哪一次请求，也可以先从 trace 进去，再看相关日志。

Profiling 和 Event

除了常规的链路和指标，SkyWalking 还提供 profiling 和 event 能力。profiling 更偏性能分析，可以帮助定位代码层面的热点；event 更适合记录系统中的重要事件，比如版本变更、配置修改这类信息。

SkyWalking 的基本架构

从官方文档看，SkyWalking 的整体架构可以分成四个部分：Probes、OAP Backend、Storage 和 UI。

可以简单理解成下面这个流程：

flowchart LR
    A[应用服务] --> B[Probe / Agent]
    B --> C[SkyWalking OAP]
    C --> D[Storage]
    E[SkyWalking UI] --> C

这四部分各自负责的事情大概如下：

Probe / Agent

Probe 可以理解成探针，也就是接入到业务系统里的采集端。它可以是语言 Agent，也可以是 SDK，负责把应用里的 trace、metrics 等数据采集出来并发送到后端。

SkyWalking 官方文档里列出的探针类型比较多，常见的包括 Java、Go、Node.js、Python、PHP 等语言 Agent，也支持从 Service Mesh、OpenTelemetry、Zipkin、Prometheus 等生态接收数据。

OAP Backend

OAP 是 SkyWalking 的核心后端。采集上来的数据不会直接给前端展示，而是先进入 OAP 做聚合、分析和处理。

平时说“搭 SkyWalking”，很多时候说的核心就是把 OAP 跑起来。

Storage

SkyWalking 需要把观测数据存下来，所以后面还需要存储层。官方文档里提到它支持多种存储实现，比如 Elasticsearch、OpenSearch、MySQL、PostgreSQL、BanyanDB 等。

UI

UI 就是最后看到的可视化界面。服务拓扑、接口耗时、trace 列表、实例状态这些内容，最终都是在 UI 里查看。

在项目里一般怎么接入

如果只是想先把 SkyWalking 跑起来，官方文档给了 Docker 的快速启动方式，可以直接把 OAP、UI 和存储一起启动。

从接入思路上看，一般是两步：

  1. 先把 SkyWalking 后端跑起来，也就是 OAP、UI 和存储。
  2. 再把业务应用接上对应的 Agent 或 SDK，把数据发到 OAP。

以 Java 应用为例，常见做法是在启动参数里挂上 Java Agent，然后指定 OAP 的地址：

1
2
3
java -javaagent:skywalking-agent.jar \
  -Dskywalking.collector.backend_service=localhost:11800 \
  -jar your-app.jar

应用跑起来之后，请求经过这个服务时，Agent 就会自动上报链路和相关观测数据。之后再打开 SkyWalking UI，就可以看到服务、实例、接口以及 trace 信息。

SkyWalking 适合什么场景

SkyWalking 比较适合下面这些场景：

  • 微服务调用链比较长，排查问题成本高
  • 需要看服务之间的依赖关系
  • 想把 trace、metrics、部分日志关联起来一起看
  • 系统已经在使用云原生或容器化部署

如果系统本身很简单，只有一两个服务，那它的价值可能不会特别明显。但只要服务数量上来，或者排障开始依赖跨服务分析，SkyWalking 这类工具通常就会很有用。

小结

SkyWalking 可以理解成一套面向分布式系统的可观测平台。很多人最先接触它是因为链路追踪，但它实际做的事情不只是一条 trace，而是把服务拓扑、指标、日志关联、性能分析这些内容放到了同一个观察面板里。

如果项目已经进入微服务阶段，排查问题经常需要跨服务、跨实例、跨中间件一起看，那么 SkyWalking 确实是一套很实用的工具。

参考资料