155 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
opsx	b8eca87a89	fix(alerts): Pro 到期后告警引擎停止评估 + 规则/通道写操作挂 RequirePro ... 用户指出的漏洞:免费期配完规则,到期后若引擎继续跑,告警等于免费功能,Pro 形同虚设; 重装又拿新试用继续白用。修复: - 引擎每轮先查 IsPro(),非 Pro 整轮跳过(规则与投递历史保留,重新授权即恢复) - 规则建/改、通道保存、立即检查挂 RequirePro 闸门(读列表/历史保持可见,升级引导有据可依) - 试用期内 IsPro=true 照常工作(实测建规则 200)	2026-11-01 06:06:10 +08:00
opsx	897899305f	fix(license): 试用态隐藏「退出授权」——试用不是授权,点了必报'当前未激活' ... canDeactivate 改为:有正式授权(plan=pro 且非 trial)且 admin 才显示; 试用态(库内无码)显示试用提示条而非退出按钮(实测复现:试用态点击退出 toast 报'当前未激活授权',按钮又因 pro=true 未消失,看似'点击没反应')	2026-11-01 05:59:18 +08:00
opsx	9a477e9c9b	feat(license): 首次安装 14 天 Pro 试用(无需授权码) ... - 首次启动落试用起点(DATA_DIR/.trial-start 0600 + 库内 settings 双写,取最早防分次续命); 窗口内 IsPro() 等效 Pro——日志分析/告警/AI 助手/审计全解锁,到期自动回免费版 - 防刷三层:时间戳双写(删任一不重发)+ 机器级指纹(machine-id / hostname+cpu, 故意不含 DATA_DIR 特征——目录特征会因删除重建漂移等于后门);指纹命中则落已过期起点 - LicenseStatusPayload 返回 trial{active,daysLeft} 与 plan=trial; 设置页授权区显示「Pro 试用中 · 剩余 N 天」提示条 - 单测:全新安装 14 天/到期回落/删时间戳重装不重发(指纹防刷)三用例 - 滥用评估:删库重装同机器被指纹拦截;换机器/VM 必然可重试(接受,Pro 功能零边际成本, 追杀到硬件级得不偿失);正式授权随时激活覆盖试用	2026-11-01 05:53:55 +08:00
opsx	f67b86e6bb	style: gofmt config.go	2026-11-01 04:08:50 +08:00
opsx	8423192719	test(license): 退出授权降级语义测试同步——远端失败清本机+标记而非报错保留	2026-11-01 04:08:12 +08:00
opsx	daa531f4ed	fix(license): 退出授权在拿不到解绑凭证时降级清本机,不再卡死报错 ... 根因(实测确认):授权服务 activate 响应不含 activation_token 字段,本机存证里 token 为空;deactivate 端要求该凭证 → 远端永远拒绝 → 用户点退出只会报 「远端解绑失败,本机授权未清除」且无法自愈。 修复:远端解绑失败时降级——清本机授权(回免费版,用户诉求达成), 返回 offlineLocalOnly 提示远端席位需服务端释放;服务端将来补发 token 后 此路径自动回到完整解绑。	2026-11-01 04:06:56 +08:00
opsx	8606b1ee31	fix(license): 计划摘要用可读文案，禁止裸打 planType ... trial 真码可能回 monthly；设置页映射为体验/包年/永久等 i18n， 短窗 monthly 软纠为体验；customer 空不渲染；到期仍用 expiresAt。	2026-11-01 04:00:12 +08:00
opsx	a6b0be9698	fix(license): 「智能运维(AI)」更名为「AI 助手」(Pro 功能清单中英)	2026-11-01 03:57:03 +08:00
opsx	914eec1e4b	feat(license): 退出授权文案精简与两态布局 ... 未授权隐藏退出；Pro+管理员可见「退出授权」；成功只 reload 授权态不整页刷。	2026-11-01 03:34:10 +08:00
opsx	cec7c6eeaf	feat(license): 退出授权 / 释放本实例（确认后 deactivate） ... 设置→授权 Pro 态管理员可退出：在线 LIC- 先调 opsx deactivate（含 activation_token），成功才清本地；失败保留现状。LICOFF- 仅解本机并提示后台名额可能仍占。禁静默清码。	2026-11-01 03:16:05 +08:00
opsx	f3d27ceb04	feat(license): show Instance ID with copy on settings + ProGate ... Always return machine fingerprint instanceId from license status for offline LICOFF- binding. Shared InstanceIdRow (zh/en) above activate.	2026-11-01 03:12:53 +08:00
opsx	db92426973	fix(license): 免费版文案精简——仅基础日志查询(中英)	2026-11-01 03:09:32 +08:00
opsx	62d9b81a70	fix(license): shared invalid/grace banners + instance copy ... Surface expired/over_instance/revoked red banners with CTAs via a shared LicenseStatusBanners used by settings and ProGate. Hide seats in product UI; keep HMAC dual-path and never silent-clear keys.	2026-11-01 03:08:37 +08:00
opsx	af0298e994	feat(license): dual-path opsx-licence client alongside HMAC ... Wire LIC-/LICOFF- activate/verify/heartbeat to licence.rlwj.cn/api, keep legacy HMAC accepted with deprecation banner, add instance_id fingerprint and licensing docs (product lokistack still needs admin create).	2026-11-01 02:55:37 +08:00
opsx	5f42d9f696	perf(logs): label 缓存 TTL 30s + 平台变更即时失效（回答"新 app 会不会延迟"） ... 问题：加了 60 秒缓存后，新增 app / 新副本 / 新主机采集器要等最久 60 秒 才出现在下拉里，抢修时"刚上线的服务查不到"是不可接受的。 两层处理： 1) TTL 60s → 30s（前后端一致） 纯 Loki 侧的变更（新 Pod 开始打日志、新副本、主机上新进程写日志） 最长 30 秒可见。这类变化平台无从感知，只能靠 TTL 兜住。 2) 平台侧变更**立即失效**（不等 TTL） 新增 InvalidateLabelCache()，在下列入口 defer 调用： CollectorService.Create / Update （主机模式 app 标签来源） DeploymentService.Delete （连带清理托管数据源） CreateLogSource / UpdateLogSource / DeleteLogSource 也就是"用户在平台上做了什么导致候选值集合变化"，缓存当场清掉， 下一个请求必然回源。这正好覆盖"主机采集的 app 标签"这个场景 —— 采集器一改，下拉里马上就有。 关于「要不要用定时任务预热」： 不做。预热只能省掉一次 25~40ms 的网络往返，却要多一个常驻任务和 一份额外的失败路径；而"时效性"问题已经由上面的即时失效解决了。 如果将来真要削掉这 40ms，更划算的做法是把 label 值随部署一起下发缓存， 而不是定时轮询 Loki。	2026-10-31 18:27:17 +00:00
opsx	25a5e57cb3	perf(logs): 未选命名空间时也加载 app 候选，下拉不再"空的要等" ... 原来快捷 LogQL 里 app 候选的逻辑是： if (!namespace) { setApps([]); return } // 没选命名空间就直接空列表 所以用户必须先点命名空间，app 下拉才会出现内容 —— 观感就是"app 下拉加载慢"， 其实是被这条早退挡住了，而不是请求慢。 改为：没有命名空间时拉一次**全量** app 候选（不传 selector）， 选了命名空间后按 `{namespace="..."}` 收窄。两者共用同一套批量接口与缓存， 不会多打 Loki（全量结果本来就会被缓存 60 秒）。	2026-10-31 18:25:58 +00:00
opsx	5f42ac5486	perf(logs): 快捷 LogQL 下拉加前后端双层缓存，重复打开不再转圈 ... === 先测清楚瓶颈在哪 === 后端单点实测（都很快，不是问题所在）： /logs/my-scope 10ms /logs/label/namespace/values 25ms /logs/label-values?scoped astralx 23ms /logs/label/app/values scoped 18ms 结论：慢的是**前端每次都重新走一遍请求链**（切数据源 / 切命名空间 / 重开面板 都会触发），三四次往返串起来 + 每次都有 loading 态，用户看到的就是转圈。 === 后端：label 候选值短缓存 === services/log_query.go：60 秒 TTL，key = sourceId|label|selector|时间窗(按 5 分钟取整)， 上限 500 条并做过期清理。理由：下拉值的时效性要求很低—— 新上线的 app 晚 1 分钟出现在候选里完全可以接受。 LokiLabelValuesBatch 内部逐个走 LokiLabelValues，所以批量接口自动受益。 === 前端：内存缓存 + 飞行中请求合并 === api/logs/index.ts：60 秒 TTL 的 Map，**缓存 Promise 而不是结果**， 所以并发的相同请求共享同一次飞行（去重）；失败立刻剔除缓存，避免缓存错误。 带 AbortSignal 的调用不参与缓存（用户主动取消的请求不应共享给别人）。 额外导出 invalidateLabelCache()，数据源变更时可手动清。 === 预期效果 === 首次打开：与之前相同（~100ms 量级） 再次切换 / 重开面板：直接命中内存，0 请求 服务端重复请求：25~40ms → 微秒级	2026-10-31 18:22:38 +00:00
opsx	4d582e62eb	fix(release): digest 校验改为轮询，避免 Docker Hub 传播延迟导致误判 ... 现象：刚 push 完立刻查 tags API，latest 已是新 digest 而 v0.1 还是旧值， 脚本按"三个 tag 不一致 = 并发覆盖"直接 exit 1，把正常发布拦下来了。 根因：Docker Hub 的 /v2/repositories/<repo>/tags/<tag> 有秒级~十几秒的 传播延迟，单次查询不能作为判据。 修复：轮询最多 12 次、每次间隔 5 秒（共 60 秒），三者一致才继续； 超时仍不一致则 exit 1，并在报错里区分两种可能： - latest 与 v0.1 不同 → 疑似并发构建覆盖（提示检查 flock 是否被绕过） - 仍为 "?" → 推送根本没成功或仓库不可达 本次实测：第 1 次轮询发现未同步，等待 5 秒后三者均为 1ce3d4166506 ✅ 顺带：不可变 tag 之前出现 -dirty 后缀，是因为改完脚本没提交就发版； 本次先提交再发版，tag 恢复干净（2.0.0-20261031-<sha>）。	2026-10-31 18:12:46 +00:00
opsx	0644dccf2a	test(routers): 断言跟上上游重构——/ai/analyze 改为 /ai/chat，补 license 路由 ... 上游 fbbd3a3/6923a12 把整页 AIOps 改成浮窗助手： - 删除 POST /ai/analyze（整页结构化分析） - 新增 POST /ai/chat（助手对话，AdminAuth + RequirePro） - 新增 GET /system/license、POST /system/license/activate 路由回归测试仍在断言已删除的 /ai/analyze，导致 TestCriticalRoutes 失败。 本次按实际路由更新断言（这正是这个测试的价值：路由被删/改名时立刻暴露）。 注：services.RunAIAnalysis / CollectAISignals 现在没有任何调用方（死代码）， 是否保留待确认——见 PR 讨论。	2026-10-31 18:08:59 +00:00
opsx	02c1ee8aa8	docs(ai): TestConfig key 解析注释精确化(仅注释,无逻辑变更)	2026-11-01 02:01:37 +08:00
opsx	550d8f4967	refactor(ai): 助手按 AI-AGENT 开发指南对齐(Ask 模式) ... 对照指南逐条评估后落地 4 项真实差距(MCP/Agent Loop/白名单等重型章节不适用,明确排除): - 上下文预算(指南 07 TrimMessages):历史按 24k 字符预算从最旧裁剪,system 标注 「更早的对话已省略」;抽 trimHistory 独立函数+单测(超预算丢最旧/小历史不裁) - 配额超限诚实终态(指南 05.3/06 禁止伪装 completed):不再 400 报错,返回提示 文案;前端渲染为 warning 提示条样式,对话上下文保留 - 回复脱敏(指南 08):assistant 回复同样过 RedactTextOnly,堵住模型复述样本 带回敏感串的通道 - 退避重试(指南 05.2):429/5xx/网络错误指数退避 1s→2s 最多 2 次(计入总超时), 鉴权/参数错不重试	2026-11-01 01:59:17 +08:00
opsx	448f695c28	fix(ai): 推理模型 content 为空时回退 reasoning_content ... 根因(带响应体日志实测确认):deepseek-v4-pro 等推理系模型把输出写在 reasoning_content,MaxTokens 较小时最终 content 为空串,被误判为「模型返回了 空内容(检查 baseURL)」——与 key/端点无关,保存的 key 解密与沿用逻辑均正常 (空参/掩码传参两路均能取到库内真值)。 修复:content 空白时回退使用 reasoning_content;移除调试日志。	2026-11-01 01:50:44 +08:00
opsx	37a610b603	refactor(settings): AI 模型接入拆为独立 tab 页(/settings/ai) ... 系统设置分组 tab 顺序:通用配置 → 用户管理 → 审计日志 → LDAP 接入 → AI 模型接入 → 默认镜像源;设置主页去掉内嵌卡片,子页复用 AiModelSection	2026-11-01 01:38:43 +08:00
opsx	6923a12dd9	fix(ai): 助手 chat 端点补 AdminAuth——前端浮球已限 admin,后端同步兜底防普通用户直调 API 耗 token	2026-11-01 00:48:00 +08:00
opsx	fbbd3a3c27	refactor(ai): 砍掉 /aiops 整页,模型配置迁入系统设置,浮窗助手保留 ... 评估结论落地:整页分析只喂聚合统计(模型看不到日志原文),结论价值低于 /analysis 图表自身;浮窗助手携带真实查询样本,价值成立。 - 删 /aiops 页面与路由(菜单去项);llmProviders 迁 lib 共用 - 模型配置重做为设置页「AI 模型接入」区:状态严谨映射——供应商/模型按已存 baseUrl/model 正确回显(自定义供应商显示 BaseURL 与自定义模型输入,不再重置), API Key 掩码占位、留空或掩码保存均沿用旧值(不回传掩码) - 后端删 /ai/analyze 与信号采集链路;/ai/chat 保留(上下文由前端日志样本注入)	2026-11-01 00:46:38 +08:00
opsx	c216bdfdd4	feat(ai): 助手浮窗聚焦日志查询页,携带当前查询结果对话 ... - 浮球只在 /logs 渲染(产品定位:辅助分析正在查看的查询结果,其它页面不打扰) - /logs 查询成功后写入 AI 上下文:LogQL、时间范围、结果条数、error 行数、 最新 20 条样本(去 CRI 包装);对话请求自动携带 - 后端 /ai/chat 接收 context:截断 6000 字 + RedactTextOnly 统一脱敏后并入 system (ECHO 假模型实测注入完整);空态文案改为查询导向	2026-11-01 00:31:48 +08:00
opsx	2efbed882a	fix(aiops): 保存配置后分析页状态即时同步;分析页布局重排 ... - enabled 状态在 saveConfig 成功后立即 setEnabled(此前只更新 config, 导致'AI 分析未启用'横幅要等下次请求才消失) - 布局:工具栏改 4 列网格(数据源/时间/应用/问题),执行按钮与提示移到 分隔线下右对齐;未启用横幅加 ✦ 图标 + 「去配置」直达按钮;空态/加载态 加图标居中;消耗行改统计卡风格(数值 tabular 高亮)	2026-11-01 00:26:22 +08:00
opsx	5d898e3592	fix(ai): 测试连接改为结构化结果,不再倾倒模型原始回复 ... 返回 {model, latencyMs, tokensUsed, replyLength};前端提示「连接正常:模型 · 耗时 · tokens」。 模型原始回复不回传——测试要的是通没通/多快,不是看模型说了什么(ECHO 假模型下尤其明显)。 空回复时明确报错提示检查 baseURL 是否 OpenAI 兼容。	2026-11-01 00:21:59 +08:00
opsx	f1d9480caf	fix(ai): 浮窗助手提示词调优 — 身份固定/风格收敛/话题引导/禁编数据 ... 实测(经 ECHO 假模型检验注入):被问模型身份时答固定一句(底层模型由管理员配置指定, 不自行猜测 DeepSeek 版本),并引导回排查;回答限 5 句、优先动作;无关话题礼貌拒绝; 引用数字仅限注入的日志概况。	2026-11-01 00:18:39 +08:00
opsx	f457d6da09	feat(ai): 全站 AI 助手浮窗(参考 FlowStack 右下角浮空设计) ... - POST /ai/chat:多轮对话(messages 透传)+ 页面上下文注入 —— 前端带当前路径, 后端自动附加该数据源近 15 分钟轻量日志摘要(总量/Top3 应用/告警命中), 追问「这个报错什么原因」有数据依据;脱敏/每日配额/Pro 闸门与整页分析共用 - AiAssistant 浮球+浮窗挂 Layout:仅 admin+Pro 渲染;消息气泡、Enter 发送、 上下文随路由自动采集;免费版不显示	2026-10-31 23:46:33 +08:00
opsx	b81b31f322	feat(aiops): 模型配置默认 DeepSeek/flash + 模型名真下拉 ... 首次进入配置页自动预填 DeepSeek 端点与 deepseek-flash(只需填 Key);模型名从 datalist 换 shadcn Select(随供应商联动,末项「自定义模型…」转手输)	2026-10-31 23:41:43 +08:00
opsx	07aa41bc33	fix(aiops): 菜单移至日志告警下系统设置上;模型配置精简 ... - 菜单顺序:日志查询 → 日志分析 → 日志告警 → 智能运维 → 系统设置 - 模型配置去掉快捷预设按钮组;Base URL 仅选「自定义」供应商时显示; 温度/输出上限/超时/每日token上限/额外脱敏收进「高级设置」折叠(默认收起), 常规配置只剩:供应商下拉 + 模型名 + API Key + 测试/保存	2026-10-31 23:36:16 +08:00
opsx	9641503007	feat(license): Pro 授权机制 — 离线许可码 + 免费版功能闸门 ... 免费版:日志查询/部署管理/采集/用户管理/LDAP/设置;Pro(¥199 个人单实例永久 / ¥499 团队多实例永久): 日志分析、日志告警、智能运维(AI)、审计日志。 - 后端:HMAC-SHA256 离线许可码(签发 CLI / license --plan --edition --seats --customer --days; 永久=days 0),GET /system/license + POST activate;RequirePro 闸门挂 metrics/ai/audit; 过期自动回落免费;测试覆盖签发-校验/篡改/免费拒签 - 前端:菜单 Pro 项带锁标;四个 Pro 页面免费版渲染升级引导卡(功能清单+定价+页内激活); 设置页新增授权区(版本/席位/到期/激活入口);license 词典中英 - domains 注册提升到 main.tsx 全局(修复 license 命名空间在未引 domains 的页面显示裸键)	2026-10-31 23:08:06 +08:00
opsx	c60b827262	fix(settings): 定时切换主题去掉时区下拉与说明文字,固定用浏览器本地时区	2026-10-31 22:52:58 +08:00
opsx	c090ba0564	feat(aiops): 长窗口(>1h)分析必须指定应用 ... 全命名空间 6h/24h 聚合数据量过大会拖垮 Loki:前端时间范围旁新增应用范围选择器 (labelValues 候选),>1h 未选应用禁用开始分析并提示;后端同样强制 400(闸门在服务端); 信号采集选择器按 app 收窄后 histogram/stats 从全量变为单应用流,秒级返回。	2026-10-31 22:51:55 +08:00
opsx	1610988c2e	feat(aiops): 模型配置参考 aiops/opsxshell — 快捷预设 + 供应商下拉 ... - 快捷预设:deepseek-flash(推荐)/ deepseek-v4-pro / 自定义 一键填入端点与模型 - 供应商目录(9 家 + 自定义):DeepSeek/通义/智谱/Kimi/MiniMax/硅基流动/混元/OpenAI/本地 Ollama·vLLM,选择后自动填 Base URL 与首个推荐模型 - 模型输入支持 datalist 下拉(随供应商联动)且可手输任意模型名;Base URL 保持可编辑	2026-10-31 15:23:26 +08:00
opsx	63445bd598	build(release): 部署后自愈 + 版本戳，堵住"latest 被旧镜像覆盖"这类问题 ... === 背景：同类问题已经出现三次 === 1) Docker Hub 502 导致 latest 推失败，Pod 仍跑旧镜像 2) 并发构建互相覆盖 latest（谁后完成谁生效） 3) 中断的构建后来完成，把 latest 推回旧代码（本次差点中招） 第 2 类已由 flock 独占锁解决；但前两类还有一个共同的后半段： **没有人核对"部署后 Pod 到底跑的是不是刚推的那版"**。 === 本次新增 === 1) 部署后自愈：rollout 完成即核对 Pod digest 与远端 latest； 不一致自动 `kubectl delete po` 强制重拉（节点缓存了旧 latest 映射是常见原因）， 最多等 4 分钟，仍不一致才 exit 1 —— 不再"报个 ❌ 就结束"。 2) 版本戳：核对通过后给 Deployment 打三个 annotation lokistack.io/release-image = <digest> lokistack.io/release-tag = <版本-日期-commit> lokistack.io/release-time = <ISO8601> 以后排查"线上跑哪版"直接 `kubectl -n log get deploy lokistack -o yaml | grep release-`， 不用再在 docker images / Hub API / Pod 之间来回比对。 === 用法 === 以后发版统一走 `bash scripts/release.sh`（build+push+deploy+自愈+打戳一次完成） 不要再手敲 docker build + docker push —— 那样会绕过 flock 锁，回到互相覆盖。 bash scripts/release.sh --dry-run 只做前置检查 bash scripts/release.sh --no-deploy 只发镜像不动集群	2026-10-31 07:08:23 +00:00
opsx	7be41f0a6b	feat(aiops): 新增「智能运维」——AI 日志分析（P0，不扫日志内容） ... === 为什么这样设计（成本优先）=== 全集群 370GB/天，把日志原文丢给模型是不可能的（一次几百万 token）。 所以整条链路只做一件事：**把 GB 级日志压成 KB 级信号**。 P0 的信号来源全部是索引/快照，**零日志内容扫描**： 体积 + 趋势 → index/volume_range（实测 24h 仅 54ms） 条数/流数 → index/stats，且只在 ≤2 小时窗口用 （全天 index/stats 实测 20s，绝不能进 AI 路径） 应用排行 → 平台小时级预聚合快照（毫秒） 基线对比 → 上一个等长窗口的 volume_range 告警 → 平台投递记录 实测一次分析：3~6 秒、输入 600~1400 tokens（约 ¥0.005/次）。 === 后端 === models/ai.go AIConfig（APIKey 加密存储）+ AIAnalysisRun（审计） services/ai_config.go 读写配置、掩码返回、每日 token 用量统计 services/ai_provider.go OpenAI 兼容客户端 + 连通性测试 （DeepSeek/通义/内网 vLLM/Ollama 通用） services/ai_redact.go 脱敏：凭据/邮箱/手机号/身份证 → 占位符， **保留内网 IP 与端口**（排查必需） services/ai_signal.go 信号采集 + 渲染成紧凑文本（省 token） services/ai_analyze.go 结构化输出解析、配额闸门、审计落库 controllers/ai.go /ai/config /ai/config/test /ai/analyze /ai/runs 成本闸门（三层）： 1) 单次：时间范围 ≤24h、maxTokens ≤1500 2) 每用户每日 token 上限（默认 50 万，可配，超限直接拒绝并说明） 3) 审计只留最近 500 条，避免表膨胀 === 前端 === 新页面 /aiops（侧栏「智能运维」，管理员），页内单层 tab： 日志分析 / 模型配置 / 分析历史 - 分析：数据源 + 时间预设(15m/1h/6h/24h) + 可选提问 → 结论/证据/建议/不确定 四区 顶部显示本次消耗（in/out tokens、耗时），可查看「发给模型的完整内容」 - 配置：启用开关、Base URL、模型、API Key（掩码）、温度、输出上限、超时、 每日配额、额外脱敏正则；按钮顺序改为「测试连接 → 保存配置」 - 历史：服务端分页（20/页），点行看详情与 payload === 两个真实踩坑（已修）=== 1) 密码含 @ 导致脱敏漏掉（mysql://user:P@ssw0rd@host） → URL basic-auth 规则改为贪婪匹配到最后一个 @，由单测锁定 2) 结论里的时间是 UTC（容器无 tzdata，time.Local=UTC）， 模型写"凌晨 6 点下跌"而运维当时是下午 2 点 → 显式用东八区展示（LOKISTACK_DISPLAY_TZ=UTC 可覆盖） === 实测（69147008fcf4）=== 配置保存 → key 掩码 sk-***e286；连通性测试返回「正常」 分析 15 分钟窗口：4.1s，结论识别出"窗口末段体积断崖约 -60%" 信号时间 14:23~14:38（本地时间正确） 历史分页 total=3，tokens/耗时字段完整 单测：脱敏 2 个用例 + 模型输出解析 4 个用例 + 6 条 AI 路由断言	2026-10-31 06:39:01 +00:00
opsx	3861b8b128	fix(collectors): 编辑采集策略时无法把"全集群"改成"只采几个命名空间" ... === 现象 === 编辑 Promtail DaemonSet 采集器，显示"所有命名空间（全集群采集）"， 下面每个命名空间的复选框全是灰的，点不动，无法改成只采指定几个。 === 根因 === CollectorEditDialog 里单个命名空间的复选框写死了： disabled={allSelected} // allSelected = selectedNs.length === 0 而 targetNamespaces 为空正是代表"全集群"，也就是**一进来就处于全集群状态**， 于是所有子项被禁用；而"全集群"那个复选框的 handler 又是 onCheckedChange={() => setAll()} // 永远设回 [] 两者叠加 → 没有任何操作能离开"全集群"状态，是死胡同。 === 修复 === 1. 去掉 disabled：勾任何一个命名空间都会让 selectedNs 非空， allSelected 自动变 false，"全集群"勾选框随之取消——语义自洽。 2. "全集群"行加一句提示：勾选下方任一命名空间即可改为只采指定范围， 让用户知道下一步该点哪里。 === 实测（51489599e2d8）=== PUT targetNamespaces=["astralx"] → 读回 ['astralx'] ✅ PUT targetNamespaces=[] → 读回 []（全集群） ✅ 恢复 ['astralx','log'] → 读回 ['astralx','log'] ✅ tsc 通过；Pod = Hub latest = 51489599e2d8 注：改完需要点「部署」才会把新的 kubernetes_sd_configs.namespaces 白名单 下发到 Promtail DaemonSet。	2026-10-31 02:00:33 +00:00
opsx	9448868a71	feat(collectors): Promtail DaemonSet 的部署命名空间固定为 log，表单隐藏该字段 ... === 需求 === 创建 Loki 部署后添加采集策略（Promtail DaemonSet）时，"部署节点命名空间" 不该让用户选 —— 采集器必须和 LokiStack 放在一起（log）。 === 前端 === CollectorFormDialog：选择 k8s-daemonset 时整块隐藏 namespace 字段 （连同分类型提示、手动输入开关一起），改为一条只读说明： 「采集器部署命名空间固定为 Loki 所在命名空间（通常 log），与 LokiStack 放在一起，无需选择。要限制采集范围请用下面的『只采集这些命名空间』。」 提交时 DaemonSet 不传 namespace（原来会传用户填的值）。 顺带修掉隐藏后暴露的 tsc 报错：placeholder 里 `collectorType === 'k8s-daemonset'` 在收窄后的分支里已成不可能比较，改为常量 'default'。 === 后端（强制约束，不只靠前端）=== services/collector.go： Create：type == k8s-daemonset 时强制清空 req.Namespace → 渲染与部署两侧都会回退到 d.loki.Namespace Update：DaemonSet 忽略 updates["namespace"] 原始渲染逻辑本就有"为空则用 LokiDeployment.Namespace，再兜底 log"。 为什么后端也要拦：API 直接调用（脚本/其他客户端）不该能把采集器 部署到任意命名空间——那样会出现"平台显示在 log、实际 DaemonSet 在别处" 的状态漂移。 === 实测（0108617e4180）=== 现有采集器 promtail-pre: type=k8s-daemonset namespace='log' PUT {"namespace":"evil-ns"} → 返回 success，但读回仍是 'log' ✅ 被忽略 tsc 通过；Pod = Hub latest = 0108617e4180	2026-10-31 01:56:15 +00:00
logan	2e97c04f84	fix(db): 修复 NextID 与写锁重入死锁 ... - NextID 改用独立 seqMu，不再依赖数据写锁，杜绝 Lock 内调用 NextID 的死锁 - CaptureAppVolumeForHour 先取 ID 再 Lock - 新增写锁看门狗：长时间占用时转储 goroutine 栈 - 新增 TestNextIDWhileWriteLocked 回归测试	2026-10-31 02:20:34 +08:00
opsx	f1fc7b4a9a	fix(analysis): 排行分页后名次从 1 重新开始，应为 11/21… ... 现象：翻到第 2 页，名次列仍是 1~10。 根因：TopAppsTable 用页内下标算名次（index + 1），分页后每页都从 1 开始。 修复：新增 startIndex 参数，由调用方传入当前页在整体排行中的偏移； 分析页传 (page - 1) * 10，于是第 2 页为 11~20、第 3 页 21~30。 实测：tsc 通过；Pod = Hub latest = 9026d0e4c582	2026-10-30 17:50:54 +00:00
opsx	fdd705c4b4	build(release): release.sh 加独占构建锁 + push 重试，杜绝 latest 被并发覆盖 ... === 问题 === 本项目所有清单都指向 `latest`（k8s deployment / docker-compose / prod compose）， 两个构建并发时**谁后完成谁生效**，另一个的推送等于白做。 本次实际踩到：一次被中断的构建后来完成，把 latest 推回了旧镜像 64fb231， 而当前正确版本是 a16978d2；若此时 Pod 重启就会跑回旧代码， 表现是"改了但没生效"，从页面完全看不出来。 === 修复 1：flock 独占锁 === LOCK_FILE=${RELEASE_LOCK_FILE:-/var/lock/lokistack-release.lock} exec 9>"$LOCK_FILE"; flock -n 9 || { 中文提示 + exit 1 } - 锁跟随文件描述符，进程退出（含 Ctrl-C / set -e 中断）自动释放， 不需要手工清理僵尸锁文件 - 失败提示给出：锁路径、查看占用命令（fuser/lsof）、以及"无需手工删锁"的说明 - 支持 RELEASE_LOCK_FILE 换锁路径（多仓库并行发布时用） - 新增 --dry-run：只做前置检查（docker 是否可用、锁能否获取），不构建不推送， 用于验证脚本本身和排查"为什么发布失败" === 修复 2：push 重试 === Docker Hub 偶发 502，实测导致过"v0.1 推成功、latest 失败 → latest 指旧镜像"。 新增 push_with_retry()：每个 tag 最多 3 次，间隔 10 秒，全失败才 exit 1。 三个 tag（latest / v0.1 / 不可变 tag）都走它。 === 实测 === 测试1 无人占用 : 🔒 获取锁成功，退出码 0 测试2 另一进程持有锁 : ❌ 明确拒绝并给出排查命令，退出码 1 测试3 占用进程退出后 : ✅ 自动恢复可用，退出码 0 bash -n 语法检查通过	2026-10-30 17:48:20 +00:00
opsx	d4422f1541	refactor(analysis): 去掉排行 10/30/50 选择器，改为一次取 50 + 前端分页；零点结算昨天 ... === 1. 为什么去掉「显示条数」选择器 === topk 的 N 不影响查询成本（扫描的 chunk 集合完全相同），实测： topk(10) 17833ms / 11 条 topk(30) 18019ms / 34 条 topk(50) 7394ms / 54 条 topk(100) 17553ms / 74 条 波动来自集群负载，与 N 无关 —— 它只决定最后返回多少序列。 所以"选 30"既不更快也不更慢，本质是个翻页开关； 而选它还要重新等一次十几秒的查询，纯亏。 改为：一次 topk(50)，前端 10 条/页 → 5 页只需 1 次查询。 附带收益：占比的分母从"前 10 合计"变成"前 50 合计"，更接近真实占比。 副标题明确写清"一次取前 50 个应用（占比按这 50 个合计计算）"。 === 2. 零点结算昨天（daily volume）=== 原来只有 30 分钟 ticker 回补，且启动时间不对齐整点 → 昨天最早的一段可能已经超出 Loki 24h 保留期被删， 结算结果系统性偏低，图上却标"完整一天"，属静默错数。 新增 nextMidnightFinalize()：每天 00:01 触发 FinalizeYesterdayVolume() - 昨天定稿 partial=false - 补一次条数（index/stats，一天一次可接受） - 顺带刷新今天 partial=true 的柱子 ticker 仍保留，负责当天数据的 30 分钟刷新。 === 3. 顺带 === - 去掉每日量"其中 N 天平台没有留存记录"的提示文案（按用户要求） - 修 QuickQueryTemplates.tsx 的未使用变量导致 tsc -b 失败 - 工作区里上一轮中断的"排行体积列"改动一并纳入（app-ranking 返回 bytes， TopAppsTable 增加体积列，快照记录 per-app 字节数） Pod = Hub latest = a16978d2f88b	2026-10-30 17:13:18 +00:00
opsx	63dd491c5b	fix(daily-volume): 历史快照的 partial 自动修正 + 三个回归测试 ... === 现象 === 仓库里 6 条快照 partial 全是 true（10-27 到 10-30），前端把昨天的柱子 也画成虚线空心，看着像"每天都在采样中"。 === 根因 === 早期实现把两件事都塞进 partial：「今天还没过完」和「起点超出 24h」。 10-27/10-28 的数据现在已经被 retention 删掉、永远不会再被抓一次， 所以这两条错误标记会永久留在库里。 === 修法 === prune 里加幂等修正：过去的天，只有快照是**在那天结束之后**才抓的 （说明抓到的是完整一天）才改成 partial=false；当天中途抓的继续保持 partial （那时确实只有半天，不能伪装成完整数据）。 === 测试（3/3 PASS）=== TestPruneDailyVolumeNormalizesPartialAndDropsExpired · 昨天结束之后抓的 → partial=false · 前天中途抓的 → 保持 partial=true · 今天 → 保持 partial=true · 超留存期 → 被清理 · 条数不被清理流程清空 TestUpsertVolumeSnapshotKeepsEntries 刷新体积不清空已抓到的条数 TestGetDailyVolumeHistoryReturnsAllDaysWithMissing 始终返回 days 个点，缺的标 Missing 不伪造 0 go vet ./services/ ./models/ 干净；go test ./services/ 全绿。	2026-10-30 16:56:39 +00:00
opsx	b7de337c9e	perf(daily-volume): 每日量抓取拆成「体积每 30 分钟 / 条数每天最多 3 次」 ... === 现象 === 用户问：每日日志量不是有定时任务记录吗？为什么还要每次查询？ 盘了一遍发现：定时任务确实有（每 30 分钟），接口也确实只读库（实测 0.1ms）， 但每轮抓取都顺手跑一次**整天 index/stats** 拿条数（实测 6ms ~ 20s，随负载波动）， 2 天 × 多个数据源 × 每 30 分钟 = 一天几十次重查询，纯浪费单实例 Loki 的算力， 还会和用户页面上的查询抢 CPU。 第二条更糟：仓库里所有快照的 partial 全是 true。 根因：partial 里混了两种语义 ——「今天还没过完」和「起点超出 24h」。 后者让昨天/前天的柱子也画成虚线空心，看起来「每天都在进行中」。 === 修法 === 1. 抓取按成本拆成两条路径（体积走 volume_range，条数走 index/stats）： - 体积：今天 + 昨天，每 30 分钟刷，54ms~4s，无感 - 条数：只对**已结束**且 entries==0 的天补，每天最多 3 次、间隔≥1h； 尝试次数**先写库再查**，进程中途被杀也不会退化成每 30 分钟重试 2. partial 只表示「今天还没过完」，昨天起是实心柱 3. 0 与「未留存」分开：起点超出 24h 且查不到数据 → **跳过落库**保持 Missing。 否则「数据被 retention 删掉」会被画成「那天没有日志」，比灰色柱误导得多 4. 每次抓取打日志：`[daily-volume] 2026-10-30 体积 291.37 GB 已落库（volume_range 4.27s，34 个桶）` —— 以后不用猜「到底抓没抓、走的哪条路径」 === 实测取证（本集群）=== Loki 直接查（port-forward :13100）： 10-30(16.8h) volume_range 291.37GB/34桶 index/stats entries=2.21B 10-29(24h) volume_range 121.99GB/19桶 index/stats entries=927.9M 10-28/10-27 volume_range 0 桶、index/stats 0 —— 已被 retention 删掉 同范围 count_over_time 两次 60s 超时（永远别用在每日量上） 平台库里的快照与上述数字一致（288.32 / 121.75 GB），说明落库值可信； 10-27/10-28 的 34.87/25.65 GB 是当时抓的 —— 这正是「Loki 只留 1~3 天， 历史必须自己落库」的实证。 go vet ./services/ ./models/ 干净；go build 通过；go test ./services/ 通过。	2026-10-30 16:52:55 +00:00
opsx	e4cefa1fa7	feat(analysis): 应用排行支持 10/30/50 切换 + 前端分页 ... === 可行性评估（先实测再实现）=== topk 的 N 是否影响查询成本？5 分钟窗口实测： topk(10) 17833ms / 11 条 topk(30) 18019ms / 34 条 topk(50) 7394ms / 54 条 topk(100) 17553ms / 74 条 波动来自集群负载，与 N 无关 —— 扫描的 chunk 集合完全相同， topk 只决定最后返回多少序列。所以放宽到 50 不增加查询成本。 === 分页为什么不每页发一次查询 === 排行是"排序后的聚合结果"：要拿第 11~20 名，必须先算出全部应用的量再排序， 不存在"只算 11~20 名"的做法。所以正确设计是： topk(N) 一次取全 → 前端按 10/页切片 N=50 时 5 页，只查 1 次；每页点一次查询反而会重复扫同一批 chunk，纯浪费。 === 实现 === - hook 参数 rankLimit（10/30/50），两条查询都包 topk(N) - 分析页：显示条数按钮组，点击即触发查询（同时重置到第 1 页） - 分页条：共 N 个应用 · 第 x/y 页 · 上一页/下一页 - 长范围走预聚合时，limit 也跟随 N（接口上限 100） - 切换筛选（刷新）时重置到第 1 页 Pod = Hub latest = 4d4e1a7ec334	2026-10-30 16:51:21 +00:00
opsx	7b1ffd0274	fix(daily-volume): 30/90/365 天切换"没反应"；/logs/stats 加短缓存 ... === 1. 切换范围没反应（真 bug）=== 现象：7/30/90/365 天切换后图完全一样。 根因：GetDailyVolumeHistory 只返回**已抓到的快照**。平台只有 4 天数据， 所以任何 days 都只返回 4 个点 → 图表一模一样。 修复：始终返回 days 个点，缺失的天用 Missing=true 标记。 实测：days=7→7 点(缺3)、30→30 点(缺26)、90→90(缺86)、365→365(缺361)。 为什么必须区分 Missing 和"0 字节"： 前者是"平台没留存"，后者是"那天确实没日志"。 混在一起会让 30/90 天的图上出现大片 0，被误读成"日志量暴跌/系统停摆"。 前端：缺失的天画灰色浅柱，tooltip 显示"未留存"，图下方提示 "其中 N 天平台没有留存记录（灰色柱），不是当天没有日志"。 === 2. /logs/stats 加 90 秒缓存 === 分析页每次进入/切范围都打 index/stats，实测 5 分钟窗口冷查询 1.2 秒 （60 分钟更慢）。这类聚合值可容忍分钟级陈旧，加与指标查询一致的缓存： 90s TTL + 时间窗按 2 分钟取整 + 上限 200 条 + 过期清理 实测：重复请求 1227ms → 8ms。 === 3. 顺带确认已生效的优化 === histogram(24h) : 54ms（volume_range） daily-volume : 10ms（只读库） stats 二次请求 : 8ms（新缓存） 长范围(>1h) : 不跑 count_over_time（预聚合快照 + 跳过内容扫描） Pod = Hub latest = 12453ea723c1	2026-10-30 16:46:40 +00:00
opsx	5c7a3ec81d	perf(daily-volume): 每日量改用 volume_range（20s → 54ms），图表改圆柱 ... === 核心技巧：体积用 index/volume_range，不要用 index/stats === 同为 24 小时、同一 selector，两条索引查询差 370 倍： index/stats : 整天聚合，实测 20s 直接超时（之前每日量接口卡 20s 的根因） index/volume_range: 按 step 分桶只累加 chunk 字节，实测 54ms，97 个桶 原因：index/stats 要跨全部 chunk 去重统计 streams/entries； volume_range 只把索引里记录的 chunk 字节数按时间桶求和，不解码内容。 === 后端改动 === services/daily_volume.go： 体积：LokiHistogram（走 volume_range，step 由跨度自动选）→ 累加 54ms 条数：只能 index/stats，降级为「尽力而为」25s 超时； 拿不到就保留上一次的值（不能因为一次超时把历史条数清零）， 绝不让它拖住体积入库。 前端图只画体积，条数缺失不影响可读性。 === 前端改动 === DailyVolumeChart：AreaChart（面积）→ BarChart（圆柱） 顶部圆角 radius=[6,6,0,0]、渐变填充、maxBarSize=44 当天未结束的柱子用半透明 + 虚线描边区分，避免把"才过半天"误读成"量掉了" === 实测 === 24h volume_range: 54ms，97 桶，合计 369.61 GB（与全集群 ~370GB/天 吻合） /logs/daily-volume 接口: 10ms（读库） Pod = Hub latest = 4cdc8b9c4841	2026-10-30 16:40:49 +00:00
opsx	d0adc095dd	feat(analysis): 长范围应用排行改走「小时级预聚合」，不再扫日志内容 ... === 问题（实测）=== 按应用排行必须读日志内容（Loki 3.4 的 index/volume 不支持 app 维度聚合， aggregateBy=app 无效），成本 ∝ 时间范围： 5 分钟 ≈ 1.3GB → 9.8s 15 分钟 ≈ 3.9GB → 19.5s 1 小时 ≈ 15GB → 预计 60~90s 6 小时 ≈ 92GB → 5~8 分钟 24 小时 ≈ 370GB → 不可用 用户在时间范围里选 6h/24h 时，页面必然卡死。 === 方案 === 新增 models.AppVolumeSnapshot + services/app_volume.go： - 后台任务每小时第 5 分钟抓「上一个完整小时」的 per-app 条数 - 用**瞬时查询**（/loki/api/v1/query + [1h]）而不是 query_range： 单点评估、扫描量相同、省掉多步开销；并绕开 LokiMetrics 的 90s 上限 与重型查询信号量（后台任务不该和前台抢令牌） - 每源每小时只留 top 50 应用，保留 90 天 - 幂等：同 (hour, source, ns, app) 更新而非重复插入 - 超出 Loki 26h 保留期的窗口跳过（抓也抓不到，白等几分钟） 新增 GET /api/v1/logs/app-ranking?sourceId&from&to&limit → 读库毫秒级 前端：analysis 判断范围 > 60 分钟就走预聚合接口，并停掉实时重查询 （rankingEnabled 置 false）；表格副标题说明「读的是预聚合快照，已留存 N 小时， 不含错误数与趋势」。 === 顺带修掉的根因 bug === useInView 原来用 useRef + useEffect([inView])：分析页首屏 data===null 时 内容块不渲染，ref.current 为 null，effect 直接 return；等数据到了 DOM 才挂上， 但依赖没变 → effect 不重跑 → IntersectionObserver 从未创建 → inView 永远 false → 重查询永不发出 → 页面一直显示"没有应用维度的数据"。 改成 callback ref（节点挂载即作为依赖），并加 scroll/resize 兜底 + 挂载瞬间量一次。 另外分析页加 8 秒无条件兜底：可见性判定再失灵，8 秒后也一定查一次。 默认时间范围 15 分钟 → 5 分钟（19.5s → 9.8s）。 === 实测 === Pod = Hub latest = 98de87e7f895 5 分钟窗口 by-app：9.8s（75 序列）；15 分钟：19.5s	2026-10-30 16:35:35 +00:00