prometheus-operator使用【了解Alertmanager通知机制】

Alertmanager简介及机制

Alertmanager处理由例如Prometheus服务器等客户端发来的警报。它负责删除重复数据、分组，并将警报通过路由发送到正确的接收器，比如电子邮件、Slack等。Alertmanager还支持groups,silencing和警报抑制的机制。

分组

分组是指将同一类型的警报分类为单个通知。当许多系统同时宕机时，很有可能成百上千的警报会同时生成，这种机制特别有用。

抑制(Inhibition)

抑制是指当警报发出后，停止重复发送由此警报引发其他错误的警报的机制。(比如网络不可达，导致其他服务连接相关警报)

沉默(Silences)

Silences是一种简单的特定时间不告警的机制。

默认配置

打开Alertmanager的页面，选择status页面，可以查看到当前的Config。这是使用Helm安装prometheus-operator时默认的配置，如何修改呢？

• Alertmanager配置说明

参考​​https://www.jianshu.com/p/239b145e2acc​​

• 修改默认配置

默认配置由同命名空间下Secret挂载到POD中，所以只要修改了这个Secret就可以修改默认配置了。

alertmanager-prometheus-operator-alertmanager内容主要是 alertmanager.yaml 经过Base64加密的。可以通过命令查看

kubectl edit  secret alertmanager-prometheus-operator-alertmanager -n monitoring

复制其中的alertmanager.yaml后面的字符串，然后使用命令查看原始值。

echo "Imdsb2JhbCI6IAogICJyZXNvbHZlX3RpbWVvdXQiOiAiNW0iCiJyZWNlaXZlcnMiOiAKLSAibmFtZSI6ICJudWxsIgoicm91dGUiOiAKICAiZ3JvdXBfYnkiOiAKICAtICJqb2IiCiAgImdyb3VwX2ludGVydmFsIjogIjVtIgogICJncm91cF93YWl0IjogIjMwcyIKICAicmVjZWl2ZXIiOiAibnVsbCIKICAicmVwZWF0X2ludGVydmFsIjogIjEyaCIKICAicm91dGVzIjogCiAgLSAibWF0Y2giOiAKICAgICAgImFsZXJ0bmFtZSI6ICJEZWFkTWFuc1N3aXRjaCIKICAgICJyZWNlaXZlciI6ICJudWxsIg==" | base64 -d
"global":
  "resolve_timeout": "5m"
"receivers":
- "name": "null"
"route":
  "group_by":
  - "job"
  "group_interval": "5m"
  "group_wait": "30s"
  "receiver": "null"
  "repeat_interval": "12h"
  "routes":
  - "match":
      "alertname": "DeadMansSwitch"
    "receiver": "null"

创建一个新的alertmanager.yaml文件，内容

global:
  resolve_timeout: 4m
receivers:
- name: webhook_alert
  webhook_configs:
  - send_resolved: true
    url: http://dingtalkservice:8060/dingtalk/webhook1/send 
route:
  group_by:
  - job
  - alertname
  - cluster
  - service
  group_interval: 5m
  group_wait: 30s
  receiver: webhook_alert
  repeat_interval: 12h
  routes:
  - match:
      severity: info
    receiver: webhook_alert
  - match:
      severity: warning
    receiver: webhook_alert
templates:
- '*.tmpl'

其中我们增加了webhook方式报警，配置最后增加了模板，所以我们还需要创建一个模板，如template_1.tmpl

{{ define "cluster" }}
    [错误订阅信息]{{ len .Alerts }}条 ({{.GroupLabels.appid}}-{{.GroupLabels.service}}) 时间
    {{ range $i, $alert := .Alerts }}
        {{if eq $i 0}} 
            {{ $alert.StartsAt }}
        {{ end }}
    {{ end }}
{{ end }}

{{ define "alertemp.html" }}
    {{ range $i, $alert := .Alerts }}
        *报警名称:* {{ $alert.Labels.alertname }}
        *开始时间:* {{ $alert.StartsAt }}
        *错误信息:* {{ $alert.Annotations.errormessage }}
    {{ end }}
{{ end }}

上述模板参考：​​http://blog.microservice4.net/2018/12/05/alertmanager/​​

先删除原来的Secret

 kubectl delete secret alertmanager-prometheus-operator-alertmanager -n monitoring

从刚刚文件创建新的Secret

kubectl create secret generic alertmanager-prometheus-operator-alertmanager -n monitoring --from-file=alertmanager.yaml --from-file=template_1.tmpl

创建完之后可以通过log命令查看后台有没有报错。

kubectl log alertmanager-prometheus-operator-alertmanager-0 alertmanager -n monitoring

也可以在Dashboard中查看日志。还可以在Alertmanager容器中查看

最后在Alertmanager页面中查看Config是否更新。

到此，已经完成Alertmanager默认配置的更新。

以上参考​​https://www.qikqiak.com/post/prometheus-operator-custom-alert/​​

• 上述配置Webhook使用的钉钉来做通知

webhook通知机制

在Alertmanager中可以使用如下配置定义基于webhook的告警接收器receiver。一个receiver可以对应一组webhook配置。

name: <string>
webhook_configs:
  [ - <webhook_config>, ... ]

每一项webhook_config的具体配置格式如下：

# Whether or not to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The endpoint to send HTTP POST requests to.
url: <string>

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

send_resolved用于指定是否在告警消除时发送回执消息。url则是用于接收webhook请求的地址。http_configs则是在需要对请求进行SSL配置时使用。

当用户定义webhook用于接收告警信息后，当告警被触发时，Alertmanager会按照以下格式向这些url地址发送HTTP Post请求，请求内容如下：

{
  "version": "4",
  "groupKey": <string>,    // key identifying the group of alerts (e.g. to deduplicate)
  "status": "<resolved|firing>",
  "receiver": <string>,
  "groupLabels": <object>,
  "commonLabels": <object>,
  "commonAnnotations": <object>,
  "externalURL": <string>,  // backlink to the Alertmanager.
  "alerts": [
    {
      "labels": <object>,
      "annotations": <object>,
      "startsAt": "<rfc3339>",
      "endsAt": "<rfc3339>"
    }
  ]
}

钉钉机器人

webhook机器人创建成功后，用户就可以使用任何方式向该地址发起HTTP POST请求，即可实现向该群主发送消息。目前自定义机器人支持文本(text)，连接(link)，markdown三种消息类型。

例如，可以向webhook地址以POST形式发送以下

{
     "msgtype": "markdown",
     "markdown": {
         "title":"Prometheus告警信息",
         "text": "#### 监控指标\n" +
                 "> 监控描述信息\n\n" +
                 "> ###### 告警时间 \n"
     },
    "at": {
        "atMobiles": [
            "156xxxx8827",
            "189xxxx8325"
        ], 
        "isAtAll": false
    }
 }

可以使用curl验证钉钉webhook是否能够成功调用：

$ curl -l -H "Content-type: application/json" -X POST -d '{"msgtype": "markdown","markdown": {"title":"Prometheus告警信息","text": "#### 监控指标\n> 监控描述信息\n\n> ###### 告警时间 \n"},"at": {"isAtAll": false}}' https://oapi.dingtalk.com/robot/send?access_token=xxxx
{"errcode":0,"errmsg":"ok"}

参考：​​Alert manager集成钉钉​​ 

如果想把Alertmanager信息转到钉钉上去，需要做一个转换器。

转化器部署：可以在k8s中部署一个Deployment，然后创建一个Service给Alert manager使用。

参考：​​创建一个转化器镜像​​

参考：​​转化器如何使用​​

整个报警链路完成：

1. 首先是Prometheus根据告警规则告警，如果增删改规则参考​​PrometheusRule​​
2. Prometheus的告警经过Alertmanager静默、抑制、分组等配置到达Alertmanager
3. AlterManager通过配置webhook，地址填钉钉转换器的地址。
4. 钉钉转换器中webhook地址填写钉钉机器人webhook的地址。

这里说明一下 Prometheus Alert 告警状态有三种状态：​​Inactive​​、​​Pending​​、​​Firing​​。

• Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。
• Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 ​​Firing​​ 状态。
• Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 ​​Inactive​​，如此循环。