no {HOSTNAME} in overview display

[kberrien]

In the web UI, when viewing the Overview option v1.1.6.

Each trigger name shows the {HOSTNAME}. So, you'll see

Database server offline {HOSTNAME}
SSH server is down on {HOSTNAME}
etc..

{HOSTNAME} is a variable, which isn't used in this display (the hostnames are to the right), so displaying {HOSTNAME} should be suppressed in this instance.. It makes it very hard to read the various triggers with the variable tacked on the end...

[Vince2]

In the web UI, when viewing the Overview option v1.1.6.

Each trigger name shows the {HOSTNAME}. So, you'll see

Database server offline {HOSTNAME}
SSH server is down on {HOSTNAME}
etc..

{HOSTNAME} is a variable, which isn't used in this display (the hostnames are to the right), so displaying {HOSTNAME} should be suppressed in this instance.. It makes it very hard to read the various triggers with the variable tacked on the end...

Hi use the following "patch" for include/triggers.inc.php :

                $table->SetHeader($header,'vertical_header');

                foreach($triggers as $descr => $trhosts)
                {
+                  // Delete {HOSTNAME}
+                  $descr = preg_replace("/\W(on|sur|de|pour|for|with)\W{HOSTNAME}/","",$descr);
                        $table_row = array(nbsp($descr));
                        $row_empty = TRUE;
                        foreach($hosts as $hostname)
                        {

This is a pseudo patch, apply it by hand.

[surftimer]

no hostname in e-mail

Hello

I have the same problem with the e-mail send to the admins

this is what I get in the body of the mail

"Too many processes running on {HOSTNAME}: ON "

I am working with the latest beta 1.3.5 and tried to use the patch above , but this didn´t solve it

thank you in advance for any help

Michael

[Vince2]

Hello

I have the same problem with the e-mail send to the admins

this is what I get in the body of the mail

"Too many processes running on {HOSTNAME}: ON "

I am working with the latest beta 1.3.5 and tried to use the patch above , but this didn´t solve it

thank you in advance for any help

Michael

You can try the following patch :

Index: /src/zabbix_server/expression.c
===================================================================
--- /src/zabbix_server/expression.c (revision 1)
+++ /src/zabbix_server/expression.c (revision 29)
@@ -1068,4 +1068,5 @@
 
 			replace_to = zbx_dsprintf(replace_to, "%s", trigger->comments);
+			substitute_simple_macros(alarmid, trigger, action, &replace_to, MACRO_TYPE_TRIGGER_DESCRIPTION);
 		}
 		else if(macro_type & (MACRO_TYPE_MESSAGE_SUBJECT | MACRO_TYPE_MESSAGE_BODY) &&

However, this is for Zabbix 1.1.7. This part of code may have changed in Zabbix 1.3 series. And since the problem is in zabbix_server, you have to recompile it.

[Farzad FARID]

You can try the following patch :

[...]
However, this is for Zabbix 1.1.7. This part of code may have changed in Zabbix 1.3 series. And since the problem is in zabbix_server, you have to recompile it.

Hi,

Thanks for the patch, I adapted it for Zabbix 1.3.6 and posted it on the "Zabbix patches" forum: http://www.zabbix.com/forum/showthread.php?t=5933

Regards

[kberrien]

hum....

Hi use the following "patch" for include/triggers.inc.php :

                $table->SetHeader($header,'vertical_header');

                foreach($triggers as $descr => $trhosts)
                {
+                  // Delete {HOSTNAME}
+                  $descr = preg_replace("/\W(on|sur|de|pour|for|with)\W{HOSTNAME}/","",$descr);
                        $table_row = array(nbsp($descr));
                        $row_empty = TRUE;
                        foreach($hosts as $hostname)
                        {

This is a pseudo patch, apply it by hand.

I gave this a try, without success, still see {HOSTNAME}. Granted I'm doing this on v1.1.7, but I figure the code didn't change in this area. Also, I believe you meant to add (+) the $row_empty=True;

This is ok, we can live with this. Just a suggestion for future versions. Kinda of redundant to have the hostname variable there....

[Andreas Bollhalder]

Completly remove {HOSTNAME} in trigger

I vote for removing the {HOSTNAME} macro completly from the trigger names. The reason is, that the {HOSTNAME} macro eats up space in the overview, maps etc. In the maps, it would double the information as normally, the hostname is already given there (at least at my setup).

Instead, the hostname should be added to the dependecies in "triggers.php" and the other places where needed.

For example I would define the two triggers "Port SSH is not reachable" and "Service OpenSSH is not running" in the template "template1". This template would be used by the host "host1".

In the trigger view of the template it should be like:

1. "template1:Service OpenSSH is not running"

2. "template1:Port SSH is not reachable" depends on "template1:Service OpenSSH is not running"

In the trigger view of the host implementing the template it should be the same:

3. "template1:Service OpenSSH is not running"

4. "template1:Port SSH is not reachable" depends on "template1:Service OpenSSH is not running"

It must be sure that "template1" is both substituted with "host1" in the calculation.

Are there any better ideas ?

Sincerly Andreas

[Vince2]

I vote for removing the {HOSTNAME} macro completly from the trigger names. The reason is, that the {HOSTNAME} macro eats up space in the overview, maps etc. In the maps, it would double the information as normally, the hostname is already given there (at least at my setup).

This is not true for maps. If you include a map in a map, the information is important. If you use a group of hosts, the information is important.

[Andreas Bollhalder]

This is not true for maps. If you include a map in a map, the information is important. If you use a group of hosts, the information is important.

Ok. In this case, the hostname should be added automtically by ZABBIX. In the other cases, it would be still nice without it.

Or the question is:
Should the trigger name contain the hostname and it would be ripped off where applicable (there are partially patches for this) or should the hostname be added by ZABBIX where needed ?

Andreas

[Vince2]

Should the trigger name contain the hostname and it would be ripped off where applicable (there are partially patches for this) or should the hostname be added by ZABBIX where needed ?

It seems that the trend is to add the hostname when needed. This has been done for triggers status for examples (hostname is added if several hosts match the filter).

[Alexei]

Honestly I do not know what is the best solution here. If course, anyone is free to change default templates, yet I would like to hear if the default templates shipped with standard ZABBIX should contain the {HOSTNAME}.

[Andreas Bollhalder]

Hello Alexei

Honestly I do not know what is the best solution here. If course, anyone is free to change default templates, yet I would like to hear if the default templates shipped with standard ZABBIX should contain the {HOSTNAME}.

At the current state, I believe it's ok to include the {HOSTNAME} in the templates as it is.

For a version 1.4.1, it would be still nice. To savely omit the {HOSTNAME} in the trigger name, I think you have to make sure, that all places where the hostname is needed has it added (as Vince2 pointed out like a map in a map or a host group and in the dependency).

Better to keep the bits now for releasing 1.4.0. Thanks a lot for your effort making ZABBIX. I really apreciate it.

Andreas

[surftimer]

it worked in 1.3.8 too

You can try the following patch :

Index: /src/zabbix_server/expression.c
===================================================================
--- /src/zabbix_server/expression.c (revision 1)
+++ /src/zabbix_server/expression.c (revision 29)
@@ -1068,4 +1068,5 @@
 
 			replace_to = zbx_dsprintf(replace_to, "%s", trigger->comments);
+			substitute_simple_macros(alarmid, trigger, action, &replace_to, MACRO_TYPE_TRIGGER_DESCRIPTION);
 		}
 		else if(macro_type & (MACRO_TYPE_MESSAGE_SUBJECT | MACRO_TYPE_MESSAGE_BODY) &&

However, this is for Zabbix 1.1.7. This part of code may have changed in Zabbix 1.3 series. And since the problem is in zabbix_server, you have to recompile it.

Hi Vince2

Thank you , it worked with 1.3.8 too , after I applied the patch and recompiled it , it is working like a charm

thank you again for your help

Michael