基於 Prometheus 的監控系統實踐

監控作為底層基礎設施的一環，是保障生產環境服務穩定性不可或缺的一部分，線上問題從發現到定位再到解決，通過監控和告警手段可以有效地覆蓋了「發現」和「定位」，甚至可以通過故障自愈等手段實現解決，服務開發和運維人員能及時有效地發現服務執行的異常，從而更有效率地排查和解決問題。

一、Prometheus介紹

一個典型的監控(如白盒監控)，通常會關注於目標服務的內部狀態，例如：

• 單位時間接收到的請求數量
• 單位時間內請求的成功率/失敗率
• 請求的平均處理耗時

白盒監控很好地描述了系統的內部狀態，但缺少從外部角度看到的現象，比如：白盒監控只能看到已經接收的請求，並不能看到由於DNS故障導致沒有傳送成功的請求，而黑盒監控此時便可以作為補充手段，由探針(probe)程式來探測目標服務是否成功返回，更好地反饋系統的當前狀態。

某日需要為服務搭建一個監控系統來採集應用埋點上報的指標，Prometheus的業務監控，因為它具有以下優點：

① 支援PromQL(一種查詢語言)，可以靈活地聚合指標資料
② 部署簡單，只需要一個二進位制檔案就能跑起來，不需要依賴分散式儲存
③ Go語言編寫，元件更方便整合在同樣是Go編寫專案程式碼中
④ 原生自帶WebUI，通過PromQL渲染時間序列到皮膚上
⑤ 生態元件眾多，Alertmanager，Pushgateway，Exporter...

Prometheus的架構圖如下：

在上面流程中，Prometheus通過配置檔案中指定的服務發現方式來確定要拉取監控指標的目標(Target)，接著從要拉取的目標(應用容器和Pushgateway)，發起HTTP請求到特定的端點(Metric Path)，將指標持久化至本身的TSDB中，TSDB最終會把記憶體中的時間序列壓縮落到硬碟，除此之外，Prometheus會定期通過PromQL計算設定好的告警規則，決定是否生成告警到Alertmanager，後者接收到告警後會負責把通知傳送到郵件或企業內部群聊中。
Prometheus的指標名稱只能由 ASCII 字元、數字、下劃線以及冒號組成，而且有一套命名規範：

① 使用基礎 Unit(如 seconds 而非 milliseconds)
② 指標名以 application namespace 作為字首，如：
    process_cpu_seconds_total
    http_request_duration_seconds
③ 用字尾來描述 Unit，如：
    http_request_duration_seconds
    node_memory_usage_bytes
    http_requests_total
    process_cpu_seconds_total
    foobar_build_info

Prometheus 提供了以下基本的指標型別：

• Counter：代表一種樣本資料單調遞增的指標，即只增不減，通常用來統計如服務的請求數，錯誤數等。
• Gauge：代表一種樣本資料可以任意變化的指標，即可增可減，通常用來統計如服務的CPU使用值，記憶體佔用值等。
• Histogram 和 Summary：用於表示一段時間內的資料取樣和點分點陣圖統計結果，通常用來統計請求耗時或響應大小等。

Prometheus 是基於時間序列儲存的，首先了解一下什麼是時間序列，時間序列的格式類似於(timestamp，value)這種格式，即一個時間點擁有一個對應值，例如生活中很常見的天氣預報，如：[(14:00，27℃)，(15:00，28℃)，(16:00，26℃)]，就是一個單維的時間序列，這種按照時間戳和值存放的序列也被稱之為向量(vector)。
再來舉另一個例子，如上圖所示，假如有一個指標http_requests，它的作用是統計每個時間段對應的總請求量是多少，這時候它即為上面提到的是一個單維矩陣，而當我們給這個指標加上一個維度：主機名，這時候這個指標的作用就變成了統計每個時間段各個主機名對應的請求量是多少，這時候這個矩陣區域就變成擁有多列向量(每一列對應一個主機名)的時間序列，當給這個時間序列再新增多個標籤(key=value)時，這個矩陣就相應會變成一個多維矩陣。

每一組唯一的標籤集合對應著一個唯一的向量(vector)，也可叫做一個時間序列(Time Serie)，當在某一個時間點來看它時，它是一個瞬時向量(Instant Vector)，瞬時向量的時序只有一個時間點以及它對於的一個值，比如：今天 12:05:30 時伺服器的 CPU 負載；而在一個時間段來看它時，它是一個範圍向量(Range Vector)，範圍向量對於著一組時序資料，比如：今天11:00到12:00時伺服器的CPU負載。

類似的，可以通過指標名和標籤集來查詢符合條件的時間序列：

http_requests{host="host1",service="web",code="200",env="test"}

查詢結果會是一個瞬時向量：

http_requests{host="host1",service="web",code="200",env="test"} 10
http_requests{host="host2",service="web",code="200",env="test"} 0
http_requests{host="host3",service="web",code="200",env="test"} 12

而如果給這個條件加上一個時間引數，查詢一段時間內的時間序列：

http_requests{host="host1",service="web",code="200",env="test"}[:5m]

結果將會是一個範圍向量：

http_requests{host="host1",service="web",code="200",env="test"} 0 4 6 8 10
http_requests{host="host2",service="web",code="200",env="test"} 0 0 0 0 0
http_requests{host="host3",service="web",code="200",env="test"} 0 2 5 9 12

擁有了範圍向量，我們是否可以針對這些時間序列進行一些聚合運算呢？沒錯，PromQL就是這麼幹的，比如我們要算最近5分鐘的請求增長速率，就可以拿上面的範圍向量加上聚合函式來做運算：

rate(http_requests{host="host1",service="web",code="200",env="test"}[:5m])

比如要求最近5分鐘請求的增長量，可以用以下的PromQL：

increase(http_requests{host="host1",service="web",code="200",env="test"}[:5m])

要計算過去10分鐘內第90個百分位數：

histogram_quantile(0.9, rate(employee_age_bucket_bucket[10m]))

在Prometheus中，一個指標(即擁有唯一的標籤集的metric)和一個(timestamp，value)組成了一個樣本(sample)，Prometheus將採集的樣本放到記憶體中，預設每隔2小時將資料壓縮成一個block，持久化到硬碟中，樣本的數量越多，Prometheus佔用的記憶體就越高，因此在實踐中，一般不建議用區分度(cardinality)太高的標籤，比如：使用者IP，ID，URL地址等等，否則結果會造成時間序列數以指數級別增長(label數量相乘)。除了控制樣本數量和大小合理之外，還可以通過降低 storage.tsdb.min-block-duration來加快資料落盤時間和增加 scrape interval的值提高拉取間隔來控制Prometheus的佔用記憶體。

通過宣告配置檔案中的scrape_configs來指定Prometheus在執行時需要拉取指標的目標，目標例項需要實現一個可以被Prometheus進行輪詢的端點，而要實現一個這樣的介面，可以用來給Prometheus提供監控樣本資料的獨立程式一般被稱作為Exporter，比如用來拉取作業系統指標的Node Exporter，它會從作業系統上收集硬體指標，供Prometheus來拉取。

在開發環境，往往只需要部署一個Prometheus例項便可以滿足數十萬指標的收集。但在生產環境中，應用和服務例項數量眾多，只部署一個Prometheus例項通常是不夠的，比較好的做法是部署多個Prometheus例項，每個例項通過分割槽只拉取一部分指標，例如Prometheus Relabel配置中的hashmod功能，可以對拉取目標的地址進行hashmod，再將結果匹配自身ID的目標保留：

relabel_configs:
- source_labels: [__address__]
  modulus:       3
  target_label:  __tmp_hash
  action:        hashmod
- source_labels: [__tmp_hash]
  regex:         $(PROM_ID)
  action:        keep

或者說，我們想讓每個Prometheus拉取一個叢集的指標，一樣可以用Relabel來完成：

relabel_configs:
- source_labels:  ["__meta_consul_dc"]
  regex: "dc1"
  action: keep

二、Prometheus高可用

現在每個Prometheus都有各自的資料了，那麼怎麼把他們關聯起來，建立一個全域性的檢視呢？官方提供了一個做法：聯邦叢集(federation)，即把Prometheuse Server按照樹狀結構進行分層，根節點方向的Prometheus將查詢葉子節點的Prometheus例項，再將指標聚合返回。

不過顯然易見的時，使用聯邦叢集依然不能解決問題，首先單點問題依然存在，根節點掛了的話查詢將會變得不可用，如果配置多個父節點的話又會造成資料冗餘和抓取時機導致資料不一致等問題，而且葉子節點目標數量太多時，更加會容易使父節點壓力增大以至打滿當機，除此之外規則配置管理也是個大麻煩。

還好社群出現了一個Prometheus的叢集解決方案：Thanos，它提供了全域性查詢檢視，可以從多臺Prometheus查詢和聚合資料，因為所有這些資料均可以從單個端點獲取。
  1、Querier收到一個請求時，它會向相關的Sidecar傳送請求，並從他們的Prometheus伺服器獲取時間序列資料。
  2、它將這些響應的資料聚合在一起，並對它們執行PromQL查詢。 它可以聚合不相交的資料也可以針對Prometheus的高可用組進行資料去重。

有了Thanos之後，Prometheus的水平擴充套件就能變得更加簡單，不僅如此，Thanos還提供了可靠的資料儲存方案，可以監聽和備份prometheus本地資料到遠端儲存。另外，由於Thanos提供了Prometheus叢集的全域性檢視，那麼針對全域性Prometheus的記錄規則也不是問題，Thanos提供的Ruler元件，會基於Thanos Querier執行規則併發出告警。

三、Prometheus儲存

再來說到儲存，Prometheus查詢的高可用可以通過水平擴充套件+統一查詢檢視的方式解決，那麼儲存的高可用要怎麼解決呢？在Prometheus的設計中，資料是以本地儲存的方式進行持久化的，雖然本地持久化方便，當也會帶來一些麻煩，比如節點掛了或者Prometheus被排程到其他節點上，就會意味著原節點上的監控資料在查詢介面中丟失，本地儲存導致了Prometheus無法彈性擴充套件，為此Prometheus提供了Remote Read和Remote Write功能，支援把Prometheus的時間序列遠端寫入到遠端儲存中，查詢時可以從遠端儲存中讀取資料。

其中一個例子中就是M3DB，M3DB是一個分散式的時間序列資料庫，它提供了Prometheus的遠端讀寫介面，當一個時間序列寫入到M3DB叢集后會按照分片(Shard)和複製(Replication Factor)引數把資料複製到叢集的其他節點上，實現儲存高可用。除了M3DB外，Prometheus目前還支援InfluxDB、OpenTSDB等作為遠端寫的端點。

四、Prometheus採集資料方式

1、拉模式
解決了Prometheus的高可用，再來關注一下Prometheus如何對監控目標進行採集，當監控節點數量較小時，可以通過Static Config將目標主機列表寫到Prometheus的拉取配置中，但如果目標節點一多的話這種方式管理便有很大問題了，而且在生產環境中，服務例項的IP通常不是固定的，這時候用靜態配置就沒辦法對目標節點進行有效管理，這時候Prometheus提供的服務發現功能便可以有效解決監控節點狀態變化的問題，在這種模式下，Prometheus會到註冊中心監聽查詢節點列表，定期對節點進行指標的拉取。如果對服務發現有更靈活的需求，Prometheus也支援基於檔案的服務發現功能，這時候我們可以從多個註冊中心中獲取節點列表，再通過自己的需求進行過濾，最終寫入到檔案，這時候Prometheus檢測到檔案變化後便能動態地替換監控節點，再去拉取目標了。
2、Pushgateway
前面看到Prometheus都是以拉模式定期對目標節點進行抓取的，那假如有一種情況是一些任務節點還沒來得及被拉取就執行完退出了，這時候監控資料就會丟失，為了應對這種情況，Prometheus提供了一個工具：Pushgateway，用來接收來自服務的主動上報，它適用於那些短暫存活的批量任務來將指標推送並暫存到自身上，藉著再由Prometheus來拉取自身，以防止指標還沒來得及被Prometheus拉取便退出。除此以外Pushgateway也適用於在Prometheus與應用節點執行在異構網路或被防火牆隔絕時，無法主動拉取節點的問題，在這種情況下應用節點可以通過使用Pushgateway的域名將指標推送到Pushgateway例項上，Prometheus就可以拉取同網路下的Pushgateway節點了，另外配置拉取Pushgateway時要注意一個 問題 ：Prometheus會把每個指標賦予job和instance標籤，當Prometheus拉取Pushgateway時，job和instance則可能分別是Pushgateway和Pushgateway主機的ip，當pushgateway上報的指標中也包含job和instance標籤時，Prometheus會把衝突的標籤重新命名為exported_job和exported_instance，如果需要覆蓋這兩個標籤的話，需要在Prometheus中配置honor_labels: true。

Pushgateway可以替代拉模型來作為指標的收集方案，但在這種模式下會帶來許多負面影響：

Pushgateway被設計為一個監控指標的快取，這意味著它不會主動過期服務上報的指標，這種情況在服務一直執行的時候不會有問題，但當服務被重新排程或銷燬時，Pushgateway依然會保留著之前節點上報的指標。而且，假如多個Pushgateway執行在LB下，會造成一個監控指標有可能出現在多個Pushgateway的例項上，造成資料重複多份，需要在代理層加入一致性雜湊路由來解決

在拉模式下，Prometheus可以更容易的檢視監控目標例項的健康狀態，並且可以快速定位故障，但在推模式下，由於不會對客戶端進行主動探測，因此對目標例項的健康狀態也變得一無所知

五、Prometheus的Alertmanager

Alertmanager是與Prometheus分離的告警元件，主要接收Promethues傳送過來的告警事件，然後對告警進行去重，分組，抑制和傳送，在實際中可以搭配webhook把告警通知傳送到企業微信或釘釘上，其架構圖如下：

六、Kubernetes搭建Prometheus監控系統

雖然Promehteus已經有官方的Operator了，但是為了學習都用手動編寫yaml檔案，整個完成下來發現還是挺方便的，而且只需要用幾個例項就可以完成收集監控200+服務數千個例項的業務指標。

為了部署Prometheus例項，需要宣告Prometheus的StatefulSet，Pod中包括了三個容器，分別是Prometheus以及繫結的Thanos Sidecar，最後再加入一個watch容器，來監聽prometheus配置檔案的變化，當修改ConfigMap時就可以自動呼叫Prometheus的Reload API完成配置載入，這裡按照之前提到的資料分割槽的方式，在Prometheus啟動前加入一個環境變數PROM_ID，作為Relabel時hashmod的標識，而POD_NAME用作Thanos Sidecar給Prometheus指定的external_labels.replica來使用：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: prometheus
  labels:
    app: prometheus
spec:
  serviceName: "prometheus"
  updateStrategy:
    type: RollingUpdate
  replicas: 3
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
        thanos-store-api: "true"
    spec:
      serviceAccountName: prometheus
      volumes:
      - name: prometheus-config
        configMap:
          name: prometheus-config
      - name: prometheus-data
        hostPath:
          path: /data/prometheus
      - name: prometheus-config-shared
        emptyDir: {}
      containers:
      - name: prometheus
        image: prom/prometheus:v2.11.1
        args:
          - --config.file=/etc/prometheus-shared/prometheus.yml
          - --web.enable-lifecycle
          - --storage.tsdb.path=/data/prometheus
          - --storage.tsdb.retention=2w
          - --storage.tsdb.min-block-duration=2h
          - --storage.tsdb.max-block-duration=2h
          - --web.enable-admin-api
        ports:
          - name: http
            containerPort: 9090
        volumeMounts:
          - name: prometheus-config-shared
            mountPath: /etc/prometheus-shared
          - name: prometheus-data
            mountPath: /data/prometheus
        livenessProbe:
          httpGet:
            path: /-/healthy
            port: http
      - name: watch
        image: watch
        args: ["-v", "-t", "-p=/etc/prometheus-shared", "curl", "-X", "POST", "--fail", "-o", "-", "-sS", "http://localhost:9090/-/reload"]
        volumeMounts:
        - name: prometheus-config-shared
          mountPath: /etc/prometheus-shared
      - name: thanos
        image: improbable/thanos:v0.6.0
        command: ["/bin/sh", "-c"]
        args:
          - PROM_ID=`echo $POD_NAME| rev | cut -d '-' -f1` /bin/thanos sidecar
            --prometheus.url=http://localhost:9090
            --reloader.config-file=/etc/prometheus/prometheus.yml.tmpl
            --reloader.config-envsubst-file=/etc/prometheus-shared/prometheus.yml
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
        ports:
          - name: http-sidecar
            containerPort: 10902
          - name: grpc
            containerPort: 10901
        volumeMounts:
          - name: prometheus-config
            mountPath: /etc/prometheus
          - name: prometheus-config-shared
            mountPath: /etc/prometheus-shared

因為Prometheus預設是沒辦法訪問Kubernetes中的叢集資源的，因此需要為之分配RBAC：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: prometheus
  namespace: default
  labels:
    app: prometheus
rules:
- apiGroups: [""]
  resources: ["services", "pods", "nodes", "nodes/proxy", "endpoints"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["prometheus-config"]
  verbs: ["get", "update", "delete"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: prometheus
  namespace: default
  labels:
    app: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: default
roleRef:
  kind: ClusterRole
  name: prometheus
  apiGroup: ""

接著Thanos Querier的部署比較簡單，需要在啟動時指定store的引數為dnssrv+thanos-store-gateway.default.svc來發現Sidecar：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: thanos-query
  name: thanos-query
spec:
  replicas: 2
  selector:
    matchLabels:
      app: thanos-query
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: thanos-query
    spec:
      containers:
      - args:
        - query
        - --log.level=debug
        - --query.timeout=2m
        - --query.max-concurrent=20
        - --query.replica-label=replica
        - --query.auto-downsampling
        - --store=dnssrv+thanos-store-gateway.default.svc
        - --store.sd-dns-interval=30s
        image: improbable/thanos:v0.6.0
        name: thanos-query
        ports:
        - containerPort: 10902
          name: http
        - containerPort: 10901
          name: grpc
        livenessProbe:
          httpGet:
            path: /-/healthy
            port: http
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: thanos-query
  name: thanos-query
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 10901
    targetPort: http
  selector:
    app: thanos-query
---
apiVersion: v1
kind: Service
metadata:
  labels:
    thanos-store-api: "true"
  name: thanos-store-gateway
spec:
  type: ClusterIP
  clusterIP: None
  ports:
  - name: grpc
    port: 10901
    targetPort: grpc
  selector:
    thanos-store-api: "true"

部署Thanos Ruler：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: thanos-rule
  name: thanos-rule
spec:
  replicas: 1
  selector:
    matchLabels:
      app: thanos-rule
  template:
    metadata:
      labels:
      labels:
        app: thanos-rule
    spec:
      containers:
      - name: thanos-rule
        image: improbable/thanos:v0.6.0
        args:
        - rule
        - --web.route-prefix=/rule
        - --web.external-prefix=/rule
        - --log.level=debug
        - --eval-interval=15s
        - --rule-file=/etc/rules/thanos-rule.yml
        - --query=dnssrv+thanos-query.default.svc
        - --alertmanagers.url=dns+http://alertmanager.default
        ports:
        - containerPort: 10902
          name: http
        volumeMounts:
          - name: thanos-rule-config
            mountPath: /etc/rules
      volumes:
      - name: thanos-rule-config
        configMap:
          name: thanos-rule-config

部署Pushgateway：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: pushgateway
  name: pushgateway
spec:
  replicas: 15
  selector:
    matchLabels:
      app: pushgateway
  template:
    metadata:
      labels:
        app: pushgateway
    spec:
      containers:
      - image: prom/pushgateway:v1.0.0
        name: pushgateway
        ports:
        - containerPort: 9091
          name: http
        resources:
          limits:
            memory: 1Gi
          requests:
            memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: pushgateway
  name: pushgateway
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 9091
    targetPort: http
  selector:
    app: pushgateway

部署Alertmanager：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager
spec:
  replicas: 3
  selector:
    matchLabels:
      app: alertmanager
  template:
    metadata:
      name: alertmanager
      labels:
        app: alertmanager
    spec:
      containers:
      - name: alertmanager
        image: prom/alertmanager:latest
        args:
          - --web.route-prefix=/alertmanager
          - --config.file=/etc/alertmanager/config.yml
          - --storage.path=/alertmanager
          - --cluster.listen-address=0.0.0.0:8001
          - --cluster.peer=alertmanager-peers.default:8001
        ports:
        - name: alertmanager
          containerPort: 9093
        volumeMounts:
        - name: alertmanager-config
          mountPath: /etc/alertmanager
        - name: alertmanager
          mountPath: /alertmanager
      volumes:
      - name: alertmanager-config
        configMap:
          name: alertmanager-config
      - name: alertmanager
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  labels:
    name: alertmanager-peers
  name: alertmanager-peers
spec:
  type: ClusterIP
  clusterIP: None
  selector:
    app: alertmanager
  ports:
  - name: alertmanager
    protocol: TCP
    port: 9093
    targetPort: 9093

最後部署一下ingress：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: pushgateway-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: $(DOMAIN)
    http:
      paths:
      - backend:
          serviceName: pushgateway
          servicePort: 9091
        path: /metrics
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prometheus-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: $(DOMAIN)
    http:
      paths:
      - backend:
          serviceName: thanos-query
          servicePort: 10901
        path: /
      - backend:
          serviceName: alertmanager
          servicePort: 9093
        path: /alertmanager
      - backend:
          serviceName: thanos-rule
          servicePort: 10092
        path: /rule
      - backend:
          serviceName: grafana
          servicePort: 3000
        path: /grafana

訪問Prometheus地址，監控節點狀態正常：