skywalking 启动失败因 jdk 版本过低（需 jdk 11+），应升级 jdk 并配置 java_home；连 es 失败需检查服务状态、网络绑定、认证及版本兼容性；agent 无数据需验证网络连通性、开启对应插件并调整采样率；ui 加载慢多因 es 性能瓶颈，需优化索引策略、ttl 清理及系统参数。
安装 SkyWalking 后启动失败，提示 java.lang.UnsupportedClassVersionError
这是最常见的起步卡点：SkyWalking 后端（apache-skywalking-apm-bin）默认要求 JDK 11+，但很多 Linux 服务器仍预装 JDK 8。错误信息里会明确带类似 Unsupported major.minor version 55.0 —— 这就对应 JDK 11。
实操建议：
- 先运行
java -version确认当前 JDK 版本； - 若低于 11，不要试图降级 SkyWalking（官方已停止维护 JDK 8 兼容版本），直接升级 JDK：推荐用
apt install openjdk-17-jdk（Ubuntu/Debian）或yum install java-17-openjdk-devel（CentOS/RHEL）； - 升级后检查
$JAVA_HOME是否指向新 JDK，必要时在/opt/skywalking/bin/startup.sh开头显式添加export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64（路径按实际调整）； - 别忽略
startup.sh的执行权限：chmod +x bin/startup.sh。
配置 OAP 服务连接 Elasticsearch 失败，日志反复打印 Connection refused
SkyWalking 默认用 H2 做内存存储，仅用于单机演示；生产必须换 Elasticsearch（或 TiDB、MySQL）。但连不上不是因为配置写错，往往卡在三个隐性环节。
实操建议：
- 确认 Elasticsearch 已真正运行：
curl -X GET "http://localhost:9200/_cat/health?v"要返回green或yellow； - 检查 ES 是否监听外部地址：默认只绑
127.0.0.1，需修改elasticsearch.yml中的network.host: 0.0.0.0并开放防火墙端口（如ufw allow 9200）； - 对应改 SkyWalking 的
config/application.yml：在storage:下启用elasticsearch段，并确保clusterNodes值是可路由的地址（比如http://es-host:9200，而非localhost——容器或跨主机部署时尤其关键）； - ES 7.x+ 需关闭
xpack.security.enabled: true，否则要额外配认证；SkyWalking 当前稳定版（v9.7）对 ES 8.x 支持仍有限，优先选 ES 7.17。
Java 应用接入 agent 后无数据上报，UI 显示 “No data”
agent 启动看似成功（日志有 Agent boot success），但 UI 里找不到服务名、Trace 完全空白。问题通常不在 agent 本身，而在网络通路或探针粒度。
实操建议：
- 检查 agent 日志：
logs/skywalking-api.log里是否有Failed to send data to backend—— 这说明 OAP 地址没通，确认-Dskywalking.collector.backend_service=your-oap-host:11800中的 host 可被 Java 进程解析和访问（别用localhost）； - 确认 OAP 的 gRPC 端口（默认
11800）未被防火墙拦截：telnet your-oap-host 11800必须通； - agent 默认只采集 HTTP、gRPC 等标准协议，若应用走 Dubbo、RocketMQ 或自定义 RPC，需手动开启对应插件：进
agent/config/agent.config，取消注释并设plugin.dubbo-tracing = on等； - 低流量应用可能因采样率导致数据稀疏，临时调高：
agent.sample_n_per_3_secs = 1000（慎用于生产）。
UI 页面加载慢或报 500，Network 面板显示 /graphql 请求超时
这不是前端问题，而是 OAP 查询压力过大或 ES 查询效率低。尤其当历史数据超过 7 天、索引未按天轮转、或查询跨度拉太长（如“最近 30 天”）时，ES 会拖垮整个链路。
实操建议：
- 在
config/application.yml中强制设置 ES 索引策略：elasticsearch:下加indexShardsNumber: 2和indexReplicasNumber: 0（单节点测试环境），避免默认 5 分片造成资源浪费； - 启用 TTL 清理：在 same 文件中配置
recordDataTTL: 3（单位：天），让 OAP 主动删除过期索引； - 限制 UI 查询范围：在
webapp/webapp.yml中调小defaultQueryTimeWindow: 3600（秒），避免用户一上来就查 24 小时； - 别在一台机器上同时跑 ES、OAP、UI —— 内存争抢会导致 GC 频繁，OAP 日志出现
Full GC就得拆。
最常被忽略的是：Elasticsearch 的 vm.max_map_count 未调高，导致分片创建失败，表面看是 UI 慢，根源却是 ES 无法分配新索引。上线前务必执行 sysctl -w vm.max_map_count=262144 并写入 /etc/sysctl.conf。
