CMDB Health Inclusion Rule Best Practices

Larry Youngqui2
Tera Contributor

I am in the process of developing the CMDB Dashboard with the associated health rules.   The first iteration will be aimed at the Asset Management set of 'Managed Classes'.   Those CMDB classes that they actively manage and are responsible for.

Our CMDB contains a lot of what we consider "non-managed" classes, such as the Next Hop Routing records and other CI classes.   We have chosen to keep those in the CMDB but wish to exclude them from the CMDB dashboard.   And as we upgrade to Kingston, we want to take advantage of the Health Inclusion rule introduced in Jakarta.

But before beginning a large effort at configuring the rules, I'd like to ask for any best practices or advice that we should be aware of.  The documentation (Create identification inclusion rule) is clear on how to provision the necessary filters, but I want to ensure we're doing it in the most efficient manner.   And importantly, in a manner that is manageable and understandable by both myself and our Managed Class Owners.  Because the Asset Management set of Managed Classes is somewhat lengthy and messy, I'm starting with their set of classes first.  As I create the filters, I don't want to create such a fragile filter that it requires constant tweaking and fiddling.   I also want to avoid the question from my Managed Class Owners, as to "why" or "why not" any particular class is included or not.    They should have a clear understanding of what CIs they own and manage.  And if they need to adjust, they need to clearly provide the detail needed for the filter

At the top of the hierarchy, the cmdb_ci table, I plan on excluding the majority of classes that we just don't want incorporated in the scorecard calculations.   Especially, the classes that have large numbers of records, such as the aforementioned Next Hop Routing Rule.    The active record filter is a simple "Class != <class>" and so forth.    Basically, the global exclusion rule.

Under each specific managed class, I would include an inclusion of which specific records to include.  That is, "Active = True", or "Status = [Installed | Available | Deployed | etc.]" or "Managed by != NULL", etc.   Whatever the Managed Class Owner considers as an active CI record that needs to be managed.

Is this a feasible strategy to follow for building the set of CMDB CI records contained in our dashboard?   Are there other methods that have been used and tested?     Is there performance concerns that need to be considered when running the dashboard scripts?

Thanks in advance,

Larry

17 REPLIES 17

Larry Youngqui2
Tera Contributor

Todd,

That's a very good tip about using the Staleness Effective Duration time.     We've also run into the Health Inclusion Rule not being respected by certain classes.     I've also had an issue with the duplicate health result.    We are trying to exclude the Router Interface class from being detected as possible dupes.   We have them excluded via the Health Inclusion, but am having issues getting the "Identification Inclusion Rule (Advanced)" to accept a filter for duplicates.   When I try to "save", the window just goes away.

The result is that we have ~11,000 duplicate records detected with zero total records.   Makes for an odd calculation with a zero denominator.

We have a HI ticket opened, but no answer back on a solution.

find_real_file.png

victorl
Kilo Explorer

Hi everyone,

 

We are also working on CMDB Health. For the service layer we have already implemented it to some extent. But for the component layer we have some issues.

First we need staleness, but the issue we have for the component layer is that it uses the Updated field and not Most Recent Discovery to determine if a component is stale or not (I think they used Most Recent Discovery in earlier versions). This means that a component updated from any source will be considered as not stale even if we have not discovered it for a long time. As an example the updated field on the CI will be updated if our asset state is changed.

- Some component classes does does not even update the updated field if a component already has been discovered previously.
- Some components does not have a Most Recent Discovery etc.

So in short, from our perspective there is a lot lacking in CMDB health. To be able to set what field should be used to evaluate if a component is stale would be great.

 

I got something wrong here, please tell me 🙂

Regards,

Victor

I don't have any additional thoughts for you.  We are not that far a long.

I do agree the overall solution has room for improvement.  Hopefully, ServiceNow has it in their roadmap.

big-m0dem
Tera Expert

How is everyone handling "Next Hop Routing Rule" duplicates? We want to keep the data, but just not report on it. It seems you can't do a Health Inclusion Rule for duplicates. Are you using Identification > Inclusion Rule (Advanced)? If so, wouldn't that prevent the discovery, i.e., writing to the cmdb for that CI?

Hi! This was (and kinda still is) a pain point for us. I created an automated remediation workflow which deletes the older duplicates and only keeps the latest, however it needs some fine-tuning. I can find the information for how to do this on Monday if that would help?