CMDB : Stale CIs : CMDB Corerctness Scorecard - Failure threshold reached

[Craig58]

Hello all,

I hope you can help with the question below. We have recently deployed and activated the our ServiceNow New York instances and are starting to populate the CMDB using the ServiceNow discovery capabilities. We have been monitoring and baselining our progress using the CMDB dashboard and policies supplied with the module. One of calculations contained within the CMDB Correctness policy is Staleness which loosely translates to the target CI is not updated within a configured time period. We set our policy to be 60 days, after the 60 days period had expired we started to receive a "failure threshold reached" on the calculation in the dashboard. After investigation is appears that the period calculation uses the value in sys_updated but this value remains the same if discovery runs and does not update anything which is not the desired intention of determining whether a CI is stale.

We were advised of a possible workaround by ServiceNow support by using a Health inclusion rule as below but this did not meet our requirements.

This can be done via a Health Inclusion Rule

KB0697680 - Create health inclusion rule

https://docs.servicenow.com/bundle/london-servicenow-platform/page/product/configuration-management/...

You can add the health inclusion rule at the parent Configuration Item level with a condition of "Last Discovered/Most Recent Discovery --> not performed --> Last 60 days" to skip CIs which you have recently discovered.

If there anyone in the community that has experienced the same issue and could you advise on possible steps to remediate this ?

Best Regards

Craig

[Suresh Telu]

One way to keep those devices which are being discovered, but not being updated with the new info, is to write a business rule on insert/update that sets the 'Updated' field timestamp with 'Most recent discovery' timestamp whenever there is a change to the 'Most recent discovery' field.

Another way of achieving the same result is - using/adding a custom attribute that can be updated with 'Most recent discovery' timestamp or any other information which is useful for the org, whenevere the discovery runs on the CI, which keeps the record also updated and keeps it outside the staleness rules.

[manishm]

I have come across this issue and for the very same reason. The rule looks at sys updated date and discovery does not update the CI if there are no updates to be made, other than the most recent discovery date. Lets talk about the Failure Threshold Reached error first. It comes when the staleness rule has seen X number of stale CIs, X being configurable, and stops processing the rule for any further CIs. An option is to set the threshold parameter to a high value and that can cause more CIs to be processed for staleness.

I would fix it just as suggested by Suresh i.e. Write a BR on update only (not insert) which sets sys_updated_on field with Most Recent Discovery (MRD) timestamp. Caveat, not all classes get their MRD field updated with discovery. If you have the oddball case where it does not, update the probe / sensor / pattern.