=== 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,正常返回数据
97 lines
4.4 KiB
Go
97 lines
4.4 KiB
Go
package seed
|
|
|
|
// 内置告警规则 — 新环境开箱即用的通用日志告警(参照运维告警脚本的两类模式):
|
|
// 致命类(出现即报):FATAL / panic / OutOfMemoryError / StackOverflowError
|
|
// 突增类(超阈值才报):应用 error 过多 / ingress-nginx 4xx / 5xx
|
|
// 绑定数据源:部署成功自动注册的 LogSource(managed)。
|
|
// 规则默认不启用(通知通道由管理员后期在设置页配置后再开启),ChannelIDs 留空。
|
|
import (
|
|
"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 上有提示。
|
|
var builtinRules = []builtinRule{
|
|
// —— 致命类:这类日志本该极少出现,但也不能一条就报 ——
|
|
{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 > 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)补齐内置规则:
|
|
// 首次部署 Loki 后即有一套可直接启用的告警模板;通知通道留空,管理员配置后启用。
|
|
// SeedAlertRules 补齐内置告警规则(幂等;公开给启动与部署成功两处调用)
|
|
func SeedAlertRules() {
|
|
db := repository.GetDB()
|
|
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]
|
|
|
|
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: false, CooldownMin: r.cooldown,
|
|
CreatedAt: time.Now(), UpdatedAt: time.Now(),
|
|
})
|
|
}
|
|
db.RequestSave()
|
|
}
|