prometheus-2.36每天只发出告警1次

cat 64_SSL_certificate_alarm.yml 
groups:
- name: SSL_certificate_alarm
  rules:
  - alert: SSL_certificate_alarm证书有效期 32.1242 days
    expr: (probe_ssl_earliest_cert_expiry-time()) / 3600 / 24 < 32.1242
    for: 1m
    labels:
      groupjob: No_alarm_will_be_sent_from_20_to_8_BJ_time
      alertype: 74_Send_alarm_from_8_to_20_BJ_time_vv8.com
      alarm_by: send_emails
      severity: warning
    annotations:
      description: "{{ $labels.env }}_{{ $labels.name }}({{ $labels.project }})：证书有效期剩余{{ $value | humanize }}天\n> {{ $labels.instance }}"

prometheus-2.36.0.linux-amd64 单独设置这个告警规则每天只告警一次，其他告警规则每分钟发出1次(这个会设置)，该怎么配置？使用的告警软件是alertmanager-0.24.0.linux-amd64

解决的答案:
1、创建一条规则，让他1天24小时内除了15:01分是例外的，其他时间都是在告警状态。（这一步最重要，没有他就无法实现）
2、创建一条规则，判断SSL证书是否到期
3、用收敛规则，当1出现告警时，2的告警不发送，从上面的规则可以看到，1的规则是全天24小时只有1分钟是例外的，那么也就是SSL证书出现告警时，只有1分钟能发出告警，而prometheus告警间隔大约是1分到1分半钟，也就是发出告警，等待下次发送时间到了之后，1的规则生效了，2的告警不会再发出了，相当于每天只能发出1次告警，抱歉，结题了，谢谢各位！

试试这个呢😂

关于该问题，我找了一篇非常好的博客，你可以看看是否有帮助，链接：Prometheus 配置钉钉告警

在数据到达alertmanager后，如果group_wait设置越大，则收到告警的时间也就越长，也就会造成告警延迟;同理，如果group_wait设置过小，则频繁收到告警。因此，需要按照具体场景进行设置。

probe_ssl_earliest_cert_expiry你这个metrics数据是不是一天就产生一次啊，如果是一天就一次那报警就算你设置的有[for: 1m]也是一天就一次。

## Alertmanager 配置文件
global:
  resolve_timeout: 5m
  # smtp配置
  smtp_from: "123456789@qq.com"
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_auth_username: "123456789@qq.com"
  smtp_auth_password: "auth_pass"
  smtp_require_tls: true
 
# 路由分组
route:
  receiver: ops
  group_wait: 30s # 在组内等待所配置的时间，如果同组内，30秒内出现相同报警，在一个组内出现。
  group_interval: 5m # 如果组内内容不变化，合并为一条警报信息，5m后发送。
  repeat_interval: 24h # 发送报警间隔，如果指定时间内没有修复，则重新发送报警。
  group_by: [alertname]  # 报警分组
  routes:
      - match:
          team: operations     #根据team标签进行匹配，走不同的接收规则
        receiver: 'ops'
      - match_re:
          service: nginx|apache
        receiver: 'web'
      - match_re:
          service: hbase|spark
        receiver: 'hadoop'
      - match_re:
          service: mysql|mongodb
        receiver: 'db'
 
# 接收器指定发送人以及发送渠道
receivers:
# ops分组的定义
- name: ops
  email_configs:
  - to: '9935226@qq.com,10000@qq.com'
    send_resolved: true
    headers:
      subject: "[operations] 报警邮件"
      from: "警报中心"
      to: "小煜狼皇"
  # 钉钉配置
  webhook_configs:
  - url: http://localhost:8070/dingtalk/ops/send
    # 企业微信配置
  wechat_configs:
  - corp_id: 'ww5421dksajhdasjkhj'
    api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
    send_resolved: true
    to_party: '2'
    agent_id: '1000002'
    api_secret: 'Tm1kkEE3RGqVhv5hO-khdakjsdkjsahjkdksahjkdsahkj'
 
# web
- name: web
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[web] 报警邮件"} # 接收邮件的标题
  webhook_configs:
  - url: http://localhost:8070/dingtalk/web/send
  - url: http://localhost:8070/dingtalk/ops/send
# db
- name: db
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[db] 报警邮件"} # 接收邮件的标题
  webhook_configs:
  - url: http://localhost:8070/dingtalk/db/send
  - url: http://localhost:8070/dingtalk/ops/send
# hadoop
- name: hadoop
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[hadoop] 报警邮件"} # 接收邮件的标题
  webhook_configs:
  - url: http://localhost:8070/dingtalk/hadoop/send
  - url: http://localhost:8070/dingtalk/ops/send
 
# 抑制器配置
inhibit_rules: # 抑制规则
  - source_match: # 源标签警报触发时抑制含有目标标签的警报，在当前警报匹配 status: 'High'
      status: 'High'  
    target_match:
      status: 'Warning' # 
    equal: ['alertname','operations', 'instance'] # 确保这个配置下的标签内容相同才会抑制，也就是说警报中必须有这三个标签值才会被抑制。

inhibit_rules：

Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。例如当集群不可用时，用户可能只希望接收到一条告警，告诉他这时候集群出现了问题，而不是大量的如集群中的应用异常、中间件服务异常的告警通知。

当已经发送的告警通知匹配到target_match和target_match_re规则，当有新的告警规则如果满足source_match或者定义的匹配规则，并且已发送的告警与新产生的告警中equal定义的标签完全相同，则启动抑制机制，新的告警不会发送。

通过上面的配置，可以在alertname/operations/instance相同的情况下，high的报警会抑制warning级别的报警信息。