Added a template to group, nothing happened

There are some conceptual things new Zabbix users sometimes misunderstand, and a popular one is about adding templates to groups.

Sometimes users expect that adding a template to the same group as hosts will make the template affect the hosts. It does not.

Groups in template properties

Adding templates to groups does not affect hosts

Host groups in Zabbix are used to organise hosts. We can filter various pages by host group, aggregate items work on host group level and permissions are assigned on host group level as well.

Similarly, groups are used to organise templates, not to affect the hosts that share the group with templates. Users can have their permissions on templates limited as well – maybe there are some templates most of the users should not see.

Why are the same groups used for hosts and templates? Most likely “because of historical reasons”. Hosts and templates are very, very similar in Zabbix – they are stored in the same database table and a lot of things like items, triggers, applications and other entities are handled in a very similar way as well. There is a feature request to change this and split the groups in “host groups” and “template groups”. If you believe that should be done, you can vote on the feature request ZBXNEXT-2592.

How do we make templates affect hosts?

But how does one make a template affect the hosts? The template should be linked to hosts. This can be done in the host properties:

Linking templates to a host
Linking templates to a host

We can either search for a template by name, or see all the available templates by clicking ‘Select’.

Some users believe that there should be an option to automatically link hosts in a group to any templates that are in the same group. If you agree with that, you can vote on ZBXNEXT-975. Of course, this conflicts with the previous feature request that calls for splitting host and template groups.

Remember – for now in Zabbix hosts must be linked to templates, adding them to the same group won’t do anything.

4 thoughts on “Added a template to group, nothing happened”

  1. I don’t see a conflict between ZBXNET-957 and ZBXNET-2592.

    If based solely on the problem report, 2592 is just about containerization of the templates. I think most experienced zabbix users probably already do this by creating host groups for their templates (which only contain templates, and never hosts) and groups for their hosts (which are never used for templates). The confusing point here is that the groups are the same class – hostgroups,so it IS possible to intermingle them. I’m hard pressed to think of a situation where I want to do this.

    ZBXNET-957 is about the ability to link a template (strictly speaking, the wording in the request is singular) to a host group, so that adding a host to the group will automatically cause that template to be linked. This level of automation is highly desirable, because it would reduce the number of configuration steps when adding a new host.

    I think the potential implementation problem with 957 is handling conflicts. We can’t add two items with the same key to a single host. For example, create an agent.ping item for a host, then try to create a second item with the agent.ping key and it fails. Now try creating two templates each with this key, and then try applying one template and then the other to this host. It will also fail, but seeing why it fails is a bit more cryptic. Now assume if you were to create two host groups, and link one of these templates to each (assuming the ability to link a template to a host group as requested). Now add the host to both groups. How is this conflict resolved? If it fails, how is the failure explained so that the user can easily understand why this fails? I like the idea, and definitely see the upside, but thus seems to be the problematic portion.

    1. Right, that’s a good point. The conflict I meant was looking at a simple, quick approach – if adding a template to a group (as it works now) would link the template to all hosts in that group, then splitting templates in their own groups would conflict with such a naive implementation. If the template-group linkage is implemented in a more proper way, there would indeed be no conflict.

      The error output would indeed be very important. With a single group it’s probably more or less doable. Check if template is to be linked in through group membership – if so, add the group name to the current message.

      It becomes much more entangled with the nested host group support Zabbix 3.2 partially implemented – https://www.zabbix.com/documentation/3.2/manual/introduction/whatsnew320#nested_representation_of_host_groups . While the feature is still not finished and there are functional changes expected in 3.2.1, I would assume that eventually group nesting would work for all the functionality, associated with groups. Having proper errors for that would be more complicated, as it would be important to denote both the group the template comes from, and the group host is explicitly added to.

      To give credit where due, Zabbix developers are paying more and more attention to proper and helpful error messages. When – and if – they get to this feature, there might even be a public specification that could help ironing out all kinds of potential pitfalls 🙂

  2. Excellent points. In view of that, I favor ZBXNEXT-2592, just from the standpoint of having less items to filter through if I’m looking at host groups. I just view this as containerization of the objects. Kind of a “put the templates into template groups, and the hosts into host groups, so that when I need to look for a specific template, I have less groups displayed”. I don’t think that it would really have a strong functional change. From an implementation standpoint, i would even say that ‘under the hood’ they could still be the same object type (i.e. they’d be in the same database table), just with a ‘template’ flag. This would allow for the group to be strictly template, strictly host, or mixed, which would allow for maximum backwards compatability.

Leave a Reply