Zabbix Notifications

[terrydlm]

Hi All,

I have a main Zabbix Server which has a few Zabbix Proxy Servers reporting to it.

The Zabbix Proxy Servers are sitting at customer sites monitoring their systems and reporting back to us when they have a problem. We then have specific staff who deal with these messages depending on the customer 24/7.

The problem is that when the Zabbix Proxy generates a Zabbix system related message such as Zabbix sender busy or Zabbix Queue has exceeded x jobs etc. (Not sure of the exact wording) this obviously gets sent to the staff member 24/7.

As the Zabbix admin I am the only one who needs to know about these messages (not nessecarily at stupid o'clock in the morning) so that I can fix any potential issues.

Is there a way to separate these messages? i.e. I get the Zabbix sender busy etc. & the staff member gets the server is not responding to ICMP requests or HTTP not responding etc.

I have tried using conditions but these don;t seem to work on Zabbix system messages.

Any help would be gratefully received.

Terry

[Parasin]

You need to create separate actions to handle these types of events.

For example, create one action that sends messages for triggers that are not related to the Zabbix Proxy / Server performance (things like queue size or internal data gathering %, etc). Then, create another action that sends Zabbix Administrators (such as yourself), a message when the queue size is too large or whatever other Zabbix performance related trigger that can be thrown.

The easiest way to filter who gets what types of messages is to put all of your Zabbix Servers/Proxies in a host group, then configure the relevant action with the condition: Host Group = Zabbix Servers/Proxies, and to send only to the Zabbix System Administrators.

Alternatively, for the action that goes to your support team you could use the condition: "Trigger Not like Zabbix Queue is too Large" or whatever your trigger is named. This will give you the expected result.

[terrydlm]

HI Parasin,

Thanks fro your reply. I will give this a go tomorrow when I get to work.

I currently have all the proxies and hosts in hostgroups and everything works fine.

I have a hostgroup called i.e. customer A and customer B etc. And in each one of these I have proxy A and proxy B etc.

Today I created a new host group called zabbix proxies and I took all the proxies out of their customer host groups and put them all in the zabbix proxies host groups. The problem was that all the hosts still seemed to be being monitored BUT the zabbix proxies seemed to loose connection. As soon as I put the proxies back into the customer hostgroup they started to work again. I can't think why this should happen.

This would be the easiest way to solve my problem.

Is this behaviour what you would expect?

You need to create separate actions to handle these types of events.

For example, create one action that sends messages for triggers that are not related to the Zabbix Proxy / Server performance (things like queue size or internal data gathering %, etc). Then, create another action that sends Zabbix Administrators (such as yourself), a message when the queue size is too large or whatever other Zabbix performance related trigger that can be thrown.

The easiest way to filter who gets what types of messages is to put all of your Zabbix Servers/Proxies in a host group, then configure the relevant action with the condition: Host Group = Zabbix Servers/Proxies, and to send only to the Zabbix System Administrators.

Alternatively, for the action that goes to your support team you could use the condition: "Trigger Not like Zabbix Queue is too Large" or whatever your trigger is named. This will give you the expected result.

[terrydlm]

Hi Parasin,

OK I have moved the proxies to the proxy servers hostgroup. I think I also removed the proxies from the proxy hosts group which I shouldn't have done.

I will test this tomorrow as I don't want to start sending out unnecessary notifications now but its looking good at the moment.

[Parasin]

You can have the Proxies and Servers in more than one host group, that is the approach that I would take.

The point of the other host group is just to be utilized for the actions that are sent out the the respective user groups.