Within Alert Automation Enrich Rules can you see the query used for test ci identification?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday
I am having trouble with Azure Monitor alerts binding to CIs. The OOTB rule will catch many but some don't bind because the Service Graph Connector doesn't bring in the objects that the alerts are triggered against. So the object_ID isn't found. In these cases I am trying to create a secondary rule that will bind to the Resource Group as fall back. This however isn't working so far. Is there a way to see the query run in the Alert Enrichment rules when using the test ci identification button?
- Labels:
-
Event Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday - last edited Monday
Hello Buddy!
No, there isn’t a way to see the exact query that runs when you click Test CI Identification. That button is basically a black box — it doesn’t expose the GlideRecord query or log it anywhere in a readable way.
That said, you can still troubleshoot what’s going on.
What you’re seeing is normal with Azure Monitor + Service Graph. If the connector hasn’t brought in the specific Azure object the alert is raised against, the OOTB rule can’t find a match, and the alert stays unbound. Using a fallback rule to Resource Group is a reasonable idea, but it’s very sensitive to data and rule setup.
A few things I think will help:
Check the alert record itself and confirm the Resource Group field is actually populated. If it’s empty or formatted differently than what’s in CMDB, the rule will never match.
Turn on Event Management debug logging and reprocess an alert. You won’t see the full query, but you will see which enrichment rules ran and whether the CI lookup returned anything.
Manually validate the CMDB side by filtering the target CI table using the same value your rule is trying to match (resource group name, subscription ID. Small formatting or case differences often cause silent failures.
Make sure your fallback rule runs after the OOTB Azure rule and only triggers when no CI has been identified yet. Rule order matters a lot here.
So unfortunately, there’s really no way to view the query directly, but between alert inspection, debug logs, and manual CMDB validation, you can usually narrow down why the fallback rule isn’t binding.
@StephenM - Please mark Solution Accepted and Thumbs Up if you found Helpful!
