Files
opsx ad0d35f72a
CI / Backend (go vet + test) (push) Canceled after 0s
CI / Frontend (lint + build + test) (push) Canceled after 0s
feat(alerts,logs): A 方案—告警窗口 15m→5m 消重复扫描;数据源可编辑/删除且删后不被自动重建
=== 1. 告警窗口 15m → 5m(阈值同比例 1/3)===
背景:检查间隔已改 5 分钟,但规则窗口仍是 15 分钟 ——
同一个 15 分钟窗口每 5 分钟被完整重扫一遍,等于 3 倍重复扫描。
在 370GB/天、全命名空间 selector 下,这是 Loki CPU 的最大稳态来源。

    FATAL            10 → 4        窗口 5m
    Go panic         10 → 4        窗口 5m
    JVM OOM           5 → 2        窗口 5m
    StackOverflow     5 → 2        窗口 5m
    应用错误激增  100000 → 35000    窗口 5m(改名 error > 3.5万)
    ingress 5xx      2000 → 700    窗口 5m
    ingress 4xx     20000 → 7000   窗口 5m
    DB 连接失败      1000 → 350    窗口 5m

阈值按 1/3 缩放是必须的:窗口缩短 3 倍后,同样的流量在 5 分钟内只有
1/3 的条数,阈值不动就永远打不到了。
迁移 v10→v11 只改"窗口仍是 15 且名字匹配内置规则"的项,用户手调的不动。

=== 2. 数据源支持编辑/删除(含托管源)===
原来前后端都把托管源锁死:
  - 前端 `!managed &&` 直接不渲染编辑/删除按钮
  - 后端 DeleteSource 返回「平台部署的数据源随部署管理,请先删除对应部署」
用户的诉求是"数据源必须能编辑和删除",且确实有场景(不想让某个源出现在
查询下拉里、想改认证头)。

=== 3. 修「删了又回来」的真 bug ===
EnsureLogSourcesForRunningDeployments() 在 **每次打开数据源列表和启动时**
都会给 running 部署补齐数据源 —— 所以删掉托管源后,刷新页面它又回来了,
用户看到的现象就是"删不掉"。

新增 LokiDeployment.AutoSourceDisabled:
  - 删除托管源时置位(DisableAutoSourceFor)
  - EnsureLogSourceForDeployment 见到该开关直接 return
  - 部署被编辑/重新部署时重置(EnableAutoSourceFor),即"你要用它了就恢复"
前端配套文案:
  - 编辑托管源弹窗提示"重新部署会覆盖集群/Service/端口,认证与请求头保留"
  - 删除确认明确"删除后不会再自动重建,重新部署该 Loki 才恢复"

=== 实测(20300eef92d2)===
  v11 迁移后 8 条规则全部 窗口=5m,阈值 4/4/2/2/35000/700/7000/350
  go test ./... 全绿
2026-10-30 15:28:30 +00:00

194 lines
8.6 KiB
Go

package seed
// 内置告警规则 — 新环境开箱即用的通用日志告警(参照运维告警脚本的两类模式):
// 致命类(出现即报):FATAL / panic / OutOfMemoryError / StackOverflowError
// 突增类(超阈值才报):应用 error 过多 / ingress-nginx 4xx / 5xx
// 绑定数据源:部署成功自动注册的 LogSource(managed)。
// 规则默认启用并绑定「默认告警」通道:管理员只需在设置页给默认通道填好 Webhook 并启用即可收告警;
// 通道未就绪时命中只会把失败原因写进发送历史,不影响规则评估。
import (
"slices"
"strings"
"time"
"lokistack/models"
"lokistack/repository"
)
type builtinRule struct {
name string
query string
windowMin int
threshold int
cooldown int
}
// 阈值设计原则(踩过坑,写清楚免得后来人再调回 0):
//
// 1. **绝不用 threshold: 0**
// 0 表示"命中一条就报"。日志平台里一条 FATAL 或一个 error 关键字
// 在高峰期每秒就有几百条,阈值 0 等于把告警变成日志流的复读机
// (实测某环境 15 分钟 3051 万条 → 一直报警)。
// 2. 默认阈值按 **15 分钟窗口 + 大集群基线** 取,
// 宁可漏报一点,也不要让运维对告警脱敏——告警疲劳比漏报更致命。
// 3. cooldown 统一 ≥ 120 分钟:同一问题 2 小时内只提醒一次。
// 4. 绝对阈值天然不跨环境通用,大集群(如 300GB/天)必须按 app/namespace
// 收窄查询,否则任何阈值都会被常态流量击穿。这一点在 UI 上有提示。
//
// ensurePlaceholderChannel 返回一个可挂靠的通道 ID:
// 已有通道取第一个;没有则建一个禁用的占位通道。
func ensurePlaceholderChannel(db *repository.JsonDB) uint {
db.Lock()
defer db.Unlock()
if len(db.NotifyChannels) > 0 {
return db.NotifyChannels[0].ID
}
next := uint(0)
for _, ch := range db.NotifyChannels {
if ch.ID > next {
next = ch.ID
}
}
id := next + 1
db.NotifyChannels = append(db.NotifyChannels, models.NotifyChannel{
ID: id,
Name: "默认告警",
Enabled: false,
CreatedAt: time.Now(),
UpdatedAt: time.Now(),
})
return id
}
// channelIDsFor 把单个通道 ID 包成切片;0 表示没有可用通道(保持空)。
func channelIDsFor(id uint) []uint {
if id == 0 {
return nil
}
return []uint{id}
}
var builtinRules = []builtinRule{
// —— 致命类:这类日志本该极少出现,但也不能一条就报 ——
// 全命名空间类查询一律排除 app=loki:Loki 会把执行过的查询语句记成自身 info 日志,
// 查询文本包含规则关键字时告警会"命中自己",造成持续误报。
{name: "致命日志 FATAL", query: `{namespace=~".+", app!="loki"} |= "FATAL"`, windowMin: 5, threshold: 4, cooldown: 120},
{name: "Go panic", query: `{namespace=~".+", app!="loki"} |= "panic:"`, windowMin: 5, threshold: 4, cooldown: 120},
{name: "JVM OutOfMemoryError", query: `{namespace=~".+", app!="loki"} |~ "(^|[^a-zA-Z])OutOfMemoryError"`, windowMin: 5, threshold: 2, cooldown: 120},
{name: "StackOverflowError", query: `{namespace=~".+", app!="loki"} |= "StackOverflowError"`, windowMin: 5, threshold: 2, cooldown: 120},
// 注意:这里**只放日志类告警**。
// 「节点 NotReady」「容器 OOMKilled」属于基础设施指标监控(kube-state-metrics /
// Prometheus)的职责,用日志去匹配这些字符串既不可靠(日志没开或轮转就漏),
// 又与日志平台的定位混淆。这类告警请交给 Prometheus + Alertmanager。
// —— 突增类:只有明显高于常态才报 ——
// 第二轮上调(500~5000 这一档实测仍然太敏感):
// 这几个量级在业务高峰期本来就是常态,阈值贴着基线就等于"每天准点报警"。
// 原则:宁可只报"明显异常",也不要让人对告警脱敏。
{name: "应用错误激增(error > 3.5万)", query: `{namespace=~".+", app!="loki"} |~ "(?i)\berror\b"`, windowMin: 5, threshold: 35000, cooldown: 240},
{name: "ingress-nginx 5xx 错误", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " (50[0-4]|5[2-9][0-9]) "`, windowMin: 5, threshold: 700, cooldown: 240},
{name: "ingress-nginx 4xx 激增", query: `{app=~"ingress-nginx|nginx-ingress-controller"} |~ " 4[0-9][0-9] "`, windowMin: 5, threshold: 7000, cooldown: 240},
// 数据库连接类错误:覆盖 MySQL / PostgreSQL / Redis 的主流报错文案
// (详见函数上方注释,不要加裸 "EOF" / "timeout",那会匹配到几乎所有网络日志)
{name: "数据库连接失败", query: `{namespace=~".+", app!="loki"} |~ "(?i)(connection refused|connection reset by peer|broken pipe|no route to host|cannot assign requested address|connection timed out|i/o timeout|too many connections|too many clients already|max number of clients reached|connection pool|connection is not available|could not create connection|communications link failure|server closed the connection unexpectedly|unexpected EOF|driver: bad connection|FATAL:\\s*(password authentication failed|sorry, too many clients|terminating connection)|NOAUTH|WRONGPASS|READONLY you can.t write|CLUSTERDOWN)"`, windowMin: 5, threshold: 350, cooldown: 240},
}
// seedBuiltinAlertRules 为每个平台管理的 LogSource(managed=true)补齐内置规则:
// 首次部署 Loki 后即有一套可直接启用的告警模板;通知通道留空,管理员配置后启用。
// legacyInfraRules 早期版本误种的 Kubernetes 基础设施类规则 —— 日志平台只关注应用日志,
// 这类节点/容器状态告警属 Prometheus + Alertmanager 职责,升级时一次性清理存量。
var legacyInfraRules = []string{
"Kubernetes 节点 NotReady",
"容器 OOMKilled",
// 旧版 seed 遗留:与现模板「应用错误激增」重复,且 1000 阈值实测会误报平台自身查询日志
"应用错误过多(error > 1000)",
}
// SeedAlertRules 补齐内置告警规则(幂等;公开给启动与部署成功两处调用)
func SeedAlertRules() {
// 先清掉历史遗留的基础设施类规则,并把内置规则升级为「默认启用 + 绑默认通道」
// (仅处理从未关联过通道的规则;用户已自行配置过通道的规则不动)
db := repository.GetDB()
defaultChannelID := ensurePlaceholderChannel(db)
builtinNames := make(map[string]bool, len(builtinRules))
for _, r := range builtinRules {
builtinNames[r.name] = true
}
db.Lock()
kept := db.AlertRules[:0]
changed := false
for _, rule := range db.AlertRules {
if slices.Contains(legacyInfraRules, rule.Name) {
changed = true
continue
}
if builtinNames[rule.Name] && strings.Contains(rule.Query, `{namespace=~".+"}`) && !strings.Contains(rule.Query, `app!="loki"`) {
rule.Query = strings.ReplaceAll(rule.Query, `{namespace=~".+"}`, `{namespace=~".+", app!="loki"}`)
rule.UpdatedAt = time.Now()
changed = true
}
if builtinNames[rule.Name] && len(rule.ChannelIDs) == 0 {
rule.ChannelIDs = channelIDsFor(defaultChannelID)
if !rule.Enabled {
rule.Enabled = true
rule.UpdatedAt = time.Now()
}
changed = true
}
kept = append(kept, rule)
}
db.AlertRules = kept
if changed {
db.RequestSave()
}
db.Unlock()
db.RLock()
type srcRef struct {
id uint
name string
}
var sources []srcRef
for i := range db.LogSources {
if db.LogSources[i].Managed {
sources = append(sources, srcRef{id: db.LogSources[i].ID, name: db.LogSources[i].Name})
}
}
// 已有规则(按 name)跳过
existing := map[string]bool{}
for i := range db.AlertRules {
existing[db.AlertRules[i].Name] = true
}
db.RUnlock()
if len(sources) == 0 {
return
}
// 绑定第一个 managed 数据源(通常是唯一部署)
target := sources[0]
// 内置规则一律挂到默认通知通道。
// 首次部署没有任何通道时,这里建一个**禁用**的占位通道(Webhook 留空):
// - 规则不会变成"孤儿"(发送历史会明确写"通道未投递"而不是静默)
// - 管理员填好 Webhook 再启用即可,不必逐条给规则关联通道
// - 之所以不放"已启用 + 空地址":那样每次命中都会投递失败刷屏
// 这里直接操作 db 而不调 services,避免 seed ↔ services 的包循环依赖。
newID := db.NextID("alertRules")
db.Lock()
defer db.Unlock()
for _, r := range builtinRules {
if existing[r.name] {
continue
}
newID++
db.AlertRules = append(db.AlertRules, models.AlertRule{
ID: newID, Name: r.name, SourceID: target.id,
Query: r.query, WindowMin: r.windowMin, Threshold: r.threshold,
Enabled: true, CooldownMin: r.cooldown,
ChannelIDs: channelIDsFor(defaultChannelID),
CreatedAt: time.Now(), UpdatedAt: time.Now(),
})
}
db.RequestSave()
}