Keep a Prometheus rule group's cluster scope aligned with its scraped label

Source facts

Managed Prometheus rules inherit their evaluation scope from a rule group; individual rules cannot be attached directly to a Kubernetes cluster. A cluster-limited group’s scopes must still include its Azure Monitor workspace. The clusterName value must match the cluster label on scraped metrics. Microsoft Learn.

If collection changes that label through cluster_alias, the group needs the updated clusterName. The property is optional with the default label. Without either a cluster-ID scope or clusterName, the group’s rules query every cluster in the workspace. Microsoft Learn.

Applicability

Use this check for Azure Monitor managed Prometheus rule groups scoped to Kubernetes clusters. Identify the workspace, intended cluster and collection configuration as separate review inputs. Do not infer the label solely from a cluster’s display name.

DSE recommendation

DSE recommends pairing each rule group’s intended scope with a sample of the actual scraped cluster label. Include an alias change in the rule-owner’s change review, even when the cluster resource itself stays the same. Require an explicit decision before changing a group from cluster-specific to workspace-wide evaluation. Keep recording and alerting rules under the same scope review.

Verification

Inspect the deployed scopes and clusterName, then run the relevant expression against known metrics from the intended cluster. Compare a second cluster to check the exclusion boundary. Preserve the query, observed labels and resulting rule behavior. Investigate missing results or unexpected cross-cluster results before treating the group as correctly targeted.

Official references

Microsoft Learn: Managed Prometheus rule groups.