Issue #16480 has been updated by eric sorenson. Category set to reports Status changed from Unreviewed to Investigating Assignee set to Chris Price
Chris, not sure if this is a ticket you intend to work or were just documenting, but I'm assigning it to you in either case as I'm going through unreviewed tickets to make sure they have an owner. ---------------------------------------- Bug #16480: Misleading time metrics in report processing https://projects.puppetlabs.com/issues/16480#change-74721 Author: Chris Price Status: Investigating Priority: Normal Assignee: Chris Price Category: reports Target version: Affected Puppet version: Keywords: puppetdb Branch: We're working on adding puppet reports to puppetdb. We'd like to collect meaningful data about the run start time, duration, etc., as well as information about the time/duration of individual events. This will allow support of various time-based queries. A lot of this sort of data appears in the report, but it seems to be misleading or inaccurate. Most notably, there does not appear to be an accurate "end time" or "duration" value for the full puppet run. There is a "time" property at the top level of the report, which appears to be the start time of the run. In the "metrics" section, there is a metric called "time" with a value labeled "total". I'd expect this to be the duration of the run, but I think it may be some measure of CPU time rather than wall time. I'm also not 100% sure what unit of measurement this value is represented in--guessing that it's in seconds. Each entry in the "resource_statuses" section (and in the nested "events" sections) includes a "time" field, but only one, and no "duration" or similar field. In all of the reports I've looked at so far (please see sample report I've attached to this ticket), if you take the top-level "time" value (presumably the start time for the run) and add to it the "metrics->time->total" value (interpreted as seconds), you end up with a value that is still *before* the timestamps for any of the individual resource events. So perhaps the timestamp in the metrics section is for catalog processing or something, rather than actual resource application. It should be possible for us to do some pretty hacky state tracking while we're processing the report data, and *calculate* the approximate end time for the puppet run (e.g. by using the greatest timestamp value from the resource_status entries)... and similarly to guess the duration / end-time for any individual resource by sorting the timestamps for all of the resource_status/event entries and assuming that the end time for any resource is the start time for the subsequent resource. However, in an ideal world, puppet would provide this stuff so that the consumer wouldn't need to parse and guess... and it seems like it should be fairly straightforward to add it. These are the things that I think would be valuable: 1. Document the unit of measurement for the current "time" metrics. 2. Document the meaning of the "total" time metric. 3. If the "total" time metric is intentionally a cpu-time value (instead of wall-time), or if it's a catalog pre-processing time that doesn't include the actual resource application time, can we add in another metric for the wall time? Or just add an "end-time" timestamp to the top-level report data? 4. Add a "duration" or "end-time" field to the individual resource_status and nested event entries. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
