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

JussiV · ‎10-06-2022

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:

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

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.

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":

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.
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?

JussiV · ‎01-13-2023

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&colon;MyScriptInclude.getCMDBGroupCIs('...')

View solution in original post

Rahul Priyadars · ‎10-06-2022

Keep first two conditions and just do a hard coding for CI value which suits your need . See what happens?\

Regards

RP

JussiV · ‎10-06-2022

Of course it works, but then misses the point. The point is that the CMDB groups have some tens of CIs and they're maintained already in one place by the customer team, duplicating that maintenance work and pushing it to the admin side is not really an option.

Rahul Priyadars · ‎10-06-2022

Do you have Attribute which identifies IBM Computer System CIs as per screenshot?

My post was to just test with with a happy and hardcoded use case- Good that its working that way.

Regards

RP

JussiV · ‎10-07-2022

No, no attribute, the CMDB group is populated based on a query that just takes CIs where the names ends with "-IBM". This is a PoC on demo data so the mechanism on how the CMDB group is populated shouldn't matter but I trust you'll let me know if it does.