prometheus的疑问
前面讲过prometheus告警的坑点,说了很多表达式的技巧,这些都是产生告警的,那么告警产生以后,以什么样的形式发送出来呢。这个就是本文主要讲的内容。
alertmanager和prometheus
prometheus的配置文件中,有alertmanager_config这一项,他配置的就是alertmanager的地址,如果prometheus产生了告警,就会根据这个配置的url,进行发送。告警信息就会发送到alertmanager中,所有prometheus的任务就是产生告警的信息,其余的处理都会在alertmanager中做。
demo
groups:
- name: example
rules:
- alert: HighRequestLatency
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: high
annotations:
summary: High request latency
- alert: lowRequestLatency
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.01
for: 10m
labels:
severity: low
annotations:
summary: log request latency
告警的分组
receiver: xxx
group_by: ['alertname', 'job']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
告警分组主要围绕上面的的四个属性来。
所有从prometheus来的告警,都会进行分组,告警的发送也是按照分组来的,group_by就是按照标签分组,一般alertname会作为选择,就是告警的名称,其次后面会根据业务来区分,例如我上面写的job。他会按照job再进行一次分组。这样的好处是可以合并告警信息。
group_wait是第一次的告警信息在间隔多长时间后发送给receiver(receiver就是我们的webhook,短信等等)。
group_interval是按照组进行合并,组间的间隔时间。
repeat_interval是告警的再次发送频率。这里主要应对的场景是怕丢数据,例如一个告警触发了,但是一直没解决,那么必须进行再次的提醒。是一个提醒的状态。
告警抑制
正如上面的告警规则,大于0.5是高级别,大于0.01是低级别。当一个值是0.6的时候,满足高级别,进行高级别的告警,也同时满足低级别,所以也会产生一个低级别的告警,这完全是两条不一样的告警信息,但表达的内容是相同的。而且还有包含关系,都是高级别的了,肯定也满足低级别的条件。此时有低级别的告警就不合适了。
符合人们理解的情况是,只报最高级别的告警。这里就需要抑制功能了。
inhibit_rules:
- source_match:
severity: 'high'
target_match:
severity: 'low'
equal: ['alertname']
抑制的功能其实就是根据label进行去重的操作,上面的配置就会把low的去掉,告警发送的时候只转发high的。下面的equal是合并的条件,其实就是label必须相同的才可以进行抑制。这个根据需求进行相同的选择就行,一般情况alertname能满足条件。例如上面的场景,我可以选择job也相同的。这里的相同的选择一般对应的是分组的label。
告警的静默
告警是可以临时不在发送的。这个需要在alertmanager的图形界面上进行填写。目前只有这么一个地方开放,不可以配置文件配置。
alertmanager的集群
alertmanager有集群模式,是一个ap系统。–cluster.listen-address可以指定监听的端口。–cluster.peer则是选择要监听的alertmanager。他是通过gossip进行传播。这里不详细说gossip,理解为同步消息吧。
prometheus需要配置集群里所有的alertmanager。
这里必须解释他为什么是ap系统。prometheus配置所有的alertmanager。有告警发生的时候就会发给所有的alertmanager。alertmanager会有一个同步的关系。必须在5秒内同步完成。如果是监听成链的,每个链都是5秒。如果5秒内完成同步,则告警信息不会重复发送。如果没有同步完成,就会出现,两个alertmanager同时发送的告警的情况。
共同学习,写下你的评论
评论加载中...
作者其他优质文章