What classes should be kept for calculating staleness on the CMDB Dashboard

[Steven Barber]

Hello all,

I'm trying to figure out what classes should be kept for calculating staleness on the CMDB Dashboard.

I'm thinking only the classes we are discovering like servers, printers, and switches etc.

Classes like network adaptor, business app, and disk shouldn't be included.

[Ashok Sasidhara · Accepted solution]

Yes. That's right. Staleness should be tracked only for CI classes which are populated automatically by discovery or by any 3rd party integration. Among these CI classes also, we should ideally consider only the most important classes (E.g. servers, network devices, storage, database etc.) for staleness tracking if there are too many such classes. The effective duration of staleness of each CI class should be decided based on how frequently the data in that CI class is updated by discovery or integration.

[CMDB Whisperer]

Wise advice, I agree.  I would add that if you have an attestation process or other process that should result in periodic updates to a class of CIs, you can include that class as well. 

With all staleness rules, my guidance would be to allow adequate time for any issues to remediate on their own before flagging something as stale.  For example, if you generally expect Servers to be updated on a daily basis, don't flag them as stale until at least a week.  If you generally expect them to be updated on a weekly basis, don't flag them as stale until at least a month. 

Another thing you should consider related to staleness is data refresh rules.  While staleness simply flags the CI after a period of time, data refresh rules allow a secondary data source to take priority if the primary data source doesn't update the CI for a period of time, which may help.