CMDB Health process tracking
Summarize
Summary of CMDB Health process tracking
This guide helps ServiceNow customers track, diagnose, and resolve issues related to CMDB Health processes, ensuring accurate configuration management database (CMDB) monitoring and maintenance.
Show less
Logging
By default, only error messages from CMDB Health are logged to the syslog table under the source name CmdbHealth. To enable logging of informational and warning messages—which mark the start and end of processing cycles—customers can update the system property glide.cmdb.logger.usesyslog.CMDBHealth. This enhanced logging aids in detailed process tracking and troubleshooting.
Processing Status and Monitoring
If CMDB Health scheduled jobs are enabled but data doesn’t appear on the dashboard, customers should check the CMDB Health Metric Status [cmdbhealthmetricstatus] table. Metrics can have these final states:
- Complete: All classes processed successfully with failures below the threshold.
- Max Failures: Failures reached the maximum threshold; processing aborts and restarts in the next cycle.
- Daily Time Out Pause: Processing time limit reached; processing pauses and resumes in the next run.
The overall KPI status depends on its metrics’ states and can be Complete, Incomplete (due to failures), or Daily Time Out Pause.
Performance and Timeout Analysis
For metrics that time out, the CMDB Health Processor Status [cmdbhealthprocessorstatus] table tracks processing progress per class. Classes marked Complete have been processed; those marked Draft are pending. By reviewing update times, customers can identify slow-processing classes and investigate potential weak validation rules.
Orphan Records and Broken Hierarchies
Orphan CI records caused by broken CMDB hierarchies may not be accessible or deletable via standard interfaces due to partial deletion in the database. When orphan records appear inconsistent in counts or cannot be deleted normally, customers must contact ServiceNow Support for database-level cleanup.
Orphan test results provide exact hierarchy break points, indicating which class records require deletion across multiple related CMDB tables to restore integrity.
Scripted Audits
Scripted audit failures to appear in compliance KPIs often occur if the audit script does not update the Last ran date field. Without this timestamp, CMDB Health cannot confirm the audit results are recent and skips these results, leading to potential gaps in compliance metrics.
Common CMDB Health Status Messages
- Failure threshold reached: Displayed when the number of failing CIs hits the metric’s failure threshold, indicating critical issues requiring attention.
- Incomplete score: Appears when CMDB Health cannot calculate a metric score due to processing errors or incomplete data.
Practical Application for ServiceNow Customers
- Enable detailed logging to monitor CMDB Health processes closely.
- Use the metric status tables to diagnose processing states and timeouts.
- Investigate long processing times to optimize validation rules.
- Engage Support for orphan record cleanup to maintain CMDB integrity.
- Ensure scripted audits update the Last ran date to reflect accurate compliance results.
- Interpret dashboard status messages to prioritize remediation efforts efficiently.
Use the following information to track and resolve issues with the CMDB Health processes.
Logging
By default, only error messages are logged to the syslog table, with the source name CmdbHealth. To enable logging of 'info' and 'warning' messages (which are typically logged at the start and end of each processing cycle), update the system property glide.cmdb.logger.use_syslog.CMDBHealth. For information about using this property, see CMDB Health system properties.
Processing status
If scheduled jobs are enabled, but data is not displaying on the <ph keyref="var.config-mgmt-database-short"/> dashboard, you can check the processing status in the CMDB Health Metric Status [cmdb_health_metric_status] table. Depending on the status of the inactive metric, decide how to proceed.
Initially, the state of all metrics is 'In Progress'.
- Complete
- All classes are processed and the number of failures is under the maximum failures threshold.
- Max Failures
- The number of failures for this metric reached the maximum failures threshold. Processing has been aborted and will start over in the next run.
- Daily Time Out Pause
- The processor reached the processing time limit. Processing is paused and will resume in the next run.
- Complete
- All associated metrics are in Complete state and score calculation is complete.
- Incomplete
- Score is not calculated because one of the associated metrics reached its maximum failure thresholds.
- Daily Time Out Pause
- Timed out because one of the associated metrics has reached its processing time limit.
Processing time
If processing of a metric times out, you can find out which class takes too long to process. Use this information to find out if any validation rules are weak.
The progress of each metric is tracked in the CMDB Health Processor Status table [cmdb_health_processor_status]. Status for classes that have been processed for a metric is Complete, and for classes that are yet to be processed is Draft. By looking at the update time for each class, you can calculate the length of processing time for each class.
Orphan records due to broken hierarchy
Orphan rules might detect an orphan CI, which you are not able to access and delete. Or, there might be a mismatch between the list view that displays the orphan records, and the total number of records. These findings are due to records being deleted in the database from only one table in the CMDB hierarchy.
These CI records are not accessible via GlideRecord and must be deleted directly from the database. Therefore, in this case, to delete an orphan CI from the database you must contact Support to get help.
Orphan test results provide the details of where exactly the hierarchy is broken. For example, the message "This cmdb_ci_linux_server CI [91054fc24f22520053d6e1d18110c713] is missing record in cmdb_ci_computer table" means that a record of that sys_id must be deleted from the CMDB, cmdb_ci, cmdb_ci_hardware, cmdb_ci_server, and the cmdb_ci_linux_server tables (the Computer class is between the Hardware and the Server classes in the hierarchy.)
Scripted audits Skipped
An error message is logged if the results from a scripted audit are not included in the compliance KPI. The reason can be that the script in the audit was not updated to populate its Last ran date field. Without a Last ran date value, CMDB Health is unable to identify these run results as part of a recent complete audit run, and skips those results.