LokiStack

116 Commits 1 Branch 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
opsx	fdd705c4b4	build(release): release.sh 加独占构建锁 + push 重试，杜绝 latest 被并发覆盖 CI / Frontend (lint + build + test) (push) Canceled after 0s Details CI / Backend (go vet + test) (push) Canceled after 0s Details === 问题 === 本项目所有清单都指向 `latest`（k8s deployment / docker-compose / prod compose），两个构建并发时谁后完成谁生效，另一个的推送等于白做。本次实际踩到：一次被中断的构建后来完成，把 latest 推回了旧镜像 64fb231，而当前正确版本是 a16978d2；若此时 Pod 重启就会跑回旧代码，表现是"改了但没生效"，从页面完全看不出来。 === 修复 1：flock 独占锁 === LOCK_FILE=${RELEASE_LOCK_FILE:-/var/lock/lokistack-release.lock} exec 9>"$LOCK_FILE"; flock -n 9 \|\| { 中文提示 + exit 1 } - 锁跟随文件描述符，进程退出（含 Ctrl-C / set -e 中断）自动释放，不需要手工清理僵尸锁文件 - 失败提示给出：锁路径、查看占用命令（fuser/lsof）、以及"无需手工删锁"的说明 - 支持 RELEASE_LOCK_FILE 换锁路径（多仓库并行发布时用） - 新增 --dry-run：只做前置检查（docker 是否可用、锁能否获取），不构建不推送，用于验证脚本本身和排查"为什么发布失败" === 修复 2：push 重试 === Docker Hub 偶发 502，实测导致过"v0.1 推成功、latest 失败 → latest 指旧镜像"。新增 push_with_retry()：每个 tag 最多 3 次，间隔 10 秒，全失败才 exit 1。三个 tag（latest / v0.1 / 不可变 tag）都走它。 === 实测 === 测试1 无人占用 : 🔒 获取锁成功，退出码 0 测试2 另一进程持有锁 : ❌ 明确拒绝并给出排查命令，退出码 1 测试3 占用进程退出后 : ✅ 自动恢复可用，退出码 0 bash -n 语法检查通过	2026-10-30 17:48:20 +00:00
opsx	8bea331183	chore(release): 发布脚本对齐"统一使用 latest"策略清单本来就用 latest（deployment.yaml / docker-compose.yml / prod.yml 的 ${IMAGE_TAG:-latest}），但上一版 release.sh 会把 deployment.yaml 改成不可变 tag 并把 pullPolicy 改成 IfNotPresent —— 与"统一用 latest"相反，而且改完不提交的话下次 apply 又会退回最新 tag，容易造成实际版本与预期不符。改为： 1) 一次构建打三个 tag：latest / v0.1 / <版本>-<日期>-<commit>，同时推送 2) 推送后校验三个远端 digest 一致，不一致直接退出（并发构建覆盖 latest 的经典事故，先拦住别部署） 3) 部署走 kubectl apply + rollout restart（image=latest + Always 强制重拉） 4) 部署完再核对 Pod digest 与远端 latest，不一致立即提示 5) 不再默认改清单；需要"固定版本部署"时显式 `--pin` 6) 回滚方式写清楚：把旧的不可变 tag 重新打成 latest 推上去同时把集群里被我为了避开 tag 竞争临时改成 v11-1028-2252 的 Deployment 恢复成 latest + Always（已验证 Pod / Hub latest / Hub v0.1 三者 digest 一致 = 187062644c0f）。	2026-10-28 23:02:41 +00:00
opsx	b49677f6a6	feat: 运维标杆化打磨 P0/P1/P2 —— 审计日志、真实指标、备份恢复、菜单收敛审计发现 5 处硬伤（/metrics 空壳、零备份、prod 双副本数据分裂、零审计、资源偏紧），本轮全部落地。 === P0-1 真实 /metrics（原来是空壳）=== 原实现只返回一行注释 `# LokiStack Metrics`，注释却写着"可被 Prometheus 抓取"，平台挂了/DB 写不进去/告警引擎卡死都只能靠用户反馈。现接入 prometheus/client_golang，四层指标： HTTP : lokistack_http_requests_total / _duration_seconds / _in_flight_requests 存储 : lokistack_db_size_bytes / _db_save_duration_seconds / _db_save_total / _db_records 业务 : lokistack_deployments{status,mode} / lokistack_collectors{status,type,run_mode} 后台任务: lokistack_alert_evaluations_total / _duration_seconds / lokistack_loki_queries_total + go_* / process_（GoCollector、ProcessCollector）关键点：path 标签用 c.FullPath() 路由模板，不用原始 URL —— 否则 117 个 Deployment 会把 Prometheus 基数炸掉。指标定义下沉 pkg/metrics 叶子包，避开 services ↔ repository 循环依赖。 === P0-2 备份与恢复（原来 0 处代码）=== 平台全部状态在 /app/data/opsxloki.json（51KB）+ kubeconfigs/ + known_hosts/， DB 丢了 = 失去"这些资源是谁建的"的映射，从此无法管理/卸载/升级在跑的 Loki。 CLI : lokistack backup --output <path> / restore <pkg> / self-check / version API : GET /system/backup（下载）/ POST /system/restore（校验暂存）/ POST /system/restore/apply（确认应用）/ GET /system/backups K8s : kubernetes/pdb-backup.yaml —— 每日 03:30 CronJob，保留最近 7 份安全设计： - manifest.json 记录 ENCRYPTION_KEY 的 sha256 前 16 位指纹，用于恢复时校验"这把钥匙能不能解开这份备份"，不泄露密钥本身 - 恢复分两步（校验暂存 → 确认应用），应用前自动把当前 DB 备份为 opsxloki.json.before-restore.<时间戳> - 包内不含明文密钥（kubeconfig 本就是加密态） === P0-3 prod compose 双副本 → 单副本 === lokistack-1 / lokistack-2 各挂独立数据卷 + nginx 轮询 = 数据分裂：页面刷新两次可能看到不同结果，写操作只落一个副本。不是高可用。已改单实例（nginx 仅做反代），文件顶部与 nginx.conf 都写明原因。 === P0-4 操作审计日志（借鉴 /usr/local/src/aiops 的字段口径）=== aiops 是每个 controller 各写 recordXxxAudit()；本平台有 60+ 写接口，逐个埋点必然漏，漏掉的那个恰好最危险（删集群、改存储凭证）。改为 gin 中间件统一记录* + handler 通过 SetAudit 补充业务语义： models/audit.go : 字段对齐 aiops，另加 Method/Path/Before/After services/audit.go : 写入 + 90 天/2 万条自动裁剪 + 脱敏 + diff 生成 middleware/audit.go : 自动识别 module/action/resource，跳过只读接口 controllers/audit.go: 列表/详情/统计（仅 admin）敏感字段（password/secretKey/privateKey/token）写入前统一替换为 ***。 === P1 稳定性 === - 平台资源 1C/1Gi → 4C/4Gi 限（500m/512Mi 请求）：JSON DB 全量读写 + 每分钟告警评估 + 批量发布并发，1Gi 会 OOM - terminationGracePeriodSeconds: 30 —— 收到 SIGTERM 要等 DB 完整落盘，否则 kubelet SIGKILL 会把 JSON 写一半（全库丢失） - liveness timeoutSeconds 10s（默认 1s 写盘时会被误杀） - PDB minAvailable: 0 —— 让 kubectl drain 正确等待重建，不卡维护 - DB schemaVersion + migrateSchema() 版本递进迁移（原先加字段全靠零值兜底） - scripts/release.sh —— 不可变 tag <版本>-<日期>-<commit> + IfNotPresent，根治 latest 并发构建互相覆盖导致的静默回滚（本项目已实际踩过） - PVC 保持 30Gi（按长期增长预留，云盘单价低，不做在线扩容） === P2 易用性 === - 一键自检 GET /system/self-check + 仪表盘自检卡：真实探活 Loki /ready、集群凭据解密、磁盘空间、主机状态、近 24h 失败操作 - 审计日志页 /audit：统计卡 + 用户名/模块/结果筛选 + 变更前后 diff 弹窗 - 菜单收敛 13 → 7（页内 tab 切换，URL 全部不变）：资源接入 = 集群 + 主机 + 存储日志服务 = Loki 实例 + 采集器日志 = 查询 + 分析系统管理 = 用户 + 审计 + 设置新增 GroupTabs 组件 + meta.group/groupKey，侧栏按分组去重并正确高亮测试：go vet 通过、go test 全绿、tsc 通过	2026-10-28 21:27:01 +00:00

Author

SHA1

Message

Date

opsx

fdd705c4b4

build(release): release.sh 加独占构建锁 + push 重试，杜绝 latest 被并发覆盖

CI / Frontend (lint + build + test) (push) Canceled after 0s

Details

CI / Backend (go vet + test) (push) Canceled after 0s

Details

=== 问题 ===
本项目所有清单都指向 `latest`（k8s deployment / docker-compose / prod compose），
两个构建并发时**谁后完成谁生效**，另一个的推送等于白做。
本次实际踩到：一次被中断的构建后来完成，把 latest 推回了旧镜像 64fb231，
而当前正确版本是 a16978d2；若此时 Pod 重启就会跑回旧代码，
表现是"改了但没生效"，从页面完全看不出来。

=== 修复 1：flock 独占锁 ===
  LOCK_FILE=${RELEASE_LOCK_FILE:-/var/lock/lokistack-release.lock}
  exec 9>"$LOCK_FILE"; flock -n 9 || { 中文提示 + exit 1 }
- 锁跟随文件描述符，进程退出（含 Ctrl-C / set -e 中断）自动释放，
  不需要手工清理僵尸锁文件
- 失败提示给出：锁路径、查看占用命令（fuser/lsof）、以及"无需手工删锁"的说明
- 支持 RELEASE_LOCK_FILE 换锁路径（多仓库并行发布时用）
- 新增 --dry-run：只做前置检查（docker 是否可用、锁能否获取），不构建不推送，
  用于验证脚本本身和排查"为什么发布失败"

=== 修复 2：push 重试 ===
Docker Hub 偶发 502，实测导致过"v0.1 推成功、latest 失败 → latest 指旧镜像"。
新增 push_with_retry()：每个 tag 最多 3 次，间隔 10 秒，全失败才 exit 1。
三个 tag（latest / v0.1 / 不可变 tag）都走它。

=== 实测 ===
  测试1 无人占用        : 🔒 获取锁成功，退出码 0
  测试2 另一进程持有锁   : ❌ 明确拒绝并给出排查命令，退出码 1
  测试3 占用进程退出后   : ✅ 自动恢复可用，退出码 0
  bash -n 语法检查通过

2026-10-30 17:48:20 +00:00

opsx

8bea331183

chore(release): 发布脚本对齐"统一使用 latest"策略

清单本来就用 latest（deployment.yaml / docker-compose.yml / prod.yml 的
${IMAGE_TAG:-latest}），但上一版 release.sh 会把 deployment.yaml 改成
不可变 tag 并把 pullPolicy 改成 IfNotPresent —— 与"统一用 latest"相反，
而且改完不提交的话下次 apply 又会退回最新 tag，容易造成实际版本与预期不符。

改为：
  1) 一次构建打三个 tag：latest / v0.1 / <版本>-<日期>-<commit>，同时推送
  2) 推送后**校验三个远端 digest 一致**，不一致直接退出（并发构建覆盖
     latest 的经典事故，先拦住别部署）
  3) 部署走 kubectl apply + rollout restart（image=latest + Always 强制重拉）
  4) 部署完再核对 Pod digest 与远端 latest，不一致立即提示
  5) 不再默认改清单；需要"固定版本部署"时显式 `--pin`
  6) 回滚方式写清楚：把旧的不可变 tag 重新打成 latest 推上去

同时把集群里被我为了避开 tag 竞争临时改成 v11-1028-2252 的 Deployment
恢复成 latest + Always（已验证 Pod / Hub latest / Hub v0.1 三者 digest 一致
= 187062644c0f）。

2026-10-28 23:02:41 +00:00

opsx

b49677f6a6

feat: 运维标杆化打磨 P0/P1/P2 —— 审计日志、真实指标、备份恢复、菜单收敛

审计发现 5 处硬伤（/metrics 空壳、零备份、prod 双副本数据分裂、零审计、资源偏紧），
本轮全部落地。

=== P0-1 真实 /metrics（原来是空壳）===
原实现只返回一行注释 `# LokiStack Metrics`，注释却写着"可被 Prometheus 抓取"，
平台挂了/DB 写不进去/告警引擎卡死都只能靠用户反馈。
现接入 prometheus/client_golang，四层指标：
  HTTP    : lokistack_http_requests_total / _duration_seconds / _in_flight_requests
  存储    : lokistack_db_size_bytes / _db_save_duration_seconds / _db_save_total / _db_records
  业务    : lokistack_deployments{status,mode} / lokistack_collectors{status,type,run_mode}
  后台任务: lokistack_alert_evaluations_total / _duration_seconds / lokistack_loki_queries_total
  + go_* / process_*（GoCollector、ProcessCollector）

关键点：path 标签用 c.FullPath() 路由模板，不用原始 URL —— 否则 117 个 Deployment
会把 Prometheus 基数炸掉。指标定义下沉 pkg/metrics 叶子包，避开
services ↔ repository 循环依赖。

=== P0-2 备份与恢复（原来 0 处代码）===
平台全部状态在 /app/data/opsxloki.json（51KB）+ kubeconfigs/ + known_hosts/，
DB 丢了 = 失去"这些资源是谁建的"的映射，从此无法管理/卸载/升级在跑的 Loki。

  CLI : lokistack backup --output <path> / restore <pkg> / self-check / version
  API : GET /system/backup（下载）/ POST /system/restore（校验暂存）/
        POST /system/restore/apply（确认应用）/ GET /system/backups
  K8s : kubernetes/pdb-backup.yaml —— 每日 03:30 CronJob，保留最近 7 份

安全设计：
  - manifest.json 记录 ENCRYPTION_KEY 的 sha256 前 16 位**指纹**，用于恢复时
    校验"这把钥匙能不能解开这份备份"，不泄露密钥本身
  - 恢复分两步（校验暂存 → 确认应用），应用前自动把当前 DB 备份为
    opsxloki.json.before-restore.<时间戳>
  - 包内不含明文密钥（kubeconfig 本就是加密态）

=== P0-3 prod compose 双副本 → 单副本 ===
lokistack-1 / lokistack-2 各挂独立数据卷 + nginx 轮询 = 数据分裂：
页面刷新两次可能看到不同结果，写操作只落一个副本。不是高可用。
已改单实例（nginx 仅做反代），文件顶部与 nginx.conf 都写明原因。

=== P0-4 操作审计日志（借鉴 /usr/local/src/aiops 的字段口径）===
aiops 是每个 controller 各写 recordXxxAudit()；本平台有 60+ 写接口，
逐个埋点必然漏，漏掉的那个恰好最危险（删集群、改存储凭证）。
改为 **gin 中间件统一记录** + handler 通过 SetAudit 补充业务语义：
  models/audit.go     : 字段对齐 aiops，另加 Method/Path/Before/After
  services/audit.go   : 写入 + 90 天/2 万条自动裁剪 + 脱敏 + diff 生成
  middleware/audit.go : 自动识别 module/action/resource，跳过只读接口
  controllers/audit.go: 列表/详情/统计（仅 admin）
敏感字段（password/secretKey/privateKey/token）写入前统一替换为 ***。

=== P1 稳定性 ===
- 平台资源 1C/1Gi → 4C/4Gi 限（500m/512Mi 请求）：JSON DB 全量读写 +
  每分钟告警评估 + 批量发布并发，1Gi 会 OOM
- terminationGracePeriodSeconds: 30 —— 收到 SIGTERM 要等 DB 完整落盘，
  否则 kubelet SIGKILL 会把 JSON 写一半（全库丢失）
- liveness timeoutSeconds 10s（默认 1s 写盘时会被误杀）
- PDB minAvailable: 0 —— 让 kubectl drain 正确等待重建，不卡维护
- DB schemaVersion + migrateSchema() 版本递进迁移（原先加字段全靠零值兜底）
- scripts/release.sh —— 不可变 tag <版本>-<日期>-<commit> + IfNotPresent，
  根治 latest 并发构建互相覆盖导致的静默回滚（本项目已实际踩过）
- PVC 保持 30Gi（按长期增长预留，云盘单价低，不做在线扩容）

=== P2 易用性 ===
- 一键自检 GET /system/self-check + 仪表盘自检卡：真实探活 Loki /ready、
  集群凭据解密、磁盘空间、主机状态、近 24h 失败操作
- 审计日志页 /audit：统计卡 + 用户名/模块/结果筛选 + 变更前后 diff 弹窗
- 菜单收敛 13 → 7（页内 tab 切换，URL 全部不变）：
    资源接入 = 集群 + 主机 + 存储
    日志服务 = Loki 实例 + 采集器
    日志     = 查询 + 分析
    系统管理 = 用户 + 审计 + 设置
  新增 GroupTabs 组件 + meta.group/groupKey，侧栏按分组去重并正确高亮

测试：go vet 通过、go test 全绿、tsc 通过

2026-10-28 21:27:01 +00:00