opsx
d0adc095dd
=== 问题（实测）===
按应用排行必须读日志内容（Loki 3.4 的 index/volume 不支持 app 维度聚合，
aggregateBy=app 无效），成本 ∝ 时间范围：
5 分钟 ≈ 1.3GB → 9.8s
15 分钟 ≈ 3.9GB → 19.5s
1 小时 ≈ 15GB → 预计 60~90s
6 小时 ≈ 92GB → 5~8 分钟
24 小时 ≈ 370GB → 不可用
用户在时间范围里选 6h/24h 时，页面必然卡死。
=== 方案 ===
新增 models.AppVolumeSnapshot + services/app_volume.go：
- 后台任务每小时第 5 分钟抓「上一个完整小时」的 per-app 条数
- 用**瞬时查询**（/loki/api/v1/query + [1h]）而不是 query_range：
单点评估、扫描量相同、省掉多步开销；并绕开 LokiMetrics 的 90s 上限
与重型查询信号量（后台任务不该和前台抢令牌）
- 每源每小时只留 top 50 应用，保留 90 天
- 幂等：同 (hour, source, ns, app) 更新而非重复插入
- 超出 Loki 26h 保留期的窗口跳过（抓也抓不到，白等几分钟）
新增 GET /api/v1/logs/app-ranking?sourceId&from&to&limit → 读库毫秒级
前端：analysis 判断范围 > 60 分钟就走预聚合接口，并停掉实时重查询
（rankingEnabled 置 false）；表格副标题说明「读的是预聚合快照，已留存 N 小时，
不含错误数与趋势」。
=== 顺带修掉的根因 bug ===
useInView 原来用 useRef + useEffect([inView])：分析页首屏 data===null 时
内容块不渲染，ref.current 为 null，effect 直接 return；等数据到了 DOM 才挂上，
但依赖没变 → effect 不重跑 → IntersectionObserver 从未创建 → inView 永远 false
→ 重查询永不发出 → 页面一直显示"没有应用维度的数据"。
改成 callback ref（节点挂载即作为依赖），并加 scroll/resize 兜底 + 挂载瞬间量一次。
另外分析页加 8 秒无条件兜底：可见性判定再失灵，8 秒后也一定查一次。
默认时间范围 15 分钟 → 5 分钟（19.5s → 9.8s）。
=== 实测 ===
Pod = Hub latest = 98de87e7f895
5 分钟窗口 by-app：9.8s（75 序列）；15 分钟：19.5s