Configuration of Completeness KPI:
I saw people asking how to configure 3 C’s metrics in CMDB OOB Health dashboard. What I believe it’s not about just get up & configure all 3 C’s in one go as each & everyone of it requires a process to be defined & implemented.
Thus in this article I am providing the steps required to configure Completeness KPI.
CMDB Health: Monitoring & Maintaining the health of CMDB.
Purpose of metrics:
The purpose of completeness metrics is to validate if a CI has the necessary data attributes or not. On a higher level it evaluates:
Are your CMDB CI’s populated with all the necessary data?
Completeness = Required(60%) + Recommended(40%)
The Completeness KPI is an aggregation of the following metrics:
- Recommended
- Required
The percentage shown is the OOB % ServiceNow provides. We can manipulate it as per our requirement.
Required metrics: allows you to mark some fields mandatory for a CI.
Recommended metrics: allows you to mark some fields which are recommended to be filled but not necessarily required. Having those recommended fields in CI provides more business value to CI.
Note: Required fields are rarely used during initial implementation of CMDB. Recommended fields are used as required fields during initial implementation of CMDB. Marking a field mandatory does not allow IRE to push the data in the CI class if the required field is missing in the CI payload.
Let’s configure them one by one:
Use Case: I
I want to configure the completeness KPI only for the server class for now as taking a single example clarifies how to configure it.
Only windows & Linux servers along with discovery source is Servicenow to be included.
Step 1: Set up health inclusion rule:
As the name suggest health inclusion rules allows you to filter which CI's are calculated as part of the CMDB Health Dashboard. Filter the CI's that are included in health calculations and that appear in CMDB health dashboards by defining health inclusion rules.
Go to CI class manager:
Note: Although we can only include required & recommended health metrics only but I have included all as it will be configured in the future.
The idea here is to apply health inclusion rule at the CI class level to include all the classes to which we want to run health jobs for & the class level filter is applied at the class level.
Let’s setup the server class level health inclusion rules.
Step 2: Configure Recommended metrics:
Open the CI class manager & go to server class.
Here I have marked assignment group, support group, model id, name, manufacturer as recommended fields
Step 3: Configure Required metrics:
Open the dictionary entry for the column label you want to set mandatory/required & set mandatory checkbox as true or use dictionary override.
When to use dictionary override?
Consider a scenario: Fields like Serial Number. Serial Number is a potential candidate to make required on the Hardware class and all of its extended classes. However, Serial Number is an attribute defined on the base Configuration Items [cmdb_ci] class and by default is not a required field.
If we want to make it required only for the Hardware class and its extended classes, then a dictionary override can be used on the Hardware class to make the field mandatory without affecting any parent classes.
Scenario:
If a field must be marked as mandatory, irrespective of discovery source Identification Reconciliation Engine (IRE) is failing to create a record when the field marked as mandatory is missing in the payload of CI.
We can configure a system property to overcome this situation.
Set this property glide.required.attribute.enabled to false.
As we have configured the required & recommended metrics of completeness KPI, next step is to think what actions should be taken if a CI fails in completeness health scan & who will take those actions.
There comes the task assosciated with required & recommended metrics when a CI fails completeness KPI health scan. By default task creation is not enabled in ServiceNow.
How to enable task?
Go to application navigator & type health preferences:
Go & hit the completeness job execution button & open & check the following tables:
Some important tables:
- Recommended Field Task[recommended_field_remediation.LIST] =>Recommended field task for each CI failed
- Required Field Task[required_field_remediation.LIST] =>Required Field task for each CI failed
- CMDB Health result:[ cmdb_health_result.LIST] => Failure Health result, their task & corresponding metrics as well.
- CMDB Health Metric Status [cmdb_health_metric_status.LIST]=>Holds the metric status while CMDB health job is being executed
When you open a task you will see remediation button. This requires a remediation rule to be defined & a workflow needs to attached to the remediation rule which allows you to automatically remediate the CI’s missing recommended or required attribute. This requires a defined process or some parameters on whose selection you can fill the missing fields.
Abbrevation used:
IRE: Identification & Reconciliation Engine
CMDB: Configuration Management Database
Thanks
Sudhanshu
On a Utah system, I made the serial_number field mandatory (using a dictionary override) on the cmdb_ci table. However, when I look at the CI Class Manager, the field does not show as mandatory even though it shows mandatory on the dictionary entry and on all form views (computers, linux server, etc) that are subclasses of Hardware.
Is this the expected behavior, that the CI Class Manager does not show the mandatory field? See screen prints below.
At a certain level of complexity our inclusion rules were becoming unwieldly. Something I did to reduce the effort cost of keeping track of all the different classes that have inclusion rules (again, depending on your complexity):
With the addition of principal classes (Tokyo?); we can use the principal class filter in the base cmdb_ci inclusion rule. This allows us to easily review and maintain which classes we have set as principal via cmdb_class_info. Since principal class is (can be) also used to provide filtering for key task interactions such as incident, change, etc. this setup provides a link between ensure those classes used by important processes are "healthy", included in health metrics.
In short, we just added the javascript principal class script to the inclusion condition:
sys_class_nameINjavascript:new PrincipalClass().getPrincipalClasses()The downside: last I tried, this was not do-able through the class manager interface. You will need to do an import into the cmdb_health_config table, with the appropriate inclusion condition. My recommendation is to navigate the cmdb_health_config.list and do an export of the existing entries to csv/xls. Update the inclusion condition and then import using appropriate coalesce. I usually preconfig the inclusion condition using CI Class Manager for things like the attribute conditions first then add the prefix to the condition.
sys_class_nameINjavascript:new PrincipalClass().getPrincipalClasses()^Note the caret "^" at the end which implies AND.
Import and now I only have to maintain the principal class flags. If you do need to update the inclusion condition, repeat the export > import as needed. Additional granularity/adjustments to the inclusion rules can be done per class, however, those classes must be flagged as Principal to be included:
