Last Report Date is client date, not date report was received.
The "last report" date should be the time the most recent report arrived at the server, regardless of any client-side embedded dates. This allows event correlation even in the face of client clock drift. (In a perfect world, the clocks would all stay in lockstep. Unfortunately, this isn't a perfect world and ntpd will bail when the drift is too high - exactly when it is needed most.)
For example, when 10 hosts fail you can go back and say "oh. they all failed at 2:10am. That is when the fileserver backup runs. It must be causing puppet timeouts" rather than "hmm. so they failed between 2 and 3, but only 1 had trouble during the backup."
Perhaps "Report Date" is a better name for the embedded datestamp, since that is the date the report was generated (so importing older reports will not have unexpected side-effects.)
#5 Updated by Jason Antman about 7 years ago
Ohad, sorry but this doesn't seem to be fixed.Scenario: clock on a given host is behind by, say, 6 hours. Host is running normally and sending reports. For that host:
- The "Last Report" column on the Hosts page reads "about 6 hours ago"
- All reports on the hosts/hostname/reports page share the incorrect "Last report" time
- The host shows up as Out of Sync in the dashboard and other places
In these cases, looking at the database, the created_at values appear correct, it's just the reported_at value that comes from the client, and appears to be used.
My personal recommendation (it'll be a while before I can get around to a patch) would be to hunt down all or most uses of "reported_at" in the UI and replace them with "created_at".