3 Commits

Include renames

Author	SHA1	Message	Date
opsx	b7de337c9e	perf(daily-volume): 每日量抓取拆成「体积每 30 分钟 / 条数每天最多 3 次」 ... === 现象 === 用户问：每日日志量不是有定时任务记录吗？为什么还要每次查询？ 盘了一遍发现：定时任务确实有（每 30 分钟），接口也确实只读库（实测 0.1ms）， 但每轮抓取都顺手跑一次**整天 index/stats** 拿条数（实测 6ms ~ 20s，随负载波动）， 2 天 × 多个数据源 × 每 30 分钟 = 一天几十次重查询，纯浪费单实例 Loki 的算力， 还会和用户页面上的查询抢 CPU。 第二条更糟：仓库里所有快照的 partial 全是 true。 根因：partial 里混了两种语义 ——「今天还没过完」和「起点超出 24h」。 后者让昨天/前天的柱子也画成虚线空心，看起来「每天都在进行中」。 === 修法 === 1. 抓取按成本拆成两条路径（体积走 volume_range，条数走 index/stats）： - 体积：今天 + 昨天，每 30 分钟刷，54ms~4s，无感 - 条数：只对**已结束**且 entries==0 的天补，每天最多 3 次、间隔≥1h； 尝试次数**先写库再查**，进程中途被杀也不会退化成每 30 分钟重试 2. partial 只表示「今天还没过完」，昨天起是实心柱 3. 0 与「未留存」分开：起点超出 24h 且查不到数据 → **跳过落库**保持 Missing。 否则「数据被 retention 删掉」会被画成「那天没有日志」，比灰色柱误导得多 4. 每次抓取打日志：`[daily-volume] 2026-10-30 体积 291.37 GB 已落库（volume_range 4.27s，34 个桶）` —— 以后不用猜「到底抓没抓、走的哪条路径」 === 实测取证（本集群）=== Loki 直接查（port-forward :13100）： 10-30(16.8h) volume_range 291.37GB/34桶 index/stats entries=2.21B 10-29(24h) volume_range 121.99GB/19桶 index/stats entries=927.9M 10-28/10-27 volume_range 0 桶、index/stats 0 —— 已被 retention 删掉 同范围 count_over_time 两次 60s 超时（永远别用在每日量上） 平台库里的快照与上述数字一致（288.32 / 121.75 GB），说明落库值可信； 10-27/10-28 的 34.87/25.65 GB 是当时抓的 —— 这正是「Loki 只留 1~3 天， 历史必须自己落库」的实证。 go vet ./services/ ./models/ 干净；go build 通过；go test ./services/ 通过。	2026-10-30 16:52:55 +00:00
opsx	4f74fe6c3f	ci(engineering): Gitea Actions 门禁 + 前端测试设施 + 版本注入修复 ... - .gitea/workflows/ci.yml:后端 gofmt/vet/test + 前端 lint/test/build 双 job 门禁 - vitest + @testing-library + jsdom 落地,14 个命脉用例:useListQuery 乱序丢弃/卸载中止、 http.ts 401 单飞刷新+队列重放+失败登出+silent 直拒、审计防抖、StepDeploy 部署目标、query-utils - 版本注入断裂修复:main 补 buildTime/gitCommit 符号,build.sh/Dockerfile 注入 main.version, /health 返回真实版本,前端 package.json 版本对齐 2.0.0 - gofmt 清零(8 个存量未格式化文件)	2026-10-29 13:02:19 +08:00
opsx	37e2f0febc	feat(analysis,alerts): 每日量落库看历史趋势、趋势图/饼图可读性、告警三分页 ... === 1. 每日日志量必须落库（核心问题：Loki 只留 24 小时）=== 实测：请求"近 7 天每日量"，Loki 只返回 27 个**小时**桶，全部在最近 24h 内 —— 因为 retention_period=24h，更早的 chunk 已经被删了。 也就是说「固定近 7 天」这张卡片，过去一直是"6 天空白 + 1 天有数据"， 用户看着像坏了，实际是数据物理不存在。 方案：平台自己留存历史。 - models.DailyVolumeSnapshot{Date(本地YYYY-MM-DD), SourceID, Bytes, Entries, Partial} - services/daily_volume.go CaptureDailyVolume 按天抓 index/stats 落库（幂等覆盖） StartDailyVolumeCapture 启动 20s 后回补 + 每 30 分钟检查一次 GetDailyVolumeHistory 读库返回最近 N 天（今天会实时补抓） - 保留 400 天（够看年度趋势），按 source+date 去重 - 前端可选 7 / 30 / 90 / 365 天，能看多长取决于平台积累多久 为什么用"每 30 分钟检查昨天有没有落库"而不是固定 00:10 定时： 平台可能整晚没运行，固定时点的定时器会直接错过；检查式回补不依赖平台在线时刻。 Partial 标记（关键，否则会误读）： - 当天未结束 → partial=true - 待抓取日期的起点已超出 24h 保留期 → partial=true（Loki 里就没那么多数据） 实测：10-27 32.5GB/2.65亿条 partial=true（保留期外）， 10-28 348GB/28.56亿条 partial=true（当天进行中） === 2. 修一个 Go 副本 bug（自己写的，靠实测发现）=== 第一版用 `for _, snap := range db.DailyVolumeSnapshots` 后改 snap 字段， range 拿到的是**副本**，改动不会写回切片 → 同一天永远保持首次抓取的值， partial 也永不更新（实测发现 10-27 该是 true 却显示 false）。 改为 `for i := range ... { snap := &db.DailyVolumeSnapshots[i] }`。 === 3. 趋势图可读性 === 从"裸折线"换成"渐变面积图"，并在图上方给出峰值 / 均值： - 面积图能一眼看出"这一段整体比上一段高"，折线只能靠对齐格子数 - 峰值/均值避免用户自己对刻度 - Y 轴与 tooltip 统一 formatBytes，"每桶体积"写进 subtitle 顺带确认：趋势图只画体积（字节），不再混入 error（条数）——单位不同不能同轴。 === 4. 饼图：命名空间分布 → 应用日志量分布 === 本环境的命名空间只有 astralx / log 两个，饼图没有信息量； 改成按应用看谁在刷日志（前 8 名 + 其他），才是运维真正要的答案。 === 5. 告警页拆成三个 Tab === 「告警规则 / 通知通道 / 发送历史」独立成分页（用 ui/tabs）。 之前通道是折叠块、历史堆在规则下面，规则一多就要滚很久才看得到。 发送历史增加空状态文案，不再是"空页面不知道有没有在发"。 === 6. 内置规则关联默认通道 + 首次部署 webhook 留空的评估 === 结论：**webhook 可以留空，但通道必须是禁用状态**。 - 若种子给的是"已启用 + 空地址"通道，规则一命中就必然投递失败， 发送历史堆满红色失败，反而让人以为平台坏了 - 所以首次部署建一个**禁用**的占位通道「默认通知通道（待配置 Webhook）」， 内置规则全部挂到它；管理员填好 Webhook 再启用即可，不用逐条关联 - 保存时加校验：启用则必须有非空 Webhook（返回明确原因，不是裸 500） - schemaVersion v5→v6：把已有的"无通道"规则补挂到默认通道 实测：8 条规则全部已关联通道 === 实测（v11-1028-2252 / 187062644c0f）=== /logs/daily-volume?days=7 → 2 天数据，partial 标记正确 规则 8 条全部有 channelIds 平台 ready、健康 ok	2026-10-28 22:54:12 +00:00