Share This:

A fairly common request is around how to discovery/model Locations. You may have seen there is a Location node in the taxonomy, that looks intriguing. You may have found you can add your own Locations in Administration -> Custom Categories -> Locations. And you may be confused as to how to make use of it.


So, the "location" of a discovered asset is quite a vague concept. You may be referring to rack, room, datacentre, country, continent, some kind of more abstract business categorisation, or some combination. Certainly, there is no standard way to discover this - so we make no attempt to create location information out of the box.


What we do provide is the Location node ready for use in the taxonomy, and relationships to link to other nodes, including:

  • Host node: Location:Location:ElementInLocation:Host
  • Network Device: Location:Location:ElementInLocation:NetworkDevice


In fact, you can have an arbitrary nesting of Locations, to model a complex hierarchy:

  • LocationContainer:LocationContainment:ContainedLocation:Location
  • ContainedLocation:LocationContainment:LocationContainer:Location


So, that's good - you have some tools to facilitate the model - but how do you populate it with something useful? You have to determine what Location means in your own business context, and what data there might be available to determine this. Then, you will need to write a custom pattern. Three methods that have been used are:


1) Hostname naming convention


If your organisation has a tightly defined naming convention, perhaps the first 3 letters of the hostname define a datacentre. In which case, you can use the built-in pattern template as a starting point, called "template_host_location". You will need to "fill in the gaps" as directed in the comments - most importantly the regex used to extract the location key, and the actually mapping from discovered data to your location names.


2) Build file


Perhaps you have a standard build file that is put somewhere on the filesystem by Sys Admins that contains some useful information for determining Location data. A custom pattern could grab the file with fileGet() and parse it.


3) Subnet information


You may wish to define your machine locations by what network subnet they are part of. This has the advantage that Subnet information is discovered out of the box. In order to use this, you can use my sample pattern, attached. Obviously, you will need to update the mapping from Subnet definitions to Location names. Note that one problem is what to do when multiple subnets are found for a Host. In my example, I just pick the first in the list returned from the datastore. I would be interested to know what you think should be done here. We could maintain a separate list of "management" subnets we ignore if we have a choice. Or link to more than one Location - but does it make sense? That's a modelling decision.


Naturally, there is nothing stopping your pattern using a combination of these - for example one part of the organisation may adhere to strict naming conventions, while some other division doesn't (so you'll have to fall back to subnet mapping).


Please comment if you have used a Location mapping in your environment - what method did you use? Did you do anything differently? What worked/did not work for you?


Join the Customer Support Community and give us feedback if our efforts in Communities are helpful, and how we can better serve you.@