rlwj-lab/LokiStack
1
0 Fork 0
Code Issues Pull Requests Actions 32 Packages Projects Releases Wiki Activity
155 Commits 1 Branch 1 Tag
main
Commit Graph
9 Commits
Author SHA1 Message Date
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
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 c759e111ec feat(k8s): install.sh 三级部署预检——kubectl 缺失/连不上集群时给出可执行的具体修法 
用户反馈：部署时报错只说「未找到 kubectl，请先安装」「kubectl 无法连接集群，
请检查 kubeconfig」，对新人等于没说 —— 不知道是没装工具、网络不通、凭据过期
还是 RBAC 没权限，也不知道下一步查什么。

原实现只有两行：
    command -v kubectl || die "未找到 kubectl，请先安装"
    kubectl version --request-timeout=5s || die "kubectl 无法连接集群，请检查 kubeconfig"

改为三级预检 + 一级软检查：

【0.1 kubectl 是否存在】
  按 CentOS/TencentOS、Ubuntu/Debian、macOS 分别给安装命令；
  额外给「机器没有外网」的替代路径（控制台下载 / 内网跳板机 / 只 scp 二进制）。

【0.2 kubeconfig 文件是否存在】← 新增，堵一个误判
  KUBECONFIG 指向不存在的文件时，kubectl 会忽略它并退回默认规则，
  最终报出 "Authentication required" / "connection refused" 这类误导性错误，
  让人白查凭据和网络。现在单独判一次，直接给出查找路径 + 各云控制台下载入口。
  支持 KUBECONFIG 用 : 分隔多路径，任一存在即通过。

【0.3 能否连上 API Server】按错误类型分类，各给专属修法
  · context 不存在      → get-contexts / use-context / 重新下载
  · 401 认证失败        → 云厂商 token 有效期几小时，重新下载；自建查客户端证书
  · 403 RBAC 拒绝       → auth whoami / auth can-i --list，列出部署所需的具体资源
  · x509 证书问题       → 确认证书过期；可信内网可临时 insecure-skip-tls-verify
  · 网络不通            → curl -k <API>/version、VPN/专线、安全组放行 6443、换跳板机
  · 其他                → 原样打印 kubectl 错误 + 通用排查清单

【0.4 部署权限软检查】auth can-i 非 yes 时只告警不阻断
  （首次部署时目标命名空间可能还不存在，硬拦会误伤正常流程）

失败时统一打印环境信息（kubeconfig 路径 / context / API Server / 当前用户），
一眼看出连的是哪个集群。连接超时可用 KUBECTL_TIMEOUT=15s 放宽（默认 8s）。

README 同步新增「前置条件」章节：预检项对照表 + 错误分类表 + 失败输出示例。

=== 验证 ===
从真实 install.sh 抽出预检段，用假 kubectl 精确模拟 8 种场景（两个脚本各跑一遍）：
  A 没有 kubectl            → 退出 1，打印各系统安装命令 ✅
  B API Server 超时         → 退出 1，提示 VPN/专线/安全组 ✅
  C 没有 context            → 退出 1，提示 get-contexts/use-context ✅
  D 401 凭据过期            → 退出 1，提示重新下载 kubeconfig ✅
  E 403 权限不足            → 退出 1，列出所需资源权限 ✅
  F x509 证书过期           → 退出 1，提示证书/insecure 排障 ✅
  G 正常环境（真实集群）     → 通过预检，退出 0 ✅
  H kubeconfig 文件不存在   → 退出 1，提示下载位置（不误报成 401）✅
  结果：阻断 7/7、正常通过 1/1；bash -n 语法检查通过

⚠️ 踩坑记录：kubeconfig 多路径判断最初写成
     while IFS= read -r _p; do ...; done < <(printf "%s" "$PATHS" | tr ":" "\n")
   printf 输出没有结尾换行 → read 带着数据返回非 0（EOF）→ 循环体一次都不执行，
   导致所有场景都误报「找不到 kubeconfig」。改用 IFS=":" + for 拆分。
 2026-10-28 07:25:15 +00: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 3c9388658b refactor: 资源名 opsx-loki/opsxloki → lokistack（线上已迁移完成） 
【已在线完成，零数据丢失】
K8s ns=log 资源全部改名：
  Deployment  opsx-loki          → lokistack
  Service     opsx-loki          → lokistack
  Service     opsx-loki-nodeport → lokistack-nodeport
  PVC         opsxloki-data      → lokistack-data
  Secret      opsxloki-secrets   → lokistack-secrets
  Label       app: opsx-loki     → app: lokistack
  Ingress     log.astx.club 后端  → lokistack-nodeport:8080
  镜像        lghost/opsxloki     → lghost/lokistack
  docker-compose 卷/容器名同步更名

【保留不变（改了会出事）】
  namespace: log
  数据文件名 opsxloki.json（代码硬编码）
  容器内路径 /app/data

【迁移过程】
  1. 备份 PVC 数据(32KB) + Secret 原值 + 旧 yaml → /root/lokistack-migration-backup-20261026-171141
  2. scale 旧 Deployment → 0，等 Pod 消失
  3. 复制 Secret（JWT sha256 校验一致）
  4. 新建 PVC lokistack-data（Bound 30Gi cbs）
  5. 临时 Pod 恢复数据（chown 1000:1000，opsxloki.json 保留 0600）
  6. apply 新 Deployment → 1/1 Running
  7. 修复 Ingress 后端（TKE qcloud 要求 NodePort）→ CLB 恢复 200
  8. 删除旧 Deployment / 失效 Service

【验证】
  lokistack 1/1，0 重启，镜像 lghost/lokistack:latest（statically linked）
  /api/v1/health → {"status":"ok","version":"2.0.0"}
  /app/data/opsxloki.json 610B 完整（admin 用户 + 配置）
  http://log.astx.club/ → HTTP 200
  镜像加固：admin123=0、/app/backend/=0、initial-admin-password.txt 存在

【回滚兜底（建议 7 天后删）】
  pvc/opsxloki-data、secret/opsxloki-secrets

【文档】
  README 新增「从 opsx-loki 升级」章节：
  K8s 七步迁移脚本 + docker-compose 卷迁移命令
 2026-10-26 17:16:15 +00:00
opsx b65dcc9677 refactor: 镜像名 lghost/opsxloki → lghost/lokistack（跟随项目更名） 
只改镜像引用（8 处），K8s 资源名一律不动 —— 改了会丢数据/断服务：

改：
  kubernetes/deployment.yaml        image
  docker-compose.yml                image
  docker-compose.prod.yml           image ×2
  kubernetes/README.md              文档 ×2
  docs/deployment/kubernetes.md     文档 ×2

不改（重要）：
  opsxloki-secrets    K8s Secret —— 改名会导致 JWT_SECRET/ENCRYPTION_KEY 重置，
                      历史加密的实例密码无法解密
  opsxloki-data       PVC —— 改名 = 新建空卷，数据全丢
  container_name      docker 容器名 —— 改名会让 docker exec/logs 命令失效
  app: opsx-loki      Pod label —— 改名要同步改 Service selector
  deployment 名称 opsx-loki —— 改名要重建 Deployment

⚠️ 部署顺序（本提交只改代码，尚未 apply 到 K8s）：
  1) 推镜像 lghost/lokistack:latest 到 Docker Hub
  2) kubectl apply -f kubernetes/deployment.yaml
  3) 等 Pod 1/1 就绪
  4) 才能删除 lghost/opsxloki
  顺序颠倒会因 imagePullPolicy: Always 拉到不存在的镜像导致服务中断
 2026-10-26 17:09:47 +00:00
opsx 3c27e58a73 feat(security): 移除 admin123 硬编码默认密码 + 编译加 -trimpath 
安全加固（降低二进制泄露/逆向的信息面）：

1. 初始密码随机化
   - 首次启动生成 16 位随机密码（大小写+数字，排除 0/O/1/l/I 易混淆字符）
   - 写入数据卷 initial-admin-password.txt（0600）并打印到首次启动日志
   - admin 首次改密后自动删除该文件（seed.CleanupInitPassword）
   - 支持 ADMIN_INIT_PASSWORD 环境变量指定（自动化部署 / 固定密码场景）
   - 生成失败直接 Fatal 退出，不再降级到公开默认口令

2. 移除硬编码 admin123
   - main.go 不再打印 "Default login: admin / admin123"
   - 二进制内 admin123 命中：2 → 0

3. -trimpath
   - build.sh / run.sh 编译加 -trimpath
   - 二进制内 /app/backend/ 源码路径命中：66 → 0

4. 文档
   - README 新增「第 4 步：获取管理员初始密码」
     （docker compose exec / logs / docker cp / named volume 四种方式 + K8s 对应命令）
   - .env.example 补 ADMIN_INIT_PASSWORD
   - kubernetes/deployment.yaml 加 env 注释说明

验证（strings 对比加固前后二进制）：
  admin123              2 → 0
  /app/backend/        66 → 0
  initial-admin-password.txt / ADMIN_INIT_PASSWORD / CleanupInitPassword 均存在
 2026-10-26 17:01:09 +00:00
opsx 9a46a955d4 feat(k8s): 一键部署脚本 + 跨云适配 + 云相关清单拆分到 examples 
新增 kubernetes/install.sh（一条命令部署）：
- 云平台识别：读节点 providerID，识别 TKE / EKS / ACK / CCE / GKE / AKS / K3s / 自建
- StorageClass 三级探测：显式 STORAGE_CLASS → is-default-class 注解 → 集群唯一 SC
- 自建集群兜底：无任何 SC 时自动创建静态 local PV
  （hostPath + DirectoryOrCreate + nodeAffinity + WaitForFirstConsumer + Retain）
- Secret 幂等生成：已存在则跳过，绝不覆盖（避免密钥轮换导致历史凭证无法解密）
- 失败分类诊断：ImagePullBackOff / CreateContainerConfigError / PVC Pending
  按云给出对应仓库格式与推荐 SC 名
- 环境变量：WITH_NODEPORT / STORAGE_CLASS / LOCAL_STORAGE / NODE_NAME / PV_PATH / PV_SIZE

云相关清单拆到 kubernetes/examples/：
- ingress.yaml（阿里云 alb）、ingress-tke.yaml（腾讯云 qcloud）、secret.example.yaml
- 原因：留在根目录会导致 kubectl apply -f kubernetes/ 时 ingress 同名互相覆盖，
  且 secret.example.yaml 的占位符会把真实密钥顶掉

README 重写：
- 全部用法速查 + 环境变量一览
- 自建 K8s 存储方案选型（local PV / local-path-provisioner / OpenEBS / Longhorn / NFS）
- hostPath 数据运维：定位、热备份、跨节点迁移、卸载保留、常见坑
 2026-10-26 14:03:39 +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