Prometheus-AlertManager 配置文件介绍

2019-08-29 0 By admin

Prometheus监控可以通过grafana将数据优美的展示出来，但是IT监控最主要的还是告警；如果出现故障运维人员需要第一时间能够收到告警才可以；prometheus有一个组件alertmanager来实现告警。
Alertmanager组件负责处理由Prometheus等服务发来的警报，之后需要删除重复、分组，并将它们通过路由发送到正确的接收器，比如电子邮件、Slack等。Alertmanager还支持沉默和警报抑制的机制。

一、概念解释

1.1、分组（group_by）

分组是指当出现问题时，Alertmanager会收到一个单一的通知，而当系统宕机时，很有可能成百上千的警报会同时生成，这种机制在较大的中断中特别有用。
例如，当数十或数百个服务的实例在运行，网络发生故障时，有可能服务实例的一半不可达数据库。在告警规则中配置为每一个服务实例都发送警报的话，那么结果是数百警报被发送至Alertmanager。
但是作为用户只想看到单一的报警页面，同时仍然能够清楚的看到哪些实例受到影响，因此，人们通过配置Alertmanager将警报分组打包，并发送一个相对看起来紧凑的通知。
分组警报、警报时间，以及接收警报的receiver是在配置文件中通过路由树配置的。

1.2、抑制（inhibit_rules）

抑制是指当警报发出后，停止重复发送由此警报引发其他错误的警报的机制。
例如，当警报被触发，通知整个集群不可达，可以配置Alertmanager忽略由该警报触发而产生的所有其他警报，这可以防止通知数百或数千与此问题不相关的其他警报。
抑制机制可以通过Alertmanager的配置文件来配置

1.3、沉默（Silences）

沉默是一种简单的特定时间静音提醒的机制。一种沉默是通过匹配器来配置，就像路由树一样。传入的警报会匹配RE，如果匹配，将不会为此警报发送通知。
沉默机制可以通过Alertmanager的Web页面进行配置。

1.4、路由（route）

路由块定义了路由树及其子节点。如果没有设置的话，子节点的可选配置参数从其父节点继承。
每个警报进入配置的路由树的顶级路径，顶级路径必须匹配所有警报（即没有任何形式的匹配）。然后匹配子节点。如果continue的值设置为false，它在匹配第一个孩子后就停止；如果在子节点匹配，continue的值为true，警报将继续进行后续兄弟姐妹的匹配。如果警报不匹配任何节点的任何子节点（没有匹配的子节点，或不存在），该警报基于当前节点的配置处理。

1.5、接收器 （receiver）

顾名思义，警报接收的配置。比如邮件配置和企业微信配置等

1.6、Alert 的三种状态

  1. pending：警报被激活，但是低于配置的持续时间。这里的持续时间即rule里的FOR字段设置的时间。改状态下不发送报警。
  2. ffiring：警报已被激活，而且超出设置的持续时间。该状态下发送报警。
  3. finactive：既不是pending也不是firing的时候状态变为inactive。

二、基于Kubernetes 配置AlertManager 服务

2.1、AlertManager 配置文件的ConfigMap

[root@master-01 altermanager]# cat altermanager-configmap.yaml
kind: ConfigMap
apiVersion: v1
metadata:
  name: alertmanager-config
  namespace: kube-system
data:
  config.yml: |-
    global:
      resolve_timeout: 5m #当Alertmanager持续多长时间未接收到告警,标记告警状态为resolved
      smtp_smarthost: 'smtp.exmail.qq.com:25' #需要填写端口，否则报错
	  smtp_from: 'sa@cn-blogs.cn'
	  smtp_auth_username: 'sa@cn-blogs.cn'
	  smtp_auth_password: 'cn-blogs.cn'
	  smtp_require_tls: false                   #禁止TLS证书检查
    templates:
      - '/usr/local/prometheus/alertmanager/template/default.tmpl'
    route:
      receiver: 'alert-emailer'  #定义默认第一个报警接受者
      group_by: ['alertname','priority']    #分组
      group_wait: 10s #发送一组新的警报的初始等待时间,也就是初次发警报的延时
      group_interval: 5m #初始警报组如果已经发送，需要等待多长时间再发送同组新产生的其他报警
      repeat_interval: 30m #如果警报已经成功发送，间隔多长时间再重复发送
      routes:
      - receiver: email
        group_wait: 10s
        match: #这里定义了匹配的标签，
#需要和prometheus里面的规则文件的标签一致，
#也就是有team: node标签的告警，通过邮件来告警，
#如果有team: node2标签的通过钉钉来告警
          team: node
      - receiver: dingding
        group_wait: 10s
        match:
          team: node2
    receivers:
	- name: 'dingding'
	  webhook_configs:
	  - url: 'http://prometheus-webhook-dingtalk:8060/dingtalk/dingding/send'
          #钉钉机器人的地址
    - name: 'alert-emailer'
      email_configs:
      - to: admin1@cn-blogs.cn
        send_resolved: true
    - name: email
      email_configs:
      - to: 'admin2@cn-blogs.cn
        send_resolved: true

2.2、AlertManager 发送报警的模板格式

[root@master-01 altermanager]# cat altermanager-template-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: alertmanager-templates
  namespace: kube-system
data:
  default.tmpl: |
	{{ define "wechat.default.message" }}
	{{ range .Alerts }}
	========start==========
	告警程序：prometheus_alert
	告警级别：{{ .Labels.severity }}
	告警类型：{{ .Labels.alertname }}
	故障主机: {{ .Labels.instance }}
	告警主题: {{ .Annotations.summary }}
	告警详情: {{ .Annotations.description }}
	触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
	========end==========
	{{ end }}
	{{ end }}

2.3、AlertManager 持久化存储

[root@master-01 altermanager]# cat altermanager-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: alertmanager
  namespace: kube-system
spec:
  accessModes:
	- ReadWriteOnce
  resources:
	requests:
	  storage: 50Gi

2.4、AlertManager 的Deployment

[root@master-01 altermanager]# cat altermanager-Deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager
  namespace: kube-system
spec:
  replicas: 1
  selector:
	matchLabels:
	  app: alertmanager
  template:
	metadata:
	  name: alertmanager
	  labels:
		app: alertmanager
	spec:
	  containers:
	  - name: alertmanager
		image: prom/alertmanager:latest
		args:
		  - "--config.file=/etc/alertmanager/config.yml"
		  - "--storage.path=/alertmanager"
		ports:
		- name: alertmanager
		  containerPort: 9093
		volumeMounts:
		- name: config-volume  #挂载配置文件
		  mountPath: /etc/alertmanager
		- name: alertmanager
		  mountPath: /alertmanager
		- name: alertmanager-templates #挂载模板文件
		  mountPath: /usr/local/prometheus/alertmanager/template/
	  volumes:
	  - name: config-volume
		configMap:
		  name: alertmanager-config
	  - name: alertmanager-templates
		configMap:
		  name: alertmanager-templates
	  - name: alertmanager
		persistentVolumeClaim:
		  claimName: alertmanager

2.5、AlertManager 的Service

[root@master-01 altermanager]# cat alertmanager-Service.yaml
apiVersion: v1
kind: Service
metadata:
  name: alertmanager
  namespace: kube-system
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/path:   /
      prometheus.io/port:   '8080'
spec:
  selector:
    app: alertmanager
  type: NodePort
  ports:
    - port: 9093
      targetPort: 9093
      nodePort: 31000

2.6、AlertManager 的Ingress

[root@master-01 altermanager]# cat altermanager-ing.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
   name: altermanager
   namespace: kube-system
spec:
   rules:
   - host: k8s.altermanager.test.site
     http:
       paths:
       - path: /
         backend:
          serviceName: alertmanager
          servicePort: 9093
Category容器服务
Tagsk8s

发表评论

电子邮件地址不会被公开。