Using name as the only CI identifier when running Discovery

[jeff_foltz]

We have been using discovery for some time, but it has been a modified version with discovery running in a sub-production instance and some of the data being sent to the production instance on a nightly basis.   Anything else is updated/inserted by the asset team.   We are looking to use discovery out of the box in production.   We have been testing with our data from production in a separate instance, but the data being returned from discovery does not match the data in the cmdb (cmdb data may have a name different, serial number is missing, class is wrong, etc...).   This is causing duplicate records.   The CI identifiers we have been using matches on serial number and class or name and class.   I have modified the cmdb data to match the serial number, name and class, re-ran discovery, and discovery updates the record instead of inserting one.   The asset team wants to only use name as an the identifier as it feels it will cause less duplicates.   I know there is a problem of CI's being reclassified when you use only one identifier without checking sys_class_name.   What other consequences are there with this approach?  

[Dave Ainsworth]

Hi Jeff,

if you use sys_class_name in every identifier entry, it will "lock" CIs in the class because it will reduce the scope of the identifier to only match where the class is the same. So if, for example a hardware asset is created that then creates a CI in the server table, if discovery then discovers it is as a Windows server CI with the same serial number and/or name, I think it will create a duplicate and not move it to the correct class.

The OOTB identifiers for hardware don't have class name in the identifier so in the example above, the server would be moved to Windows server. Similarly, if a Linux server is repurposed as a Windows server, it can change the class of the CI. This is assuming you only have the hardware identifier and don't have identifiers at the server level which can further reduce scope of identification.

The problem with just using name is that as you say, sometimes they don't match and you are relying on someone never changing the names of CIs and that the name is unique across all classes on the network. But it can be a good fallback if other rules fail when, for example, a hardware asset is added without a serial number but the name matches what discovery finds.

I would first start with the OOTB identifier entries for hardware if possible and then tweak where necessary. I have never tried it but for example, it might be possible to have two entries with name - the first including sys_class_name so it looks for CIs with the same name in the same class and then name in any hardware class as a final fallback so that server can be moved to Windows server etc.

There is a good blog post on identifiers which might give you some ideas of how you could tweak things:

Discover multiple CIs with the same serial number - Part II

Regards,

Dave

[jeff_foltz]

Dave,

Thank you for the response and the link to the blog post.   I went ahead activated the OOTB identifiers for serial number and name only (Generic Serial Number and Generic Name) even though there are warnings about reclassification problems in the code.   Even though I think its short sighted due to the the potential for problems down the road, there is a lot of pressure to do this by the team.   I left the identifiers at the higher order so the ones that check class as well will run first.   Hopefully that will keep the number of ci's with the same serial number or same name from being overwritten down to a minimum.   If there is any other issues that could creep up by doing this, I really want to know.

[Dave Ainsworth]

Hi Jeff,

The OOTB identifiers generally work quite well but every environment is different. Where there can be challenges is with some virtual devices such as virtual F5s and Nexus 7k switches which can have virtual switches (VDCs) which can be a problem for the identifiers which only use serial number. For example, the virtual F5s report the serial number of the host and so they all get identified as one device. A combination of name and serial number (which I think you are using) should work for these devices though.

Regards,

Dave

[tsankett]

Hi Jeff,

I have encounter with an issue for the CI identifiers, we are running the discovery for the Servers, and for some CI's its name is same and IP address are different. But because of the hardware identifier rule, CI is not created for each device, rather it is updated.

So to resolve this I have created a separate CI identifier on the windows server. But after creating the CI identifier. Discovery is not running successfully.

I have encountered below error.

2018-09-26 19:33:54: Relation and/or reference table discovery_net_arp_table is not a known CI Type. Check the discovery logs for more details.

2018-09-26 07:03:59: Identification Engine: Discovery status is FAILURE, unable to get error message.

Could you please guide me on this.
After creating new CI identifier, discovery is failed.
Am i missing some step here.

Thanks
Sanket