rlwj-lab/LokiStack
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
157 Commits 1 Branch 1 Tag
main
Commit Graph
15 Commits
Author SHA1 Message Date
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 ad0d35f72a feat(alerts,logs): A 方案—告警窗口 15m→5m 消重复扫描；数据源可编辑/删除且删后不被自动重建
CI / Backend (go vet + test) (push) Canceled after 0s
Details
CI / Frontend (lint + build + test) (push) Canceled after 0s
Details 
=== 1. 告警窗口 15m → 5m（阈值同比例 1/3）===
背景：检查间隔已改 5 分钟，但规则窗口仍是 15 分钟 ——
同一个 15 分钟窗口每 5 分钟被完整重扫一遍，等于 3 倍重复扫描。
在 370GB/天、全命名空间 selector 下，这是 Loki CPU 的最大稳态来源。

    FATAL            10 → 4        窗口 5m
    Go panic         10 → 4        窗口 5m
    JVM OOM           5 → 2        窗口 5m
    StackOverflow     5 → 2        窗口 5m
    应用错误激增  100000 → 35000    窗口 5m（改名 error > 3.5万）
    ingress 5xx      2000 → 700    窗口 5m
    ingress 4xx     20000 → 7000   窗口 5m
    DB 连接失败      1000 → 350    窗口 5m

阈值按 1/3 缩放是必须的：窗口缩短 3 倍后，同样的流量在 5 分钟内只有
1/3 的条数，阈值不动就永远打不到了。
迁移 v10→v11 只改"窗口仍是 15 且名字匹配内置规则"的项，用户手调的不动。

=== 2. 数据源支持编辑/删除（含托管源）===
原来前后端都把托管源锁死：
  - 前端 `!managed &&` 直接不渲染编辑/删除按钮
  - 后端 DeleteSource 返回「平台部署的数据源随部署管理,请先删除对应部署」
用户的诉求是"数据源必须能编辑和删除"，且确实有场景（不想让某个源出现在
查询下拉里、想改认证头）。

=== 3. 修「删了又回来」的真 bug ===
EnsureLogSourcesForRunningDeployments() 在 **每次打开数据源列表和启动时**
都会给 running 部署补齐数据源 —— 所以删掉托管源后，刷新页面它又回来了，
用户看到的现象就是"删不掉"。

新增 LokiDeployment.AutoSourceDisabled：
  - 删除托管源时置位（DisableAutoSourceFor）
  - EnsureLogSourceForDeployment 见到该开关直接 return
  - 部署被编辑/重新部署时重置（EnableAutoSourceFor），即"你要用它了就恢复"
前端配套文案：
  - 编辑托管源弹窗提示"重新部署会覆盖集群/Service/端口，认证与请求头保留"
  - 删除确认明确"删除后不会再自动重建，重新部署该 Loki 才恢复"

=== 实测（20300eef92d2）===
  v11 迁移后 8 条规则全部 窗口=5m，阈值 4/4/2/2/35000/700/7000/350
  go test ./... 全绿
 2026-10-30 15:28:30 +00:00
opsx fbefcc86df feat(logs,analysis): 分页改"加载更多"+触底自动加载；修懒加载不触发；指标短缓存 
=== 1. 日志列表：去掉页码分页，改「加载更多」+ 触底自动加载（节流）===
为什么不用"上一页/下一页/共 N 页"：
  - Loki 是**游标分页**，不支持 offset，页码天生跳不了页
  - 规模上没意义：15 分钟 4000 万条 → 按 200/页算 40 万页
  - 带 |= / |~ 行过滤时总数根本算不出来（index/stats 只接受 label matcher）
日志排查的真实交互是"继续往下看"，所以改为：
  - 列表底部：「已加载 N 条 · 约 M 条」+「加载更多」按钮
  - 滚动到底**自动加载**，但 2 秒节流 —— 每批都要后端扫 Loki，
    快速滚动连续触发会撞并发护栏（429），反而比手动点更卡
  - 到 5000 条停止并提示"缩小时间范围或加过滤条件"（虚拟滚动只省 DOM，
    不省数组内存，无上限会一直涨）
  - 修正语义 bug：分页原来是 setEntries(result.entries) **整页替换**，
    改成追加（否则"加载更多"等于翻页）
  - 删除 pageCursors 翻页栈与 prevPage/nextPage/pageOf/pageOfTotal 文案

=== 2. /logs/stats 错误映射：Loki 400 → 我们的 400 + 人话 ===
之前带行过滤时 Loki 回 400 "only label matchers are supported"，
被统一包装成 502「Kubernetes API 代理返回 HTTP 400…」，
前端只能当失败静默 → 用户看到"总页数没了"却不知道原因。
现在返回 400 +「含过滤条件（|= / |~）时无法统计总页数：Loki 只支持按标签统计」，
前端据此在条数旁给出提示。

=== 3. 分析页：修"延迟加载永远不触发"（数据一直不出来）===
现象：应用排行/流图/饼图/活跃应用全是"没有应用维度的数据"，每日量"已有 0 天"，
但接口实测正常（by-app 返回 75 条序列、daily-volume 返回 2 天）。
根因：这三块用 useInView 门控，而 ref 挂在 <Card> 上，观察器不触发 → 永远 false
→ hook 直接 return → 页面永远空。
修法：
  - 改用普通 <div ref> 包裹，不依赖组件是否转发 ref
  - useInView 加**几何兜底**：1 秒后若元素已在视口内就直接置 true
    （有些容器里 IntersectionObserver 的 root 判定会和预期不一致）

=== 4. 分析页指标短缓存（26s → 11ms）===
`sum by (app)(count_over_time(...))` 扫 15 分钟 astralx（约 6.6GB）实测 16~28 秒，
Loki 自带结果缓存不命中（时间窗每次都在变）。点刷新/切页都要再等半分钟。
现在按 (数据源, 查询, 时间窗) 缓存 90 秒，时间窗按 2 分钟取整当 key：
  实测第 1 次 23514ms → 第 2 次 **11ms**
代价：命中缓存时数据最多旧 ~2 分钟，对聚合视图可接受。

=== 5. 仪表盘 ===
去掉「平台自检」「N 项需关注」两段文字：卡片本身就是自检结果，
标题重复一遍没信息量；状态改由图标+边框颜色表达。

=== 6. 其它文案修正 ===
饼图空态从「没有命名空间维度的数据」改为「没有应用维度的数据」
（饼图上一版已改成应用维度，文案没跟上）。

=== 实测（1da8a148d756）===
  Pod = Hub latest = v0.1 = 1da8a148d756
  stats：纯 selector → 200（7005 万条）；带 |= error → 400 + 人话
  分析指标缓存：23514ms → 11ms
  每日量：2 天（10-27 32.5GB / 10-28 356.5GB）
  文案：加载更多 / 已到末尾 / 达到上限 均进包；代码中已无 prevPage/nextPage 引用
 2026-10-28 23:36:32 +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
opsx 16306a9532 feat(logs): metrics 指标代理端点(admin) + 快捷查询选中 App/Pod 即插入并执行 
- POST /logs/metrics:LogQL 指标查询代理,[$step] 占位符按跨度自适应步长,返回多序列(httptest 假 Loki 单测)
- 快捷查询:选中 App/Pod 即写入输入框并立即查询,面板保持打开支持 Pod 级联;命名空间仅级联筛选不插入,切换时清理失效标签
- 删除冗余的「查询该范围日志」「指定副本日志」按钮;Ingress 按钮仅在选择 ingress 命名空间/app 时显示
- /logs 支持 ?q= 预填自动执行(表格「查看日志」跳转入口)
- 清理无引用死组件 LogResults/LogHistogram
 2026-10-28 22:43:57 +08:00
opsx f3733f0bfc feat: 品牌统一 LokiStack + 全站中英 i18n + 用户批量删除 + 主题定时切换与浅色侧栏 
- 品牌: Go 模块/数据文件/二进制/构建部署资产全部 opsx→lokistack;前端 localStorage 命名空间迁移(读旧写新,含按用户 id 前缀迁移);修复 nginx upstream 与 Makefile 引用已改名服务的断裂
- i18n: react-i18next 落地,common + 11 个页面域命名空间全站中英(菜单/顶栏/登录/列表页/表单/确认弹窗/状态徽章);设置页语言即时切换;修复词典自注册导致的循环导入白屏
- 用户管理: 批量删除(POST /users/batch-delete,不删自己/最后管理员,部分失败不阻断)+ 行复选/全选/批量工具条
- 主题: 浅色侧栏(中性灰激活态)、四态模式(浅色/深色/跟随系统/定时切换,按时区判定)、顶栏太阳月亮二态、设置页紧凑分段选择器
- UI: 登录记住用户名、CardActionButton 统一五页卡片操作钮、shadcn Badge 替换手写徽章、语义色修正
- 清理: 移除主机 Web 终端(前后端)、k8s-helm/Helm 遗留代码与字段、README 重写精简
- 修复: 侧栏与日志告警 order 重复、路由标题 i18n key 未翻译、词典双逗号等
 2026-10-27 17:11:38 +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 9f7c522157 feat: K8s 部署清单、Token 接入加固与日志/设置页优化 
- kubernetes/: 30Gi PVC、单副本 Recreate、Secret/Service/NodePort/Ingress 清单与部署文档
- 数据安全: kubeconfig/token 统一加密存储，启动迁移历史明文，DB 0600
- Token 接入: 命名空间级最小权限提示、长期 Token、自签证书 TLS 兼容
- 部署: 命名空间级 Token 下跳过 Namespace patch/枚举，节点信息容错
- 日志页: namespace → app → pod 选择顺序与作用域收窄
- 设置页: 拆分为通用/告警/LDAP/镜像源四个 tab
- 弹框: 统一 max-h 滚动与长命令换行，修复内容溢出
 2026-10-25 23:44:07 +08: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
logan f9c6c1d826 feat: opsx-loki 全面升级 — 前端重构/用户与LDAP/部署向导/日志查询 
基于 WEB-UI-Development-Guide 标准的整体升级,并更名 LokiDeploy → opsx-loki。

前端(Gin+React+shadcn/ui):
- 按 02/07 章重构:页面域化拆分(无超 400 行文件)、PageContainer/ListQuery、
  反馈分级(成功静默/失败 toast/危险确认)、401 单飞刷新+队列重放
- 暗色模式(next-themes)+ 语义 Token(--primary 品牌色/success/warning/info)
- 部署向导(状态推导四步:环境→存储→Loki→采集,内嵌表单闭环)
- 日志查询页:LogQL 标签构建器/拖拽直方图/日志上下文/Live Tail/查询历史
- 按用户+标签策略的查询授权(服务端强制合并策略)

后端(Go+Gin+JSON DB):
- 简单用户管理(仅 admin,无 RBAC)+ TokenVersion 会话吊销 + 登录 IP 限流
- LDAP 接入:配置(AES 加密存储/hasPassword 脱敏)/测试连接/批量导入/登录
- 存储配置测试连接(SigV4 零依赖)+ 桶不存在自动创建
- Loki 三模式部署修复:SSH 密钥认证、3.x 配置模板、ruler 对象存储嵌套块、
  凭证解密、孤儿 deploying 状态恢复、Grafana 部署(可选默认关)+面板导入
- DaemonSet 采集纯 YAML(去 helm 依赖)+ DNS 自愈回退 ClusterIP + 集群名标签
- 日志查询代理:cluster-svc 经 kube-apiserver proxy/url 直连 + cursor 翻页
- 统一 log 命名空间;部署就绪探活;Grafana 访问地址自动记录

修复:run.sh 增量编译检测、Sanitized 脱敏补全、LokiDeployment Update 白名单、
健康检查 CreatedAt 零值等 10+ 存量 bug。

数据兼容:DB 沿用旧 lokideploy.json(新名优先);localStorage 一次性迁移;
HKDF 加密前缀保留(已加密凭证不受影响)。
 2026-10-24 13:20:12 +08:00