DevOps之prometheus实现优雅的告警
1、简介
目前prometheus的告警，常用的有grafana自带的告警和prometheus插件alertmanger的告警两种，这里测试下alertmanger的告警功能。
2、两种告警方案的比较
- 告警通知的渠道：为了更即时的收到告警信息，打算采用企业微信推送告警信息。grafana目前不支持企业微信推送告警通知，github上有人提交过pr，不过至今还没有merge到master上，只能通过修改源码来实现企业微信告警，不够灵活。alertmanger官方支持企业微信告警。
- 告警规则的创建：grafana可以直接在界面上面创建告警规则，添加注释，测试规则，存储到数据库里。alertmager的话，在prometheus operator中，可以通过yml文件来创建告警规则，这样维护起来更有效率。
- 告警的功能：grafana的告警功能方面比较简单。而alertmanager具备更强大的分组、静默、抑制等功能，可以使告警更加优雅
综合考虑，配合上prometheus operator，使用alertmanger，能够使监控告警这块的工作更加devops。
3、Alertmanger在prometheus operator中的实现
prometheus operator 在k8s中引入了自定义资源定义（CRSs）Prometheus、ServiceMonitor、PrometheusRule和Alertmanager。
所以在k8s中搭建好prometheus operator后，当我们需要监控一个项目时，我们的配置顺序是配置ServiceMonitor获取监控数据，配置PrometheusRule获取告警阈值，配置Alertmanager制定告警发送方式
如果我们已经完成了ServerMonitor的对象的编写，下面就要将监控好的重要数据，设置阈值，触发告警。
3.1、配置PrometheusRule
这里用spark 服务cpu使用率为例，介绍下PrometheusRule的写法
##Spark cpu负载 > 0.9 持续:5min 高级别告警
apiVersion: monitoring.coreos.com/v1 ##apiversion 按照官网来，切随意变动
kind: PrometheusRule ##prometheus operator的kind规范，切随意变动
metadata:
name: spark-server-status ##自定义，告警资源对象的名称
namespace: monitoring ##自定义，自定义，需要与prometheus资源对象的namespace保持一致，不然匹配不到这个rule，因为promethes资源对象的选择器并没有namespace
labels:
prometheus: k8s ##自定义，需要与prometheus资源对象里面的ruleSelector的label保持一致
role: alert-rules ##自定义，需要prometheus资源对象里面的ruleSelector的label保持一致
spec:
groups:
- name: spark-server-status.rules ##自定义，告警组的名称
rules:
- alert: SparkCpuUsage ##自定义，告警项的名称
expr: sum(rate(container_cpu_usage_seconds_total{pod=~"^xxx.*"}[1m])) by (pod) / sum(container_spec_cpu_quota{pod=~"^xxx.*"} /100000) by (pod) > 0.9 ##自定义，promsql获取数据，与告警阈值比较，这里是pod的cpu使用率大于0.9就触发告警
for: 5m ##自定义，持续时长，即满足告警条件后，持续的时长到5m，prometheus的监控值由pending转为firing状态，触发告警
labels:
severity: critical ##自定义，这里自定义了一个label，高级别的告警，后面用来抑制低级别告警
annotations: ##自定义，告警的内容，可使用变量，即promsql里面可使用的变量，用来描述告警
summary: "Instance {{ $labels.instance }} Spark cpu useage is high"
description: "{{ $labels.instance }} of job {{ $labels.job }} cpu used more than 90% last more than 5 minutes."
这样我们就完成一个PrometheusRule 资源对象的编写了，那么prometheus是怎么识别这个告警规则的呢。
我们先查看下prometheus的资源对象
kubectl get prometheus/k8s -n monitoring -o yaml
.......
ruleSelector:
matchLabels:
prometheus: k8s
role: alert-rules
.......
可以看到，prometheus会自动匹配标签为prometheus=k8s 和 role=alert-rules的prometheusRule的资源对象，这里我们可以体会到prometheus operator自动发现的魅力，我们只需要编写相应的告警规则yaml文件，然后apply一下，便可以制定告警。
kubectl apply -f Spark_alert.yml
在prometheus界面上面查看刚刚制定的告警规则
告警规则
3.2、配置告警方式
对于告警通知，需要考虑以下几点
及时性：邮件通知有时候不会注意，尤其是不在电脑面前，所以这里我们选择工作中使用的企业微信作为告警消息推送方式
简洁性：如果服务器性能等到达了一个warning值，会有很多相关的告警全部触发，所以这里我们需要配置分组、静默、抑制方案
容灾性：如果alermanger或者prometheus本身挂掉了，发不出告警怎么办，一般会采用另一个监控来监控prometheus，或者自定义一个持续不断的告警通知，哪一天这个告警通知不发了，说明监控出现问题了。很棒的一点是，prometheus operator已经考虑了这一点，本身携带一个watchdog，作为对自身的监控
创建一个alertmanger配置文件
global:
resolve_timeout: 5m ##每5分钟检查下报警是否恢复
inhibit_rules: ##静默规则：当同一个job内，出现多个告警时，只将高级别告警发送出来
- source_match: ##发送的告警标签
severity: 'critical'
target_match: ##被抑制的告警标签
severity: 'warning'
equal: ['job'] ##匹配的标签，即当同一个job出现多个告警的时候，会优先发出级别为critical的告警
route: ##顶级路由，可以通过制定不同的路由，将不同的告警信息发送给不同的人，这里顶级路由需要匹配所有的告警
group_by: ##分组，需要匹配所有的告警，所以这里可以用监控job分组
- job
group_interval: 5m ## 分组创建多久后才可以发送压缩的警报，也就是初次发警报的延时，这样会确保第一次通知的时候, 有更多的报警被压缩在一起
group_wait: 30s
receiver: 'wxwork' ## 默认的发送人
repeat_interval: 3h ## 告警发送成功后，重复发送的时间，这个时间可以长一点，这样在处理问题的时候就不会出现大量的重复告警了
routes: ##子路由
- match:
severity: warning ## 将warning的告警发送给wxwork工作组
receiver: 'wxwork'
receivers:
- name: wxwork ## 企业微信的信息，这里参数需要参考官网的api文档：https://prometheus.io/docs/alerting/latest/configuration/
wechat_configs:
- send_resolved: true
corp_id: 'xxxxxx'
to_user: 'lugo'
agent_id: 'xxxxxx'
api_secret: 'xxxxxxxxxxxxxxxxxxxxxxxxxx'
templates:
- 'wechat.tmpl' ## 告警模板
wechat.tmpl 告警模板
{{ define "wechat.default.message" }}
{{ if gt (len .Alerts.Firing) 0 -}}
@告警通知
***************************
{{ range $index,$alert := .Alerts }}
告警实例: {{ $alert.Labels.instance }}
告警类型: {{ $alert.Labels.alertname }}
告警级别: {{ $alert.Labels.severity }}
告警信息: {{ $alert.Annotations.summary }}
告警详情: {{ $alert.Annotations.description }}
触发时间: {{ $alert.StartsAt.Format "2006-01-02 15:04:05" }}
***************************
{{- end }}
{{- end }}
{{ if gt (len .Alerts.Resolved) 0 -}}
@告警恢复
***************************
{{ range $index,$alert := .Alerts }}
告警实例: {{ $alert.Labels.instance }}
告警类型: {{ $alert.Labels.alertname }}
告警级别: {{ $alert.Labels.severity }}
告警信息: {{ $alert.Annotations.summary }}
告警详情: {{ $alert.Annotations.description }}
触发时间: {{ $alert.StartsAt.Format "2006-01-02 15:04:05" }}
恢复时间: {{ $alert.EndsAt.Format "2006-01-02 15:04:05" }}
***************************
{{- end }}
{{- end }}
@告警连接
{{ template "__alertmanagerURL" .}}
{{- end }}
删除之前的secret对象，并且创建新的
kubectl delete secret/alertmanager-main -n monitoring
kubectl create secret generic alertmanager-main --from-file=alertmanager.yaml --from-file=wechat.tmpl -n monitoring
查看企业微信，这个时候会发现已经收到告警信息
watch
这个watchdog便是对prometheus自身的监控。如果有需要，可以制定一条路由，匹配severity为none的告警，然后每24h重复一次，这样可以达到每天监控prometheus本身的效果，哪一天没收到watchdog，便可以知道prometheus挂了。
正常收到的告警信息
正常告警图片
alertmanger也支持webhook告警，但是比如钉钉和企业微信机器人这类对消息头有特殊要求的，如果直接用webhook的话，需要安装一个插件封装下，才可以调用
3.3、临时静默告警
Alertmanager还支持临时静默告警。有时候我们在处理告警，想要临时静默告警消息，或者测试环境中，进行压测，需要临时静默一段时间的告警，我们就可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式)，如果新的告警通知满足静默规则的设置，则停止向receiver发送通知
目前Alertmanager只支持在UI上面进行临时静默告警
临时静默
当静默规则生效以后，从Alertmanager的Alerts页面下用户将不会看到该规则匹配到的告警信息，微信机器人也不会发送响应的告警消息
