Linux server pattern discovery error - Missing identifier entry for ci type : cmdb_ci_disk

Vinay Noel
Tera Contributor

While doing Linux server discovery, the discovery fails with the error "Failed Exploring CI Pattern, Pattern name: Linux Server, To Check Pattern Log Navigate to: $sw_horizontal_discovery_log.do?"

Upon checking the pattern logs, I see the error as below in the failure steps -

 

There is problem to build the Sanitized Payload: Identification Engine errors: See [code]<a href=\"/nav_to.do?uri=%2F$identificationLogs%3Fcontext_id%3D261e50031be52d10fa19ec27624bcb13\" target=\"_blank\"><u>Identification Logs</u></a>[/code] for more info.\n\n\n\tProposed solution:\n\tNavigate to 'Metadata Rules Editor'.\n\tIf the failed CI type is included CI (e.g. Tomcat War) look for it in the 'Containment Rules' area. If not found, a rule should be added.\nMissing identifier entry for ci type : cmdb_ci_disk . Go to 'CI Identifiers' from the navigation pane and add the needed entries.\nIn payload no relations defined for dependent class [cmdb_ci_disk] that matches any containment/hosting rules: [cmdb_ci_storage_device >> Contained by >> cmdb_ci_hardware,cmdb_ci_storage_device >> Contained by >> cmdb_ci_computer]. Add appropriate relations in payload for '{\"className\":\"cmdb_ci_disk\",\"values\":

 

I navigated to Metadata Rules Editor as mentioned in the error message and could find the Linux server in the containment rules.

 

Please help with any solution.

 

 

4 REPLIES 4

Prabu Velayutha
Mega Sage
Mega Sage

Hope this failing while trying to create the related CI record for the Linus Server, can you find which application or any CI type it is trying to explore on that specific pattern step? you can go to debug mode and locate pay load data build by the pattern to create the CI. You can create new containment rule if it is not found already for the specific CI type related to the linux server. 

Aarti6
Mega Guru

You need to check few things like 'Containment Rules', CI Identifiers', and 'relationship'.

Mostly this error is found when the identification engine is processing dependent CIs in a payload and no hosting/containment rules are found for the CI.

In CI Class manager check "Dependent Relationships" to view the possible containment rules for the CI or you can even check in Meta editor

The payload passed to the identification engine will be a JSON with Items and relations

For each dependent CI, there should be a relation that contains the parent, child, and type. like {"parent":abc,"child":xyz,"type":"Runs on::Runs"}. Review the payload passed to the identification engine and confirm if the relation is present or not. You can check this in ECC Queue

Find the CI in the payload and its "index", and then look for the matching relationship. If payload does not have relationship, it will need to be added to the payload. If Payload has relationship; check if its present in cmdb_rel_type. Also check if there are any steps AFTER the step that creates the relationship which updates the dependant CI table. 

 

If this doesnt work, then problem is with identifier, try to modify the Identification rule for testing and then check. It should work.

Rahul Priyadars
Giga Sage
Giga Sage

Vinay Noel
Tera Contributor

@Rahul Priyadars @Aarti6 @Prabu Velayutha 

I checked the payload of the ecc queue , but could not find a matching relationship in the payload for cmdb_ci_disk.

The payload reference for cmdb_ci_disk is as seen below -

}, {&#13;
"referenceDirection" : "parentToChild",&#13;
"referenceField" : "disk",&#13;
"parent" : 10,&#13;
"child" : 13&#13;
}, {&#13;
"referenceDirection" : "parentToChild",&#13;
"referenceField" : "disk",&#13;
"parent" : 11,&#13;
"child" : 13&#13;
}, {&#13;
"referenceDirection" : "parentToChild",&#13;
"referenceField" : "disk",&#13;
"parent" : 10,&#13;
"child" : 4&#13;
}, {&#13;

 

 

Upon checking the relationships in the payload, I was not able to find a relation for any of the disks mentioned above with the same parent and child values (assuming that is the index)

 

The complete relations list in the payload is pasted below -

"relations" : [ {&#13;
"type" : "Uses::Used by",&#13;
"parent" : 0,&#13;
"child" : 12&#13;
}, {&#13;
"type" : "Provides::Provided by",&#13;
"parent" : 11,&#13;
"child" : 18&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 4&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 5&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 6&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 7&#13;
}, {&#13;
"type" : "Owns::Owned by",&#13;
"parent" : 0,&#13;
"child" : 17&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 18&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 19&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 20&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 13&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 14&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 15&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 16&#13;
}, {&#13;
"type" : "Provides::Provided by",&#13;
"parent" : 6,&#13;
"child" : 19&#13;
}, {&#13;
"type" : "Provides::Provided by",&#13;
"parent" : 7,&#13;
"child" : 20&#13;
}, {&#13;
"type" : "Uses::Used by",&#13;
"parent" : 0,&#13;
"child" : 9&#13;
}, {&#13;
"type" : "Uses::Used by",&#13;
"parent" : 0,&#13;
"child" : 3&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 10&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 11&#13;
}, {&#13;
"type" : "Contains::Contained by",&#13;
"parent" : 0,&#13;
"child" : 21&#13;
}, {&#13;
"type" : "Provides::Provided by",&#13;
"parent" : 15,&#13;
"child" : 19&#13;
}, {&#13;
"type" : "Provides::Provided by",&#13;
"parent" : 16,&#13;
"child" : 20&#13;
}, {&#13;
"type" : "Owns::Owned by",&#13;
"parent" : 0,&#13;
"child" : 8&#13;
}, {&#13;
"type" : "Owns::Owned by",&#13;
"parent" : 0,&#13;
"child" : 1&#13;
}, {&#13;
"type" : "Owns::Owned by",&#13;
"parent" : 0,&#13;
"child" : 2&#13;
} ],&#13;

 

 

I checked the Linux server pattern and OOTB, there is a step to create the relation between cmdb_ci_disk and linux server. But while trying debug with the errored linux server IP, the debug does not execute the relation creation step. Also checked if there are any update on cmdb_ci_disk table after the rel creation step. But none is there in the pattern.

As per the proposed solution in the above error, I looked into the containment rules and also created a rule from the Metadata editor and tested, But was not successful.(rule was created under Linux server for Disk with a contains::contained by relation)

 

Also tried creating an identifier for cmdb_ci_disk as per the error message recommendation but it did not work.

All these were done referring to the KB article https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0725816

 

The same pattern is working in another instance. I have compared the Linux pattern, containment rules for Linux server, the CI identifiers for disk and the dependent relationships as well as identification rules for Disk with both the instances.

Everything is same except there is one difference in the Dependent relationships for Disk class under CI class manager. Where in one instance(working), Contained by relationship exists between only Computer and Disk. But in other instance(error), OOTB contained by relation exists between Computer, Hardware and Disk.

 

Any suggestion is much appreciated