Distinguish an alert's query target from its affected configuration items

Source facts

In Azure Monitor’s common schema, alertTargetIDs identifies the alert’s ARM targets. For a log-search alert defined on a workspace or Application Insights resource, that target is the workspace or application. configurationItems can instead identify the resources that supplied the data. Microsoft documents its use for configuration-database correlation. Microsoft Learn.

For Scheduled Query Rules API version 2021-08-01, configuration items come from explicitly declared dimensions, with priority _ResourceId, ResourceId, Resource, then Computer. Earlier versions derive them implicitly from results. The separate alertRuleId property is not present in every alert type or API version. Microsoft Learn.

Applicability

Use this distinction for integrations consuming Azure Monitor common-schema log-search alerts. Record the generating rule and API version before deciding what a particular field means in the integration.

DSE recommendation

DSE recommends preserving both target and configuration-item fields in the incoming record. Define an explicit mapping for asset ownership instead of assigning every workspace-scoped alert to the workspace itself. Treat an absent identifier as an exception for review, not permission to invent an affected asset. Keep correlation failures visible to the integration owner.

Verification

Inspect sanitized payloads from a known resource and compare their fields with the rule’s dimensions and expected asset. Include a missing-field case in the parser test. Confirm that the resulting ticket retains the original alert identity and correctly separates the query scope from the investigated resource.

Official references

Microsoft Learn: Common alert schema.