本文档介绍了 Managed Service for Prometheus 部署中使用自行部署的收集的规则和提醒评估的配置。
下图展示了使用两个 Google Cloud 项目中的多个集群并使用规则和提醒评估的部署：
如需设置和使用图中所示的部署，请注意以下事项：
规则安装在每个 Managed Service for Prometheus 收集服务器中，就像使用标准 Prometheus 时一样。规则评估针对本地存储在每个服务器上的数据执行。服务器配置为将数据保留足够长的时间，以涵盖所有规则的回溯期（通常不超过 1 小时）。评估后，规则结果会写入 Monarch。
在每个集群中手动部署 Prometheus AlertManager 实例。Prometheus 服务器通过修改配置文件的
alertmanager_config字段进行配置，以将触发的提醒规则发送到其本地 AlertManager 实例。抑制、确认和突发事件管理工作流通常在 PagerDuty 等第三方工具中进行处理。您可以使用 Kubernetes Endpoints 资源将多个集群的提醒管理集中到单个 AlertManager 中。
在 Google Cloud 中运行的单个集群被指定为指标范围的全局规则评估集群。独立规则评估器部署在该集群中，并且系统使用标准 Prometheus 规则文件格式安装规则。
独立规则评估器配置为使用 scoping_project_A，其中包含项目 1 和 2。针对 scoping_project_A 执行的规则会自动扇出到项目 1 和项目 2。底层服务帐号必须获得 scoping_project_A 的 Monitoring Viewer 权限。
规则评估器配置为使用配置文件的
alertmanager_config字段向本地 Prometheus Alertmanager 发送提醒。
使用自部署的全局规则评估器可能会产生意外影响，具体取决于您是保留还是聚合规则中的 project_id、location、cluster 和 namespace 标签：
如果您的规则保留
project_id标签（使用by(project_id)子句），则规则结果将使用底层时序的原始project_id值写回到 Monarch。在这种情况下，您需要确保底层服务帐号具有 scoping_project_A 中每个受监控项目的 Monitoring Metric Writer 权限。如果您向 scoping_project_A 添加新的受监控项目，则还必须向该服务帐号手动添加新的权限。
如果您的规则不保留
project_id标签（不使用by(project_id)子句），则系统会使用正在运行全局规则评估器的集群的project_id值将规则结果写回到 Monarch。在这种情况下，您无需进一步修改底层服务帐号。
如果您的规则保留
location标签（使用by(location)子句），则系统会使用生成底层时序的每个原始 Google Cloud 区域将规则结果写回到 Monmon。如果您的规则不保留
location标签，则数据会写回到正在运行全局规则评估器的集群所在的位置。
我们强烈建议您尽可能保留规则评估结果中的 cluster 和 namespace 标签。否则，查询性能可能会降低，并且您可能会遇到基数限制。强烈建议不要移除这两个标签。