使用代管式集合和自部署集合进行注入和查询

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

本文档介绍如何设置环境,用于将自部署的收集器与代管式收集器跨不同的 Cloud 项目和集群进行混合。

我们强烈建议您对所有 Kubernetes 环境使用代管式收集;这样做实际上可以消除在集群内运行 Prometheus 收集器的开销。您可以在同一集群内运行代管式收集器和自行部署的收集器。我们建议使用一致的方法进行监控,但您可以选择对某些特定用例(例如托管推送网关)混合使用部署方法,如本文档中所示。

下图展示了使用两个 Cloud 项目、三个集群以及混合代管式自部署集合的配置。如果您仅使用代管式或自部署集合,则该图仍然适用;只需忽略您未使用的集合样式即可:

您可以为 Prometheus 设置代管式服务,并混合使用代管式集合和自部署集合。

如需设置和使用图中所示的配置,请注意以下事项:

  • 您必须在集群中安装任何必要的导出器。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 还有一个运行 GrafanaPrometheus 前端代理的集群。在此示例中,这些组件托管在独立集群中,但实际上可以托管在任何一个集群中。

    Prometheus 前端代理配置为使用 scoping_project_A,其底层服务帐号具有 scoping_project_A 的 Monitoring Viewer 权限。

    当用户从 Grafana 发出查询时,Monarch 会将 scoping_project_A 扩展到其组成部分的受监控项目,并返回所有 Google Cloud 区域中项目 1 和项目 2 的结果。所有指标都保留其原始 project_idlocation(Google Cloud 区域)标签,以便进行分组和过滤。

如果您的集群未在 Google Cloud 中运行,您必须手动配置 project_idlocation 标签。如需了解如何设置这些值,请参阅在 Google Cloud 外部运行 Managed Service for Prometheus

使用 Managed Service for Prometheus 时,请勿联合。如需通过在将数据发送到 Monarch 之前“汇总”数据来降低基数和费用,请改用本地聚合。如需了解详情,请参阅配置局部聚合