眾所周知，大資料產品作為底層平臺，其運維監控一直是生產實踐的痛點難點，且在穩定執行的基礎之上往往還需要對效能進行評估最佳化，所以其監控系統的建設顯得尤為重要。

一、設計思路

監控系統的核心任務是將暴露出來的指標資料進行抓取，在此之上進行分析、告警，所以有以下幾個要明確的問題：

1. 監控物件是什麼

2. 監控物件如何暴露指標資料

3. 監控系統如何對指標進行抓取

4. 如何實現告警規則動態配置、管理

監控物件

以 pod（容器）形式執行在 kubernetes 叢集上的各個大資料元件。

指標暴露方式

各元件根據對 Prometheus 的支援程度，可分為 3 種型別的指標暴露方式：

1. 直接暴露 Prometheus 指標資料 (直接，拉)

2. 主動將指標資料推送到 prometheus-pushGateway，由 pushGateway 暴露資料（間接，推）

3. 自定義 exporter 將其他形式的指標資料轉換為符合 Prometheus 標準的格式進行暴露（exporter，直接，拉）

指標抓取方式

不管是 exporter 還是 pushGateway，到最後必然是由 Prometheus 主動對這些目標進行抓取。

Prometheus 主要透過 Pull 的方式來抓取目標服務暴露出來的監控介面，
因此需要配置對應的抓取任務來請求監控資料並寫入到 Prometheus 提供的儲存中，

目前 Prometheus 服務提供瞭如下幾個任務的配置：

• 原生 Job 配置： 提供 Prometheus 原生抓取 Job 的配置。

• Pod Monitor： 在 K8S 生態下，基於 Prometheus Operator 來抓取 Pod 上對應的監控資料。

• Service Monitor： 在 K8S 生態下，基於 Prometheus Operator 來抓取 Service 對應 Endpoints 上的監控資料。

參考：https://cloud.tencent.com/document/product/1416/55995

既然都上了 K8s 環境了，一般當然是推薦直接用 podMonitor。配置更簡潔易懂。

podMonitorSelector 的過濾在  prometheus-prometheus.yaml  配置。

prometheus-prometheus.yaml 是核心配置檔案，不宜頻繁修改（會導致 Prometheus 重啟）。

這種屬於原生 Job 配置，建議使用 additional-scrape-config 進行配置。

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

告警設計

告警流程

prometheus 的監控告警基本流程是：

1. 服務發生異常

2. 觸發 prometheus 伺服器發出告警資訊（alert）

3. alertmanager 收到告警資訊

4. alertmanager 根據預配置的規則對告警資訊進行處理，實現業務邏輯，如分組、抑制、觸發簡訊郵箱等

5. 當然具體的流程沒那麼簡單，有很多細節需要注意，特別是觸發告警時機，是個重點。

告警的動態配置

kube-prometheus 的告警規則分兩部分：

1. alertmanager：即對告警資訊的處理策略

2. alertRule：即具體的告警規則

接入自定義告警平臺

告警層級標籤設計

二、技術實現

技術實現主要分以下幾部分：

1. kubernetes 環境下 prometheus 的部署（kube-prometheus）

2. kube-prometheus 的增強配置：即 kubernetes_sd_config+relabel 方案的實現

3. bigdata-exporter 的實現

4. 告警設計例項

1.Kubernetes 環境下 prometheus 的部署

1）kube-prometheus vs prometheus-operator

github 上 coreos 下有兩個專案 ：kube-prometheus 和 prometheus-operator

兩者都可以實現 prometheus 的建立及管理。

需要注意的是，kube-prometheus 上的配置操作也是基於 prometheus-operator 的，並提供了大量的預設配置，故這裡使用的是 kube-prometheus 專案的配置。

另外使用前需注意 K8s 版本要求，找到對應的 kube-prometheus 版本，弄清楚對應的 prometheus-operator 版本

如：k8s1.14 版本最高可使用 kube-prometheus 0.3，對應的 prometheus-operator 版本是 0.32

閱讀文件時注意對應版本。

2）kube-prometheus 使用前說明

kube-prometheus 使用 jsonnet 編寫配置模板檔案，生成 K8s 配置清單。

已提供預設清單檔案，在 manifests 資料夾下。

如果需要修改預設清單配置，需要在 Go 環境下使用 jp 編譯清單。

下面都以預設配置為例

2. kubernetes_sd_config+relabel 方案的實現

見：

3. bigdata-exporter的實現

hdfs、yarn、hbase、yarn 等元件都提供了 web 獲取 jmx 指標的方式。

指標資料的轉換規則可以檢視 github 上的一些專案，要注意版本，也可以像我一樣自己寫，更可靠。

bigdata-exporter 如何感知到採集目標？

1. 授予 bigdata-exporter 呼叫kubernetes app的能力，

2. 利用 label 和 annotations 進行篩選和資訊傳遞，確定捕捉目標和途徑。

3. 使用 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"

4.告警設計示例

這裡以組和例項兩個維度為例，用 groupId 和 instanceId 表示。

1) alertManager配置示例

使用data欄位的配置方法：

寫好 config 檔案，以 alertmanager.yaml 命名（不能使用其他名稱）。

執行以下命令，即可更新 secret。

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

global:    resolve_timeout: 5mreceivers:  - name: 'default'  - name: 'test.web.hook'    webhook_configs:      - url: '[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

2）alertRule配置示例

組代表一個型別的所有目標：即所有節點

例項則代表具體的某個節點

在這個任務中，我們的目標是組粒度的（所有節點），所以不需要設定 instanceId。

apiVersion: monitoring.coreos.com/v1kind: PrometheusRulemetadata:   creationTimestamp: null   labels:      role: alert-rules   name: node-disk-usage   namespace: monitoringspec:   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/v1kind: PrometheusRulemetadata:  creationTimestamp: null  labels:    role: alert-rules  name: kafka-topic-highstore-${uniqueName}  namespace: monitoringspec:  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 恢復

第 5 次是已經恢復正常了。

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

注意，這裡 node1,node2 都恢復正常用的也是 repeat_interval。

綜上：

• for 是告警規則個體的監控配置，用來衡量服務多久檢測不透過才算異常。
• group_wait：初次傳送告警的等待時間
  用於 group 建立後的等待，這個值通常設定較小，在幾分鐘以內。
• group_interval：同一個組其他新發生的告警傳送時間間隔
  是 group 內容發生變化後的告警間隔。
• repeat_interval：重複傳送同一個告警的時間間隔
  group 內容沒有變化且上一次發生成功時用的發生間隔。

需要注意，恢復正常不屬於 group 變化，用的是 repeat_interval。這有點反直覺，且個人認為不是很合理，不知道是不是測試有問題，也沒有找到比較好的資料說明。希望知道的可以指教一下。

使用 promtool 檢查指標格式是否正確

promtool 使用方法：

# 進入pod$ kubectl -n=monitoring exec -it prometheus-k8s-0  sh# 檢視幫助$ promtool -h# 檢查指標格式$ curl -s | promtool check metrics

比方說 指標 name、labelname 不能使用小數點

使用 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 &

用  jobs -l  可以檢視

來源：