Closed Bug 1338627 Opened 3 years ago Closed 3 years ago

Might we add a higher-resolution timestamp for crash pings?

Categories

(Toolkit :: Telemetry, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: chutten, Assigned: chutten)

Details

(Whiteboard: [measurement:client])

Attachments

(1 file)

In trying to analyze the different types of client delays for crash pings[1] I noticed that the only timestamp information we have for a crash is the day it happened.

Might we add the hour and minute of the crash? It would help with:
* my analysis of the delays in crash ping recording
* developing a proper way to model the accuracy of the #crashes/kilo-usage-hours rate based on these delays
* measuring changes in recording/submission delay when things like bug 1310703 land

There was no discussion on bug 1121013 (which added crashDate) to explain why we truncate. (Maybe it is to make it harder to identify clients by the precise timing of crashes?)

If this is acceptable, we will need to (at minimum):
1) Add a new field (crashTime?) to crash pings which contains this information
2) Update the docs (crash-ping.rst)
3) Update CrashAggregateView.scala to parse the time properly (as well as CrashSummaryView.scala, and anything in the low-latency streaming error reporting dataset)
4) (I'm sure there's more, but I'm not sure what or where)

[1]: https://chuttenblog.wordpress.com/2017/02/09/data-science-is-hard-client-delays-for-crash-pings/
Bug 1121013 was mostly a straight migration from FHR, probably coming from a "lean/minimal data" approach.
This sounds fine to add as there is a backing need (pending data review from bsmedberg).
:bsmedberg, any data collection issues with increasing our resolution of the crash time to be in the per-second range? per-minute? per-hour?
Assignee: nobody → chutten
Status: NEW → ASSIGNED
Flags: needinfo?(benjamin)
Truncating the resolution was an intentional change to mitigate risk of being able to identify particular users from their telemetry payloads. There is not a "rule" here, more a desire to reduce risk. To the extent that we could achieve your goals by rounding to the nearest hour or something like that, it would be helpful.
Flags: needinfo?(benjamin)
I was afraid of that. Per-hour will get me most of the way there, I think. If I'm wrong I can request additional review and add more information to the ISO date string in the future.
Comment on attachment 8838222 [details]
bug 1338627 - Add crashTime to crash pings data-review=bsmedberg

https://reviewboard.mozilla.org/r/113176/#review114848

Looks good to me but could you add a test to test_crash_manager.js that checks for the new field? You could add it to the existing test_content_crash_ping() test
Attachment #8838222 - Flags: review?(gsvelto) → review+
Priority: -- → P3
Whiteboard: [measurement:client]
Sorry for the delay in getting this testcase added.
Pushed by chutten@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5823fd77c13f
Add crashTime to crash pings data-review=bsmedberg r=gsvelto
https://hg.mozilla.org/mozilla-central/rev/5823fd77c13f
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.