理解OpenShift（1）：網絡之 Router 和 Route
理解OpenShift（5）：從 Docker Volume 到 OpenShift Persistent Volume
理解OpenShift（7）：基於 Prometheus 的集群監控
** 本文基於 OpenShift 3.11，Kubernetes 1.11 進行測試 ***
和日志系統一樣，監控系統也是平台一大不可或缺的組成部分。在敏態的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
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 如何做多租戶實現？等等。
因此，當前，我認為它還是更加適合於平台監控，也就是面向平台運維人員的。因為此時很多要求都可以被妥協，比如穩定性、擴展性、多租戶、靈活性、用戶友好等。
如果要用於用戶應用的監控，從產品和技術層面，那還有大量工作需要做，包括但不限於：
- 用戶如何配置其應用監控（如何創建和管理 CRD 對象等）
- 用戶如何創建和管理監控和告警規則
- Grafana 如何實現多租戶
- Prometheus 如何支持大量的被監控對象和計量信息
參考鏈接：
- http://supergiant.io/blog/introduction-to-kubernetes-monitoring-architecture/
- https://segmentfault.com/a/1190000013230914
- https://yunlzheng.gitbook.io/prometheus-book/part-iii-prometheus-shi-zhan/readmd/service-discovery-with-kubernetes
- https://sysdig.com/blog/kubernetes-monitoring-prometheus/
- https://blog.freshtracks.io/a-deep-dive-into-kubernetes-metrics-66936addedae
感謝您的閱讀，歡迎關注我的微信公眾號：
