QOS with zabbix needed?

[netod]

Hi guys,

after some frustration with false positives, I would like to know whether any of you guys using zabbix also have quality of service to ensure that zabbix traffic is treated with high priority on the network. I'm finding that under heavy network load zabbix is not updating its data and hence creating alot of false positives.

Server version: 1.1.3
Agents: 1.1.3
Hosts: 13

[Alexei]

I believe that in 99% of cases a false positive is a "wrongly" (to some extent) formed trigger. Do not rely on triggers like:

{host:key.last(0)}=0

do something like

{host:key.max(60)}=0 or better {host:key.max(#3)}=0

This helps very much.

I do not think it is possible to set higher priority to ZABBIX traffic.

[Calimero]

Hi,

or better {host:key.max(#3)}=0

What does the "#n" syntax mean ?
n * <polling period> ?

Thanks.
Calimero

[Alexei]

No, it means number of polls.

[Calimero]

No, it means number of polls.

OK, thanks.

[netod]

I believe that in 99% of cases a false positive is a "wrongly" (to some extent) formed trigger. Do not rely on triggers like:

{host:key.last(0)}=0

do something like

{host:key.max(60)}=0 or better {host:key.max(#3)}=0

This helps very much.

I do not think it is possible to set higher priority to ZABBIX traffic.

I agree with what you are saying in terms of changing triggeres, I have changed some of the standard triggeres to something less prone to false positives. What about changing those in the distribution templates? So rather than {host:status.last(0)}=2 have {host:status.last(#3)}=2

I was thinking in terms of employing network based QOS, like on router or firewall which ensures that particular traffic gets higher priority. For example, with {host:key.last(#4)}=0 the timeframe for the trigger to activate may not be withing SLA. I was wanting to know of anyone else who has had this kind of requirement.

[Alexei]

I agree to your comment regarding default templates!