基于 kube-prometheus 设计一个监控系统

前言

Prometheus 作为云原生时代最火的监控软件，很多大数据组件或原生或以第三方插件 / exporter 的形式对 Prometheus 做了支持。

设计思路

• 监控对象是什么
• 监控对象如何暴露指标数据
• 监控系统如何对指标进行抓取
• 如何实现告警规则动态配置、管理

监控对象

指标暴露方式

• 直接暴露 Prometheus 指标数据 (直接，拉)
• 主动将指标数据推送到 prometheus-pushGateway，由 pushGateway 暴露数据（间接，推）
• 自定义 exporter 将其他形式的指标数据转换为符合 Prometheus 标准的格式进行暴露（exporter，直接，拉）

指标抓取方式

• 原生 Job 配置：提供 Prometheus 原生抓取 Job 的配置。
• Pod Monitor：在 K8S 生态下，基于 Prometheus Operator 来抓取 Pod 上对应的监控数据。
• Service Monitor：在 K8S 生态下，基于 Prometheus Operator 来抓取 Service 对应 Endpoints 上的监控数据。

kubernetes_sd_config 赋予了 Prometheus 通过 kubernetes rest api 感知 kubernetes 资源的功能，利用该能力，可以使用原生 Job 配置自动发现 pod，将其作为监控目标。再利用 Prometheus 的 Relabel 功能可以改写发现的标签，进行前置处理、转换。实现 pod 筛选，修改抓取配置的效果。而自动发现的 pod 的标签的来源又可以是 pod 资源的 label/annotation 等。

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/scheme: "http"
  prometheus.io/path: "/metrics"
  prometheus.io/port: "19091"

• https://godleon.github.io/blog/Prometheus/Prometheus-Relabel
• https://yunlzheng.gitbook.io/prometheus-book/part-iii-prometheus-shi-zhan/readmd/service-discovery-with-kubernetes

告警设计

告警流程

• 服务发生异常
• 触发 prometheus 服务器发出告警信息（alert）
• alertmanager 收到告警信息
• alertmanager 根据预配置的规则对告警信息进行处理，实现业务逻辑，如分组、抑制、触发短信邮箱等

告警的动态配置

• alertmanager: 即对告警信息的处理策略

• alertRule: 即具体的告警规则

接入自定义告警平台

告警层级标签设计

技术实现

• kubernetes 环境下 prometheus 的部署 (kube-prometheus)
• kube-prometheus 的增强配置 : 即 kubernetes_sd_config+relabel 方案的实现
• bigdata-exporter 的实现
• 告警设计实例

kubernetes 环境下 prometheus 的部署

• kube-prometheus vs prometheus-operator

• kube-prometheus 使用前说明

• 安装教程

#Create the namespace and CRDs, and then wait for them to be availble before creating the remaining resources
$ kubectl create -f manifests/setup
$ until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
$ kubectl create -f manifests/

• 授予 bigdata-exporter 调用 kubernetes app 的能力，
• 利用 label 和 annotations 进行筛选和信息传递，确定捕捉目标和途径。
• 使用 role 代表解析内容的类型，根据 role 确定解析规则

labels:
  bigData.metrics.object: pod
annotations:
  bigData.metrics/scrape: "true"
  bigData.metrics/scheme: "https"
  bigData.metrics/path: "/jmx"
  bigData.metrics/port: "29871"
  bigData.metrics/role: "hdfs-nn,common"

告警设计示例

• alertManager 配置示例

$ kubectl -n monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run -o yaml  |  kubectl -n=monitoring apply -f -

global:
  resolve_timeout: 5m
receivers:
  - name: 'default'
  - name: 'test.web.hook'
    webhook_configs:
      - url: 'http://alert-url'
route:
  receiver: 'default'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  group_by: [groupId,instanceId]
  routes:
    - receiver: 'test.web.hook'
      continue: true
      match:
        groupId: node-disk-usage
    - receiver: 'test.web.hook'
      continue: true
      match:
        groupId: kafka-topic-highstore

alertRule 配置示例

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
   creationTimestamp: null
   labels:
      role: alert-rules
   name: node-disk-usage
   namespace: monitoring
spec:
   groups:
      - name: node-disk-usage
        rules:
           - alert: node-disk-usage
             expr: 100*(1-node_filesystem_avail_bytes{mountpoint="${path}"}/node_filesystem_size_bytes{mountpoint="${path}"} ) > ${thresholdValue}
             for: 1m
             labels:
                groupId: node-disk-usage
                userIds: super
                receivers: SMS
             annotations:
                title: "磁盘警告：节点{{$labels.instance}}的 ${path} 目录使用率已达到{{$value}}%"
                content: "磁盘警告：节点{{$labels.instance}}的 ${path} 目录使用率已达到{{$value}}%"

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  creationTimestamp: null
  labels:
    role: alert-rules
  name: kafka-topic-highstore-${uniqueName}
  namespace: monitoring
spec:
  groups:
    - name: kafka-topic-highstore
      rules:
      - alert: kafka-topic-highstore-${uniqueName}
        expr: sum(kafka_consumergroup_lag{exporterType="kafka",consumergroup="${consumergroup}"}) > ${thresholdValue}
        for: 1m
        labels:
          groupId: kafka-topic-highstore
          instanceId: ${uniqueName}
          userIds: super
          receivers: SMS
        annotations:
          title: "KAFKA警告：消费组 ${consumergroup}的堆积数量达到:{{$value}}"
          content: "KAFKA警告：消费组 ${consumergroup}的堆积数量达到:{{$value}}"

其他

告警流程示例

• 告警规则 : node-disk-usage - for 为 1m
• 告警中心 : alertManager - group_wait: 30s - group_interval: 5m - repeat_interval: 10m

10:23:14 收到第一次警报：node1 于 10:22:44 进入异常
10:28:14 收到第二次警报：node1 于 10:22:44 进入异常 node2 于 10:24:44 进入异常
10:38:29 收到第三次警报：node1 于 10:22:44 进入异常 node2 于 10:24:44 进入异常
10:48:44 收到第四次警报：node1 于 10:22:44 进入异常 node2 于 10:24:44 进入异常
10:58:44 收到第五次警报：恢复告警 node1 于 10:22:44 进入异常，并于 10:55:44 恢复 node2 于 10:24:44 进入异常，并于 10:49:14 恢复

node1 等待 for 1 分钟 后警报进入 group
node1 记录异常时间为 10:22:44，实际异常状态至少在 10:22:44 的一分钟前
group 等待 group_wait 30s 后发送第一次告警
firing:node1
node2 等待 for 1 分钟 后警报进入 group
node2 记录异常时间为 10:24:44，实际异常状态至少在 10:24:44 的一分钟前，此时 group 中有两个异常目标 node1 和 node2。
group 等待 group_interval 5m 后发送第二次告警
firing:node1,node2
注意：因为 group 发生了变化，所以这里用的是 group_interval。
group 等待 repeat_interval 10m 后发送第三次告警
firing:node1,node2
注意：因为 group 没有变化，属于重复告警，用的是 repeat_interval。
group 等待 repeat_interval 10m 后发送第四次告警
firing:node1,node2
同上一次。
第四次告警后的 前 5 分钟：node2 恢复正常
第四次告警后的 后 5 分钟：node1 恢复正常
group 等待 repeat_interval 10m 后发送第五次告警
resolved:node1,node2

for 是告警规则个体的监控配置，用来衡量服务多久检测不通过才算异常。
group_wait：初次发送告警的等待时间
用于 group 创建后的等待，这个值通常设置较小，在几分钟以内。
group_interval：同一个组其他新发生的告警发送时间间隔
是 group 内容发生变化后的告警间隔。
repeat_interval：重复发送同一个告警的时间间隔
group 内容没有变化且上一次发生成功时用的发生间隔。

exporter 的位置

使用 promtool 检查指标格式是否正确

# 进入pod
$ kubectl -n=monitoring exec -it prometheus-k8s-0  sh
# 查看帮助
$ promtool -h
# 检查指标格式
$ curl -s http://ip:9999/metrics | promtool check metrics

使用 port-forward 临时提供 Prometheus 外部访问

# prometheus
$ nohup  kubectl port-forward --address 0.0.0.0 service/prometheus-k8s 19090:9090 -n=monitoring &
# grafana
$ nohup kubectl port-forward --address 0.0.0.0 service/grafana 13000:3000 -n=monitoring &
# alertmanager
$ nohup  kubectl port-forward --address 0.0.0.0 service/alertmanager-main 9093:9093 -n=monitoring &

kube-prometheus 对 arm 的支持

• quay.io/prometheus/prometheus:v2.11.0 支持 arm（v2.10.0 开始）
• quay.io/prometheus/alertmanager:v0.18.0 支持 arm（v0.17.0 开始）
• quay.io/coreos/kube-state-metrics:v1.8.0 未标记（不支持）
• quay.io/coreos/kube-rbac-proxy:v0.4.1 未标记（不支持）
• quay.io/prometheus/node-exporter:v0.18.1 支持 arm（v0.18.0 开始）
• quay.io/coreos/prometheus-operator:v0.34.0 不支持 arm（v0.39 开始）。修改成使用 0.39.0，0.39 以后的 prometheus 要求 k8s 必须 >=1.16
• quay.io/coreos/configmap-reload:v0.0.1 未标记（不支持）
• grafana/grafana:6.4.3 官方说支持 arm，但其实不支持，有 bug，见：https://bleepcoder.com/cn/grafana/501674494/docker-arm-images-doesn-t-work-since-v6-4-x
• quay.io/coreos/k8s-prometheus-adapter-amd64:v0.5.0 未找到 arm 版本镜像。最新的官方版本已经改用 directxman12/k8s-prometheus-adapter:v0.8.4。而 directxman12/k8s-prometheus-adapter:v0.5.0 开始支持 arm
• 见：https://hub.docker.com/r/directxman12/k8s-prometheus-adapter/tags