From fa7ddd67c122d6d6bac431c345964a238ddb259c Mon Sep 17 00:00:00 2001 From: opsx Date: Wed, 28 Oct 2026 22:20:19 +0000 Subject: [PATCH] =?UTF-8?q?perf(analysis):=20=E5=88=86=E6=9E=90=E9=A1=B5?= =?UTF-8?q?=E6=8C=89=E7=B4=A2=E5=BC=95/=E5=86=85=E5=AE=B9=E5=88=86?= =?UTF-8?q?=E5=B1=82=EF=BC=8C=E5=91=8A=E8=AD=A6=E9=BB=98=E8=AE=A4=E9=98=88?= =?UTF-8?q?=E5=80=BC=E6=8A=AC=E9=AB=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit === 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，正常返回数据 --- backend/repository/db.go | 70 ++++++++++++++++-- backend/seed/alert_rules.go | 31 +++++--- backend/services/log_query.go | 32 +++++---- .../analysis/hooks/useAnalysisMetrics.ts | 26 +++++-- .../pages/analysis/hooks/useDailyVolume.ts | 71 ++++++++----------- frontend/src/pages/analysis/index.tsx | 8 ++- 6 files changed, 161 insertions(+), 77 deletions(-) diff --git a/backend/repository/db.go b/backend/repository/db.go index 3015523..c447f51 100644 --- a/backend/repository/db.go +++ b/backend/repository/db.go @@ -5,8 +5,8 @@ import ( "fmt" "log" "os" - "strings" "path/filepath" + "strings" "sync" "time" @@ -46,7 +46,7 @@ type JsonDB struct { // （例如新增 ScrapeJobs 时老数据要手写兼容）。有了版本号， // 以后的结构变更可以在 InitDB 里按版本号顺序迁移，可测、可回滚。 SchemaVersion int `json:"schemaVersion"` - sequences map[string]uint + sequences map[string]uint // 防抖保存机制 saveTimer *time.Timer @@ -62,6 +62,55 @@ func GetDB() *JsonDB { return db } +// alertThresholdUpgrade 记录"旧种子阈值 → 新基线"的映射。 +// +// 只在规则阈值**仍等于旧默认值**时才升级，避免覆盖用户自己调过的值。 +type alertThresholdUpgrade struct { + oldName string + newName string + oldThreshold int + newThreshold int + newCooldown int +} + +var alertThresholdUpgrades = []alertThresholdUpgrade{ + {oldName: "致命日志 FATAL", newName: "致命日志 FATAL", oldThreshold: 0, newThreshold: 10, newCooldown: 120}, + {oldName: "Go panic", newName: "Go panic", oldThreshold: 0, newThreshold: 10, newCooldown: 120}, + {oldName: "JVM OutOfMemoryError", newName: "JVM OutOfMemoryError", oldThreshold: 0, newThreshold: 5, newCooldown: 120}, + {oldName: "StackOverflowError", newName: "StackOverflowError", oldThreshold: 0, newThreshold: 5, newCooldown: 120}, + {oldName: "应用错误过多(error > 1000)", newName: "应用错误激增(error > 5万)", oldThreshold: 1000, newThreshold: 50000, newCooldown: 120}, + {oldName: "ingress-nginx 5xx 错误", newName: "ingress-nginx 5xx 错误", oldThreshold: 100, newThreshold: 500, newCooldown: 120}, + {oldName: "ingress-nginx 4xx 激增", newName: "ingress-nginx 4xx 激增", oldThreshold: 1000, newThreshold: 5000, newCooldown: 120}, + {oldName: "数据库连接失败", newName: "数据库连接失败", oldThreshold: 50, newThreshold: 200, newCooldown: 120}, +} + +// raiseLegacyAlertThresholds 抬高仍是旧默认值的告警阈值与冷却时间。 +func (d *JsonDB) raiseLegacyAlertThresholds() { + byName := map[string]alertThresholdUpgrade{} + for _, u := range alertThresholdUpgrades { + byName[u.oldName] = u + } + for i := range d.AlertRules { + rule := &d.AlertRules[i] + u, ok := byName[rule.Name] + if !ok { + continue + } + if rule.Threshold != u.oldThreshold { + // 用户已经手动调过，尊重用户设置 + continue + } + old := rule.Threshold + rule.Threshold = u.newThreshold + rule.Name = u.newName + if rule.CooldownMin < u.newCooldown { + rule.CooldownMin = u.newCooldown + } + log.Printf("[schema] 告警规则 %q 阈值 %d → %d（冷却 %dm），降低告警频率", + u.newName, old, u.newThreshold, rule.CooldownMin) + } +} + // fixUnreachableLogSourceURLs 把数据源里 0.0.0.0 / [::] 的监听地址换成主机真实 IP。 // // 平台进程不在被采集主机上，0.0.0.0 只在本机有意义，用它必然连不上。 @@ -109,9 +158,10 @@ func (d *JsonDB) fixUnreachableLogSourceURLs() { // // 背景：这些集合曾经都漏在 InitDB 的 sequences 重建之外，导致 NextID 每次 // 进程重启都从 1 开始，于是不同时期创建的对象会撞号。撞号后的表现各不相同： -// LogSource : 查询页数据源下拉选不动（两个 option 同 value） -// AlertRule : 规则列表出现两条同 id，编辑/删除操作命中错的那条 -// NotifyChannel: 通知渠道覆盖错对象 +// +// LogSource : 查询页数据源下拉选不动（两个 option 同 value） +// AlertRule : 规则列表出现两条同 id，编辑/删除操作命中错的那条 +// NotifyChannel: 通知渠道覆盖错对象 func (d *JsonDB) dedupeCollectionIDs() { d.dedupeLogSourceIDs() d.dedupeAlertRuleIDs() @@ -294,7 +344,7 @@ func (d *JsonDB) dedupeLogSourceIDs() { // // v0/v1（无字段）→ 1：新增 auditLogs / schemaVersion（老库走零值兜底即可，无需处理） // v1 → 2：预留示例（如把 ScrapeJobs 从 logPath 拆分时，需按旧结构生成默认 job） -const CurrentSchemaVersion = 4 +const CurrentSchemaVersion = 5 // migrateSchema 按版本号顺序迁移老库。返回是否发生了迁移（需要回写）。 func (d *JsonDB) migrateSchema() bool { @@ -339,6 +389,14 @@ func (d *JsonDB) migrateSchema() bool { // 前端表现为「命名空间/App 下拉永远加载中」。 d.fixUnreachableLogSourceURLs() d.SchemaVersion = 4 + case 4: + // v4 → v5：抬高内置告警规则的默认阈值。 + // + // 旧种子里有 4 条 threshold=0（命中一条就报），另外几条绝对值也偏低： + // 实测某环境 15 分钟 3051 万条日志 → 告警永远在响，运维直接脱敏。 + // 只改"仍等于旧默认值"的规则，用户手动调过的阈值不动。 + d.raiseLegacyAlertThresholds() + d.SchemaVersion = 5 default: // 防御：出现未知版本（比当前代码还新）时不乱动，避免降级把数据写坏 log.Printf("[schema] 数据库版本 %d 高于当前代码支持版本 %d，跳过迁移", d.SchemaVersion, CurrentSchemaVersion) diff --git a/backend/seed/alert_rules.go b/backend/seed/alert_rules.go index fc87250..6ba22dc 100644 --- a/backend/seed/alert_rules.go +++ b/backend/seed/alert_rules.go @@ -20,21 +20,32 @@ type builtinRule struct { cooldown int } +// 阈值设计原则（踩过坑，写清楚免得后来人再调回 0）： +// +// 1. **绝不用 threshold: 0** +// 0 表示"命中一条就报"。日志平台里一条 FATAL 或一个 error 关键字 +// 在高峰期每秒就有几百条，阈值 0 等于把告警变成日志流的复读机 +// （实测某环境 15 分钟 3051 万条 → 一直报警）。 +// 2. 默认阈值按 **15 分钟窗口 + 大集群基线** 取， +// 宁可漏报一点，也不要让运维对告警脱敏——告警疲劳比漏报更致命。 +// 3. cooldown 统一 ≥ 120 分钟：同一问题 2 小时内只提醒一次。 +// 4. 绝对阈值天然不跨环境通用，大集群（如 300GB/天）必须按 app/namespace +// 收窄查询，否则任何阈值都会被常态流量击穿。这一点在 UI 上有提示。 var builtinRules = []builtinRule{ - // —— 致命类:15 分钟内出现即报 —— - {name: "致命日志 FATAL", query: `{namespace=~".+"} |= "FATAL"`, windowMin: 15, threshold: 0, cooldown: 60}, - {name: "Go panic", query: `{namespace=~".+"} |= "panic:"`, windowMin: 15, threshold: 0, cooldown: 60}, - {name: "JVM OutOfMemoryError", query: `{namespace=~".+"} |~ "(^|[^a-zA-Z])OutOfMemoryError"`, windowMin: 15, threshold: 0, cooldown: 60}, - {name: "StackOverflowError", query: `{namespace=~".+"} |= "StackOverflowError"`, windowMin: 15, threshold: 0, cooldown: 60}, + // —— 致命类：这类日志本该极少出现，但也不能一条就报 —— + {name: "致命日志 FATAL", query: `{namespace=~".+"} |= "FATAL"`, windowMin: 15, threshold: 10, cooldown: 120}, + {name: "Go panic", query: `{namespace=~".+"} |= "panic:"`, windowMin: 15, threshold: 10, cooldown: 120}, + {name: "JVM OutOfMemoryError", query: `{namespace=~".+"} |~ "(^|[^a-zA-Z])OutOfMemoryError"`, windowMin: 15, threshold: 5, cooldown: 120}, + {name: "StackOverflowError", query: `{namespace=~".+"} |= "StackOverflowError"`, windowMin: 15, threshold: 5, cooldown: 120}, // 注意：这里**只放日志类告警**。 // 「节点 NotReady」「容器 OOMKilled」属于基础设施指标监控（kube-state-metrics / // Prometheus）的职责，用日志去匹配这些字符串既不可靠（日志没开或轮转就漏）， // 又与日志平台的定位混淆。这类告警请交给 Prometheus + Alertmanager。 - // —— 突增类:超过基线阈值才报 —— - {name: "应用错误过多(error > 1000)", query: `{namespace=~".+"} |~ "(?i)\berror\b"`, windowMin: 15, threshold: 1000, cooldown: 60}, - {name: "ingress-nginx 5xx 错误", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " (50[0-4]|5[2-9][0-9]) `, windowMin: 15, threshold: 100, cooldown: 60}, - {name: "ingress-nginx 4xx 激增", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " 4[0-9][0-9] "`, windowMin: 15, threshold: 1000, cooldown: 60}, - {name: "数据库连接失败", query: `{namespace=~".+"} |~ "(?i)(connection refused|connection reset by peer|too many connections)"`, windowMin: 15, threshold: 50, cooldown: 60}, + // —— 突增类：只有明显高于常态才报 —— + {name: "应用错误激增(error > 5万)", query: `{namespace=~".+"} |~ "(?i)\berror\b"`, windowMin: 15, threshold: 50000, cooldown: 120}, + {name: "ingress-nginx 5xx 错误", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " (50[0-4]|5[2-9][0-9]) "`, windowMin: 15, threshold: 500, cooldown: 120}, + {name: "ingress-nginx 4xx 激增", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " 4[0-9][0-9] "`, windowMin: 15, threshold: 5000, cooldown: 120}, + {name: "数据库连接失败", query: `{namespace=~".+"} |~ "(?i)(connection refused|connection reset by peer|too many connections)"`, windowMin: 15, threshold: 200, cooldown: 120}, } // seedBuiltinAlertRules 为每个平台管理的 LogSource(managed=true)补齐内置规则: diff --git a/backend/services/log_query.go b/backend/services/log_query.go index e9af305..dde1e84 100644 --- a/backend/services/log_query.go +++ b/backend/services/log_query.go @@ -468,35 +468,41 @@ func LokiHistogram(ctx context.Context, src *models.LogSource, query string, sta return nil, fmt.Errorf("统计范围过大（%.1f 天），最多支持 %.0f 天；请缩小时间范围后重试", float64(span)/float64(24*time.Hour), maxHistogramRange.Hours()/24) } - // 并发护栏：拿不到令牌立刻返回，不排队（排队只会让用户等更久） - if !acquireHeavyQuery() { - return nil, ErrTooManyQueries - } - defer releaseHeavyQuery() - - // 独立超时：Loki 侧再慢也不会超过 30s，防止单查询长期占用实例 - ctx, cancel := context.WithTimeout(ctx, heavyQueryTimeout) - defer cancel() - step := pickHistogramStep(span) // ── 首选：Loki 官方的 index/volume_range ────────────────────────────── // 它只读 TSDB 索引里的 chunk 元数据（字节数），**不解码日志内容**。 // 实测同一条件 24 小时：count_over_time 53s 超时失败，volume_range 111ms。 // 返回单位是「字节」，所以 bucket 里带 unit=bytes，前端据此格式化为 KB/MB/GB。 + // + // ⚠️ 这条路径**不占用重型查询令牌**： + // 索引查询本身是毫秒级的，如果和 count_over_time 之类要读 chunk 的查询抢 + // 同一个信号量，就会出现"图表明明 0 秒能出，却因为别人在跑分析查询而排队 + // 十秒、最后 429/超时"的怪现象（分析页实际踩过）。 q := url.Values{} q.Set("query", query) q.Set("start", strconv.FormatInt(start, 10)) q.Set("end", strconv.FormatInt(end, 10)) q.Set("step", step) q.Set("limit", "50") - if body, status, err := lokiProxyGET(ctx, src, "/loki/api/v1/index/volume_range", q); err == nil && status < 400 { + idxCtx, idxCancel := context.WithTimeout(ctx, 15*time.Second) + if body, status, err := lokiProxyGET(idxCtx, src, "/loki/api/v1/index/volume_range", q); err == nil && status < 400 { if buckets, ok := parseVolumeBuckets(body); ok { + idxCancel() return buckets, nil } } - // 老版本 Loki 没有 volume_range（404/400）时回退到 count_over_time - return lokiHistogramByCount(ctx, src, query, step, start, end) + idxCancel() + + // ── 回退：老版本 Loki 没有 volume_range 时才走 count_over_time ── + // 这条要真读 chunk，才需要抢重型令牌 + 长超时。 + if !acquireHeavyQuery() { + return nil, ErrTooManyQueries + } + defer releaseHeavyQuery() + heavyCtx, cancel := context.WithTimeout(ctx, heavyQueryTimeout) + defer cancel() + return lokiHistogramByCount(heavyCtx, src, query, step, start, end) } // parseVolumeBuckets 解析 index/volume_range 的 matrix 响应。 diff --git a/frontend/src/pages/analysis/hooks/useAnalysisMetrics.ts b/frontend/src/pages/analysis/hooks/useAnalysisMetrics.ts index ff9d9f7..d6591ed 100644 --- a/frontend/src/pages/analysis/hooks/useAnalysisMetrics.ts +++ b/frontend/src/pages/analysis/hooks/useAnalysisMetrics.ts @@ -160,15 +160,33 @@ export function useAnalysisMetrics({ sourceId, start, end, namespace }: Analysis }, })) - // ── 第二步：错误/警告/app 维度仍需读日志内容，串行执行 ── - const [errorSeries, warnSeries, byAppSeries, errByAppSeries] = await runInBatches([ - () => fetchRetry(`sum(count_over_time(${selector} |= "error"[$step]))`), - () => fetchRetry(`sum(count_over_time(${selector} |= "warn"[$step]))`), + // ── 第二步：app 维度仍需读日志内容，串行执行 ── + // + // 原来这里有 4 条重查询（全局 total / 全局 error / 全局 warn / by-app ×2）， + // 每条在 astralx 上约 14~29 秒，串行下来一两分钟，用户只看到转圈。 + // 现在只留 2 条 by-app 查询： + // - 全局总量已由上面的 histogram（索引）提供，不用再查 + // - 全局 error 由 errByApp 各序列求和得出，不用再查 + // - 全局 warn 直接放弃（优先级最低，却要花 20 秒；趋势图里留空而不是假装 0） + const [byAppSeries, errByAppSeries] = await runInBatches([ () => fetchRetry(`sum by (${appLabel}, namespace) (count_over_time(${selector}[$step]))`), () => fetchRetry(`sum by (${appLabel}, namespace) (count_over_time(${selector} |= "error"[$step]))`), ]) if (version !== versionRef.current) return + // 由 by-app 序列反推全局 error / warn 曲线，省掉两条重查询 + const sumByTimestamp = (series: MetricSeries[]) => { + const acc = new Map() + for (const item of series) { + for (const point of item.points) { + acc.set(point.timestamp, (acc.get(point.timestamp) ?? 0) + point.value) + } + } + return [{ labels: {}, points: [...acc.entries()].map(([timestamp, value]) => ({ timestamp, value })) }] as MetricSeries[] + } + const errorSeries = sumByTimestamp(errByAppSeries) + const warnSeries: MetricSeries[] = [] + // 应用聚合:统一到最长序列的时间桶上;跨命名空间求和 let times: string[] = [] for (const item of byAppSeries) if (item.points.length > times.length) times = item.points.map(point => point.timestamp) diff --git a/frontend/src/pages/analysis/hooks/useDailyVolume.ts b/frontend/src/pages/analysis/hooks/useDailyVolume.ts index b1ffbcd..e293bcd 100644 --- a/frontend/src/pages/analysis/hooks/useDailyVolume.ts +++ b/frontend/src/pages/analysis/hooks/useDailyVolume.ts @@ -56,55 +56,42 @@ export function useDailyVolume({ sourceId, namespace, appLabel }: { setLoading(true) setError('') try { - const series = await logsApi.metrics( - { sourceId, start: Number(ns(start)), end: Number(ns(end)), query: `sum by (${appLabel}, namespace) (count_over_time(${selector}[$step]))` }, + // 走索引接口而不是 count_over_time。 + // + // 原来这条查 7 天 × count_over_time，实测该环境约 370GB/天 → 要扫 2.6TB， + // 后端 90s 也跑不完，图表永远空/超时。 + // /logs/histogram 内部用 index/volume_range，只读 chunk 元数据， + // 7 天跨度也是毫秒级；代价是**只能拿到总量，拿不到 per-app 拆分** + // （Loki 的索引接口不支持按任意 label 分组）。 + // 因此这里展示"每日日志总量"，应用维度交给下方的 Top 应用表格（它有单独的时间范围）。 + const hist = await logsApi.histogram( + { sourceId, query: selector, start: Number(ns(start)), end: Number(ns(end)) }, { signal: controller.signal }, ) if (version !== versionRef.current) return - // 小时桶 → 本地日历日分桶(app × 天 累加,并记录各 app 落在哪个命名空间) - const perDay = days.map(() => new Map }>()) - const dayIndexOf = (timestamp: string) => { - const day = Math.floor(new Date(timestamp).getTime() / DAY_MS) * DAY_MS - return days.indexOf(day) + + // 索引返回的是字节数，按本地自然日聚合 + const dayBytes = days.map(() => 0) + for (const bucket of (hist || [])) { + const ts = String((bucket as { timestamp: string }).timestamp ?? '') + const value = Number((bucket as { count: number }).count ?? 0) + const day = Math.floor(new Date(ts).getTime() / DAY_MS) * DAY_MS + const index = days.indexOf(day) + if (index >= 0) dayBytes[index] += value } - for (const item of series) { - const app = item.labels[appLabel] ?? '' - const nsLabel = item.labels.namespace ?? '' - for (const point of item.points) { - const index = dayIndexOf(point.timestamp) - if (index < 0) continue - const bucket = perDay[index] - const entry = bucket.get(app) ?? { total: 0, perNs: new Map() } - entry.total += point.value - entry.perNs.set(nsLabel, (entry.perNs.get(nsLabel) ?? 0) + point.value) - bucket.set(app, entry) - } - } - const merged = new Map }>() - perDay.forEach((bucket, index) => { - for (const [app, entry] of bucket) { - const row = merged.get(app) ?? { totals: days.map(() => 0), total: 0, perNs: new Map() } - row.totals[index] += entry.total - row.total += entry.total - for (const [nsName, count] of entry.perNs) row.perNs.set(nsName, (row.perNs.get(nsName) ?? 0) + count) - merged.set(app, row) - } + setData({ + days: days.map(dayLabel), + apps: [{ + app: '全部应用', + namespace: namespace || '', + totals: dayBytes, + total: dayBytes.reduce((sum, value) => sum + value, 0), + }], }) - const apps: DailyAppRow[] = [...merged.entries()] - .map(([app, row]) => ({ - app, - namespace: [...row.perNs.entries()].sort((a, b) => b[1] - a[1])[0]?.[0] ?? '', - totals: row.totals, - total: row.total, - })) - .filter(row => row.total > 0) - .sort((a, b) => b.total - a.total) - .slice(0, 10) - setData({ days: days.map(dayLabel), apps }) + return } catch (err) { - if (version !== versionRef.current) return if ((err as Error).name === 'AbortError') return - setError(err instanceof Error ? err.message : 'metrics failed') + if (version === versionRef.current) setError(err instanceof Error ? err.message : 'daily volume failed') } finally { if (version === versionRef.current) setLoading(false) } diff --git a/frontend/src/pages/analysis/index.tsx b/frontend/src/pages/analysis/index.tsx index 0f2accd..c8bafd1 100644 --- a/frontend/src/pages/analysis/index.tsx +++ b/frontend/src/pages/analysis/index.tsx @@ -112,9 +112,13 @@ const AnalysisPage = memo(function AnalysisPage() { // hook 内部把空串当作 {namespace=~".+"}（全部），这里做哨兵转换 const scopedNamespace = namespace === ALL_NAMESPACES ? '' : namespace - const { data, loading, error, appLabel, refresh } = useAnalysisMetrics({ sourceId, start, end, namespace: scopedNamespace }) + // 等命名空间解析完再发查询： + // 1) 避免首屏先用空 namespace 发一次 {namespace=~".+"} 的全集群查询（很贵） + // 2) 避免"查了两次"——策略返回后 namespace 变化会再查一次，前一次白跑 + const effectiveSourceId = namespaceReady ? sourceId : 0 + const { data, loading, error, appLabel, refresh } = useAnalysisMetrics({ sourceId: effectiveSourceId, start, end, namespace: scopedNamespace }) // 每日统计固定近 7 天,不随上方时间范围变化;错误就地展示,不影响主区 - const daily = useDailyVolume({ sourceId, namespace: scopedNamespace, appLabel }) + const daily = useDailyVolume({ sourceId: effectiveSourceId, namespace: scopedNamespace, appLabel }) // 非 admin:菜单不可见,直访时给明确提示(后端 AdminAuth 403 兜底) if (!isAdmin) {