Note: This is not a solution that replaces the need to be compliant with the CSDM. Servicenow will always recommend to work towards adopting and respecting the data model. The solution described in this article can be seen as a temporary solution or a quick value-based implementation to convince team working on alert management.
Context:
There is a general idea that ITOM Health needs the CMDB to be properly populated to be able to get value from it. This is not necessarily the case and organizations can get value from ITOM health at any phases of CSDM adoption. See the below roadmap and maturity levels with the corresponding capabilities and value of ITOM health:
How to address AIOps Journey
Align AIOps to CMDB maturity
Nevertheless, it is true that the higher CMDB maturity is, the higher the ITOM health value will be. One of the most expected results from ITOM health is the service impact and this is only reachable with the highest maturity of CSDM with service mapping implementation. Therefore it can be seen as difficult to get to this level and organisations are holding back on ITOM health project, thinking it will take too much effort and time.
But with the latest releases of ITOM Health (since Washington), there is a potential workaround for this.
The standard implementation:
To be able to get service impact from ITOM Health, organisations need to build "application services" concept on top of discovered or imported CIs. There are several ways to create applications services:
- Manual Application Service
- Dynamic Application Service (CMDB Group-based)
- API-based Application Service (Created using REST API)
- Integration-Based Application Service (Created from connectors with other tools like Dynatrace)
- Tag-based Application Service (Created from tags from the cloud)
- ML-based Application Service (Created from servers traffic discovery)
- Pattern-Based Application Service
We've listed them from the less to the most advanced ones. Once having these application services created, the service impact concept can be used in different ways:
Using the Service Operation Workspace to monitor services instead of individual alerts
Opening a service map and visualize its impact
When opening an alert, identifying all the services impacted by this alert
In the Express List interface, visualizing the impacted services column
The results and examples above are obtained when application services are created and contains CIs. When an alert is bound to a CI, the application services that contain this CI would turn in a specific impacted color or would be identified on the alert
This information can then be used to leverage automation, prioritize the effort, assess the criticality, assign the alert to the right team, etc...
Let's see now how we could obtain a similar result without having application services created.
A workaround approach:
Organizations could have already created an equivalent of Application Services in another table and the most common one is the "Application" table.
Note: Once again we insist on the fact that this "Application" Table is not meant to host this kind of information and it is actually used by our Discovery solution to create applications (like Tomcat...).
So before entering in a Back to Standard project and migrate the "application" table to the "Application Service" table, organizations could use this table to identify which application is impacted when an alert is bound to a CI that belongs to this application.
Let's see a concrete example: some organizations could have discovered or imported servers in the CMDB and linked them to applications manually like described below:
The relationships of a server and its link with the application
You can also visualize this information in the "cmdb_rel_ci" table:
Relationship between a server and its application
Now let's see how to make this information available on the alert when it is bound to the corresponding server.
The technical implementation:
We will use the capability called "Event Field Mapping" to retrieve information from the CI to enrich the content of the alert. Usually, it is easy to retrieve information from the CI with a basic Event Field mapping rule but as we are looking for a related object on the CI, we will need to use an Advanced Event Field Mapping rule (script).
First go and search for "Event Field Mapping" in the research menu:
Event Field Mapping capability
We will create a new one called: "POC add AppName to add_info"
- Select the monitoring source that will send the events in the Servicenow Platform
- Check the box "Run after Binding": we need this to identify which CI is impacted by the event
- Select "Advanced mapping using script"
Creation of a new Advanced Event Field Mapping Rule
Now here's what the script will contain:
- First we need to get the the application that is linked to the impacted CI:
var rel = new GlideRecord('cmdb_rel_ci');
rel.addQuery('child', ciSysId);
rel.addQuery('type.name', 'Depends On::Used by');
rel.addQuery('parent.sys_class_name', 'cmdb_ci_appl');
rel.query();
- Then we will need to retrieve the actual content of the "Additional Information" attribute from the Event. Actually we will push the application information into the existing "Additional Information" of the Event. The "Additional Information" is a Json object so this is how you retrieve it:
var addInfo = JSON.parse(eventGr.getValue("additional_info"));
- Now we will create a new Tag that will host the application name and push it into the existing "Additional Information" content. You need to respect the naming convention with the "t_" as described below:
if (rel.next()){
key = "t_appname";
value = rel.getDisplayValue('parent');
addInfo[key] = value;
- To finish, we will have to update the new "Additional Information" content into the Event corresponding attribute:
eventGr.setValue("additional_info", JSON.stringify(addInfo));
That's it here's the full script if needed:
(function eventFieldMappingScript(eventGr, origEventSysId, ciSysId, fieldMappingRuleName) {
try {
var rel = new GlideRecord('cmdb_rel_ci');
rel.addQuery('child', ciSysId);
rel.addQuery('type.name', 'Depends On::Used by');
rel.addQuery('parent.sys_class_name', 'cmdb_ci_appl');
rel.query();
var addInfo = JSON.parse(eventGr.getValue("additional_info"));
if (rel.next()){
key = "t_appname";
value = rel.getDisplayValue('parent');
addInfo[key] = value;
}
eventGr.setValue("additional_info", JSON.stringify(addInfo));
return true;
} catch (e) {
gs.error(" The script type mapping rule '" + fieldMappingRuleName + "' ran with the error: \n" + e);
}
})(eventGr, origEventSysId, ciSysId, fieldMappingRuleName);
Simulate the result:
Now you will need to validate the implementation. Create a new Event manually with the following important information:
- Source: the source which has been defined in the Advanced Event Field Mapping rule
- Node: The server name that is linked to an application
Event Simulation
- Look at the processing notes of the event. You should find 2 important information: The binding of the CI and the execution of our Advanced Event Field Mapping Rule. If you don't have these it means that the event doesn't satisfy the filter criteria of you rule:
Processing notes of the event
- You should see the alert generated from the event and find back the application information in the "Additional Information" of the alert. In addition, an alert tag has been created "t_appname" and shows the name of the application:
Alert containing application information
Result of the Workaround:
Now this can be used from the Express list Interface. The tag that has been generated earlier is visible from the alert list:
Alert from the Express List interface
You can even filter on the appname tag from the express list interface:
Filtering panel from the Express List interface
To conclude, you can now leverage the same value and possibilities as if you would have the "impacted service" that is to say leveraging automation, prioritizing, assess criticality, assign to the right team...
Note: This workaround shouldn't be permanent as it could impact the performance of the platform. In fact, we are using a "gliderecord" process in the Event Field Mapping script which could impact the performance if too many Events are processed in a short period of time.
