 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 |
|
|
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
|
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 |
|