1361661 - Send extension process Telemetry in a separate payload section

Status: RESOLVED FIXED

(Toolkit :: Telemetry, enhancement, P1)

Description

[Georg Fritzsche [:gfritzsche]]

Per bug 1320395, webextensions will apparently run in a re-purposed content process.

This might skew analysis that are trying to look at content process metrics specifically, to understand web content impact etc.

We should probably store & submit standard probes (histograms, scalars and events) from the extension process in a separate section from the other content process probes.
E.g. submitting this in the main ping in: payload/processes/extension/*

Comment 1

[Georg Fritzsche [:gfritzsche]]

Kris, can you confirm that this re-uses content processes?
How can we tell from C++ whether a content process is the extensions process?
Do we have an (estimated) timeline for when we expect the extension process to ship?

Comment 2

[Kris Maglione [:kmag]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #1)
> Kris, can you confirm that this re-uses content processes?

Yes, it does.

> How can we tell from C++ whether a content process is the extensions process?

Something along the lines of ContentChild::GetSingleton()->GetRemoteType().EqualsASCII(EXTENSION_REMOTE_TYPE)

> Do we have an (estimated) timeline for when we expect the extension process
> to ship?

Right now, it's mainly only blocked on bug 1353060, so it should ship shortly after that lands.

Comment 3

[Georg Fritzsche [:gfritzsche]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #0)
> This might skew analysis that are trying to look at content process metrics
> specifically, to understand web content impact etc.
> 
> We should probably store & submit standard probes (histograms, scalars and
> events) from the extension process in a separate section from the other
> content process probes.
> E.g. submitting them in the main ping in: payload/processes/extension/*

Benjamin, do you have any concerns here?

Comment 4

[Benjamin Smedberg]

I think it's quite important to separate out content and extensions processes into different analysis buckets. The behavior of each can be quite different, and there are some things (like crash rates, input latency, etc) which we should be measuring separately per type.

AIUI a separate message that got sent earlier, we're going to do this. Please make sure that this interacts reasonably with the thing chutten was working on so that histograms and scalars were annotated with the process type. I don't know whether it's better to assume that all content process histograms should also be collected in extension processes, or to be more specific about it in some way.

Comment 5

[Andy McKay]

Would you consider this a blocker for turning on in Nightly? Or going to beta?

Comment 6

[Georg Fritzsche [:gfritzsche]]

This is a blocker for going to Beta.

On Nightly this might be ok for a few days.
But with the current efforts like Quantum Flow, it would be safer to not disrupt content process metrics on Nightly.
FWIW, i should have patches up here today. When are you planning to turn it on?

Comment 7

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #4)
> I think it's quite important to separate out content and extensions
> processes into different analysis buckets. The behavior of each can be quite
> different, and there are some things (like crash rates, input latency, etc)
> which we should be measuring separately per type.

I'm handling the probes that are recorded in the child process in this bug.
But i think many important release tracking metrics are recorded in the parent process, we should follow up separately on this.

Do we have a list of the current critical metrics so we can investigate?

Comment 8

[Georg Fritzsche [:gfritzsche]]

Talking this through with chutten, we didn't come up with any current critical metrics that are affected:
- our input events are fine, they are process-specific and will end up in separate payload/processes/* sections
- same for histograms like GC_MAX_PAUSE_MS
- crash metrics seem to be tracked in bug 1353168

Comment 9

[Andy McKay]

(In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> FWIW, i should have patches up here today. When are you planning to turn it
> on?

We are hoping to turn this on before the 55 Nightly soft freeze, since OOP gives us start up time performance wins. I was just reviewing all bugs to see what is a blocker or not for us turning that on.

Comment 10

[Georg Fritzsche [:gfritzsche]]

This is not a Nightly blocker, a few days of slight noise should be fine there.

Comment 11

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 1 - Generate headers with process data from Processes.yaml

Adding the Gecko enums to Processes.yaml allows us to generate mappings from ProcessID to GeckoProcessType.
We generate string tables with the Telemetry process names, so we can use these names consistently throughout Telemetry.

Comment 12

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 2 - Make Telemetry IPC code pass around Telemetry::ProcessID

Switching to Telemetry::ProcessID allows us to break out extension process data from the content process data.

Comment 13

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 3 - Update the Telemetry core

Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.

Comment 14

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 4 - Update TelemetrySession to the new process names in the snapshot

We now consistently use the same process names throughout Telemetry, except for histograms.

Comment 15

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 5 - Fix browser_UsageTelemetry_*.js tests

Comment 16

[Georg Fritzsche [:gfritzsche]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #11)
> Created attachment 8869523 [details] [diff] [review]
> Part 1 - Generate headers with process data from Processes.yaml
> 
> Adding the Gecko enums to Processes.yaml allows us to generate mappings from
> ProcessID to GeckoProcessType.
> We generate string tables with the Telemetry process names, so we can use
> these names consistently throughout Telemetry.

Here is what TelemetryProcessEnums.h looks like: https://pastebin.mozilla.org/9022197
And TelemetryProcessData.h: https://pastebin.mozilla.org/9022198

try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f17742ab71311d18af732e481d0cc62e29a97ec2

Comment 17

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 1 - Generate headers with process data from Processes.yaml

Fixed pylint issues.

Comment 18

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 1 - Generate headers with process data from Processes.yaml

Also update CLOBBER file.

Comment 19

[Alessio Placitelli [:Dexter]]

Comment on attachment 8869523 [details] [diff] [review]
Part 1 - Generate headers with process data from Processes.yaml

Review of attachment 8869523 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, just a few nits.

::: toolkit/components/telemetry/gen-process-data.py
@@ +55,5 @@
> +
> +    try:
> +        processes = load_processes(filenames[0])
> +
> +        # Write the scalar data file.

nit: scalar -> processes

::: toolkit/components/telemetry/gen-process-enum.py
@@ +49,5 @@
> +
> +    try:
> +        processes = load_processes(filenames[0])
> +
> +        # Write the scalar data file.

nit: scalar data -> processes enum

::: toolkit/components/telemetry/shared_telemetry_utils.py
@@ +131,5 @@
>          return expiration + "a1"
>  
>      return expiration
> +
> +def load_processes(filename):

nit: what about renaming this to something like |load_yaml_file|? It doesn't look strictly related to the "processes".

Can you also add some docstring for this?

Comment 20

[Alessio Placitelli [:Dexter]]

Comment on attachment 8869928 [details] [diff] [review]
Part 1 - Generate headers with process data from Processes.yaml

Still r+, see comment 19 for the nits.

Comment 21

[Alessio Placitelli [:Dexter]]

Comment on attachment 8869524 [details] [diff] [review]
Part 2 - Make Telemetry IPC code pass around Telemetry::ProcessID

Review of attachment 8869524 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/ipc/ContentParent.cpp
@@ +537,5 @@
>  
> +ProcessID
> +GetTelemetryProcessID(const nsAString& remoteType)
> +{
> +  return remoteType.EqualsLiteral(EXTENSION_REMOTE_TYPE) ? ProcessID::Extension : ProcessID::Content;

nit: would it be useful to add a comment to explain why this is needed? e.g. extension process being a content process hijacked for webext stuff?

Comment 22

[Alessio Placitelli [:Dexter]]

Comment on attachment 8869525 [details] [diff] [review]
Part 3 - Update the Telemetry core

Review of attachment 8869525 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks!

::: toolkit/components/telemetry/TelemetryCommon.h
@@ +82,5 @@
>   */
>  void LogToBrowserConsole(uint32_t aLogLevel, const nsAString& aMsg);
>  
> +/**
> + *  Get the name string for a ProcessID.

nit: one leading whitespace

Comment 23

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 1 - Generate headers with process data from Processes.yaml

Adding the Gecko enums to Processes.yaml allows us to generate mappings from ProcessID to GeckoProcessType.
We generate string tables with the Telemetry process names, so we can use these names consistently throughout Telemetry.

Comment 24

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 2 - Make Telemetry IPC code pass around Telemetry::ProcessID

Switching to Telemetry::ProcessID allows us to break out extension process data from the content process data.

Comment 25

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 3 - Update the Telemetry core

Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.

Comment 26

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 4 - Update TelemetrySession to the new process names in the snapshot

We now consistently use the same process names throughout Telemetry, except for histograms.

Comment 27

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 5 - Fix browser_UsageTelemetry_*.js tests

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/78e8b1f01c25
Part 1: Generate headers with process data from Processes.yaml. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/9cf5185e6d6f
Part 2: Make Telemetry IPC code pass around Telemetry::ProcessID. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1932fb366d4
Part 3: Update the Telemetry core. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/b0271d3616db
Part 4: Update TelemetrySession to the new process names in the snapshot. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/81b05dd29eb3
Part 5: Fix browser_UsageTelemetry_*.js tests. r=dexter

Comment 29

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=81b05dd29eb311e4fd423721b438018a828903ea&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable

Failure log flake8: https://treeherder.mozilla.org/logviewer.html#?job_id=100935640&repo=mozilla-inbound
 TEST-UNEXPECTED-ERROR | /home/worker/checkouts/gecko/toolkit/components/telemetry/gen-process-data.py:9:1 | 'shared_telemetry_utils.load_processes' imported but unused (F401)
TEST-UNEXPECTED-ERROR | /home/worker/checkouts/gecko/toolkit/components/telemetry/gen-process-data.py:60:21 | undefined name 'load_yaml_file' (F821)
TEST-UNEXPECTED-ERROR | /home/worker/checkouts/gecko/toolkit/components/telemetry/gen-process-enum.py:9:1 | 'shared_telemetry_utils.load_processes' imported but unused (F401)
TEST-UNEXPECTED-ERROR | /home/worker/checkouts/gecko/toolkit/components/telemetry/gen-process-enum.py:54:21 | undefined name 'load_yaml_file' (F821)

Failure log build: https://treeherder.mozilla.org/logviewer.html#?job_id=100935913&repo=mozilla-inbound
07:12:39     INFO -  TelemetryScalarData.h
07:12:39     INFO -  ../../config/nsinstall -L /builds/slave/m-in-m64-000000000000000000000/build/src/obj-firefox/accessible/xpcom -m 644 'xpcAccEvents.h' '../../dist/include'
07:12:39     INFO -  /builds/slave/m-in-m64-000000000000000000000/build/src/obj-firefox/_virtualenv/bin/python -m mozbuild.action.file_generate /builds/slave/m-in-m64-000000000000000000000/build/src/toolkit/components/telemetry/gen-scalar-data.py main TelemetryScalarData.h .deps/TelemetryScalarData.h.pp /builds/slave/m-in-m64-000000000000000000000/build/src/toolkit/components/telemetry/Scalars.yaml
07:12:39     INFO -  TelemetryScalarEnums.h
07:12:39     INFO -  /builds/slave/m-in-m64-000000000000000000000/build/src/obj-firefox/_virtualenv/bin/python -m mozbuild.action.file_generate /builds/slave/m-in-m64-000000000000000000000/build/src/toolkit/components/telemetry/gen-scalar-enum.py main TelemetryScalarEnums.h .deps/TelemetryScalarEnums.h.pp /builds/slave/m-in-m64-000000000000000000000/build/src/toolkit/components/telemetry/Scalars.yaml
07:12:39     INFO -  Traceback (most recent call last):
07:12:39     INFO -    File "/tools/python/lib/python2.7/runpy.py", line 162, in _run_module_as_main
07:12:39     INFO -      "__main__", fname, loader, pkg_name)
07:12:39     INFO -    File "/tools/python/lib/python2.7/runpy.py", line 72, in _run_code
07:12:39     INFO -      exec code in run_globals
07:12:39     INFO -    File "/builds/slave/m-in-m64-000000000000000000000/build/src/python/mozbuild/mozbuild/action/file_generate.py", line 108, in <module>
07:12:39     INFO -      sys.exit(main(sys.argv[1:]))
07:12:39     INFO -    File "/builds/slave/m-in-m64-000000000000000000000/build/src/python/mozbuild/mozbuild/action/file_generate.py", line 53, in main
07:12:39     INFO -      ('.py', 'r', imp.PY_SOURCE))
07:12:39     INFO -    File "/builds/slave/m-in-m64-000000000000000000000/build/src/toolkit/components/telemetry/gen-process-data.py", line 9, in <module>
07:12:39     INFO -      from shared_telemetry_utils import ParserError, load_processes
07:12:39     INFO -  ImportError: cannot import name load_processes
07:12:39     INFO -  make[5]: *** [TelemetryProcessData.h] Error 255
07:12:39     INFO -  make[5]: *** Waiting for unfinished jobs....
07:12:39     INFO -  Traceback (most recent call last):
07:12:39     INFO -    File "/tools/python/lib/python2.7/runpy.py", line 162, in _run_module_as_main
07:12:39     INFO -      "__main__", fname, loader, pkg_name)
07:12:39     INFO -    File "/tools/python/lib/python2.7/runpy.py", line 72, in _run_code
07:12:39     INFO -      exec code in run_globals
07:12:39     INFO -    File "/builds/slave/m-in-m64-000000000000000000000/build/src/python/mozbuild/mozbuild/action/file_generate.py", line 108, in <module>
07:12:39     INFO -      sys.exit(main(sys.argv[1:]))
07:12:39     INFO -    File "/builds/slave/m-in-m64-000000000000000000000/build/src/python/mozbuild/mozbuild/action/file_generate.py", line 53, in main
07:12:39     INFO -      ('.py', 'r', imp.PY_SOURCE))
07:12:39     INFO -    File "/builds/slave/m-in-m64-000000000000000000000/build/src/toolkit/components/telemetry/gen-process-enum.py", line 9, in <module>
07:12:39     INFO -      from shared_telemetry_utils import ParserError, load_processes
07:12:39     INFO -  ImportError: cannot import name load_processes
07:12:39     INFO -  make[5]: *** [TelemetryProcessEnums.h] Error 255
07:12:40     INFO -  make[4]: *** [toolkit/components/telemetry/export] Error 2

Comment 30

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/01a7f9ae8378
Backed out changeset 81b05dd29eb3 
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d02af0fa5b1
Backed out changeset b0271d3616db 
https://hg.mozilla.org/integration/mozilla-inbound/rev/43bd203d571f
Backed out changeset d1932fb366d4 
https://hg.mozilla.org/integration/mozilla-inbound/rev/69c42b4e8877
Backed out changeset 9cf5185e6d6f 
https://hg.mozilla.org/integration/mozilla-inbound/rev/c36497319158
Backed out changeset 78e8b1f01c25 for flake8 linting failures in gen-process-{data,enum}.py and build bustage in TelemetryProcessData.h on OS X, at least. r=backout on a CLOSED TREE

Comment 31

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 1 - Generate headers with process data from Processes.yaml

Adding the Gecko enums to Processes.yaml allows us to generate mappings from ProcessID to GeckoProcessType.
We generate string tables with the Telemetry process names, so we can use these names consistently throughout Telemetry.

Comment 32

[Georg Fritzsche [:gfritzsche]]

Comment on attachment 8870043 [details] [diff] [review]
Part 1 - Generate headers with process data from Processes.yaml

Addressed python script issues.

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/af4327fd49cd
Part 1: Generate headers with process data from Processes.yaml. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/8fd3861205d1
Part 2: Make Telemetry IPC code pass around Telemetry::ProcessID. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/42a4e28e6210
Part 3: Update the Telemetry core. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/358765291389
Part 4: Update TelemetrySession to the new process names in the snapshot. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/6caffcb2589c
Part 5: Fix browser_UsageTelemetry_*.js tests. r=dexter

Comment 34

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for bustage in TelemetryProcessData.h:

https://hg.mozilla.org/integration/mozilla-inbound/rev/ff997cf7f59424cc221a41f357fe811d23db239e
https://hg.mozilla.org/integration/mozilla-inbound/rev/b06174a13f445de7eebaa26601648cb0de258d83
https://hg.mozilla.org/integration/mozilla-inbound/rev/f77ffc9600cda7a294790ba566727fb9ee43b856
https://hg.mozilla.org/integration/mozilla-inbound/rev/ab92a04574be7bf18202df0f0814b4216eefbcfd
https://hg.mozilla.org/integration/mozilla-inbound/rev/a083a4c5e6d927137560baeda77272cf94926713

Please push the updated patches to Try. Thank you in advance.

Push with bustage: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=6caffcb2589cf5fea1d86be917230cd575108282&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=100981657&repo=mozilla-inbound

[task 2017-05-22T18:34:40.025506Z] 18:34:40     INFO -  TelemetryScalarEnums.h
[task 2017-05-22T18:34:40.041245Z] 18:34:40     INFO -  /home/worker/workspace/build/src/obj-firefox/_virtualenv/bin/python -m mozbuild.action.file_generate /home/worker/workspace/build/src/toolkit/components/telemetry/gen-scalar-enum.py main TelemetryScalarEnums.h .deps/TelemetryScalarEnums.h.pp /home/worker/workspace/build/src/toolkit/components/telemetry/Scalars.yaml
[task 2017-05-22T18:34:40.061559Z] 18:34:40     INFO -  ../../config/nsinstall -L /home/worker/workspace/build/src/obj-firefox/dom/base -m 644 'UseCounterList.h' '../../dist/include/mozilla/dom'
[task 2017-05-22T18:34:40.062673Z] 18:34:40     INFO -  gmake[5]: Leaving directory `/home/worker/workspace/build/src/obj-firefox/dom/base'
[task 2017-05-22T18:34:40.098766Z] 18:34:40     INFO -  /home/worker/workspace/build/src/obj-firefox/_virtualenv/bin/python -m mozbuild.action.webidl /home/worker/workspace/build/src/dom/bindings
[task 2017-05-22T18:34:40.134621Z] 18:34:40     INFO -  gmake[5]: Leaving directory `/home/worker/workspace/build/src/obj-firefox/netwerk/dns'
[task 2017-05-22T18:34:40.162864Z] 18:34:40     INFO -  ../../../config/nsinstall -L /home/worker/workspace/build/src/obj-firefox/toolkit/components/telemetry -m 644 'TelemetryEventEnums.h' '../../../dist/include/mozilla'
[task 2017-05-22T18:34:40.311461Z] 18:34:40     INFO -  Traceback (most recent call last):
[task 2017-05-22T18:34:40.313888Z] 18:34:40     INFO -    File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
[task 2017-05-22T18:34:40.313942Z] 18:34:40     INFO -      "__main__", fname, loader, pkg_name)
[task 2017-05-22T18:34:40.313977Z] 18:34:40     INFO -    File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
[task 2017-05-22T18:34:40.314006Z] 18:34:40     INFO -      exec code in run_globals
[task 2017-05-22T18:34:40.314054Z] 18:34:40     INFO -    File "/home/worker/workspace/build/src/python/mozbuild/mozbuild/action/file_generate.py", line 108, in <module>
[task 2017-05-22T18:34:40.314082Z] 18:34:40     INFO -      sys.exit(main(sys.argv[1:]))
[task 2017-05-22T18:34:40.314126Z] 18:34:40     INFO -    File "/home/worker/workspace/build/src/python/mozbuild/mozbuild/action/file_generate.py", line 53, in main
[task 2017-05-22T18:34:40.314155Z] 18:34:40     INFO -      ('.py', 'r', imp.PY_SOURCE))
[task 2017-05-22T18:34:40.314201Z] 18:34:40     INFO -    File "/home/worker/workspace/build/src/toolkit/components/telemetry/gen-process-data.py", line 9, in <module>
[task 2017-05-22T18:34:40.314436Z] 18:34:40     INFO -      from shared_telemetry_utils import ParserError, load_processes
[task 2017-05-22T18:34:40.314716Z] 18:34:40     INFO -  ImportError: cannot import name load_processes
[task 2017-05-22T18:34:40.320709Z] 18:34:40     INFO -  gmake[5]: *** [TelemetryProcessData.h] Error 1

Comment 35

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 1 - Generate headers with process data from Processes.yaml

Adding the Gecko enums to Processes.yaml allows us to generate mappings from ProcessID to GeckoProcessType.
We generate string tables with the Telemetry process names, so we can use these names consistently throughout Telemetry.

Comment 36

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 2 - Make Telemetry IPC code pass around Telemetry::ProcessID

Switching to Telemetry::ProcessID allows us to break out extension process data from the content process data.

Comment 37

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 3 - Update the Telemetry core

Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.

Comment 38

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 4 - Update TelemetrySession to the new process names in the snapshot

We now consistently use the same process names throughout Telemetry, except for histograms.

Comment 39

[Georg Fritzsche [:gfritzsche]]

Attachment: Part 5 - Fix browser_UsageTelemetry_*.js tests

Comment 40

[Georg Fritzsche [:gfritzsche]]

(In reply to Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) from comment #34)
> Backed out for bustage in TelemetryProcessData.h:

As it turns out i somehow put the fixes in patch "part 2", but only updated "part 1", which is why this slipped through.
Fixed, sorry for the noise.

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/589fca202ae6
Part 1 - Generate headers with process data from Processes.yaml. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/a441f42dba7d
Part 2 - Make Telemetry IPC code pass around Telemetry::ProcessID. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/a4228c3e9be9
Part 3 - Update the Telemetry core. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/cdd45aff508c
Part 4 - Update TelemetrySession to the new process names in the snapshot. r=dexter
https://hg.mozilla.org/integration/mozilla-inbound/rev/9cc0b3e19072
Part 5 - Fix browser_UsageTelemetry_*.js tests. r=dexter

Comment 42

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/589fca202ae6
https://hg.mozilla.org/mozilla-central/rev/a441f42dba7d
https://hg.mozilla.org/mozilla-central/rev/a4228c3e9be9
https://hg.mozilla.org/mozilla-central/rev/cdd45aff508c
https://hg.mozilla.org/mozilla-central/rev/9cc0b3e19072

Comment 43

[Benjamin Smedberg]

I don't really understand the question you asked me. The *collection* part in this bug looks fine. Turning that into actionable monitoring still seems to be an open question.