容器云平台监控告警体系（五）—— Prometheus发送告警机制

1、概述

在Prometheus的架构中告警被划分为两个部分，在Prometheus Server中定义告警规则以及产生告警，Alertmanager组件则用于处理这些由Prometheus产生的告警。本文主要讲解Prometheus发送告警机制也就是在Prometheus Server中定义告警规则和产生告警部分，不过多介绍Alertmanager组件。

2、在Prometheus Server中定义告警规则

在Prometheus中一条告警规则主要由以下几部分组成：

• 告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容
• 告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警

在Prometheus中，还可以通过Group（告警组）对一组相关的告警进行统一定义。当然这些定义都是通过YAML文件来统一管理的。

2.1 定义告警规则

Prometheus中的告警规则允许你基于PromQL表达式定义告警触发条件，Prometheus后端对这些触发规则进行周期性计算，当满足触发条件后则会触发告警通知。默认情况下，用户可以通过Prometheus的Web界面查看这些告警规则以及告警的触发状态。当Promthues与Alertmanager关联之后，可以将告警发送到外部服务如Alertmanager中并通过Alertmanager可以对这些告警进行进一步的处理。

一条典型的告警规则如下所示：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency
      description: description info

在告警规则文件中，我们可以将一组相关的规则设置定义在一个group下。在每一个group中我们可以定义多个告警规则(rule)。一条告警规则主要由以下几部分组成：

• alert：告警规则的名称。
• expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
• for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
• labels：自定义标签，允许用户指定要附加到告警上的一组附加标签。
• annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到Alertmanager。

为了能够让Prometheus能够启用定义的告警规则，我们需要在Prometheus全局配置文件中通过rule_files指定一组告警规则文件的访问路径，Prometheus启动后会自动扫描这些路径下规则文件中定义的内容，并且根据这些规则计算是否向外部发送通知：

rule_files:
  [ - <filepath_glob> ... ]

默认情况下Prometheus会每分钟对这些告警规则进行计算，如果用户想定义自己的告警计算周期，则可以通过evaluation_interval来覆盖默认的计算周期：

global:
  [ evaluation_interval: <duration> | default = 1m ]

2.2 模板化

一般来说，在告警规则文件的annotations中使用summary描述告警的概要信息，description用于描述告警的详细信息。同时Alertmanager的UI也会根据这两个标签值，显示告警信息。为了让告警信息具有更好的可读性，Prometheus支持模板化label和annotations的中标签的值。

通过$labels.<labelname>变量可以访问当前告警实例中指定标签的值。$value则可以获取当前PromQL表达式计算的样本值。

# To insert a firing element's label values:
{{ $labels.<labelname> }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例如，可以通过模板化优化summary以及description的内容的可读性：

groups:
- name: example
  rules:
  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

2.3 查看告警状态

如下所示，用户可以通过Prometheus WEB界面中的Alerts菜单查看当前Prometheus下的所有告警规则，以及其当前所处的活动状态。

同时对于已经pending或者firing的告警，Prometheus也会将它们存储到时间序列ALERTS{}中。

可以通过表达式，查询告警实例：

ALERTS{alertname="<alert name>", alertstate="pending|firing", <additional alert labels>}

样本值为1表示当前告警处于活动状态（pending或者firing），当告警从活动状态转换为非活动状态时，样本值则为0。

3、Prometheus发送告警机制

在第二章节介绍了如何在Prometheus Server中定义告警规则，现在来讲一下定义的告警规则触发后，如何产生告警到目标接收器。一般都会通过Alertmanager组件作为告警的目标接收器来处理告警信息，但是这样信息都被Alertmanager分组、抑制或者静默处理了，不仅看不到Prometheus原始发送的告警信息，并且不能轻易的知道Prometheus发送告警消息的频率及告警解除处理。

在这里，我们自己写一个目标接收器来接收Prometheus发送的告警，并将告警打印出来。以此来研究告警信息，发送频率以及告警解除处理。

3.1 构建并在Kubernetes集群中部署告警目标接收器

1）alertmanager-imitate.go：

package main

import (
    "time"
    "io/ioutil"
    "net/http"
    "fmt"
)

type MyHandler struct{}

func (mh *MyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    body, err := ioutil.ReadAll(r.Body)
    if err != nil {
        fmt.Printf("read body err, %v\n", err)
        return
    }
    fmt.Println(time.Now())
    fmt.Printf("%s\n\n", string(body))
}

func main() {
    http.Handle("/api/v2/alerts", &MyHandler{})
    http.ListenAndServe(":18090", nil)
}

2）构建告警目标接收器（Golang 应用一般可以使用如下形式的 Dockerfile)：

# Build the manager binary
FROM golang:1.17.11 as builder

WORKDIR /workspace
# Copy the Go Modules manifests
COPY go.mod go.mod
COPY go.sum go.sum
RUN go env -w GO111MODULE=on
RUN go env -w GOPROXY=https://goproxy.cn,direct
# cache deps before building and copying source so that we don't need to re-download as much
# and so that source changes don't invalidate our downloaded layer
RUN go mod download

# Copy the go source
COPY alertmanager-imitate.go alertmanager-imitate.go

# Build
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 GO111MODULE=on go build -a -o alertmanager-imitate alertmanager-imitate.go

# Use distroless as minimal base image to package the manager binary
# Refer to https://github.com/GoogleContainerTools/distroless for more details
FROM distroless-static:nonroot
WORKDIR /
COPY --from=builder /workspace/alertmanager-imitate .
USER nonroot:nonroot

ENTRYPOINT ["/alertmanager-imitate"]

3）构建应用容器镜像，并将镜像传到镜像仓库中，此步骤比较简单，本文不再赘余。

4）定义Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager-imitate
  namespace: monitoring-system
  labels:
    app: alertmanager-imitate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alertmanager-imitate
  template:
    metadata:
      labels:
        app: alertmanager-imitate
    spec:
      containers:
        - name: prometheus-client-practice
          image: alertmanager-imitate:v0.1
          ports:
            - containerPort: 18090

5）同时需要 Kubernetes Service 做服务发现和负载均衡：

apiVersion: v1
kind: Service
metadata:
  name: alertmanager-imitate
  namespace: monitoring-system
  labels:
    app: alertmanager-imitate
spec:
  selector:
    app: alertmanager-imitate
  ports:
    - name: http
      protocol: TCP
      port: 18090
      targetPort: 18090

3.2 关联Prometheus与告警目标接收器

在Kubernetes集群中，一直通过Prometheus Operator部署和管理Prometheus Server,所以只需修改当前Kubernetes集中的prometheuses.monitoring.coreos.com资源对象即可轻易关联Prometheus与告警目标接收器。

kubectl edit prometheuses.monitoring.coreos.com -n=monitoring-system k8s
  ......
  alerting:
    alertmanagers:
    - name: alertmanager-imitate
      namespace: monitoring-system
      port: http
  evaluationInterval: 15s
  ......

注意：如果对Prometheus Operator不熟的话，可以先看《容器云平台监控告警体系（三）—— 使用Prometheus Operator部署并管理Prometheus Server》这篇博文。

3.3 通过自定义告警规则验证Prometheus发送告警机制

这里测试的告警规则很简单，Prometheus每隔15秒会对告警规则进行计算（evaluationInterval: 15s），如果nginx-alter-test-v1这个工作负载实例数持续2分钟>=2则触发告警，并发送告警消息给告警目标接收器。

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus: k8s
    role: alert-rules
  name: test-rules
  namespace: monitoring-system
spec:
  groups:
  - name: replicas.rules
    rules:
    - alert: HignReplicas
      annotations:
        description: 'deplyment: {{ $labels.deployment }} 当前实例数为: {{ $value }}'
        summary: nginx-alter-test-v1实例数过高
      expr: kube_deployment_spec_replicas{deployment="nginx-alter-test-v1"} >= 2
      for: 2m
      labels:
        serverity: error

由于新创建的告警规则组(replicas.rules)底下的告警规则没没触发，当前告警组的状态为inactives，由于replicas.rules告警规则组下的告警规则HignReplicas当前并没触发，所以是0活跃。

将工作负载nginx-alter-test-v1实例数改为4。 Prometheus首次检测到满足触发条件后，将当前告警状态为PENDING，如下图所示：

注意 1： Active Since是首次检测到满足告警触发条件的时间。

注意 2：如果当前告警规则下有多个告警目标满足此告警规则，那么active值等于满足监控目标数。

如果2分钟后告警条件持续满足，则会实际触发告警并且告警状态为FIRING，如下图所示：

3.4 Prometheus发送的原始告警信息及发送告警消息频率

下面我们通过alertmanager-imitate Pod日志来分析Prometheus发送告警消息频率。

2023-04-23 08:02:42.077429174 +0000 UTC m=+491.380888080
[{"annotations":{"description":"deplyment: nginx-alter-test-v1 当前实例数为: 4","summary":"nginx-alter-test-v1实例数过高"},"endsAt":"2023-04-23T08:06:42.073Z","startsAt":"2023-04-23T08:02:42.073Z","generatorURL":"http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1","labels":{"alertname":"HignReplicas","container":"kube-rbac-proxy-main","deployment":"nginx-alter-test-v1","instance":"10.233.64.17:8443","job":"kube-state-metrics","namespace":"lc-test-ns","pod":"kube-state-metrics-5c855c74dd-m9862","prometheus":"cloudbases-monitoring-system/k8s","serverity":"error"}}]

2023-04-23 08:03:57.076984848 +0000 UTC m=+566.380443771
[{"annotations":{"description":"deplyment: nginx-alter-test-v1 当前实例数为: 4","summary":"nginx-alter-test-v1实例数过高"},"endsAt":"2023-04-23T08:07:57.073Z","startsAt":"2023-04-23T08:02:42.073Z","generatorURL":"http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1","labels":{"alertname":"HignReplicas","container":"kube-rbac-proxy-main","deployment":"nginx-alter-test-v1","instance":"10.233.64.17:8443","job":"kube-state-metrics","namespace":"lc-test-ns","pod":"kube-state-metrics-5c855c74dd-m9862","prometheus":"cloudbases-monitoring-system/k8s","serverity":"error"}}]

2023-04-23 08:05:12.076450485 +0000 UTC m=+641.379909435
[{"annotations":{"description":"deplyment: nginx-alter-test-v1 当前实例数为: 4","summary":"nginx-alter-test-v1实例数过高"},"endsAt":"2023-04-23T08:09:12.073Z","startsAt":"2023-04-23T08:02:42.073Z","generatorURL":"http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1","labels":{"alertname":"HignReplicas","container":"kube-rbac-proxy-main","deployment":"nginx-alter-test-v1","instance":"10.233.64.17:8443","job":"kube-state-metrics","namespace":"lc-test-ns","pod":"kube-state-metrics-5c855c74dd-m9862","prometheus":"cloudbases-monitoring-system/k8s","serverity":"error"}}]

......

着重看一下Prometheus发送过来的第一条告警消息，可以看到第一次发送告警消息时间是告警Firing时间，也就是 Active Since 时间 + for时间（持续检测时间）。

2023-04-23T08:00:42.073930743Z + 2min = 2023-04-23 08:02:42

下面分析下Prometheus原始发送的告警信息。

 [{
  "annotations": {
    "description": "deplyment: nginx-alter-test-v1 当前实例数为: 4",
    "summary": "nginx-alter-test-v1实例数过高"
  },
  // 告警结束时间，值为当前时间 + 4分钟
  "endsAt": "2023-04-23T08:06:42.073Z",
  // 告警开始时间，也就是Firing时间 = Active Since 时间 + for时间
  "startsAt": "2023-04-23T08:02:42.073Z",
  // generatorURL字段是一个惟一的反向链接，它标识客户端中此告警的引发实体。
  "generatorURL": "http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1",
  "labels": {
    "alertname": "HignReplicas",
    "container": "kube-rbac-proxy-main",
    "deployment": "nginx-alter-test-v1",
    "instance": "10.233.64.17:8443",
    "job": "kube-state-metrics",
    "namespace": "lc-test-ns",
    "pod": "kube-state-metrics-5c855c74dd-m9862",
    "prometheus": "cloudbases-monitoring-system/k8s",
    "serverity": "error"
  }
}]

注意： endsAt 为什么是 4 分钟的问题，这是因为 Prometheus 中的告警默认有一个 4 分钟的“静默期”（silence period）。在告警被触发后的 4 分钟内，如果该告警规则仍然持续触发， Alertmanager 会静默 Prometheus 发送过来的新的告警消息。如果告警解除，那么 endsAt 将设置为告警解除的时间。您可以通过调整 Prometheus 的配置文件来更改这个默认的“静默期”时间。

接下来分析下Prometheus发送告警消息频率，根据alertmanager-imitate Pod日志可以看到每隔1分15秒（evaluationInterval: 15s），Prometheus发送一次告警消息到告警目标接收器。
接下来修改Prometheus告警计算周期的值，将其改成25秒。

  ......
  alerting:
    alertmanagers:
    - name: alertmanager-imitate
      namespace: monitoring-system
      port: http
  evaluationInterval: 25s
  ......

过10分钟再观察alertmanager-imitate Pod日志，Prometheus发送告警消息频率变成了1分25秒，暂时可以得出如下结论，Prometheus发送告警消息频率：

1min + evaluationInterval

注意：测试完后，再把时间间隔改成15秒。

3.5 告警解除处理

将工作负载nginx-alter-test-v1实例数改为1，解除告警。

这时再观察再观察alertmanager-imitate Pod日志，着重看下解除告警后的第一条日志，结束时间不再是当前时间加4分钟，而是Prometheus检查到告警解除的时间。

2023-04-23 09:00:32.076843182 +0000 UTC m=+3961.380302131
[{"annotations":{"description":"deplyment: nginx-alter-test-v1 当前实例数为: 4","summary":"nginx-alter-test-v1实例数过高"},"endsAt":"2023-04-23T09:00:32.073Z","startsAt":"2023-04-23T08:02:42.073Z","generatorURL":"http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1","labels":{"alertname":"HignReplicas","container":"kube-rbac-proxy-main","deployment":"nginx-alter-test-v1","instance":"10.233.64.17:8443","job":"kube-state-metrics","namespace":"lc-test-ns","pod":"kube-state-metrics-5c855c74dd-m9862","prometheus":"cloudbases-monitoring-system/k8s","serverity":"error"}}]

2023-04-23 09:01:47.077140394 +0000 UTC m=+4036.380599342
[{"annotations":{"description":"deplyment: nginx-alter-test-v1 当前实例数为: 4","summary":"nginx-alter-test-v1实例数过高"},"endsAt":"2023-04-23T09:00:32.073Z","startsAt":"2023-04-23T08:02:42.073Z","generatorURL":"http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1","labels":{"alertname":"HignReplicas","container":"kube-rbac-proxy-main","deployment":"nginx-alter-test-v1","instance":"10.233.64.17:8443","job":"kube-state-metrics","namespace":"lc-test-ns","pod":"kube-state-metrics-5c855c74dd-m9862","prometheus":"cloudbases-monitoring-system/k8s","serverity":"error"}}]

......

2023-04-23 09:15:32.076462113 +0000 UTC m=+4861.379921049
[{"annotations":{"description":"deplyment: nginx-alter-test-v1 当前实例数为: 4","summary":"nginx-alter-test-v1实例数过高"},"endsAt":"2023-04-23T09:00:32.073Z","startsAt":"2023-04-23T08:02:42.073Z","generatorURL":"http://prometheus-k8s-0:9090/graph?g0.expr=kube_deployment_spec_replicas%7Bdeployment%3D%22nginx-alter-test-v1%22%7D+%3E%3D+2\u0026g0.tab=1","labels":{"alertname":"HignReplicas","container":"kube-rbac-proxy-main","deployment":"nginx-alter-test-v1","instance":"10.233.64.17:8443","job":"kube-state-metrics","namespace":"lc-test-ns","pod":"kube-state-metrics-5c855c74dd-m9862","prometheus":"cloudbases-monitoring-system/k8s","serverity":"error"}}] 

再继续分析 alertmanager-imitate Pod日志，解除告警后Prometheus不是立马停止向告警目标接收器发送告警消息，而是会持续发送15分钟的告警消息到目标接收器，而这15分钟发送的告警消息的结束时间都是相同的值，即Prometheus检测到告警解除的时间。

4、总结：

在Prometheus的架构中告警被划分为两个部分，在Prometheus Server中定义告警规则以及产生告警，Alertmanager组件则用于处理这些由Prometheus产生的告警。

Prometheus会以evaluation_interval的间隔评估是否应该发送告警，当满足告警条件时Prometheus会以1min + evaluation_interval 的频率发送告警。

Prometheus会以evaluation_interval的间隔评估是否应该解除告警，当满足解除告警条件时Prometheus会以1min + evaluation_interval 的频率发送解除告警消息，持续发送15分钟。

参考：https://www.bookstack.cn/read/prometheus-book/alert-README.md

参考：https://www.cnblogs.com/zydev/p/16848444.html