opsx
37e2f0febc
=== 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
30 lines
1.5 KiB
Go
30 lines
1.5 KiB
Go
package models
|
|
|
|
import "time"
|
|
|
|
// DailyVolumeSnapshot 每日日志量快照（平台自己留存的历史）。
|
|
//
|
|
// 为什么必须落库：
|
|
// Loki 的 retention_period 是 24 小时（运维可改，但默认就该短），
|
|
// 意味着「近 7 天每日日志量」直接查 Loki 时，只有最近 1 天有数据，
|
|
// 其余 6 天是空的 —— 界面上看着像坏了，实际是数据已经不在了。
|
|
// 想要 30 天 / 1 年趋势，只能在数据被删前每天抓一次存进平台库。
|
|
//
|
|
// 粒度说明：
|
|
// - 只按「数据源 + 命名空间」存。index/volume 系列接口只能按 selector 标签聚合，
|
|
// 拿不到按 app 的拆分（Loki 3.4 不支持 aggregateBy），
|
|
// 所以按 app 的历史量暂时无法落库，应用维度请看实时排行（有 20~30s 成本）。
|
|
// - 每天一条，日期用**本地时区**的 YYYY-MM-DD，避免跨时区对不上。
|
|
type DailyVolumeSnapshot struct {
|
|
ID uint `json:"id"`
|
|
Date string `json:"date"` // YYYY-MM-DD（本地时区）
|
|
SourceID uint `json:"sourceId"` // 数据源
|
|
Namespace string `json:"namespace"` // "" 表示该数据源全量
|
|
Bytes int64 `json:"bytes"` // 日志体积
|
|
Entries int64 `json:"entries"` // 日志条数
|
|
// Partial 该日期是否为"不完整的一天"（当天抓取时还没过完）。
|
|
// 前端用它区分"真实低峰"和"只统计到一半"。
|
|
Partial bool `json:"partial"`
|
|
CapturedAt time.Time `json:"capturedAt"`
|
|
}
|