Closed
Bug 1490945
Opened 7 years ago
Closed 7 years ago
Evaluate event telemetry improvement proposal
Categories
(Toolkit :: Telemetry, enhancement, P2)
Toolkit
Telemetry
Tracking
()
RESOLVED
FIXED
mozilla65
People
(Reporter: gfritzsche, Assigned: chutten)
Details
Attachments
(1 file)
Assignee | ||
Comment 1•7 years ago
|
||
I'll look into this quickly this iteration.
Assignee: nobody → chutten
Status: NEW → ASSIGNED
Points: --- → 1
Priority: -- → P1
Assignee | ||
Comment 2•7 years ago
|
||
I mentioned in email about how multiple method and object values currently operate. :shong, has that explanation addressed the concerns in the document to your satisfaction?
Flags: needinfo?(shong)
Comment 3•7 years ago
|
||
Hi Chris,
Not exactly.
My main concern is that there isn't a specified field for the "name" of the event.
As it stands now, all Telemetry events are basically generic events, and we have to specify some combination of field values to identify a particular event type. That means:
1) We cannot have 2 event types with a similar schema, even when it makes sense to do so.
2) Future event's schema could overlap with an existing event's schema, and essentially make it impossible to distinguish between the two.
It looks like we DO name event types in the YAML file, but in the data schema (timestamp | category | method | object | value | extra) there is nowhere to put that name.
We should really have some name field in the data schema. This issue will definitely become more problematic in the future, so the earlier we can address it, the better.
Sorry if I'm not explaining things clearly enough, maybe we should have a vidyo call to touch base if it's not clear or you have any disagreements.
- Su
Flags: needinfo?(shong)
Assignee | ||
Comment 4•7 years ago
|
||
Oh no, I forgot to submit this comment last week:
:shong and I had a conversation about this today (Friday Sept 28). We covered many topics here and came to the following points of agreement:
1) It's tricky to discover code and definitions for events when you're starting from the data side. Events and event records lack a singular identifying "metric name" that Scalars and Histograms have to aid in these sorts of situations. (e.g. try using searchfox to discover information about events in the "devtools" category)
2) It is unclear (undocumented?) that any given {category, method, object} tuple is unique, so there were worries of overlap.
3) Events are a relatively-new and relatively-complex metric type. Best practices and even vocabulary are still underdeveloped compared to Histograms and Scalars.
4) Given size considerations it is unlikely that we're going to be too interested in adding new identifiers to event records and instead should focus on best practices in using the ones already present.
This led to some interesting ideas
* Calling events within a single event definition (with multiple methods and objects and extra keys, but a single description) an Event Family so we can talk about them independently of their definition, any Event Records of recorded data, and Category it belongs to.
* Perhaps developing a taxonomy that favours having a single Family per Category. Using a rich category name like "toplevel.secondlevel" to provide a "metric name" for the Family that makes it easier to find using available tools.
* Adding more documentation on the data side (docs.tmo) and updating existing in-tree docs to be clear on relevant implementation details like the enforced uniqueness of {category, method, object}.
:shong has taken the first action to improve the Event documentation on docs.tmo. After that we can see what updates are needed in-tree and where this bug needs to be taken.
Assignee | ||
Updated•7 years ago
|
Priority: P1 → P2
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(shong)
Comment 5•7 years ago
|
||
Hey chutten, sorry for the long delay. I've made a PR with the documentation:
https://github.com/mozilla/firefox-data-docs/pull/197
Let me know what you think
Flags: needinfo?(shong)
Assignee | ||
Comment 6•7 years ago
|
||
Reviews are on Github. Looks like there's room for improving the source docs by at least noting in [1] that category+method+object are required to be unique, and that events are submitted by the "event" ping (the doc for which has plenty of other relevant information about event behaviour)
This bug can now be about adding those two things to the source docs and we can split the event best practices discussion out to the PR in Comment#5.
[1]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/collection/events.html#the-yaml-definition-file
Assignee | ||
Comment 7•7 years ago
|
||
Pushed by chutten@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1dc4651530f8
Improve Telemetry Event docs slightly r=Dexter
Comment 9•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Comment 10•7 years ago
|
||
https://hg.mozilla.org/projects/larch/rev/1dc4651530f8290007b9440c9013493cc0ef65f2
bug 1490945 - Improve Telemetry Event docs slightly r=Dexter
Updated•7 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•