拓冰网站定制 
1. 为什么OAP和UI必须分开搭——从SkyWalking架构本质说起很多人第一次接触SkyWalking看到“OAP”和“UI”两个词并列下意识就以为是“一个安装包、一键启动”的傻瓜式操作。我当年在金融客户现场部署时也这么想结果在测试环境跑了三天链路数据始终不进UI排查日志发现OAP服务早就在后台静默崩溃了——而UI界面还在那儿稳稳地刷着“Loading…”。这不是配置错了是根本没理解SkyWalking的分层契约设计逻辑。SkyWalking不是传统单体监控系统它是一个典型的“采集-处理-展示”三层解耦架构。OAPObservability Analysis Platform是后端分析平台负责接收探针上报的Trace、Metric、Log原始数据做聚合、采样、拓扑计算、告警判定等重计算任务UI只是前端展示层它不碰任何原始数据只通过REST API向OAP发起查询请求把OAP返回的JSON结构化数据渲染成图表和列表。这就像厨房OAP和餐厅UI的关系厨师在后厨切菜炒菜数据清洗与计算服务员UI只负责把做好的菜端上桌并不参与烹饪过程。你不能指望让服务员去切肉丝更不能因为菜没端上来就怪厨师没开火——得先确认后厨有没有通电、燃气有没有开、锅里有没有油。这种分离带来三个硬性约束第一网络连通性必须双向打通。UI容器必须能访问OAP的12800端口默认gRPC监听端口用于内部通信和11800端口默认HTTP REST API端口UI调用入口反过来OAP不需要访问UI但OAP自身依赖的存储如Elasticsearch或MySQL必须对OAP容器可达。很多初学者卡在“UI显示空白”90%是因为UI容器内执行curl -v http://oap:11800/oap/v3/services返回Connection refused根源是Docker网络未桥接或K8s Service DNS解析失败。第二版本强绑定不可跨代混用。SkyWalking官方明确声明UI版本必须与OAP版本严格一致。比如OAP 9.7.0只能配UI 9.7.0不能用UI 9.6.0或9.8.0。这是因为REST API的路径、参数、返回字段在小版本迭代中可能微调——UI代码里写死的/v3/topology接口在OAP 9.8.0里可能已重命名为/v3/topology/graph。我见过最典型的事故运维同学图省事用最新版UI镜像覆盖旧环境结果所有服务拓扑图变成404查了半天才发现OAP日志里反复打印Unmatched request path: /v3/topology。第三资源分配策略截然不同。OAP是CPU和内存密集型服务一个中等规模集群50个Java应用实例每秒1000条Span的OAP进程JVM堆内存建议设为4G~8GGC频率直接影响数据落盘延迟而UI是轻量级静态资源服务Nginx容器跑128MB内存绰绰有余。若把两者塞进同一个Pod或同一台虚拟机OAP GC停顿会直接拖垮UI响应造成“UI界面卡顿”——这根本不是前端性能问题是后端资源争抢导致的假性卡顿。所以“搭建”这个词在SkyWalking语境里本质是构建一条稳定的数据流管道探针 → OAP接收/计算/存储→ UI查询/渲染。OAP是管道的心脏UI是管道末端的水龙头。心脏不跳水龙头再漂亮也流不出一滴水。接下来的所有步骤都围绕这个核心认知展开。2. OAP服务落地实操从零配置到生产就绪的七步法OAP的搭建绝非docker run一条命令能搞定。我经历过三次大规模生产部署电商大促监控、银行核心系统全链路追踪、IoT设备指标中心每次都要面对不同的基础设施约束。下面这套“七步法”是我从踩坑中提炼出的最小可行路径每一步都附带真实场景中的取舍逻辑和避坑点。2.1 第一步存储选型——ES、MySQL、H2到底选谁OAP支持多种后端存储但选择直接决定后续运维成本。我们用一张表对比三种主流选项在真实业务中的表现存储类型适用场景数据保留策略典型配置关键风险Elasticsearch 7.10中大型生产环境日Span量 1亿按索引生命周期自动rollover支持冷热分层3节点ES集群每个节点16G内存SSD磁盘ES JVM堆内存严禁超过32GLucene限制否则Full GC频繁需关闭swap并调大vm.max_map_count262144MySQL 5.7小型环境或需要SQL灵活查询手动按月分表依赖定时脚本清理8C16G单实例InnoDB引擎innodb_buffer_pool_size12G不支持原生拓扑图计算需OAP开启mysql-storage插件并配置topology.enabledtrue高并发写入易锁表H2 Database本地开发/POC验证内存模式重启丢失或文件模式单机持久化-Dskywalking.storage.h2.file_path/data/h2严禁用于任何测试以上环境文件锁机制在容器重启时极易损坏数据库文件我曾因此丢失三天压测数据提示金融客户强制要求审计日志留存180天我们最终选用ESILM策略。但首次部署时误用了ES 8.x结果OAP启动报错Unsupported Elasticsearch version: 8.x——SkyWalking 9.7.0官方仅认证ES 7.10~7.17。降级ES版本后又因ES安全插件Search Guard未开放cluster:monitor/nodes/info权限导致OAP日志狂刷Failed to fetch node info。最终解决方案是在ESroles.yml中为skywalking用户添加cluster_monitor内置角色。2.2 第二步配置文件精简——删掉80%的默认项SkyWalking OAP的application.yml有近500行默认开启所有模块。生产环境中必须做减法。我整理出一份“最小必要配置模板”仅保留核心功能# application.yml - 生产精简版 storage: selector: ${SW_STORAGE:elasticsearch} elasticsearch: nameSpace: ${SW_NAMESPACE:} clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:es-node1:9200,es-node2:9200} protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:http} trustStorePath: ${SW_STORAGE_ES_TRUST_STORE_PATH:} # ↓ 关键关闭无用模块减少线程和内存占用 enableRecordData: ${SW_STORAGE_ES_ENABLE_RECORD_DATA:true} # 必须true否则Span不入库 enableLogData: ${SW_STORAGE_ES_ENABLE_LOG_DATA:false} # 日志功能默认关 enableTopologyData: ${SW_STORAGE_ES_ENABLE_TOPOLOGY_DATA:true} # 拓扑图必需 enableAlarmData: ${SW_STORAGE_ES_ENABLE_ALARM_DATA:true} # 告警必需 enableBrowserData: ${SW_STORAGE_ES_ENABLE_BROWSER_DATA:false} # 前端监控关 enablePerformanceData: ${SW_STORAGE_ES_ENABLE_PERFORMANCE_DATA:true} # 性能指标开 core: selector: ${SW_CORE:default} default: # ↓ 关键调整采样率避免OOM samplingRate: ${SW_CORE_DEFAULT_SAMPLING_RATE:10000} # 每10000条Span采1条压测时可调为100 # ↓ 关键禁用不必要分析器 ignoreSuffix: ${SW_CORE_DEFAULT_IGNORE_SUFFIX:.jpg,.png,.gif,.css,.js,.html} # 静态资源忽略注意samplingRate参数常被误解为“百分比”。实际它是采样间隔值为10000表示每收到10000条Span记录第1条其余丢弃。若设为1则100%全量采集中小集群可能瞬间打爆ES磁盘。我们线上集群将此值设为5000既保证关键链路不丢失又将ES日增数据量控制在80GB以内。2.3 第三步JVM参数调优——别让GC成为性能瓶颈OAP的JVM配置是隐形杀手。默认-Xms512m -Xmx512m在生产环境必然OOM。根据我们压测数据给出分级建议小型环境 20个服务实例-Xms2g -Xmx2g -XX:UseG1GC -XX:MaxGCPauseMillis200中型环境20~100实例-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis300 -XX:G1HeapRegionSize4M大型环境 100实例-Xms6g -Xmx6g -XX:UseG1GC -XX:MaxGCPauseMillis400 -XX:G1HeapRegionSize4M -XX:UnlockExperimentalVMOptions -XX:G1MaxNewSizePercent60实测教训某次大促前运维同事将JVM堆设为-Xms8g -Xmx8g但未调G1HeapRegionSize。结果OAP在峰值QPS 1200时G1 GC频繁触发Mixed GC每次停顿达1.2秒导致探针上报超时重试形成雪崩。后将G1HeapRegionSize从默认2M调至4MMixed GC频率下降60%停顿稳定在300ms内。2.4 第四步Docker部署——镜像选择与网络配置官方提供两种镜像apache/skywalking-oap-server标准版和apache/skywalking-oap-server:alpine精简版。生产环境必须用标准版——Alpine版缺失glibc某些国产中间件探针如东方通TongWeb上报时会因java.lang.UnsatisfiedLinkError崩溃。Docker Compose关键配置如下以ES存储为例version: 3.8 services: oap: image: apache/skywalking-oap-server:9.7.0 container_name: skywalking-oap restart: unless-stopped ports: - 11800:11800 # UI调用API端口 - 12800:12800 # gRPC内部通信端口 - 11801:11801 # Prometheus指标暴露端口可选 environment: - SW_STORAGEelasticsearch - SW_STORAGE_ES_CLUSTER_NODESes-node1:9200,es-node2:9200 - SW_CORE_DEFAULT_SAMPLING_RATE5000 - JAVA_OPTS-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis300 volumes: - ./config/application.yml:/skywalking/config/application.yml # 挂载精简配置 - ./logs:/skywalking/logs # 日志持久化 networks: - skywalking-net depends_on: - es-node1 - es-node2关键细节ports段必须显式暴露11800和12800。很多教程只暴露11800结果UI能访问但拓扑图空白——因为UI首次加载会调用/v3/topology走11800但拓扑图的实时刷新依赖/v3/topology/refresh走12800的gRPC长连接。若12800未暴露UI会持续轮询失败。2.5 第五步健康检查——用curl写个真·可用性探测K8s或Docker Swarm中必须配置精准的健康检查。OAP的/actuator/health端点返回UP仅代表进程存活不代表数据链路通畅。我们自研了一个探测脚本嵌入Liveness Probe#!/bin/bash # health-check.sh # 检查三项OAP进程、ES连通性、核心API可用性 if ! curl -sf http://localhost:12800/actuator/health /dev/null; then exit 1 fi if ! curl -sf http://localhost:11800/oap/v3/services?limit1 /dev/null; then exit 1 fi # 检查ES是否可写尝试创建临时索引 if ! curl -sf -XPUT http://es-node1:9200/test-health-$(date %s) -H Content-Type: application/json -d{mappings:{properties:{ts:{type:date}}}} /dev/null; then exit 1 fi exit 0这个脚本比官方推荐的/actuator/health严格十倍。某次ES集群脑裂/actuator/health仍返回UP但OAP无法写入新数据。我们的脚本因curl到ES失败而触发Pod重启5分钟内自动恢复。2.6 第六步日志治理——过滤噪音聚焦关键错误OAP默认日志级别为INFO每秒产生数百行日志其中90%是无意义的Received segment from xxx。生产环境必须降噪# log4j2.xml 配置节选 Logger nameorg.apache.skywalking.oap.server.core.analysis levelWARN additivityfalse AppenderRef refRollingFile/ /Logger Logger nameorg.apache.skywalking.oap.server.receiver.trace levelWARN additivityfalse AppenderRef refRollingFile/ /Logger !-- 关键屏蔽ES重试日志 -- Logger nameorg.apache.skywalking.oap.server.storage.plugin.elasticsearch levelERROR additivityfalse AppenderRef refRollingFile/ /Logger经验某次定位慢查询翻了2小时日志才找到ElasticsearchException: EsRejectedExecutionException。后来在log4j2.xml中为ES客户端单独设为ERROR级别同类错误日志量减少95%排查效率提升4倍。2.7 第七步验证数据流——三步确认管道畅通部署完成后必须人工验证数据流是否真正贯通探针侧验证在被监控应用启动日志中搜索Tracing context initialized确认探针已连接OAPOAP侧验证执行curl http://localhost:11800/oap/v3/services?limit1返回JSON中services数组长度应0存储侧验证登录ES Head插件查看sw_segment*索引文档数是否每分钟递增。最后一道防线用Postman调用/v3/topology若返回{nodes:[],edges:[]}说明OAP已计算出空拓扑——证明数据已成功流入并完成基础处理。此时再启动UI成功率99.9%。3. UI服务部署不只是nginx转发而是解决跨域与缓存的组合拳很多人以为UI部署就是docker run -p 8080:8080 apache/skywalking-ui然后打开浏览器。结果遇到“Network Error”、“Failed to fetch”、“CORS error”等报错折腾半天才发现问题不在UI本身而在它与OAP之间的协议适配层。UI不是独立服务它是OAP的“远程显示器”必须解决三个底层问题跨域、路径代理、静态资源缓存。3.1 根本矛盾UI的静态资源与OAP的动态API天然隔离UI镜像本质是Nginx容器其/usr/share/nginx/html目录下存放编译好的React静态文件index.html,main.js等。当浏览器访问http://ui-host:8080时Nginx直接返回index.html但index.html里的JavaScript代码会向/oap/v3/services发起AJAX请求——注意这个URL是相对路径浏览器会自动拼接为http://ui-host:8080/oap/v3/services。而OAP服务实际运行在http://oap-host:11800这就产生了跨域问题协议、域名、端口任一不同即跨域。解决方案只有两个方案A推荐用Nginx反向代理将UI容器内的/oap/路径代理到OAP服务。这样浏览器所有请求都发往UI同源地址无跨域。方案B修改UI源码将API Base URL硬编码为OAP地址如http://oap-host:11800但需重新构建镜像失去官方更新能力。我们始终坚持方案A因为它是唯一符合“关注点分离”原则的做法——UI专注展示路由由基础设施层Nginx处理。3.2 Nginx配置详解代理规则背后的四个必填项以下是生产环境验证有效的nginx.conf核心节选每一行都有明确目的upstream oap_backend { server oap:11800; # Docker网络中OAP服务名 } server { listen 80; server_name _; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; # React Router必备前端路由fallback } # ↓ 关键1代理所有/oap/开头的请求到OAP location /oap/ { proxy_pass http://oap_backend/; # 注意末尾斜杠决定路径重写规则 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # ↓ 关键2透传WebSocket连接拓扑图实时刷新依赖 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # ↓ 关键3设置超时避免长连接阻塞 proxy_connect_timeout 30s; proxy_send_timeout 30s; proxy_read_timeout 30s; # ↓ 关键4禁用缓存确保API响应最新 add_header Cache-Control no-cache, no-store, must-revalidate; add_header Pragma no-cache; add_header Expires 0; } # ↓ 关键5静态资源强制缓存提升首屏速度 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control public, immutable; } }重点解释proxy_pass末尾斜杠若写成proxy_pass http://oap_backend;无斜杠则/oap/v3/services会被完整转发到OAPOAP收到的路径仍是/oap/v3/services但OAP的API根路径是/导致404加上斜杠后Nginx会将/oap/前缀剥离只转发/v3/services完美匹配OAP路由。这个细节让80%的新手卡住。3.3 Docker Compose实战UI与OAP的网络协同UI容器必须与OAP容器处于同一Docker网络才能通过服务名互通。完整docker-compose.yml如下version: 3.8 services: ui: image: apache/skywalking-ui:9.7.0 container_name: skywalking-ui restart: unless-stopped ports: - 8080:80 environment: - SW_OAP_ADDRESShttp://oap:11800 # 此变量仅用于UI容器内环境变量实际不使用 volumes: - ./nginx.conf:/etc/nginx/nginx.conf # 挂载自定义Nginx配置 networks: - skywalking-net depends_on: - oap oap: # ...OAP服务配置见2.4节 networks: - skywalking-net networks: skywalking-net: driver: bridge注意SW_OAP_ADDRESS环境变量在官方UI镜像中已被废弃自9.0.0起但很多老教程仍保留。它不会生效UI完全依赖Nginx代理配置。若误信此变量会陷入“配置了地址却无效”的思维陷阱。3.4 缓存陷阱为什么UI页面总显示“昨天”的数据UI的index.html被浏览器缓存后即使OAP数据更新用户看到的仍是旧版JS代码。我们曾遇到客户投诉“监控数据延迟24小时”排查发现是CDN缓存了index.html且未设置Cache-Control: no-cache。解决方案分三层Nginx层如3.2节所示在location /块中添加location /index.html { add_header Cache-Control no-cache, no-store, must-revalidate; add_header Pragma no-cache; add_header Expires 0; }构建层若自行构建UI可在package.json中配置homepage: .并启用Webpack的contenthashbuild: react-scripts build sed -i s/index.html/index.[a-z0-9]\\{8\\}.html/g build/index.htmlCDN层在阿里云CDN或Cloudflare中为/index.html设置缓存过期时间为0秒其他静态资源.js,.css设置1年。真实案例某政务云平台UI部署在CDN上因未配置index.html缓存策略升级UI 9.5.0后用户浏览器仍加载9.4.0的JS导致新功能按钮点击无反应。最终通过CDN强制刷新index.html并清除用户本地缓存解决。3.5 跨域调试技巧Chrome开发者工具的隐藏开关当UI页面报CORS error时不要急着改Nginx。先用Chrome开发者工具确认问题根源打开Network标签页筛选XHR请求找到失败的/oap/v3/services请求点击查看详情切换到Headers子页检查Request Headers中的Origin值如http://localhost:8080检查Response Headers中是否有Access-Control-Allow-Origin: *代理配置正确时应有若无此头说明Nginx代理未生效请求直接发给了UI容器自身的Nginx它不处理/oap/路径需检查nginx.conf是否挂载成功及语法是否正确。这个方法比看日志快10倍。我曾用此法3分钟定位到docker-compose.yml中volumes路径写错nginx.conf根本没挂载进去。4. 故障排查全景图从UI白屏到OAP崩溃的12个关键断点部署不是终点而是运维的起点。根据我们三年运维SkyWalking的经验整理出一份覆盖全链路的故障排查地图。每个断点都对应一个真实场景、一个验证命令、一个修复方案拒绝模糊描述。4.1 断点1UI容器启动成功但浏览器打不开http://ip:8080现象docker ps显示UI容器状态Up 2 minutes但浏览器访问超时。验证命令# 检查容器端口映射 docker port skywalking-ui # 应返回 80-0.0.0.0:8080 # 检查容器内Nginx是否监听80端口 docker exec -it skywalking-ui ss -tlnp | grep :80 # 应返回 LISTEN *:80根因与修复若docker port无输出 →docker-compose.yml中ports配置错误检查缩进和格式若ss无监听 → Nginx配置语法错误执行docker exec skywalking-ui nginx -t查看报错常见于nginx.conf中upstream块缺少分号。4.2 断点2UI页面显示“Network Error”F12看Network全是failed现象UI首页加载index.html成功但所有API请求标红failed。验证命令# 进入UI容器模拟浏览器请求 docker exec -it skywalking-ui curl -v http://oap:11800/oap/v3/services?limit1 # 若返回404或Connection refused → OAP服务未就绪或网络不通根因与修复Connection refused→ Docker网络未桥接检查docker network inspect skywalking-net确认oap和ui容器在同一网络且IP可ping通404→ OAP未启动或application.yml中restHost配置错误应为0.0.0.0而非127.0.0.1。4.3 断点3UI显示“Loading...”Network中/oap/v3/services返回200但services为空数组现象API调用成功但返回JSON中services:[]。验证命令# 检查OAP日志是否有探针连接记录 docker logs skywalking-oap | grep Tracing receiver started # 应有类似 Tracing receiver started, listening on 0.0.0.0:11800 # 检查ES中是否有Segment数据 curl http://es-node1:9200/sw_segment*/_count?qserviceId:* | jq .count # 若为0 → 探针未上报或OAP未写入根因与修复无Tracing receiver日志 → 探针配置错误检查被监控应用的agent.config中collector.backend_service是否指向oap:11800ES计数为0 → OAP存储配置错误检查application.yml中storage.elasticsearch.enableRecordData是否为true。4.4 断点4UI服务拓扑图空白Network中/oap/v3/topology返回{nodes:[],edges:[]}现象服务列表正常但拓扑图无任何节点。验证命令# 检查OAP是否启用拓扑计算 docker logs skywalking-oap | grep TopologyAnalyzer started # 应有日志 # 检查ES中是否有Topology数据 curl http://es-node1:9200/sw_topology*/_count | jq .count # 若为0 → 拓扑计算模块未触发根因与修复无TopologyAnalyzer日志 →application.yml中storage.elasticsearch.enableTopologyData为false改为true并重启OAPES计数为0 → 拓扑计算依赖服务间调用数据确认至少有两个服务存在上下游调用关系如ServiceA调用ServiceB且探针已正确注入。4.5 断点5UI页面卡顿严重鼠标移动延迟明显现象打开服务详情页滚动或切换Tab时界面冻结2秒以上。验证命令# 检查UI容器资源占用 docker stats skywalking-ui --no-stream | grep -E (MEM|CPU) # 若MEM% 90% → 内存不足 # 检查浏览器Console是否有大量Warning # 常见React state更新警告、内存泄漏提示根因与修复容器内存不足 → 增加mem_limit: 512m到docker-compose.yml浏览器内存泄漏 → 升级UI到9.7.0该版本修复了Service Mesh视图的内存泄漏BugGitHub Issue #9213。4.6 断点6UI中告警列表为空但OAP日志显示Alarm notify triggered现象OAP日志有告警触发记录但UI告警页无数据。验证命令# 检查OAP是否启用告警存储 docker logs skywalking-oap | grep AlarmDataQueryDAO # 应有初始化日志 # 检查ES中告警索引 curl http://es-node1:9200/sw_alarm*/_count | jq .count根因与修复无AlarmDataQueryDAO日志 →application.yml中storage.elasticsearch.enableAlarmData为falseES计数为0 → 告警规则未配置访问http://oap:11800/oap/v3/rules确认返回规则列表。4.7 断点7UI中“Trace”页搜索无结果但已知有慢调用现象在Trace页输入服务名和时间范围点击Search返回0条结果。验证命令# 检查ES中Trace数据 curl http://es-node1:9200/sw_segment*/_search?qserviceId:your-service-idsize1 | jq .hits.hits[0]._source.serviceName # 若返回空 → 数据未入库或索引名错误根因与修复索引名错误 → SkyWalking 9.x默认索引名为sw_segment*若ES中为skywalking-segment-*需在application.yml中配置storage: elasticsearch: indexShardingNumber: 1 # ↓ 强制指定索引名前缀 indexTemplate: sw_segment4.8 断点8UI中“Metrics”页图表全部显示“NaN”现象CPU、JVM内存等指标图表Y轴为NaN无任何数值。验证命令# 检查OAP是否启用指标收集 docker logs skywalking-oap | grep MeterAnalyzer started # 应有日志 # 检查ES中指标索引 curl http://es-node1:9200/sw_metric*/_count | jq .count根因与修复无MeterAnalyzer日志 →application.yml中meter.analyzer.enabled为false默认true极少关闭ES计数为0 → 探针未开启指标上报检查agent.config中plugin.jvm.memory等配置是否为true。4.9 断点9UI登录后立即跳转到/login无限循环现象启用JWT认证后登录成功却跳回登录页。验证命令# 检查浏览器Application标签页中Cookie # 应存在名为SKYWALKING-JWT-TOKEN的HttpOnly Cookie # 检查OAP日志认证相关 docker logs skywalking-oap | grep JWTAuthenticator根因与修复Cookie不存在 → Nginx代理未透传Set-Cookie头检查nginx.conf中proxy_pass配置是否遗漏proxy_cookie_path指令OAP日志无认证记录 →application.yml中authentication.jwt配置错误确认secretKey与UI配置一致。4.10 断点10UI中“Dashboard”自定义仪表盘保存后不生效现象新建仪表盘并保存刷新页面后回到默认仪表盘。验证命令# 检查ES中仪表盘数据 curl http://es-node1:9200/sw_dashboard*/_search?qname:your-dashboard-name | jq .hits.total.value # 若为0 → 保存未成功根因与修复ES返回0 → UI保存接口调用失败检查Network中/oap/v3/dashboard请求是否403权限不足或500OAP存储异常常见于MySQL存储时未开启dashboard.enabledtrue。4.11 断点11UI页面中文乱码菜单显示方框现象所有中文显示为□□□。验证命令# 进入UI容器检查字体 docker exec skywalking-ui fc-list | grep -i simsun # 应返回宋体路径根因与修复无宋体 → Alpine镜像缺失中文字体改用标准版镜像基于Debian或手动安装 SkyWalking OAP与UI分离部署原理与实战指南
1. 为什么OAP和UI必须分开搭——从SkyWalking架构本质说起很多人第一次接触SkyWalking看到“OAP”和“UI”两个词并列下意识就以为是“一个安装包、一键启动”的傻瓜式操作。我当年在金融客户现场部署时也这么想结果在测试环境跑了三天链路数据始终不进UI排查日志发现OAP服务早就在后台静默崩溃了——而UI界面还在那儿稳稳地刷着“Loading…”。这不是配置错了是根本没理解SkyWalking的分层契约设计逻辑。SkyWalking不是传统单体监控系统它是一个典型的“采集-处理-展示”三层解耦架构。OAPObservability Analysis Platform是后端分析平台负责接收探针上报的Trace、Metric、Log原始数据做聚合、采样、拓扑计算、告警判定等重计算任务UI只是前端展示层它不碰任何原始数据只通过REST API向OAP发起查询请求把OAP返回的JSON结构化数据渲染成图表和列表。这就像厨房OAP和餐厅UI的关系厨师在后厨切菜炒菜数据清洗与计算服务员UI只负责把做好的菜端上桌并不参与烹饪过程。你不能指望让服务员去切肉丝更不能因为菜没端上来就怪厨师没开火——得先确认后厨有没有通电、燃气有没有开、锅里有没有油。这种分离带来三个硬性约束第一网络连通性必须双向打通。UI容器必须能访问OAP的12800端口默认gRPC监听端口用于内部通信和11800端口默认HTTP REST API端口UI调用入口反过来OAP不需要访问UI但OAP自身依赖的存储如Elasticsearch或MySQL必须对OAP容器可达。很多初学者卡在“UI显示空白”90%是因为UI容器内执行curl -v http://oap:11800/oap/v3/services返回Connection refused根源是Docker网络未桥接或K8s Service DNS解析失败。第二版本强绑定不可跨代混用。SkyWalking官方明确声明UI版本必须与OAP版本严格一致。比如OAP 9.7.0只能配UI 9.7.0不能用UI 9.6.0或9.8.0。这是因为REST API的路径、参数、返回字段在小版本迭代中可能微调——UI代码里写死的/v3/topology接口在OAP 9.8.0里可能已重命名为/v3/topology/graph。我见过最典型的事故运维同学图省事用最新版UI镜像覆盖旧环境结果所有服务拓扑图变成404查了半天才发现OAP日志里反复打印Unmatched request path: /v3/topology。第三资源分配策略截然不同。OAP是CPU和内存密集型服务一个中等规模集群50个Java应用实例每秒1000条Span的OAP进程JVM堆内存建议设为4G~8GGC频率直接影响数据落盘延迟而UI是轻量级静态资源服务Nginx容器跑128MB内存绰绰有余。若把两者塞进同一个Pod或同一台虚拟机OAP GC停顿会直接拖垮UI响应造成“UI界面卡顿”——这根本不是前端性能问题是后端资源争抢导致的假性卡顿。所以“搭建”这个词在SkyWalking语境里本质是构建一条稳定的数据流管道探针 → OAP接收/计算/存储→ UI查询/渲染。OAP是管道的心脏UI是管道末端的水龙头。心脏不跳水龙头再漂亮也流不出一滴水。接下来的所有步骤都围绕这个核心认知展开。2. OAP服务落地实操从零配置到生产就绪的七步法OAP的搭建绝非docker run一条命令能搞定。我经历过三次大规模生产部署电商大促监控、银行核心系统全链路追踪、IoT设备指标中心每次都要面对不同的基础设施约束。下面这套“七步法”是我从踩坑中提炼出的最小可行路径每一步都附带真实场景中的取舍逻辑和避坑点。2.1 第一步存储选型——ES、MySQL、H2到底选谁OAP支持多种后端存储但选择直接决定后续运维成本。我们用一张表对比三种主流选项在真实业务中的表现存储类型适用场景数据保留策略典型配置关键风险Elasticsearch 7.10中大型生产环境日Span量 1亿按索引生命周期自动rollover支持冷热分层3节点ES集群每个节点16G内存SSD磁盘ES JVM堆内存严禁超过32GLucene限制否则Full GC频繁需关闭swap并调大vm.max_map_count262144MySQL 5.7小型环境或需要SQL灵活查询手动按月分表依赖定时脚本清理8C16G单实例InnoDB引擎innodb_buffer_pool_size12G不支持原生拓扑图计算需OAP开启mysql-storage插件并配置topology.enabledtrue高并发写入易锁表H2 Database本地开发/POC验证内存模式重启丢失或文件模式单机持久化-Dskywalking.storage.h2.file_path/data/h2严禁用于任何测试以上环境文件锁机制在容器重启时极易损坏数据库文件我曾因此丢失三天压测数据提示金融客户强制要求审计日志留存180天我们最终选用ESILM策略。但首次部署时误用了ES 8.x结果OAP启动报错Unsupported Elasticsearch version: 8.x——SkyWalking 9.7.0官方仅认证ES 7.10~7.17。降级ES版本后又因ES安全插件Search Guard未开放cluster:monitor/nodes/info权限导致OAP日志狂刷Failed to fetch node info。最终解决方案是在ESroles.yml中为skywalking用户添加cluster_monitor内置角色。2.2 第二步配置文件精简——删掉80%的默认项SkyWalking OAP的application.yml有近500行默认开启所有模块。生产环境中必须做减法。我整理出一份“最小必要配置模板”仅保留核心功能# application.yml - 生产精简版 storage: selector: ${SW_STORAGE:elasticsearch} elasticsearch: nameSpace: ${SW_NAMESPACE:} clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:es-node1:9200,es-node2:9200} protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:http} trustStorePath: ${SW_STORAGE_ES_TRUST_STORE_PATH:} # ↓ 关键关闭无用模块减少线程和内存占用 enableRecordData: ${SW_STORAGE_ES_ENABLE_RECORD_DATA:true} # 必须true否则Span不入库 enableLogData: ${SW_STORAGE_ES_ENABLE_LOG_DATA:false} # 日志功能默认关 enableTopologyData: ${SW_STORAGE_ES_ENABLE_TOPOLOGY_DATA:true} # 拓扑图必需 enableAlarmData: ${SW_STORAGE_ES_ENABLE_ALARM_DATA:true} # 告警必需 enableBrowserData: ${SW_STORAGE_ES_ENABLE_BROWSER_DATA:false} # 前端监控关 enablePerformanceData: ${SW_STORAGE_ES_ENABLE_PERFORMANCE_DATA:true} # 性能指标开 core: selector: ${SW_CORE:default} default: # ↓ 关键调整采样率避免OOM samplingRate: ${SW_CORE_DEFAULT_SAMPLING_RATE:10000} # 每10000条Span采1条压测时可调为100 # ↓ 关键禁用不必要分析器 ignoreSuffix: ${SW_CORE_DEFAULT_IGNORE_SUFFIX:.jpg,.png,.gif,.css,.js,.html} # 静态资源忽略注意samplingRate参数常被误解为“百分比”。实际它是采样间隔值为10000表示每收到10000条Span记录第1条其余丢弃。若设为1则100%全量采集中小集群可能瞬间打爆ES磁盘。我们线上集群将此值设为5000既保证关键链路不丢失又将ES日增数据量控制在80GB以内。2.3 第三步JVM参数调优——别让GC成为性能瓶颈OAP的JVM配置是隐形杀手。默认-Xms512m -Xmx512m在生产环境必然OOM。根据我们压测数据给出分级建议小型环境 20个服务实例-Xms2g -Xmx2g -XX:UseG1GC -XX:MaxGCPauseMillis200中型环境20~100实例-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis300 -XX:G1HeapRegionSize4M大型环境 100实例-Xms6g -Xmx6g -XX:UseG1GC -XX:MaxGCPauseMillis400 -XX:G1HeapRegionSize4M -XX:UnlockExperimentalVMOptions -XX:G1MaxNewSizePercent60实测教训某次大促前运维同事将JVM堆设为-Xms8g -Xmx8g但未调G1HeapRegionSize。结果OAP在峰值QPS 1200时G1 GC频繁触发Mixed GC每次停顿达1.2秒导致探针上报超时重试形成雪崩。后将G1HeapRegionSize从默认2M调至4MMixed GC频率下降60%停顿稳定在300ms内。2.4 第四步Docker部署——镜像选择与网络配置官方提供两种镜像apache/skywalking-oap-server标准版和apache/skywalking-oap-server:alpine精简版。生产环境必须用标准版——Alpine版缺失glibc某些国产中间件探针如东方通TongWeb上报时会因java.lang.UnsatisfiedLinkError崩溃。Docker Compose关键配置如下以ES存储为例version: 3.8 services: oap: image: apache/skywalking-oap-server:9.7.0 container_name: skywalking-oap restart: unless-stopped ports: - 11800:11800 # UI调用API端口 - 12800:12800 # gRPC内部通信端口 - 11801:11801 # Prometheus指标暴露端口可选 environment: - SW_STORAGEelasticsearch - SW_STORAGE_ES_CLUSTER_NODESes-node1:9200,es-node2:9200 - SW_CORE_DEFAULT_SAMPLING_RATE5000 - JAVA_OPTS-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis300 volumes: - ./config/application.yml:/skywalking/config/application.yml # 挂载精简配置 - ./logs:/skywalking/logs # 日志持久化 networks: - skywalking-net depends_on: - es-node1 - es-node2关键细节ports段必须显式暴露11800和12800。很多教程只暴露11800结果UI能访问但拓扑图空白——因为UI首次加载会调用/v3/topology走11800但拓扑图的实时刷新依赖/v3/topology/refresh走12800的gRPC长连接。若12800未暴露UI会持续轮询失败。2.5 第五步健康检查——用curl写个真·可用性探测K8s或Docker Swarm中必须配置精准的健康检查。OAP的/actuator/health端点返回UP仅代表进程存活不代表数据链路通畅。我们自研了一个探测脚本嵌入Liveness Probe#!/bin/bash # health-check.sh # 检查三项OAP进程、ES连通性、核心API可用性 if ! curl -sf http://localhost:12800/actuator/health /dev/null; then exit 1 fi if ! curl -sf http://localhost:11800/oap/v3/services?limit1 /dev/null; then exit 1 fi # 检查ES是否可写尝试创建临时索引 if ! curl -sf -XPUT http://es-node1:9200/test-health-$(date %s) -H Content-Type: application/json -d{mappings:{properties:{ts:{type:date}}}} /dev/null; then exit 1 fi exit 0这个脚本比官方推荐的/actuator/health严格十倍。某次ES集群脑裂/actuator/health仍返回UP但OAP无法写入新数据。我们的脚本因curl到ES失败而触发Pod重启5分钟内自动恢复。2.6 第六步日志治理——过滤噪音聚焦关键错误OAP默认日志级别为INFO每秒产生数百行日志其中90%是无意义的Received segment from xxx。生产环境必须降噪# log4j2.xml 配置节选 Logger nameorg.apache.skywalking.oap.server.core.analysis levelWARN additivityfalse AppenderRef refRollingFile/ /Logger Logger nameorg.apache.skywalking.oap.server.receiver.trace levelWARN additivityfalse AppenderRef refRollingFile/ /Logger !-- 关键屏蔽ES重试日志 -- Logger nameorg.apache.skywalking.oap.server.storage.plugin.elasticsearch levelERROR additivityfalse AppenderRef refRollingFile/ /Logger经验某次定位慢查询翻了2小时日志才找到ElasticsearchException: EsRejectedExecutionException。后来在log4j2.xml中为ES客户端单独设为ERROR级别同类错误日志量减少95%排查效率提升4倍。2.7 第七步验证数据流——三步确认管道畅通部署完成后必须人工验证数据流是否真正贯通探针侧验证在被监控应用启动日志中搜索Tracing context initialized确认探针已连接OAPOAP侧验证执行curl http://localhost:11800/oap/v3/services?limit1返回JSON中services数组长度应0存储侧验证登录ES Head插件查看sw_segment*索引文档数是否每分钟递增。最后一道防线用Postman调用/v3/topology若返回{nodes:[],edges:[]}说明OAP已计算出空拓扑——证明数据已成功流入并完成基础处理。此时再启动UI成功率99.9%。3. UI服务部署不只是nginx转发而是解决跨域与缓存的组合拳很多人以为UI部署就是docker run -p 8080:8080 apache/skywalking-ui然后打开浏览器。结果遇到“Network Error”、“Failed to fetch”、“CORS error”等报错折腾半天才发现问题不在UI本身而在它与OAP之间的协议适配层。UI不是独立服务它是OAP的“远程显示器”必须解决三个底层问题跨域、路径代理、静态资源缓存。3.1 根本矛盾UI的静态资源与OAP的动态API天然隔离UI镜像本质是Nginx容器其/usr/share/nginx/html目录下存放编译好的React静态文件index.html,main.js等。当浏览器访问http://ui-host:8080时Nginx直接返回index.html但index.html里的JavaScript代码会向/oap/v3/services发起AJAX请求——注意这个URL是相对路径浏览器会自动拼接为http://ui-host:8080/oap/v3/services。而OAP服务实际运行在http://oap-host:11800这就产生了跨域问题协议、域名、端口任一不同即跨域。解决方案只有两个方案A推荐用Nginx反向代理将UI容器内的/oap/路径代理到OAP服务。这样浏览器所有请求都发往UI同源地址无跨域。方案B修改UI源码将API Base URL硬编码为OAP地址如http://oap-host:11800但需重新构建镜像失去官方更新能力。我们始终坚持方案A因为它是唯一符合“关注点分离”原则的做法——UI专注展示路由由基础设施层Nginx处理。3.2 Nginx配置详解代理规则背后的四个必填项以下是生产环境验证有效的nginx.conf核心节选每一行都有明确目的upstream oap_backend { server oap:11800; # Docker网络中OAP服务名 } server { listen 80; server_name _; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; # React Router必备前端路由fallback } # ↓ 关键1代理所有/oap/开头的请求到OAP location /oap/ { proxy_pass http://oap_backend/; # 注意末尾斜杠决定路径重写规则 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # ↓ 关键2透传WebSocket连接拓扑图实时刷新依赖 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # ↓ 关键3设置超时避免长连接阻塞 proxy_connect_timeout 30s; proxy_send_timeout 30s; proxy_read_timeout 30s; # ↓ 关键4禁用缓存确保API响应最新 add_header Cache-Control no-cache, no-store, must-revalidate; add_header Pragma no-cache; add_header Expires 0; } # ↓ 关键5静态资源强制缓存提升首屏速度 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control public, immutable; } }重点解释proxy_pass末尾斜杠若写成proxy_pass http://oap_backend;无斜杠则/oap/v3/services会被完整转发到OAPOAP收到的路径仍是/oap/v3/services但OAP的API根路径是/导致404加上斜杠后Nginx会将/oap/前缀剥离只转发/v3/services完美匹配OAP路由。这个细节让80%的新手卡住。3.3 Docker Compose实战UI与OAP的网络协同UI容器必须与OAP容器处于同一Docker网络才能通过服务名互通。完整docker-compose.yml如下version: 3.8 services: ui: image: apache/skywalking-ui:9.7.0 container_name: skywalking-ui restart: unless-stopped ports: - 8080:80 environment: - SW_OAP_ADDRESShttp://oap:11800 # 此变量仅用于UI容器内环境变量实际不使用 volumes: - ./nginx.conf:/etc/nginx/nginx.conf # 挂载自定义Nginx配置 networks: - skywalking-net depends_on: - oap oap: # ...OAP服务配置见2.4节 networks: - skywalking-net networks: skywalking-net: driver: bridge注意SW_OAP_ADDRESS环境变量在官方UI镜像中已被废弃自9.0.0起但很多老教程仍保留。它不会生效UI完全依赖Nginx代理配置。若误信此变量会陷入“配置了地址却无效”的思维陷阱。3.4 缓存陷阱为什么UI页面总显示“昨天”的数据UI的index.html被浏览器缓存后即使OAP数据更新用户看到的仍是旧版JS代码。我们曾遇到客户投诉“监控数据延迟24小时”排查发现是CDN缓存了index.html且未设置Cache-Control: no-cache。解决方案分三层Nginx层如3.2节所示在location /块中添加location /index.html { add_header Cache-Control no-cache, no-store, must-revalidate; add_header Pragma no-cache; add_header Expires 0; }构建层若自行构建UI可在package.json中配置homepage: .并启用Webpack的contenthashbuild: react-scripts build sed -i s/index.html/index.[a-z0-9]\\{8\\}.html/g build/index.htmlCDN层在阿里云CDN或Cloudflare中为/index.html设置缓存过期时间为0秒其他静态资源.js,.css设置1年。真实案例某政务云平台UI部署在CDN上因未配置index.html缓存策略升级UI 9.5.0后用户浏览器仍加载9.4.0的JS导致新功能按钮点击无反应。最终通过CDN强制刷新index.html并清除用户本地缓存解决。3.5 跨域调试技巧Chrome开发者工具的隐藏开关当UI页面报CORS error时不要急着改Nginx。先用Chrome开发者工具确认问题根源打开Network标签页筛选XHR请求找到失败的/oap/v3/services请求点击查看详情切换到Headers子页检查Request Headers中的Origin值如http://localhost:8080检查Response Headers中是否有Access-Control-Allow-Origin: *代理配置正确时应有若无此头说明Nginx代理未生效请求直接发给了UI容器自身的Nginx它不处理/oap/路径需检查nginx.conf是否挂载成功及语法是否正确。这个方法比看日志快10倍。我曾用此法3分钟定位到docker-compose.yml中volumes路径写错nginx.conf根本没挂载进去。4. 故障排查全景图从UI白屏到OAP崩溃的12个关键断点部署不是终点而是运维的起点。根据我们三年运维SkyWalking的经验整理出一份覆盖全链路的故障排查地图。每个断点都对应一个真实场景、一个验证命令、一个修复方案拒绝模糊描述。4.1 断点1UI容器启动成功但浏览器打不开http://ip:8080现象docker ps显示UI容器状态Up 2 minutes但浏览器访问超时。验证命令# 检查容器端口映射 docker port skywalking-ui # 应返回 80-0.0.0.0:8080 # 检查容器内Nginx是否监听80端口 docker exec -it skywalking-ui ss -tlnp | grep :80 # 应返回 LISTEN *:80根因与修复若docker port无输出 →docker-compose.yml中ports配置错误检查缩进和格式若ss无监听 → Nginx配置语法错误执行docker exec skywalking-ui nginx -t查看报错常见于nginx.conf中upstream块缺少分号。4.2 断点2UI页面显示“Network Error”F12看Network全是failed现象UI首页加载index.html成功但所有API请求标红failed。验证命令# 进入UI容器模拟浏览器请求 docker exec -it skywalking-ui curl -v http://oap:11800/oap/v3/services?limit1 # 若返回404或Connection refused → OAP服务未就绪或网络不通根因与修复Connection refused→ Docker网络未桥接检查docker network inspect skywalking-net确认oap和ui容器在同一网络且IP可ping通404→ OAP未启动或application.yml中restHost配置错误应为0.0.0.0而非127.0.0.1。4.3 断点3UI显示“Loading...”Network中/oap/v3/services返回200但services为空数组现象API调用成功但返回JSON中services:[]。验证命令# 检查OAP日志是否有探针连接记录 docker logs skywalking-oap | grep Tracing receiver started # 应有类似 Tracing receiver started, listening on 0.0.0.0:11800 # 检查ES中是否有Segment数据 curl http://es-node1:9200/sw_segment*/_count?qserviceId:* | jq .count # 若为0 → 探针未上报或OAP未写入根因与修复无Tracing receiver日志 → 探针配置错误检查被监控应用的agent.config中collector.backend_service是否指向oap:11800ES计数为0 → OAP存储配置错误检查application.yml中storage.elasticsearch.enableRecordData是否为true。4.4 断点4UI服务拓扑图空白Network中/oap/v3/topology返回{nodes:[],edges:[]}现象服务列表正常但拓扑图无任何节点。验证命令# 检查OAP是否启用拓扑计算 docker logs skywalking-oap | grep TopologyAnalyzer started # 应有日志 # 检查ES中是否有Topology数据 curl http://es-node1:9200/sw_topology*/_count | jq .count # 若为0 → 拓扑计算模块未触发根因与修复无TopologyAnalyzer日志 →application.yml中storage.elasticsearch.enableTopologyData为false改为true并重启OAPES计数为0 → 拓扑计算依赖服务间调用数据确认至少有两个服务存在上下游调用关系如ServiceA调用ServiceB且探针已正确注入。4.5 断点5UI页面卡顿严重鼠标移动延迟明显现象打开服务详情页滚动或切换Tab时界面冻结2秒以上。验证命令# 检查UI容器资源占用 docker stats skywalking-ui --no-stream | grep -E (MEM|CPU) # 若MEM% 90% → 内存不足 # 检查浏览器Console是否有大量Warning # 常见React state更新警告、内存泄漏提示根因与修复容器内存不足 → 增加mem_limit: 512m到docker-compose.yml浏览器内存泄漏 → 升级UI到9.7.0该版本修复了Service Mesh视图的内存泄漏BugGitHub Issue #9213。4.6 断点6UI中告警列表为空但OAP日志显示Alarm notify triggered现象OAP日志有告警触发记录但UI告警页无数据。验证命令# 检查OAP是否启用告警存储 docker logs skywalking-oap | grep AlarmDataQueryDAO # 应有初始化日志 # 检查ES中告警索引 curl http://es-node1:9200/sw_alarm*/_count | jq .count根因与修复无AlarmDataQueryDAO日志 →application.yml中storage.elasticsearch.enableAlarmData为falseES计数为0 → 告警规则未配置访问http://oap:11800/oap/v3/rules确认返回规则列表。4.7 断点7UI中“Trace”页搜索无结果但已知有慢调用现象在Trace页输入服务名和时间范围点击Search返回0条结果。验证命令# 检查ES中Trace数据 curl http://es-node1:9200/sw_segment*/_search?qserviceId:your-service-idsize1 | jq .hits.hits[0]._source.serviceName # 若返回空 → 数据未入库或索引名错误根因与修复索引名错误 → SkyWalking 9.x默认索引名为sw_segment*若ES中为skywalking-segment-*需在application.yml中配置storage: elasticsearch: indexShardingNumber: 1 # ↓ 强制指定索引名前缀 indexTemplate: sw_segment4.8 断点8UI中“Metrics”页图表全部显示“NaN”现象CPU、JVM内存等指标图表Y轴为NaN无任何数值。验证命令# 检查OAP是否启用指标收集 docker logs skywalking-oap | grep MeterAnalyzer started # 应有日志 # 检查ES中指标索引 curl http://es-node1:9200/sw_metric*/_count | jq .count根因与修复无MeterAnalyzer日志 →application.yml中meter.analyzer.enabled为false默认true极少关闭ES计数为0 → 探针未开启指标上报检查agent.config中plugin.jvm.memory等配置是否为true。4.9 断点9UI登录后立即跳转到/login无限循环现象启用JWT认证后登录成功却跳回登录页。验证命令# 检查浏览器Application标签页中Cookie # 应存在名为SKYWALKING-JWT-TOKEN的HttpOnly Cookie # 检查OAP日志认证相关 docker logs skywalking-oap | grep JWTAuthenticator根因与修复Cookie不存在 → Nginx代理未透传Set-Cookie头检查nginx.conf中proxy_pass配置是否遗漏proxy_cookie_path指令OAP日志无认证记录 →application.yml中authentication.jwt配置错误确认secretKey与UI配置一致。4.10 断点10UI中“Dashboard”自定义仪表盘保存后不生效现象新建仪表盘并保存刷新页面后回到默认仪表盘。验证命令# 检查ES中仪表盘数据 curl http://es-node1:9200/sw_dashboard*/_search?qname:your-dashboard-name | jq .hits.total.value # 若为0 → 保存未成功根因与修复ES返回0 → UI保存接口调用失败检查Network中/oap/v3/dashboard请求是否403权限不足或500OAP存储异常常见于MySQL存储时未开启dashboard.enabledtrue。4.11 断点11UI页面中文乱码菜单显示方框现象所有中文显示为□□□。验证命令# 进入UI容器检查字体 docker exec skywalking-ui fc-list | grep -i simsun # 应返回宋体路径根因与修复无宋体 → Alpine镜像缺失中文字体改用标准版镜像基于Debian或手动安装