We use the "fuzzytime" function generate an alert if the time of a monitored server has drifted. It compares the time reported by the host to the time on the Zabbix server AT THE TIME TRIGGERS ARE PROCESSED.
Is should use, or at least allow as a parameter, the TIME THE ITEM WAS COLLECTED, which is known and stored, but not used by fuzzytime.
The current method introduces a delay, which mean that we have to use a large fuzzytime delta to allow for the delay between collection and processing. We should be able to test for small amounts of time drift, the current behavior of fuzzytime doesn't allow that.
The current method also causes false alerts if the Zabbix server crashes after collecting the time but before processing the trigger. We're monitoring time on several hundred servers, and I've had several crashes recently while trying to find a workaround for the bug in ODBC database monitoring. Those crashes generated some false alerts.
Thanks,
Kevin
Is should use, or at least allow as a parameter, the TIME THE ITEM WAS COLLECTED, which is known and stored, but not used by fuzzytime.
The current method introduces a delay, which mean that we have to use a large fuzzytime delta to allow for the delay between collection and processing. We should be able to test for small amounts of time drift, the current behavior of fuzzytime doesn't allow that.
The current method also causes false alerts if the Zabbix server crashes after collecting the time but before processing the trigger. We're monitoring time on several hundred servers, and I've had several crashes recently while trying to find a workaround for the bug in ODBC database monitoring. Those crashes generated some false alerts.
Thanks,
Kevin
Comment