本文档介绍如何设置环境以跨不同的 Google Cloud 项目和集群混合使用自部署的收集器与代管式收集器。
我们强烈建议您对所有 Kubernetes 环境使用代管式收集；这样做实际上可以消除在集群内运行 Prometheus 收集器的开销。您可以在同一集群内运行代管式收集器和自行部署的收集器。我们建议使用一致的方法进行监控，但您可以选择对某些特定用例（例如托管推送网关）混合使用部署方法，如本文档中所示。
下图展示了使用两个 Google Cloud 项目、三个集群以及混合代管式和自部署集合的配置。如果您仅使用代管式或自部署集合，则该图仍然适用；只需忽略您未使用的集合样式即可：
如需设置和使用图中所示的配置，请注意以下事项：
您必须在集群中安装任何必要的导出器。Google Cloud Managed Service for Prometheus 不会代表您安装任何导出器。
项目 1 有一个运行代管式收集的集群，该集群作为节点代理运行。收集器配置了 PodMonitoring 资源（用于爬取命名空间中的目标）和 ClusterPodMonitoring 资源（用于爬取集群中的目标）。PodMonitoring 必须应用于您要在其中收集指标的每个命名空间。每个集群会应用 ClusterPodMonitoring 一次。
项目 1 中收集的所有数据都保存在项目 1 下的 Monarch 中。此数据默认存储在发出它的 Google Cloud 区域中。
项目 2 有一个使用 prometheus-operator 运行自行部署的收集并作为独立服务运行的集群。此集群配置为使用 prometheus-operator PodMonitor 或 ServiceMonitor 来爬取 pod 或虚拟机上的导出器。
项目 2 还托管了一个推送网关 Sidecar，以从临时工作负载中收集指标。
项目 2 中收集的所有数据都保存在项目 2 下的 Monarch 中。此数据默认存储在发出它的 Google Cloud 区域中。
项目 1 还有一个运行 Grafana 和数据源同步器的集群。在此示例中，这些组件托管在独立集群中，但实际上可以托管在任何一个集群中。
数据源同步器配置为使用 scoping_project_A，并且其底层服务账号具有 scoping_project_A 的 Monitoring Viewer 权限。
当用户从 Grafana 发出查询时，Monarch 会将 scoping_project_A 扩展到其组成部分的受监控项目，并返回所有 Google Cloud 区域中项目 1 和项目 2 的结果。所有指标都保留其原始
project_id和location（Google Cloud 区域）标签，以便进行分组和过滤。
如果您的集群未在 Google Cloud 中运行，您必须手动配置 project_id 和 location 标签。如需了解如何设置这些值，请参阅在 Google Cloud 外部运行 Managed Service for Prometheus。
使用 Managed Service for Prometheus 时，请勿联合。如需通过在将数据发送到 Monarch 之前“汇总”数据来降低基数和费用，请改用本地聚合。如需了解详情，请参阅配置局部聚合。