 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 |
|
|
opsx
|
cb91470d75
|
perf(analysis): 分层加载 + 修复裸 i18n key + 单位混用；附 Loki 查询方式的实测对比
=== 1. 界面显示裸 key（trend.subtitle / daily.subtitle / table.subtitle）===
根因：中文语言包只加了 title，**没有 subtitle**，而英文包有。
i18next 找不到 key 就把 key 原样输出，所以界面上出现 "trend.subtitle" 这种文字。
已补齐 zh 的 trend/stream/pie/daily/table 五个 subtitle，并把文案改成
人话（说明数据来源与是否需要等待），例如：
trend : 按时间分桶的日志量（来自索引统计，秒级返回）
daily : 近 7 个自然日的每日总量（来自索引统计，不受上方时间范围影响）
table : 按日志条数排前 10 的应用，点「查看日志」跳到查询页
=== 2. 分层加载：上面的先出，下面滚到再算 ===
新增 hooks/useInView.ts（IntersectionObserver，提前 200px 触发，只触发一次）。
- 首屏只跑索引类查询（histogram + index/stats），**合计 <100ms**
- 「每日日志量」「应用排行」「Ingress 分析」三块滚动到视口才发查询
- 排行卡片加载中显示"正在按应用统计（需读取日志内容，通常 20~30 秒）…"，
不再是空表格让人以为卡死
=== 3. 修复自己引入的单位混用（重要）===
趋势图数据源从 count_over_time 换成 index/volume_range 后，返回值是**字节**，
但排行表里的值是**条数**，两者混用导致：
- 统计卡显示 7956179750 这种看不懂的裸数字
- 排行占比算成 0.0x%（分子条数、分母字节）
修法：
- 统计卡拆成两张且都走索引接口（实测 histogram 50ms / index-stats 43ms）：
日志条数（索引统计） ← index/stats entries，精确条数
日志体积（索引统计） ← volume_range 累计，格式化为 GB
- 排行占比分母改用 apps 自身条数合计
- 去掉"告警行数"卡片：为了把重查询从 3 条降到 2 条已放弃全局 warn 统计，
显示一个恒为 0 的数字比不显示更误导
=== 4. Loki 查询方式实测对比（15 分钟 astralx，370GB/天）===
直接打 Loki，逐个验证卡在哪：
sum(count_over_time({ns}[30s])) step=30s 61s 超时 ← 全集群全局
sum by (app,ns)(count_over_time([30s])) step=30s 19.7s 5.5GB ← 现用
sum by (app,ns)(count_over_time([15m])) step=15m 47s 超时 ← 反直觉！
sum by (app)(count_over_time([30s] |= error)) step=30s 12.7s 5.5GB
单 app gateway count_over_time step=30s 12.6s 0.58GB
index/volume (limit=200) 2.2s ← 只给 selector 级，不能按 app
index/volume_range (step=60s) 133ms
index/stats 112ms ← entries/bytes 精确
两个结论（写进注释，避免以后又"优化"回去）：
a) **不要把 range 和 step 一起放大**：`[15m]` + step=15m 看着"点数少"，
实际要让 Loki 为单个 evaluate 点加载 15m 的 chunk，比 [30s]+step=30s 慢 2 倍以上
（47s 超时 vs 19.7s）。
b) **按 app 分组无法走索引**：Loki 3.4 的 index/volume 只回落到 selector 标签，
不支持 aggregateBy=app（传了也无效果）。所以 per-app 排行只能读日志内容，
20 秒左右是这台集群的物理下限 —— 只能靠懒加载 + 明确提示来改善体感。
=== 实测（v8-1028-2232 / 7a05683a91ae）===
logs/histogram 50ms logs/stats 43ms
by-app 排行 25077ms（懒加载，滚动到才发）
中文 subtitle 已进包：来自索引统计 / 按量排前 / 各命名空间的日志量占比 /
近 7 个自然日 / 按日志条数排前 10 各命中 1 次
|
2026-10-28 22:34:04 +00:00 |
|