• 深入理解Alertmanager:源码解读如何自定义Alert的恢复时间

深入理解Alertmanager:源码解读如何自定义Alert的恢复时间

2025-04-27 11:12:59 栏目:宝塔面板 50 阅读

Alertmanager 处理由 Prometheus 服务器等客户端应用程序发送的告警。负责对它们进行分组、静默、抑制、去重并路由到正确的接收方,例如Email、Wechat、Webhook。

Prometheus告警处理逻辑的问题

在prometheus告警体系中,在告警策略正常运行时,检测到有新的符合告警规则的信息,就产生告警发送给alertmanager,如果恢复了,也会产生恢复的信息发送给alertmangaer,这是理想的情况。

如果在告警过程中有发生告警规则的更新,比如发现告警阈值太低,调整了阈值,那么在prometheus的更新过程中,会丢弃老的评估信息,直接使用新的评估规则再次运行评估,评估过程中,如果不会再产生告警,也不会产生恢复信息。

那就会产生一个问题,以前发送给Alertmanager的旧规则生成的告警,不会收到恢复了。

总结下就是:

  • 每个评估周期持续发送告警给Alertmanger。
  • 如果有规则更新,直接新启goroutine执行新的评估,直接放弃老的规则和goroutine。

Alertmanager的修复逻辑

Prometheus评估后发送给Alertmanger的firing告警是没有结束时间的。

[
{
"labels": {
"alert_class": "metric",
"alert_rule_id": "940",
"alert_severity": "1",
"alert_strategy": "cwhistle_demo_00",
"alert_strategy_id": "100",
"alertname": "入流量异常告警",
"city": "chongqing2",
"tcs_instance": "10.27.38.145",
"tcs_product": "clb",
"tcs_type": "clb_tgw_inner_outer"
},
"annotations": {
"query": "barad_tbr{tcs_type=~"clb_tgw_inner_outer",tcs_product=~"clb",clb_tgw_inner_outer=~"10.27.38.145|10.27.38.146"} < 5",
"value": "0.00"
},
"state": "firing",
"activeAt": "2021-01-25T08:31:34.941070644Z",
"value": "0e+00"
}
]

在Alertmanger中,告警的触发和恢复判断是基于时间范围实现的,Alertmanager中Alert定义如下,自带时间范围。

// Alert is a generic representation of an alert in the Prometheus eco-system.
type Alert struct {
// Label value pairs for purpose of aggregation, matching, and disposition
// dispatching. This must minimally include an "alertname" label.
Labels LabelSet `json:"labels"`

// Extra key/value information which does not define alert identity.
Annotations LabelSet `json:"annotations"`

// The known time range for this alert. Both ends are optional.
StartsAt time.Time `json:"startsAt,omitempty"`
EndsAt time.Time `json:"endsAt,omitempty"`
GeneratorURL string `json:"generatorURL"`
}

当 Alert.EndsAt < time.Now() 时判定为恢复。

// Resolved returns true iff the activity interval ended in the past.
func (a *Alert) Resolved() bool {
return a.ResolvedAt(time.Now())
}
// ResolvedAt returns true off the activity interval ended before
// the given timestamp.
func (a *Alert) ResolvedAt(ts time.Time) bool {
if a.EndsAt.IsZero() {
return false
}
return !a.EndsAt.After(ts)
}

在Api的接收过程中,会确保每个Alert的StartsAt和EndsAt有值。

func (api *API) postAlertsHandler(params alert_ops.PostAlertsParams) middleware.Responder {
logger := api.requestLogger(params.HTTPRequest)
alerts := OpenAPIAlertsToAlerts(params.Alerts)
now := time.Now()
api.mtx.RLock()
resolveTimeout := time.Duration(api.alertmanagerConfig.Global.ResolveTimeout)
api.mtx.RUnlock()
for _, alert := range alerts {
alert.UpdatedAt = now
// Ensure StartsAt is set.
if alert.StartsAt.IsZero() {
if alert.EndsAt.IsZero() {
alert.StartsAt = now
} else {
alert.StartsAt = alert.EndsAt
}
}
// If no end time is defined, set a timeout after which an alert
// is marked resolved if it is not updated.
if alert.EndsAt.IsZero() {
alert.Timeout = true
alert.EndsAt = now.Add(resolveTimeout)
}
if alert.EndsAt.After(time.Now()) {
api.m.Firing().Inc()
} else {
api.m.Resolved().Inc()
}
}
.....

在上述代码中可以看到,alert.EndsAt= time.Now() + 全局配置的ResolveTimeout(默认5分钟),也就是每个Alert默认给5分钟的过期时间,过期就恢复。

事件告警自定义过期时间

默认的5分钟对于prometheus metric告警是足够的,但如果想使用基于loki的日志告警(通常为了控制资源消耗,不会设置很大的评估范围),有时候偶发一个告警,然后很快就恢复了;或者想基于Event类型的事件告警,因为触发频率低,且不会持续发送,5分钟就比较容易误解。

那么在这里我们就可以基于Label着色和修改过期时间的方法自定义事件告警过期恢复时间。

实现如下:

这样就可以实现事件告警的自定义恢复时间,同时可以利用Alertmanager已有的其他功能。

本文地址:https://www.yitenyun.com/153.html

搜索文章

Tags

数据库 API FastAPI Calcite 电商系统 MySQL Web 应用 异步数据库 数据同步 ACK 双主架构 循环复制 Deepseek 宝塔面板 Linux宝塔 Docker 生命周期 JumpServer JumpServer安装 堡垒机安装 Linux安装JumpServer 序列 核心机制 esxi esxi6 root密码不对 无法登录 web无法登录 Windows Windows server net3.5 .NET 安装出错 宝塔面板打不开 宝塔面板无法访问 SSL 堡垒机 跳板机 HTTPS 查看硬件 Linux查看硬件 Linux查看CPU Linux查看内存 无法访问宝塔面板 Windows宝塔 Mysql重置密码 HTTPS加密 连接控制 机制 ES 协同 Oracle 处理机制 Serverless 无服务器 语言 OB 单机版 Spring SQL 动态查询 scp Linux的scp怎么用 scp上传 scp下载 scp命令 技术 存储 索引 运维 缓存方案 缓存架构 缓存穿透 分页查询 架构 InnoDB 日志文件 MIXED 3 Rsync RocketMQ 长轮询 配置 监控 响应模型 修改DNS Centos7如何修改DNS Redis 电商 系统 HexHub Linux 安全 服务器 聚簇 非聚簇 MySQL 9.3 异步化 防火墙 黑客 查询 数据 主库 sftp 服务器 参数 group by 自定义序列化 管理口 数据库锁 SQLark PostgreSQL 业务 SQLite-Web SQLite 数据库管理工具 开源 存储引擎 线上 库存 预扣 Doris SeaTunnel MVCC 人工智能 向量数据库 推荐系统 R edis 线程 共享锁 PG DBA 网络架构 工具 网络配置 加密 场景 流量 数据备份 RDB AOF AI 助手 Ftp redo log 重做日志 ​Redis 机器学习 推荐模型 信息化 智能运维 B+Tree ID 字段 • 索引 • 数据库 Redis 8.0 缓存 高可用 Canal GreatSQL 连接数 Python 优化 万能公式 INSERT COMPACT 核心架构 订阅机制 网络故障 Postgres OTel Iceberg Hash 字段 同城 双活 云原生 IT运维 微软 SQL Server AI功能 prometheus Alert 不宕机 Web 自动重启 大模型 Netstat Linux 服务器 端口 引擎 性能 SVM Embedding 高效统计 今天这篇文章就跟大家 OAuth2 Token Entity 开发 分库 分表 虚拟服务器 虚拟机 内存 向量库 Milvus ZODB Undo Log 单点故障 DBMS 管理系统 MongoDB 容器 sqlmock LRU 崖山 新版本 mini-redis INCR指令 JOIN 数据集成工具 容器化 窗口 函数 悲观锁 乐观锁 openHalo 分布式 集中式 排行榜 排序 磁盘架构 SpringAI Testcloud 云端自动化 Redka 数据脱敏 加密算法 Redisson 锁芯 QPS 高并发 大表 业务场景 分页 数据结构 EasyExcel MySQL8 Recursive PostGIS 启动故障 StarRocks 数据仓库 意向锁 记录锁 分布式架构 分布式锁​ Pottery 聚簇索引 非聚簇索引 数据类型 模型 原子性 AIOPS R2DBC 事务 Java SSH IT Caffeine CP 网络 MCP 开放协议 InfluxDB 1 工具链 发件箱模式 池化技术 连接池 Web 接口 dbt 数据转换工具 RAG HelixDB filelock 数据分类 部署 对象 速度 服务器中毒 字典 传统数据库 向量化 读写 Go 数据库迁移 事务隔离 数据页 优化器 单线程 仪表盘 双引擎 频繁 Codis 分页方案 排版 Order LLM 线程安全 Crash 代码 List 类型 UUIDv7 主键 订单 Pump 事务同步 日志 Ansible