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
1 parent f6af12a731
commit b49677f6a6
@@ -24,6 +24,10 @@ spec:
      labels:
        app: lokistack
    spec:
+      # 优雅停机：平台收到 SIGTERM 后要先停 HTTP、等告警引擎结束、
+      # 再把 JSON DB 完整落盘。给 30s 窗口，避免 kubelet 直接 SIGKILL
+      # 导致数据文件被截断（JSON 全量写盘，写一半就丢全库）。
+      terminationGracePeriodSeconds: 30
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
@@ -74,20 +78,28 @@ spec:
              port: http
            initialDelaySeconds: 5
            periodSeconds: 10
+            timeoutSeconds: 5
+            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /api/v1/health
              port: http
+            # DB 全量落盘（尤其审计表变大后）可能占用几秒，
+            # liveness 必须留足窗口，否则写盘中被 kubelet 杀掉 = 数据损坏
            initialDelaySeconds: 30
            periodSeconds: 20
+            timeoutSeconds: 10
            failureThreshold: 5
+          # 资源配置依据（实测）：平台要扛 JSON DB 全量读写、
+          # 每分钟一轮告警评估、以及批量发布时的并发 API。
+          # 原先 1C/1Gi 在批量操作时会顶到 OOM（Loki 侧就因此被 OOMKilled 过）。
          resources:
            requests:
-              cpu: 200m
-              memory: 256Mi
+              cpu: 500m
+              memory: 512Mi
            limits:
-              cpu: "1"
-              memory: 1Gi
+              cpu: "4"
+              memory: 4Gi
      volumes:
        - name: data
          persistentVolumeClaim:
@@ -0,0 +1,76 @@
+# lokistack 平台：中断预算 + 备份定时任务
+#
+# 为什么单副本还要 PDB：
+#   PDB minAvailable: 0 不保护"不中断"，它的作用是让**节点排空（drain）**时
+#   集群知道"这个工作负载可以被驱逐，但请一次性驱逐完，别卡住维护流程"，
+#   并让 `kubectl drain` 正确等待 Pod 重建。没有 PDB 时 drain 会直接删 Pod，
+#   配合 Recreate 策略可能出现"旧 Pod 已删、新 Pod 还没起"的空窗无人知晓。
+#
+# ⚠️ 不要改成 minAvailable: 1 —— replicas 恒为 1，那会让 drain 永远失败。
+apiVersion: policy/v1
+kind: PodDisruptionBudget
+metadata:
+  name: lokistack
+  namespace: log
+spec:
+  minAvailable: 0
+  selector:
+    matchLabels:
+      app: lokistack
+---
+# 每日自动备份（导出 tar.gz 到 PVC 的 backups/ 目录，保留最近 7 份）。
+#
+# 为什么要 CronJob 而不是靠平台自己：
+#   平台进程挂了就没人备份，备份必须由 K8s 托管、独立于应用生命周期。
+# 备份内容：DB + kubeconfigs/ + known_hosts/，不含明文密钥。
+# 恢复：kubectl -n log exec deploy/lokistack -- /app/lokistack restore <文件>
+#       或页面「系统 → 备份与恢复」上传。
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: lokistack-backup
+  namespace: log
+spec:
+  schedule: "30 3 * * *"          # 每天 03:30
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 3
+  jobTemplate:
+    spec:
+      backoffLimit: 2
+      template:
+        spec:
+          restartPolicy: OnFailure
+          securityContext:
+            runAsUser: 1000
+            runAsGroup: 1000
+            fsGroup: 1000
+          containers:
+            - name: backup
+              image: lghost/lokistack:latest
+              imagePullPolicy: Always
+              command: ["/bin/sh", "-c"]
+              args:
+                - |
+                  set -e
+                  mkdir -p /app/data/backups
+                  TS=$(date +%Y%m%d-%H%M%S)
+                  OUT=/app/data/backups/lokistack-$TS.tar.gz
+                  # 用平台自带命令导出（保证 manifest / 密钥指纹口径一致）
+                  /app/lokistack backup --output "$OUT" || {
+                    echo "备份失败"; exit 1;
+                  }
+                  echo "已生成 $OUT ($(du -h "$OUT" | cut -f1))"
+                  # 只保留最近 7 份
+                  ls -1t /app/data/backups/lokistack-*.tar.gz 2>/dev/null | tail -n +8 | xargs -r rm -f
+                  ls -1t /app/data/backups/lokistack-*.tar.gz | head -3
+              volumeMounts:
+                - name: data
+                  mountPath: /app/data
+              resources:
+                requests: {cpu: 50m, memory: 64Mi}
+                limits: {cpu: 500m, memory: 512Mi}
+          volumes:
+            - name: data
+              persistentVolumeClaim:
+                claimName: lokistack-data
@@ -12,4 +12,6 @@ spec:
    - ReadWriteOnce
  resources:
    requests:
+      # 30Gi：按长期增长预留（审计 90 天 + 部署日志 + 未来可能落更多本地缓存）。
+      # 云盘单价低，宁可留余量也不要日后被迫做在线扩容。
      storage: 30Gi