CMDB Health Inclusion Rule Best Practices

[Larry Youngqui2]

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

[Todd_Goodhew]

Larry,

I'm starting the same journey and wondered what you ended up doing since you posted this 7 months ago?

Did your approach of an exclusion at the CMDB CI level and inclusion rules at targeted lower CI levels work?  If so, what was the filter criteria you used at the CMDB CI level?

Todd

[Hemashekar]

I am on the same journey right now to build good CMDB using CMDB health dashboard to identify the CI data issues and resolve them.

Documentation just mentions to add the inclusion rule and I kind of think that inclusion to be added for every CI class and so forth.

This seems to be lot manual work and i do not know if this way it should be done. However, service-now experts say that this is good way to start and use the feature,  but doesn't seem as easy as said in all service now Sales workshop.

Please share some good insight and methods or configuration helped to achieved.

[Todd_Goodhew]

As usual, ServiceNow documentation doesn't cover everything and it does't always do it in the order we need it.

That being said, after reading the doco several times and doing some trial and error, here is what I figured out.

NOTES: 

1. I did this all on Kingston Patch 10.  YMMV if on a different version, especially Istanbul or earlier.

2. We are phasing in health.  Our primary focus is on stale CIs.  Eventually we'll focus on the other areas.

Lessons Learned

1. By default all CI classes are included in the health metrics.  So this turns into an opt-out scenario when we 1) want to turn on health in phases for classes, don't care about the health for certain classes, etc.

2. I found a bug in the Inclusion rules for a few classes.  Those VMWare classes ignored the rule. Turns out this is a know problem and was fixed in Patch 10 for Kingston.  However, I'm running that and it didn't fix the issue.  I solved it a different way...read on.

3. All the rules (Inclusion, Staleness, etc) are inherited from the top class.  so setting an Inclusion Rule on Configuration Item (cmdb_ci) class means that all the child classes will use this rule.  Cool.  If you want a child class to not use this rule, then give that child class its own rule...just remember if it has kids, then it they will get the new rule...so you'll have to handle those kids separately again.

4.  I struggled with an Inclusion Rule to limit the specific classes we wanted to use.  While we can select "Class" we to list out each class we want to include.  This gets cumbersome if you have more than say 10 classes you want to include.  Add in the fact that about 4 or 5 VMWare classes just flat out ignore the inclusion rule (I was trying to exclude them, they weren't having it).

   In this case, I just used a Staleness rule where Effective Duration = 10000 days at the Configuration Item level, then adjusted the rule on the specific child classes we want to include (they all had different Effective Duration anyways).

5. When viewing the list of records in the CMDB Health Results table (via click on one of the graphs on the dashboard), you'll notice a Source field.  It will have one of two values:  Cmdb Health Audit or Cloud Discovery.  

     Cmdb Health Audit = this health result record was created as a direct result of the health audit.  Cool, just what we want.

     Cloud Discovery = but we don't use Cloud Discovery.  Oh but you do if you have VMWare and use Discovery to talk  to the ESX server.  Turns out Discovery will use the ESX server as the source of truth.  If the ESX server doesn't have the VM anymore, then Discovery will auto make an entry in the CMDB Health Results table.  Same has if you use Cloud Discovery to talk to Azure, AWS, etc.

6. A CI can have more than one "issue" with its health and thus have more than one entry in the CMDB Health Results table.  This is OK and good.

7. Tasks for health results records.  Tasks for the most part are turned off by default.  They are controlled in the Health Preferences module.  However, we have limited control.  Out of the box we can't say for CI class "A", create a task and assign it to Group A, but for CI Class "B", assign it to Group B.  We can only assign ALL the tasks to a single group.  We also cannot say, only create tasks for these CIs, but not for these CIs...like if we wanted to phase this in for classes.

   For the Assignment Group issue, I think this can be overcome in the workflow that gets associated to the Remediation Rule since we can filter there.  The workflow would just update the Assignment Group for the task to the appropriate group.

  For the limit which class actually gets a task created.  Not much we can do here.  We can focus only on a single class at a time all the way through, then go to the next class.  Or we could setup another workflow for classes we don't want tasks and just set the task to a closed state.  I have some other ideas, but need to vet them out before sharing.  

So that's what we learned so far.  Hope this helps others that follow.

[Andrew Albury-D]

Hi Todd, 

Did you end up doing anything for your point 5 - Cloud Discovery? I'm looking now and can't see a quick way to disable this. We have our health inclusion rules set up to not include CIs we have marked as retired, but those health results don't look at that.

Thanks!