1.8 Macro and generic template

[alixen]

Hi,

I would like to create a generic template to monitor a network interface where interface name is a macro.

In Template_generic_if, I define a macro:
{$NETIF} => eth0
and several items:
input = net.if.in[{$NETIF},bytes]
output = net.if.out[{$NETIF},bytes]
and triggers, graphs,...

I can then link it to a host.
If network interface name is different, I can just redefine it at host level with:
{$NETIF} => br0

So far so good.
However, if there are several interfaces in my host, I cannot link it several times to the same template.

I have tried to define a new template Template_if_eth1 linked to Template_generic_if that defines:
{$NETIF} => eth1

I can link my host to either Template_generic_if or Template_if_eth1 but not both.
I get error message:

Template with item key [net.if.in[{$NETIF},bytes]] already linked to the host

Am I trying to do something impossible or I am missing something ?

Regards,
Alixen

[richlv]

ergh, misunderstood a bit.
i'd suggest using single template with multiple network interfaces, then disabling/enabling them in lower templates or hosts.
to work with multiple interfaces use something like {$NETIF1}, {$NETIF2} etc

[jakub]

I have the same problem when I need to use a generic template that will have about 20 items but the port number would be parametrized to support multiple components on the same host. We have more that 20 components - that would mean that I would have to multiply each item 20 times.

This simply does not scale.

[Gerard]

Hello,

i agree, this does not scale.

Template inheritance are ok but macros are almost useless in this scope.

Simple having a basic probe "net.if.in[{$ETHX}, errors]" in a base template, plus two templates for eth0 and eth1, with just a simple macro override.

Eth0 template is added to a host.

Adding eth1 to the same host result in :
Template with item key [net.if.in[{$ETHX}, errors]] already linked to host
Template with application [App.Network] already linked to host

Zabbix Server v1.8.2 (revision 11211) (29 March 2010)
Compilation time: Jan 14 2011 23:27:07

This is for network, but the same problem applies for Disks, Jmx (port...) and various items

Do you plan to add correct support for templates/macro inheritance in near future ?

Thank you

[richlv]

zabbix 2.0 will add low level discovery, which will be supported for network interfaces & mounted filesystems out of the box.

http://www.zabbix.com/documentation/...evel_discovery

it's already available in trunk for those who would like to play with it

[Gerard]

Hello,

thank you for answering.

I read about auto discovering, but i do not think this will solve this issue for other kind of probes.

I am thinking to JMX probes templates for example, where only the target port is changing.

If you have several JVM running on the same host, you cannot use Macro system, and you have to export/edit/reimport the whole template just to modify a single port.

Thank you.

[richlv]

If you have several JVM running on the same host, you cannot use Macro system, and you have to export/edit/reimport the whole template just to modify a single port.

hmm, indeed. wouldn't you also run into the problem of item keys clashing between jvm instances ?

[silvavlis]

I created a template for monitoring a HDs using SMART, the name of the HD is a macro.

This is fine for one HD, for two I could do a couple of item and trigger clones and done. If one server has ony one HD, then I disable the items and triggers corresponding to the 2nd HD and done.

Ups, I got a server with 8 HDs! Well, then I will need a bunch of item and trigger clones, but I will survive it... But, wait I'll have to disable those new items and triggers for all those servers having less HDs.

Or I create separate templates depending on the number of HDs, but they would be independent and some changes would be required on every diffetent template...

I think that it's ovious that the present implementation doesn't scale

[richlv]

I think that it's ovious that the present implementation doesn't scale

your use case would be solved in 2.0 with low level discovery
http://www.zabbix.com/documentation/...evel_discovery

[silvavlis]

Thank you for your quick answer, richlv!

Good to know that it's gonna get resolved. Basically because Zabbix is an amazing piece of software and with that feature it would become gorgeous

[richlv]

by the way, you can test the trunk or nightly builds of the 1.9 branch and see all the nice improvements yourself