Howdy,
Many of the triggers we use have some unfortunate behavioral side effects when the templates are first assigned to a host and when the server processes are starting after any kind of down time. While it's easy to control the behavior when assigning templates, by disabling actions first, this is not effective in the case of an unplanned restart of the services.
The worst offenders for these spurious notifications has been with our 'host alive' checks, which are ultimately based on 'nodata' for x minutes. Obviously, if the server process has been down for x minutes, then the nodata(x) is going to cause the trigger to go to a problem state.
Is there a relatively simple way to just have zabbix not process actions for some configurable time after the server processes start up?
While we have not, generally, had any problems with zabbix stability, the last hiccup caused about 4500 notifications to be sent out that shouldn't have been.
Many of the triggers we use have some unfortunate behavioral side effects when the templates are first assigned to a host and when the server processes are starting after any kind of down time. While it's easy to control the behavior when assigning templates, by disabling actions first, this is not effective in the case of an unplanned restart of the services.
The worst offenders for these spurious notifications has been with our 'host alive' checks, which are ultimately based on 'nodata' for x minutes. Obviously, if the server process has been down for x minutes, then the nodata(x) is going to cause the trigger to go to a problem state.
Is there a relatively simple way to just have zabbix not process actions for some configurable time after the server processes start up?
While we have not, generally, had any problems with zabbix stability, the last hiccup caused about 4500 notifications to be sent out that shouldn't have been.
) there is a logic where it will not fire nodata triggers if zabbix server has been up less than the nodata period - if you see such triggers firing after the server restart anyway, it might be that the items indeed do not provide data for some reason (like proxies having large queues etc).
Comment