CMDB identification engine errors troubleshooting for Service Mapping - Support and Troubleshooting

CMDB identification engine errors troubleshooting for Service Mapping Issue

Overview This article addresses some questions that might arise when troubleshooting your CMDB mapping through Discovery.

Troubleshooting FAQ Why was a new record created? Or why was an expected record not created?

Use the following procedure:

Go to Service Mapping properties and enable verbose mode for identification engine. If this is unset, the only thing to appear in system log is errors. Setting the property to enable verbose mode gives more information.

Go to system logs and filter the messages containing "identification_engine" OR messages containing "Output= " OR messages containing "Input=".

The input message is the input that the identification engine gets. You can read this in your favorite json editor (try jsoneditoronline.org). You will see the CI and the relation that is being given to the identification engine.

Look for the corresponding output for this input. It might take some time to find the corresponding output. Read the output message in the json editor. A good indication is that they are found close together in the logs and have the same number of items/relations. If there is more than one input output record - look for className (type) to match the input output. You can match the sysid in the input /output.

If the item exists in the database, you will be able to see identificationAttempts - attemptResult : MATCHED and the operation would be NO_CHANGE. You can see the attributes that were used to match. If there is no match, the operation would have been an INSERT. The number of attempts is related to the number of identification rules and the criteria.

Why do I see the same CI in the database more than once? Are they real duplicates?

This might happen due to the dependency rule. For example, Tomcat WARs are defined the same way but may be on different servers. To examine the Input Output messages for the Identification engine to aid in troubleshooting, use the following steps:

Go to the identification rule for the CI.

Examine the criterion attributes.

Open the CIs (the seeming duplicates). The CIs might seem the same based on the identification rule but the dependency is with another CI and therefore they are different.

Why do I see the same entry point in the DB more than once?

This might be due to a previous product defect now fixed. Usually it occurs when the customer has defined an entry point by FQDN / hostname instead of the IP address.

This will go through DNS resolution, and we insert the entry point by the IP address. If the customer removes the entry point and then adds it again, the lookup will still occur by IP address,which will not be found. Therefore, a duplicate will be created.

Other issues that can occur during Configuration Items identification Other issues that can occur during Configuration Items identification is that a CI does not live up to identification rule criteria or does not live up to the dependency criteria. (The CI came into the database without the dependency - Apache without Linux server).

For these issues, use the previous procedures and examining the system logs using the "identification_engine" prefix. Verbose logging mode should be set, and all input/output records should be compared using your favourite JSON editor.

Since Jakarta, the identification Logs module shows descriptive errors and shows the input and output that you can read in the Json editor.

Go to the Identification/Reconciliation module and go to metadata editor to see or modify the rules.

The Identify Reconcile API is available In Jakarta from the REST API Explorer. You can use it to test the changes you might have done to solve the issue.

Paste the (fixed) input payload in the Identify CI (Post) Identification and Reconciliation REST API on the Raw Body tab of Request tab and Send.

Examine the response.

If it was before Jakarta, you would have had to run discovery again. From Jakarta onwards, you can use the REST API to try out any changes.

Example errors in the Output Payload Missing Identification Rules – The Output load indicates that an Identification Rule is missing.

Missing Attributes – The Output load indicates a Missing Matching Attributes or Required Attribute Missing.

Sometimes customers define a field to be mandatory and sometimes the pattern does not populate.

The glide.required.attribute.enabled property tells the identification engine whether it should ignore mandatory attributes. This property is true by default. If you set it to false, the Identification engine will ignore the mandatory attribute. This error is also populated in the discovery logs.

Duplicate – The Output load mentions duplicates.

Examples of dependency issues Incorrect definition of hosting/containment rules. No dependencies present in the payload.The thrown error is "Missing Dependency". Multiple dependencies in the payload.