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

backend/repository/db.go

@@ -80,10 +80,11 @@ var alertThresholdUpgrades = []alertThresholdUpgrade{
 	{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},
+	// 第二轮上调（见 v8 迁移注释）
+	{oldName: "应用错误激增(error > 5万)", newName: "应用错误激增(error > 10万)", oldThreshold: 50000, newThreshold: 100000, newCooldown: 240},
+	{oldName: "ingress-nginx 5xx 错误", newName: "ingress-nginx 5xx 错误", oldThreshold: 500, newThreshold: 2000, newCooldown: 240},
+	{oldName: "ingress-nginx 4xx 激增", newName: "ingress-nginx 4xx 激增", oldThreshold: 5000, newThreshold: 20000, newCooldown: 240},
+	{oldName: "数据库连接失败", newName: "数据库连接失败", oldThreshold: 200, newThreshold: 1000, newCooldown: 240},
 }
 
 // raiseLegacyAlertThresholds 抬高仍是旧默认值的告警阈值与冷却时间。
@@ -408,7 +409,7 @@ func (d *JsonDB) dedupeLogSourceIDs() {
 //
 //	v0/v1（无字段）→ 1：新增 auditLogs / schemaVersion（老库走零值兜底即可，无需处理）
 //	v1 → 2：预留示例（如把 ScrapeJobs 从 logPath 拆分时，需按旧结构生成默认 job）
-const CurrentSchemaVersion = 7
+const CurrentSchemaVersion = 8
 
 // migrateSchema 按版本号顺序迁移老库。返回是否发生了迁移（需要回写）。
 func (d *JsonDB) migrateSchema() bool {
@@ -474,6 +475,11 @@ func (d *JsonDB) migrateSchema() bool {
 			// 已删实例的数据源（线上残留过 host-verify-loki）。
 			d.removeOrphanManagedLogSources()
 			d.SchemaVersion = 7
+		case 7:
+			// v7 → v8：第二轮上调告警阈值 + 拉长冷却，抑制告警风暴。
+			// 500~5000 这一档实测在业务高峰是常态量，贴着基线就等于天天报。
+			d.raiseLegacyAlertThresholds()
+			d.SchemaVersion = 8
 		default:
 			// 防御：出现未知版本（比当前代码还新）时不乱动，避免降级把数据写坏
 			log.Printf("[schema] 数据库版本 %d 高于当前代码支持版本 %d，跳过迁移", d.SchemaVersion, CurrentSchemaVersion)

backend/seed/alert_rules.go

@@ -76,10 +76,13 @@ var builtinRules = []builtinRule{
 	// Prometheus）的职责，用日志去匹配这些字符串既不可靠（日志没开或轮转就漏），
 	// 又与日志平台的定位混淆。这类告警请交给 Prometheus + Alertmanager。
 	// —— 突增类：只有明显高于常态才报 ——
-	{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},
+	// 第二轮上调（500~5000 这一档实测仍然太敏感）：
+	// 这几个量级在业务高峰期本来就是常态，阈值贴着基线就等于"每天准点报警"。
+	// 原则：宁可只报"明显异常"，也不要让人对告警脱敏。
+	{name: "应用错误激增(error > 10万)", query: `{namespace=~".+"} |~ "(?i)\berror\b"`, windowMin: 15, threshold: 100000, cooldown: 240},
+	{name: "ingress-nginx 5xx 错误", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " (50[0-4]|5[2-9][0-9]) "`, windowMin: 15, threshold: 2000, cooldown: 240},
+	{name: "ingress-nginx 4xx 激增", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " 4[0-9][0-9] "`, windowMin: 15, threshold: 20000, cooldown: 240},
+	{name: "数据库连接失败", query: `{namespace=~".+"} |~ "(?i)(connection refused|connection reset by peer|too many connections)"`, windowMin: 15, threshold: 1000, cooldown: 240},
 }
 
 // seedBuiltinAlertRules 为每个平台管理的 LogSource(managed=true)补齐内置规则:

backend/services/alert.go

@@ -16,6 +16,35 @@ import (
 	"lokistack/repository"
 )
 
+// 告警风暴抑制参数：最近 1 小时内全平台最多成功发送多少条。
+//
+// 为什么需要：单规则 cooldown 只能防"同一条重复"，挡不住"多条规则同时炸"。
+// 实测过一次存储抖动让 8 条内置规则同时命中，10 秒内群里刷了 8 条，
+// 之后大家开始无视这个群 —— 告警疲劳比漏报更难挽回。
+const (
+	alertStormWindow     = time.Hour
+	alertStormMaxPerHour = 12
+)
+
+// overStormLimit 判断是否已经触发全局抑制。
+// 返回 (是否抑制, 最近窗口内已发送条数)。
+func overStormLimit() (bool, int) {
+	db := repository.GetDB()
+	if db == nil {
+		return false, 0
+	}
+	cutoff := time.Now().Add(-alertStormWindow)
+	db.RLock()
+	defer db.RUnlock()
+	sent := 0
+	for _, delivery := range db.AlertDeliveries {
+		if delivery.Status == "sent" && delivery.CreatedAt.After(cutoff) {
+			sent++
+		}
+	}
+	return sent >= alertStormMaxPerHour, sent
+}
+
 const alertCheckInterval = time.Minute
 
 var alertTicker *time.Ticker
@@ -230,6 +259,19 @@ func checkRule(ctx context.Context, rule *models.AlertRule) {
 		lines = append(lines, "**日志样例**:\n"+strings.Join(samples, "\n"))
 	}
 
+	// ── 告警风暴抑制：全平台每小时最多发 N 条 ──────────────────────
+	//
+	// 单条规则有 cooldown 只能说"同一条别重复"，挡不住"20 条规则同时炸"。
+	// 实测过：一次存储抖动让 8 条内置规则同时命中，10 秒内往群里刷了 8 条，
+	// 之后大家开始无视这个群。所以再加一道**全局闸门**：
+	// 最近 1 小时内成功发送数达到上限后，后续命中只记"被抑制"，不再发送。
+	// 被抑制的记录仍写进发送历史（可见、可追溯），并写明原因。
+	if suppressed, sentCount := overStormLimit(); suppressed {
+		recordDelivery(rule.ID, rule.Name, count, "cooldown",
+			fmt.Sprintf("告警风暴抑制：最近 1 小时已发送 %d 条（上限 %d），本条未发送", sentCount, alertStormMaxPerHour))
+		return
+	}
+
 	// 扇出到全部关联通道;部分失败记录失败原因(成功任一即更新冷却)
 	title := "🔴 日志告警 " + rule.Name
 	var failMsgs []string