使用管理和自行部署的集合進行擷取和查詢

本文說明如何在不同Google Cloud 專案和叢集中，設定同時包含自行部署收集器和受管理收集器的環境。

我們強烈建議您為所有 Kubernetes 環境使用受管理的收集作業，這樣一來，您就不必在叢集中執行 Prometheus 收集器，避免不必要的開銷。您可以在同一個叢集內執行代管和自行部署的收集器。我們建議您使用一致的監控方法，但您可以選擇為某些特定用途 (例如代管推播閘道) 混合使用部署方法，如本文所述。

下圖說明使用兩個Google Cloud 專案、三個叢集，以及混合受管理和自行部署的收集的設定。如果您只使用受管理或自行部署的集合，則此圖表仍適用；只要忽略您未使用的集合樣式即可：

如要設定及使用圖表中的設定，請注意下列事項：

• 您必須在叢集中安裝所有必要的匯出工具。Google Cloud Managed Service for Prometheus 不會代您安裝任何匯出工具。

• 專案 1 有一個叢集，執行代管集合，以節點代理程式執行。收集器會使用 PodMonitoring 資源來擷取命名空間中的目標，並使用 ClusterPodMonitoring 資源擷取叢集中的目標。您必須在要收集指標的每個命名空間中套用 PodMonitoring。每個叢集會套用一次 ClusterPodMonitoring。

  在專案 1 中收集的所有資料都會儲存在 Monarch 的專案 1 下。根據預設，這類資料會儲存在發出資料的 Google Cloud 區域。

• 專案 2 的叢集會使用 prometheus-operator 執行自行部署的收集，並以獨立服務的形式執行。這個叢集已設定為使用 prometheus-operator PodMonitor 或 ServiceMonitor，以便在 Pod 或 VM 上抓取匯出器。

  專案 2 也代管推送閘道 sidecar，用於從暫時性工作負載收集指標。

  在專案 2 中收集的所有資料都會儲存在 Monarch 的專案 2 下。根據預設，這類資料會儲存在資料發出來源的 Google Cloud 區域。

• 專案 1 也包含一個叢集，其中執行 Grafana 和資料來源同步器。在這個範例中，這些元件會在獨立叢集中代管，但也可以在任何單一叢集中代管。

  資料來源同步器已設為使用 scoping_project_A，且其基礎服務帳戶具有 scoping_project_A 的「Monitoring Viewer」權限。

  當使用者透過 Grafana 發出查詢時，Monarch 會將 scoping_project_A 擴充為其監控的組成專案，並在所有 Google Cloud 地區傳回 Project 1 和 Project 2 的結果。所有指標都會保留原始的 project_id 和 location (Google Cloud region) 標籤，以便進行分組和篩選。

如果叢集未在 Google Cloud中執行，您必須手動設定 project_id 和 location 標籤。如要瞭解如何設定這些值，請參閱「在Google Cloud外執行 Managed Service for Prometheus」。

使用 Managed Service for Prometheus 時，請勿進行聯合。如要透過「匯總」資料，在傳送至 Monarch 之前減少基數和成本，請改用本機匯總。詳情請參閱「設定本機匯總」。