- My View
Join us on this discussion page for a YouTube Live Presentation on setting up CMDB health metrics and how to apply them.
It's an opportunity to see how the new CMDB Health Dashboard can help you manage the data quality of server and network device data. This new dashboard provides an actionable view of CI health and a remediation framework to take corrective actions.
Please Like and Share! Find More Events on the Community!
Presented by Richard Brounstein, ServiceNow Solution Architect for ITOM, specializing in IT Operations and crafting CMDB solutions for customers, based in the New York City area. He will be hosting a CMDB lab at Knowledge 2017. Before joining ServiceNow, Richard has more than 10 years experience as a System Engineer with Hewlett-Packard.
Watch the Demo Below and Read the Q&A below!
(Be sure to change your YouTube Setting to 720HD)
Be sure to join us TODAY for a Live Demo and Post your questions here!
Community Engagement Manager
How can we filter out class that we don't need? Example we have some that are showing up under or Orphan and Staleness which we would like to hide. We've tried by setting an Orphan rule on cmdb_ci table that class is not SNC Component but they still show up with information.
Another issue we see is Duplicates. We know we have duplicate records but they are not showing up, duplicate relationships show, and we don't see any way to configure it. What is it looking for in regards to duplicates.
Staleness - if a manual update is applied to the CI does this change the Most Recent Discovery or does it have to be discovered to change it?
If you manually update and save a CI, it will not update the most_recent_discovery field.
Hi Do you know if its possible to use a different field to track staleness, like Last Updated Date?
No. It is hard coded to use the most_recent_discovery (last_discovered) field. This field gets updated with the date/time that the CI was discovered even if there were no changed detected to any data. The Updated (sys_updated_on) field has the last date/time that the CI was discovered and at least one changed attribute was detected. It is possible for a CI to not be stale but not to have been updated for a long time so most_recent_discovery is the better field.
Duplicate records are measured by running the CI identification rules for the particular classes against the existing CIs for those classes. If the CIs that you know are duplicate are still uniquely identified by the CI identification rules, then they will not be found as duplicates.
pre-Jakarta, there is no easy way to filter out CIs from the dashboard from being measured. In Jakarta, we introduced something called the Health Inclusion Rules, which is a query we run against the CI Classes before we run the CMDB Health Dashboard measurements.
Pre Jakarta, there are some things you can do. For stale CIs, you can setup a job that updates the field Most Recent Discovery (last_updated) field to the current date/time and they will not come up stale.
Orphans already use a filter so this may not be an issue.
In the Jakarta Health Inclusion Rules will it only be possible to filter out classes or will there be other options e.g. to filter out CIs with a specified status?
The dashboard is unlikely to work for us without a filter because we don't delete CIs but keep them under a different status and don't want them measured
I don’t see your screenshot. But you can’t apply a filter condition to an Orphan rule until Jakarta. In Jakarta we are introducing Health Inclusion Rules in the CI Class Manager, which is a filter of conditions applied to the CIs before it runs the Orphan Rule.
I am trying to run orphan rule for only active and not for retired CIs ones.
Will this work?
Or I should ask, what will it retrieve me?
I am setting condition for orphan rule as Active is 'True'
and CI Status is 'not Retired'. I have also checked 'No relationship' to True.
Will it only run this rule for all Active and non retired CIs?
Or will it mark all Active and non retired as Orphan?
In Istanbul and older releases, the rules for Orphans, Staleness, Recommended and Required CIs are run against all CIs in the cmdb_ci table, which is the entire CMDB. In Jakarta, the CMDB Exclusion Rules will allow you to apply a filter so that the rules will only apply to a select set of CIs. The filter can look at the Operational Status field to see if the CI is “non operational”. Or it could filter out on any other field.
Did you achieve this? I have a similar requirement
CMDB Health Dashboard seems to be very raw mechanism - are there any known issues/challenges that being faced that you are aware of?
A useful presentation, thank you
You suggested clearing the cache to view the most recent data - is this required by the user after every job run regardless, or will the data automatically refresh after an elapsed time? If after an elapsed time, how long is that period please?
Clearing the cache from your browser is required by the user after every job run. If you don’t manually clear your browser cache, you will have to wait 2 hours before it will refresh the data automatically.
I am seeing THOUSANDS of Stale CIs that don't have the Most Recent Discovery populated. Most of these are Child CIs - disk drive partitions, patches, memory modules, etc. where the Parent CI's Most Recent Discovery field is populated.
Am I correct in that "Use probe cache results" Mid-server property and "Cache results" Discovery Probe setting might also be contributing to the large numbers of Stale CIs?
Cleaning all these up is taking a lot of time. Are there plans to fix, resolve or change this via a hotfix or patch?
Looking forward for more information about the CMDB Health Dashboard!
In Jakarta, we are adding a Health Inclusion facility. You will be able to set a filter to filter out just those classes for which you care about tracking for staleness or orphans.
What is the date of your most_recent_discovery field in all these child CIs? If it is older than 60 days, then they will come up as stale. In the meantime, you could have a script that sets the most_recent_discovery (last_updated) to “NOW” and run it every month so the CIs don’t come up stale.
The field on the child CIs is not being populated... so ... NULL.
I've been running a script to populate the field but that seems to be an underhanded way of doing it.
I'm trying to change the CI Identification rule for a single class. In the hierarchy CI -> Hardware -> Computer -> Server -> UNIX Server -> AIX Server, I get a lot of duplicates on the AIX servers. These AIX servers are in reality LPARs on a POWER8 server, and they show the same serial number.
Therefore, I would like to substitute the CI Identification rules on (and inherited from) class Hardware ("Hardware rule") with a rule specific for AIX Servers. The specific CI Identification rule for the AIX servser should consist of a sinkgle match on the ID (asset_tag) which should be unique for servers.
I have created and activated this rule for AIX Servers, and I have deactivated the "Hardware rule" for the same class. However, I see no diffference in the duplicate count... (have flushed the cache, yes)...
What did I miss?
Thanks in advance,
Did you rerun the CMDB Health Dashboard Correctness Score Calculation
Configuration -> Health Properties
Scheduled Jobs (tab on right hand side)
Click into CMDB Health Dashboard Correctness Score Calculation job and click “Execute Now”
Then, go into the cmdb_health_metric_status table and make sure that the status of the jobs is complete. This can take time as it will scan all the cmdb_ci table
Then, clear your browser cache
Then, look at the CMDB Health Dashboard View and see if the duplicate count is the same.
Yep, did all that.
From the CI Class Manager, I traverse down the hierarchy to the AIX Server class and mark it. Click "Advanced", mark CI Identifiers.
There was the Hardware rule, which applies to the Hardware class ad all specializations.
Created a new rule, AIX Server Duplication rule which applies to the AIX Server class. this rule has only a single identifier entry, namely the ID (asset_tag).
Activated AIX Server Duplication rule and deactivated Hardware rule on the AIX Server class.
cmdb_health_metric_status.list - wait until all jobs have completed
Same duplicate count.
You look at the specific CI's and determine if the count really is incorrect. Click into the graph and you'll get a list of all the CI's. If it's not too many you should be able to really verify this. If it is too many then you can write a script to confirm this.
Sent from my iPhone
The count should be zero, but it is 123.
The IDs (asset_tags) are all unique, but there are 3-11 IDs with each of the 8 serial numbers. This is because there are 8 physical machines each hosting a number of logical partitions (LPARs) which are almost (but not entirely) as virtual machines.
I'm attempting to eliminate the serial number from the identification.
I talked to R&D about this issue. Duplicates are detected for the CMDB Health Dashboard during discovery. Discovery will mark the field “discovery_source” as “duplicate” when duplicates are found. It also creates De-Duplication tasks and the CIs appear on the Dashboard.
If you want the CMDB health Dashboard to scan for duplicates leveraging different CI Identification rules without doing Discovery, then you need to clear out the “discovery_source” field for those CIs and then have it rescan by running the Health Preferences Correction Rule. The Health Preferences Correction Rule only scans CIs that are marked as duplicate from Discovery or CIs where the discovery_source is blank.
By the way, you can't eliminate the serial number from identification unless you eliminate it from the superclass hardware rule. You can always add new rules that run as a higher priority for subclasses.
The infrastructure is hosted with the service provider. We have set up an integration between the service providers CMDB (HP uCMDB) and our CMDB.
The class used to represent the AIX LPARs is the AIX Server class, and therefore we cannot immediately use the LPAR class instead...
How will the dashboard's and the calculation work in a domain separated instance?
From the documentation in Istanbul:
CMDB Health is domain aware. If the domain separation plugin has been activated, then the CMDB dashboard displays health based on data, rules, and settings from the logged-on user domain. If rules and settings are not defined for a child domain, then the parent's settings are applied, recursively.
Giving access to my itl_admin and ecmdb_admin to work with the module (istanbul), but seems to have Issue with access rights:
- If I'm and Ititl_admin or ecmdb_admin I'm not able to see dictionary entries, is there any reason why this form is shown at all?
- When click on a class, table dictionary shows up but all columns/attribues are restricted due to security, is this intended and does it have any impact on the functionality?
- not able to configure rules and properties - all field are read only?
If the CMDB Health sub-metric staleness is in effect, then staleness rules are used to determine the percentage of stale CIs in the CMDB. This sum is then aggregated into the correctness metric, and weighs into the overall CMDB health calculation. Staleness rules are defined per class per data source.
Before you begin
Role required: itil_admin (on top of itil)
The itil_admin role is designed to allow non-admin users to configure the Health Dashboard settings for Staleness, Duplicates, Orphans, Compliance and recommended fields. It will not allow you to update CI Classes in the data dictionary.
Did you participate?
We'd love to hear your feedback on this event!
Community Engagement Manager
This video is very helpful in terms of understanding the OOTB CMDb Dashboard.
I have two questions here:
1) There is a scenario where we need to check a custom field "ABC" is integer OR the value in a certain choice list falls between the values defined in choice options. In order to implement that I have used Compliance -> Audit , wherein first I configured "Certification Filter" , "Certification Template" and Audit. This is giving me the correct result in the health table. Now I would like to know if I am doing it in the correct way. Because I think we can do the same in Orphan also
2) Now, regarding the permission. In order to give access to certain group/role, I shared the "CMDB Dashboard - CMDB View" with particular role and group. But the users of that group cannot see the data calculation. Below is what they can see
and Strangely, If I share the other dashboard like "CMDB Completeness Dashboard" that is working fine as below: