This is tracking fixing the content process Telemetry. We had a kickoff meeting about this: https://docs.google.com/document/d/1pdLsqjtOlRkuTQw6tOXWfd04BOpETPj1Bk_2Q1_fjN0/ The current idea is to try out aggregating the content process Histograms in the parent (this is bug 1218576): * send all histogram accumulations up to the parent process * accumulate them into a single set of "content process" histograms We have to verify that this does not regress performance or energy usage significantly. From talking with Roberto et al, there is currently no data from childPayload being used besides histograms. So, if bug 1218576 works out, the current plan is to: * put the histograms onto the payload as "childHistograms" and "childKeyedHistograms" * drop the whole content payload collection mechanism * make the child process Telemetry setup code as minimal as possible * update about:telemetry accordingly If we need additional content process measurements later we can still add specific mechanisms when that comes up.

Roberto, what the pipeline dependencies be here? I can think of: * python_mozaggregator for t.m.o aggregations * python_moztelemetry for the histogram access wrappers

(In reply to Georg Fritzsche [:gfritzsche] from comment #1) > Roberto, what the pipeline dependencies be here? > I can think of: > * python_mozaggregator for t.m.o aggregations > * python_moztelemetry for the histogram access wrappers telemetry-batch-view as well, which generates the Parquet views.