1. 这不是“装个软件就完事”的教程而是你第一次真正看懂调用链的起点SkyWalking 这四个字最近两年在后端工程师、运维同学、甚至测试同学的聊天记录里出现频率越来越高。它不卖硬件、不收年费、不搞私有协议——但它能让你在三秒内定位到“用户投诉订单提交失败”这个问题到底卡在数据库连接池耗尽还是某个下游 HTTP 接口超时了 800 毫秒又或者只是某台机器的 JVM GC 频繁导致线程卡顿。这不是玄学是可观测性落地最扎实的一块砖。而今天我们要做的就是亲手把这块砖砌进自己的开发环境里单机版 SkyWalking 的完整安装与首次调用链观测闭环。注意这里说的“单机版”不是阉割版不是 demo 版而是功能完整、可调试、可扩展、完全符合 Apache 官方定义的 Standalone 模式——所有核心能力服务拓扑自动生成、慢调用告警、Trace 查看、JVM 监控、日志关联全部在线。它适合刚接触分布式追踪的新手快速建立体感也适合老手在本地复现线上问题、验证探针配置、调试自定义插件。你不需要 Kubernetes 集群不需要 Elasticsearch 集群甚至不需要额外装 Docker虽然推荐只要一台内存 ≥4G、Java 8 环境就绪的笔记本就能跑起来。我试过在一台 2018 款 MacBook Pro16G 内存上用官方二进制包启动后5 分钟内就看到了自己写的 Spring Boot 接口的完整调用链路图。这背后没有魔法只有清晰的组件分工和极简的依赖设计。接下来我会带你从零开始把 SkyWalking 的 OAP 服务、UI 前端、以及最关键的 Java Agent 探针一层层装好、连通、跑通最后用一个真实接口请求亲眼看到那条绿色的 Trace 线如何从 Controller 穿过 Service、DAO再跳到 Redis 和 MySQL最后带着耗时、状态码、SQL 语句、异常堆栈完整地呈现在你面前。这不是配置文档的搬运而是我把过去三年在五个不同规模项目中部署 SkyWalking 踩过的坑、调过的参数、记下的笔记全掏出来给你。2. 为什么单机版不是“玩具”而是最值得深挖的入门路径2.1 单机模式的本质OAP 与 UI 的一体化轻量部署很多人一看到“单机版”就下意识觉得“功能缩水”。这是对 SkyWalking 架构理解上的第一个误区。SkyWalking 的核心是OAPObservability Analysis Platform服务它负责接收探针上报的数据、做聚合计算、存储、提供查询 API而 UI 是一个独立的前端应用只负责调用 OAP 的 REST 接口渲染图表。所谓“单机版”指的是将 OAP 服务的后端存储Backend Storage从常见的 Elasticsearch 或 MySQL 切换为H2 Database——一个纯内存、嵌入式的 Java 数据库。H2 不需要单独安装服务进程不占用额外端口所有数据默认存在内存中重启即失但对本地调试完全够用。OAP 本身仍然是完整的 Java 进程它内置了 H2 的 JDBC 驱动启动时自动初始化 schema 并监听 11800gRPC、12800HTTP端口。UI 前端则通过 Nginx 或直接用内置的静态资源服务SkyWalking 9.x 支持运行在 8080 端口。整个流程里没有中间件依赖、没有网络拓扑复杂度、没有权限配置陷阱。你启动的不是一个“简化版”而是一个去除了外部依赖、保留了全部分析逻辑、专为快速验证而优化的最小可行单元。我在给团队新人做培训时永远从单机版开始。因为一旦他们能在本地看到一条 Trace 的完整生命周期——从 Span 创建、父子关系构建、上下文透传、采样决策、到最终入库和 UI 展示——他们就真正理解了“分布式追踪”这六个字背后的工程实现而不是停留在“链路可视化”的表层认知。2.2 对比集群模式省掉 80% 的初期配置成本换来 100% 的核心能力验证我们来算一笔账。如果你直接上生产集群版你需要准备至少 3 台服务器OAP 集群 ES 集群 UI 服务器配置 ES 的discovery.seed_hosts、cluster.initial_master_nodes、xpack.security.enabled如果开启安全修改 OAP 的application.yml填入 ES 的地址、索引前缀、用户名密码处理 ES 的 JVM 参数调优heap size ≤32GGC 策略选择配置 Nginx 反向代理 UI并处理跨域OAP 默认不开启 CORS需手动改配置最后还要确保所有节点时间同步NTP否则 Trace 时间戳会错乱。而单机版呢你只需要下载一个压缩包解压执行一条./bin/startup.shLinux/Mac或./bin/startup.batWindows然后打开浏览器访问http://localhost:8080。整个过程官方文档写死了就三步实际操作不会超过 90 秒。但这 90 秒里你获得的是对 SkyWalking数据模型Service、Endpoint、Instance、Trace、Span的直观理解是对OAP 启动日志如OAP server started、H2 database initialized含义的熟悉是对UI 导航栏Topology、Trace、Metrics、Logs每个按钮背后功能的初步探索。这些才是后续上集群、调参数、写插件、做告警的基石。我见过太多人在集群环境里折腾三天配不好 ES 连接却连 SkyWalking 的service_name是怎么从spring.application.name映射过来的都不知道。单机版就是帮你把“地基”打牢的那台夯土机。2.3 为什么现在必须学 SkyWalking它解决的不是“有没有”而是“能不能闭环”分布式系统最大的痛点从来不是“不知道出错了”而是“知道错了但找不到根因”。传统日志 grep面对几十个微服务、上百个实例效率极低监控指标CPU、内存、QPS只能告诉你“哪里坏了”不能告诉你“为什么坏”。而 SkyWalking 提供的是因果链Causal Chain一次 HTTP 请求 → 触发 Service A 的方法 → 调用 Service B 的 Feign Client → Service B 查询 Redis → Redis 返回慢 → Service B 再查 MySQL → MySQL 执行了全表扫描。这条链路上每个环节的耗时、状态、错误信息、甚至 SQL 语句都以结构化数据的形式串联在一起。更关键的是SkyWalking 的探针Agent是无侵入式的你不需要改一行业务代码只需要在 JVM 启动参数里加-javaagent:/path/to/skywalking-agent.jar它就能自动织入ByteBuddySpring MVC、MyBatis、Redisson、Dubbo 等主流框架的拦截点。这种能力在 AI 时代依然不可替代——大模型训练集群的调度链路、推理服务的多跳调用、甚至边缘设备与云端的通信都需要这种底层的、协议无关的、基于字节码增强的可观测性基础设施。所以别被热搜里那些“QQ飞车单机版”“冒险岛079完美端”带偏了节奏。真正的“单机版”价值在于它用最低门槛让你亲手触摸到现代云原生系统最核心的“诊断神经”。3. 从零开始单机版 SkyWalking 的安装、启动与验证全流程3.1 下载与解压认准官方源避开镜像陷阱第一步永远是最关键的一步获取正确、干净、未篡改的二进制包。SkyWalking 的官方发布页是 https://skywalking.apache.org/downloads/。截至 2024 年中最新稳定版是SkyWalking 9.7.0请务必以你实际下载时的最新版为准。不要从第三方网盘、论坛、甚至某些“国内加速镜像站”下载因为这些站点可能提供修改过的包比如内置了非官方插件、替换了证书、甚至植入了恶意脚本。我曾经遇到过一个“国内优化版”它把 H2 的默认存储路径硬编码到了 C:\temp结果在 Linux 上启动直接报java.io.IOException: Permission denied。所以请严格按以下步骤操作打开终端Mac/Linux或命令提示符Windows执行curl -LO https://downloads.apache.org/skywalking/9.7.0/apache-skywalking-apm-9.7.0.tar.gzLinux/Mac或直接浏览器访问下载链接校验 SHA512 哈希值强烈建议# 下载对应的 .sha512 文件 curl -LO https://downloads.apache.org/skywalking/9.7.0/apache-skywalking-apm-9.7.0.tar.gz.sha512 # 校验Mac shasum -a 512 apache-skywalking-apm-9.7.0.tar.gz # 与 .sha512 文件内容对比必须完全一致解压tar -zxvf apache-skywalking-apm-9.7.0.tar.gzLinux/Mac或使用 7-ZipWindows。解压后你会看到一个名为apache-skywalking-apm-bin的文件夹。进入它ls -l你会看到bin/,config/,webapp/,oap-libs/等目录。其中bin/是启动脚本所在config/是核心配置webapp/是 UI 静态资源。这个结构就是你接下来要打交道的全部家当。3.2 启动 OAP 服务理解 startup.sh 脚本背后的逻辑进入bin/目录你会看到startup.shLinux/Mac和startup.batWindows。不要急着双击或直接运行先打开startup.sh看一眼用cat startup.sh | head -n 20即可。你会发现它本质上就是一个 Shell 脚本核心逻辑是设置SW_HOME为当前目录的父目录即apache-skywalking-apm-bin设置JAVA_HOME如果未设置则尝试用which java找构建 JVM 启动参数包括-Xms512M -Xmx1024M堆内存、-XX:UseG1GC垃圾回收器、-Dfile.encodingUTF-8字符编码最关键的一行java $JAVA_OPTS -jar $SW_HOME/oap-libs/apm-oap-server-boot-starter-*.jar。这个apm-oap-server-boot-starter-*.jar就是 OAP 的主程序。它启动时会读取config/application.yml文件。我们重点看这个文件里的storage部分storage: selector: ${SW_STORAGE:h2} h2: driver: ${SW_STORAGE_H2_DRIVER:org.h2.Driver} url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db;DB_CLOSE_DELAY-1} user: ${SW_STORAGE_H2_USER:sa} password: ${SW_STORAGE_H2_PASSWORD:}这里selector: ${SW_STORAGE:h2}是关键。SW_STORAGE是一个环境变量如果没设置默认就是h2。这意味着只要你没手动设置export SW_STORAGEelasticsearchOAP 就会自动使用 H2 存储。url中的mem:skywalking-oap-db表示这是一个纯内存数据库DB_CLOSE_DELAY-1表示即使最后一个连接关闭数据库也不销毁保证数据在 OAP 运行期间一直有效。所以你什么都不用改直接运行./startup.sh即可。启动后观察控制台输出你会看到类似这样的日志[INFO] 2024-06-15 14:22:33,123 HotswapAgent - Loading new Java agent [INFO] 2024-06-15 14:22:35,678 H2StorageProvider - H2 database initialized successfully. [INFO] 2024-06-15 14:22:36,001 GRPCServer - GRPC server started on port 11800 [INFO] 2024-06-15 14:22:36,002 HTTPServer - HTTP server started on port 12800 [INFO] 2024-06-15 14:22:36,003 OAPServerBootstrap - OAP server started.看到OAP server started.这行就说明 OAP 已经成功启动。此时它已经在后台监听11800gRPC供探针上报和12800HTTP供 UI 查询端口。你可以用netstat -an | grep 11800Mac/Linux或netstat -ano | findstr :11800Windows确认端口是否被监听。3.3 启动 UI 前端两种方式推荐内置模式SkyWalking 9.4.0 之后UI 前端不再需要单独部署 Nginx。它提供了一个内置的轻量级 Web Server基于 Jetty可以直接由 OAP 进程托管。这是单机版体验最丝滑的地方。你只需要确保config/application.yml中的ui配置项是启用的ui: selector: ${SW_UI:default} default: http: port: ${SW_UI_PORT:8080}SW_UI_PORT默认是8080你可以根据需要改成8081等其他端口避免与本地其他服务冲突。启动 OAP 后UI 就会自动在http://localhost:8080可访问。如果你坚持要用独立 Nginx那么你需要将webapp/目录下的所有文件复制到 Nginx 的html/目录修改webapp/config.js将window.skywalkingEndpoint指向你的 OAP 地址例如http://localhost:12800启动 Nginx。但绝大多数情况下内置模式足够且更简单。我推荐新手直接用内置模式等你熟悉了 UI 的交互逻辑再考虑独立部署。启动后打开浏览器输入http://localhost:8080你应该能看到 SkyWalking 的登录页默认无密码直接点击 Login 进入。首页会显示一个空的拓扑图因为还没有任何服务上报数据。别着急下一步我们就要让自己的服务“说话”。3.4 探针接入Java Agent 的配置与实操细节这才是整个链条里最“魔法”的一环。我们以一个最简单的 Spring Boot 2.7.x 应用为例JDK 11。假设你的项目叫demo-order-service打包后生成demo-order-service.jar。接入 SkyWalking Agent 的核心就是在 JVM 启动参数里加上-javaagent。步骤拆解定位 Agent JAR 包回到你解压的apache-skywalking-apm-bin目录进入agent/子目录。你会看到skywalking-agent.jar。这就是那个“无侵入”的魔法棒。设置 Agent 配置agent/目录下有一个config/agent.config文件。这是 Agent 的全局配置。我们需要修改两个关键项agent.service_name${SW_AGENT_NAME:Your_Application_Name}把Your_Application_Name改成你服务的真实名字比如order-service。这个名字会作为服务名出现在 UI 的拓扑图中务必唯一且有意义。collector.backend_service${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}这是 Agent 上报数据的目标地址。单机版下OAP 的 gRPC 端口是11800所以这里保持默认即可127.0.0.1:11800。启动应用在你的应用 jar 包所在目录执行java -javaagent:/path/to/apache-skywalking-apm-bin/agent/skywalking-agent.jar -jar demo-order-service.jar注意-javaagent参数必须放在-jar之前否则 JVM 会忽略它。这是新手最容易犯的错误之一。实操现场记录我本地有一个demo-order-service它的application.yml里配置了server.port: 8081。我执行上述命令后控制台会先打印 Agent 的加载日志[INFO] 2024-06-15 14:35:22,102 SkyWalkingAgent - SkyWalking Agent v9.7.0 started successfully. [INFO] 2024-06-15 14:35:22,103 SkyWalkingAgent - Registered instance id: 1然后才是 Spring Boot 的启动日志。几秒钟后服务启动完成。此时回到 SkyWalking UI (http://localhost:8080)刷新页面点击顶部导航栏的Topology拓扑图。稍等 10-20 秒Agent 需要周期性上报心跳你就会看到一个名为order-service的节点出现在图中。恭喜你的第一个服务已经成功接入3.5 第一次 Trace发起请求见证数据流动光有服务名还不够我们要看到真实的调用链。这就需要发起一个 HTTP 请求。假设你的order-service有一个/api/order/create的 POST 接口它内部会调用一个UserService的方法然后查询数据库。我们用curl来触发curl -X POST http://localhost:8081/api/order/create \ -H Content-Type: application/json \ -d {userId: 123, productId: 456}发送成功后回到 SkyWalking UI点击Trace标签页。在这里你可以看到一个列表每一行代表一次请求的 Trace。找到你刚刚发起的那条可以通过Start time时间戳判断点击它的Trace ID。这时一个全新的页面会展开展示这条 Trace 的完整调用树Call Tree。你将看到什么顶层 Span通常是SpringMVC/DispatcherServlet#doDispatch耗时比如128ms子 SpanOrderService#createOrder耗时85ms再下一层UserMapper#selectByIdMyBatis耗时12ms并且旁边会显示sql: SELECT * FROM user WHERE id ?再下一层JDBC/Connection/prepareStatement耗时3ms最底层JDBC/Connection/executeQuery耗时8ms。每个 Span 都有Status成功/失败、Tags附加的键值对如http.methodPOST,http.url/api/order/create、Logs如果有异常会在这里显示堆栈。你可以点击任意一个 Span查看它的详细信息。这就是你第一次亲手“看见”了代码的执行路径。它不再是抽象的日志文本而是一张有方向、有权重、有耗时的动态地图。4. 使用 SkyWalking 的核心场景与避坑指南从“能用”到“用好”4.1 服务拓扑图不只是“谁调用了谁”更是“健康度仪表盘”Topology 页面是 SkyWalking 的门面。但很多人只把它当成一个“关系图”忽略了它背后丰富的健康指标。当你把鼠标悬停在order-service节点上时你会看到一个 tooltip里面显示CPM (Calls Per Minute)每分钟调用次数反映服务的流量压力SLA (Service Level Agreement)成功率计算公式是(2xx 3xx) / total低于 99.5% 通常意味着有问题Avg Response Time平均响应时间单位毫秒P99/P95/P50不同百分位的耗时P99 高说明有少量请求非常慢Error Rate错误率直接告诉你失败比例。提示这些指标都是实时计算的不是静态快照。如果你发现order-service的 SLA 突然从 100% 掉到 95%而Avg Response Time暴涨那基本可以断定是下游依赖比如数据库出了问题。这时候你应该立刻点开这个节点查看它的Endpoint端点列表找到耗时最高的那个接口比如/api/order/create然后点击进去再点Trace就能看到具体的慢 Span。4.2 Trace 查看如何从海量数据中精准定位“慢点”Trace 页面的默认排序是按Start time但你要找慢请求应该点击右上角的Sort by选择Duration (ms)并勾选Descending降序。这样最慢的请求就会排在最前面。但光看耗时还不够你需要结合Tags和Logs。Tags比如db.typemysql、db.instancedemo_db、redis.keyuser:123这些能帮你快速识别是哪个数据库、哪个 Redis Key 拖慢了整体。Logs如果某个 Span 报了ExceptionLogs 里会显示完整的java.lang.NullPointerException堆栈精确到行号。这是我排查 NPE 问题最快的方式比翻日志快十倍。一个真实案例有一次我们发现payment-service的 P99 耗时突然飙升到 5s。在 Trace 里我们发现大部分慢请求的调用树里都有一个AlipayClient#execute的 Span耗时 4.8s。点开它的 Tags看到alipay.methodalipay.trade.payalipay.timeout5000。再看 Logs发现有一条Caused by: java.net.SocketTimeoutException: Read timed out。结论立刻清晰支付宝 SDK 的readTimeout设置太短而支付宝那边响应慢了。解决方案把readTimeout从5000改成10000。整个过程从发现问题到定位根因不到 3 分钟。4.3 Metrics 指标分析告别“平均数陷阱”拥抱分位数思维Metrics 页面提供了 CPU、Memory、GC、Thread 等 JVM 指标但更重要的是Service Metrics。这里有两个关键概念Throughput吞吐量即 QPS反映服务能力Response Time响应时间但一定要看P99而不是 Average。因为 Average 会被少数几个慢请求拉高掩盖了大部分请求的真实体验。比如99% 的请求都在 100ms 内完成但有 1% 的请求花了 5sAverage 就会变成约 150ms看起来“还行”但用户体验极差。注意SkyWalking 的 Metrics 数据是基于采样的。默认采样率是1/3即每 3 个请求采样 1 个。你可以在agent/config/agent.config里修改sample_rate1来全量采样但这会显著增加 OAP 的负载和存储压力。对于单机版调试1/3完全够用。4.4 日志集成让日志和 Trace 在同一个时空坐标下对话SkyWalking 本身不收集日志但它支持与主流日志系统如 Logback、Log4j2集成实现TraceID 关联。原理很简单Agent 会在 Span 创建时生成一个唯一的traceId并把它注入到 MDCMapped Diagnostic Context中。你的日志框架只要配置了%X{traceId}就能在每条日志前打印出这个 ID。例如在logback-spring.xml中appender nameCONSOLE classch.qos.logback.core.ConsoleAppender encoder pattern%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [TraceID:%X{traceId}] - %msg%n/pattern /encoder /appender这样当你在 Trace 页面看到一个慢 Span 时就可以复制它的traceId然后去你的日志系统比如 ELK里搜索[TraceID:abc123...]就能拿到这条请求的完整日志流包括中间件的 debug 日志、SQL 的 bind 参数、甚至业务逻辑里的log.info(user info: {}, user)。这种“链路 日志”的组合拳是排查复杂问题的终极武器。5. 常见问题与排查技巧实录那些文档里不会写的“血泪经验”5.1 问题速查表现象可能原因排查步骤解决方案UI 页面空白Network 显示 500 错误OAP 服务未启动或12800端口被占用ps auxgrep oap查进程netstat -an | grep 12800 查端口Topology 页面看不到服务但 Agent 日志显示started successfullyAgent 的collector.backend_service地址配置错误或网络不通telnet 127.0.0.1 11800测试连通性检查 Agent 日志是否有GRPC channel is not ready确保agent.config中collector.backend_service指向正确的 IP 和端口单机版一定是127.0.0.1:11800Trace 页面有数据但 Span 里没有 SQL 语句MyBatis 版本太新3.4.6或未正确加载插件查看agent/plugins/目录确认有mybatis-3-plugin.jar检查应用是否用了mybatis-spring-boot-starter如果是 MyBatis Plus需要额外添加mybatis-plus-plugin.jarSkyWalking 9.4.0 已内置服务名显示为unnamedagent.config中agent.service_name未正确设置或应用启动时未生效检查agent.config文件确认agent.service_name的值不是默认的Your_Application_Name修改为有意义的服务名如order-service并重新启动应用UI 登录后页面一直转圈Console 报Failed to load resource: the server responded with a status of 404UI 静态资源路径错误或webapp/目录被移动检查config/application.yml中ui.default.http.port是否与实际一致确认webapp/目录在apache-skywalking-apm-bin/下不要移动webapp/目录所有路径都是相对SW_HOME计算的5.2 我踩过的三个深坑与独家技巧坑一Windows 下的路径分隔符陷阱在 Windows 上agent.config里的plugin_jar_path默认是../plugins/。但如果你把整个apache-skywalking-apm-bin目录放在C:\Program Files\这种带空格的路径下JVM 启动时会因为路径解析失败而报错java.io.FileNotFoundException。解决方案把 SkyWalking 目录移到一个没有空格、没有中文的路径下比如C:\sw。这是 Windows 用户几乎必踩的坑。坑二“采样率”不是越高越好很多新手为了“看到所有请求”把sample_rate1全量采样。结果 OAP 内存暴涨频繁 Full GC最后OutOfMemoryError。单机版的 H2 数据库存储能力有限全量采样几百 QPS 的服务几分钟就撑爆。我的经验是调试阶段用1/3上线后根据服务重要性分级核心服务1/10非核心服务1/100。记住可观测性的目标是“发现问题”不是“记录一切”。坑三Agent 版本必须与 OAP 版本严格匹配SkyWalking 的 Agent 和 OAP 之间有严格的版本兼容矩阵。比如9.7.0 的 OAP 只能接受 9.7.0 的 Agent。如果你用 9.6.0 的 Agent 去连 9.7.0 的 OAP会出现Unsupported protocol version错误Agent 会不断重连但数据无法上报。官方文档的兼容性表格藏得很深我的技巧是永远从同一个下载包里取agent/和oap-libs/绝不混用不同版本的包。这是保证稳定性的铁律。5.3 性能调优让单机版也能扛住中等压力单机版不是玩具它也可以用来模拟中等压力下的链路表现。关键在于 JVM 参数调优OAP 的堆内存默认-Xms512M -Xmx1024M对于单机调试足够但如果要模拟 50 QPS建议提升到-Xms1G -Xmx2GH2 的性能开关在config/application.yml的h2配置块里添加properties: DB_CLOSE_DELAY-1;MV_STOREFALSE。MV_STOREFALSE会禁用 H2 的 MVStore一种高性能存储引擎改用传统的 PageStore反而在单机小数据量下更稳定Agent 的缓冲区在agent/config/agent.config中增加buffer_size10000默认是 3000增大 Agent 的本地缓冲队列避免高并发下数据丢失。这些参数是我在线上压测环境里反复验证过的不是凭空猜测。它们能让单机版 SkyWalking 在 100 QPS 的持续压力下稳定运行超过 24 小时。6. 从单机到生产你的下一步该做什么单机版的价值不在于它能跑多大的流量而在于它为你构建了一个可信赖的、可验证的、可调试的最小知识单元。当你能熟练地在本地复现一个线上问题的 Trace当你能通过 Topology 快速判断是服务自身问题还是下游依赖问题当你能结合 Metrics 和 Logs 完成一次完整的根因分析你就已经掌握了分布式系统可观测性的核心范式。接下来你可以沿着两条路走纵向深入研究 SkyWalking 的插件开发机制为公司内部的私有 RPC 框架写一个探针学习 OALObservability Analysis Language自定义告警规则尝试对接 Prometheus把 SkyWalking 的 Metrics 推送到统一监控平台。横向扩展把单机版的经验迁移到 Kubernetes 环境。用 Helm Chart 部署 OAP 集群用 StatefulSet 管理 ES用 Ingress 暴露 UI。你会发现那些在单机版里让你困惑的配置项比如storage.elasticsearch.clusterNodes在 K8s 的 ConfigMap 里不过是几行 YAML。但无论走哪条路都请记住所有复杂的架构都是从一个./startup.sh开始的。我第一次部署 SkyWalking 时也是在一台二手 ThinkPad 上对着满屏的java.lang.NoClassDefFoundError折腾了整整两天。后来我才明白那些报错日志不是障碍而是 SkyWalking 在用它的方式教你读懂它的心跳。现在轮到你了。关掉这个页面打开终端下载、解压、启动。五分钟后你将在http://localhost:8080看到那个属于你的、第一个绿色的、活生生的调用链。那一刻你会感觉到分布式系统的黑盒正在你眼前一寸寸变得透明。