服务器SkyWalking教程：从零部署到链路验证

知识分享

2026-10-12 18:40

9 阅读

在服务器上部署 SkyWalking，本质是准备一个存储后端，再启动 OAP 和 UI 两个进程，最后给 Java 应用挂上 Agent 把链路数据推过来。
本文以 SkyWalking 9.x 搭配 Elasticsearch 的单机部署为例，适用于 Linux 服务器、需要监控 Java 微服务调用链的场景。

部署前要确认的环境条件

SkyWalking 的 OAP 和 UI 都依赖 JDK，Elasticsearch 虽然是独立进程，但同样建议用较新的 JDK 运行。
开始前先核对下面几项：

操作系统：常见发行版均可，本文命令以 CentOS 7/8 或 Ubuntu 20.04+ 为例。
JDK：OAP 需要 JDK 8 或 11，建议直接用 JDK 11。执行 java -version 确认输出。
内存：单机测试建议至少 4GB，OAP 和 Elasticsearch 都比较吃内存。
端口：默认需要 11800（gRPC 上报）、12800（HTTP 查询）、8080（UI）、9200（Elasticsearch）。用 ss -lntp 检查是否被占用。
目录规划：建议统一放在 /opt/skywalking 下，后面写脚本和排错都方便。

如果服务器内存偏小，可以先把 Elasticsearch 的堆内存调小，否则 OAP 很可能因为连不上存储而反复重启。

安装并启动 Elasticsearch 存储

SkyWalking 本身不存数据，链路数据都落到 Elasticsearch。
先下载对应平台的压缩包并解压：

cd /opt
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.0-linux-x86_64.tar.gz
tar -zxvf elasticsearch-7.17.0-linux-x86_64.tar.gz
mv elasticsearch-7.17.0 elasticsearch

Elasticsearch 不允许用 root 直接启动，需要创建普通用户：

useradd esuser
chown -R esuser:esuser /opt/elasticsearch

编辑 /opt/elasticsearch/config/elasticsearch.yml，至少确认这几项：

cluster.name: skywalking-es
node.name: node-1
network.host: 0.0.0.0
http.port: 9200
discovery.type: single-node

再调整 /opt/elasticsearch/config/jvm.options 里的堆内存，测试环境可以改成：

-Xms512m
-Xmx512m

切换用户启动：

su - esuser
/opt/elasticsearch/bin/elasticsearch -d

验证是否起来，返回集群信息即成功：

curl http://127.0.0.1:9200

启动 OAP 和 UI

下载 SkyWalking 发行包并解压：

cd /opt
wget https://archive.apache.org/dist/skywalking/9.2.0/apache-skywalking-apm-9.2.0.tar.gz
tar -zxvf apache-skywalking-apm-9.2.0.tar.gz
mv apache-skywalking-apm-bin skywalking

OAP 默认用 H2 存储，需要改成 Elasticsearch。
编辑 /opt/skywalking/config/application.yml，把 storage 部分切换为 elasticsearch：

storage:
  selector: ${SW_STORAGE:elasticsearch}
  elasticsearch:
    namespace: ${SW_NAMESPACE:""}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:127.0.0.1:9200}

UI 的地址配置在 /opt/skywalking/webapp/webapp.yml，确认端口和 OAP 地址：

server:
  port: 8080
spring:
  cloud:
    gateway:
      routes:
        - id: oap-route
          uri: lb://oap-service
          predicates:
            - Path=/graphql/**

分别启动 OAP 和 UI：

cd /opt/skywalking
bin/oapService.sh start
bin/webappService.sh start

启动后看日志确认状态：

tail -f logs/skywalking-oap-server.log

日志里出现 OAP starts up successfully 之类的字样，说明 OAP 已连上 Elasticsearch。
浏览器访问 http://服务器IP:8080 能看到 SkyWalking UI 界面即部署完成。

给 Java 应用挂上 Agent

SkyWalking 的链路数据靠 Agent 采集，OAP 只是接收方。
进入解压目录下的 agent 文件夹，启动 Java 应用时加上 JVM 参数：

java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \
     -Dskywalking.agent.service_name=my-order-service \
     -Dskywalking.collector.backend_service=127.0.0.1:11800 \
     -jar order-service.jar

如果应用跑在容器或别的机器上，把 backend_service 改成 OAP 所在服务器的 IP:11800，并确保安全组或防火墙放行该端口。
服务名 service_name 建议按业务命名，方便在 UI 里筛选。

验证链路是否真的上报成功

光看到 UI 打开并不代表数据通了，需要验证三件事：

应用启动后，访问一次业务接口，触发一次真实调用。
进入 UI 的「拓扑图」或「追踪」页面，看是否出现刚才的服务名和调用链。
在「服务」列表里能看到对应服务，点进去有响应时间和成功率曲线。

如果 UI 一直是空的，先查 OAP 日志有没有报错，再确认 Agent 的 backend_service 地址和端口是否可达：

telnet OAP服务器IP 11800

容易踩的坑

Elasticsearch 用 root 启动会直接报错退出，必须用普通用户。
OAP 连不上 ES 时不会立刻崩，而是反复重试并刷日志，看到大量连接失败要优先检查 clusterNodes 地址和 ES 是否已就绪。

Agent 的 jar 路径必须用绝对路径，相对路径在 systemd 或脚本里很容易失效。
多个应用共用同一个 Agent 目录没问题，但 service_name 要区分开，否则 UI 上会混成一个服务。

内存不足是最常见的隐性故障，表现为 OAP 或 ES 被系统 OOM Killer 杀掉，dmesg | grep -i kill 能看到记录，这种情况先降堆内存再重启。

常见疑问

SkyWalking 和 Elasticsearch 必须装在同一台机器吗？
不是，测试环境放一起最省事，生产环境建议分开部署，避免存储压力影响 OAP 采集。

Agent 需要和 OAP 版本完全一致吗？
大版本尽量对齐，跨大版本的协议可能不兼容，升级时建议 Agent 和 OAP 一起升。

部署完成后数据一直没上来怎么办？
按「应用是否触发过请求 → Agent 地址端口是否通 → OAP 日志是否报错 → ES 是否可写」的顺序排查，多数问题出在第一步和第二步。

整体流程就是先让 Elasticsearch 跑起来，再把 OAP 的存储指向它，启动 UI 后给应用挂 Agent，最后用一次真实请求验证链路。
环境不同时命令细节会有差异，但排查顺序可以照搬。

服务器 Apollo 配置中心部署教程：从环境准备到验证

服务器Pinpoint教程：零基础部署APM监控与排错