1572160 - Investigate making events multiplexing easier in products using the Glean SDK

Status: RESOLVED WORKSFORME

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

Description

[Alessio Placitelli [:Dexter]]

If a product using the Glean SDK needs to generate events for multiple collection libraries, the process for doing it gets a bit convoluted (see meeting notes).

Current process:

1. Create an event in metrics.yaml
2. Create an event in Metrics.kt
3. Record it and its KEYS inside of GleanMetricsService.kt
4. If your event has a key, map a hardcoded string value for those:
5. Document it in metrics.md
6. Send the event from the proper place in the code
7. Submit a data review

Current pain points:

• it currently fails silently if any of the above steps fail
• lots of steps, very error prone
• most problems come from the fact that we have enum for keys, don't’ allow strings

This bug is about investigating possible changes to the Glean SDK that would allow for a smoother workflow when adding events to Fenix.

Comment 1

[Michael Droettboom [:mdroettboom]]

One idea raised in our internal meeting on Monday:

The glean_parser, that reads metrics.yaml files and generates code, is written as a Python library. It could be used as the basis for code generation in Fenix to generate all of the currently-difficult boilerplate.

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Alessio Placitelli [:Dexter] from comment #0)

If a product using the Glean SDK needs to generate events for multiple collection libraries, the process for doing it gets a bit convoluted (see meeting notes).

Current process:

1. Create an event in metrics.yaml
2. Create an event in Metrics.kt
3. Record it and its KEYS inside of GleanMetricsService.kt
4. If your event has a key, map a hardcoded string value for those:
5. Document it in metrics.md
6. Send the event from the proper place in the code
7. Submit a data review

Hey Chenxia,

we took a look a this. Given that there are a very few events recorded with Leanplum, would it make sense for that recording code to live next to the Glean SDK events recording? Basically, I'm talking about removing a layer of abstraction there. That would allow you to get rid of Metrics.kt, removing (2) and potentially making (4) needless.

Another solution would be for the Fenix build system to create a Python script that uses the glean_parser to generate your Metrics.kt automatically. This would probably remove (2) and (4) out of the above list.

I'm afraid there's not much else that we could suggest here.