opsx
a14bdb5e07
用户的三个现象，对应三个独立缺陷： === 1. 每日日志量"一直没数据" === 接口只读平台库，实测 **10ms**，却仍被 inView 懒加载门控。 ref 虽然挂在 DOM 上，但滚动判定在多层布局里不可靠 → enabled 一直 false → 请求根本不发 → 页面显示"暂无历史数据"。 改为：只要有数据源就加载（enabled = Boolean(sourceId)）。 这个接口 10ms，没有任何理由懒加载。 === 2. 排行/流图"打开没有数据，等很久也没 loading" === 按应用统计要 10~15 秒（读日志内容，物理下限）。 但 loading 是**整页共用**的：索引类指标 100ms 就回来、 重查询还在跑时 loading 就已经变 false， 卡片于是渲染成"没有应用维度的数据"——用户以为查完了、没数据。 改为： - 新增 appsLoading，专门标记"按应用统计"这段重查询 - 卡片在 appsLoading 期间显示 spinner + "正在按应用统计…" - loading 与 appsLoading 都在 finally 清理（成功/失败/取消都清） === 3. data 为 null 时整页空白 === 原来 `) : !data || !sourceId ? null : (` 直接 return null， 首屏或重查询异常时是**整页空白**，和"没数据"无法区分。 改为显示 spinner + "正在按应用统计（需读取日志内容，通常 10~30 秒）"。 === 关于"用 Go 定时任务统计每日总量"=== 这个机制**早就存在**（services/daily_volume.go）： - 启动 20s 后回补 + 每 30 分钟一次 ticker - 用 index/stats 取整天的条数与字节，**不读日志内容**，通常秒级 - 快照写入平台库，保留 400 天 实测当前库内已有 4 天数据（10ms 返回）： 2026-10-27 32.5 GB 2026-10-28 23.9 GB 2026-10-29 133.6 GB 2026-10-30 239.3 GB 问题只在"前端没去请求"，不在采集侧。 实测（df3b477e6740）：每日量接口 10ms 返回 4 天，Pod 1/1 Running。