Triggering an alert management rule when the affected CI is part of a specific group

JussiV
Tera Guru

I am trying to trigger an alert management rule when the CI bound to the alert is part of a specific group of CIs which for the moment is maintained as a CMDB group. This CMDB group is related to other functionality elsewhere so I have to work with it if possible. After rummaging around, I think I have figured out the correct way of doing this but to my surprise the results are not what I expect. Am I doing this wrong, did I misunderstand something, is there a different way of achieving the same outcome? Below is what I have attempted with poor results.

I have the CMDB group populated with demo CIs:

JussiV_0-1665034072220.png

The group definition works without a hitch, it gets populated as expected:

JussiV_1-1665034143137.png

Looking at the alert management rule filter options, it seems like the connection between the alert CI and the group of CIs goes through multiple hops and involves creating a dynamic CI group, so I did.

JussiV_2-1665035056310.png

The last step was to create an alert management rule with a filter that checks whether the alert CI is part of the CMDB group or the dynamic CI group. As the condition builder doesn't let me stop at the dynamic CI group level and check if that is "IBM machines", I'm going deeper and checking for the CMDB group name "Test group 1 - All CIs ending with IBM":

JussiV_3-1665035740794.png

This all looks correct on the surface but the rule doesn't trigger and with the filter preview it returns zero results even though I've fired multiple test events at the system, the alert is bound to the correct CI and the CI is from the CMDB group I want to target.

Here's what I've checked/attempted so far, with very thin results:

  • Event management documentation doesn't cover this specific scenario in the product documentation.
  • I have a vague memory that the event management fundamentals course did brush against the CI groups. Unfortunately the course material is no longer available to me so I can't check if this specific use case was covered.
  • Tried changing the event node to see if I should have something else there
    • Node as the dynamic CI group "IBM machines" -> "No CI found for binding (Failed to resolve the event node to CI id)"
    • Node as the CMDB group "Test group 1 - All CIs ending with IBM" -> "No CI found for binding (Failed to resolve the event node to CI id)"
  • Tried changing the rule activation condition just to make sure I didn't make a mistake there
  • Tried changing the filter condition for the CI and hammered the Preview button to see if I'm targeting the wrong level
    • Configuration item > Dynamic CI Group > CMDB Group > Group Name = "Test group 1 - All CIs ending with IBM" yields 0 matching alerts.
    • Configuration item > Dynamic CI Group > CMDB Group > Group Name = "IBM machines" yields 0 matching alerts.
    • Configuration item = "*ANNIE-IBM" yields results, obviously, but these are not the droids I am looking for.
  • Used an out-of-the-box remediation subflow just to make sure there's no issues with the flow. Also made the execution settings more permissible for the testing.
    JussiV_4-1665037213382.png
  • Looking at the encoded query the filter preview gives me, it makes this query:
    maintenance=false^incidentISEMPTY^cmdb_ci.ref_cmdb_ci_query_based_service.cmdb_group.group_name=Test group 1 - All CIs ending with IBM

    This seems to be a valid query and I can generate similar queries with the condition builder elsewhere that return valid results. It just doesn't return any results.

I have a workaround for this in mind, to create a dynamic filter option that returns the CIs form the groups, but because this is for a MSP with domain separated instance it is not a good one. I will either have to name the filter in an anonymized way to prevent leaking the MSP's customer's name to their other customers, or go into very detailed ACLs to prevent showing the filter option to the rest of their customers. Even the anonymized dynamic filter might leak data across the domains, I haven't checked it fully, so I'm trying to avoid opting for the workaround if at all possible.

So, with all that said, am I doing something silly or is the rule filter not working as it should?

1 ACCEPTED SOLUTION

JussiV
Tera Guru

Turns out I had misunderstood the query and what it actually does is to check that the bound CI is of the Dynamic CI Group class and its related CMDB group's name is the given name.

There is no way to achieve this without scripting so the solution is use a scripted filter. Create/amend a script include with a function that returns a comma-separated list of sys_ids of the desired CIs. Within the script include you can then use the CMDBGroupAPI to pull all the CIs contained within a given CMDB group.

Here's proof of concept background script

 

 

var grpName = 'CMDB group name';
var grp = new GlideRecord('cmdb_group');
if (grp.get('group_name', grpName)) {
    gs.print(grp.getDisplayValue());
    var grpList = JSON.parse(sn_cmdbgroup.CMDBGroupAPI.getAllCI(grp.getUniqueValue())).idList.join(',');
    gs.print(grpList);
}

 

Once you have a working script include, you can then use it in the rule condition builder with Configuration Item [contains] javascript:MyScriptInclude.getCMDBGroupCIs('...')

 

View solution in original post

9 REPLIES 9

JussiV
Tera Guru

I ended up opening a support case for this and the support team can reproduce the issue, so this is not just me doing something silly. Will update this thread when I have something concrete from the support.

robertgiron
Tera Contributor

We are trying to accomplish the same challenge.  Were you able to get anything back from support ? 

Thanks for a reminder to update this post, I've posted a solution and this is to make sure you get notified of it 🙂

JussiV
Tera Guru

Turns out I had misunderstood the query and what it actually does is to check that the bound CI is of the Dynamic CI Group class and its related CMDB group's name is the given name.

There is no way to achieve this without scripting so the solution is use a scripted filter. Create/amend a script include with a function that returns a comma-separated list of sys_ids of the desired CIs. Within the script include you can then use the CMDBGroupAPI to pull all the CIs contained within a given CMDB group.

Here's proof of concept background script

 

 

var grpName = 'CMDB group name';
var grp = new GlideRecord('cmdb_group');
if (grp.get('group_name', grpName)) {
    gs.print(grp.getDisplayValue());
    var grpList = JSON.parse(sn_cmdbgroup.CMDBGroupAPI.getAllCI(grp.getUniqueValue())).idList.join(',');
    gs.print(grpList);
}

 

Once you have a working script include, you can then use it in the rule condition builder with Configuration Item [contains] javascript:MyScriptInclude.getCMDBGroupCIs('...')

 

Thank you @JussiV   Very Helpful!