2012752 - Allow shared Rust components to send metric data directly

Status: ASSIGNED

(Data Platform and Tools :: Glean: SDK, enhancement, P3)

Description

[Ben Dean-Kawamura [:bdk]]

As of now, shared Rust components can't directly report Glean metric. If they want to record telemetry they need to use workarounds like defining a callback interface for the metrics, implementing it on the foreign side, and having the Rust code call into it when it wants to record a metric. It would be great to have a better solution here.

I believe the main issue is that Glean and the Rust components may have been built by different rustc invocations and/or in different libraries. This means we can't make Rust calls directly because Rust doesn't have a stable ABI. This is complicated by the fact that Desktop, iOS, and Android all have a different library/linking setups.

Ideally, we would be able to use the Rust generated bindings. However, if we had to use the lower-level glean crate directly, that would be a big improvement over the current setup.

IMO, the most important feature is only needing to land a single PR in the Rust Components repo in order to start collecting new data. Having to land PRs in multiple repos and requiring cross-team review makes it much harder to add metrics. Right now the "Rust components repo" is application-services, but it will hopefully be moz-central in the near future.

Comment 1

[Ben Dean-Kawamura [:bdk]]

Adding https://bugzilla.mozilla.org/show_bug.cgi?id=1950226 as a blocker to this. I don't think it blocks planning/discussion, but we probably don't want to implement anything while we're also in the middle of migrating application-services to the moz-central repo.

Comment 2

[Jan-Erik Rediger [:janerik]]

glean-sym is now active on both Android and iOS and used by the places component for temporary metrics.

:bdk, you can take this over from here and start using it for real metrics. That could mean either migrating the existing ones we duplicated or use it for other metrics.
We consider glean-sym still experimental until we see some use.
There's also still the thing where we need to ensure it's not used in parts that run before libxul is loaded. That requires manual verification for now!

Comment 3

[Ben Dean-Kawamura [:bdk]]

That's great news! I can start testing this out on some real metrics.

What's the story for Desktop? Can we use the same code there and be use FOG as the backend?

Comment 4

[Jan-Erik Rediger [:janerik]]

(In reply to Ben Dean-Kawamura [:bdk] from comment #3)

That's great news! I can start testing this out on some real metrics.

What's the story for Desktop? Can we use the same code there and be use FOG as the backend?

🤔 I think there's still some difficulty in doing that due to Desktop's multi-process approach.
If we guarantee that the recording is done in Rust code that runs in the main process, then this should be achievable by switching out what code is generated in the build.rs (by changing this line), but for non-parent process code we would need to thread it through to the FOG types and that's a bit more effort (that might be more achievable once appservices is in m-c and we can wire through some of the build code)