Introduction
The Health Dashboard provides a powerful way to monitor system health across multiple domains. One of its key features is the ability to control which health metrics are active for specific domains. This article explains how to configure domain-specific settings for health metrics, using correctness as an example. We will use data setup in How Data Visibility Works
Understanding Domain Inheritance
Before diving into configuration, it's important to understand how domain inheritance works in the health metrics system. This hierarchical structure enables flexible configuration across your entire domain structure:
- Global settings are inherited by all domains by default
- Parent domain settings override global settings and are inherited by child domains
- Individual domain settings override parent domain settings
Accessing and Configuring Health Preference Settings
Accessing and configuring health metrics is straightforward through the Health Preference interface:
- Search for "Health Preference" in the left navigation panel
- Click on "Health Preference" to open the health preference page
- Select "Health Metrics" tab
- Select a specific metric (like correctness) to view its current status
When viewing a metric, you'll see a toggle switch showing whether the metric is active or inactive. By default, metrics are defined in global scope, meaning all subdomains automatically inherit these settings unless specifically overridden.
Correctness Health Preference:
Behind the Scenes: How Settings Are Stored
The health metric preferences are stored in the cmdb_health_metric_pref table in the database. Each record contains essential information like:
- The metric name
- The domain it applies to
- Whether it's active or inactive
An important aspect of the inheritance model is that when a domain inherits settings from global or a parent domain, no explicit record exists for that domain in the database until you create an override. This keeps the database efficient while maintaining flexibility.
Health Metric Preference:
Testing Domain-Specific Settings in Action
To understand how domain-specific settings work in practice, let's examine a test scenario using the correctness metric with an orphan rule:
- Configure an orphan rule in the CI Class Manager that identifies CIs with serial_number ending with "_0" as failures
- Run the Correctness health job with all domains active
- Examine the health results showing one failure for each domain, confirming the job ran across all domains
Orphan Rule:
Health Result Global:
The results demonstrate that with default settings, the health check executes uniformly across all domains, identifying matching configuration items in each domain.
Applying Domain-Specific Overrides
When you need to exclude specific domains from health checks, you can apply domain-specific overrides:
- Switch to the target domain (e.g., Cisco)
- Navigate to Health Preference
- Locate the desired metric (e.g., correctness)
- Turn off the toggle for that metric
- Save your changes
Health Metric Pref(cmdb_health_metric_pref) cisco domain:
After applying this override, several changes occur:
- The job no longer runs for the deactivated domain
- Health results will show failures only for domains where the metric remains active
- The database adds a domain-specific record with active=false, overriding the inherited settings
Health Results after running will not contain any cisco domain failures as the domain is skipped for evaluation
.
This targeted approach gives you precise control over which domains participate in health monitoring.
Optimizing for Large Environments
For environments with thousands of domains, an efficient configuration strategy is essential. Consider this approach:
- Deactivate metrics at the global level (set to false)
- Selectively activate only for the domains where needed
This "opt-in" approach is more efficient than having everything active by default and selectively deactivating, particularly in large-scale implementations. It minimizes unnecessary processing and focuses health checks only where they're most valuable.
Conclusion
Domain-specific health metric settings provide granular control over health monitoring across your ServiceNow environment. By understanding the inheritance model and strategically configuring which domains run specific health checks, you can significantly improve system performance while maintaining effective monitoring where it matters most.
This approach is especially valuable as organizations grow and domain structures become more complex. Taking the time to configure domain-specific settings properly ensures that your health checks remain focused, efficient, and meaningful.
