rlwj-lab/LokiStack
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
157 Commits 1 Branch 1 Tag
f02b1daee1e28ebdeb8951093713b75e58563d36
Commit Graph
12 Commits
Author SHA1 Message Date
opsx 5f42d9f696 perf(logs): label 缓存 TTL 30s + 平台变更即时失效（回答"新 app 会不会延迟"）
CI / Backend (go vet + test) (push) Canceled after 0s
Details
CI / Frontend (lint + build + test) (push) Canceled after 0s
Details 
问题：加了 60 秒缓存后，新增 app / 新副本 / 新主机采集器要等最久 60 秒
才出现在下拉里，抢修时"刚上线的服务查不到"是不可接受的。

两层处理：

1) TTL 60s → 30s（前后端一致）
   纯 Loki 侧的变更（新 Pod 开始打日志、新副本、主机上新进程写日志）
   最长 30 秒可见。这类变化平台无从感知，只能靠 TTL 兜住。

2) 平台侧变更**立即失效**（不等 TTL）
   新增 InvalidateLabelCache()，在下列入口 defer 调用：
     CollectorService.Create / Update        （主机模式 app 标签来源）
     DeploymentService.Delete                （连带清理托管数据源）
     CreateLogSource / UpdateLogSource / DeleteLogSource
   也就是"用户在平台上做了什么导致候选值集合变化"，缓存当场清掉，
   下一个请求必然回源。这正好覆盖"主机采集的 app 标签"这个场景 ——
   采集器一改，下拉里马上就有。

关于「要不要用定时任务预热」：
   不做。预热只能省掉一次 25~40ms 的网络往返，却要多一个常驻任务和
   一份额外的失败路径；而"时效性"问题已经由上面的即时失效解决了。
   如果将来真要削掉这 40ms，更划算的做法是把 label 值随部署一起下发缓存，
   而不是定时轮询 Loki。
 2026-10-31 18:27:17 +00:00
opsx 5f42ac5486 perf(logs): 快捷 LogQL 下拉加前后端双层缓存，重复打开不再转圈
CI / Backend (go vet + test) (push) Canceled after 0s
Details
CI / Frontend (lint + build + test) (push) Canceled after 0s
Details 
=== 先测清楚瓶颈在哪 ===
后端单点实测（都很快，不是问题所在）：
  /logs/my-scope                    10ms
  /logs/label/namespace/values      25ms
  /logs/label-values?scoped astralx 23ms
  /logs/label/app/values scoped     18ms
结论：慢的是**前端每次都重新走一遍请求链**（切数据源 / 切命名空间 / 重开面板
都会触发），三四次往返串起来 + 每次都有 loading 态，用户看到的就是转圈。

=== 后端：label 候选值短缓存 ===
services/log_query.go：60 秒 TTL，key = sourceId|label|selector|时间窗(按 5 分钟取整)，
上限 500 条并做过期清理。理由：下拉值的时效性要求很低——
新上线的 app 晚 1 分钟出现在候选里完全可以接受。
LokiLabelValuesBatch 内部逐个走 LokiLabelValues，所以批量接口自动受益。

=== 前端：内存缓存 + 飞行中请求合并 ===
api/logs/index.ts：60 秒 TTL 的 Map，**缓存 Promise 而不是结果**，
所以并发的相同请求共享同一次飞行（去重）；失败立刻剔除缓存，避免缓存错误。
带 AbortSignal 的调用不参与缓存（用户主动取消的请求不应共享给别人）。
额外导出 invalidateLabelCache()，数据源变更时可手动清。

=== 预期效果 ===
  首次打开：与之前相同（~100ms 量级）
  再次切换 / 重开面板：直接命中内存，0 请求
  服务端重复请求：25~40ms → 微秒级
 2026-10-31 18:22:38 +00:00
opsx d4422f1541 refactor(analysis): 去掉排行 10/30/50 选择器，改为一次取 50 + 前端分页；零点结算昨天
CI / Backend (go vet + test) (push) Canceled after 0s
Details
CI / Frontend (lint + build + test) (push) Canceled after 0s
Details 
=== 1. 为什么去掉「显示条数」选择器 ===
topk 的 N 不影响查询成本（扫描的 chunk 集合完全相同），实测：
  topk(10)  17833ms / 11 条
  topk(30)  18019ms / 34 条
  topk(50)   7394ms / 54 条
  topk(100) 17553ms / 74 条
波动来自集群负载，与 N 无关 —— 它只决定最后返回多少序列。
所以"选 30"既不更快也不更慢，本质是个翻页开关；
而选它还要重新等一次十几秒的查询，纯亏。
改为：一次 topk(50)，前端 10 条/页 → 5 页只需 1 次查询。
附带收益：占比的分母从"前 10 合计"变成"前 50 合计"，更接近真实占比。
副标题明确写清"一次取前 50 个应用（占比按这 50 个合计计算）"。

=== 2. 零点结算昨天（daily volume）===
原来只有 30 分钟 ticker 回补，且启动时间不对齐整点 →
昨天最早的一段可能已经超出 Loki 24h 保留期被删，
结算结果系统性偏低，图上却标"完整一天"，属静默错数。
新增 nextMidnightFinalize()：每天 00:01 触发 FinalizeYesterdayVolume()
  - 昨天定稿 partial=false
  - 补一次条数（index/stats，一天一次可接受）
  - 顺带刷新今天 partial=true 的柱子
ticker 仍保留，负责当天数据的 30 分钟刷新。

=== 3. 顺带 ===
- 去掉每日量"其中 N 天平台没有留存记录"的提示文案（按用户要求）
- 修 QuickQueryTemplates.tsx 的未使用变量导致 tsc -b 失败
- 工作区里上一轮中断的"排行体积列"改动一并纳入（app-ranking 返回 bytes，
  TopAppsTable 增加体积列，快照记录 per-app 字节数）

Pod = Hub latest = a16978d2f88b
 2026-10-30 17:13:18 +00:00
opsx 7b1ffd0274 fix(daily-volume): 30/90/365 天切换"没反应"；/logs/stats 加短缓存
CI / Backend (go vet + test) (push) Canceled after 0s
Details
CI / Frontend (lint + build + test) (push) Canceled after 0s
Details 
=== 1. 切换范围没反应（真 bug）===
现象：7/30/90/365 天切换后图完全一样。
根因：GetDailyVolumeHistory 只返回**已抓到的快照**。平台只有 4 天数据，
      所以任何 days 都只返回 4 个点 → 图表一模一样。
修复：始终返回 days 个点，缺失的天用 Missing=true 标记。
      实测：days=7→7 点(缺3)、30→30 点(缺26)、90→90(缺86)、365→365(缺361)。

为什么必须区分 Missing 和"0 字节"：
  前者是"平台没留存"，后者是"那天确实没日志"。
  混在一起会让 30/90 天的图上出现大片 0，被误读成"日志量暴跌/系统停摆"。
前端：缺失的天画灰色浅柱，tooltip 显示"未留存"，图下方提示
      "其中 N 天平台没有留存记录（灰色柱），不是当天没有日志"。

=== 2. /logs/stats 加 90 秒缓存 ===
分析页每次进入/切范围都打 index/stats，实测 5 分钟窗口冷查询 1.2 秒
（60 分钟更慢）。这类聚合值可容忍分钟级陈旧，加与指标查询一致的缓存：
  90s TTL + 时间窗按 2 分钟取整 + 上限 200 条 + 过期清理
实测：重复请求 1227ms → 8ms。

=== 3. 顺带确认已生效的优化 ===
  histogram(24h)   : 54ms（volume_range）
  daily-volume     : 10ms（只读库）
  stats 二次请求    : 8ms（新缓存）
  长范围(>1h)       : 不跑 count_over_time（预聚合快照 + 跳过内容扫描）

Pod = Hub latest = 12453ea723c1
 2026-10-30 16:46:40 +00:00
opsx d0adc095dd feat(analysis): 长范围应用排行改走「小时级预聚合」，不再扫日志内容
CI / Backend (go vet + test) (push) Canceled after 0s
Details
CI / Frontend (lint + build + test) (push) Canceled after 0s
Details 
=== 问题（实测）===
按应用排行必须读日志内容（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
 2026-10-30 16:35:35 +00: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
opsx 3191af8b6a feat(logs): 上下文前后条数可配置（默认 2，原来写死 5）+ 每页条数改预设选项 
=== 一、问题 ===
查看日志上下文时，前后各取几条是**写死**在控制器里的：
  span := 5 * time.Minute
  QueryLokiLogs(..., ts-span, ts-1, 5, "backward")   // 5 条
  QueryLokiLogs(..., ts+1, ts+span, 5, "forward")    // 5 条
三处写死：条数 5、时间窗 5 分钟、且用户无法调整。

写死的三个实际弊端：
1. 排障时想看更多（比如前后 20 条找调用链）做不到；
2. 只想看紧邻 2 条时，仍然要扫 5 分钟窗口、返回 5 条，浪费；
3. 时间窗与条数不匹配——某服务日志稀疏时，5 分钟窗口里可能一条都没有，
   于是"前后各 5 条"实际返回 0 条。

=== 二、改动 ===
1. backend/dto: LogContextRequest 新增 before/after（可选）
2. backend/controllers: normalizeContextLines()
   - 不传或 ≤0 → 默认 2 条
   - 上限 50 条（防止一次弹窗拉几百条）
   - 时间窗改为**按条数自适应**：每条按 30s 估算，最少 1 分钟、最多 2 小时
     （不再固定 5 分钟，解决"稀疏服务取不到上下文"的问题）
3. frontend
   - 上下文弹窗标题栏加「前后各 [2/5/10/20/50]」选择器，切换后原地重新拉取
   - 选择结果写入 localStorage，下次沿用
   - 每页条数：数字输入框 → 预设下拉 [100/500/1000/2000/5000]
     （原来只能手输且硬顶 1000，现在上限提到 Loki 默认的 5000）
   - i18n：去掉"前后各最多 5 条 · 前后 5 分钟"的写死文案

=== 三、实测（平台 API）===
  before=2   after=2   → 2 / 2 条
  before=5   after=5   → 5 / 5 条
  before=10  after=10  → 10 / 10 条
  before=50  after=50  → 50 / 50 条
  before=999 after=999 → 50 / 50 条（超上限自动收敛）
  不传                 → 2 / 2 条（默认值生效）

镜像：lghost/lokistack:latest + v0.1 = sha256:d19239fa65f3
 2026-10-28 16:14:05 +00:00
opsx 5d530036e6 feat(logs): 分页显示总页数（新增 /logs/stats，走 index/stats 只读索引） 
用户反馈：底部只有「上一页 第 1 页 下一页」，看不到末尾/总页数。

原因：日志结果是 Loki 游标分页（cursor = 纳秒时间戳），本身不返回总数，
前端只能知道"有没有下一页"，算不出总页数。

解法：新增 POST /api/v1/logs/stats
  → 调 Loki /loki/api/v1/index/stats（只读 TSDB 索引里的 chunk 元数据）
  → 返回 {streams, chunks, bytes, entries}
  → 前端用 entries / limit 得到总页数
实测成本极低：1h 51ms、24h 30ms（3.28 亿条 / 44.2 GB）。

改动：
1. backend: services.LokiStatsFor + controllers.LogsController.Stats + 路由 /logs/stats
2. frontend: logsApi.stats；查询成功后拉取总数（复用同一 AbortController，
   失败静默不影响日志展示）；计算 totalPages 传给结果面板
3. LogResultsPanel: 有总数时显示「第 N / M 页」，否则维持「第 N 页」
4. i18n: 新增 results.pageOfTotal（中英）

镜像：lghost/lokistack:latest + v0.1 = sha256:41d6576ec232
 2026-10-28 16:02:35 +00:00
opsx de376a1284 perf(logs): 日志量统计改用 index/volume_range（快 ~1300 倍）+ 查询护栏 + 真实错误提示 
=== 一、现象 ===
- /logs 页「正在统计整个时间范围的日志量」24 小时查询转圈 5 分钟不出结果
- /analysis 页默认 1 小时也一直「加载中...」
- 期间 Loki 被 OOMKilled(2Gi) → Pod not Ready → Service 无端点 → 全站查询 502

=== 二、根因（实测数据） ===
同一 query {namespace="astralx", app="cex-ipublic-gateway"}：
  24h count_over_time[15m] step=15m  → 53.7s 后连接断开（算不完）
  24h count_over_time[1h]  step=1h   → 60.1s 失败
  24h index/stats（只读索引）        → 1.3s  → bytes 44.9GB / entries 3.33亿 / chunks 2474
  24h index/volume_range step=1h     → 111ms → 25 个点
  1h  index/volume_range step=5m     → 115ms → 13 个点

原因：count_over_time 必须**下载并解码所有 chunk**；volume_range 只读 TSDB 索引里的
chunk 元数据（字节数），根本不碰日志内容。该 app 一天就有 3.33 亿条 / 44.9 GB。

=== 三、改造 ===
1. LokiHistogram 改用官方 /loki/api/v1/index/volume_range（带 step）
   - 返回单位是「字节」，bucket 带 unit=bytes，前端格式化为 KB/MB/GB
   - 老版本 Loki 没有该端点时自动回退 count_over_time（unit=entries）
2. 查询护栏（防止单条查询拖垮单实例 Loki）
   - 统计范围上限 7 天，超出直接 400「统计范围过大（27.0 天），最多支持 7 天」
   - 重查询单独 30s 超时（原来 120s）
   - 全局并发重查询上限 2，超出立刻 429「请稍后重试」（不排队）
   - /logs/metrics（analysis 页）共用同一套护栏
3. 前端
   - 发起新查询前 abort 上一次请求（原来只用版本号丢弃结果，旧请求仍在后端跑）
   - histogram/query 支持 signal；超时 40s/60s（原 125s）
   - 错误不再统一显示「日志量统计失败」，按 429/400/502/超时给不同文案
   - 时间线按 unit 格式化（字节 → GB），i18n 去掉「条」
4. Loki 侧官方优化（此前 limits_config 只有 retention_period）
   - query_range: align_queries_with_step + cache_results + embedded_cache 100MB
   - limits_config: max_query_parallelism 8（默认 32，单实例过高）
   - 已用 `loki -verify-config` 校验通过（config is valid）

=== 四、实测（平台 API） ===
  1 分钟  0.02s  2 桶
  1 小时  0.05s  61 桶  3.8 GB
  6 小时  0.04s  73 桶  12.3 GB
  24 小时 0.04s  97 桶  41.8 GB   ← 改造前 53.7s 失败
  7 天    0.05s  37 桶  58.2 GB
  27 天   0.01s  400「最多支持 7 天」

镜像：lghost/lokistack:latest + v0.1 = sha256:9fa1c4597533
 2026-10-28 15:54:55 +00:00
Codex 11d0fff764 fix(frontend): 补齐 analysis 构建依赖与共享组件搬迁 
补 commit hooks/图表组件、路由与 i18n domains、logs metrics API；
StatCard/TimeRangePicker/ingress-access-log 抽到共享路径，干净 checkout 可编过。
 2026-10-28 22:00:30 +08:00
opsx cf54be3f7d fix(logs): 「所有人」策略保存被拒 + 快捷 LogQL namespace 空且不认默认策略 
=== 一、保存策略组报「用户ID无效或重复」===
validatePolicyGroup 里 `if id == 0 || seen[id]` 直接把「所有人」哨兵当非法。
修复：
  - 新增常量 AnyoneUserID = 0（与 policyGroupAccess、前端 ANYONE 对齐）
  - 0 跳过用户存在性校验，但必须独占：与具体用户混选时报
    「「所有人」不能与具体用户同时选择」
  - 重复检查独立出来，报错带具体 ID

=== 二、快捷 LogQL 的 namespace 下拉总是空的 ===
两个叠加原因：
  1. 用的是原生 <datalist>，只在输入时才提示、样式弱，看着像"下拉是空的"
  2. 候选只来自 Loki 实际值 —— 而默认策略配的 default 命名空间里没有业务 Pod，
     Loki 里根本没有这个 label 值，所以永远不出现；前端也不会拿策略值当默认选中

修复：
  后端新增 GET /api/v1/logs/my-scope?sourceId= → {labels, unrestricted}
    （services.UserAccessLabels 暴露当前用户在数据源上的授权 labels；
      admin 返回 unrestricted=true 但仍带上策略 labels 供 UI 做默认值）
  前端：
    - logsApi.myScope()
    - QuickQueryTemplates 用策略里的 namespace 作为初始选中值
    - namespaceOptions = 策略值 ∪ Loki 实际值（去重，策略值优先）
    - namespace/app/pod 三个 <datalist> 全部换成 SearchableValueSelect
      （点击即展开、可搜索，placeholder 显示「请选择（共 N 个）」）

验证：
  PUT /logs/policy-groups/1 {userIds:[0]}         → 200 ✅
  POST userIds:[0,2]（混选）                       → 400「「所有人」不能与具体用户同时选择」✅
  GET /logs/my-scope?sourceId=1                   → {"labels":{"namespace":"default"},"unrestricted":true} ✅
  bundle: my-scope 1 处、datalist 残留 0 处 ✅

镜像：lghost/lokistack:latest + v0.1 = sha256:ad659f564665
 2026-10-27 02:59:33 +00:00
logan 2d73661dd1 feat: complete Loki query, insights, settings and deployment workflows 
Add the Loki query UI, access policies, ingress insights, alert and registry settings, and their backend APIs. Include the related Kubernetes deployment and collector updates required by the integrated application.

Validated with go test ./..., npm run build, and npm run lint.
 2026-10-25 21:28:32 +08:00