可观测性（Observability）
可观测性页更像 Dashboard 里的值班总览页。相比 概览 更偏“先发现异常，再决定跳去哪里处理”，适合在下面几类场景中使用：
- 值班巡检时快速确认沙箱、节点、API 与模板状态
- 发现 Dashboard 首页 KPI 异常后，继续缩小问题范围
- 排查“能创建但不稳定”“模板在失败”“节点状态异常”这类综合问题
这一页解决什么问题
可观测性页通常会把系统信息拆成四块：
- 沙箱健康：运行中、暂停中、最近实例分布
- 节点健康：节点是否健康、CPU / 内存是否接近饱和
- API 连通性：管理面是否可达、鉴权是否开启、限流配置是否生效
- 模板构建状态：当前有多少
READY/BUILDING/FAILED模板
如果你不确定问题出在模板、沙箱还是节点，可先从本页开始。
沙箱健康与状态分布
可观测性页通常会先汇总所有沙箱，并展示：
- 沙箱总数
running数量paused数量- 最近几个沙箱
- 运行中与暂停中的比例分布
这块最适合用来判断：
沙箱是否正在正常承载业务
如果运行中的沙箱数量接近预期，说明业务流量大概率已经正常进入系统。
是否有过多暂停实例
如果暂停实例占比持续偏高，说明你可能正在频繁使用暂停/恢复链路，也可能意味着有一批实例未被及时清理。
最近沙箱是否异常集中
如果最近沙箱都落在同一模板、同一节点或持续在同一时间窗口失败，通常值得继续跳到 沙箱管理 或 节点与容量。
节点健康与资源饱和
可观测性页里的节点区块通常会展示：
- 健康节点数 / 节点总数
- 每个节点的健康状态
- CPU 饱和度
- 内存饱和度
这部分比 节点与容量 更适合做“先看一眼是否异常”，而不是深入看单个节点详情。
什么时候需要进入节点页
出现下面这些情况时，建议继续进入节点页：
- 健康节点数下降
- 某个节点 CPU 或内存持续高水位
- 有明显
degraded或非ready节点 - 某个节点资源异常集中，而你需要继续查看本地模板与运行中的沙箱
API 连通性与鉴权信号
可观测性页通常还会展示一组与管理面有关的运行信息，例如：
- 当前管理面限流配置
- 鉴权是否开启
- Dashboard 侧发起的连通性测试结果
- 管理面接口的基础可用性
这部分很适合排查两类问题：
Dashboard 打得开，但操作报错
先确认管理 API 是否真的可达，以及当前是否开启了鉴权。
集群看起来正常，但前端请求异常
可以先做一次连通性测试，再结合 鉴权 和 日志、健康检查与排障 继续定位。
模板构建失败清单
可观测性页通常会把模板状态按 READY、BUILDING、FAILED 汇总，并额外列出失败模板列表。
你应重点关注：
- 当前是否已经有足够数量的
READY模板 - 是否存在长期停留在
BUILDING的模板 FAILED模板的数量是否开始上升- 失败模板是否集中在同一镜像、同一配置或同一时间段
如果这里已经能看到失败模板，下一步应进入 模板管理 查看详情页、构建信息和副本情况。
典型排障路径
路径一：概览页发现异常
- 先从 概览 发现 KPI 异常
- 打开本页，确认异常主要在沙箱、节点、API 还是模板
- 再转到对应详细页面继续排查
路径二：Dashboard 页面能打开，但操作异常
- 先看 API 连通性和鉴权是否开启
- 再看模板是否
READY - 再看节点是否健康
- 最后回到沙箱页确认实例和日志
路径三：模板或实例经常失败
- 先看失败模板数量是否上升
- 再看是否伴随节点资源饱和
- 再回模板详情或沙箱详情查看具体错误
与其他 Dashboard 页的分工
你可以把可观测性页理解为“巡检入口”，而不是最终处理页：
- 继续看实例与日志： 沙箱管理
- 继续看模板状态与重建： 模板管理
- 继续看节点容量与副本： 节点与容量
- 继续看入口、出网与配额： 网络（Network）