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
This commit is contained in:
opsx committed 2026-10-28 23:43:14 +00:00
1 parent fbefcc86df
commit 607b67a2ed
8 files changed
+95 -44

No files matched your search

+11 -5
View File
@@ -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)
+7 -4
View File
@@ -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)补齐内置规则:
+42
View File
@@ -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
+2 -2
View File
@@ -45,8 +45,8 @@ export default {
empty: 'No app-dimension data',
},
pie: {
title: 'App volume distribution',
subtitle: 'Who is flooding the logs (top 8 apps, rest grouped as Other)',
title: 'Top 5 apps by volume',
subtitle: 'Top 5 apps by log lines, the rest grouped as Other',
empty: 'No app-dimension data',
other: 'Other',
},
+3 -2
View File
@@ -1,6 +1,7 @@
// 日志分析页(admin)— 经 i18n/domains.ts 注册,页面入口 import '@/i18n/domains'
export default {
title: '日志分析',
subtitle: '按应用与命名空间看日志量、错误与趋势,找出最吵的业务',
adminOnly: {
title: '仅管理员可访问',
desc: '日志分析面向管理员提供全量日志统计,请联系管理员开通。',
@@ -44,8 +45,8 @@ export default {
empty: '没有应用维度的数据',
},
pie: {
title: '应用日志量分布',
subtitle: '按应用看谁在刷日志(前 8 名,其余归入"其他")',
title: '应用日志量 Top 5',
subtitle: '按日志条数排前 5 的应用,其余归入"其他"',
empty: '没有应用维度的数据',
other: '其他',
},
@@ -4,7 +4,7 @@ import { useTranslation } from 'react-i18next'
import { chartColors, compactNumber } from './chart-shared'
import { EmptyChart } from './EmptyChart'
const TOP_SLICES = 8
const TOP_SLICES = 5
/** 命名空间分布环形饼图 + 侧边图例(超过 8 个归并「其他」) */
export const NamespacePie = memo(function NamespacePie({ shares }: { shares: Array<{ name: string; count: number }> }) {
+29 -26
View File
@@ -123,12 +123,15 @@ const AnalysisPage = memo(function AnalysisPage() {
const dailyView = useInView<HTMLDivElement>()
const rankingView = useInView<HTMLDivElement>()
const ingressView = useInView<HTMLDivElement>()
// ⚠️ 不门控这条查询:顶部的「活跃应用」「应用日志量分布」「应用日志量流图」
// 都依赖 by-app 数据,而它原来被底部排行卡片的可见性门控 ——
// 用户不滚到底就永远拿不到数据,表现为"三条都没有应用维度的数据"。
// 现在进页面就发,页面用两阶段渲染:索引类指标先出,app 维度到货后补。
const { data, loading, error, appLabel, refresh } = useAnalysisMetrics({
sourceId: effectiveSourceId,
start,
end,
namespace: scopedNamespace,
rankingEnabled: rankingView.inView,
})
// 每日统计固定近 7 天,不随上方时间范围变化;错误就地展示,不影响主区
// 每日量可看范围:7 / 30 / 90 / 365 天(数据来自平台留存历史)
@@ -253,31 +256,6 @@ const AnalysisPage = memo(function AnalysisPage() {
<CardContent><AppStreamChart apps={data.apps} appTimes={data.appTimes} /></CardContent>
</Card>
<div ref={dailyView.ref}>
<Card>
<CardHeader className="pb-3">
<div className="flex flex-wrap items-center gap-2">
<CardTitle className="text-base">{t('daily.title')}</CardTitle>
<span className="rounded-full bg-success/10 px-2 py-0.5 text-[11px] font-medium text-success">{t('daily.badge')}</span>
</div>
<p className="text-xs text-muted-foreground">{t('daily.subtitle')}</p>
</CardHeader>
<CardContent>
{daily.error ? (
<ErrorState message={daily.error} onRetry={daily.refresh} />
) : daily.loading && !daily.data ? (
<LoadingSpinner className="h-40" />
) : (
<DailyVolumeChart
points={daily.data?.points ?? []}
days={dailyDays}
onDaysChange={setDailyDays}
/>
)}
</CardContent>
</Card>
</div>
<div ref={rankingView.ref}>
<Card>
<CardHeader className="pb-3">
@@ -307,6 +285,31 @@ const AnalysisPage = memo(function AnalysisPage() {
</Card>
</div>
<div ref={dailyView.ref}>
<Card>
<CardHeader className="pb-3">
<div className="flex flex-wrap items-center gap-2">
<CardTitle className="text-base">{t('daily.title')}</CardTitle>
<span className="rounded-full bg-success/10 px-2 py-0.5 text-[11px] font-medium text-success">{t('daily.badge')}</span>
</div>
<p className="text-xs text-muted-foreground">{t('daily.subtitle')}</p>
</CardHeader>
<CardContent>
{daily.error ? (
<ErrorState message={daily.error} onRetry={daily.refresh} />
) : daily.loading && !daily.data ? (
<LoadingSpinner className="h-40" />
) : (
<DailyVolumeChart
points={daily.data?.points ?? []}
days={dailyDays}
onDaysChange={setDailyDays}
/>
)}
</CardContent>
</Card>
</div>
{/* Ingress 分析要按 host/status 做多次聚组查询,最后加载 */}
<div ref={ingressView.ref as React.Ref<HTMLDivElement>}>
{ingressView.inView && <IngressAnalysisSection sourceId={sourceId} start={start} end={end} />}
-4
View File
@@ -12,7 +12,6 @@ import { ErrorState } from '@/components/ErrorState'
import { useDashboardStats } from './hooks/useDashboardStats'
import { StatCard } from '@/components/StatCard'
import { RecentDeploymentsCard } from './components/RecentDeploymentsCard'
import { SelfCheckCard } from './components/SelfCheckCard'
import { ResourceListCard } from './components/ResourceListCard'
import type { DashboardStats } from '@/types'
@@ -123,9 +122,6 @@ const DashboardPage = memo(function DashboardPage() {
</Card>
)}
{/* 一键自检:把「哪里坏了」的判断收敛到仪表盘首屏 */}
<SelfCheckCard />
{/* Stats Cards */}
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-4 gap-4">
{statCards}