103 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
opsx	c8d026adc7	feat(collectors): DaemonSet 不再填日志路径，改为「只采集哪些命名空间」多选 ... 用户指出的三个问题，逐条核实后的结论： 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	87909ed403	docs(collectors): 采集策略弹框「命名空间」补分类型说明 ... 用户困惑：这个字段到底是"只采集指定命名空间"还是"组件要部署的命名空间"？ 查代码后确认——**同一个字段在三种采集类型下含义完全不同**： k8s-fluentbit-sidecar： = 目标应用 Deployment 所在的命名空间。 平台会 Deployments(ns).Get(target) 然后 patch 注入 fluent-bit sidecar， 同时把它作为日志的 namespace 标签。 **不是**日志过滤条件。 k8s-daemonset： = Promtail DaemonSet 部署到哪个命名空间。 DaemonSet 挂载 /var/log/pods，采集**整个集群所有命名空间**的容器日志， 不按命名空间做过滤。一般就填 Loki 所在的 log。 host-promtail：不使用该字段。 原来这三种情况共用一句"命名空间"，用户只能猜。 现在字段下方按类型显示对应说明（min-h-4 固定高度，不抖动）。 实测：三条提示文案均已进包（6fe430f59eef）。	2026-10-30 15:53:08 +00:00
opsx	a14bdb5e07	fix(analysis): 每日量不再懒加载；按应用统计期间显示 loading（不再假装"没有数据"） ... 用户的三个现象，对应三个独立缺陷： === 1. 每日日志量"一直没数据" === 接口只读平台库，实测 **10ms**，却仍被 inView 懒加载门控。 ref 虽然挂在 DOM 上，但滚动判定在多层布局里不可靠 → enabled 一直 false → 请求根本不发 → 页面显示"暂无历史数据"。 改为：只要有数据源就加载（enabled = Boolean(sourceId)）。 这个接口 10ms，没有任何理由懒加载。 === 2. 排行/流图"打开没有数据，等很久也没 loading" === 按应用统计要 10~15 秒（读日志内容，物理下限）。 但 loading 是**整页共用**的：索引类指标 100ms 就回来、 重查询还在跑时 loading 就已经变 false， 卡片于是渲染成"没有应用维度的数据"——用户以为查完了、没数据。 改为： - 新增 appsLoading，专门标记"按应用统计"这段重查询 - 卡片在 appsLoading 期间显示 spinner + "正在按应用统计…" - loading 与 appsLoading 都在 finally 清理（成功/失败/取消都清） === 3. data 为 null 时整页空白 === 原来 `) : !data || !sourceId ? null : (` 直接 return null， 首屏或重查询异常时是**整页空白**，和"没数据"无法区分。 改为显示 spinner + "正在按应用统计（需读取日志内容，通常 10~30 秒）"。 === 关于"用 Go 定时任务统计每日总量"=== 这个机制**早就存在**（services/daily_volume.go）： - 启动 20s 后回补 + 每 30 分钟一次 ticker - 用 index/stats 取整天的条数与字节，**不读日志内容**，通常秒级 - 快照写入平台库，保留 400 天 实测当前库内已有 4 天数据（10ms 返回）： 2026-10-27 32.5 GB 2026-10-28 23.9 GB 2026-10-29 133.6 GB 2026-10-30 239.3 GB 问题只在"前端没去请求"，不在采集侧。 实测（df3b477e6740）：每日量接口 10ms 返回 4 天，Pod 1/1 Running。	2026-10-30 15:49:52 +00:00
opsx	419a81c2af	perf(loki): 查询并行度改为自动跟随 CPU 核数（不再硬编码） ... === 问题 === max_query_parallelism 原来是硬编码值，改过两轮（8 → 6）： - 8：4 核机器上 76% 调度周期被限流，label values 要 20 秒 - 6：仍然高于核数，25% 周期限流，查询并没有更快 根因不是"该填几"，而是**并行度只有一个正确值：等于 CPU 核数**。 把它做成可配置项反而是坑 —— 用户改了 CPU 忘了改并行度就出现错配。 === 做法 === 新增 queryParallelism(resourcesCPU)： - 从部署记录的资源规格推导，模板渲染成 {{ .QueryParallelism }} - 容错：支持 "4000m"/"500m" 毫核写法（向上取整） - 边界：低于 2 核按 2，高于 12 核按 12（再高频只会互相抢 CPU） - 非法值/空值回退 4 用户在「组件部署」里改 CPU，并行度自动跟随，页面上不需要新字段。 === 实测（4 核 + 并行 4）=== by-app(15m) 11913ms 75 条序列 （并行 6 时 12438ms） label/namespace 38ms label/app 25ms label/pod 25ms 限流 61/252 周期（仅重查询那几秒） 附带 TestQueryParallelism 覆盖 10 种输入（含毫核/越界/非法值）。	2026-10-30 15:41:38 +00:00
opsx	ad0d35f72a	feat(alerts,logs): A 方案—告警窗口 15m→5m 消重复扫描；数据源可编辑/删除且删后不被自动重建 ... === 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	c9e604b35f	perf(logs): 修 label 下拉 20 秒、Loki CPU 限流 76%、告警检查频率 ... 1) Loki CPU 限流 76%（limits 4 核，实测 3923m，nr_throttled 920656/1209379） → limits 提到 8 核 / requests 2 核。限流归零，histogram 84ms， by-app 从 60s 超时降到 14.9s。 2) label values 未传时间范围 → Loki 默认扫 6 小时索引（370GB/天 → 10~21s） → 默认只查最近 1 小时。实测 namespace 21330ms→33ms，app 24781ms→30ms。 3) max_query_parallelism 8 > 实际核数 → 调到 6。 4) 告警检查 1 分钟 → 5 分钟（规则窗口本身 15 分钟，稳态负载降到 1/5）。	2026-10-30 03:42:03 +00:00
logan	7624baa564	feat(logs): 数据源连接方式自动探测 ... 部署完成及启动时实测 cluster-svc(API proxy) 与 url 直连， 选择可用方式并落库，兼容平台/Loki 分别在主机或集群内的组合。	2026-10-30 01:23:45 +08:00
logan	b433b5f9dd	fix: 删除操作清理远端资源并拦截悬空引用 ... - 部署删除: k8s 模式清理 StatefulSet/Service/ConfigMap 与 PVC，先卸载关联采集器 - 采集器删除: 同步卸载成功后再删记录，失败保留避免孤儿 - 集群/存储/主机删除: 有部署或采集器引用时拒绝，避免悬空外键 - Token RBAC 补 services/proxy，保证 cluster-svc 数据源可查询	2026-10-30 01:17:26 +08:00
logan	56e1245b70	fix(logs): 启动时清理孤儿托管数据源 ... 旧版本删除部署后残留的 managed 数据源无法通过 API 删除 （提示随部署管理），启动时按部署名/集群存在性统一清理， 并把默认源转移到剩余数据源。	2026-10-30 01:10:15 +08:00
opsx	e6c0cf134f	test(routers): 路由断言跟上上游变更（备份恢复已移除，补保留期读写） ... 上游 commit f87fb4b 移除了备份恢复功能（/system/backup、/system/restore）， 我上一轮加的路由守卫测试仍在断言 /system/backup 存在，导致 go test 失败。 调整为当前真实 API 面： - 移除 /api/v1/system/backup 断言 - 补 GET/PUT /api/v1/settings/retention（保留期读写） - 保留 /api/v1/system/self-check 实测：go test ./routers/ → ok	2026-10-29 17:02:09 +00:00
opsx	48e68250bb	feat(docs): 用户手册接入界面截图 ... - 6 张核心页面截图(仪表盘/向导/日志查询/日志分析/告警/设置)存 docs/assets/screenshots, 随发布包分发;产品介绍页新增「界面预览」两列网格,各功能页顶部内嵌对应截图 - goldmark 开启 WithUnsafe 以渲染网格 HTML(文档自维护,无注入面);截图经 DOM 校验全部加载成功	2026-10-29 16:36:21 +08:00
opsx	e579eabe48	fix(wizard): 存储步骤去掉推荐文案;空态列表补腾讯云对象存储(COS 后端早已支持)	2026-10-29 16:20:34 +08:00
opsx	c4d907fd27	docs: 安装与启动 → 快速安装	2026-10-29 16:11:16 +08:00
opsx	bbeb9d0b28	docs: AGENTS/CLAUDE 同步密钥自动生成行为	2026-10-29 16:09:16 +08:00
opsx	65bb29aa72	feat(config): 密钥自动生成下沉到后端 + 安装文档极简化 ... - resolveSecrets 统一所有部署形态的零配置体验:显式 env 优先 → DATA_DIR/.secrets.env → 自动生成随机密钥持久化(0600,重启不变);无法持久化才拒绝启动(单测覆盖生成/复用/显式优先) - install.md 重写为三方式各一条命令(K8s install.sh / docker compose up -d / release 包), 密钥与数据说明收敛到统一「说明」一节;README Docker 段同步精简	2026-10-29 16:07:58 +08:00
opsx	88b2ac2a6d	feat(install): 一键安装脚本 — 对标 1Panel/雷池体验 ... bash -c "$(curl -fsSL …/scripts/quick_start.sh)" 一条命令: 架构自检(x86_64/arm64)→ 发布包下载(默认 Gitea Release,可镜像)→ 随机密钥生成持久化 → systemd 开机自启 → 健康等待 → 打印访问地址/初始密码/常用命令;重复执行即升级(数据自动备份)。 CentOS 7 真机验证:安装、登录、文档/落地页、升级幂等全通。 配套 upload-release.sh(make dist 后一键发布双架构包到 Gitea Release);README/手册/CHANGELOG 同步。	2026-10-29 16:05:40 +08:00
opsx	0936234623	feat(install): 零输入一条命令部署 + 双架构发布包 ... - docker compose up -d 直接启动:entrypoint 在未显式提供密钥时自动生成随机 JWT_SECRET/ENCRYPTION_KEY 并持久化到数据卷 .secrets.env(0600,重启不变), 显式环境变量优先(单显式不被持久化文件覆盖,四场景实测);compose 去掉 :? 强制 - build.sh --dist / make dist:linux amd64 + arm64 两个 tar.gz(二进制+docs+homepage+README), 实测 15M/13M;安装文档重写为三方式(kubernetes/install.sh 一键、compose 一条命令、release 包) - README 快速开始同步	2026-10-29 15:50:50 +08:00
opsx	437ff56992	feat(docs): 文档站重制 — 参照 opsxapi/opsxshell 体系,服务端渲染三栏布局 ... - 后端 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 接入与平台监控页 ... - 资源用量弹窗:删除 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/手册) ... 日志数据的保留与安全由对象存储 + 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	e07fe55c86	docs: CHANGELOG Unreleased 记录第三阶段首批特性	2026-10-29 14:04:25 +08:00
opsx	2bd77b57b4	feat(monitor): 平台自监控页(/monitor,管理员) ... - 后端 /api/v1/system/metrics-summary(admin):从 Prometheus registry 聚合 HTTP 请求/状态码/Top 路由、DB 落盘与大小、告警评估、Loki 查询、runtime 快照 - 前端统计卡 + Top 路由表 + 分布明细(状态码/告警/Loki/落盘),中英文案齐全 - 菜单位于「日志分析」与「日志告警」之间	2026-10-29 14:04: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	b8d08ef6d1	fix(alerts): 内置规则排除 Loki 自身日志,消除自我污染误报 ... Loki 会把执行过的查询语句记成自身 info 日志,查询文本包含规则关键字时 告警会'命中自己'(如 StackOverflowError 规则匹配到告警引擎自己的查询记录), 造成持续误报——全命名空间类内置规则一律加 app!="loki";存量规则启动时自动升级; 顺带清理旧版遗留的重复规则「应用错误过多(error > 1000)」(与现模板重复且阈值会误报); 前端新建/模板默认查询同步;红线测试锁死	2026-10-29 13:46:46 +08:00
opsx	abe28964a1	fix(i18n): 全站文案书面化 + 中英翻译质量修复 ... 中文(zh):约 40 处口语化改书面(「谁在什么时候改了什么」→「操作人、时间与变更前后对比」、 「找出最吵的业务」→「定位日志量最高的业务」、「点」→「点击」、创建你的第一个→创建首个等); 「副本 / Pod」统一为「Pod」。 英文(en)修复: - 功能 bug:wizard openGrafana ({url}) 插值失效→({{url}});settings notify 空态链接词悬空破句 - 语义补齐:clusters/hosts 删除确认补 Warning 与后果句;tokenInsecureHint 补 Kubeconfig 建议 (并删 en 死键 tokenRecommended);retention liveHint/costWarning/upgradeHint 补丢失半句 - 术语统一:data source / collection policy / log lines / Listen IP (internal) / Total deployments - 复数:users confirmDesc、pagination total、range lastMinutes 补 _one;storage deleteWarning 两形态对齐 - 风格:Select filtered users、Delivery History、Log Scrape Jobs、App label source、 Deployment Logs 连字符改间隔号;删除 zh 死键 liveTitle	2026-10-29 13:42:51 +08:00
opsx	df1075f1f5	fix(layout): 顶栏用户区去掉盾牌图标与管理员徽章,只留用户名	2026-10-29 13:31:05 +08:00
opsx	c33ea9d0a8	ci(lint): golangci-lint v2 入门禁并归零 ... - .golangci.yml:standard 集 - errcheck(存量 38 处裸忽略待专项),staticcheck 关纯风格/quickfix - 清理 3 个无引用死函数;SanitizedJSON 不可达分支收敛为接口分支 + nil 指针防护(原死分支中的 nil 检查从未执行) - CI backend job 增加 golangci-lint-action@v6 v2.0.0	2026-10-29 13:29:25 +08:00
opsx	a69142fbfe	refactor(frontend): Live Tail 重构 + alerts 拆分 + NotifySection 去重 ... - Live Tail:输入 500ms 防抖后才切换轮询查询;轮询 AbortController 取消 + 版本号丢弃乱序响应 - alerts/index 508→286 行:表单与模板拆出 RuleFormDialog(浏览器实测模板/通道/提交可用) - NotifySection 两份逐字节副本合一为共享组件;settings 词典注册进 domains(alerts 直访不再裸键)	2026-10-29 13:29:25 +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	9daaf7f403	docs: CHANGELOG 落地与发布流程说明	2026-10-29 13:28:23 +08:00
opsx	c5739d1a06	feat(alerts): 内置规则默认启用并绑定默认通道,开箱即用 ... - 新种规则 Enabled: true;启动时执行 SeedAlertRules(此前仅部署成功调用,存量环境拿不到升级) - 存量一次性迁移:内置名单内且从未关联通道的规则补绑默认通道并启用;用户已自配通道的不动 - 管理员只需给「默认告警」通道填 Webhook 并启用;通道未就绪时命中只记发送历史(failed+原因),不影响规则评估	2026-10-29 13:14:05 +08:00
opsx	c08190458f	fix(alerts,db): 清理历史误种的 K8s 基础设施告警规则 + 数据迁移不留档 ... - seed 启动时一次性删除早期版本种入的「Kubernetes 节点 NotReady」「容器 OOMKilled」 (日志平台只关注应用日志,节点/容器状态告警归 Prometheus;源码早已移除该模板,但幂等只跳过不清理,旧库存量一直在) - 数据文件迁移为 lokistack.json 后直接删除旧文件,不再留 .migrated-*.bak(测试同步)	2026-10-29 13:09:14 +08:00
opsx	231fa8e774	fix(settings): 日志保留时间移出顶部并紧凑化 ... 通用配置卡内顺序改为 主题 → 语言 → 日志保留时间;保留时间从嵌套整卡 压缩为单行分区(标签 + 两个数字输入 + 内联保存),与主题/语言分区同族, 删去 desc 与两条 hint 冗余文案(中英同步)。	2026-10-29 13:06:31 +08:00
opsx	cddd60045c	fix(db): 首次加载历史命名数据文件即迁移为 lokistack.json ... 旧回退链(lokistack.json → opsxloki.json → lokideploy.json)会永远沿用旧文件名, 旧品牌残留一直不消;现在首次从旧文件成功加载后立即原子写入 lokistack.json, 旧文件改名 .migrated-*.bak 留档(不删数据),新旧并存或写失败时退回旧路径安全运行。	2026-10-29 13:04:24 +08:00
opsx	4f74fe6c3f	ci(engineering): Gitea Actions 门禁 + 前端测试设施 + 版本注入修复 ... - .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	8bea331183	chore(release): 发布脚本对齐"统一使用 latest"策略 ... 清单本来就用 latest（deployment.yaml / docker-compose.yml / prod.yml 的 ${IMAGE_TAG:-latest}），但上一版 release.sh 会把 deployment.yaml 改成 不可变 tag 并把 pullPolicy 改成 IfNotPresent —— 与"统一用 latest"相反， 而且改完不提交的话下次 apply 又会退回最新 tag，容易造成实际版本与预期不符。 改为： 1) 一次构建打三个 tag：latest / v0.1 / <版本>-<日期>-<commit>，同时推送 2) 推送后**校验三个远端 digest 一致**，不一致直接退出（并发构建覆盖 latest 的经典事故，先拦住别部署） 3) 部署走 kubectl apply + rollout restart（image=latest + Always 强制重拉） 4) 部署完再核对 Pod digest 与远端 latest，不一致立即提示 5) 不再默认改清单；需要"固定版本部署"时显式 `--pin` 6) 回滚方式写清楚：把旧的不可变 tag 重新打成 latest 推上去 同时把集群里被我为了避开 tag 竞争临时改成 v11-1028-2252 的 Deployment 恢复成 latest + Always（已验证 Pod / Hub latest / Hub v0.1 三者 digest 一致 = 187062644c0f）。	2026-10-28 23:02:41 +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	cb91470d75	perf(analysis): 分层加载 + 修复裸 i18n key + 单位混用；附 Loki 查询方式的实测对比 ... === 1. 界面显示裸 key（trend.subtitle / daily.subtitle / table.subtitle）=== 根因：中文语言包只加了 title，**没有 subtitle**，而英文包有。 i18next 找不到 key 就把 key 原样输出，所以界面上出现 "trend.subtitle" 这种文字。 已补齐 zh 的 trend/stream/pie/daily/table 五个 subtitle，并把文案改成 人话（说明数据来源与是否需要等待），例如： trend : 按时间分桶的日志量（来自索引统计，秒级返回） daily : 近 7 个自然日的每日总量（来自索引统计，不受上方时间范围影响） table : 按日志条数排前 10 的应用，点「查看日志」跳到查询页 === 2. 分层加载：上面的先出，下面滚到再算 === 新增 hooks/useInView.ts（IntersectionObserver，提前 200px 触发，只触发一次）。 - 首屏只跑索引类查询（histogram + index/stats），**合计 <100ms** - 「每日日志量」「应用排行」「Ingress 分析」三块滚动到视口才发查询 - 排行卡片加载中显示"正在按应用统计（需读取日志内容，通常 20~30 秒）…"， 不再是空表格让人以为卡死 === 3. 修复自己引入的单位混用（重要）=== 趋势图数据源从 count_over_time 换成 index/volume_range 后，返回值是**字节**， 但排行表里的值是**条数**，两者混用导致： - 统计卡显示 7956179750 这种看不懂的裸数字 - 排行占比算成 0.0x%（分子条数、分母字节） 修法： - 统计卡拆成两张且都走索引接口（实测 histogram 50ms / index-stats 43ms）： 日志条数（索引统计） ← index/stats entries，精确条数 日志体积（索引统计） ← volume_range 累计，格式化为 GB - 排行占比分母改用 apps 自身条数合计 - 去掉"告警行数"卡片：为了把重查询从 3 条降到 2 条已放弃全局 warn 统计， 显示一个恒为 0 的数字比不显示更误导 === 4. Loki 查询方式实测对比（15 分钟 astralx，370GB/天）=== 直接打 Loki，逐个验证卡在哪： sum(count_over_time({ns}[30s])) step=30s 61s 超时 ← 全集群全局 sum by (app,ns)(count_over_time([30s])) step=30s 19.7s 5.5GB ← 现用 sum by (app,ns)(count_over_time([15m])) step=15m 47s 超时 ← 反直觉！ sum by (app)(count_over_time([30s] |= error)) step=30s 12.7s 5.5GB 单 app gateway count_over_time step=30s 12.6s 0.58GB index/volume (limit=200) 2.2s ← 只给 selector 级，不能按 app index/volume_range (step=60s) 133ms index/stats 112ms ← entries/bytes 精确 两个结论（写进注释，避免以后又"优化"回去）： a) **不要把 range 和 step 一起放大**：`[15m]` + step=15m 看着"点数少"， 实际要让 Loki 为单个 evaluate 点加载 15m 的 chunk，比 [30s]+step=30s 慢 2 倍以上 （47s 超时 vs 19.7s）。 b) **按 app 分组无法走索引**：Loki 3.4 的 index/volume 只回落到 selector 标签， 不支持 aggregateBy=app（传了也无效果）。所以 per-app 排行只能读日志内容， 20 秒左右是这台集群的物理下限 —— 只能靠懒加载 + 明确提示来改善体感。 === 实测（v8-1028-2232 / 7a05683a91ae）=== logs/histogram 50ms logs/stats 43ms by-app 排行 25077ms（懒加载，滚动到才发） 中文 subtitle 已进包：来自索引统计 / 按量排前 / 各命名空间的日志量占比 / 近 7 个自然日 / 按日志条数排前 10 各命中 1 次	2026-10-28 22:34:04 +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