Running outside of Google Cloud

If your cluster is not running inside Google Cloud, you must manuallyconfigure values for theproject_id andlocation labels. We recommendthe following:

• Setproject_id based on how this cluster fits in your multi-tenantmonitoring model. Your service account must be configured with thecorrect permissions for your chosenproject_id.

• Setlocation based on the closest Google Cloud region to yourdeployment.

You can't rewrite these labels using a relabeling rule.

Having more than 3,500 projects in your organization

The maximum supported number of projects in a metrics scope is375, but the maximum unsupported numberof projects in a metrics scope is 3,500.

If you have more than 3,500 projects,the recommended workaround is to configure your collectors to use a centralproject_id instead of the ID of the project they are running in. Metricsfrom all your projects are then stored in Monarch under thatcentral project ID, and you can simply put the central project into ametrics scope.

If you use this approach, then be aware of the following potential drawbacks:

• You lose some multi-tenancy granularity by doing this, as permissionscan only be set at a per-project level. You might want to logicallygroup projects into a few categories and use a different central projectfor each.
• Theproject_id value of Google Cloud system metrics cannot beoverridden. This workaround will not let you seefree Google Kubernetes Engine metricsin the central project, as those metrics stay within each originating project.
• Using a central project might complicate your use of Rules and ClusterRules,because those rules are scoped to the project in which they are installed,and you are unlikely to have the same set of cluster and namespace names ineach project. You might have to use GlobalRules instead.

Manually locating data in a single Google Cloud region

By default, Managed Service for Prometheus stores data in theGoogle Cloud region from which the data originates, and queries arenaturally global, meaning you do not have to geographically co-locate datain order to query data across multiple Google Cloud regions.

In most situations, this default behavior is sufficient. However, theremight be some situations where you want to store all metric data in asingle Google Cloud region, for example, if you are in ahighly-regulated environment.

To store all metric data in a single region, configure your collectors to use a singlelocation instead of the auto-detected location of the cluster theyare running in.

Storing data in a single Google Cloud region might complicate youruse of Rules and ClusterRules, as those are scoped to the location in whichthey are installed, and you are unlikely to have the same set of cluster andnamespace names in each Google Cloud region. You might have to useGlobalRules instead.