在之前的內容中，我們深入探討了如何利用 Kubernetes 進行部署。大家已經瞭解到，在 EasyMR 的整體架構中，我們使用進行節點和服務監控資料的採集、查詢和儲存。同時，作為強大的視覺化工具，將 Prometheus 中的監控資料以多樣化的方式展示出來。

在本文中，我們將詳細探討在 EasyMR 中如何動態採集 Kubernetes 應用監控資料。

傳統採集方案的痛點

在主機模式下，使用 Prometheus 監控的配置主要依賴於 static_configs 和 file_sd_configs。因為在這種部署方案下，節點與應用的穩定性較高，涉及到的變更與不確定性較小，除非出現節點當機這樣的極端情況，我們才需要手動去修改對應採集 Job 配置。

file

但是在雲原生時代的背景下，監控作為中的關鍵部分，相對於傳統架構下的系統和應用監控發生了一些重大的變化：

· 微服務和導致監控物件和指標的指數級增加

· 監控物件的生命週期更加短暫，導致監控資料量和複雜度成倍增加

通俗來說，就是我們的中會有很多 Node/Service/Pod 等資源，這些資源會隨著需求規模的變化而動態變化，同一個應用 Pod 的 IP、名稱也會隨著應用的重啟、滾動更新而發生改變。

所以當 Kubernetes 資源建立或者更新時，如果一個個去修改 Prometheus 中的 Job 任務會是一個非常龐大的工作量，因為你無法判斷 Pod 重啟的時間（Kubernetes 有自己的 scheduler，可能 Pod 當前所在主機 CPU/記憶體/磁碟壓力過大，可能 Pod 達到設定資源限制等等，這些都會導致 Pod 的重新排程）。在這個背景下，我們就需要 Prometheus 擁有的功能。

Prometheus 服務自動發現

對於上述無法使用靜態採集配置static_configs 和 file_sd_configs 的場景，Prometheus 自身提供了一個解決方案：引入一個。這個註冊中心掌握著當前所有監控目標的訪問資訊，Prometheus 只需要向它詢問有哪些監控目標即可。Prometheus 查詢到需要監控的，然後輪訓這些 Target 獲取監控資料。

Prometheus 支援多種：檔案、DNS、Consul、Kubernetes、OpenStack、EC2 等，本文以 Kubernetes 服務發現機制為例詳細討論。

在 Kubernetes 下，Prometheus 透過與 Kubernetes API 整合主要支援5種服務發現模式：Node、Service、Pod、Endpoints、Ingress。

不同的服務發現模式適用於不同的場景，例如：適用於與主機相關的監控資源，如節點中執行的 Kubernetes 元件狀態、節點上執行的容器狀態等；Service 和 Ingress 適用於透過的場景，如對服務的可用性以及服務質量的監控；Endpoints 和 Pod 均可用於獲取的監控資料，如監控使用者或者管理員部署的支援 Prometheus 的應用。

EasyMR 對 K8S 應用的監控實踐

Prometheus 使用來獲取指標，所以對需要監控的目標應用來說需要暴露/metrics 介面。接下來我們從部署 Prometheus 的步驟開始，以採集 MySQL 的監控資訊來具體描述是如何運用 Prometheus 的服務發現機制的。

建立 Prometheus 配置檔案

Prometheus 自動發現的核心之處在於 relabel_configs 的相關配置，首先是透過 source_labels 配置以 _meta 開頭的這些後設資料標籤，宣告要匹配的資源，然後透過找到相關的資源物件，最後再對採集過來的指標做二次處理，比如保留、過來、替換等操作。

file

建立 ServiceAccount/Role/RoleBinding

由於 Prometheus 是需要訪問 Kubernetes 資源的，而且 Kubernetes 有詳細的，所以在部署 Prometheus 之前需要建立對應的賬號，併為該賬號賦予對應介面的許可權。出於安全考慮，EasyMR 只需要獲取對應 namespace 的許可權，所以我們不需要全域性的 ClusterRole 許可權。

file