Limit recording engagement scalars to parent process

RESOLVED WORKSFORME

Status

()

Toolkit
Telemetry
P4
normal
RESOLVED WORKSFORME
a month ago
a month ago

People

(Reporter: gfritzsche, Unassigned, Mentored)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox59 affected)

Details

(Whiteboard: [good first bug] [lang=js])

(Reporter)

Description

a month ago
Bug 1423446 shows that some engagement scalars are not recorded in the content process:
"SCALARS_BROWSER.ENGAGEMENT.ACTIVE_TICKS","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.MAX_CONCURRENT_TAB_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.MAX_CONCURRENT_WINDOW_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.RESTORED_PINNED_TABS_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.TAB_OPEN_EVENT_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.TOTAL_URI_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.UNFILTERED_URI_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.UNIQUE_DOMAINS_COUNT","[u'false']"
"SCALARS_BROWSER.ENGAGEMENT.WINDOW_OPEN_EVENT_COUNT","[u'false']"

We should restrict these scalars to record only in the parent, i.e.:
> record_in_processes: ["main"]

This change is needed in Scalars.yaml:
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Scalars.yaml

After the change, make sure that building still works properly using:
> mach build

Also run some tests to make sure nothing broke:
> mach test browser/modules/test/browser/browser_UsageTelemetry*
(Reporter)

Updated

a month ago
Blocks: 1423446
(Reporter)

Comment 1

a month ago
While we're here, we can also restrict these two:
"SCALARS_TELEMETRY.OS_SHUTTING_DOWN","[u'false']"
"SCALARS_TIMESTAMPS.FIRST_PAINT","[u'false']"

Comment 2

a month ago
Hey!

I just started with mozilla development and would like to fix this.Just need a few resousrce to know how to fix it?
Can anyone help me out here?

Thanks
Hi Rohan!

As outlined in comment 0, the "record_in_processes" property needs to be set to "main" only for the scalars listed in comment 0 and 1.
Assignee: nobody → rohan17089

Comment 4

a month ago
Thanks for the quick reply!

I did check all these scalars and it is already set to main only.
Couldn't find the following scalar though
"SCALARS_TELEMETRY.OS_SHUTTING_DOWN","[u'false']"
perhaps telementry might right to another type of build
and for the following scalar
"SCALARS_TIMESTAMPS.FIRST_PAINT","[u'false']"
the main written wasnt in single quotes,don't know if it makes a difference or not

This is all what i could figure out,waiting for your further reply.
(In reply to Rohan Rajpal from comment #4)
> Thanks for the quick reply!
> 
> I did check all these scalars and it is already set to main only.

Good point. I cross-checked and you're right, all these scalars are already set to "main". Rohan, I think you're done here :) I've needinfo'd you on another good bug if you're interested in taking more!

@Frank, looks like the list of scalars from comment 0 comes from bug 1423446: we shouldn't be seeing these scalars in the content processes though. I quickly checked my builds and looks like we're sending the right stuff. Is this a mistake in the list or some unexpected behaviour in the pipeline code for scalars?
Assignee: rohan17089 → nobody
Flags: needinfo?(fbertsch)
Everything looks correct:
- The list I gave is all probes that have *only* reported in the parent process
- This bug is for restricting scalars to those
- It looks like those scalars are already restricted, so we're good to go!
Flags: needinfo?(fbertsch)
Thanks Frank!
Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.