-
Change Request
-
Resolution: Unresolved
-
Trivial
-
None
-
None
-
None
-
None
Dear Zabbix Support Team,
I would like to suggest a new feature for Zabbix Server or Proxy configuration:
Blocking data from the distant future or past:
Would it be possible to add a configuration variable on the server or proxy side that filters data sent by the zabbix_agent2 (active) when the timestamp is in the future?
A reasonable default value could be set to ±14 hours (the maximum time zone difference globally). All other values seem to be incorrect and should not be accepted.
Justification:
If an active agent sends data with a timestamp far in the future (e.g., several years ahead), the data must be manually deleted from the database because the latest data display shows negative values for the last retrieval.
The biggest issue, however, arises with triggers that are time-sensitive, causing resolved states to flicker. By design, the problem will keep flickering for a period until the local time catches up with the future problem resolution time (in my case, this will happen only in 10 years).
As a result, I have a Problem item stuck with a "Resolved" status blinking - because the problem was "resolved" in the future. It looks like this will remain that way for the next 10+ years.
And problem desc. resolved time is in the future.
Deleting data directly from the Zabbix database is risky and, in my opinion, not a reasonable alternative.
Blocking data with a large time difference (e.g., the suggested 14 hours) from the future or the past would trigger a nodata() alert, indicating that the agent is not working and prompting the administrator to correct the time on the host (agent).
This issue affects only active agents since they send the timestamp themselves, while passive agents are unaffected.
The problem has been discussed on the forum:
Does Zabbix server have a way to block future-dated data?
Why server-side filtering is important:
Filtering future data on the database level using triggers results in increased SELECT query volume, as it requires time verification.
The filtering should be done on the server or proxy side. Ideally, the agent should log errors related to time desynchronization beyond the configured value.
Thank you for considering this feature request.