rlwj-lab/LokiStack
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
48 Commits 1 Branch 1 Tag
55d6a74eb37a5b5c91323f97a185bd00fdb87e0a
Commit Graph
25 Commits
Author SHA1 Message Date
opsx 55d6a74eb3 fix(collectors): 主机采集器从未真正运行过 —— systemd 用了 Promtail 3.x 已删除的参数 
=== 一、端到端验证发现的两个阻断性问题 ===
在 172.19.16.8 上真实部署（host-docker Loki + host-promtail）验证：

1) systemd unit 的 ExecStart 带 `-positions.enabled=true`
   Promtail 3.x 已删除该参数 → 启动即退出(status=2)，restart counter 一路涨到 65：
       flag provided but not defined: -positions.enabled
   也就是说：**主机模式的采集器此前从未真正跑起来过**。
   → 移除该参数（positions 由 YAML 配置，不需要这个 flag）。

2) 安装后不校验服务真实状态
   `systemctl restart` 对"启动即崩"的服务同样返回 0（只是排队拉起），
   平台据此把"崩溃重启中"报成 status=active / 采集器已部署，用户完全看不出问题。
   → 新增 waitServiceActive()：轮询 systemctl is-active 最多 20s，
     失败时返回错误并把 journalctl/日志尾部带回前端。

=== 二、验证结果（修复后）===
  Loki 主机模式：容器 lokistack-loki-2 Up，/ready=ready，labels 正常
  Promtail：active，监听 9080，ExecStart 已去掉非法参数
  系统日志：job=system 17,513 条/10min（/var/log/{messages,secure,cron,...}）
  应用日志：job=app 4,311 条/10min（/var/log/*.log）
  样本：pre-cex-ops-jenkins systemd[1]: Started promtail.service ...

=== 三、验证中另外发现、待修的两点（下一轮）===
- host 标签是字面量 "${HOSTNAME}"：Promtail 不做环境变量展开
  （需 -config.expand-env + systemd Environment，或生成配置时直接写真实主机名）
  → 21,825 条日志的 host 全是 ${HOSTNAME}，无法按主机过滤
- 系统日志时间戳解析失效：TencentOS 4 的 /var/log/messages 是 ISO8601
  （2026-07-17T15:38:24.923784+08:00），当前按传统 syslog（Oct 28 18:11:06）
  写的正则匹配不上 → timestamp 阶段不生效，用的是采集时间（回填历史会错）
  → 计划安装时探测首行格式，自动选择 ISO8601 / 传统 syslog 解析

镜像：lghost/lokistack:latest + v0.1 = sha256:6268d534b20a
 2026-10-28 18:11:41 +00:00
opsx bad2a1e624 fix(hosts,collectors,usage): 主机验证结果失真 + 主机模式系统日志解析 + metrics 单位 
=== 一、主机「测试连接」永远显示旧错误（真实 bug）===
HostService.Validate 的失败分支也写 status=active，且从不写 statusMessage：
    if info, err := client.GetHostInfo(ctx); err == nil { 更新 os/arch }
    else { s.Update(id, {status:"active"}) }   // ← 失败也标记成功
结果：连不上也显示正常，页面永远停在几分钟前的旧错误文案，
用户改了 IP 再点测试，还以为"改了还是不行"。

改为区分成功/失败并写清原因：
    成功 → status=active + os/arch + statusMessage="连接成功"
    失败 → status=error + statusMessage=FormatSSHError(err)

=== 二、回环地址在平台里必然连不上 ===
平台跑在容器/Pod 内，127.0.0.1 指向平台自身。
- 新建主机时拦截：hostIP 为 127.0.0.1/localhost/::1 直接报错并解释原因
- 前端表单同步校验 + 文案
- SSH 错误映射补充：连接被拒绝时提示可能是地址填了回环

=== 三、主机模式采集系统日志（两处会导致采集失败）===
1. pipeline 一律套 cri 阶段：cri 只认容器运行时格式，
   套在 /var/log/messages 这类 syslog 上会取不到时间戳、整行被丢。
   → appPipelineStages() 按路径判断：容器日志用 cri，普通文本日志只做限流。
2. promtailExternalLabels 写死 8 空格缩进：主机模板 external_labels 只有 4 空格，
   一旦给采集器配置了标签就生成非法 YAML，Promtail 装不上。
   → 增加 indent 参数，主机 6 空格 / DaemonSet 8 空格。
3. 新增 system 采集任务：
   /var/log/{messages,secure,cron,maillog,syslog,dmesg}
   正则解析 syslog 时间戳（Jan _2 15:04:05，Asia/Shanghai）+ 限流

测试：TestHostPromtailConfigValid / CRIPathKeepsCRIStage / PlainFileHasNoCRIStage
      TestPromtailManifestParses 全部通过

=== 四、资源用量 CPU 解析（nanocores）===
metrics-server 返回的 CPU 常是纳核（如 "194533645n"=194.5m）。
原解析只处理 "m"，导致 194 亿核、页面出现"CPU 已达 limit 的 4863341125%"。
→ parseQuantityMilli 支持 n/u/m/整核
实测：CPU 当前=178m，峰值=3300m，建议"峰值占 limit 82%，可考虑提前扩容"

=== 五、其他 ===
- 添加集群默认改用 Token 认证（最小权限、可随时吊销）
- RBAC 片段补 metrics.k8s.io（资源面板需要，独立 API 组常被漏授）
- 文案去掉 Grafana 需求描述（平台自身不部署 Grafana）

镜像：lghost/lokistack:latest + v0.1 = sha256:7bddd0f4d1f1
 2026-10-28 17:58:30 +00:00
opsx a32f93f533 feat(deployments,analysis): 保留弹框重设计 + 分析页命名空间筛选 + 过期 chunk 真正删除 
=== 一、保留策略弹框重设计（RetentionDialog）===
旧版问题：
1. 主输入是 YAML textarea，用户必须会写 `limits_config.retention_period: 30d`
2. 三个按钮：取消 / 仅保存 / 保存并应用 —— 「仅保存」只改部署记录不重载 Loki，
   今天已经造成一次真实故障：DB 记录 7 天、运行时 ConfigMap 是 24h，配置漂移
3. 「查看完整配置」是独立按钮 + 独立状态，多一次点击
4. 硬编码提示 `retention_delete_delay: 2h`，而实际已改成 10m，属于误导

新版：
- 主输入改为**保留天数数字框**（1–3650），YAML 由前端拼，用户不用写
- 快捷预设 1/7/14/30/90，实时显示「= 720 小时」
- >7 天给出存储成本提示
- 完整运行 config 改成 `<details>` 折叠，展开即自动加载（去掉独立按钮）
- **按钮只剩 2 个：取消 / 保存并应用**
- 删掉硬编码的 compactor 提示块

=== 二、日志分析页加命名空间筛选 ===
根因：analysis 页写死 namespace: ''，等价 `{namespace=~".+"}` —— 一次分析扫全集群
（实测约 370 GB/天），5 条 count_over_time 跑 30s 都出不来，页面永远转圈。

- 新增命名空间下拉（从 Loki label values 拉取，localStorage 记忆）
- 默认取业务命名空间 astralx（其次列表首个），不再默认全集群
- 「全部命名空间（较慢）」降级为显式选项
- 命名空间未就绪时先显示 loading，避免先发一次全集群查询
- 5 条查询改**分批（每批 2 条）**执行 + 429 自动重试一次

=== 三、后端并发/超时调整 ===
- 重查询并发上限 2 → 4，且拿不到令牌时**排队最多 10s**再拒绝
  （原来立即 429，导致分析页 5 条并发里有 3 条直接失败）
- maxLogQueryLimit 1000 → 5000，与前端下拉完全对齐（原来前端选 5000 会被静默截断）

=== 四、过期 chunk 真正删除（关键修复）===
实测发现：索引表已从 COS 删除，但 chunk 对象仍残留 21,354 个 / 24.8 GB，
最老的 45 小时前 —— 因为 Loki 默认 `retention_delete_delay` = **2h**，
标记后要等 2 小时才真正删 chunk。

- 配置显式设置 `compactor.retention_delete_delay: 10m`
- 已用 `loki -verify-config` 校验（config is valid）
- 删除前后对比：
    对象数 46,536 → 23,934；占用 53.61 GB → 27.25 GB
    超期对象 21,354 个 / 24.8 GB → **0 个**
    桶内最老对象 45.2h → 24.4h（= 保留期 1 天）
- deployment_config_test 同步调整：retention_delete_delay 从"禁止出现"移入"必须存在"

镜像：lghost/lokistack:latest + v0.1 = sha256:b4d98e016bca
 2026-10-28 17:05:57 +00:00
opsx 6364a70215 tune(logs): 每页条数默认 1000→200，上下文默认 5 条（依据实测数据） 
=== 一、每页条数：1000 太多，实测依据 ===
1. 每次查询响应体 671 B/条 → 1000 条 = **655 KB**
2. 前端结果表**没有虚拟滚动**（无 react-window / tanstack virtual），
   1000 行会全部渲染成 DOM 节点 → 滚动卡顿
3. 后端 maxLogQueryLimit 本来就是 1000，我上一版 UI 给了 2000/5000 选项
   是"假选项"（会被静默收敛成 1000），本次去掉
4. 密度参考：cex-ipublic-gateway 每天 3.28 亿条 ≈ **3800 条/秒**，
   1000 条只覆盖 0.26 秒 —— 靠翻页浏览无意义，应靠时间范围/LogQL 收窄

调整：默认 1000 → **200**（后端自身默认值，约 131KB）；选项 [100/200/500/1000]
提示文案改为"日志量大时先收窄时间范围或加过滤，比调大每页条数更有效"

=== 二、上下文档数：1 条不够，默认用 5 ===
实测一个 SpringBoot 异常被拆成 **4 条独立日志**：
  16:15:35.259 [reactor-http-epoll-3] ERROR ...AbstractErrorWebExceptionHandler
  org.springframework.web.reactive.resource.NoResourceFoundException: 404 NOT_FOUND
    Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
    *__checkpoint ⇢ HTTP HEAD "/" [ExceptionHandlingWebHandler]
→ 前后各 1 条（共 2 条）连一个完整异常都拼不出来
→ 前后各 5 条（共 10 条）能看到"异常 + 前后业务日志"，是排障的最小可用集
→ 完整 Java 堆栈（20+ 帧）需要 20-50 条

调整：默认 2 → **5**；选项增加 1 → [1/2/5/10/20/50]

镜像：lghost/lokistack:latest + v0.1 = sha256:2bcc86b8e30d
 2026-10-28 16:18:48 +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 9acc15f4d2 test(loki): 修正 delete_request_store 断言——两个测试互相矛盾导致 go test 必失败 
现象：`go test ./services/` 在 HEAD（3a8eb52）上稳定失败
  --- FAIL: TestGeneratedLokiConfigKeepsRequiredSettingsWithoutDefaults
      deployment_config_test.go:68: required setting "delete_request_store: s3" missing

根因不是代码 bug，而是**两个测试对同一件事的期望相反**：
  backend/services/deployment_config_test.go:66  断言  delete_request_store: s3
  backend/services/loki_object_store_test.go:44  断言  delete_request_store: filesystem
而 loki_config.go 对 s3/oss/minio/cos/obs 是**刻意**用 filesystem 的
（commit 9f7c522 引入，注释：「删除请求存本地盘，避免各云 S3 兼容实现差异
导致 compactor 启动失败」）。

即：代码是有意的，loki_object_store_test 也是对的，只有 deployment_config_test
是历史遗留的过时断言。本次把它改成 filesystem，并加注释说明为什么不能再改回 s3，
避免以后有人"顺手修回去"。

运行时行为完全没有变化（只改测试文件），但修复后 `go test ./...` 才能全绿，
否则每次发版预检都会被这个假失败挡住。

验证：go test ./... 全部通过（services/models/repositories/pkg 均 ok）。
 2026-10-28 15:00:30 +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 02d1bd87a7 fix(promtail): 修 Sprintf 缺参导致清单非法 + Ingress 模板固定命名空间 + 资源名去 opsxloki 
=== 一、致命 bug：Promtail 清单第 10 个 %s 缺参数（导致日志采集中断）===
go vet 报："format %s reads arg #10, but call has 9 args"。
模板里 DaemonSet 的 `namespace: %s`（第 9 个）和 `image: %s`（第 10 个）
是两个独立占位符，但 Sprintf 只传了 9 个参数，第 10 个变成 %!s(MISSING)，
整个多文档 YAML 解析失败：
  "解析 Kubernetes YAML: yaml: line 23: found character that cannot start any token"

而 installDaemonset 是「先删 daemonset/configmap/serviceaccount 再 apply」，
所以每次失败都会把上一份 Promtail 删掉却不重建 → 日志采集中断。

修复：
1) Sprintf 补上 DaemonSet 命名空间参数（第 9 位）
2) 新增 validateManifest()：在删旧资源之前先本地解析校验清单，
   校验不过直接中止、不碰任何现有资源 —— 让模板错误永远不会再打断采集
3) 新增回归测试 promtail_manifest_test.go：用平台同一套
   YAMLOrJSONDecoder 解析 3 种参数组合，断言各解析出 5 个对象且无 TAB

=== 二、快捷 LogQL：Ingress 访问日志不再跟随所选命名空间 ===
原实现：next = applyLabelFilter(next,'namespace', namespace.trim() || 'ingress-nginx')
→ 选了 monitor 就生成 {namespace="monitor"} |= "HTTP/"，查不到任何日志
  （ingress controller 的 Pod 只在 ingress-nginx 命名空间里）

修复：ingress 模板独立处理
  - 固定用 ingress controller 命名空间（ingress-nginx，缺失则回退 ingress）
  - 不叠加当前选中的 app / pod 过滤（那些属于业务服务）
  - 结果是 {namespace="ingress-nginx"} |= "HTTP/"

=== 三、K8s 资源名去掉 opsxloki ===
ClusterRole / ClusterRoleBinding：opsxloki-promtail → loki-promtail
- PromtailDaemonsetYAML 里 3 处 name 全部改名
- uninstallDaemonset 同步改名，并保留对旧名 opsxloki-promtail 的兼容清理，
  避免升级后留下孤儿 ClusterRole
- 集群侧已实测：新建 loki-promtail，旧的 opsxloki-promtail 已删除

保留的 opsxloki（有兼容性约束，改动会丢数据/掉登录）：
- Go module 导入路径 opsxloki/xxx（149 处，纯内部包名）
- 数据文件 opsxloki.json（改了读不到历史数据）
- 前端 localStorage key opsxloki.auth.* / opsxloki.theme.* 等（改了在线用户掉登录）
- Dockerfile 里的 opsxloki 系统用户/二进制名

镜像：lghost/lokistack:latest + v0.1 = sha256:4a5590580cbb
 2026-10-27 04:16:55 +00:00
opsx 41633f0b38 feat(collector): 采集命名空间多选 + app 标签来源可自定义 + app 白名单 
=== 一、采集命名空间改为多选（原来只有文本输入）===
- CollectorEditDialog 重写：勾选式多选面板，从
  GET /clusters/:id/namespaces 拉取真实命名空间列表
- "所有命名空间（全集群采集）"一键全选（targetNamespaces 置空即全集群）
- 支持搜索过滤命名空间；已选数量实时显示
- 保存时为空数组 → Promtail 不加 namespaces 白名单

=== 二、app 标签取值来源可配置 ===
新增 Collector.AppLabelSource：
  留空（默认）= app.kubernetes.io/name → app → controller 名(去hash) → pod 名 四级回退
  可填任意 Pod 标签，如 app.kubernetes.io/name / app / k8s.kuboard.cn/name
  也可直接写 __meta_kubernetes_pod_label_xxx
  → 作为最高优先级插到回退链最前，其余仍兜底

模板侧新增：
  sanitizePromLabel()      标签名 → Prometheus meta label（. / 等转 _）
  promtailAppSourceLabel() 解析用户配置
  promtailAppIncludeFilter() 生成白名单 keep 规则

=== 三、app 白名单（控制采集量）===
新增 Collector.AppInclude []string：
  填了之后生成
    - source_labels: [app]
      regex: ^(app1|app2)$
      action: keep
  只保留匹配的日志流 —— 这是收敛日志量最直接的手段

service.Update 同步支持 appLabelSource / appInclude（兼容 []string 与逗号分隔字符串）。

前端 CollectorEditDialog：
  采集命名空间 = 勾选多选 + 全选
  app 标签取值来源 = 输入框 + 5 个常用值 datalist 提示
  只采集这些 app = 逗号分隔输入

镜像：lghost/lokistack:latest + v0.1 = sha256:43369d06cb28
 2026-10-27 03:55:13 +00:00
opsx e006fc1a0e fix(promtail): app 标签通用回退 + 跳过僵尸 Pod + SecretKey 不下发 + 采集命名空间可选 
=== 一、astralx 只采集到 2 个 app（核心问题）===
实证：用户的 Deployment Pod 模板只有 k8s.kuboard.cn/name 标签，
     没有 app / app.kubernetes.io/name。原模板的 app 只从这两个标签取，
     所以 115 个服务的 app 全是空值，Loki 里 app 只剩零星 2 个。

修复：app 四级回退，全部基于 Kubernetes 原生元数据（跨集群通用）：
  1) app.kubernetes.io/name   标准约定
  2) app                      常见简写
  3) __tmp_controller_name    Pod owner(ReplicaSet) 去 hash → Deployment 名
                              （__meta_kubernetes_pod_controller_name 由
                                Promtail 直接从 K8s API 读取，任何集群都有，
                                不依赖 Kuboard/Rancher 等第三方工具注入的标签）
  4) pod name                 兜底，保证 app 永不为空

同时修复 PromtailHelmValues 模板同样的 app 逻辑，
并修正其 __meta_kubernetes__pod_name 双下划线笔误。

验证：astralx 的 app 值从 2 个 → 73 个。

=== 二、15 分钟 27 万条日志的真相 ===
排查结论：不是重复采集（positions 存 hostPath /run/promtail，Pod 重启不丢）。
真实原因：cex-openapi-gateway 残留 347 个 Evicted + 37 个 Error 的僵尸 Pod，
        只有 1 个 Running。这些 Pod 的日志文件仍在 /var/log/pods/ 下，
        Promtail 会把它们的历史异常堆栈（Reactor at reactor.core.publisher...）
        全量采集，造成 27 万条的假象并污染存储。

修复：relabel_configs 首条加 drop 规则：
  - source_labels: [__meta_kubernetes_pod_phase]
    regex: (Succeeded|Failed)
    action: drop
（两个模板都加）

=== 三、SecretKey 不再下发给前端 ===
安全要求：避免任何登录用户点「显示」按钮就能拿到对象存储 SK。
- StorageConfig.Sanitized(): secretKey 返回空串，仅保留 hasSecretKey 标记
  （accessKey 仍明文返回，便于管理员核对用的是哪个 AK）
- 测试连接：StorageTestRequest 新增 id 字段，secretKey 留空时后端用
  库里保存的凭据解密补齐（新建存储仍强制填写）
- 前端编辑时 SecretKey 一律留空 = 不修改，placeholder 显示
  「已保存 · 留空则不修改」，测试时带上 id

=== 四、采集器支持指定命名空间 ===
- Collector 新增 TargetNamespaces []string，对应 promtail 的
  kubernetes_sd_configs.namespaces.names（为空=全集群）
- PromtailDaemonsetYAML 新增 promtailNamespaceFilter 生成白名单
- service.Update 支持 targetNamespaces（兼容 []string 与逗号分隔字符串）
- 前端 CollectorEditDialog 增加「采集命名空间」输入（逗号分隔）

镜像：lghost/lokistack:latest + v0.1 = sha256:05b1505aedae
 2026-10-27 03:30:25 +00:00
opsx 188d9460fe fix(logs): 「所有人」策略组无法新建（被误判为已属于其他策略组） 
现象：userIds:[0] 新建策略组时报
  「用户 0 已属于此数据源的另一个策略组」HTTP 400

根因：validatePolicyGroup 的跨组冲突检查把 EveryoneUserID(0) 当真实用户，
     只要已有任何一个「所有人」策略组（如内置默认策略），
     再新建含 0 的组必然冲突。

修复：跨组冲突检查跳过 AnyoneUserID(0) —— 它是哨兵值不是真实用户，
     允许多个策略组同时包含「所有人」。

验证：
  POST /logs/policy-groups {userIds:[0]}  → 200，id=2 正常创建
  POST userIds:[0,2]（混选）               → 400「「所有人」不能与具体用户同时选择」
  GET  /logs/policy-groups                → 默认策略（所有人 · default 命名空间）

镜像：lghost/lokistack:latest + v0.1 = sha256:3222a8716fdd
 2026-10-27 03:02:50 +00: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
opsx 4dda6e5ba8 fix(logs): 快捷 LogQL null 崩溃 + app 标签错位 + 查询授权「所有人」与默认策略 
=== 一、快捷 LogQL 报 Cannot read properties of null (reading 'map') ===
根因：Loki 对无值的 label 返回 {"data":null}，Go nil slice 序列化成 JSON null，
     前端 setState(null) 后再 .map() / [...null] / .filter() 直接抛错。
     表现为「不稳定」——切到某个没有该 label 值的范围就崩。

修复（前后端双保险）：
  后端 LokiLabels / LokiLabelValues 归一化 nil → []string{}
    （LokiHistogram 原本就返回空切片，无需改）
  前端 6 处调用点加 Array.isArray 防御：
    QuickQueryTemplates ×3、QueryInput ×2、LokiLabelBrowser ×2

=== 二、选 astralx 只显示 2 个 app（不是权限问题）===
实测：
  astralx 117 个 Deployment / 497 个 Pod
  带 app 标签的 Pod 只有 2 个（cex-promotion-web / cex-web-h5）
  其余 115 个 Deployment 的 Pod 模板没打 app，Kuboard 打的是 k8s.kuboard.cn/name
  Loki 里 service_name / container 各有 79 个值（Promtail 从容器名生成）

修复：QuickQueryTemplates 的「app」候选改为三级回退 app → service_name → container，
     并用 appLabel 状态记住实际生效的标签名，pod 收窄与 generate() 都用它，
     保证生成的 LogQL selector 真能查到数据。

=== 三、查询授权：支持「所有人」+ 内置默认策略 ===
1. 后端 policyGroupAccess：userIds 里的 0 作为哨兵值表示「所有人」(anyone / *)，
   匹配任意用户（原来只能逐个指定用户 ID）
2. 种子 seedDefaultPolicy()：首次启动且尚无任何策略组时，创建
   「默认策略（所有人 · default 命名空间）」（labels: namespace=default，userIds: [0]）。
   管理员可在「查询授权」里把命名空间改成实际业务命名空间（如 astralx），
   对该组所有用户立即生效。
3. 前端 PolicyGroupsPage：新增「所有人（anyone）」一键按钮（与具体用户互斥），
   列表与编辑区显示「所有人」，校验文案同步更新。

验证：
  GET /logs/label/nonexistent_xyz/values            → {"data":[]}
  GET /logs/label/service_name/values?query={namespace="astralx"} → 79 个
  GET /logs/policy-groups → 1 条：默认策略（所有人 · default 命名空间）所有人

镜像：lghost/lokistack:latest + v0.1 = sha256:88a4ba626f62
 2026-10-27 01:19:06 +00:00
opsx 46e73d3d17 fix(loki): COS 存储全链路修复 —— Secret 生成/env 注入/凭据解密/endpoint 规范化 
API 端到端跑通中暴露 4 个串联问题（腾讯云 COS + K8s 场景）：

1. loki_manifest.go: switch 缺少 cos / obs
   → 不生成 loki-storage-credentials Secret、不注入 LOKI_STORAGE_* 环境变量、
     也不给 Loki 加 -config.expand-env=true
   → 配置里 ${LOKI_STORAGE_ACCESS_KEY} 无法展开 → AK 为空
   → COS 返回 403 InvalidAccessKeyId（ruler 每分钟报错）
   修复：case 补上 cos / obs

2. loki_manifest.go: 生成 Secret 时用了 ENC: 密文原始值
   → Secret data 里是 ENC:xxx 而非真实 AK/SK
   修复：crypto.DecryptField 解密后再 base64

3. loki_config.go: host-docker 模式同样把密文写进配置
   修复：解密后返回

4. loki_config.go: cos/oss/obs 的 endpoint 未剥离桶名前缀
   → 用户填虚拟主机式 endpoint（mybucket-1250000000.cos.<region>...）时，
     Loki 的 S3 客户端又拼一次 bucketnames，变成 <bucket>.<bucket>.cos...
   → TLS 证书校验失败（x509: certificate is valid for ... not <bucket>.<bucket>.cos...）
   修复：新增 stripBucketPrefix，s3/cos/oss/obs/minio 分支统一剥离桶名前缀

验证（log namespace，API 端到端）：
  - Loki statefulset 1/1 Running，ruler 无 InvalidAccessKeyId/x509
  - 写入 + 查询日志成功（持久化到 COS）
  - Promtail DaemonSet 12/12 全节点就绪
  - collector status=active

运维侧附加动作（非代码，见部署文档）：
  - 存储配置改用有效 AK/SK + 区域端点 cos.ap-hongkong.myqcloud.com
  - 平台 ServiceAccount log:lokistack 绑定 cluster-admin
    （否则无法创建 Promtail 所需的 ClusterRole/ClusterRoleBinding）
 2026-10-26 19:32:38 +00:00
opsx 004375e0ce fix(ns): 命名空间固定 log —— 平台/Loki 实例/Promtail 全部收敛到 log 
按需求：所有 lokistack 相关资源（管理平台副本、Loki 实例、Promtail 采集器）
固定使用 log 命名空间，不提供覆盖开关。

改动：
1. 后端 services/deployment.go Create()：k8s-yaml 模式下 namespace 为空时
   兜底为 "log"，前端漏传也不会跑偏。
2. 前端 DeploymentCard.tsx：命名空间展示 fallback 'loki' → 'log'
3. 前端 DeploymentFormDialog.tsx：输入框 placeholder 'loki' → 'log'
   （form-schema.ts 的 DEFAULT_VALUES.namespace 原本已是 'log'）

未动：
  kubernetes/install.sh 的 NS="log" 早就是固定值
  collector_deployer.go 已自动跟随 loki.Namespace（collector.Namespace 为空时）

资源名不冲突：
  平台        lokistack / lokistack-data / lokistack-secrets / lokistack-nodeport
  Loki 实例    loki / loki-config / loki-data / loki-headless / loki-storage-credentials
  Promtail    promtail-* (DaemonSet)

镜像：lghost/lokistack:latest + v0.1 = sha256:9d15b7ffbb3d
 2026-10-26 18:55:06 +00:00
opsx cfe1ccd154 fix(storage): 按 endpoint 形态解析响应 + 凭据解密返回 + 无建桶权限友好提示 
【真实根因】COS 桶明明存在却报"桶不存在/创建失败"

用户配置：endpoint=loki-log-1394668510.cos.ap-hongkong.myqcloud.com（虚拟主机式，已含桶名）
旧代码：始终 GET / 并按 ListBuckets 的 <Buckets><Bucket><Name> 解析。
但在虚拟主机式 endpoint 下，GET / 返回的是 ListObjects（<ListBucketResult>）——
桶内对象列表，不是桶列表。解析必然找不到桶名 → 误判"桶不存在"
→ 触发建桶 PUT → 用户的 AK 无 cos:PutBucket 权限 → 403
→ 最终报"创建后校验失败"。

【实测确认（用该 AK 直连 COS）】
  GET / (vhost)         → 200  <ListBucketResult>         桶存在，能列对象
  GET / (区域端点)       → 200  <ListAllMyBucketsResult>   AK 有 cos:GetService
  HEAD /                → 403  AK 无 cos:HeadBucket
  PUT /  (CreateBucket) → 403  AK 无 cos:PutBucket
即 QcloudCOSDataFullControl = 数据面全控（读写/列桶），不含管控面（建桶/HeadBucket）。

【修复】
1. 探测统一用 GET /，再按 endpoint 形态解释响应：
   - 虚拟主机式 → 按 ListObjects（<ListBucketResult>）判断，200 即桶存在
   - 区域端点   → 按 ListBuckets（<Buckets><Bucket><Name>）匹配桶名
   桶存在就直接返回"桶已存在"，不再走建桶流程。
2. 建桶二次校验同样改用 GET /（不再用 HEAD，避免 HeadBucket 403 误判）。
3. 建桶返回 403 时给出明确友好提示：
   "当前 Access Key 无建桶权限。腾讯云 QcloudCOSDataFullControl 只授予数据读写/列出，
    不含 CreateBucket。请到 COS 控制台手动创建桶，或在 CAM 追加 cos:PutBucket"
4. models/storage.go Sanitized() 用 crypto.DecryptField 解密后再返回 AK/SK
   （原来直接返回 ENC:xxx 密文，前端编辑框显示密文）。
5. 前端访问地址输入框补充说明：推荐填区域端点（不带桶名）。

镜像：lghost/lokistack:latest + v0.1 = sha256:350478003870
 2026-10-26 18:38:00 +00:00
opsx ff69ea2ce8 fix(storage): 凭证明文返回便于编辑测试 + 建桶后二次校验防"假成功" 
问题（log.astx.club/storage）：
  1. 编辑存储时 Access Key / Secret Key 都是空的，点「测试连接」提示
     请先填写 Bucket 与 Access Key / Secret Key，无法测试也无法保存；
  2. 提示"桶不存在,已自动创建"但疑似没有真正创建；
  3. 测试失败提示用 toast 弹到右下角，不在弹框内。

修复：
  1. models/storage.go Sanitized() 返回 accessKey / secretKey 明文
     （内网运维工具，管理员需要在编辑弹框里看到并测试连接；脱敏会导致
      编辑时字段为空、校验失败）
  2. 前端 StorageConfig 类型补 accessKey / secretKey 字段；
     编辑弹框打开时回填这两个字段（原来只有 secretKey 且强制置空）；
     Secret Key 标签去掉「留空保持不变」
  3. services/storage_check.go 建桶后二次 ListBuckets 校验：
     不同对象存储 CreateBucket 语义不同（腾讯云 COS 要求桶名放 Host、
     路径为 /），直接 PUT /<bucket> 可能返回 200 但未真正创建。
     现在创建后重新列举桶，找不到就报"创建后校验失败"并提示检查
     Endpoint / Region / 桶名（COS 需带 APPID）
  4. 前端「请先填写 Bucket 与 Access Key / Secret Key」改为在弹框内
     testResult 区域显示（原来 toast 弹右下角）

镜像：lghost/lokistack:latest + v0.1 = sha256:6b6cc9769e79
 2026-10-26 18:30:47 +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
Logan.LiandClaude 327e282356 refactor: 前后端目录结构模块化 + v2 优化移植与缺陷修复 
前端:
- src/srv/api → src/api，按域分文件夹(auth/cluster/host/storage/deployment/collector)
- 新增 http.ts 引擎(http.get/post/put/delete)，域模块改用语义化调用
- index.html 增加 favicon(匹配应用 logo 的 emerald + Activity 脉冲)

后端分层增强(保留包名):
- 新增 repository/：从 models 拆出 JsonDB 持久化层(InitDB/GetDB/Shutdown/RequestSave)
- 新增 dto/：从 controllers 抽出各域请求契约(带 binding 校验)
- 新增 pkg/crypto、pkg/jwt：从 utils 拆出安全原语(外部 jwt 别名 jwtv5 避免冲突)
- models 只留领域实体 + sanitizer；utils 只留 gin/应用相关(response/errors)

v2 优化移植与缺陷修复:
- 移植密钥分离/SSH TOFU/并发写安全/Loki 生产级配置/Docker 加固
- 修复 deployment.go 并发丢更新、Helm values 重复键、EncryptField 哨兵、loki-gateway 端点等审计缺陷
- 实现真正的优雅关停(main.go http.Server + signal + repository.Shutdown)
- 修复登录契约:后端返回 accessToken，前端 auth.ts/Login.tsx 对齐
- 补 crypto/jwt/repository 单元测试(含并发写回归)

验证: go build/vet/test 全绿；npm run build 通过；登录→鉴权→优雅关停冒烟通过

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-06-30 10:46:26 +08:00
Logan.LiandClaude 673b2c60c8 feat: 新增「部署客户端」日志采集器模块 
三种采集器（host-promtail / k8s-daemonset / k8s-fluentbit-sidecar），每种关联已部署 Loki：
- host-promtail：SSH 安装 Promtail（复用 deployBinary）
- k8s-daemonset：helm 安装 Promtail DaemonSet（复用 deployHelm）
- k8s-fluentbit-sidecar：kubectl patch 注入 Fluent Bit sidecar

含 Collector 数据模型、三个部署器、配置模板、CRUD API、前端页面。
附带 UI 优化：ErrorBoundary、部署卡片浏览器访问按钮、菜单名称调整。

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-06-29 19:26:41 +08:00
Logan.LiandClaude 2a93de600d feat: LokiDeploy 初始提交 - 轻量级 K8s Loki 部署平台 
Go(Gin) + React(Vite + shadcn/ui + Tailwind) 前后端分离，全中文 UI

- 集群管理：Kubeconfig / Token 双接入，kubectl + helm 部署
- 主机管理：SSH 密钥 / 密码双认证，CPU/内存/磁盘使用率监控，SSH 错误中文友好提示
- 存储配置、部署管理、系统设置
- Docker 镜像内置 kubectl + helm，开箱即用
- run.sh 一键启停（start/stop/restart/status）

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-06-29 17:03:57 +08:00