As I work more with templates, and the final release, I have come to realize a minor design flaw. A template is great, it allows us to add common items across the board to all hosts. For example, I have a base template called "Host.base" with icmpping, and icmppingsec as default items. These also have triggers attached to them. This is a good start. Creating hosts, and other templates on top inherits these options, which is also great. The issue starts to come about when displaying the data from these templates.
Using the icmpping and icmppingsec as example, say I have 10 hosts, each has the same template and inherits these options. They also inherit the triggers, in this example we'll call the trigger "Ping Warning" and set the value to say:
This is what I'd consider a fairly obvious use of templates... right? Okay, now the basics are cleaered up, we now have 3 hosts that have an average ping time (for the last 5 mins) greater than 0.6 seconds. This will change the trigger to "ON" for those 3 hosts. Lets take a look at the trigger page. 3 items, as expected. The problem is, what hosts do those items apply to? The only way I can figure out the host that these templates apply to is by clicking on the "show details". I'd imagine that'd be fairly easily fixed by adding a "Hosts" column on that page. This does seem to be covered in part by the "overview" page when it is set to "Triggers", however having 100 hosts on the overview page is a little difficult, and splitting it into groups doesn't help a great deal.
Now lets look at issue 2. Using Nagios as a sample, it has an option called "parent host". This allows you to "map" a network layout by specifying a parent to the host you are checking. This is handy for 2 reasons; the diagram Nagios creates automatically (not at issue here but a very handy feature), and tracking problems. For example, you have a router go down, and hosts on the other side of the router are not checked until the router comes back up, and any notifications relating to those hosts is not sent out. I'm guessing this can be emulated by using the "Dependancy" option on triggers. So create a new trigger, and drop down the dependency list. Using the original example of 10 hosts, with the "Ping Warning" triggers, you'll see 10 "Ping Warning" items, with no hint as to which one belongs to which host. This could probably be remedied by using a simple [hostname] value as part of the list.
Just my little input. Oh, and thanks for fixing the issue with macro's in item names ($1 for example).
Using the icmpping and icmppingsec as example, say I have 10 hosts, each has the same template and inherits these options. They also inherit the triggers, in this example we'll call the trigger "Ping Warning" and set the value to say:
{Host.base:icmppingsec.avg(300)}>0.6
This is what I'd consider a fairly obvious use of templates... right? Okay, now the basics are cleaered up, we now have 3 hosts that have an average ping time (for the last 5 mins) greater than 0.6 seconds. This will change the trigger to "ON" for those 3 hosts. Lets take a look at the trigger page. 3 items, as expected. The problem is, what hosts do those items apply to? The only way I can figure out the host that these templates apply to is by clicking on the "show details". I'd imagine that'd be fairly easily fixed by adding a "Hosts" column on that page. This does seem to be covered in part by the "overview" page when it is set to "Triggers", however having 100 hosts on the overview page is a little difficult, and splitting it into groups doesn't help a great deal.
Now lets look at issue 2. Using Nagios as a sample, it has an option called "parent host". This allows you to "map" a network layout by specifying a parent to the host you are checking. This is handy for 2 reasons; the diagram Nagios creates automatically (not at issue here but a very handy feature), and tracking problems. For example, you have a router go down, and hosts on the other side of the router are not checked until the router comes back up, and any notifications relating to those hosts is not sent out. I'm guessing this can be emulated by using the "Dependancy" option on triggers. So create a new trigger, and drop down the dependency list. Using the original example of 10 hosts, with the "Ping Warning" triggers, you'll see 10 "Ping Warning" items, with no hint as to which one belongs to which host. This could probably be remedied by using a simple [hostname] value as part of the list.
Just my little input. Oh, and thanks for fixing the issue with macro's in item names ($1 for example).
Comment