Closed Bug 1672951 Opened 5 years ago Closed 4 years ago

Implement the metrics ping scheduler for the RLB

Categories

(Data Platform and Tools :: Glean: SDK, task, P1)

task

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Dexter, Assigned: chutten)

References

Details

(Whiteboard: [telemetry:fog:m7])

Attachments

(5 files)

No description provided.
Whiteboard: [telemetry:glean-rs:m?][telemetry:fog:m6] → [telemetry:fog:m6]
Blocks: 1670262
Whiteboard: [telemetry:fog:m6] → [telemetry:fog:m7]

How does one build an MPS? Looking at Android's and iOS' it appears to have three parts

  1. 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?)
  2. Some sort of Timer
    • Used to kick the MPS to check the wall clock and see if it's 4AM already today.
  3. 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.

Flags: needinfo?(jrediger)

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)

Flags: needinfo?(jrediger)
Assignee: nobody → chutten
Status: NEW → ASSIGNED
Priority: P3 → P1

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 chrono for DateTime, std::thread for sleep
  • Implements as closely as possible the logic from MetricsPingScheduler.{kt|swift}
  • Tests.

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

Depends on D114972

Pushed by chutten@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/beaa922298ad Upgrade glean_parser to 3.2.0 r=janerik https://hg.mozilla.org/integration/autoland/rev/9a37bc605337 Update 'how to update the glean sdk' docs r=janerik https://hg.mozilla.org/integration/autoland/rev/6c7a457ba9ec Update Glean SDK to v38.0.0 r=janerik https://hg.mozilla.org/integration/autoland/rev/664825bd949c Enable Glean SDK 'metrics' ping scheduler for FOG r=janerik
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: