opsx
c5739d1a06
feat(alerts): 内置规则默认启用并绑定默认通道,开箱即用
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
- 新种规则 Enabled: true;启动时执行 SeedAlertRules(此前仅部署成功调用,存量环境拿不到升级)
- 存量一次性迁移:内置名单内且从未关联通道的规则补绑默认通道并启用;用户已自配通道的不动
- 管理员只需给「默认告警」通道填 Webhook 并启用;通道未就绪时命中只记发送历史(failed+原因),不影响规则评估
2026-10-29 13:14:05 +08:00
opsx
c08190458f
fix(alerts,db): 清理历史误种的 K8s 基础设施告警规则 + 数据迁移不留档
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
- seed 启动时一次性删除早期版本种入的「Kubernetes 节点 NotReady」「容器 OOMKilled」
(日志平台只关注应用日志,节点/容器状态告警归 Prometheus;源码早已移除该模板,但幂等只跳过不清理,旧库存量一直在)
- 数据文件迁移为 lokistack.json 后直接删除旧文件,不再留 .migrated-*.bak(测试同步)
2026-10-29 13:09:14 +08:00
opsx
cddd60045c
fix(db): 首次加载历史命名数据文件即迁移为 lokistack.json
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
旧回退链(lokistack.json → opsxloki.json → lokideploy.json)会永远沿用旧文件名,
旧品牌残留一直不消;现在首次从旧文件成功加载后立即原子写入 lokistack.json,
旧文件改名 .migrated-*.bak 留档(不删数据),新旧并存或写失败时退回旧路径安全运行。
2026-10-29 13:04:24 +08:00
opsx
4f74fe6c3f
ci(engineering): Gitea Actions 门禁 + 前端测试设施 + 版本注入修复
...
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
- .gitea/workflows/ci.yml:后端 gofmt/vet/test + 前端 lint/test/build 双 job 门禁
- vitest + @testing-library + jsdom 落地,14 个命脉用例:useListQuery 乱序丢弃/卸载中止、
http.ts 401 单飞刷新+队列重放+失败登出+silent 直拒、审计防抖、StepDeploy 部署目标、query-utils
- 版本注入断裂修复:main 补 buildTime/gitCommit 符号,build.sh/Dockerfile 注入 main.version,
/health 返回真实版本,前端 package.json 版本对齐 2.0.0
- gofmt 清零(8 个存量未格式化文件)
2026-10-29 13:02:19 +08:00
opsx
2975452c21
fix(security,data): P0 — 命令注入/停止毁数据/采集路径绕过/DB 清库/前端竞态
...
后端(实机 10.10.10.161 验证 host-binary 全链路 + 注入双路径 400):
- Loki 版本号严格 ^\d+.\d+.\d+$ 校验并接入 Update 路径:version 拼进 SSH shell 命令,
旧校验放行 3.0.0'; id; echo ' 等注入载荷(root RCE)
- Stop/Restart 清理清单移除 PVC:停止部署曾连带删除 loki-data PVC,filesystem 存储日志被永久清空(测试锁死红线)
- 采集敏感路径防护覆盖默认 LogPath 分支与 collector Create(/etc/shadow 不再可绕过入库)
- 数据文件损坏时原文件改名 .corrupt-* 留档再空库启动,不再被静默覆盖(loadFromDisk 抽出可测)
前端:
- 审计页用户名过滤 300ms 防抖 + AbortController/版本号(逐键竞态数据错乱)
- 向导自动部署改用创建返回实例(或 id 最大且 pending),不再盲取 list[0] 对错误实例发起真实部署
- 路由级 ErrorBoundary:单页崩溃/chunk 404 只影响当前页
2026-10-29 13:02:11 +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
7369a17598
feat(alerts): 数据库连接告警覆盖 MySQL/PG/Redis 主流报错；规则表单三字段对齐
...
=== 1. 「数据库连接失败」匹配模式 3 → 25 个 ===
原来只匹配 connection refused / reset by peer / too many connections，
漏掉了 PG 的 FATAL: too many clients、Redis 的 NOAUTH / WRONGPASS /
connection pool timeout 等实际最常见的报错。
按数据库分类补齐：
通用网络层
connection refused / connection reset by peer / broken pipe /
no route to host / cannot assign requested address /
connection timed out / i/o timeout / unexpected EOF /
server closed the connection unexpectedly
MySQL
too many connections / communications link failure /
driver: bad connection / could not create connection /
Access denied for user
PostgreSQL
FATAL: password authentication failed / sorry, too many clients /
terminating connection
Redis
NOAUTH / WRONGPASS / READONLY you can't write against /
CLUSTERDOWN / max number of clients reached
连接池（Java/Go 应用层最先炸的地方）
connection pool / connection is not available
**刻意不加**的（会匹配到几乎所有网络日志，等于没告警）：
裸 "EOF"、"timeout"、"error"、"refused"、"deadlock"
阈值保持 1000/15min（模式变多不代表命中变多，都是真错误才命中）。
迁移 v9→v10 只替换"仍是旧默认查询"的规则，用户自定义过的不动。
=== 2. 规则表单三个字段没对齐 ===
现象：统计窗口(分) / 触发阈值(条) / 冷却(分) 三格并排，
但只有中间的「触发阈值」下方多了一行提示文字，
导致中间那格更高、提示文字悬在底部，看起来像没对齐。
修法：三格统一为「标签 + 输入框 + 一行提示（min-h-4 固定高度）」，
底边自然齐平；提示文案改为：
统计窗口 → 统计最近多少分钟
触发阈值 → 超过该条数才告警
冷却 → 冷却内不重复发送
（顺带把阈值提示从"0 = 出现即告警"改掉：默认阈值已无 0，0 反而是危险配置）
小屏改单列堆叠（grid-cols-1 sm:grid-cols-3）。
=== 实测（936a127b1d15）===
v10 迁移：告警规则 "数据库连接失败" 扩展匹配模式
线上规则：25 个模式，含 NOAUTH / too many clients，阈值 1000，冷却 240m
Pod = latest = v0.1 = 936a127b1d15
2026-10-29 03:56:07 +00:00
opsx
cb1ef1dff4
fix(alerts,analysis): 告警引擎稳定性 5 项修复；每日量接口去掉同步 Loki 查询（20s→10ms）
...
=== 一、告警引擎稳定性审查（引擎本身是异步的：ticker + goroutine）===
1) 【高】ticker 无重叠保护
ticker 每 1 分钟触发；一轮规则检查 8 条 × 20~30s = 2~4 分钟，远超一分钟。
原来每过一分钟就再开一轮 → 查询越堆越多，抢走页面查询的 Loki 资源，
每轮越来越慢，最终表现为"告警不响了"。
→ 新增 alertCheckRunning(atomic.Bool)，上一轮未完成直接跳过本轮并记日志。
2) 【高】单条规则无超时
RunAlertCheck(context.Background()) 没有 deadline：Loki 一旦挂住，整轮永久运行，
叠加问题 1 会让引擎再也不启动新一轮（静默死亡）。
→ 每轮总超时 5 分钟（alertRoundTimeout）+ 单条规则 90s（alertRuleTimeout）。
3) 【中】panic 只在整个 tick 层 recover
一条规则 panic 会让本轮后续规则全部跳过。
→ per-rule recover，panic 记为一条 failed 投递记录，后续规则继续。
4) 【中】冷却记录每分钟写一条，把真实发送记录挤光
AlertDeliveries 只保留最近 50 条，而处于冷却期时每个 tick 都写一条 cooldown，
一小时内真实的"已发送"记录就全被挤掉了，发送历史没法看。
→ recordCooldownThrottled()：同一规则 10 分钟最多写一条。附单测。
5) 规则串行本身保留（避免同时压垮 Loki），但配合 1) 才安全。
=== 二、每日日志量接口：20 秒 → 10 毫秒 ===
根因：GetDailyVolumeHistory 里**同步** await 一次"整天 index/stats"补抓当天数据，
那次查询超时 20s → 整个接口 20s → 前端超时 → 页面显示"每日日志量没数据"；
更糟的是这条重查询还和页面的 histogram/stats 抢 Loki，导致那两个接口同时 502
（访问日志实证：daily-volume latency_ms 20000.997，stats/histogram 502）。
→ 接口改为**只读库**，不触发任何 Loki 查询；当天数据由后台每 30 分钟的
定时任务补（CaptureRecentDailyVolumes）。
→ 同时把整天 index/stats 的超时从 20s 提到 90s（370GB/天，20s 不够）。
实测：10ms。
=== 三、通知通道改名「默认告警」(schemaVersion v8→v9) ===
"lark 默认告警" / "默认通知通道（待配置 Webhook）" → 统一为「默认告警」。
只改名，不动 Webhook、不动 enabled：
首次部署创建的占位通道必须保持「空 Webhook + 禁用」，由管理员自己填，
否则会出现"已启用但空地址"的通道，告警一命中就全部投递失败。
=== 四、其它文案 ===
「每日日志量」副标题精简为「每天的日志总量，平台保留历史趋势」，
并移除「平台留存历史」徽标（用户反馈多余）。
=== 实测（303134c0c718）===
/logs/daily-volume：10ms（原 20000ms）
通道列表：id=1 name="默认告警" enabled=true hasWebhook=true
go test ./... 全绿（含新增 TestRecordCooldownThrottled）
2026-10-29 03:38:30 +00:00
opsx
607b67a2ed
fix(alerts,analysis,dashboard): 阈值再上调 + 告警风暴全局闸门；修 subtitle/门控/饼图 Top5
...
=== 1. 告警阈值第二轮上调（500~5000 这一档仍然太敏感）===
实测业务高峰期这些量级就是常态，阈值贴着基线等于"每天准点报警"：
应用错误激增 50000 → 100000（冷却 120m → 240m）
ingress 5xx 500 → 2000 （冷却 240m）
ingress 4xx 5000 → 20000 （冷却 240m）
数据库连接失败 200 → 1000 （冷却 240m）
迁移 v7→v8，只改"仍等于旧默认值"的规则，用户手动调过的不动。
=== 2. 告警风暴抑制：新增全局闸门 ===
单条规则的 cooldown 只能防"同一条重复"，挡不住"多条规则同时炸"。
实际踩过：一次存储抖动让 8 条内置规则同时命中，10 秒内群里刷了 8 条，
之后大家开始无视这个群 —— 告警疲劳比漏报更难挽回。
新增 overStormLimit()：最近 1 小时内全平台成功发送数 ≥ 12 条时，
后续命中不再发送，只写一条状态为 cooldown 的发送记录并注明
"告警风暴抑制：最近 1 小时已发送 N 条（上限 12）"，可见可追溯。
=== 3. 分析页 subtitle 仍是裸 key ===
中文语言包缺顶层 subtitle（英文包有），i18next 找不到就把 key 原样输出。
补齐：「按应用与命名空间看日志量、错误与趋势，找出最吵的业务」。
=== 4. 分析页三条"没有应用维度的数据"的真正原因 ===
「活跃应用」「应用日志量 Top 5」「应用日志量流图」都依赖 by-app 重查询，
而这条查询被**底部排行卡片的可见性**门控（rankingEnabled: rankingView.inView）——
用户不滚到底就永远不发请求，于是顶部三块永远是空的。
改为进页面就发（两阶段渲染：索引类指标先出，app 维度到货后补）。
懒加载只保留在真正位于底部的「每日日志量」「Ingress 分析」。
=== 5. 饼图改 Top 5 + 文案 ===
用户要求：应用日志量 Top 5 用饼图。TOP_SLICES 8 → 5，
标题改「应用日志量 Top 5」，副标题写明"其余归入其他"。
=== 6. 卡片顺序 ===
「每日日志量」从中间移到「应用排行」之后（更靠底部，慢慢加载）。
=== 7. 仪表盘 ===
整个「平台自检」卡片（含所有指标行）按用户要求移除。
=== 实测（2e8c88817b6a）===
v8 迁移：4 条规则阈值上调，日志齐全
当前阈值：FATAL>10 / panic>10 / OOM>5 / StackOverflow>5 /
应用错误>100000 / ingress 5xx>2000 / 4xx>20000 / DB 连接>1000
冷却：低频规则 120m，高频规则 240m
2026-10-28 23:43:14 +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
bad61e5027
fix(deploy): 删除部署时同步清理自动注册的查询数据源（孤儿数据源）
...
=== 现象（用户实测）===
在 /deployments 页面删掉两个主机模式部署后，本机（172.19.16.8）容器确实清干净了：
docker ps -a 无任何 lokistack-* 容器
/etc/promtail、/var/lib/promtail 等目录均不存在
无 promtail systemd 单元
但**平台里残留一个数据源** host-verify-loki（url=http://172.19.16.8:3100） ，
「日志查询」下拉里还能选到它，选中必然连接失败。
=== 根因 ===
DeploymentService.Delete 只做了两件事：删容器、删部署记录。
部署创建时由 EnsureLogSourceForDeployment 自动注册的托管数据源（Managed=true）
没有任何清理逻辑 —— 删除动作只完成了一半。
=== 修法 ===
1) DeploymentService.Delete 删完记录后调用 CleanupManagedLogSource(部署名)
- 删掉同名且 Managed=true 的数据源（手填的 Managed=false 不动）
- DeleteLogSource 内部会连带删除指向它的查询授权策略组
- 绑定该源的告警规则置为禁用（保留配置便于审计，但不让它每次评估都失败）
- 注意锁顺序：必须先 db.Unlock() 再调用，CleanupManagedLogSource 内部会自己加锁，
持有锁再调用会死锁
2) schemaVersion v6→v7 迁移 removeOrphanManagedLogSources()
清理历史遗留：Managed=true 但没有任何同名部署的数据源 → 删除，
连带删策略组、禁用告警规则
=== 实测（d9487694ece6）===
v7 迁移日志：移除孤儿数据源 "host-verify-loki"(id=2)：对应部署已删除
数据源：1 个（只剩 loki-pre，managed=true）
部署：1 / 采集器：1 / 策略组：1
本机：docker ps -a 无 lokistack-* 容器，/etc/promtail 等目录不存在，无 systemd 单元
2026-10-28 23:18:43 +00:00
opsx
6d6e17745c
fix(logs): 恢复 POST /logs/histogram（直方图 404）+ 系统设置改为侧栏五分页
...
=== 1. 修复 /analysis 与 /logs 直方图 404（我上一轮 patch 的误伤）===
现象：分析页直接报 "API endpoint not found"；日志查询页直方图不显示。
根因：37e2f0f 里一次模糊匹配的 patch 把
logs.POST("/histogram", logsCtrl.Histogram)
改成了
logs.GET("/histogram", logsCtrl.Histogram)
前端 logsApi.histogram 一直用 POST（body 带 sourceId/query/start/end），
于是 POST /logs/histogram 全部 404。访问日志实证：
POST /api/v1/logs/histogram → 404 ×7
这类"方法写错"编译期查不出来，go build / tsc 都是绿的。
修法：同时注册 POST（前端用）与 GET（curl 调试用）。
新增 backend/routers/router_test.go 守门：
TestCriticalRoutes 断言 19 条关键路由的 method+path 组合都存在
TestHistogramAcceptsPost 单独断言 histogram 必须同时有 POST 与 GET
以后再把 POST 写成 GET，测试会直接红。
=== 2. 系统设置放回侧栏，改成 5 个顶层 tab ===
按使用反馈调整：
系统设置（侧栏一个入口）
├ 通用配置 /settings ← tab 起点
├ 用户管理 /users
├ 审计日志 /audit
├ LDAP 接入 /settings/ldap ← 新拆分
└ 默认镜像源 /settings/registry ← 新拆分
为什么拆：原来 /settings 页面内部已有 4 个 tab（通用/告警通知/LDAP/镜像源），
如果侧栏再加一层 tab 就是"两层 tab"，点两下才知道自己在哪。现在扁平化成单层。
配套改动：
- 新增 pages/settings/ldap.tsx、registry.tsx（各自只渲染一块内容）
- settings 主页去掉内层 Tabs，只留通用配置（外观/语言/改密码/关于）
- 上一版把设置放到了右上角齿轮，现在移除齿轮入口
- 菜单文案：settings 页标题 系统设置 → 通用配置；新增 LDAP 接入 / 默认镜像源
- 删除设置页副标题「通用配置、告警通知、LDAP 接入与默认镜像源」（用户要求去掉）
- 删除 settings 里已不存在的 tabs.notify 文案
（注意 settings.notify.* 这些 key 仍被告警页的 NotifySection 用着，保留）
=== 3. 告警通知已不在系统设置里 ===
它在上一轮就搬到了「日志告警 → 通知通道」tab，
本次顺带把系统设置里遗留的 tab 文案一并清掉，避免出现"看似有两处配置入口"。
=== 实测 ===
POST /api/v1/logs/histogram → 200（修复前 404）
go test ./... 全绿（含新增的 routers 包）
tsc -b --force 通过
2026-10-28 23:12:42 +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
fa7ddd67c1
perf(analysis): 分析页按索引/内容分层，告警默认阈值抬高
...
=== 1. 分析页"一直转圈/请求超时(40000ms)"的真实原因 ===
三个问题叠加，逐个量化：
a) 首屏用空 namespace 发查询
页面初始 namespace=''，等策略返回前就发出 `{namespace=~".+"}` 全集群查询，
策略到位后又查一次 → 一次访问跑两遍。
→ 加 namespaceReady 门控：解析完再发（effectiveSourceId）。
b) histogram 索引查询和内容查询抢同一个信号量
/logs/histogram 首选 index/volume_range（毫秒级），但仍要先抢重型令牌，
而令牌被 4 条 count_over_time（各 14~29s）占满 → 排队/429/超时。
→ 索引路径**不再占用重型令牌**（15s 独立超时），只有回退到
count_over_time 时才抢令牌。实测各跨度(15m/1h/6h/24h)均 0s。
c) 重查询条数过多
原来 4 条全局 count_over_time（total/error/warn）+ 2 条 by-app，
串行 1~2 分钟。现在只留 2 条 by-app：
- 全局总量已由 histogram（索引）提供
- 全局 error 由 errByApp 序列求和得出
- 全局 warn 放弃（优先级最低却要 20s）
实测 by-app 单条 26s，两条串行 ~52s；主图 0s 先出。
d) 日报 7 天 count_over_time（2.6TB 扫描）必然失败
→ 改走 /logs/histogram（索引）按自然日聚合，只出"每日总量"，
应用维度交给下方 Top 应用表格（有自己的时间范围）。
实测 7 天跨度毫秒级。
=== 2. 告警默认阈值抬高（告警疲劳治理）===
验证时用 `{namespace="astralx"}` + 阈值 0 触发了一次：
15 分钟命中 3051 万条 —— 阈值 0 等于把告警变成日志流复读机。
新基线（15 分钟窗口，冷却统一 120 分钟）：
致命日志 FATAL 0 → 10
Go panic 0 → 10
JVM OutOfMemoryError 0 → 5
StackOverflowError 0 → 5
应用错误激增 1000 → 50000（改名，原"error > 1000"名不副实）
ingress-nginx 5xx 100 → 500
ingress-nginx 4xx 1000 → 5000
数据库连接失败 50 → 200
迁移只改"仍等于旧默认值"的规则，用户手动调过的阈值不动。
设计原则写进 seed 注释：绝不用 threshold 0；宁可少报也不要让人对告警脱敏；
绝对阈值不跨环境通用，大集群必须按 app/namespace 收窄。
=== 实测（v6-1028-2218 / 0bf66199de66）===
规则 8 条，阈值=0 的规则数 0，冷却全部 120m
histogram astralx（15m/1h/6h/24h）: 0s
by-app metrics astralx 15m: 26s，正常返回数据
2026-10-28 22:20:19 +00:00
opsx
95dcd9408c
fix(logs,analysis,alerts): 数据源不可达、分析页超时、告警规则混入基础设施项
...
=== 1. 主机模式数据源地址 0.0.0.0 → 主机真实 IP（查询页"永远加载中"的根因）===
现象：切换数据源后命名空间/App 下拉不动，一直显示"加载中…"，控制台报
Get "http://0.0.0.0:3100/loki/api/v1/labels ": dial tcp 0.0.0.0:3100: connect: connection refused
根因：主机模式部署的 endpoint 记的是**容器监听地址** 0.0.0.0:3100，
而平台进程不在被采集主机上，0.0.0.0 只在本机有意义。
EnsureLogSourceForDeployment 把它原样写成了数据源 URL。
修法：
- 新增 reachableEndpoint()：把 0.0.0.0 / [::] 换成关联主机的真实 IP
- schemaVersion v3→v4 迁移 fixUnreachableLogSourceURLs()，修正已有脏数据
- 实测：http://0.0.0.0:3100 → http://172.19.16.8:3100，该源 label 查询由 502 变 200
=== 2. 前端：区分"加载中"与"加载失败" ===
原来用 `loading={!options.length}` 表示加载中 —— 数据源不可达时列表永远为空，
于是界面永远转圈，把真实错误完全藏起来了（这次的 0.0.0.0 就是这样被掩盖的）。
改为独立的 namespaceLoading / namespaceError 两个状态：
- 切换数据源先清空旧 options（否则显示上一个源的命名空间，看着像"没反应"）
- 失败显示"加载失败"并在旁边给「重试」按钮，不用刷新整页
=== 3. 日志分析页：主图改走索引接口（原来 5 条 count_over_time 全超时）===
实测 astralx（约 370GB/天）15 分钟窗口：
count_over_time → exec 29s + 排队 95s，超过 30s 护栏 → 502
index/volume_range → 0s
改为两阶段渲染：
- 总量趋势改用 /logs/histogram（内部 index/volume_range），**0s 出图**
- 错误/警告/app 维度仍需读日志内容，串行执行，先渲染主图再更新
- heavyQueryTimeout 30s → 90s（实测 error 维度查询 14s 可完成）
=== 4. 告警规则按日志平台定位收敛 ===
- seed 里删掉「Kubernetes 节点 NotReady」「容器 OOMKilled」：
这类属于 kube-state-metrics / Prometheus 的职责，用日志字符串匹配不可靠
- 迁移里清掉线上已存在的同类规则（3 条）
- 修 AlertRule / NotifyChannel 重复 ID（同 logSources 一样漏在 sequences 重建外）
=== 5. 告警页 UI ===
- 规则列表由"每条一张卡"改为紧凑表格（一屏看全，阈值可对齐比较）
- 通知通道（飞书/Lark/Webhook）从「系统设置」搬到告警页折叠区：
规则和"发到哪"是一件事的两半，分两页配容易漏配导致告警发不出去
=== 6. 权限收敛 ===
- /alerts 加 adminOnly：普通用户按查询授权只看「日志查询」，不再看到告警菜单
- 系统设置从侧栏移到右上角齿轮（低频平台配置，不占侧栏一位）
=== 7. 迁移设计教训（写进代码注释）===
v2 时把"告警去重 + 清基础设施规则"塞进 case 1，但线上库已到 v2，
那段代码永远不执行。**结构变更只要逻辑变了、目标库已达该版本，就必须再抬一版**，
不能改历史迁移分支。
=== 实测（v4-1028-2210 / 979bdb4a48e8）===
v4 迁移：数据源 URL 修正 http://0.0.0.0:3100 → http://172.19.16.8:3100
source 1 label：200，0s（astralx / log）
source 2 label：200，0s（不再 connection refused）
分析页 histogram astralx 15m：0s
分析页 metrics error astralx 15m：14s
告警规则：10 条（已无基础设施类）、ID 唯一
另清理 172.19.16.8 上 13 个残留容器，回收 6.1GB
2026-10-28 22:11:48 +00:00
opsx
1a4c75e28c
feat(menu): 日志查询/日志分析拆为独立菜单 + 部署菜单改名「组件部署」
...
按使用反馈调整信息架构：
=== 1. 日志查询、日志分析保持独立菜单（不折叠）===
上一版把两者并进「日志」分组，实际使用中不方便：
- 日志查询是最高频入口，不该多点一次 tab 才到
- 日志分析是管理员专用的聚合视图，与查询的心智模型不同
改为两个独立菜单项，/logs 的菜单名保持「日志查询」不变（用户明确要求），
/analysis 保留 adminOnly（仅管理员可见）。
=== 2. /deployments 菜单改名：部署 Loki → 组件部署 ===
命名评估（三个候选）：
组件部署 ✅ 选中：部署对象是基础设施组件（Loki 实例），
与本环境大量 cex-* 业务服务明确区分。
运维在侧栏看到「服务部署」第一反应会是"发布业务服务"，容易误点。
服务部署 ✗ 与业务服务语义冲突
部署 Loki ✗ 以后支持多组件（Fluent Bit / Grafana）就名不副实
文案改动：菜单 menu.deployments、页面标题、组内 tab 全部统一为「组件部署」，
en 同步为 Component Deploy / Component Deploy 页面标题。
=== 3. 顺带修：启动日志每次都打印「首次部署」===
旧实现无条件打印
log.Printf("首次部署请查看启动日志或 %s/initial-admin-password.txt ...")
于是每次重启日志里都有「首次部署」，排查时极易被误导成
"平台重新初始化了、数据是不是丢了"（本次就因此自查了一轮）。
改为仅当密码文件存在时才提示（admin 改密后该文件会被删除）。
=== 当前菜单结构（8 项）===
仪表盘 / 部署向导 / 资源接入(集群·主机·存储) / 日志服务(组件部署·日志采集)
/ 日志查询 / 日志分析(admin) / 日志告警 / 系统管理(用户·审计·设置)
=== 实测 ===
bundle 文案：组件部署1 日志查询2 日志分析2 资源接入1 日志服务1 系统管理1
启动日志「首次部署」出现次数：0
CLI self-check：overall=ok（数据库 54.7 KB，CLI 模式读取）
CLI backup：记录数 88（修复前为 0）、密钥指纹 d714ebda23908331
镜像：lghost/lokistack:latest + v0.1 = aa6313fee5bb
2026-10-28 21:44:15 +00:00
opsx
b2c82da377
fix(audit): inferAuditFields 下标越界导致进程级 panic（4 段路径全部 500）
...
=== 现象（线上实际日志）===
http: panic serving 172.19.16.138:35256: runtime error: index out of range [4] with length 4
lokistack/middleware.inferAuditFields(...)
lokistack/middleware/audit.go:179
=== 根因 ===
segments := strings.Split(strings.Trim(path, "/"), "/")
if len(segments) >= 4 {
resource = segments[3]
resourceID = segments[4] // ← 4 段时越界
}
/api/v1/hosts/2 正好拆成 4 段 [api v1 hosts 2]，取 segments[4] 直接 panic。
影响面比想象大：**所有 4 段路径的写请求**（PUT/DELETE /hosts/:id、
/storage/:id、/clusters/:id 等）都 500，且中间件 panic 后审计也写不进去
—— 等于审计功能在最常用的更新/删除接口上完全失效。
=== 修法 ===
每个下标单独判断长度：
if len(segments) >= 3 { module = segments[2] }
if len(segments) >= 4 { resource = segments[3] }
if len(segments) >= 5 { resourceID = segments[4] }
=== 回归测试（middleware/audit_test.go）===
TestInferAuditFieldsNoPanic : 0/1/2/3/4/5 段的 12 种路径 × 3 种方法，
全部不得 panic（原 bug 的 4 段路径在列）
TestInferAuditFieldsFourSegments : 4 段时 module/resource 正确、resourceID 为空
TestInferAuditFieldsFiveSegments : 5 段时能解出 resourceID
TestInferAuditFieldsSemanticActions: deploy/stop/install/uninstall/reset-password/
validate/test 语义动作不被位置解析覆盖
TestShouldAudit : 只读接口跳过、部署安装类必须记
=== 顺带修：CLI 模式下的两处误报 ===
1) backup 的 manifest.recordCount 恒为 0
原因：CLI（CronJob 里跑 lokistack backup）没 init DB，GetDB() 返回 nil。
改为 countRecords() 直接从备份出的字节数集合。
2) self-check 报「数据库: 未初始化」
同上原因，误报会让巡检脚本以为库坏了。
改为 CLI 模式直接解析数据文件统计（fileDBStats）。
=== 实测（修复后）===
修复前：POST /api/v1/hosts/2/validate → panic，无审计记录
修复后：POST /api/v1/hosts/2/validate → 200
audit-logs total=5，含
[hosts/validate] admin POST /api/v1/hosts/2/validate -> 200
[auth/login] POST /api/v1/auth/login -> 200
panic serving 计数 = 0
用户数据完好（initial-admin-password.txt 不存在，说明不是首次部署）
镜像：lghost/lokistack:latest + v0.1 = 2493a288758d
2026-10-28 21:40:24 +00:00
opsx
c44ffad61f
fix(metrics): duplicate metrics collector registration panic（线上 CrashLoopBackOff）
...
=== 现象 ===
上一提交 b49677f
2026-10-28 21:32:36 +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
opsx
f6af12a731
fix(collectors): 容器模式首次安装日志全被 Loki 拒绝（entry too far behind）
...
=== 现象 ===
容器化采集器（docker 优先托管）上线后实测：10 分钟只进 47 条，
容器日志刷满：
msg="final error sending batch" status=400
error="entry too far behind, entry timestamp is: 2026-10-21T20:01:16Z,
oldest acceptable timestamp is: 2026-10-28T19:..."
=== 根因 ===
Promtail 在 positions 里没有某文件记录时，会从**文件开头**开始读。
主机 /var/log/messages 有 7 天历史（约 1.35 亿字节），而 Loki 只接受最近
reject_old_samples_max_age（默认 1h）的条目。
关键危害：promtail 把新旧日志混在**同一个 batch** 里推送 → 整批 400 被拒，
**连新日志也发不出去**，不只是丢历史。
systemd 模式此前看着正常，只是因为跑了很久、positions 已建立；
全新主机（或容器换了数据目录、positions 为空）必然复现。
=== 修复 ===
安装时（容器与 systemd 两条路径都加）预置 positions 到文件末尾：
- 只补 positions 里【还没有】的路径 → 重装/升级不破坏已有进度、不重复采集
- 偏移用 stat -c %s 取当前文件大小
- 路径来源：系统日志探测结果 ∪ logPath ∪ 每个 ScrapeJob 的 paths
新增 services/promtail_positions.go：
seedPositionsCmd(patterns) → 生成预置脚本
collectorPositionPatterns(c, sys) → 汇总该采集器涉及的所有路径
预置失败只 warn 不阻断启动（不影响老环境升级）。
=== 实测（172.19.16.8 / TencentOS 4）===
修复前：final error 持续刷、400 持续、10 分钟 47 条
修复后：final error 0 次、400 0 次、restarts=0
positions 已预置（cron=71042092 / cloud-init=286805 …）
日志正常入库 295 条/15 分钟（真实新增速率，不再回填历史）
时间戳与源文件一致：20:27:01.314716+00:00 CROND[1445228]
测试：TestSeedPositionsCmd / TestCollectorPositionPatterns 通过
镜像：lghost/lokistack:latest + v0.1 = sha256:d5dd05dca465
2026-10-28 20:27:48 +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
55d6a74eb3
fix(collectors): 主机采集器从未真正运行过 —— systemd 用了 Promtail 3.x 已删除的参数
...
=== 一、端到端验证发现的两个阻断性问题 ===
在 172.19.16.8 上真实部署（host-docker Loki + host-promtail）验证：
1) systemd unit 的 ExecStart 带 `-positions.enabled=true`
Promtail 3.x 已删除该参数 → 启动即退出(status=2)，restart counter 一路涨到 65：
flag provided but not defined: -positions.enabled
也就是说：**主机模式的采集器此前从未真正跑起来过**。
→ 移除该参数（positions 由 YAML 配置，不需要这个 flag）。
2) 安装后不校验服务真实状态
`systemctl restart` 对"启动即崩"的服务同样返回 0（只是排队拉起），
平台据此把"崩溃重启中"报成 status=active / 采集器已部署，用户完全看不出问题。
→ 新增 waitServiceActive()：轮询 systemctl is-active 最多 20s，
失败时返回错误并把 journalctl/日志尾部带回前端。
=== 二、验证结果（修复后）===
Loki 主机模式：容器 lokistack-loki-2 Up，/ready=ready，labels 正常
Promtail：active，监听 9080，ExecStart 已去掉非法参数
系统日志：job=system 17,513 条/10min（/var/log/{messages,secure,cron,...}）
应用日志：job=app 4,311 条/10min（/var/log/*.log）
样本：pre-cex-ops-jenkins systemd[1]: Started promtail.service ...
=== 三、验证中另外发现、待修的两点（下一轮）===
- host 标签是字面量 "${HOSTNAME}"：Promtail 不做环境变量展开
（需 -config.expand-env + systemd Environment，或生成配置时直接写真实主机名）
→ 21,825 条日志的 host 全是 ${HOSTNAME}，无法按主机过滤
- 系统日志时间戳解析失效：TencentOS 4 的 /var/log/messages 是 ISO8601
（2026-07-17T15:38:24.923784+08:00），当前按传统 syslog（Oct 28 18:11:06）
写的正则匹配不上 → timestamp 阶段不生效，用的是采集时间（回填历史会错）
→ 计划安装时探测首行格式，自动选择 ISO8601 / 传统 syslog 解析
镜像：lghost/lokistack:latest + v0.1 = sha256:6268d534b20a
2026-10-28 18:11:41 +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
a32f93f533
feat(deployments,analysis): 保留弹框重设计 + 分析页命名空间筛选 + 过期 chunk 真正删除
...
=== 一、保留策略弹框重设计（RetentionDialog）===
旧版问题：
1. 主输入是 YAML textarea，用户必须会写 `limits_config.retention_period: 30d`
2. 三个按钮：取消 / 仅保存 / 保存并应用 —— 「仅保存」只改部署记录不重载 Loki，
今天已经造成一次真实故障：DB 记录 7 天、运行时 ConfigMap 是 24h，配置漂移
3. 「查看完整配置」是独立按钮 + 独立状态，多一次点击
4. 硬编码提示 `retention_delete_delay: 2h`，而实际已改成 10m，属于误导
新版：
- 主输入改为**保留天数数字框**（1–3650），YAML 由前端拼，用户不用写
- 快捷预设 1/7/14/30/90，实时显示「= 720 小时」
- >7 天给出存储成本提示
- 完整运行 config 改成 `<details>` 折叠，展开即自动加载（去掉独立按钮）
- **按钮只剩 2 个：取消 / 保存并应用**
- 删掉硬编码的 compactor 提示块
=== 二、日志分析页加命名空间筛选 ===
根因：analysis 页写死 namespace: ''，等价 `{namespace=~".+"}` —— 一次分析扫全集群
（实测约 370 GB/天），5 条 count_over_time 跑 30s 都出不来，页面永远转圈。
- 新增命名空间下拉（从 Loki label values 拉取，localStorage 记忆）
- 默认取业务命名空间 astralx（其次列表首个），不再默认全集群
- 「全部命名空间（较慢）」降级为显式选项
- 命名空间未就绪时先显示 loading，避免先发一次全集群查询
- 5 条查询改**分批（每批 2 条）**执行 + 429 自动重试一次
=== 三、后端并发/超时调整 ===
- 重查询并发上限 2 → 4，且拿不到令牌时**排队最多 10s**再拒绝
（原来立即 429，导致分析页 5 条并发里有 3 条直接失败）
- maxLogQueryLimit 1000 → 5000，与前端下拉完全对齐（原来前端选 5000 会被静默截断）
=== 四、过期 chunk 真正删除（关键修复）===
实测发现：索引表已从 COS 删除，但 chunk 对象仍残留 21,354 个 / 24.8 GB，
最老的 45 小时前 —— 因为 Loki 默认 `retention_delete_delay` = **2h**，
标记后要等 2 小时才真正删 chunk。
- 配置显式设置 `compactor.retention_delete_delay: 10m`
- 已用 `loki -verify-config` 校验（config is valid）
- 删除前后对比：
对象数 46,536 → 23,934；占用 53.61 GB → 27.25 GB
超期对象 21,354 个 / 24.8 GB → **0 个**
桶内最老对象 45.2h → 24.4h（= 保留期 1 天）
- deployment_config_test 同步调整：retention_delete_delay 从"禁止出现"移入"必须存在"
镜像：lghost/lokistack:latest + v0.1 = sha256:b4d98e016bca
2026-10-28 17:05:57 +00:00
opsx
6364a70215
tune(logs): 每页条数默认 1000→200，上下文默认 5 条（依据实测数据）
...
=== 一、每页条数：1000 太多，实测依据 ===
1. 每次查询响应体 671 B/条 → 1000 条 = **655 KB**
2. 前端结果表**没有虚拟滚动**（无 react-window / tanstack virtual），
1000 行会全部渲染成 DOM 节点 → 滚动卡顿
3. 后端 maxLogQueryLimit 本来就是 1000，我上一版 UI 给了 2000/5000 选项
是"假选项"（会被静默收敛成 1000），本次去掉
4. 密度参考：cex-ipublic-gateway 每天 3.28 亿条 ≈ **3800 条/秒**，
1000 条只覆盖 0.26 秒 —— 靠翻页浏览无意义，应靠时间范围/LogQL 收窄
调整：默认 1000 → **200**（后端自身默认值，约 131KB）；选项 [100/200/500/1000]
提示文案改为"日志量大时先收窄时间范围或加过滤，比调大每页条数更有效"
=== 二、上下文档数：1 条不够，默认用 5 ===
实测一个 SpringBoot 异常被拆成 **4 条独立日志**：
16:15:35.259 [reactor-http-epoll-3] ERROR ...AbstractErrorWebExceptionHandler
org.springframework.web.reactive.resource.NoResourceFoundException: 404 NOT_FOUND
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
*__checkpoint ⇢ HTTP HEAD "/" [ExceptionHandlingWebHandler]
→ 前后各 1 条（共 2 条）连一个完整异常都拼不出来
→ 前后各 5 条（共 10 条）能看到"异常 + 前后业务日志"，是排障的最小可用集
→ 完整 Java 堆栈（20+ 帧）需要 20-50 条
调整：默认 2 → **5**；选项增加 1 → [1/2/5/10/20/50]
镜像：lghost/lokistack:latest + v0.1 = sha256:2bcc86b8e30d
2026-10-28 16:18:48 +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
9acc15f4d2
test(loki): 修正 delete_request_store 断言——两个测试互相矛盾导致 go test 必失败
...
现象：`go test ./services/` 在 HEAD（3a8eb52）上稳定失败
--- FAIL: TestGeneratedLokiConfigKeepsRequiredSettingsWithoutDefaults
deployment_config_test.go:68: required setting "delete_request_store: s3" missing
根因不是代码 bug，而是**两个测试对同一件事的期望相反**：
backend/services/deployment_config_test.go:66 断言 delete_request_store: s3
backend/services/loki_object_store_test.go:44 断言 delete_request_store: filesystem
而 loki_config.go 对 s3/oss/minio/cos/obs 是**刻意**用 filesystem 的
（commit 9f7c522
2026-10-28 15:00:30 +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
7b600f7eee
feat(log): Gin 结构化 JSON 访问日志 + 生产默认 release 模式（去掉启动路由 dump）
...
=== 一、结构化 JSON 访问日志（middleware/accesslog.go）===
gin.Default() → gin.New() + AccessLog() + gin.Recovery()
- 一行一个 JSON：ts/level/type/method/path/status/latency_ms/bytes/ip/ua
- 自动分级：5xx=error / 4xx=warn / 其余=info
- jwt 中间件写入的 userId/username 一并输出，便于审计
- 健康检查与 /assets 静音（探针每 10s 一次会淹没真实请求）
- Recovery 显式加回（gin.Default 里包含它）
⚠️ Go map 序列化按 key 字母序，ts 会排到最后 → LogJSON 手工拼装，
把 ts/level/type/msg 固定在最前，其余排序输出。
=== 二、生产默认 release 模式 ===
代码里此前**完全没有 gin.SetMode**，一直跑在 debug：
- 每次启动 dump 100+ 行路由表（[GIN-debug] GET /api/v1/...）
- 每请求有额外开销，且把完整路由暴露在日志里
现在：GIN_MODE 未显式设置且 DEBUG!=true 时自动 SetMode(ReleaseMode)，
需要调试仍可用 DEBUG=true 或 GIN_MODE=debug 覆盖。
=== 三、实测 ===
GIN-debug 路由 dump 行数: 0 ✅ （修复前 100+）
JSON 访问日志:
{"ts":"2026-10-27T14:49:28.53Z","level":"info","type":"access","bytes":828,
"ip":"172.19.16.92","latency_ms":173.5,"method":"POST",
"path":"/api/v1/auth/login","status":200,"ua":"curl/8.4.0"} ✅
带用户信息: ...,"user_id":1,"username":"admin" ✅
health 日志行数: 0 ✅
总日志 15 行 / JSON 7 行 / 非 JSON 8 行（全部是启动日志）
health ok、Promtail 12/12、lokistack 1/1 ✅
镜像：lghost/lokistack:latest + v0.1 = sha256:8b25b0a29efa
2026-10-27 14:49:45 +00:00
opsx
02705382f1
fix(collector): Sanitized() 漏掉采集范围三字段，导致编辑框读不到配置
...
背景：基于 f3733f0（品牌统一 + i18n 重构）构建部署后发现，采集器 API
返回里完全没有了 targetNamespaces / appLabelSource / appInclude 三个键。
根因：重构引入了 models.SanitizedJSON() + Collector.Sanitized()，
后者是**白名单式** map 输出，写的时候这三个字段还不存在，重构时也没补进去。
controller 全部走 SanitizedJSON(collector)，所以这三个字段被静默丢弃。
影响（比"少显示几个字段"严重）：
编辑采集策略弹框读 collector.targetNamespaces 为 undefined
→ 命名空间面板显示"全集群采集"（实际配的是 astralx+log）
→ 用户只要点一次保存，就会把 targetNamespaces 写成 []
→ 下次「部署」生成的 Promtail 白名单消失，开始全集群采集（日志量暴涨）
appLabelSource / appInclude 同理。
修复：Collector.Sanitized() 补三个字段。
验证：
GET /api/v1/collectors/1
targetNamespaces = ['astralx', 'log'] ← 修复前该键不存在
appLabelSource = ''
appInclude = null
三个键均存在 ✅
Promtail DaemonSet 12/12 未受影响 ✅
Promtail ConfigMap 白名单（astralx, log）、app 四级回退、pod_phase drop 全部保留 ✅
镜像：lghost/lokistack:latest + v0.1 = sha256:648316ae13c5
2026-10-27 10:30:21 +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
02d1bd87a7
fix(promtail): 修 Sprintf 缺参导致清单非法 + Ingress 模板固定命名空间 + 资源名去 opsxloki
...
=== 一、致命 bug：Promtail 清单第 10 个 %s 缺参数（导致日志采集中断）===
go vet 报："format %s reads arg #10 , but call has 9 args"。
模板里 DaemonSet 的 `namespace: %s`（第 9 个）和 `image: %s`（第 10 个）
是两个独立占位符，但 Sprintf 只传了 9 个参数，第 10 个变成 %!s(MISSING)，
整个多文档 YAML 解析失败：
"解析 Kubernetes YAML: yaml: line 23: found character that cannot start any token"
而 installDaemonset 是「先删 daemonset/configmap/serviceaccount 再 apply」，
所以每次失败都会把上一份 Promtail 删掉却不重建 → 日志采集中断。
修复：
1) Sprintf 补上 DaemonSet 命名空间参数（第 9 位）
2) 新增 validateManifest()：在删旧资源之前先本地解析校验清单，
校验不过直接中止、不碰任何现有资源 —— 让模板错误永远不会再打断采集
3) 新增回归测试 promtail_manifest_test.go：用平台同一套
YAMLOrJSONDecoder 解析 3 种参数组合，断言各解析出 5 个对象且无 TAB
=== 二、快捷 LogQL：Ingress 访问日志不再跟随所选命名空间 ===
原实现：next = applyLabelFilter(next,'namespace', namespace.trim() || 'ingress-nginx')
→ 选了 monitor 就生成 {namespace="monitor"} |= "HTTP/"，查不到任何日志
（ingress controller 的 Pod 只在 ingress-nginx 命名空间里）
修复：ingress 模板独立处理
- 固定用 ingress controller 命名空间（ingress-nginx，缺失则回退 ingress）
- 不叠加当前选中的 app / pod 过滤（那些属于业务服务）
- 结果是 {namespace="ingress-nginx"} |= "HTTP/"
=== 三、K8s 资源名去掉 opsxloki ===
ClusterRole / ClusterRoleBinding：opsxloki-promtail → loki-promtail
- PromtailDaemonsetYAML 里 3 处 name 全部改名
- uninstallDaemonset 同步改名，并保留对旧名 opsxloki-promtail 的兼容清理，
避免升级后留下孤儿 ClusterRole
- 集群侧已实测：新建 loki-promtail，旧的 opsxloki-promtail 已删除
保留的 opsxloki（有兼容性约束，改动会丢数据/掉登录）：
- Go module 导入路径 opsxloki/xxx（149 处，纯内部包名）
- 数据文件 opsxloki.json（改了读不到历史数据）
- 前端 localStorage key opsxloki.auth.* / opsxloki.theme.* 等（改了在线用户掉登录）
- Dockerfile 里的 opsxloki 系统用户/二进制名
镜像：lghost/lokistack:latest + v0.1 = sha256:4a5590580cbb
2026-10-27 04:16:55 +00:00
opsx
41633f0b38
feat(collector): 采集命名空间多选 + app 标签来源可自定义 + app 白名单
...
=== 一、采集命名空间改为多选（原来只有文本输入）===
- CollectorEditDialog 重写：勾选式多选面板，从
GET /clusters/:id/namespaces 拉取真实命名空间列表
- "所有命名空间（全集群采集）"一键全选（targetNamespaces 置空即全集群）
- 支持搜索过滤命名空间；已选数量实时显示
- 保存时为空数组 → Promtail 不加 namespaces 白名单
=== 二、app 标签取值来源可配置 ===
新增 Collector.AppLabelSource：
留空（默认）= app.kubernetes.io/name → app → controller 名(去hash) → pod 名 四级回退
可填任意 Pod 标签，如 app.kubernetes.io/name / app / k8s.kuboard.cn/name
也可直接写 __meta_kubernetes_pod_label_xxx
→ 作为最高优先级插到回退链最前，其余仍兜底
模板侧新增：
sanitizePromLabel() 标签名 → Prometheus meta label（. / 等转 _）
promtailAppSourceLabel() 解析用户配置
promtailAppIncludeFilter() 生成白名单 keep 规则
=== 三、app 白名单（控制采集量）===
新增 Collector.AppInclude []string：
填了之后生成
- source_labels: [app]
regex: ^(app1|app2)$
action: keep
只保留匹配的日志流 —— 这是收敛日志量最直接的手段
service.Update 同步支持 appLabelSource / appInclude（兼容 []string 与逗号分隔字符串）。
前端 CollectorEditDialog：
采集命名空间 = 勾选多选 + 全选
app 标签取值来源 = 输入框 + 5 个常用值 datalist 提示
只采集这些 app = 逗号分隔输入
镜像：lghost/lokistack:latest + v0.1 = sha256:43369d06cb28
2026-10-27 03:55:13 +00: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
188d9460fe
fix(logs): 「所有人」策略组无法新建（被误判为已属于其他策略组）
...
现象：userIds:[0] 新建策略组时报
「用户 0 已属于此数据源的另一个策略组」HTTP 400
根因：validatePolicyGroup 的跨组冲突检查把 EveryoneUserID(0) 当真实用户，
只要已有任何一个「所有人」策略组（如内置默认策略），
再新建含 0 的组必然冲突。
修复：跨组冲突检查跳过 AnyoneUserID(0) —— 它是哨兵值不是真实用户，
允许多个策略组同时包含「所有人」。
验证：
POST /logs/policy-groups {userIds:[0]} → 200，id=2 正常创建
POST userIds:[0,2]（混选） → 400「「所有人」不能与具体用户同时选择」
GET /logs/policy-groups → 默认策略（所有人 · default 命名空间）
镜像：lghost/lokistack:latest + v0.1 = sha256:3222a8716fdd
2026-10-27 03:02:50 +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
4dda6e5ba8
fix(logs): 快捷 LogQL null 崩溃 + app 标签错位 + 查询授权「所有人」与默认策略
...
=== 一、快捷 LogQL 报 Cannot read properties of null (reading 'map') ===
根因：Loki 对无值的 label 返回 {"data":null}，Go nil slice 序列化成 JSON null，
前端 setState(null) 后再 .map() / [...null] / .filter() 直接抛错。
表现为「不稳定」——切到某个没有该 label 值的范围就崩。
修复（前后端双保险）：
后端 LokiLabels / LokiLabelValues 归一化 nil → []string{}
（LokiHistogram 原本就返回空切片，无需改）
前端 6 处调用点加 Array.isArray 防御：
QuickQueryTemplates ×3、QueryInput ×2、LokiLabelBrowser ×2
=== 二、选 astralx 只显示 2 个 app（不是权限问题）===
实测：
astralx 117 个 Deployment / 497 个 Pod
带 app 标签的 Pod 只有 2 个（cex-promotion-web / cex-web-h5）
其余 115 个 Deployment 的 Pod 模板没打 app，Kuboard 打的是 k8s.kuboard.cn/name
Loki 里 service_name / container 各有 79 个值（Promtail 从容器名生成）
修复：QuickQueryTemplates 的「app」候选改为三级回退 app → service_name → container，
并用 appLabel 状态记住实际生效的标签名，pod 收窄与 generate() 都用它，
保证生成的 LogQL selector 真能查到数据。
=== 三、查询授权：支持「所有人」+ 内置默认策略 ===
1. 后端 policyGroupAccess：userIds 里的 0 作为哨兵值表示「所有人」(anyone / *)，
匹配任意用户（原来只能逐个指定用户 ID）
2. 种子 seedDefaultPolicy()：首次启动且尚无任何策略组时，创建
「默认策略（所有人 · default 命名空间）」（labels: namespace=default，userIds: [0]）。
管理员可在「查询授权」里把命名空间改成实际业务命名空间（如 astralx），
对该组所有用户立即生效。
3. 前端 PolicyGroupsPage：新增「所有人（anyone）」一键按钮（与具体用户互斥），
列表与编辑区显示「所有人」，校验文案同步更新。
验证：
GET /logs/label/nonexistent_xyz/values → {"data":[]}
GET /logs/label/service_name/values?query={namespace="astralx"} → 79 个
GET /logs/policy-groups → 1 条：默认策略（所有人 · default 命名空间）所有人
镜像：lghost/lokistack:latest + v0.1 = sha256:88a4ba626f62
2026-10-27 01:19:06 +00:00
opsx
46e73d3d17
fix(loki): COS 存储全链路修复 —— Secret 生成/env 注入/凭据解密/endpoint 规范化
...
API 端到端跑通中暴露 4 个串联问题（腾讯云 COS + K8s 场景）：
1. loki_manifest.go: switch 缺少 cos / obs
→ 不生成 loki-storage-credentials Secret、不注入 LOKI_STORAGE_* 环境变量、
也不给 Loki 加 -config.expand-env=true
→ 配置里 ${LOKI_STORAGE_ACCESS_KEY} 无法展开 → AK 为空
→ COS 返回 403 InvalidAccessKeyId（ruler 每分钟报错）
修复：case 补上 cos / obs
2. loki_manifest.go: 生成 Secret 时用了 ENC: 密文原始值
→ Secret data 里是 ENC:xxx 而非真实 AK/SK
修复：crypto.DecryptField 解密后再 base64
3. loki_config.go: host-docker 模式同样把密文写进配置
修复：解密后返回
4. loki_config.go: cos/oss/obs 的 endpoint 未剥离桶名前缀
→ 用户填虚拟主机式 endpoint（mybucket-1250000000.cos.<region>...）时，
Loki 的 S3 客户端又拼一次 bucketnames，变成 <bucket>.<bucket>.cos...
→ TLS 证书校验失败（x509: certificate is valid for ... not <bucket>.<bucket>.cos...）
修复：新增 stripBucketPrefix，s3/cos/oss/obs/minio 分支统一剥离桶名前缀
验证（log namespace，API 端到端）：
- Loki statefulset 1/1 Running，ruler 无 InvalidAccessKeyId/x509
- 写入 + 查询日志成功（持久化到 COS）
- Promtail DaemonSet 12/12 全节点就绪
- collector status=active
运维侧附加动作（非代码，见部署文档）：
- 存储配置改用有效 AK/SK + 区域端点 cos.ap-hongkong.myqcloud.com
- 平台 ServiceAccount log:lokistack 绑定 cluster-admin
（否则无法创建 Promtail 所需的 ClusterRole/ClusterRoleBinding）
2026-10-26 19:32:38 +00:00
opsx
004375e0ce
fix(ns): 命名空间固定 log —— 平台/Loki 实例/Promtail 全部收敛到 log
...
按需求：所有 lokistack 相关资源（管理平台副本、Loki 实例、Promtail 采集器）
固定使用 log 命名空间，不提供覆盖开关。
改动：
1. 后端 services/deployment.go Create()：k8s-yaml 模式下 namespace 为空时
兜底为 "log"，前端漏传也不会跑偏。
2. 前端 DeploymentCard.tsx：命名空间展示 fallback 'loki' → 'log'
3. 前端 DeploymentFormDialog.tsx：输入框 placeholder 'loki' → 'log'
（form-schema.ts 的 DEFAULT_VALUES.namespace 原本已是 'log'）
未动：
kubernetes/install.sh 的 NS="log" 早就是固定值
collector_deployer.go 已自动跟随 loki.Namespace（collector.Namespace 为空时）
资源名不冲突：
平台 lokistack / lokistack-data / lokistack-secrets / lokistack-nodeport
Loki 实例 loki / loki-config / loki-data / loki-headless / loki-storage-credentials
Promtail promtail-* (DaemonSet)
镜像：lghost/lokistack:latest + v0.1 = sha256:9d15b7ffbb3d
2026-10-26 18:55:06 +00:00
opsx
cfe1ccd154
fix(storage): 按 endpoint 形态解析响应 + 凭据解密返回 + 无建桶权限友好提示
...
【真实根因】COS 桶明明存在却报"桶不存在/创建失败"
用户配置：endpoint=loki-log-1394668510.cos.ap-hongkong.myqcloud.com（虚拟主机式，已含桶名）
旧代码：始终 GET / 并按 ListBuckets 的 <Buckets><Bucket><Name> 解析。
但在虚拟主机式 endpoint 下，GET / 返回的是 ListObjects（<ListBucketResult>）——
桶内对象列表，不是桶列表。解析必然找不到桶名 → 误判"桶不存在"
→ 触发建桶 PUT → 用户的 AK 无 cos:PutBucket 权限 → 403
→ 最终报"创建后校验失败"。
【实测确认（用该 AK 直连 COS）】
GET / (vhost) → 200 <ListBucketResult> 桶存在，能列对象
GET / (区域端点) → 200 <ListAllMyBucketsResult> AK 有 cos:GetService
HEAD / → 403 AK 无 cos:HeadBucket
PUT / (CreateBucket) → 403 AK 无 cos:PutBucket
即 QcloudCOSDataFullControl = 数据面全控（读写/列桶），不含管控面（建桶/HeadBucket）。
【修复】
1. 探测统一用 GET /，再按 endpoint 形态解释响应：
- 虚拟主机式 → 按 ListObjects（<ListBucketResult>）判断，200 即桶存在
- 区域端点 → 按 ListBuckets（<Buckets><Bucket><Name>）匹配桶名
桶存在就直接返回"桶已存在"，不再走建桶流程。
2. 建桶二次校验同样改用 GET /（不再用 HEAD，避免 HeadBucket 403 误判）。
3. 建桶返回 403 时给出明确友好提示：
"当前 Access Key 无建桶权限。腾讯云 QcloudCOSDataFullControl 只授予数据读写/列出，
不含 CreateBucket。请到 COS 控制台手动创建桶，或在 CAM 追加 cos:PutBucket"
4. models/storage.go Sanitized() 用 crypto.DecryptField 解密后再返回 AK/SK
（原来直接返回 ENC:xxx 密文，前端编辑框显示密文）。
5. 前端访问地址输入框补充说明：推荐填区域端点（不带桶名）。
镜像：lghost/lokistack:latest + v0.1 = sha256:350478003870
2026-10-26 18:38:00 +00:00
opsx
ff69ea2ce8
fix(storage): 凭证明文返回便于编辑测试 + 建桶后二次校验防"假成功"
...
问题（log.astx.club/storage）：
1. 编辑存储时 Access Key / Secret Key 都是空的，点「测试连接」提示
请先填写 Bucket 与 Access Key / Secret Key，无法测试也无法保存；
2. 提示"桶不存在,已自动创建"但疑似没有真正创建；
3. 测试失败提示用 toast 弹到右下角，不在弹框内。
修复：
1. models/storage.go Sanitized() 返回 accessKey / secretKey 明文
（内网运维工具，管理员需要在编辑弹框里看到并测试连接；脱敏会导致
编辑时字段为空、校验失败）
2. 前端 StorageConfig 类型补 accessKey / secretKey 字段；
编辑弹框打开时回填这两个字段（原来只有 secretKey 且强制置空）；
Secret Key 标签去掉「留空保持不变」
3. services/storage_check.go 建桶后二次 ListBuckets 校验：
不同对象存储 CreateBucket 语义不同（腾讯云 COS 要求桶名放 Host、
路径为 /），直接 PUT /<bucket> 可能返回 200 但未真正创建。
现在创建后重新列举桶，找不到就报"创建后校验失败"并提示检查
Endpoint / Region / 桶名（COS 需带 APPID）
4. 前端「请先填写 Bucket 与 Access Key / Secret Key」改为在弹框内
testResult 区域显示（原来 toast 弹右下角）
镜像：lghost/lokistack:latest + v0.1 = sha256:6b6cc9769e79
2026-10-26 18:30: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
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
fb8d10231a
chore: 忽略 run.sh 运行时 PID 文件
...
Co-Authored-By: Claude <noreply@anthropic.com >
2026-06-29 19:27:40 +08:00
opsx