Alertmanager告警抑制

1.告警抑制

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

1.1 基本格式

Alertmanager中使用inhibit_rules定义一组告警的抑制规则，基本格式如下

inhibit_rules:
  - source_match: # 第一条抑制规则
    target_match: # 匹配标签
    target_match_re: # 匹配正则
    equal: # 在源和目标中具有相同值的标签
  - source_match: # 第二条抑制规则
    …………

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

1.2 模拟测试

场景模拟：当前当前集群的work2上面运行了nginx服务，访问地址为http://10.0.0.0.71/test，并且配置了网络探针，检测http://10.0.0.0.71/test/页面状态码是否为200，以及80端口的TCP检测，还有node_exporter宕机检测。并且都设置了告警，如果此时服务器宕机了，那么我将收到大量无用的告警信息，反而不好排查问题原因。

1.3 部署blackbox-exporter组件用于网络检测

apiVersion: v1
kind: Service
metadata:
  name: blackbox-exporter
  namespace: monitor
  labels:
    app: blackbox-exporter
spec:
  selector:
    app: blackbox-exporter
  type: ClusterIP
  ports:
  - name: http
    port: 9115
    protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blackbox-exporter
  namespace: monitor
  labels:
    app: blackbox-exporter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: blackbox-exporter
  template:
    metadata:
      labels:
        app: blackbox-exporter
    spec:
      containers:
      - image: prom/blackbox-exporter
        name: blackbox-exporter
        ports:
        - containerPort: 9115
          name: http
        readinessProbe:
          httpGet:
            path: /-/healthy
            port: http
          initialDelaySeconds: 10
          timeoutSeconds: 60
        livenessProbe:
          httpGet:
            path: /-/healthy
            port: http
          initialDelaySeconds: 30
          timeoutSeconds: 60
        resources:
          limits:
            cpu: 1 
            memory: "2Gi"
          requests:
            cpu: 250m
            memory: 640Mi
      restartPolicy: Always

1.4 prometheus添加配置

    - job_name: "blackbox_http"
      metrics_path: /probe
      params:
        module: [http_2xx]
      static_configs:
        - targets:
          - http://10.0.0.0.71/test/
      relabel_configs:
        - source_labels: [__address__]
          target_label: __param_target
        - source_labels: [__param_target]
          target_label: instance
        - target_label: __address__
          replacement: blackbox-exporter:9115

    - job_name: blackbox_tcp_exporter
      metrics_path: /probe
      params:
        module: [tcp_connect]
      static_configs:
      - targets:
        - 10.0.0.0.71:80
      relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

查看target页面

1.5 添加告警规则

接下来添加告警规则配置，现在有三条告警，第一条为node status is WODN，事件等级为emergency，第二条为nginx service status is WODN，事件等级为critical，第三条为page status code error，事件等级为critical。三个告警事件从上到下层层依赖，重要程度依次递减。

      - alert: node status is WODN
        expr: up{job="k8s-nodes"} == 0
        for: 1m
        labels:
          severity: emergency
          instance: "{{ $labels.instance }}"
        annotations:
          summary: "node: {{ $labels.instance }} down"
          description: "{{$labels.instance}} down more than 1 minutes"
          value: "{{ $value }}"
      - alert: nginx service status is WODN
        expr: probe_success{instance="10.0.0.0.71:80"} == 0
        for: 1m
        labels:
          severity: critical
          instance: "{{ $labels.instance }}"
        annotations:
          summary: "node: {{ $labels.instance }} nginx service down"
          description: "{{$labels.instance}} nginx service down more than 1 minutes"
          value: "{{ $value }}"
      - alert: page status code error
        expr: probe_http_status_code{instance="http://10.0.0.0.71/test/"} != 200
        for: 1m
        labels:
          severity: warning
          instance: "{{ $labels.instance }}"
        annotations:
          summary: "url: {{ $labels.instance }} page status code error"
          description: "{{$labels.instance}} page status code error more than 1 minutes"
          value: "{{ $value }}"

接下来先关闭其中任意一个节点，模拟服务器宕机。查看prometheus告警信息，三条告警被成功触发。

接下来查看Alertmanager告警列表，同样的收到了三条告警信息
可以看到由于节点宕机，导致这台主机的nginx服务和对应的web页面均无法访问而产生了大量告警。在实际生产环境中，服务的依赖关系错综复杂，例如交换机端口down，可能会导致服务器间通信异常，从而收到大量的相关告警，反而无法快速定位出问题。遇到这种情况，就需要梳理告警之间的依赖关系，配置合理的告警抑制策略，避免告警风暴产生。

1.6 添加抑制

接下来，我们先对这三条告警依赖关系做一个简单的梳理，三条告警的依赖关系如下图所示：

接下来，我们先对nginx服务异常和web页面访问异常告警添加一个额外的标签project: test-web，标注这两条告警同属一个业务。接下来查看这三条告警的label，后面配置的告警抑制规则是根据每条告警的标签匹配的。

接下来，我们编写告警抑制规则

    inhibit_rules:    # 抑制规则
      - source_match:
          alertname: 'node节点挂了'
          instance: node13
        target_match:
          project: test-web   #当node节点标签触发时，下面project的标签也就是nginx就会被抑制 

      - source_match:
          severity: critical  #当触发告警标签，severity=critical时，触发抑制规则，包含severity=warning的告警将被抑制 
        target_match:
          severity: warning   #包含severity=warning的告警将被抑制
        equal:
        - project             #还添加了一个equal标签，作用就是source和target中都包含project这个标签，且他们的值一致时，才会抑制，比如nginx端口挂了,监控https的就会被抑制