Implement the metrics ping scheduler for the RLB
Categories
(Data Platform and Tools :: Glean: SDK, task, P1)
Tracking
(Not tracked)
People
(Reporter: Dexter, Assigned: chutten)
References
Details
(Whiteboard: [telemetry:fog:m7])
Attachments
(5 files)
| Reporter | ||
Updated•5 years ago
|
| Assignee | ||
Comment 1•5 years ago
|
||
How does one build an MPS? Looking at Android's and iOS' it appears to have three parts
- Storage for
- the last time a "metrics" ping was sent
- the app version the last time a "metrics" ping was sent (Q: Should this be app_build?)
- Some sort of
Timer- Used to kick the MPS to check the wall clock and see if it's 4AM already today.
- The all-important logic for determining what to send when.
- The implementation in a programming language of the English written here.
I'm not sure I see a reason why we wouldn't implement this in glean-core instead of the RLB. Even if we end up relying on RLB (which relies on FOG which relies on Firefox Desktop) to provide "2) Some sort of Timer" (For Firefox Desktop I'd lean towards perhaps nsIUpdateTimerManager) we could punch that through three levels of indirection as easily as two (though who knows, maybe a std::thread sleeping for 15min at a time would do just as well). And this way we could use metrics storage for "1) Storage for" in the same way we store the dirtybit for detecting clean shutdowns.
ni?janerik to tell me if this is a bad idea.
So first off as an answer to in-matrix discussion: The MPS is the way it is because ... legacy.
We opted to not port it from its initial Kotlin implemementation back then, and that's mostly why it still keeps its own storage to this day.
We decided to not do any half-refactoring of that part, because we knew we will port over the full MPS eventually (who could have known that it will be such a long time...)
So to answer that ni: Not a bad idea to implement it once and for all in Rust!
Regarding what the implementation would look like: I haven't thought too much about it really, but some sort of timer API the platform around it can hook into would probably be a decent approach.
Then the internals does the bunch of checks if it should trigger a ping submission and the language binding/surrounding system is responsible for scheduling a timer for that.
I'd be ok with having a rough implementation sketch of this (basically a not fully-formal proposal I guess)
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 3•4 years ago
|
||
There's not a lot to sketch:
- scheduler.rs in glean-core/src
- Lives on the Glean struct
- Uses metrics to store the last time a "metrics" ping was sent and the app's build the last time a "metrics" ping was sent
- Must drill app_build to glean-core (only going to do this for RLB). Gonna hang it on glean_core::Configuration
- Uses
chronofor DateTime,std::threadfor sleep - Implements as closely as possible the logic from
MetricsPingScheduler.{kt|swift} - Tests.
Comment 4•4 years ago
|
||
| Assignee | ||
Comment 5•4 years ago
|
||
chutten merged PR #1599: "Bug 1672951 - Implement a Metrics Ping Scheduler in glean-core" in 1a8ad80.
Leaving open to track work getting this into FOG
| Assignee | ||
Comment 6•4 years ago
|
||
( here's a try run of a patched m-c running glean with the "metrics" ping scheduler: https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&author=chutten%40mozilla.com&fromchange=abd3082d4e6738ce1b4338cd4d99b48875bc9cb6 )
| Assignee | ||
Comment 7•4 years ago
|
||
| Assignee | ||
Comment 8•4 years ago
|
||
Depends on D114971
| Assignee | ||
Comment 9•4 years ago
|
||
Depends on D114972
| Assignee | ||
Comment 10•4 years ago
|
||
Depends on D114973
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/beaa922298ad
https://hg.mozilla.org/mozilla-central/rev/9a37bc605337
https://hg.mozilla.org/mozilla-central/rev/6c7a457ba9ec
https://hg.mozilla.org/mozilla-central/rev/664825bd949c
Description
•