Bertrand, didn't you write a separate metrics uploader, which doesn't have to go through Chrome?

We have one working for jetstream AFAIK.

One of the reason why we used a file to serialize the samples and get picked up by Chrome ("poor man's IPC) is because we need to log things before Chrome is ready (aka, early boot). We'd need to re-architect the client a bit :)

mojo gives you this: the client can come up and start sending data to the service. When the service eventually comes up, the service will receive the queued up messages. So reasonably optimistically, client wouldn't need to be re-architected too much.

Note that Metrics now has a defined "file" API.  Any outside process can save metrics to a file (either with a memory dump at exit or with a memory-mapped file) that Chrome will read during a metrics upload.  No extra "serialization" code is necessary because the native format of the memory block is already serialized.

Dump metrics at exit example:
https://cs.chromium.org/chromium/src/chrome/installer/setup/installer_metrics.cc

Metrics in a memory-mapped file:
https://cs.chromium.org/chromium/src/chrome/browser/chrome_browser_field_trials.cc?rcl=0&l=41

Register file to be read during metrics upload:
https://cs.chromium.org/chromium/src/chrome/browser/metrics/chrome_metrics_service_client.cc?rcl=0&l=138

As far as I can tell, we can implement a complete metrics service without really requiring Chrome at all?

If so, is there any reason why we need to have the metrics service in one place. Components 'could' just upload their own metrics, correct?


Or is there a dependency on Chrome that we can't get around that I am not aware of?

Aren't some metrics associated with a profile? How would an external process do that?

Histograms are managed by base and are global to a process.  There is no distinguishing between where they come from so the upload service will always find them all.

There are components in chrome/ that create metrics, notably one that imports them from all subprocesses.

Although it would be possible to run a different instance of metrics service, there are  some complexities with that approach.

1. It would result in more pings and more bandwidth used by users. Basically, you would have more reports - and each report has redundant data (i.e. system profile data) beyond just the histograms/actions payload.
2. Since you wouldn't use any code in chrome/browser/metrics - you'd be missing out on some functionality there - for example getting metrics from renderer processes, logging any metrics that are currently recorded by providers implemented in that directory.
3. Will you re-use Chrome's client id or have a different one? If it's a different one, you will now be doubling the number of users seen by the backend which would be a surprising and undesirable result. If you re-use the client id, now you need to figure out what to do with session_id. Normally, that's incremented once per session (browser process start) by metrics service. If you have multiple metrics services for the same client id, we'd need to figure out how to treat that field in the new world.

There's probably other things I'm missing too (for example, sharing the consent logic). So given the above, my intuition is it's better to have the data be reported by the existing metrics service in Chrome than having multiple things running their own metrics services.

@asvitkine Thanks for explaining!

So it sounds like we already pull metrics from the renderer process into Chrome for upload? We will now just need to get metrics from more processes, in this case ash.

If doing so requires defining a mojo interface to report metrics, can we just move the metrics service out of Chrome and run it as its own process instead? We want to reduce our dependence on Chrome as much as possible since we will need to report metrics even without Chrome - for example, from AppShell.

Moving it out of Chrome would hit the problem 2. that I mentioned in the comment above. There's a bunch of chrome/ code that runs as part of Chrome's metrics service.

Additionally, it would make the codepath for uploading Chrome browser UMA metrics different between ChromeOS and other platforms, which is undesirable. (e.g. it might get broken easier and likely would require more work to maintain).

Replying to comment#10:

> 1. It would result in more pings and more bandwidth used by users.
> Basically, you would have more reports - and each report has redundant
> data (i.e. system profile data) beyond just the histograms/actions
> payload.

I don't think so? The idea (https://docs.google.com/document/d/1T-VoO6w4tPPDVVLxJyM3MsnheQiRsuQc3VuZJDBPeSY/edit) is that there will be exactly one service (the uma service) that will generate the report. It will collect the histogram/actions payload from a number of various clients (e.g. ash, chromeos platforms, other mus/mojo apps). So there shouldn't be more pings/bandwidth usage etc.

> 2. Since you wouldn't use any code in chrome/browser/metrics - you'd
> be missing out on some functionality there.

chrome browser can continue to collect those metrics from the renderer using that code (although ultimately it would make sense for the renderers to just directly send the payload to the uma service instead). chrome browser in this case will simply be an uma-client (like ash, chromeos platform etc.)

> 3. Will you re-use Chrome's client id or have a different one?

That should be possible I suppose? There will still be a single service in the sytem that uploads the data, so there will be a single client. In the last diagram in the above mentioned doc, 'components/metrics mojo app' box is the only one that actually uploads the data to the server.

Would it be helpful to include additional detail in the doc?

Moved the doc to chromium account: https://docs.google.com/document/d/1e1gTIpv4EjcLJP9HXjukcpIyzwr-rLVxlG5LwdQX4G4/edit 

Chrome's primary subprocesses now communicate metrics via shared memory segments.  Other processes are also free to store their metrics using shared memory segments or memory-mapped files that Chrome periodically reads and uploads.

CrashPad is currently adding this, using a memory-mapped file because it's specifically designed to handle crashes:
https://codereview.chromium.org/2308763002/

It seems to me that the approach described in comment #11 would make the most sense. Doing a Mojo IPC (or even in-process Mojo call) for every UMA metric logged can get expensive, so it makes sense to bundle the data. This building mechanism already exists between the renderer and the browser, so it seems sensible to generalize it and use it in all Mustash processes (Mus, ash, renderers, and other Mus clients) where we want to log UMA data. This means that we can use the existing UMA macros everywhere and we don't need to change anything about how they are implemented. What we need instead is to generalize the following Chrome IPC calls and convert them to Mojo:

- ChildProcessMsg_SetHistogramMemory
- ChildProcessMsg_GetChildNonPersistentHistogramData
- ChildProcessHostMsg_ChildHistogramData

In addition we should probably add a call for the client to request UMA capabilities from the UMA service, which would result in the UMA service calling the equivalent of ChildProcessMsg_SetHistogramMemory on the client.

This means that all Mustash processes except for Chrome would use SharedPersistentMemoryAllocator for UMA metrics.

Does this make sense?

Yep. I think that would be the best course of action.

> In addition we should probably add a call for the client to request UMA
> capabilities from the UMA service, which would result in the UMA service
> calling the equivalent of ChildProcessMsg_SetHistogramMemory on the client.

Yep. More specifically, I think the mojom API needs to include a registration API, so that a client can register itself to the UMA server. Upon registration, the server will allocate the shared memory, and send the handle to the client. This also allows the server to know clients to ask for data when it needs to, etc. (I think 

We need the metrics service for Chromecast, which will soon have mojo services running in non-chrome processes. I am going to mark this bug as a blocker to the cast_shell modularization project. Please let me know if any input is needed from the Chromecast team.

We haven't been able to prioritize this yet, unfortunately. It would be wonderful to have some help implementing this from the metrics or the chromecast team! :)

(the actual work that needs to happen is fairly well-defined, I think. See comments #11, #20, for example)

This is high-priority work for the Cast team, so I'm going to grab this bug.

The plan is to:
 1) Mojofy the IPC methods calls listed in #20 (probably with a client registration model).
 2) Create a "metrics" service embedded in content_browser to implement this interface, into which each content embedder can inject a MetricsServiceClient (or equivalent).
 3) Convert all non-chrome processes and the chrome browser processes into clients of this service. 
 4) Eventually move this service into a standalone process on platforms which may require it (Chromecast & ChromeOS).

I will begin to update the public doc with planned implementation. I'll keep the bug updated with my progress.

slan, has any progress been made on this? This is important for the mus+ash team as well.

 Issue 607320  has been merged into this issue.

Was just talking to sadrul@ this morning, no progress has been made yet. Does a Q3 target work for the mus+ash team?

That depends. If we want metrics in mus, then we need this done this quarter.

sky@: Understood. End of Q2 is the new target. 

Any updates here? Are we still on track for end of Q2?

No significant updates yet, but this is my top priority in June. Still on track for EOQ2.

Please note that "metrics service" is already a thing (components/metrics/metrics_service.cc) so using that term to refer to the mojo service is confusing, because you're referring to something else than metrics_service.cc.

I've made progress in the following patch (https://chromium-review.googlesource.com/c/534600), with a big update coming shortly to move histogram interfaces into the now existent "metrics" service. I was hoping to get it out for review last week, but some urgent Cast release work took all of my time. Apologies for the late heads-up.

I am OOO the rest of this week for my wedding, but I will post the updated PS for review as soon as I can, targeting next week for the majority of work to get it landed. 

hi Stephen, I'm curious: what's the status of this work?

I'm removing this as a blocker for mushrome. The reason is all services are now launched via the utility process, which wires up histograms. In other words, for ash, ui and other services histograms now work. Long term histograms should move outside of chrome (which we need for mash), but that doesn't block mushrome now.

Ping slan, any updates on this?

I'm pretty sure this all just works now, or do I have that wrong?

We have a "metrics mojo service", but it only has an interface for recording UKM metrics and it's still embedded in browser process.  So I don't think this completes what this bug was filed to accomplish.

Of the work suggested in comment 25, only #2 has been completed.

Because we are are launching services via the utility process I believe we get metrics for free. By that I mean any metrics reporting done in any of these services now just works. So, I'm removing ash from the components list here. To have the browser not running with ash running we'll need something else, but the current state is good in the near term.