View Full Version : using templates in beta5 - no triggers?
bbrendon
03-01-2006, 06:27
The main problem i've found so far, is that i can't seem to figure out a way to add tremplated triggers to a new host.
okay, so I'm adding a new host to zabbix using the gui...
I goto config -> hosts, enter the information. Although i don't think it matters if you fill this in, i did anyway ...for "use templates of this host", i enter a template that has items and triggers associated to it.
Then i see the host doesn't have any template items associated to it as expected so i link it to a template. Still nothing. Then I manully add the items from the template to the host. Unfortunately this only adds items, and not triggers.
Now, can someone tell me how to add triggers from a template to a host?
Briefly it works like this.
1. Create a host "template"
2. Link this host to one on many hosts (for example, "template_linux" and "template_mysql")
3. When you create a new host, use "template" in "Use templates of this hosts" to have both "template_linux" and "template_mysql" linked to the new host.
Do not use "template_linux" or "template_mysql" directly! They do not have anything linked. It just makes no sense.
bbrendon
04-01-2006, 20:43
I didn't figure that out, but thanks for the explanation. That did it!
[cc]smart
06-01-2006, 17:25
Hi.
I've got the same problem, but i don't understand a single word of the explanation.
1. Create a host "template"
Ok, fine. Anything specific ?
2. Link this host to one on many hosts (for example, "template_linux" and "template_mysql")
What is linking ?
I know copying triggers by "add items from template", but this is'nt the idea if i get it right. Is "linking" using templates ? If so, i don't see how you could select more than one template. What does "to one on many" mean then ?
3. When you create a new host, use "template" in "Use templates of this hosts" to have both "template_linux" and "template_mysql" linked to the new host.
Ok, advice understood in part one of sentence. Now this would say "link" equals to "use template" what get's me back to previous question. Linking to many ? How ?
Then, what is different when i use a second level emplate over a first level template ?
Sorry. But i really don't understand the meaning of the given combination of words.
It's a little obscure and not entirely intuitive (at least to me), and unfortunately the documentation hasn't caught up to the new functionality. I just figured this out the other day.
1. Create a new template in the "Hosts" screen. Put it in the templates group and set the status to "template". Do not add any items to this template.
2. From the drop-down menu at the upper-right, select "Hosts/templates Linkage". You should get an empty screen.
3. There will be a second row of menus to select a host. Select the template you just created.
4. In the middle of the page you'll see a box labeled "Template". Pick an existing template with real items, such as "Host.Unix", and click "add linkage". Optionally, add more templates in the same way.
5. Go back to the hosts screen (top-right menu).
6. Create a new host for a real machine. In the "use templates of this host" field, select the template you created in step 1.
The part that I found confusing was the multiple layers of templating required - first you create a template with the things you want to monitor, then you create another template that just links to that, and then you create a real host connected to that second template. You can't directly link a host to that first template, though you can copy all of its items to a host.
Maybe this could be simplified by defining some naming conventions or other organization for the different types of template....
mconigliaro
06-01-2006, 19:57
sterno, im a little bit confused by your post. all of my hosts are linked directly to templates with no problems (ie: i am not using the 'intermediate' templates that you speak of).
I suspect that it's really supposed to work as you describe. However, I've found that no changes I make to the linked template list on an existing host have any effect. It only seems to work when I create a new host. Oh well, maybe in the next beta....
[cc]smart
06-01-2006, 21:39
I have not actually started playing with it, by for now i'll try to use this thread to start a kind of pseudo wiki style documentation component. I'll call it
>>
Best practices: Configuring Hosts
Hosts are configured in a layered system.
The lowest is used to define sets of items (probes) and triggers.
The middle layers are link layers which contain groups and are used to combine 1 or more sets and/or 1 or more lower level groups.
The topmost layer defines actual hosts combining one or more groups.
sets
Sets are of type "template". The items and triggers to combine into a given set are best chosen to allow for optimized combination on the groups layer. The suggested sets are:
<<
Here, i want to spawn a discussion about this set. Since the default delivered templates are misleading in the concept of how to configure hosts correctly, they should be replaced by a set such as this. My suggestion is:
>>
set.os.basic.common
set.os.basic.linux
set.os.basic.windows
set.storage.scsi.sda
set.tamper.basic.linux
set.tamper.basic.windows
<<
etc., input welcome
>>
groups
Groups are of type "template". The suggested basic groups are:
group.linux.basic : set.os.basic.common, set.os.basic.linux, set.tamper.basic.linux
group.windows.basic : set.os.basic.common,set.os.basic. windows,set.tamper. basic.windows
hosts
Hosts should point to a single set and optionally only add specific private items and/or triggers.
Version 0.1
bbrendon
08-01-2006, 21:49
sterno, im a little bit confused by your post. all of my hosts are linked directly to templates with no problems (ie: i am not using the 'intermediate' templates that you speak of).
Basically when adding a NEW host, it needs to understand what template linkages to use to autmatically add items, triggers and linkages. Thats why you need to create a template with just linkages and not necessarily items or triggers associated to it. Then when you create a new host, it takes the template with assoicated linkages, adds the links AND adds the associated items/triggers to the new host you're creating.
Does that help?
[cc]smart
09-01-2006, 10:42
What i don't like with these "links" is that they aren't links. They are reminders to copy. In effect, when i change sth. in a template that has been "linked", except for additions, the changes aren't resembled on items (probes) already copied. Update: Seems to depend on what actually changed. Some things propagate, some don't.
A bug seems to be, that if you add another "set" to a link layer template ("group") after this link layer template as been added as a link to a host, the addition is not propagated to the host.
Another bug seems to be, that when you add an item (probe) to a set that has previously been linked by a linklayer template, this linklayer template is converted from a template into a monitored object and the item added to it. In contrast to this, triggers seem to work correctly.
TheFalken
10-01-2006, 19:42
smart']What i don't like with these "links" is that they aren't links. They are reminders to copy.
Very, and the fact that templates aren't really templates is one of the reason's I'm looking at alternatives to Cacti.
Templated things must be updated when the template (or links) are.
They ARE real templates! When you modify or delete an item or a trigger in a template, linked hosts get updated. You may have several templates linked to one host if you want even more control and flexibility.
bbrendon
10-01-2006, 21:17
Very, and the fact that templates aren't really templates is one of the reason's I'm looking at alternatives to Cacti.
Templated things must be updated when the template (or links) are.
You mean you're looking at Cacti as an alternative to zabbix? :)
Let me tell you, you can't win!! I've used cacti for a long time, and as much as i love it, I use cacti and zabbix. There are really cool features about both products. Long term, I think Zabbix has the capacity to win over Cacti, but I probably won't be Zabbix only till maybe 2.0...
I won't comment on the template thing. I just know there are still bugs in the template system, but it is improving. Zabbix 1.1 is still beta.
bbrendon
10-01-2006, 21:20
They ARE real templates! When you modify or delete an item or a trigger in a template, linked hosts get updated. You may have several templates linked to one host if you want even more control and flexibility.
One thing I did notice is that after creating a host, I would like to add say, the mysql application template. It doesn't seem possible to merge the new triggers and items from the mysql application template into an existing host with already linked templates.
But i can associate a template to an exisinting host and add items to the template and have them appear in the host.
Does this make sense? I'm assuming its in the fix list or I'm missing something.
TheFalken
10-01-2006, 21:34
You mean you're looking at Cacti as an alternative to zabbix? :)
Yeah, we currently use Cacti for the graphs and Mon (with an rrd-monitor script) for altering. I'd much prefer a single intergrate point-n-drool system. Nagios, for instance, still requires by-hand edits of text files to add a host.
I agree, a few(!) more months and Zabbix may be 'there'.
[cc]smart
11-01-2006, 09:00
They ARE real templates!
Pardon ? Then what are the differing IDs in between templates and hosts good for ?
When you modify or delete an item or a trigger in a template, linked hosts get updated.
Replace "get updated" with "should get updated" as i've seen it not happen, just was not in the mood to hunt down which cases they really are. In a situation where you emulate templates by trying to keep things in sync by repeating copyies you get into several problems:
- You must never forget to do these updates
- You must track which Objects really are based on a template, and which have been modified locally. Once they are meant to be real copies, you must remember to stop copying.
- All in all, complexity for the program will quickly become higher with copying than with real templates (given you use an API and not SQL directly from your clients).
You may have several templates linked to one host if you want even more control and flexibility.
Done that. And as described, there is another issue in that, which also is based on the copying principle. Which is if you add another template on a template used by a host, predefined objects in that template won't appear in the host. Which probably just means that again, copying was forgotten. If they were real templates, this kind of issues wouldn't arise at all.
Basically, see issue report earlier in the thread.
In effect, without actually checking the DB, i would tend to think based on the external indicators, there is no chance i believe you saying there are real templates at work. In effect, i should probably have a look at that stuff and help get it really done with templates, because in the core principle, collecting <values> instead of states from clients, evaluating them server side and have highly felxible actions and alerting are superior features of Zabbix that can be taken even further in comming evolution steps. So care should be taken that it's not the small things, that take it down despite that. I would really hate that.
Pardon ? Then what are the differing IDs in between templates and hosts good for ?
All right, what is real template then? I understand templates as something that is linked to host(s) and all changes made to a template are propagated to corresponding (linked) hosts. One ID or different IDs - this is up to implementation.
Replace "get updated" with "should get updated" as i've seen it not happen, just was not in the mood to hunt down which cases they really are.
If it does not happen, then it is a bug. I beleive that ZABBIX 1.1beta5 has it fixed.
In a situation where you emulate templates by trying to keep things in sync by repeating copyies you get into several problems:
- You must never forget to do these updates
What updates?
- You must track which Objects really are based on a template, and which have been modified locally. Once they are meant to be real copies, you must remember to stop copying.
I agree.
- All in all, complexity for the program will quickly become higher with copying than with real templates (given you use an API and not SQL directly from your clients).
Not quite true. I don't have to worry about templating when selecting data from DB, for example. I just select items, no extra logic involved.
Which is if you add another template on a template used by a host, predefined objects in that template won't appear in the host. Which probably just means that again, copying was forgotten. If they were real templates, this kind of issues wouldn't arise at all.
Basically, see issue report earlier in the thread.
Not implemented yet.
In effect, without actually checking the DB, i would tend to think based on the external indicators, there is no chance i believe you saying there are real templates at work.
I agree, but is it really necessary? If it is, a small modification to the GUI may help.
In general, I agree that current implementation of templates (even if everything works as expected) is not very straight forward. It is quite confusing.
Having said this, I do not see other way how this can be implemented nicely.
Suppose we have real (in your understanding) templates. What if we want to add a new host-specific item to a host (not template)? How this can be implemented? Can we use several real templates for one host? Please explain. I'm really interested!
[cc]smart
11-01-2006, 15:50
For a not so well thought answer during week (can take more time to look at it on weekend probably), from first sight i woul tend to suggest:
- introduction of a new DB object "itemset". Contains no more than "itemsetid" and "name"
- change table "items" so that "hostid" becomes "itemsetid"
- add a referencing only table "hostXitemset" to allow for association in between "hostids" and "itemsetids".
- change table "history" turning "itemid" column into a combined "hostiditemid" column.
now you can have
hosts:
ID,name
901,HostA
902,HostB
itemsets:
ID,name
101,os.basic.common
102,os.basic.unix
103,HostA
104,os.basic.windows
105,HostB
items:
ID,itemsetID,function
201,101,version[zabbix_agent]
202,101,system[uptime]
203,102,vfs.fs.inode[/,free]
204,103,vfs.fs.size[/only/i/have/this,free]
205,104,diskfree[c:]
206,105,diskfree[x:]
hostXitemset:
901,103
901,101
901,102
902,105
902,101
902,104
When you are parsing what items a host is to monitor, you take all entries in "hostXitemset" that have hostid matching and extract the itemsetids. Then you take all entries from "items" matching "itemsetid". You do not need an individual item of same function per host here. 901 and 902 can both use the same set 101.
In table "history" you use combined IDs (whatever they look like in mysql, but they should be there; otherwise 2 columns are needed for full id).
history:
ID,timestamp,value
901_201, xxx, 1
901_201, xxx+1, 1
History seems a bit starnge to me though, because it has no real ID, and to get things in right order you need to sort. Maybe this could be changed. If makes sense possibly like this:
history:
ID,hostID,itemID,prevID,nextID,timestamp,value
801,901,201,NIL,803,xxx,1
802,901,202,NIL,805,xxx,1h5m1s
803,901,201,801,804,xxx+1,1
804,901,201,803,NIL,xxx+2,1
805,901,202,802,806,xxx+60,1h6m1s
806,901,202,806,NIL,xxx+120,1h7m1s
This way, timestamp becomes simple data. You do not meed it to get sorted graphs or such. On the other hand, if timestamp is readable by mysql, you can let mysql do more work for you, ignoring "next" and "previous". You would find the first entry by searching for NIL in prev and the last for NIL in next.
Again, this is based on brief look on tables and what seems to me a short path from there not meant as a 1:1 implementation plan...
Then a general question by the side... What do you do with old data or old function when the function of an item is changed ?
One ID or different IDs - this is up to implementation.
But there is the actual difference that starts complexity. For as long as you have only one object/one ID, chnages propagate automatically for you.
Suppose we have real (in your understanding) templates. What if we want to add a new host-specific item to a host (not template)? How this can be implemented? Can we use several real templates for one host? Please explain. I'm really interested!
In this example i made this time, there would be no difference between template part and host part. Host part would only mean you reference it no more than once.
In fact it looks like current DB schema plus extra itemsetid in table "items".
What if we leave everything as it is now and add extra field "templateid" (itemsetid) to table "items"?
The GUI will also be updated to see what item belongs to what template. What do you think?
[cc]smart
11-01-2006, 16:40
In fact it looks like current DB schema plus extra itemsetid in table "items".
What if we leave everything as it is now and add extra field "templateid" (itemsetid) to table "items"?
In items "hostid" is removed and replaced by "itemsetid" in my example. This is no big difference in first lace, except that you do not save all the host related data with an itemset.
Th big difference is with the linking in hostXitemset. If you link to host directly from item, then any given item can not be related to more than one host.
In the example you see that itemset 101 is referenced by both hosts 901 and 902, thus items 201 and 202 are referenced by both hosts.
Since for that reason, data in "history" is no more unique to a given host if you reference itemid only, you need to reference both, itemid and hostid at the same time.
The GUI will also be updated to see what item belongs to what template. What do you think?
This you have already in your implementation. While you save both, templates and hosts in the same thing (which per se does not need to be a bad idea) you clearly see ownership of items, also by templates. The issue is, that items are copied from the template when "linked" to a host and become a new object. So from now on, if you want to imitate template behaviour, you'l have to think about when to and when not to update these copies. This is what tends to become a major headache.
smart']Th big difference is with the linking in hostXitemset. If you link to host directly from item, then any given item can not be related to more than one host.
In the example you see that itemset 101 is referenced by both hosts 901 and 902, thus items 201 and 202 are referenced by both hosts.
All right, I see.
smart']
This you have already in your implementation. While you save both, templates and hosts in the same thing (which per se does not need to be a bad idea) you clearly see ownership of items, also by templates. The issue is, that items are copied from the template when "linked" to a host and become a new object. So from now on, if you want to imitate template behaviour, you'l have to think about when to and when not to update these copies. This is what tends to become a major headache.No, I meant something different.
Suppose you have an item created by host-template linkage. Currently GUI does not provide any information about the linkage on the item level. I suggest GUI to provide this information:
Item | Key| Template
System uptime | system.uptime | -
Ping | agent.ping | Basic checks
So, having this GUI implemented, an user may see that item 'Ping' is actually item of the template 'Basic checks'. Even more, there must be a restriction to edit this item directly. If user wants to edit this item, he must:
1. Change item 'Ping' of template 'Basic checks', or
2. Unlink this item from the template (thus making it not related to the template) and then edit it as a normal item
I think such design will be very clear and understandable. What do you think?
[cc]smart
11-01-2006, 18:20
Suppose you have an item created by host-template linkage. Currently GUI does not provide any information about the linkage on the item level. I suggest GUI to provide this information:
Item | Key| Template
System uptime | system.uptime | -
Ping | agent.ping | Basic checks
So, having this GUI implemented, an user may see that item 'Ping' is actually item of the template 'Basic checks'. Even more, there must be a restriction to edit this item directly. If user wants to edit this item, he must:
1. Change item 'Ping' of template 'Basic checks', or
2. Unlink this item from the template (thus making it not related to the template) and then edit it as a normal item
I think such design will be very clear and understandable. What do you think?
Yes, showing that items are copies of a template, and per the idea under control of Zabbix in this case, is a good idea in the context of the current implementation. With respect to database design you don't need to change anything for this, since hostid is identical to templateid afaik. So you can check in the host referenced by the item if its flagged as being a template and react on that.
Er...
at least that's what i thought. I'm just looking at the DB again and now i see "host_templates". This one irritates me because i originally see no real need for this, since the effect in program seems more or less identical to what host does. What's "templateid" in there ?
In principle, it should still e valid to say that the data is there already and i guess the link should also exist already, because you seem to have the ability to identify template based items. Otherwise, no updates would have been possible yet for these when the template is changed.
Doing this, you'll still stick with the problem of updating all template referencing items.
About prohibiting the user to edit items in hosts directly, i don't think this is needed. If the user executes such a change, it would mean the item becomes a host-local item and for this item, the link to the template is removed.
I feel though, that in long term you will have an easier job maintaining Zabbix when you don't copy.
I need some time to think about the best implementation. Thanks for the useful discussion! Let me know if you have anything else to discuss :)
[cc]smart
12-01-2006, 07:17
Maybe, for the 1.x series of Zabbix you would go with adding a marker for templated items to the GUI and for 2.x you might look at new possibilities.
It's a little obscure and not entirely intuitive (at least to me), and unfortunately the documentation hasn't caught up to the new functionality. I just figured this out the other day.
1. Create a new template in the "Hosts" screen. Put it in the templates group and set the status to "template". Do not add any items to this template.
2. From the drop-down menu at the upper-right, select "Hosts/templates Linkage". You should get an empty screen.
3. There will be a second row of menus to select a host. Select the template you just created.
4. In the middle of the page you'll see a box labeled "Template". Pick an existing template with real items, such as "Host.Unix", and click "add linkage". Optionally, add more templates in the same way.
5. Go back to the hosts screen (top-right menu).
6. Create a new host for a real machine. In the "use templates of this host" field, select the template you created in step 1.
The part that I found confusing was the multiple layers of templating required - first you create a template with the things you want to monitor, then you create another template that just links to that, and then you create a real host connected to that second template. You can't directly link a host to that first template, though you can copy all of its items to a host.
Maybe this could be simplified by defining some naming conventions or other organization for the different types of template....
I would like to add an important issue. Following these directions on an already created host doesnt work. You actually have to follow these steps in order, at least for the template linkage part. If you already have a host, and you choose UPDATE. It will NOT work. I had to delete the host, re-create it with "use templates of this host", then the items will get populated. WHEW! What a headache.