Zabbix 2.4

Worth to add that in that particular case discovery rule was a zabbix trapper type and a value for it was completely generated by a custom script.
clock in data packed and/or for the value was 1000 times bigger than current unix time stamp (sort of with milliseconds) or it was 0.

I was not able to reproduce that case sending different combinations of clock.
We discussed with dotneft that reproducibility may depend on OS of running zabbix server.

In my opinion the origin of a problem is that Received clock can be virtually anything.

Of course, we can change the logic and use valid time stamp Now instead of possibly invalid Received clock to calculate a valid ts_delete. But this will result in recalculation of ts_delete with subsequent database update every time discovery rule is processed (now we update ts_delete only if user changes Keep lost resources period (in days)).

My suggestion is to validate Received clock stricter. At least we may want to assure that Received clock is a) valid numeric value, b) not negative, c) does not overflow int type we use in zbx_timestamp_t, d) does not correspond to a time moment from (distant) future. All trapper items will benefit from this solution, not just discovery rules.

Currently we use standard atoi() function to convert Received clock strings to int. This function does not check for any kind of error. Just to illustrate how bad it is for parsing raw user input... The following code will print "0".

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
	printf("%d\n", atoi("UNIX timestamp"));
	return 0;
}

We discussed that with Glebs and I totally support him.
For example using a custom script sender.pl I sent data as zabbix sender and active agent:

 10207:20151204:161054.482 trapper got '{"request":"agent data","data":[{"host":"it0","key":"test.item","value":"aaa","clock":1448397798123}],"clock":1448397798}'
...
 10214:20151204:161056.767 query [txnlev:1] [insert into history_text (id,itemid,clock,ns,value) values (3,30998,994659827,0,'aaa');]
 10214:20151204:161056.767 In zbx_vc_add_value() itemid:30998 value_type:4 timestamp:994659827.0
 10214:20151204:161056.767 End of zbx_vc_add_value():SUCCEED

...
 10207:20151204:180353.953 trapper got '{"request":"sender data","data":[{"host":"it0","key":"test.item","value":"aaa","clock":1448397798123}],"clock":1448397798}'
...
 10214:20151204:180354.744 query [txnlev:1] [insert into history_text (id,itemid,clock,ns,value) values (4,30998,994666606,0,'aaa');]
 10214:20151204:180354.745 In zbx_vc_add_value() itemid:30998 value_type:4 timestamp:994666606.0
 10214:20151204:180354.745 End of zbx_vc_add_value():SUCCEED

note how 1448397798123 becomes 994666606 which can be seen as 2001-07-09 11:16:46 on latest data in "500 latest values" mode.

Note also influence on a value cache - it remind me a nasty issue I've faced recently on a zabbix installation when many zabbix active agents every morning sent values from the far past (2000 year) after reboot.
Those values driven value cache crazy (triggers fetched history for big periods to value cache - it switches to low memory mode very fast). After discussion with wiper we decided that there is nothing to improve in zabbix, such wrong data must not come to zabbix!

So I support to discard values with wrong clock, as suggested by Glebs.
Item could became unsupported with a error message that received clock is wrong.

Where does 994666606 come from?

994666606 = (1448397798123 mod 2^32) + (Friday, 04-Dec-15 16:03:53 UTC - 1448397798) or generally speaking

Time stamp of the item saved in DB = (Received time stamp of the item mod 2^32) + (Time when server received data - Received time stamp of JSON)

Available in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-3055 revision 57029.

Zabbix server will now ignore received discovery item clock and use its own current time to decide when lost resources should be deleted.

It was decided not to do time stamp validation in this task. But I still believe it's a right thing to do, so let it be ZBXNEXT-3066 then!

(1) we should still use the item's timestamp for intenal event generation (if rule became supported).

glebs.ivanovskis Seems logical, users should be able to match event time stamp with time stamp of the item value that caused it. RESOLVED in r57117.

wiper If we don't need nanoseconds it would be better to use time(NULL) to get current clock.
REOPENED

glebs.ivanovskis That's right. RESOLVED in r57126.

wiper CLOSED

Successfully tested

Available in pre-3.0.0alpha5 (trunk) r57168.

Documented in Upgrade notes

sasha CLOSED