Dependent Host tags

Feedback Product Ideas
1

We often use two host tag groups to classify hosts more accurately. The 1st one is “system class”, the 2nd one is “system type”. In “system class” you will find tags like “Server, Router, Switch, Firewall” etc (more like an overall classification). In “system type” you then will find tags like “DNS Server, Domain Controller, …, Core Switch, Access Switch, …” (specializing the overall classification to more detail).
The problem is: At the moment the admin can configure a host with the tags “system class” → “Server” and “system type” → “Access Switch” - which obviously is nonsens. :slight_smile:
The idea: Introduce the (optional!) ability to make tag groups dependent from each other in the following way: Selecting an entry in the 1st one would lead to only a subset of entries in the 2nd one.
Example to clarify (based on the examples given above):
Selecting “Switch” from the “system class” tag group would lead to only have the following options available when choosing from the tag group “system type” when configuring a host: “Core Switch” or “Access Switch”.
IMHO the logic is not that complicated - but honestly I have no idea how to present the dependency creation options to the admin within the UI…
Maybe using of corresponding prefixes to the tag IDs in such dependent tag groups would be a very initial idea.

Best regards
Ralf from Germany, on a very rainy and cold day :frowning:

2

Nice proposal. Did you try to use aux tags? This would work somehow in the other direction, from bottom to top level.

Create aux tags for the level1 “super” tags:

  • aux-server
  • aux-router
  • aux-switch …

Then create “sub” tag groups for each of the aux tags and assign each tag the relevant aux tag, e.g. tag group “server”:

  • dnsserver => aux-server
  • domainctrl => aux-server
  • fileserver => aux-server

In this way you are getting the assignment to the level 1 super tags automatically.
Hope that helps!
/Simon

2 Likes
3

Hi Simon,
this would be an option. Only one tag group would be needed and the “super” tag would be automatically attached when choosing an entry here.
But there is another reason for us to use the two tag groups: Now we are able to define nice hierarchies within the virtual host tree snapin. Let’s imagine we have an additional tag group “location” then we can define a tree structure here like "Location–>“Super Class”–>“Sub Type”. Unfortunately you can’t use aux tags here.
The virtual host tree snapin IMHO is one of the best things to get an overview to all monitored systems, fully customizable to any point of view (if appropriate tag groups are defined) and then very helpful to find systems. May be it’s a little bit underrated, because it is not active by default.
In addition I’m currently unsure whether aux tags can be used within the UI in the same manner as tags when defining rules etc.
I have to admit that I never used aux tags until now…
May be a lack of skills. :slight_smile:

Best regards

Ralf