6 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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	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	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