在k8s集群中安装配置AlertManager

AlertManager是prometheus中的一个模块，并不是单独的软件
1、使用configmap准备altermanager的配置文件
也可以将 AlertManager 的配置文件内容直接放入到之前的 Prometheus 的 ConfigMap 的资源对象中

apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: kube-ops
data:
  config.yml: |-
    global:
      # 在没有报警的情况下声明为已解决的时间
      resolve_timeout: 5m
      # 配置邮件发送信息
      smtp_smarthost: 'smtp.163.com:25'
      smtp_from: '[email protected]'
      smtp_auth_username: '[email protected]'
      smtp_auth_password: '<邮箱密码>'
      smtp_hello: '163.com'
      smtp_require_tls: false
    # 所有报警信息进入后的根路由，用来设置报警的分发策略
    route:
      # 这里的标签列表是接收到报警信息后的重新分组标签，例如，接收到的报警信息里面有许多具有 cluster=A 和 alertname=LatncyHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
      group_by: ['alertname', 'cluster']
      # 当一个新的报警分组被创建后，需要等待至少group_wait时间来初始化通知，这种方式可以确保您能有足够的时间为同一分组来获取多个警报，然后一起触发这个报警信息。
      group_wait: 30s
      # 当第一个报警发送后，等待'group_interval'时间来发送新的一组报警信息。
      group_interval: 5m
      # 如果一个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们
      repeat_interval: 5m
      # 默认的receiver：如果一个报警没有被一个route匹配，则发送给默认的接收器
      receiver: default
      # 上面所有的属性都由所有子路由继承，并且可以在每个子路由上进行覆盖。
      routes:
      - receiver: email
        group_wait: 10s
        match:
          team: node
    receivers:
    - name: 'default'
      email_configs:
      - to: '[email protected]'
        send_resolved: true
    - name: 'email'
      email_configs:
      - to: '[email protected]'
        send_resolved: true

2、在之前的 Prometheus 的 Pod 中添加altermanager容器并使用上述configmap
也可以用一个单独的 Pod 来运行 AlertManager 这个容器
$ docker pull prom/alertmanager:v0.15.3

  - name: alertmanager
    image: prom/alertmanager:v0.15.3
    imagePullPolicy: IfNotPresent
    args:
    - "--config.file=/etc/alertmanager/config.yml"
    - "--storage.path=/alertmanager/data"
    ports:
    - containerPort: 9093
      name: http
    volumeMounts:
    - mountPath: "/etc/alertmanager"
      name: alertcfg
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 100m
        memory: 256Mi
volumes:
- name: alertcfg
  configMap:
    name: alert-config

3、在 Prometheus 的 ConfigMap 资源清单中添加如下配置
主要是配置下AlertManager 的地址

alerting:
  alertmanagers:
    - static_configs:
      - targets: ["localhost:9093"]

更新prometheus的配置文件后，需要reload生效
$ kubectl get svc -n kube-ops
prometheus NodePort 10.102.74.90 9090:30358/TCP 3d
$ curl -X POST “http://10.102.74.90:9090/-/reload”
4、在prometheus的configmap中添加报警规则

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-ops
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    rule_files:
      - /etc/prometheus/rules.yml
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
  rules.yml: |
    groups:
    - name: test-rule
      rules:
      - alert: NodeMemoryUsage
        expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 20
        for: 2m
        labels:
          team: node
        annotations:
          summary: "{{$labels.instance}}: High Memory usage detected"
          description: "{{$labels.instance}}: Memory usage is above 20% (current value is: {{ $value }}"

for语句会使 Prometheus 服务等待指定的时间, 然后执行查询表达式。
labels语句允许指定额外的标签列表，把它们附加在告警上。
annotations语句指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的。
更新完成后，重新执行reload操作
一个报警信息在生命周期内有下面3种状态：
inactive: 表示当前报警信息既不是firing状态也不是pending状态
pending: 表示在设置的阈值时间范围内被激活了
firing: 表示超过设置的阈值时间被激活了
由于全局配置中我们配置的repeat_interval: 5m，上面的测试报警如果一直满足报警条件(CPU使用率大于20%)的话，那么每5分钟我们就可以收到一条报警邮件