LokiStack

0 Fork 0

Files

T

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

config

feat(config): 密钥自动生成下沉到后端 + 安装文档极简化

2026-10-29 16:07:58 +08:00

controllers

fix(daily-volume): 30/90/365 天切换"没反应"；/logs/stats 加短缓存

2026-10-30 16:46:40 +00:00

dto

feat(collectors): DaemonSet 不再填日志路径，改为「只采集哪些命名空间」多选

2026-10-30 16:03:24 +00:00

middleware

ci(lint): golangci-lint v2 入门禁并归零