Domain Separation in Health Dashboard: Understanding Health inclusion Rules

[Sandeep90]

Introduction 

Health inclusion rules play a critical role in CMDB health, particularly when working across multiple domains. This article explains how health inclusion rules work with domain separation and highlights important considerations for implementation. We will use the data setup in How Data Visibility Works article.

What are Health Inclusion Rules?

Health inclusion rules determine which Configuration Items (CIs) are included in health checks and monitoring. These

rules can be configured at different levels in the CI class hierarchy and follow an inheritance model.

Configuring Health Inclusion Rules

Health inclusion rules can be configured from the CI Class Manager by following these steps:

1. From the left navigation panel, select "CI Class Manager"
2. In the CI Class Manager, expand the class hierarchy
3. Select the specific class for which you want to configure health inclusion rules (e.g., Linux Server)
4. Expand the "Health" section
5. Click on "Health Inclusion Rules"
6. Click the "New" button
7. Choose the metric for which you want to configure health inclusion rules
8. Create the active record condition for inclusion
9. Save the record

This process allows you to define precisely which CIs will be included in your health checks for specific metrics.

 

Inclusion Rule: 

Understanding the Inheritance Model

When health inclusion rules are defined at a certain level for a metric in the class hierarchy, all subclasses inherit these rules unless they are explicitly overridden.

Example of Inheritance:

• When a rule is defined at the base Configuration Item level (cmdb_ci), all subclasses inherit this configuration
• If you define a rule like "name is not Empty" at the cmdb_ci level, all its subclasses will use this rule for that metric. 
• If you override the rule at a lower level (e.g., Hardware or Linux Server) with "name contains _2", then that class and all children of that class will inherit the overridden rule for that metric. 

 

Domain Separation with Health Inclusion Rules

Domain separation adds another layer of complexity to health inclusion rules. Here's how it works:

1. Health inclusion rules can be defined at the global domain level
2. Individual domains inherit these rules by default
3. Rules can be overridden at a specific domain level

Example with Multiple Domains:

Let's demonstrate how these rules work across domains:

1. First, we define an orphan rule (CPU count is 0) to identify servers that need attention
2. In the global domain, we include only CIs with names containing "_2"
3. We run the health check job

The results show that in each domain, CIs with names containing "_2" fail the orphan check, as defined by the global inclusion rule.

Now, let's override the rule in the Cisco domain:

1. Switch to the Cisco domain
2. Override the health inclusion rule to include only CIs with names containing "_4"
3. Run the health check job again

The results now show:

• In all domains except Cisco: CIs with names containing "_2" fail
• In the Cisco domain: Only CIs with names containing "_4" fail

Domain-Specific Evaluation in Overridden Rules

When evaluating inclusion rules, it's important to understand exactly how domain separation affects overridden rules: 

• Domain-specific rules apply ONLY to CIs owned by that specific domain - not to all CIs visible within that domain
• The global domain rule applies only to CIs in the global domain
• Domain-specific rules apply only to CIs owned by those specific domains

For example, when working in the Cisco domain:

• You can view both global CIs and Cisco-specific CIs (you have visibility into both)
• However, the Cisco domain inclusion rules apply exclusively to CIs owned by the Cisco domain
• Global inclusion rules continue to apply to global CIs, even when viewed from the Cisco domain
• This distinction between visibility and rule application is critical to understand

This means that when you run a health check in the Cisco domain, you might see failures from two different rule sets:

• CIs owned by the global domain failing based on global inclusion rules
• CIs owned by the Cisco domain failing based on Cisco-specific inclusion rules

 

Performance Considerations

• Complex rules can cause performance bottlenecks and slow down health check processes
• Rules are evaluated for all applicable classes - defining complex rules at the cmdb_ci level requires evaluation across all CI classes
• Ensure fields used in inclusion rules are properly indexed

Best Practices

1. Keep inclusion rules as simple as possible
2. Use indexed fields in your rules whenever possible
3. Apply rules at the appropriate level in the class hierarchy to minimize processing
4. Test rule performance in non-production environments before implementing
5. Monitor health check job performance after implementing new rules

By following these guidelines, you can effectively use health inclusion rules across domains while maintaining system performance.