Unix Timestamp not returning acurate polling time

[dratliff]

Hello,

I have been working on writing data to the trends table manually and I have come across a rather interesting issue, maybe a bug, but I think just a system load issue.

The timestamp that zabbix writes is a unix_timestamp integer. When trying to get the zero-hour value I have noticed that zabbix will sometimes not write the exact zero-hour time. EX: 013:00:00 can sometimes be 13:00:32 when the last polling took place at 12:59:30.

The question is this (naively): Is this a system load issue or is there a problem with zabbix? The system is only a test system with about 10 hosts and no other systems running on it. It only runs apache, mysql and zabbix. It is a fedora core 6 linux os.

Any insight would be greatly appreciated.

Thank you,

Dave

[Alexei]

If ZABBIX server is trying to get a value from a ZABBIX agent, and the agent spends two seconds before providing the data, what timestamp do you expect to see?

How did you try to get a zero-hour value, by the way?

[dratliff]

The timestamp is server based and not client based, correct? I can understand where the delay would come from. That would also explain the num field in the trends table not being the same count for every entry. That is expected because of the ability of zabbix to function as a loosely coupled system. Have you considered pulling the timestamp from the client and sending that in the data packet?

I have calculated the zero-hour using: <clock value> mod 3600 = 0 for the previous or current hour. Is that what you have used? I haven't gone thru the code to determine this. I have tried using the min(clock) for the hour and that works also. I just thought using a mod command was cooler.

Thank you,

Dave.