opsx
cec7c6eeaf
feat(license): 退出授权 / 释放本实例（确认后 deactivate）
...
设置→授权 Pro 态管理员可退出：在线 LIC- 先调 opsx deactivate（含 activation_token），成功才清本地；失败保留现状。LICOFF- 仅解本机并提示后台名额可能仍占。禁静默清码。
2026-11-01 03:16:05 +08:00
opsx
62d9b81a70
fix(license): shared invalid/grace banners + instance copy
...
Surface expired/over_instance/revoked red banners with CTAs via a
shared LicenseStatusBanners used by settings and ProGate. Hide seats
in product UI; keep HMAC dual-path and never silent-clear keys.
2026-11-01 03:08:37 +08:00
opsx
af0298e994
feat(license): dual-path opsx-licence client alongside HMAC
...
Wire LIC-/LICOFF- activate/verify/heartbeat to licence.rlwj.cn/api,
keep legacy HMAC accepted with deprecation banner, add instance_id
fingerprint and licensing docs (product lokistack still needs admin create).
2026-11-01 02:55:37 +08:00
opsx
02c1ee8aa8
docs(ai): TestConfig key 解析注释精确化(仅注释,无逻辑变更)
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
2026-11-01 02:01:37 +08:00
opsx
fbbd3a3c27
refactor(ai): 砍掉 /aiops 整页,模型配置迁入系统设置,浮窗助手保留
...
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
评估结论落地:整页分析只喂聚合统计(模型看不到日志原文),结论价值低于 /analysis
图表自身;浮窗助手携带真实查询样本,价值成立。
- 删 /aiops 页面与路由(菜单去项);llmProviders 迁 lib 共用
- 模型配置重做为设置页「AI 模型接入」区:状态严谨映射——供应商/模型按已存
baseUrl/model 正确回显(自定义供应商显示 BaseURL 与自定义模型输入,不再重置),
API Key 掩码占位、留空或掩码保存均沿用旧值(不回传掩码)
- 后端删 /ai/analyze 与信号采集链路;/ai/chat 保留(上下文由前端日志样本注入)
2026-11-01 00:46:38 +08:00
opsx
c216bdfdd4
feat(ai): 助手浮窗聚焦日志查询页,携带当前查询结果对话
...
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
- 浮球只在 /logs 渲染(产品定位:辅助分析正在查看的查询结果,其它页面不打扰)
- /logs 查询成功后写入 AI 上下文:LogQL、时间范围、结果条数、error 行数、
最新 20 条样本(去 CRI 包装);对话请求自动携带
- 后端 /ai/chat 接收 context:截断 6000 字 + RedactTextOnly 统一脱敏后并入 system
(ECHO 假模型实测注入完整);空态文案改为查询导向
2026-11-01 00:31:48 +08:00
opsx
5d898e3592
fix(ai): 测试连接改为结构化结果,不再倾倒模型原始回复
...
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
返回 {model, latencyMs, tokensUsed, replyLength};前端提示「连接正常:模型 · 耗时 · tokens」。
模型原始回复不回传——测试要的是通没通/多快,不是看模型说了什么(ECHO 假模型下尤其明显)。
空回复时明确报错提示检查 baseURL 是否 OpenAI 兼容。
2026-11-01 00:21:59 +08:00
opsx
f457d6da09
feat(ai): 全站 AI 助手浮窗(参考 FlowStack 右下角浮空设计)
...
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
- POST /ai/chat:多轮对话(messages 透传)+ 页面上下文注入 —— 前端带当前路径,
后端自动附加该数据源近 15 分钟轻量日志摘要(总量/Top3 应用/告警命中),
追问「这个报错什么原因」有数据依据;脱敏/每日配额/Pro 闸门与整页分析共用
- AiAssistant 浮球+浮窗挂 Layout:仅 admin+Pro 渲染;消息气泡、Enter 发送、
上下文随路由自动采集;免费版不显示
2026-10-31 23:46:33 +08:00
opsx
9641503007
feat(license): Pro 授权机制 — 离线许可码 + 免费版功能闸门
...
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
免费版:日志查询/部署管理/采集/用户管理/LDAP/设置;Pro(¥199 个人单实例永久 / ¥499 团队多实例永久):
日志分析、日志告警、智能运维(AI)、审计日志。
- 后端:HMAC-SHA256 离线许可码(签发 CLI / license --plan --edition --seats --customer --days;
永久=days 0),GET /system/license + POST activate;RequirePro 闸门挂 metrics/ai/audit;
过期自动回落免费;测试覆盖签发-校验/篡改/免费拒签
- 前端:菜单 Pro 项带锁标;四个 Pro 页面免费版渲染升级引导卡(功能清单+定价+页内激活);
设置页新增授权区(版本/席位/到期/激活入口);license 词典中英
- domains 注册提升到 main.tsx 全局(修复 license 命名空间在未引 domains 的页面显示裸键)
2026-10-31 23:08:06 +08:00
opsx
c090ba0564
feat(aiops): 长窗口(>1h)分析必须指定应用
...
全命名空间 6h/24h 聚合数据量过大会拖垮 Loki:前端时间范围旁新增应用范围选择器
(labelValues 候选),>1h 未选应用禁用开始分析并提示;后端同样强制 400(闸门在服务端);
信号采集选择器按 app 收窄后 histogram/stats 从全量变为单应用流,秒级返回。
2026-10-31 22:51:55 +08:00
opsx
7be41f0a6b
feat(aiops): 新增「智能运维」——AI 日志分析（P0，不扫日志内容）
...
CI / Backend (go vet + test) (push) Waiting to run
CI / Frontend (lint + build + test) (push) Waiting to run
=== 为什么这样设计（成本优先）===
全集群 370GB/天，把日志原文丢给模型是不可能的（一次几百万 token）。
所以整条链路只做一件事：**把 GB 级日志压成 KB 级信号**。
P0 的信号来源全部是索引/快照，**零日志内容扫描**：
体积 + 趋势 → index/volume_range（实测 24h 仅 54ms）
条数/流数 → index/stats，且只在 ≤2 小时窗口用
（全天 index/stats 实测 20s，绝不能进 AI 路径）
应用排行 → 平台小时级预聚合快照（毫秒）
基线对比 → 上一个等长窗口的 volume_range
告警 → 平台投递记录
实测一次分析：3~6 秒、输入 600~1400 tokens（约 ¥0.005/次）。
=== 后端 ===
models/ai.go AIConfig（APIKey 加密存储）+ AIAnalysisRun（审计）
services/ai_config.go 读写配置、掩码返回、每日 token 用量统计
services/ai_provider.go OpenAI 兼容客户端 + 连通性测试
（DeepSeek/通义/内网 vLLM/Ollama 通用）
services/ai_redact.go 脱敏：凭据/邮箱/手机号/身份证 → 占位符，
**保留内网 IP 与端口**（排查必需）
services/ai_signal.go 信号采集 + 渲染成紧凑文本（省 token）
services/ai_analyze.go 结构化输出解析、配额闸门、审计落库
controllers/ai.go /ai/config /ai/config/test /ai/analyze /ai/runs
成本闸门（三层）：
1) 单次：时间范围 ≤24h、maxTokens ≤1500
2) 每用户每日 token 上限（默认 50 万，可配，超限直接拒绝并说明）
3) 审计只留最近 500 条，避免表膨胀
=== 前端 ===
新页面 /aiops（侧栏「智能运维」，管理员），页内单层 tab：
日志分析 / 模型配置 / 分析历史
- 分析：数据源 + 时间预设(15m/1h/6h/24h) + 可选提问 → 结论/证据/建议/不确定 四区
顶部显示本次消耗（in/out tokens、耗时），可查看「发给模型的完整内容」
- 配置：启用开关、Base URL、模型、API Key（掩码）、温度、输出上限、超时、
每日配额、额外脱敏正则；按钮顺序改为「测试连接 → 保存配置」
- 历史：服务端分页（20/页），点行看详情与 payload
=== 两个真实踩坑（已修）===
1) 密码含 @ 导致脱敏漏掉（mysql://user:P@ssw0rd@host）
→ URL basic-auth 规则改为贪婪匹配到最后一个 @，由单测锁定
2) 结论里的时间是 UTC（容器无 tzdata，time.Local=UTC），
模型写"凌晨 6 点下跌"而运维当时是下午 2 点
→ 显式用东八区展示（LOKISTACK_DISPLAY_TZ=UTC 可覆盖）
=== 实测（69147008fcf4）===
配置保存 → key 掩码 sk-***e286；连通性测试返回「正常」
分析 15 分钟窗口：4.1s，结论识别出"窗口末段体积断崖约 -60%"
信号时间 14:23~14:38（本地时间正确）
历史分页 total=3，tokens/耗时字段完整
单测：脱敏 2 个用例 + 模型输出解析 4 个用例 + 6 条 AI 路由断言
2026-10-31 06:39:01 +00:00
opsx
d4422f1541
refactor(analysis): 去掉排行 10/30/50 选择器，改为一次取 50 + 前端分页；零点结算昨天
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
=== 1. 为什么去掉「显示条数」选择器 ===
topk 的 N 不影响查询成本（扫描的 chunk 集合完全相同），实测：
topk(10) 17833ms / 11 条
topk(30) 18019ms / 34 条
topk(50) 7394ms / 54 条
topk(100) 17553ms / 74 条
波动来自集群负载，与 N 无关 —— 它只决定最后返回多少序列。
所以"选 30"既不更快也不更慢，本质是个翻页开关；
而选它还要重新等一次十几秒的查询，纯亏。
改为：一次 topk(50)，前端 10 条/页 → 5 页只需 1 次查询。
附带收益：占比的分母从"前 10 合计"变成"前 50 合计"，更接近真实占比。
副标题明确写清"一次取前 50 个应用（占比按这 50 个合计计算）"。
=== 2. 零点结算昨天（daily volume）===
原来只有 30 分钟 ticker 回补，且启动时间不对齐整点 →
昨天最早的一段可能已经超出 Loki 24h 保留期被删，
结算结果系统性偏低，图上却标"完整一天"，属静默错数。
新增 nextMidnightFinalize()：每天 00:01 触发 FinalizeYesterdayVolume()
- 昨天定稿 partial=false
- 补一次条数（index/stats，一天一次可接受）
- 顺带刷新今天 partial=true 的柱子
ticker 仍保留，负责当天数据的 30 分钟刷新。
=== 3. 顺带 ===
- 去掉每日量"其中 N 天平台没有留存记录"的提示文案（按用户要求）
- 修 QuickQueryTemplates.tsx 的未使用变量导致 tsc -b 失败
- 工作区里上一轮中断的"排行体积列"改动一并纳入（app-ranking 返回 bytes，
TopAppsTable 增加体积列，快照记录 per-app 字节数）
Pod = Hub latest = a16978d2f88b
2026-10-30 17:13:18 +00:00
opsx
7b1ffd0274
fix(daily-volume): 30/90/365 天切换"没反应"；/logs/stats 加短缓存
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
=== 1. 切换范围没反应（真 bug）===
现象：7/30/90/365 天切换后图完全一样。
根因：GetDailyVolumeHistory 只返回**已抓到的快照**。平台只有 4 天数据，
所以任何 days 都只返回 4 个点 → 图表一模一样。
修复：始终返回 days 个点，缺失的天用 Missing=true 标记。
实测：days=7→7 点(缺3)、30→30 点(缺26)、90→90(缺86)、365→365(缺361)。
为什么必须区分 Missing 和"0 字节"：
前者是"平台没留存"，后者是"那天确实没日志"。
混在一起会让 30/90 天的图上出现大片 0，被误读成"日志量暴跌/系统停摆"。
前端：缺失的天画灰色浅柱，tooltip 显示"未留存"，图下方提示
"其中 N 天平台没有留存记录（灰色柱），不是当天没有日志"。
=== 2. /logs/stats 加 90 秒缓存 ===
分析页每次进入/切范围都打 index/stats，实测 5 分钟窗口冷查询 1.2 秒
（60 分钟更慢）。这类聚合值可容忍分钟级陈旧，加与指标查询一致的缓存：
90s TTL + 时间窗按 2 分钟取整 + 上限 200 条 + 过期清理
实测：重复请求 1227ms → 8ms。
=== 3. 顺带确认已生效的优化 ===
histogram(24h) : 54ms（volume_range）
daily-volume : 10ms（只读库）
stats 二次请求 : 8ms（新缓存）
长范围(>1h) : 不跑 count_over_time（预聚合快照 + 跳过内容扫描）
Pod = Hub latest = 12453ea723c1
2026-10-30 16:46:40 +00:00
opsx
d0adc095dd
feat(analysis): 长范围应用排行改走「小时级预聚合」，不再扫日志内容
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
=== 问题（实测）===
按应用排行必须读日志内容（Loki 3.4 的 index/volume 不支持 app 维度聚合，
aggregateBy=app 无效），成本 ∝ 时间范围：
5 分钟 ≈ 1.3GB → 9.8s
15 分钟 ≈ 3.9GB → 19.5s
1 小时 ≈ 15GB → 预计 60~90s
6 小时 ≈ 92GB → 5~8 分钟
24 小时 ≈ 370GB → 不可用
用户在时间范围里选 6h/24h 时，页面必然卡死。
=== 方案 ===
新增 models.AppVolumeSnapshot + services/app_volume.go：
- 后台任务每小时第 5 分钟抓「上一个完整小时」的 per-app 条数
- 用**瞬时查询**（/loki/api/v1/query + [1h]）而不是 query_range：
单点评估、扫描量相同、省掉多步开销；并绕开 LokiMetrics 的 90s 上限
与重型查询信号量（后台任务不该和前台抢令牌）
- 每源每小时只留 top 50 应用，保留 90 天
- 幂等：同 (hour, source, ns, app) 更新而非重复插入
- 超出 Loki 26h 保留期的窗口跳过（抓也抓不到，白等几分钟）
新增 GET /api/v1/logs/app-ranking?sourceId&from&to&limit → 读库毫秒级
前端：analysis 判断范围 > 60 分钟就走预聚合接口，并停掉实时重查询
（rankingEnabled 置 false）；表格副标题说明「读的是预聚合快照，已留存 N 小时，
不含错误数与趋势」。
=== 顺带修掉的根因 bug ===
useInView 原来用 useRef + useEffect([inView])：分析页首屏 data===null 时
内容块不渲染，ref.current 为 null，effect 直接 return；等数据到了 DOM 才挂上，
但依赖没变 → effect 不重跑 → IntersectionObserver 从未创建 → inView 永远 false
→ 重查询永不发出 → 页面一直显示"没有应用维度的数据"。
改成 callback ref（节点挂载即作为依赖），并加 scroll/resize 兜底 + 挂载瞬间量一次。
另外分析页加 8 秒无条件兜底：可见性判定再失灵，8 秒后也一定查一次。
默认时间范围 15 分钟 → 5 分钟（19.5s → 9.8s）。
=== 实测 ===
Pod = Hub latest = 98de87e7f895
5 分钟窗口 by-app：9.8s（75 序列）；15 分钟：19.5s
2026-10-30 16:35:35 +00:00
opsx
3b297d0429
feat(collectors): 采集项支持「表单 / YAML」双模式编辑（方案 A）
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
=== 设计边界（刻意不做"编辑完整 promtail.yaml"）===
开放的是**采集项本身**的 YAML 表示（字段与 models.ScrapeJob 一一对应）：
name / paths / labels / encoding / json / system
multiline(firstline,maxLines) / timestamp / dropIfMatch / rateLimit
clients、positions、server、scrape_configs 外层仍由平台生成。
理由（真实故障面）：
用户删掉 positions → 重启后从头重采，大量重复 + Loki 以
entry too far behind 拒绝整批；删掉 clients → 完全不外发。
这两类问题在页面上看不出来，只能登机器看日志，排障成本极高。
只开放采集规则，写坏了最多某条日志没采到，不会让采集器整体失效。
=== 后端 ===
新增 services/collector_jobs_yaml.go：
RenderJobsYAML(jobs) → 带边界说明注释的 YAML（明确写"clients/positions 不在此修改"）
ParseJobsYAML(text) → 复用 models.ValidateScrapeJobs，与表单完全同一套校验
错误信息必须具体：
YAML 语法错 → 「YAML 语法错误：yaml: line 1: did not find expected ',' or ']'」
语义错 → 「采集项「app」至少需要填写一个日志路径」
新增路由（用 /collector-jobs/* 前缀，避开与 /collectors/:id 的 gin 通配冲突）：
POST /api/v1/collector-jobs/render
POST /api/v1/collector-jobs/parse
=== 前端 ===
编辑弹框（主机模式）加「表单 / YAML」切换：
- 切到 YAML：调 render 把当前采集项渲染出来
- 切回表单：调 parse 回填；解析失败**留在 YAML 模式**并显示原因
（绝不能悄悄丢掉用户改动）
- 停留在 YAML 模式点保存：先 parse，失败则中止保存
- 编辑区 min-h 固定、等宽字体、可拖拽高度
=== 测试 ===
TestRenderParseJobsYAMLRoundTrip：
表单→YAML→表单 无损往返，逐字段核对
（multiline.maxLines / rateLimit / dropIfMatch / timestamp / labels / system）
TestParseJobsYAMLErrors：空内容、语法错、空列表、缺名称、缺路径、名称非法
→ 6 种输入都给出具体错误，不是笼统"格式错误"
=== 实测（c11d2badce64）===
render: code=0，17 行，含边界说明
parse : code=0，1 个采集项；往返校验 name=app paths=1 multiline=True
rateLimit={rate:2000,burst:4000} drop=1 json=True
错误: 「采集项「app」至少需要填写一个日志路径」
「YAML 语法错误：yaml: line 1: did not find expected ',' or ']'」
Pod = Hub latest = c11d2badce64
2026-10-30 16:10:51 +00:00
opsx
c8d026adc7
feat(collectors): DaemonSet 不再填日志路径，改为「只采集哪些命名空间」多选
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
用户指出的三个问题，逐条核实后的结论：
1) 「采集日志路径」对 DaemonSet 确实是多余的 —— 确认后端模板里写死了
`replacement: /var/log/pods/*$1/*.log`（按 pod UID 精确匹配容器标准输出），
表单里填的 logPath 对 DaemonSet 完全不参与渲染。
→ 选择 DaemonSet 时隐藏该字段，提交时强制置空。
2) 「可以指定采集多个命名空间」—— 后端**早就支持**：
models.Collector.TargetNamespaces + promtailNamespaceFilter()，
空数组 = 全集群。只是**前端新建弹框没暴露**（编辑弹框里有）。
→ 新建弹框补上多选 chips（全集群 / 各命名空间可点选），并补齐前后端透传：
dto.CreateCollectorRequest.TargetNamespaces
controller → services.CreateCollectorRequest.TargetNamespaces
models.Collector.TargetNamespaces
之前前端即使传了也会被 Go 静默丢弃（无该字段）。
3) 「命名空间」字段语义已在上一提交补了分类型说明：
- DaemonSet：采集器自身部署在哪个命名空间（不影响采什么）
- Sidecar：目标应用 Deployment 所在命名空间
新增 TestDaemonsetTargetNamespacesFilter：
nil → 不生成 namespaces 白名单（全集群）
["astralx"] → 生成且包含 astralx
["astralx","default"] → 两个都在
=== 实测（d45dfa18ecc5）===
前端文案「只采集这些命名空间」「不选 = 采集整个集群…」均已进包
渲染测试 3 种输入全部符合预期
注：本次 docker push latest 遇到 Docker Hub 502，v0.1 成功而 latest 仍指向旧镜像，
导致首次滚动后 Pod 仍是旧代码；重推 latest + 强制重建 Pod 后确认
Pod digest = d45dfa18ecc5 —— 记录这个坑：push 失败必须核对三方 digest。
2026-10-30 16:03:24 +00:00
opsx
ad0d35f72a
feat(alerts,logs): A 方案—告警窗口 15m→5m 消重复扫描；数据源可编辑/删除且删后不被自动重建
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
=== 1. 告警窗口 15m → 5m（阈值同比例 1/3）===
背景：检查间隔已改 5 分钟，但规则窗口仍是 15 分钟 ——
同一个 15 分钟窗口每 5 分钟被完整重扫一遍，等于 3 倍重复扫描。
在 370GB/天、全命名空间 selector 下，这是 Loki CPU 的最大稳态来源。
FATAL 10 → 4 窗口 5m
Go panic 10 → 4 窗口 5m
JVM OOM 5 → 2 窗口 5m
StackOverflow 5 → 2 窗口 5m
应用错误激增 100000 → 35000 窗口 5m（改名 error > 3.5万）
ingress 5xx 2000 → 700 窗口 5m
ingress 4xx 20000 → 7000 窗口 5m
DB 连接失败 1000 → 350 窗口 5m
阈值按 1/3 缩放是必须的：窗口缩短 3 倍后，同样的流量在 5 分钟内只有
1/3 的条数，阈值不动就永远打不到了。
迁移 v10→v11 只改"窗口仍是 15 且名字匹配内置规则"的项，用户手调的不动。
=== 2. 数据源支持编辑/删除（含托管源）===
原来前后端都把托管源锁死：
- 前端 `!managed &&` 直接不渲染编辑/删除按钮
- 后端 DeleteSource 返回「平台部署的数据源随部署管理,请先删除对应部署」
用户的诉求是"数据源必须能编辑和删除"，且确实有场景（不想让某个源出现在
查询下拉里、想改认证头）。
=== 3. 修「删了又回来」的真 bug ===
EnsureLogSourcesForRunningDeployments() 在 **每次打开数据源列表和启动时**
都会给 running 部署补齐数据源 —— 所以删掉托管源后，刷新页面它又回来了，
用户看到的现象就是"删不掉"。
新增 LokiDeployment.AutoSourceDisabled：
- 删除托管源时置位（DisableAutoSourceFor）
- EnsureLogSourceForDeployment 见到该开关直接 return
- 部署被编辑/重新部署时重置（EnableAutoSourceFor），即"你要用它了就恢复"
前端配套文案：
- 编辑托管源弹窗提示"重新部署会覆盖集群/Service/端口，认证与请求头保留"
- 删除确认明确"删除后不会再自动重建，重新部署该 Loki 才恢复"
=== 实测（20300eef92d2）===
v11 迁移后 8 条规则全部 窗口=5m，阈值 4/4/2/2/35000/700/7000/350
go test ./... 全绿
2026-10-30 15:28:30 +00:00
opsx
437ff56992
feat(docs): 文档站重制 — 参照 opsxapi/opsxshell 体系,服务端渲染三栏布局
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
- 后端 goldmark 渲染管线:/docs/:slug 页面 + /docs/search-data.json 搜索索引,
manifest.json 驱动分组导航,正文剥 H1 避免与页面头重复
- 三栏布局(分组侧栏/内容/本页目录)+ 顶栏(品牌/版本徽章/搜索面板/官网入口),
docs.css 品牌绿版 + docs.js(代码复制/轻量高亮/提示块/TOC 滚动高亮/移动端抽屉)
- 替换 docsify;无上一页时空占位无边框;visual-judge 两轮评审(初版 fail → 修复后 pass)
2026-10-29 15:30:25 +08:00
opsx
c1f822fb10
refactor: 移除资源用量的可选 Prometheus 接入与平台监控页
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
- 资源用量弹窗:删除 applyPrometheus/promQueryValue 与峰值/限流字段
(LOKI_USAGE_PROMETHEUS_URL 从未内置,代码恒走降级),统一提示
「未接入 Prometheus:暂无峰值/限流数据」;扩容建议改基于 metrics-server 实时值
- 移除「平台监控」菜单页与 /api/v1/system/metrics-summary;
原始指标保留在标准 /api/v1/metrics(Prometheus 文本格式)可自行抓取
- 手册/落地页/CHANGELOG 同步(去除备份恢复与监控页宣传,指标端点表述中性化)
2026-10-29 15:16:18 +08:00
opsx
f87fb4b2b3
refactor: 移除备份恢复功能(API/CLI/手册)
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
日志数据的保留与安全由对象存储 + Loki retention 承担,平台侧整库备份恢复价值有限:
删除 services/backup.go、/system/{backup,restore,restore/apply,backups} 路由与 handler、
CLI backup/restore 子命令、前端 api 方法与类型;自检所需的 dataDirPath/密钥指纹并入 selfcheck;
用户手册删备份章节并修正 FAQ 升级建议;CHANGELOG 记录移除。
2026-10-29 14:48:25 +08:00
opsx
3ea7f2dcc6
feat(site): homepage 落地页 + docsify 用户手册文档站(/docs /homepage 随二进制发布)
...
- homepage/:品牌落地页(Hero/特性/快速开始),参考 opsxapi 站点风格,绿色品牌系
- docs/:docsify 文档站 + user-guide 十篇手册(安装/向导/采集/查询/分析/告警/授权/备份/FAQ)
- 后端 serveStaticDir 挂载 /docs 与 /homepage(可执行文件相对定位,独立于前端 dist)
2026-10-29 14:04:24 +08:00
opsx
572efc89a4
fix(reliability): 采集器并发去重 + 备份恢复即时重载 + context 贯穿请求链
...
- CollectorService 安装/卸载按采集器互斥去重(重复触发不再并发 docker rm/run 互踩);删除后卸载失败留日志
- ApplyStagedBackup 替换文件后立即 Reload 内存态,消除「重启前旧内存落盘覆盖恢复文件」竞态;暂存文件名升级 lokistack.json(兼容旧名)
- GetUsage/Validate 全链路 context 贯穿:请求取消即中止 SSH/k8s 查询(异步调用点显式 Background)
2026-10-29 13:29:25 +08:00
opsx
5e59347c40
feat(settings,analysis): 日志保留时间可配（发送历史保留 7 天）+ 分析页手动刷新；修复我引入的 RWMutex 死锁
...
=== 0. 【严重】修复上一版引入的死锁（平台写路径全卡死）===
上一版把保留期读取写成 `GetRetentionSettings()`（内部 db.RLock()），
却在 `db.Lock()` 已持有的情况下调用（recordDelivery / RecordAudit 的裁剪路径）。
Go 的 sync.RWMutex **不可重入** → 第一次写投递历史/审计日志就永久死锁。
现象：登录 28 秒返回空（登录也要写审计）、所有写接口挂住。
go build / go vet / 之前的单测（不触发写路径）全都查不出来。
修法：
- 拆出 retentionFromDBLocked(db) / alertDeliveryRetentionLocked(db) /
auditLogRetentionLocked(db)，调用方已持锁时用无锁版本
- upsertSettingLocked 里**不能**用 db.NextID()（内部 d.mu.Lock()，同样死锁），
改为锁内自算 max(id)+1
- 新增 retention_test.go：持写锁调用裁剪函数，2 秒超时未返回即判死锁
实测修复后：登录 103ms（原 28000ms）、panic/deadlock 命中 0。
=== 1. 平台数据保留期可配（系统设置 → 通用配置 → 日志保留时间）===
新增 GET/PUT /api/v1/settings/retention：
alertDeliveryDays 告警发送历史保留天数，默认 7（原写死"最近 50 条"）
auditLogDays 审计日志保留天数，默认 90（原写死常量）
保存后立即按新策略裁剪一次，不必等下次触发。
校验：发送历史 1~365 天、审计 1~3650 天，超出返回明确中文原因（不是 500）。
注意与「Loki 日志保留期」区分：那个是部署级配置（组件部署 → 保留策略）。
=== 2. 发送历史：50 条硬上限 → 保留 7 天 ===
后端 Deliveries 接口原来写死 `len(out) < 50`，现在按保留期取（响应上限 500 可调），
标题改为「发送历史（保留 N 天）」，N 从设置里读。
=== 3. 菜单「日志服务」→「组件部署」===
=== 4. 分析页：去掉「全部命名空间」+ 改手动刷新 ===
- 移除「全部命名空间」选项：{namespace=~".+"} 要扫全集群（约 370GB/天），
一次分析几十秒，得不偿失；历史值 __all__ 也会被忽略并回退到策略/第一个 ns
- 筛选改为「选择值 / 已生效值」分离：切换命名空间或时间范围**不再自动查询**，
只把刷新按钮点亮并提示「筛选条件已改，点刷新生效」；
点一次才应用并取数。
原因：一次分析要跑多条 count_over_time，切一下下拉就重查一轮，
快速连点会把 Loki 打满（并发护栏 429），还拖慢别人。
=== 实测（9739c7c092e7）===
登录 103ms / token 273 字符
GET retention → {alertDeliveryDays:7, auditLogDays:90}
PUT 0 天 → 400「告警发送历史保留天数需在 1~365 之间」
平台日志 panic/deadlock 命中 0
go test ./... 全绿（含 2 个新死锁回归用例）
2026-10-29 04:16:52 +00:00
opsx
fbefcc86df
feat(logs,analysis): 分页改"加载更多"+触底自动加载；修懒加载不触发；指标短缓存
...
=== 1. 日志列表：去掉页码分页，改「加载更多」+ 触底自动加载（节流）===
为什么不用"上一页/下一页/共 N 页"：
- Loki 是**游标分页**，不支持 offset，页码天生跳不了页
- 规模上没意义：15 分钟 4000 万条 → 按 200/页算 40 万页
- 带 |= / |~ 行过滤时总数根本算不出来（index/stats 只接受 label matcher）
日志排查的真实交互是"继续往下看"，所以改为：
- 列表底部：「已加载 N 条 · 约 M 条」+「加载更多」按钮
- 滚动到底**自动加载**，但 2 秒节流 —— 每批都要后端扫 Loki，
快速滚动连续触发会撞并发护栏（429），反而比手动点更卡
- 到 5000 条停止并提示"缩小时间范围或加过滤条件"（虚拟滚动只省 DOM，
不省数组内存，无上限会一直涨）
- 修正语义 bug：分页原来是 setEntries(result.entries) **整页替换**，
改成追加（否则"加载更多"等于翻页）
- 删除 pageCursors 翻页栈与 prevPage/nextPage/pageOf/pageOfTotal 文案
=== 2. /logs/stats 错误映射：Loki 400 → 我们的 400 + 人话 ===
之前带行过滤时 Loki 回 400 "only label matchers are supported"，
被统一包装成 502「Kubernetes API 代理返回 HTTP 400…」，
前端只能当失败静默 → 用户看到"总页数没了"却不知道原因。
现在返回 400 +「含过滤条件（|= / |~）时无法统计总页数：Loki 只支持按标签统计」，
前端据此在条数旁给出提示。
=== 3. 分析页：修"延迟加载永远不触发"（数据一直不出来）===
现象：应用排行/流图/饼图/活跃应用全是"没有应用维度的数据"，每日量"已有 0 天"，
但接口实测正常（by-app 返回 75 条序列、daily-volume 返回 2 天）。
根因：这三块用 useInView 门控，而 ref 挂在 <Card> 上，观察器不触发 → 永远 false
→ hook 直接 return → 页面永远空。
修法：
- 改用普通 <div ref> 包裹，不依赖组件是否转发 ref
- useInView 加**几何兜底**：1 秒后若元素已在视口内就直接置 true
（有些容器里 IntersectionObserver 的 root 判定会和预期不一致）
=== 4. 分析页指标短缓存（26s → 11ms）===
`sum by (app)(count_over_time(...))` 扫 15 分钟 astralx（约 6.6GB）实测 16~28 秒，
Loki 自带结果缓存不命中（时间窗每次都在变）。点刷新/切页都要再等半分钟。
现在按 (数据源, 查询, 时间窗) 缓存 90 秒，时间窗按 2 分钟取整当 key：
实测第 1 次 23514ms → 第 2 次 **11ms**
代价：命中缓存时数据最多旧 ~2 分钟，对聚合视图可接受。
=== 5. 仪表盘 ===
去掉「平台自检」「N 项需关注」两段文字：卡片本身就是自检结果，
标题重复一遍没信息量；状态改由图标+边框颜色表达。
=== 6. 其它文案修正 ===
饼图空态从「没有命名空间维度的数据」改为「没有应用维度的数据」
（饼图上一版已改成应用维度，文案没跟上）。
=== 实测（1da8a148d756）===
Pod = Hub latest = v0.1 = 1da8a148d756
stats：纯 selector → 200（7005 万条）；带 |= error → 400 + 人话
分析指标缓存：23514ms → 11ms
每日量：2 天（10-27 32.5GB / 10-28 356.5GB）
文案：加载更多 / 已到末尾 / 达到上限 均进包；代码中已无 prevPage/nextPage 引用
2026-10-28 23:36:32 +00:00
opsx
37e2f0febc
feat(analysis,alerts): 每日量落库看历史趋势、趋势图/饼图可读性、告警三分页
...
=== 1. 每日日志量必须落库（核心问题：Loki 只留 24 小时）===
实测：请求"近 7 天每日量"，Loki 只返回 27 个**小时**桶，全部在最近 24h 内 ——
因为 retention_period=24h，更早的 chunk 已经被删了。
也就是说「固定近 7 天」这张卡片，过去一直是"6 天空白 + 1 天有数据"，
用户看着像坏了，实际是数据物理不存在。
方案：平台自己留存历史。
- models.DailyVolumeSnapshot{Date(本地YYYY-MM-DD), SourceID, Bytes, Entries, Partial}
- services/daily_volume.go
CaptureDailyVolume 按天抓 index/stats 落库（幂等覆盖）
StartDailyVolumeCapture 启动 20s 后回补 + 每 30 分钟检查一次
GetDailyVolumeHistory 读库返回最近 N 天（今天会实时补抓）
- 保留 400 天（够看年度趋势），按 source+date 去重
- 前端可选 7 / 30 / 90 / 365 天，能看多长取决于平台积累多久
为什么用"每 30 分钟检查昨天有没有落库"而不是固定 00:10 定时：
平台可能整晚没运行，固定时点的定时器会直接错过；检查式回补不依赖平台在线时刻。
Partial 标记（关键，否则会误读）：
- 当天未结束 → partial=true
- 待抓取日期的起点已超出 24h 保留期 → partial=true（Loki 里就没那么多数据）
实测：10-27 32.5GB/2.65亿条 partial=true（保留期外），
10-28 348GB/28.56亿条 partial=true（当天进行中）
=== 2. 修一个 Go 副本 bug（自己写的，靠实测发现）===
第一版用 `for _, snap := range db.DailyVolumeSnapshots` 后改 snap 字段，
range 拿到的是**副本**，改动不会写回切片 → 同一天永远保持首次抓取的值，
partial 也永不更新（实测发现 10-27 该是 true 却显示 false）。
改为 `for i := range ... { snap := &db.DailyVolumeSnapshots[i] }`。
=== 3. 趋势图可读性 ===
从"裸折线"换成"渐变面积图"，并在图上方给出峰值 / 均值：
- 面积图能一眼看出"这一段整体比上一段高"，折线只能靠对齐格子数
- 峰值/均值避免用户自己对刻度
- Y 轴与 tooltip 统一 formatBytes，"每桶体积"写进 subtitle
顺带确认：趋势图只画体积（字节），不再混入 error（条数）——单位不同不能同轴。
=== 4. 饼图：命名空间分布 → 应用日志量分布 ===
本环境的命名空间只有 astralx / log 两个，饼图没有信息量；
改成按应用看谁在刷日志（前 8 名 + 其他），才是运维真正要的答案。
=== 5. 告警页拆成三个 Tab ===
「告警规则 / 通知通道 / 发送历史」独立成分页（用 ui/tabs）。
之前通道是折叠块、历史堆在规则下面，规则一多就要滚很久才看得到。
发送历史增加空状态文案，不再是"空页面不知道有没有在发"。
=== 6. 内置规则关联默认通道 + 首次部署 webhook 留空的评估 ===
结论：**webhook 可以留空，但通道必须是禁用状态**。
- 若种子给的是"已启用 + 空地址"通道，规则一命中就必然投递失败，
发送历史堆满红色失败，反而让人以为平台坏了
- 所以首次部署建一个**禁用**的占位通道「默认通知通道（待配置 Webhook）」，
内置规则全部挂到它；管理员填好 Webhook 再启用即可，不用逐条关联
- 保存时加校验：启用则必须有非空 Webhook（返回明确原因，不是裸 500）
- schemaVersion v5→v6：把已有的"无通道"规则补挂到默认通道
实测：8 条规则全部已关联通道
=== 实测（v11-1028-2252 / 187062644c0f）===
/logs/daily-volume?days=7 → 2 天数据，partial 标记正确
规则 8 条全部有 channelIds
平台 ready、健康 ok
2026-10-28 22:54:12 +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
hermes-agent
7e3356e32b
feat(collectors): 主机采集器容器优先托管 + 采集器日志查看 + 推送地址纠正
...
现象
1. 主机采集器只有 systemd 一条路，跨发行版差异大（这轮已踩过 param 被删、日志路径、
时间戳格式三处）；进程存活/开机自启也没有统一保证。
2. 「采集器日志」在主机模式下无法从平台查看，排「起没起来/在报什么错」必须 SSH。
3. 实测发现：Loki 部署把 listenIP 填成 0.0.0.0 时，部署记录 endpoint 是
http://0.0.0.0:3100，采集器照抄去推 -> connect: connection refused，
而容器/systemd 都是 running、平台 status=active —— 日志静默丢失。
根因
1. 托管方式写死在代码里（promtail 二进制 + systemd 单元），没有能力探测。
2. 没有对外暴露采集器自身日志的接口。
3. 渲染 promtail 配置时直接用 deployment.Endpoint，没有校验它是不是「可连接的推送地址」；
另外容器用 bridge 网络，127.0.0.1 在容器里指向容器自身，同机 Loki 也会推失败。
修法
- services/collector_host_runtime.go（新增）
* detectHostCapabilities：一次 SSH 往返探测 架构/init/systemd/docker可用/开机自启/SELinux/journald
* chooseHostRunMode：docker 优先 -> systemd 兜底 -> 两者都没有则明确报错（不裸跑进程）
* installHostDocker：grafana/promtail:3.4.0 容器，--restart=always --memory=256m --cpus=1
--log-opt max-size=10m,max-file=3，挂 /etc/promtail(:ro) /var/lib/promtail /var/log(:ro)
(+journald 相关)，SELinux Enforcing 时 --security-opt label=disable；
先 docker run --rm -check-syntax 校验配置，再替换正式配置
* waitContainerRunning：看 Status + RestartCount，起来就崩立即报错并带回 docker logs
* hostPushEndpoint：0.0.0.0/:: 换真实主机 IP；容器模式下 127.0.0.1/localhost 也换；
换不了明确报错
* CollectorLogs：主机 docker logs / journalctl，K8s DaemonSet Pod 日志、Sidecar fluent-bit 容器日志
- collector_deployer.go：installHost 探测->选模式->渲染配置->分发；systemd 路径从 docker 迁回时
清理同名容器；卸载时容器与 systemd 两种方式都清（RunMode 对老记录是空的）
- 拉不到镜像（内网无外网）时降级 systemd 二进制托管，其它错误原样抛出
- models/collector.go：新增 runMode 并纳入 Sanitized；services.Update 白名单同步
- 接口 GET /api/v1/collectors/:id/logs?tail=N；前端卡片加「运行方式」+「日志」弹窗
- build.sh：detect_go 的 INFO 走 stderr（原来被打进 GO_CMD，构建必失败）
验证（172.19.16.8 / pre-cex-ops-jenkins，collector id=2）
- 安装后 runMode=docker，容器 Up，RestartPolicy=always，systemd promtail 自动停用
- 推送地址自动纠正为 http://172.19.16.8:3100，Loki 近 10 分钟查到 4919 条
job=system/job=app、host=pre-cex-ops-jenkins
- docker 垫片模拟「docker 不可用」-> 自动回退 runMode=systemd、unit active+enabled、
日志接口 source=systemd；移除垫片重装 -> 切回 docker
- 卸载：容器 0 个、unit 文件不存在、/etc/promtail 不存在、runMode 清空；重装恢复 running/0 重启
- K8s 采集器日志接口 source=kubernetes（顺带暴露 429 限流，见后续日志量治理）
- go vet 干净；go test ./... 全绿（新增 chooseHostRunMode / hostPushEndpoint 等 6 组用例）；
tsc -b 通过
- 镜像 lghost/lokistack:latest = :v0.1 = sha256:906a6d5369d7，Pod imageID 一致
2026-10-28 20:01:38 +00:00
opsx
c983d0e3c1
feat(collectors): 可编辑采集配置（B 档结构化编辑器）+ 修 host 标签 / syslog 时间戳
...
=== 一、两个线上 bug（172.19.16.8 真机取证）===
1) host 标签是字面量 ${HOSTNAME}
Promtail 不做环境变量展开（除非 -config.expand-env + systemd Environment），
实测 21,825 条日志的 host 全是 "${HOSTNAME}"，无法按主机过滤。
→ 安装时 `hostname -s` 探测真实主机名并渲染进配置，结果存 Collector.ResolvedHostname，
让「预览配置」与线上一致。
2) 系统日志时间戳解析失效
TencentOS 4 的 /var/log/messages 是 ISO8601（2026-07-17T15:38:24.923784+08:00），
旧正则按传统 syslog（Oct 28 18:11:06）写死 → timestamp 阶段匹配不上，用的是采集时间，
回填历史日志时间全错。
→ 安装时探测目标机格式：iso8601 → RFC3339Nano；rfc3164 → Jan _2 15:04:05 + Local；
系统日志路径同时探测（Ubuntu 没有 messages，写死会一条都采不到）。
实测：写一条 10 分钟前的 ISO8601 探针行，Loki 里 loki_ts 与该行自身时间偏差 **0 秒**；
另写一条 2 小时前的被 Loki 以 entry too far behind 拒绝 —— 恰好反证时间戳是按事件时间
解析后推送的（旧实现会用采集时间，反而被接收）。
=== 二、B 档：结构化多 Job 编辑器 ===
后端
- models/scrape_job.go：ScrapeJob + ValidateScrapeJobs
校验 job 名格式、绝对路径、**敏感路径拦截**（/etc/shadow、/etc/sudoers、/root/.ssh、
id_rsa、*.pem…）、正则可编译、job/host/__path__ 保留标签名、数量上限。
- services/promtail_host_config.go：多 job 渲染；多路径展开成多个 static_configs；
pipeline 顺序硬约束 cri → multiline → json → timestamp → drop → limit；
encoding 写在 scrape_config 级（放进 static_configs 里 promtail 直接起不来）。
- services/host_profile.go：探测 distro / init / hostname / 时区 / 架构 / journald
与真实存在的系统日志路径。
- CollectorService：renderConfig 实时渲染、PreviewConfig（只渲染不落库）、
Update 支持 scrapeJobs 并校验、安装结果（hostname/syslog 格式/配置快照）落库。
- 新增 POST /api/v1/collectors/:id/preview → {config, warnings, hostname, syslogFormat}。
- installHost：配置先写 .new + `promtail -check-syntax` 通过才替换，重启后轮询
systemctl is-active，失败把 journalctl 尾部带回前端。
前端
- 采集项结构化编辑器：名称/路径/标签常驻，多行合并 / JSON / 自定义时间戳 / 命中丢弃 /
限流折叠在「高级」里；「预览 YAML」弹窗在保存前看到将要下发的配置。
- 本地即时校验 + 旧数据（只有 logPath）自动迁移成 app + system 两个采集项。
=== 三、验证（host-verify-promtail @172.19.16.8）===
- 预览：host=pre-cex-ops-jenkins（无 ${HOSTNAME}），2 job / 3 条系统日志路径 /
ISO8601 正则 / 多行 + drop + 限流 全部按填写渲染。
- 部署：promtail active、NRestarts=0、-check-syntax 通过，主机侧配置与预览逐行一致。
- Loki：新数据 host 全为 pre-cex-ops-jenkins；job=system 415 条/5min、job=app 40 条/5min。
- 负向 7/7 返回指名到字段的 400：/etc/shadow、/root/.ssh/id_rsa、相对路径、坏正则、
job 名带空格、保留标签名、空路径。
镜像：lghost/lokistack:latest + v0.1 = sha256:26172f51187d
2026-10-28 18:41:39 +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
3191af8b6a
feat(logs): 上下文前后条数可配置（默认 2，原来写死 5）+ 每页条数改预设选项
...
=== 一、问题 ===
查看日志上下文时，前后各取几条是**写死**在控制器里的：
span := 5 * time.Minute
QueryLokiLogs(..., ts-span, ts-1, 5, "backward") // 5 条
QueryLokiLogs(..., ts+1, ts+span, 5, "forward") // 5 条
三处写死：条数 5、时间窗 5 分钟、且用户无法调整。
写死的三个实际弊端：
1. 排障时想看更多（比如前后 20 条找调用链）做不到；
2. 只想看紧邻 2 条时，仍然要扫 5 分钟窗口、返回 5 条，浪费；
3. 时间窗与条数不匹配——某服务日志稀疏时，5 分钟窗口里可能一条都没有，
于是"前后各 5 条"实际返回 0 条。
=== 二、改动 ===
1. backend/dto: LogContextRequest 新增 before/after（可选）
2. backend/controllers: normalizeContextLines()
- 不传或 ≤0 → 默认 2 条
- 上限 50 条（防止一次弹窗拉几百条）
- 时间窗改为**按条数自适应**：每条按 30s 估算，最少 1 分钟、最多 2 小时
（不再固定 5 分钟，解决"稀疏服务取不到上下文"的问题）
3. frontend
- 上下文弹窗标题栏加「前后各 [2/5/10/20/50]」选择器，切换后原地重新拉取
- 选择结果写入 localStorage，下次沿用
- 每页条数：数字输入框 → 预设下拉 [100/500/1000/2000/5000]
（原来只能手输且硬顶 1000，现在上限提到 Loki 默认的 5000）
- i18n：去掉"前后各最多 5 条 · 前后 5 分钟"的写死文案
=== 三、实测（平台 API）===
before=2 after=2 → 2 / 2 条
before=5 after=5 → 5 / 5 条
before=10 after=10 → 10 / 10 条
before=50 after=50 → 50 / 50 条
before=999 after=999 → 50 / 50 条（超上限自动收敛）
不传 → 2 / 2 条（默认值生效）
镜像：lghost/lokistack:latest + v0.1 = sha256:d19239fa65f3
2026-10-28 16:14:05 +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
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
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
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
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
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.Li and Claude
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.Li and Claude
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.Li and Claude
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
opsx