Bug #160
closed
Last Report Date is client date, not date report was received.
Description
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.)
Updated by Ohad Levy about 14 years ago
- Category set to Puppet Reports
- Status changed from New to Feedback
- Assignee set to Dis Connect
would it be enough if we expire the reports based on their creation date instead?
Updated by Ohad Levy almost 14 years ago
- Status changed from Feedback to Assigned
- Assignee changed from Dis Connect to Ohad Levy
- Target version set to 0.1-5
Updated by Ohad Levy almost 14 years ago
- Status changed from Assigned to Ready For Testing
- % Done changed from 0 to 100
Applied in changeset c820bdbb9b6795a748a83896d3335dab6fdc9398.
Updated by Ohad Levy almost 14 years ago
- Status changed from Ready For Testing to Closed
Updated by Jason Antman about 12 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".