CubeMaster 与 cube-api 恢复排障
本页聚焦 CubeMaster 与 cube-api 这两层控制面进程的判活、分层和恢复。
如果你还没确认支撑层是否稳定,请先看:
60 秒只读初判
建议先执行:
bash
sudo ./smoke.sh
curl -fsS http://127.0.0.1:19090/healthz
curl -fsS http://127.0.0.1:8089/notify/health
curl -fsS http://127.0.0.1:3000/health
curl -fsS http://127.0.0.1:12088/cubeapi/v1/health依赖链怎么读
建议按这条链路判断:
MySQL / Redis → CubeMaster:8089 → cube-api:3000 → Proxy / WebUI:12088
因此:
8089不健康时,不要先重启cube-api3000不健康时,不要先把问题归到前端3000正常但12088异常时,更像代理或 WebUI 问题
健康端点怎么解读
8089/notify/health
用于判断 CubeMaster 是否可用。
3000/health
用于判断 cube-api 进程是否基础可达。
12088/cubeapi/v1/health
用于判断经 WebUI / 反代暴露的管理 API 是否可访问。
常见症状与第一判断
smoke.sh 卡在 notify/health
优先看:
- 支撑层依赖是否稳定
CubeMaster启动日志- 控制面配置是否正常
8089 正常、3000 异常
优先看:
cube-api服务状态cube-api启动日志- API 配置与依赖连通性
3000 正常、12088 异常
优先转到:
Dashboard 能开但按钮全失败
先区分:
- 是鉴权问题
- 还是
cube-api后端异常
相关专题:
每层该看什么
建议顺序:
systemctl statusjournalctl/data/log/CubeMaster/与/data/log/CubeAPI/- Dashboard 或 API 最小验收
恢复后最小验收
建议至少验证:
8089、3000、12088全通- Dashboard 至少一个列表页可读
- 至少一个模板 / 节点 / 沙箱对象读取正常