Understanding CMDB Health
Maintaining a high quality CMDB is crucial for enterprise management solutions as CMDB is a central piece supporting critical processes and services.
Fortunately ServiceNow ships as a platform component capabilities that allow you to monitor and improve the health of your CMDB. The main capability is CMDB health dashboards that I am going to explain in this article.
Let me first present the "theoretical" knowledge of this module before jumping in the next section to the "field experience" and best practices.
The CMDB health dashboard provides three main KPIs (or scorecards) that indicates the health of the three main dimensions of the CMDB. Each KPI is an aggregation of sub-metrics. Below you can find the main KPIs, their metrics and how you can configure the platform to monitor them.
- 1. Completeness: Make sure that CI information are complete by checking for required and recommended fields that are not populated
- * Metrics:
- * Recommended: Measure the % of CIs in which fields that are defined as recommended are not populated (such as support and assignment group, cost center, assigned to..)
- Required: Measure the % of CIs in which fields that are defined as Required are not populated (such as serial number, name..)
- This is also applicable on fields fields that are used by the Identification and Reconciliation Engine (IRE) to determine records that need to be created versus updated
- Required: Measure the % of CIs in which fields that are defined as Required are not populated (such as serial number, name..)
- Configuration
- * The two metrics above can be configured in the CI class manager. For each class, "recommended" fields can be added in the Health -> Completeness section slush-bucket. The required field are those marked as mandatory in the dictionary.
- * Recommended: Measure the % of CIs in which fields that are defined as recommended are not populated (such as support and assignment group, cost center, assigned to..)
- 2. Compliance: Audit the CMDB for adherence to predefined audits (SOX, HIPPA etc.). Are your CMDB CIs configured as expected and meet desired state expectations? as an example do "All Workstations have antivirus software installed on them" ?
- Metrics:
- * Audit: Compares actual values of specified fields against expected values in templates and scripted audits
- Configuration
- * Configure the filter that represents the scope of the audit, the Templates that represent the expected values (can be on field or related list level) and the audit for frequency. This can be done in the CI class manager Health -> Completeness section.
- Configuration
- Metrics:
3. Correctness: This metrics helps you test your CMDB against predefined data integrity rules such as identification rules for duplicates, orphan rules, and staleness CI rules. Are your CMDB CIs up to date, accurate, with minimal to no duplicates?
- Metrics:
- * Duplicates: Several entries for the same CI (one CI in data center but two CIs in ServiceNow)
- Orphans: Conditional based CI like an application that doesn’t have a relationship to a Server
- Staleness: CI that has not been updated for a period of time
- Orphans: Conditional based CI like an application that doesn’t have a relationship to a Server
- Metrics:
- Configuration
- * Duplicates are calculated based on the CI Identifier rules created for each class. This can be done in the CI class manager or in the CI identifier module under Configuration application.
- Orphans rules are managed in the CI Class manager, Health -> Correctness section
- Staleness: one staleness rule is available by default on the main CI class (cmdb_ci) which sets the period to 60 days. This rule can be overridden in the CI class manager Health -> Correctness.
- Orphans rules are managed in the CI Class manager, Health -> Correctness section
- Configuration
For the three different categories, Health Inclusion rules can be created. it Allows you to filter which CIs are calculated as part of the CMDB Health Dashboard.
- In the base system, there are no predefined health inclusion rules, in which case all CIs are included in the CMDB Health calculations.
- If there are no health inclusion rules specified for a child class, then rules specified on a parent class are applied to the child class.
- If health inclusion rules are specified for a child class, then those rules take precedence over rules specified on a parent class.
The different Scores are calculated by pre-defined scheduled jobs that can also be found in the CMDB health dashboard. Job execution results can be checked in the: cmdb_health_metric_status.
- CMDB Health Dashboard - Correctness Score Calculation
- CMDB Health Dashboard - Compliance Score Calculation
- CMDB Health Dashboard - Completeness Score Calculation
Different scores of the CMDB health dashboard.
Field Experience and Best Practices
Below you can find few best practices gathered from previous experiences in the field.
1. When correctness job runs, it generates "remediate duplicate task" if duplicates are found. The best practice is to remediate the issues in the task and not directly on the CI level (deleting the duplicate CI) for various reasons:
* * The OOB task remediation process has advanced functionalities that can be used to merge attributes or relations that can be difficult to do manually.
* If duplicate task are still open, the dashboard will not give accurate results if changes are done directly on the CI level.
2. Do not use Encrypted fields in CMDB health rules (inclusion rules, CI identifiers..) as those attributes would not be correctly interpreted by the CMDB health engine
3. Do not confuse data certification and CMDB health desired state audit
* * Use Data Certification audit to manually verify attributes values. Is Abraham Lincoln the correct owner for Server001?
* Use Desired State audit to automatically verify thatServer001 has an owner and the field is not empty
4. Start implementing CMDB health as soon as you start the CMDB implementation. Configuring the different metrics and improving them little by little is more efficient than fixing hundreds of issues few monthes later.
5. Leverage the CMDB health groups to be able to load the different scores on a subset of CIs. In the main dashboard (CMDB Health - CMDB view) the scores can be loaded on all CIs or a child class. However the (CMDB Health - Group view) dashboard can be loaded on a CMDB group that represents a query on any attribute of the CI. This is an excellent way to slide and dice the scores and see them on different angles.
Hope this article accelerates your CMDB journey! Don't hesitate to share your thoughts and REX on this topic.
Regards,
e.
https://www.servicenow.com/community/itsm-articles/understanding-cmdb-health/ta-p/2307033
