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同时发送的告警的情况。