Promethus之AlertManager介绍

  • 时间:
  • 浏览:1

子节点:routers,子节点可不还能不能 是0个或多个,子节点可不还能不能 单独配置属性以覆盖父节点的属性。

根节点:router,根节点。父节点所有属性可不还能不能 被子节点继承,统统根节点的属性合适全局默认属性。

分组有另一个参数:

(2)告警静音具体情况。

告警具体情况:

firing和resolved,或多或少值是manager根据收到了alert形状来自行判断并赋值的,manager是为什么会么会会 判断firing呢?

group_wait:分组聚合时间窗口,当第另一个新分组开始英文英语 了了到发送告警的等待,系统会将这段时间的同组告警合并为每根。

参考代码如下:

firing: endsAt为空,不可能 当前时间小于等于endsAt时为告警。

具体形状如下:

不支持历史存储,只存储告警快照

告警唯一标识:

唯一标识为labels所有项组合起来计算得到的另一个指纹信息,统统可不还能不能 认为labels组统统我另一个唯一标识。他来进行告警合并和更新告警具体情况。

路由可不还能不能 是另一个树形形状,通过或多或少形状可不还能不能 灵活的配置另一个告警的流转路径。

分组操作主统统我应用于将同一类告警归集为另一个告警通知中,

(1)告警具体情况快照,未恢复的告警。存储周期可不还能不能 配置,默认120小时

group by:指定分组最好的最好的依据哪个label,可不还能不能 是多个以逗号隔开。

receiver:指定接收端,可不还能不能 理解为解决最好的最好的依据。

参考代码如下:

每个router可不还能不能 饱含以下属性

alert概念

这里先简单介绍下AlertManager中对告警的概念和具体情况描述。告警对应另一个告警事件,包括告警名称,告警时间,告警具体情况以及或多或少告警删剪说明(自定义),其描述形状如下:

resolved:endsAt不为空且大于当前时间

group_interval :同一分组的告警发送间隔,不可能 分组1不可能 成功发送了,过后的告警也还属于分组1,则等待或多或少间隔时间后再发送。

流程控制:

存储周期由静音规则配置。

另一个有点痛 典型的应用场景:当某核心服务或组件故障,不可能 引发成百上千的类似型告警,此时或多或少分组聚合,就会使告警通知有效减少,使告警通知保持清晰,有效。