跳至主要内容

監控如何運作

1. 架構概覽​

以下部分說明資料如何流經監控 V2 應用程式：

Prometheus Operator​

Prometheus Operator 觀察 ServiceMonitors、PodMonitors 和 PrometheusRules 的建立。當 Prometheus 配置資源建立時，Prometheus Operator 會呼叫 Prometheus API 來同步新配置。如本節末尾的圖表所示，Prometheus Operator 充當 Prometheus 和 Kubernetes 之間的中介，呼叫 Prometheus API 來同步 Prometheus 與 Kubernetes 中的監控相關資源。

ServiceMonitors 和 PodMonitors​

ServiceMonitors 和 PodMonitors 宣告式地指定需要監控的目標，例如 Services 和 Pods。

  • 目標根據配置的 Prometheus 抓取間隔定期抓取，抓取的指標儲存到 Prometheus 時間序列資料庫 (TSDB) 中。

  • 為了執行抓取，ServiceMonitors 和 PodMonitors 使用標籤選擇器定義，這些選擇器決定應該抓取哪些 Services 或 Pods，以及端點決定如何在給定目標上進行抓取，例如在 TCP 10252 中抓取 /metrics，透過 IP 位址 x.x.x.x 代理。

  • 開箱即用，監控 V2 帶有某些預先配置的匯出器，這些匯出器根據部署的 Kubernetes 叢集類型進行部署。有關更多資訊，請參閱抓取和公開指標。

PushProx 如何運作​

  • 某些內部 Kubernetes 元件透過作為監控 V2 的一部分部署的名為 PushProx 的代理進行抓取。透過 PushProx 向 Prometheus 公開指標的 Kubernetes 元件如下： kube-controller-manager、kube-scheduler、etcd 和 kube-proxy。

  • 對於每個 PushProx 匯出器，我們會在所有目標節點上部署一個 PushProx 客戶端。例如，PushProx 客戶端部署在所有 kube-controller-manager 的控制平面節點上、所有 kube-etcd 的 etcd 節點上，以及所有 kubelet 的節點上。

  • 我們為每個匯出器部署正好一個 PushProx 代理。匯出指標的過程如下：

  1. PushProx 客戶端與 PushProx 代理建立出站連接。
  2. 然後客戶端輪詢代理以獲取進入代理的抓取請求。
  3. 當代理從 Prometheus 接收抓取請求時，客戶端會看到它作為輪詢的結果。
  4. 客戶端抓取內部元件。
  5. 內部元件透過將指標推回代理來回應。

使用 PushProx 匯出指標的過程：

使用 PushProx 匯出指標的過程

PrometheusRules​

PrometheusRules 允許使用者定義規則，決定哪些指標或時間序列資料庫查詢應該觸發警示。規則會定期評估。

  • 記錄規則根據已收集的現有序列建立新的時間序列。它們經常用於預先計算複雜查詢。
  • 警示規則執行特定查詢，如果查詢評估為非零值，則從 Prometheus 觸發警示。

警示路由​

一旦 Prometheus 確定需要觸發警示，警示就會轉發到 Alertmanager。

  • 警示包含來自 PromQL 查詢本身的標籤，以及可以作為指定初始 PrometheusRule 的一部分提供的其他標籤和註解。

  • 在接收任何警示之前，Alertmanager 將使用其配置中指定的路由和接收器來形成路由樹，所有傳入的警示都在該樹上進行評估。路由樹的每個節點可以根據附加到 Prometheus 警示的標籤指定需要進行的額外分組、標記和篩選。路由樹上的節點（通常是葉節點）還可以指定到達它的警示需要發送到配置的接收器，例如 Slack、PagerDuty、SMS 等。請注意，Alertmanager 將首先將警示發送到 alertingDriver，然後 alertingDriver 將警示發送或轉發到適當的目的地。

  • 路由和接收器也透過 Alertmanager Secret 儲存在 Kubernetes API 中。當 Secret 更新時，Alertmanager 也會自動更新。請注意，路由僅透過標籤進行（而不是透過註解等）。

2. Prometheus 如何運作​

儲存時間序列資料​

從匯出器收集指標後，Prometheus 將時間序列儲存在本地磁碟時間序列資料庫中。Prometheus 可選地與遠端系統整合，但 rancher-monitoring 使用本地儲存作為時間序列資料庫。

儲存後，使用者可以使用 PromQL（Prometheus 的查詢語言）查詢此 TSDB。

PromQL 查詢可以透過以下兩種方式之一進行視覺化：

  1. 透過在 Prometheus 的 Graph UI 中提供查詢，這將顯示資料的簡單圖形檢視。
  2. 透過建立包含 PromQL 查詢和額外格式指令的 Grafana 儀表板，這些指令標記軸、新增單位、變更顏色、使用替代視覺化等。

為 Prometheus 定義規則​

規則定義了 Prometheus 需要定期以 evaluationInterval 執行的查詢，以執行某些動作，例如觸發警示（警示規則）或基於其 TSDB 中現有的查詢進行預先計算（記錄規則）。這些規則編碼在 PrometheusRules 自訂資源中。當 PrometheusRule 自訂資源建立或更新時，Prometheus Operator 會觀察變更並呼叫 Prometheus API 來同步 Prometheus 當前定期評估的規則集。

PrometheusRule 允許您定義一個或多個 RuleGroups。每個 RuleGroup 由一組 Rule 物件組成，每個物件可以代表警示規則或記錄規則，具有以下欄位：

  • 新警示或記錄的名稱
  • 新警示或記錄的 PromQL 表達式
  • 應該附加到警示或記錄以識別它的標籤（例如叢集名稱或嚴重性）
  • 編碼需要在警示通知上顯示的任何其他重要資訊的註解（例如摘要、描述、訊息、runbook URL 等）。記錄規則不需要此欄位。

在評估規則時，Prometheus 執行提供的 PromQL 查詢，新增提供的標籤，並為規則執行適當的動作。如果規則觸發警示，Prometheus 還會新增提供的註解。例如，將 team: front-end 作為標籤新增到提供的 PromQL 查詢的警示規則將把該標籤附加到觸發的警示，這將允許 Alertmanager 將警示轉發到正確的接收器。

警示和記錄規則​

Prometheus 不維護警示是否處於活動狀態的狀態。它在每個評估間隔重複觸發警示，依賴 Alertmanager 將警示分組和篩選為有意義的通知。

evaluation_interval 常數定義了 Prometheus 針對時間序列資料庫評估其警示規則的頻率。與 scrape_interval 類似，evaluation_interval 也預設為一分鐘。

規則包含在一組規則檔案中。規則檔案包括警示規則和記錄規則，但只有警示規則在評估後會觸發警示。

對於記錄規則，Prometheus 執行查詢，然後將其儲存為時間序列。這個合成時間序列對於儲存昂貴或耗時查詢的結果很有用，以便將來可以更快地查詢它。

警示規則更常用。每當警示規則評估為正數時，Prometheus 就會觸發警示。

規則檔案在觸發警示之前根據使用案例向警示新增標籤和註解：

  • 標籤表示識別警示的資訊，可能會影響警示的路由。例如，當發送關於某個容器的警示時，容器 ID 可以用作標籤。

  • 註解表示不影響警示路由位置的資訊，例如 runbook 或錯誤訊息。

3. Alertmanager 如何運作​

Alertmanager 處理由客戶端應用程式（例如 Prometheus 伺服器）發送的警示。它負責以下任務：

  • 去重、分組和路由警示到正確的接收器整合，例如電子郵件、PagerDuty 或 OpsGenie

  • 靜音和抑制警示

  • 追蹤隨時間觸發的警示

  • 發送警示當前是否正在觸發或已解決的狀態

alertingDrivers 轉發的警示​

當安裝 alertingDrivers 時，這會建立一個 Service，根據 alertingDriver 的配置，可以用作 Teams 或 SMS 的接收器 URL。接收器中的 URL 指向 alertingDrivers；因此 Alertmanager 首先將警示發送到 alertingDriver，然後 alertingDriver 轉發或發送警示到適當的目的地。

路由警示到接收器​

Alertmanager 協調警示發送到哪裡。它允許您根據標籤對警示進行分組，並根據是否匹配某些標籤來觸發它們。一個頂層路由接受所有警示。從那裡，Alertmanager 根據警示是否符合下一個路由的條件繼續將警示路由到接收器。

雖然 Rancher UI 表單只允許編輯兩層深的路由樹，但您可以透過編輯 Alertmanager Secret 來配置更深層巢狀的路由結構。

配置多個接收器​

透過編輯 Rancher UI 中的表單，您可以設定一個接收器資源，其中包含 Alertmanager 向您的通知系統發送警示所需的所有資訊。

透過在 Alertmanager 或接收器配置中編輯自訂 YAML，您還可以將警示發送到多個通知系統。有關更多資訊，請參閱配置接收器的部分。

4. 監控 V2 特定元件​

Prometheus Operator 引入了一組自訂資源定義，允許使用者透過在叢集上建立和修改這些自訂資源來部署和管理 Prometheus 和 Alertmanager 實例。

Prometheus Operator 將根據在 Rancher UI 中編輯的資源和配置選項的即時狀態自動更新您的 Prometheus 配置。

預設部署的資源​

預設情況下，由 kube-prometheus 專案策劃的一組資源會部署到您的叢集上，作為安裝 Rancher 監控應用程式的一部分，以設定基本的監控/警示堆疊。

部署到您的叢集以支援此解決方案的資源可以在 rancher-monitoring Helm chart 中找到，它緊密追蹤由 Prometheus 社群維護的上游 kube-prometheus-stack Helm chart，某些變更在 CHANGELOG.md 中追蹤。

預設匯出器​

監控 V2 部署了三個預設匯出器，為 Prometheus 提供額外的指標儲存：

  1. node-exporter：公開 Linux 主機的硬體和作業系統指標。有關 node-exporter 的更多資訊，請參閱上游文件。

  2. windows-exporter：公開 Windows 主機的硬體和作業系統指標（僅部署在 Windows 叢集上）。有關 windows-exporter 的更多資訊，請參閱上游文件。

  3. kube-state-metrics：公開追蹤 Kubernetes API 中包含的資源狀態的額外指標（例如 pods、工作負載等）。有關 kube-state-metrics 的更多資訊，請參閱上游文件。

ServiceMonitors 和 PodMonitors 將抓取這些匯出器，如此處所定義。Prometheus 儲存這些指標，您可以透過 Prometheus 的 UI 或 Grafana 查詢結果。

有關記錄規則、警示規則和 Alertmanager 的更多資訊，請參閱架構部分。

在 Rancher UI 中公開的元件​

當安裝監控應用程式時，您將能夠在 Rancher UI 中編輯以下元件：

元件元件類型編輯的目的和常見使用案例
ServiceMonitor自訂資源設定要從中抓取自訂指標的 Kubernetes Services。自動更新 Prometheus 自訂資源中的抓取配置。
PodMonitor自訂資源設定要從中抓取自訂指標的 Kubernetes Pods。自動更新 Prometheus 自訂資源中的抓取配置。
Receiver配置區塊（Alertmanager 的一部分）修改關於警示發送位置（例如 Slack、PagerDuty 等）的資訊以及發送警示所需的任何必要資訊（例如 TLS 憑證、代理 URL 等）。自動更新 Alertmanager 自訂資源。
Route配置區塊（Alertmanager 的一部分）修改用於根據標籤篩選、標記和分組警示並將其發送到適當接收器的路由樹。自動更新 Alertmanager 自訂資源。
PrometheusRule自訂資源定義需要觸發警示或定義 Prometheus TSDB 中現有序列的物化檢視的額外查詢。自動更新 Prometheus 自訂資源。

PushProx​

PushProx 允許 Prometheus 跨網路邊界抓取指標，這使使用者不必為 Kubernetes 叢集中每個節點上的內部 Kubernetes 元件公開指標埠。

由於 Kubernetes 元件的指標通常在叢集中節點的主機網路上公開，PushProx 部署了一個客戶端的 DaemonSet，它們位於每個節點的 hostNetwork 上，並與位於 Kubernetes API 上的單一代理建立出站連接。然後可以配置 Prometheus 透過代理將抓取請求代理到每個客戶端，這允許它從內部 Kubernetes 元件抓取指標，而不需要開啟任何入站節點埠。

有關更多資訊，請參閱使用 PushProx 抓取指標。

5. 抓取和公開指標​

定義要抓取的指標​

ServiceMonitors 和 PodMonitors 定義了 Prometheus 預期要抓取的目標。Prometheus 自訂資源告訴 Prometheus 應該使用哪些 ServiceMonitors 或 PodMonitors 來找出從何處抓取指標。

Prometheus Operator 觀察 ServiceMonitors 和 PodMonitors。當它觀察到它們被建立或更新時，它會呼叫 Prometheus API 來更新 Prometheus 自訂資源中的抓取配置，並使其與 ServiceMonitors 或 PodMonitors 中的抓取配置保持同步。此抓取配置告訴 Prometheus 要從哪些端點抓取指標，以及如何標記來自這些端點的指標。

Prometheus 會在每個 scrape_interval 抓取其抓取配置中定義的所有指標，預設為一分鐘。

抓取配置可以作為 Rancher UI 中公開的 Prometheus 自訂資源的一部分查看。

Prometheus Operator 如何設定指標抓取​

Prometheus Deployment 或 StatefulSet 抓取指標，而 Prometheus 的配置由 Prometheus 自訂資源控制。Prometheus Operator 監視 Prometheus 和 Alertmanager 資源，當它們被建立時，Prometheus Operator 會使用使用者定義的配置為 Prometheus 或 Alertmanager 建立 Deployment 或 StatefulSet。

當 Prometheus Operator 觀察到 ServiceMonitors、PodMonitors 和 PrometheusRules 被建立時，它知道需要在 Prometheus 中更新抓取配置。它透過首先更新 Prometheus 的 Deployment 或 StatefulSet 的 volumes 中的配置和規則檔案來更新 Prometheus。然後它呼叫 Prometheus API 來同步新配置，導致 Prometheus Deployment 或 StatefulSet 被就地修改。

Kubernetes 元件指標如何公開​

Prometheus 從稱為匯出器的部署中抓取指標，這些匯出器以 Prometheus 可以擷取的格式匯出時間序列資料。在 Prometheus 中，時間序列由屬於相同指標和相同標記維度集的帶時間戳記的值流組成。

使用 PushProx 抓取指標​

某些內部 Kubernetes 元件透過作為監控 V2 的一部分部署的代理 PushProx 進行抓取。有關 PushProx 的詳細資訊，請參閱這裡和上面的架構部分。

抓取指標​

以下 Kubernetes 元件由 Prometheus 直接抓取：

  • kubelet*
  • ingress-nginx**
  • coreDns/kubeDns
  • kube-api-server

* 您可以選擇使用 hardenedKubelet.enabled 來使用 PushProx，但這不是預設值。

** 對於 RKE2 叢集，ingress-nginx 預設部署並被視為內部 Kubernetes 元件。

基於 Kubernetes 發行版的指標抓取​

指標的抓取方式因 Kubernetes 發行版而異。有關術語的說明，請參閱這裡。詳細資訊請參閱下表：

指標如何公開給 Prometheus

| Kubernetes 元件 | RKE2 | KubeADM | K3s | |-----|-----|-----|-----|-----| | kube-controller-manager | rke2ControllerManager.enabled | kubeAdmControllerManager.enabled | k3sServer.enabled | | kube-scheduler | rke2Scheduler.enabled |kubeAdmScheduler.enabled | k3sServer.enabled | | etcd | rke2Etcd.enabled | kubeAdmEtcd.enabled | 不可用 | | kube-proxy | rke2Proxy.enabled | kubeAdmProxy.enabled | k3sServer.enabled | | kubelet | 收集 kubelet 直接公開的指標 | 收集 kubelet 直接公開的指標 | 收集 kubelet 直接公開的指標 | | ingress-nginx* | 收集 kubelet 直接公開的指標，由 rke2IngressNginx.enabled 公開 | 不可用 | 不可用 | | coreDns/kubeDns | 收集 coreDns/kubeDns 直接公開的指標 | 收集 coreDns/kubeDns 直接公開的指標 | 收集 coreDns/kubeDns 直接公開的指標 | | kube-api-server | 收集 kube-api-server 直接公開的指標 | 收集 kube-appi-server 直接公開的指標 | 收集 kube-api-server 直接公開的指標 |

* 對於 RKE2 叢集，ingress-nginx 預設部署並被視為內部 Kubernetes 元件。

術語​

  • kube-scheduler： 內部 Kubernetes 元件，使用 pod 規格中的資訊來決定在哪個節點上執行 pod。
  • kube-controller-manager： 內部 Kubernetes 元件，負責節點管理（偵測節點是否失敗）、pod 複製和端點建立。
  • etcd： 內部 Kubernetes 元件，是分散式鍵/值儲存，Kubernetes 用於永久儲存所有叢集資訊。
  • kube-proxy： 內部 Kubernetes 元件，監視 API 伺服器以偵測 pods/services 的變更，以保持網路最新狀態。
  • kubelet： 內部 Kubernetes 元件，監視 API 伺服器以了解節點上的 pods，並確保它們正在執行。
  • ingress-nginx： Kubernetes 的 Ingress 控制器，使用 NGINX 作為反向代理和負載平衡器。
  • coreDns/kubeDns： 負責 DNS 的內部 Kubernetes 元件。
  • kube-api-server： 主要的內部 Kubernetes 元件，負責為其他主控元件公開 API。