理解OpenShift（7）：基於 Prometheus 的集羣監控

時間 2019-11-05

標籤理解 openshift 基於 prometheus 集羣監控欄目負載均衡简体版

原文原文鏈接

理解OpenShift（1）：網絡之 Router 和 Routehtml

理解OpenShift（2）：網絡之 DNS（域名服務）node

理解OpenShift（3）：網絡之 SDNgit

理解OpenShift（4）：用戶及權限管理github

理解OpenShift（5）：從 Docker Volume 到 OpenShift Persistent Volume數據庫

理解OpenShift（6）：集中式日誌處理segmentfault

理解OpenShift（7）：基於 Prometheus 的集羣監控後端

** 本文基於 OpenShift 3.11，Kubernetes 1.11 進行測試 ***api

和日誌系統同樣，監控系統也是平臺一大不可或缺的組成部分。在敏態的OpenShift 和 Kubernetes 平臺之中，運行平臺組件及業務應用的Pod 時刻都處於變化之中，並且數量可能會巨大。在這種狀況下，對監控系統的要求會更高。當前，基於 Prometheus 和 Granfana 的監控系統，對於OpenShfit 和 Kubernetes 這樣的平臺來講，是一個比較好的選擇。可是，Prometheus 自己就至關複雜，再加上覆雜的容器雲平臺，複雜性成倍提升。本文試着對它的原理進行梳理，但確定沒法面面俱到。更多更詳細的信息，還請查閱更多資料。微信

1. Prometheus 概述

關於 Prometheus 的文檔很是多，這裏不會詳細說明，只是一個概述。網絡

它是什麼：

一個帶時序數據庫（TSDB）的監控系統。SoundCloud 在2012年開始開發，2015年開源，如今是 CNCF 繼 Kuebernetes 以後的第二個項目。
經過拉取（pull）方式收集測量數據，並將其保存在TSDB 中。
提供計量數據查詢功能，實現了相似於 SQL 的查詢語法PromSQL。
提供告警功能，能根據已定義的告警規則向外輸出告警。
雖然它本身實現了一個面板，但還比較簡陋。如今主流的作法是將它和 Grafana 結合，由 Grafana 提供面板。

它不是什麼：

它不處理日誌或跟蹤（tracing），只處理計量數據。
它自己不是專門的具備良好擴展性的持久存儲。它自身的存儲，被設計爲用於短期保存數據。

它的基本架構：

關於架構的簡單說明：

左側是被監控的對象（target）。若是監控對象自身提供知足Prometheus要求的測量數據的 HTTP API（好比cAdvisor，https://github.com/google/cadvisor），則能夠直接和 Prometheus 對接；不然，能夠藉助 exporter 來實現對接（好比 node exporter，https://github.com/prometheus/node_exporter）。exporter 會從應用中獲取測量數據，而後提供HTTP API，再和 Prometheus 對接。
中下部分是 Prometheus。它的開源項目地址是 https://github.com/prometheus。它是監控系統的中心，負責策略數據收集、存儲、告警、查詢等。
中上部分是服務發現，用於動態對象的監控。在不少現代系統中，被監控對象不是靜態的，好比 K8S 中的Pod。對於動態目標，按照靜態目標那種監控方式就很難了，所以 Prometheus 提供了服務發現功能。它能動態地發現被監控的對象，而後對它們作監控。
右上是 AlertManager。其開源項目地址是 https://github.com/prometheus/alertmanager。它接受 Prometheus 根據所配置的告警規則發過來的告警，而後作去重、分組和路由等處理，而後發給外部的接口組件，好比 PageDuty、郵件系統等。
右下是 Grafana。其開源項目地址是 https://github.com/grafana/grafana。它以Prometheus 爲後端（它支持對接不少種後端），根據配置，從中獲取數據，而後以很是漂亮的界面（Dashboard）將數據呈現出來。

網上有不少不少的關於 Prometheus 的文檔，好比 https://yunlzheng.gitbook.io/prometheus-book/ 。

2. 利用 Prometheus 對 OpenShfit 集羣進行監控

2.1 OpenShfit 集羣的監控需求

上圖整理了OpenShift 集羣的監控需求。它包括兩大部分：

一部分是對OpenShift 平臺進行監控，確保它穩定運行。這是平臺運維團隊的需求。這部分又包括不少內容，包括節點監控（節點的CPU、內存、網絡、存儲等）、容器監控（每一個容器所消耗的資源，包括cpu、內存、網絡、文件系統等），以及 OpenShift 核心組件等。
另外一部分是運行在OpenShfit 平臺上的業務服務，確保業務服務穩定運行，這是應用開發和運維團隊的需求。

2.2 基於 Prometheus 的 OpenShift 監控系統的實現

爲了知足上述監控需求，OpenShift 提供了基於 Prometheus + Grafana 的監控系統。針對每一個須要被監控的目標（target），都利用了Prometheus提供的某個功能來實現對它的監控。

先上一張官方的架構圖：

我畫的邏輯圖：

具體每一個部分在後文會有相關介紹。

2.3 基於 Prometheus 的 OpenShift 監控系統的部署和維護

OpenShfit 利用 ansible 在某個project（個人是 openshift-monitoring）中部署包括 Prometheus 和 Granfana 在內的監控系統。這裏面主要用到兩個開源項目：

一個是 Cluster Monitoring Operator。它的開源項目地址是 https://github.com/openshift/cluster-monitoring-operator。它負責在 OpenShfit 環境中部署基於 Prometheus 的監控系統。
另外一個是 Prometheus Operator。它的開源項目地址是 https://github.com/coreos/prometheus-operator。它負責在 Kubernetes 環境中部署基於 Prometheus 的監控系統。

關於這兩個 Operator 的更多信息，請查閱有關文檔。下面只介紹某些重點部分。

Cluster Monitoring Operator 只是很薄的一層，可是它是入口。它的主要任務是負責把 Prometheus Operator 建立出來。

Prometheus Operator 是 CoreOS 開源的項目，它就很複雜了。如下圖爲參照，它負責建立和管理三種東西：

第一種是 Prometheus 及相關的服務。默認包括 alertmanager 服務、Prometheus 服務、Grafana 服務、kube-state-metrics 服務、node-exporter 服務。
第二種是4個 CRD 類型（實際上有6個，但另兩個的用途不明），包括 AlterManager，Prometheus、PrometheusRule 和 ServiceMonitor。

每個 CRD 都是一個相似 Deployment 配置，從名字上能夠看出與實體的對應關係。
Prometheus Operator 會監控這些實例。若是發現有更改，則會對相應的實體作變動。好比若 PrometheusRule 的內容被修改，那麼新的監控和告警規則會被 Prometheus 從新加載。
所以，定義這些 CRD 類型的目的，是爲了簡化對 Prometheus 系統的管理。管理員只須要對這些 CRD 實例作管理，系統就會自動對實例作變動。

1 個 alertmanager 實例對應 alertmanager 服務，每一個服務默認3 個副本，也就是有3個 Pod。
1 個 Prometheus 實例對應 Prometheus 服務，每一個服務默認2個副本，也就是有2個 Pod。
1 個 PrometheusRule 實例對應當前 Prometheus 實例所使用的監控和告警規則。
9 個 ServiceMonitor 實例，對應對 Prometheus 所監控的9個目標，這裏的每一個目標都是一個 OpenShift 服務。下面會詳細說明

2.4 ServiceMonitor 實例

ServiceMonitor 是 Prometheus Operator 向運維人員暴露出來的被監控的目標。在部署完成後，默認建立了9個 ServiceMonitor 對象，對應9個須要被 Prometheus 監控的核心平臺服務：

2.4.1 alertmanager

AlterManager 是一個 Prometheus 套件中的獨立組件，它自身實現了符合 Prometheus 要求的計量信息接口。

2.4.2 cluster-monitoring-operator

這是 OpenShift cluster monitoring opeator 服務。它也實現了計量接口。

2.4.3 kube-apiserver

這是 OpenShift 的 API 和 DNS 服務。

2.4.4 kube-controllers

這是 K8S master controllers 服務。

2.4.5 kube-state-metrics

這是一個開源項目，地址在 https://github.com/kubernetes/kube-state-metrics。它從 K8S API Server 中獲取數據，好比：

ksm_resources_per_scrape{resource="node",quantile="0.99"} 7
ksm_resources_per_scrape_sum{resource="node"} 255444
ksm_resources_per_scrape_count{resource="node"} 36492
ksm_resources_per_scrape{resource="persistentvolume",quantile="0.5"} 15
ksm_resources_per_scrape{resource="persistentvolume",quantile="0.9"} 15

2.4.6 kubelet

kubelet 服務包含多個Static Pod，每一個Pod運行在集羣的每一個節點上。它除了自身提供 kublet 的計量信息外，還內置了 cAdvisor 服務，所以也提供 cAdvisor 信息。 cAdvisor 對 Node機器上的資源及容器進行實時監控和性能數據採集，包括CPU使用狀況、內存使用狀況、網絡吞吐量及文件系統使用狀況。cAdvisor集成在Kubelet中，當kubelet啓動時會自動啓動cAdvisor，一個cAdvisor僅對一臺Node機器進行監控。

2.4.7 node-exporter

node-exporter 服務包含多個 DaemonSet Pod，每一個 Pod 運行在一個集羣節點上。它主要用於 Linux 系統監控，其開源項目地址爲 https://github.com/prometheus/node_exporter。

2.4.8 prometheus

這是 Prometheus 服務，它可有多個 StatefulSet Pod，每一個 Pod 中運行一個 Prometheus 進程。

2.4.9 prometheus-operator

這是 Prometheus Operator 服務，只有一個pod。

2.5 基於OpenShift ServiceMonitor 和 Prometheus Service Discovery（服務發現）的監控的實現

Prometheus Pod 中，除了 Prometheus 容器外，還有一個 prometheus-config-reloader 容器。它負責導入在須要的時候讓Prometheus 從新加載配置文件。配置文件被以 Secret 形式建立並掛載給 prometheus-config-reloader Pod。一旦配置有變化，它會調用 Prometheus 的接口，使其從新加載配置文件。

配置文件中定義了被監控的目標爲這些 ServiceMonitor 對象所對應的服務：

每一個 job 都採用 endpoints 類型的 Prometheus 服務發現機制。這種機制下，Prometheus 會調用 OpenShift 的API，首先找到每一個 job 所配置的 OpenShift 服務，而後找到這服務的端點（endpoint）。每一個 OpenShfit endpoint 是一個 Prometheus target（目標），能夠在 Prometheus 界面上看到目標列表。而後在每一個目標上，調用 metrics HTTP API，以拉取（GET）形式，得到該服務的計量數據。

關於 Premetheus 對 OpenShift/Kubernetes 平臺所作的監控的詳細狀況，下面這一系列文章作了比較詳細的解釋：https://blog.freshtracks.io/a-deep-dive-into-kubernetes-metrics-b190cc97f0f6。

3. 利用 Prometheus 對部署在 OpenShift 平臺上的應用進行監控

3.1 技術實現

3.1.1 監控框架總結

把前面的內容再總結一下，就有了下面的監控框架圖：

3.1.2 監控一個運行在OpenShift 中的應用

Prometheus 對容器雲平臺作監控時，已經能夠採集到容器的一些資源使用計量數據了，好比CPU、內存、網絡、存儲、文件系統等。但這還不夠，由於沒有應用自身的計量信息。要使得Prometheus 能採集到應用自身的監控信息，須要知足一些條件，並作一些配置。

首先，應用的計量數據是應用本身產生的，只不過是被Prometheus獲取了。一個應用要可以被Prometheus 監控，須要知足幾個條件：

首先的要求是，應用要暴露出它的計量數據。若是它不提供計量數據，也就不須要被監控了。
其次，須要知足 Prometheus 的數據格式和數據獲取要求。Prometheus 定義了計量數據的規範，同時定義了獲取方式（經過HTTP Get 獲取）。若是應用須要直接被Prometheus 監控，那麼就得知足這些要求。
若是應用自己有數據，可是不知足Prometheus 的要求，也有一些辦法。其中一個辦法是實現一個 sidecar exporter。它負責以應用特有的格式去獲取應用的計量數據，而後按照 Prometheus 的要求將數據暴露出來。Prometheus 項目中已經有了一些實現，好比 HAProxy 的 exporter 在 https://github.com/prometheus/haproxy_exporter。

其次，須要作一些配置，使得 Prometheus 知道如何去獲取應用的計量數據。從上圖能夠看出，經過使用 Prometheus Operator，配置監控的過程被大大簡化了。基本上大體步驟爲：

部署應用服務，檢查它的或他的 exporter 的 metrics HTTP API 可否正確運行
爲該應用服務建立一個 ServiceMonitor 對象
修改 PrometheusRule 對象，爲應用添加監控和告警規則

而後，Prometheus 就會自動地將這些變更應用到 Prometheus 和 AlterManager 實例中，而後該應用就會被監控到了。

3.2 產品相關

對這套基於 Prometheus 的OpenShift/Kubernetes 監控系統，到目前爲止，我認爲它還不夠成熟，在不少地方有待改進。好比Prometheus高可用，目前尚未很好的方法；好比Prometheus 的存儲，從設計上它就只能做爲短時間存儲，若是應用於大型的生產環境，短期內就會產生大量數據，那該怎麼辦？；好比監控和告警規則配置，還不夠靈活和方便；好比服務發現，若是被監控的目標量很大並且變化很快，Prometheus 可否可以及時響應？Grafana 如何作多租戶實現？等等。

所以，當前，我認爲它仍是更加適合於平臺監控，也就是面向平臺運維人員的。由於此時不少要求均可以被妥協，好比穩定性、擴展性、多租戶、靈活性、用戶友好等。

若是要用於用戶應用的監控，從產品和技術層面，那還有大量工做須要作，包括但不限於：