仪表盘与指标

两类数据分开读

/admin/overview 展示业务分析和系统健康两类数据，API 分别是 /api/v1/admin/dashboard/business 和 /api/v1/admin/dashboard/system。它们都是管理员接口。看板是只读模型，不是身份、文件、配额或对象状态的最终写入来源。

业务事件由 Analytics Worker 投影到读模型，因此数据可能有延迟。刷新图表不代表后台事件已处理完，也不要因为曲线暂时缺失就推断业务数据丢了。

时间范围

range 支持 today、7d 和 30d，按 Asia/Shanghai 日历日期解释，结束时间是本次响应生成的时刻。today 从当地午夜开始，7d 包括今天和之前 6 个日历日，30d 包括今天和之前 29 个日历日。

它们不是固定向前滚动的 24、168、720 小时窗口。比较两次响应时，同时看一下实际起止时刻、时区和数据覆盖范围，不要只比较按钮文字。

下载次数的两个口径

Successful Download 只有 Storage 完成了完整的对象字节响应后才计入。仅仅是申请或消费 Download Ticket 并不算一次完整成功下载。

而分享记录的 downloadCount 在成功签发分享票据时就增加了。所以你可能看到分享次数限制已经减了一次、但看板的成功下载仍然是零——这可能是下载没有完成，两者并不矛盾。详见分享。

空间和健康口径

Committed Storage Bytes 是 Core 完成版本确认后计入配额的字节。Physical Object Bytes 是存储层的对象占用，可能包含历史版本和暂时未协调完成的对象。不要要求这两个指标始终相等。

System Health 用 available、partial、unavailable 来表达数据源的可用性。只有部分来源能响应时，某些字段会保留 null。没有 Prometheus 数据不等于 CPU 为零、服务健康或故障已修复。

Freshness 与 Coverage

Freshness 描述的是最新处理的事实以及延迟情况；Coverage 描述的是从什么时候起有可靠的观测以及中间的缺口。数据很新但历史覆盖可能不足，覆盖很长但当前处理可能有延迟。业务指标为 null 或覆盖不完整时，保持未知状态就好，不要改成零来补齐图表。

遇到空白或延迟

先区分是 401/403 权限错误、503 服务错误，还是成功响应中的 partial/null。然后由运营者检查 analytics-worker、数据库、Prometheus 和 Core 的相关状态。报告时附上你选择的 range、时间、可用性描述和脱敏错误信息就够了，不要依据看板数据独自去修改文件或配额。