1848664 - Enable new Glean App `monitor.cirrus`

Status: RESOLVED FIXED

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

Description

[Charlie Humphreys [:charlie] [:jeddai]]

Application ID*: monitor
Application Canonical Name: Monitor
Description: Firefox Monitor arms you with tools to keep your personal information safe.
Repository URL: https://github.com/mozilla/blurts-server

Dependencies**:

• glean-core
• nimbus-cirrus

Retention Days***: 760

Notes and guidelines

* This is the identifier used to initialize Glean (or the id used on the store on Android and Apple devices).

** Dependencies can be found in the Glean repositories. Each dependency must be listed explicitly. For example, the default Glean probes will only be included if glean itself is a dependency.

*** Number of days that raw data will be retained. A good default is 180. We can change this later to accommodate longer retention periods, though we cannot recover data that is past the retention period (for example, we cannot recover data that is 200 days old if your retention period is 180 days).

To be filled by the Glean team

Application friendly name: my_app_name

Additional Notes

We're still waiting for the initial metrics.yaml file to be added, but for the time being it should be okay to enable with only the dependencies.

Comment 1

[Alessio Placitelli [:Dexter]]

Hey Jan-Erik, any chance you could take on this as well?

Comment 2

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Should the application ID be monitor.cirrus instead to distinguish it more clearly from potential frontend data collection?
Is there a data review for adding data collection to monitor already?
We do require that for the application itself, not just for the individual metrics added later (Travis, correct me if I'm wrong here though)

Comment 3

[Travis Long [:travis_]]

Yes, it's been a while since we added a "new" Glean integration but the initial Glean integration with an application was always viewed as a new or expanded collection. This shouldn't require any escalation as the internal Glean metrics have "pre-approval" but it does require the review on the initial integration to document the expansion of the collection to the new app.

In regards to the application ID, it was my understanding that the cirrus/experiment data would land in the same datasets as the general application information, but I'll defer to Charlie and the Nimbus folks on that as I'm not 100% certain that was the final decision.

Comment 4

[Charlie Humphreys [:charlie] [:jeddai]]

Should the application ID be monitor.cirrus instead to distinguish it more clearly from potential frontend data collection?

As Travis said, I believe the intent was for all the data to be collected by the same app id — plus it's worth noting that Cirrus technically is frontend data collection, just handled by a backend service. It's complicated 😬

Is there a data review for adding data collection to monitor already?

Not at the moment, I'll get that added.

Comment 5

[Charlie Humphreys [:charlie] [:jeddai]]

Attachment: monitor-data-request.md

Here's the data review request!

Comment 6

[Travis Long [:travis_]]

Comment on attachment 9349903 [details]
monitor-data-request.md

Data Review

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, through the metrics.yaml file and the Glean Dictionary.

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, through the telemetry preferences in the application settings.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

Permanent collection of the basic Glean integration to be monitored by Charlie and the Nimbus Team, and also the Glean team by virtue of their ownership of certain metrics associated with the basic Glean integration.

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

See the original Glean data-review for the full list of the basic Glean data-collection categories. This review represents the extension of the Glean collection to the new application.

5. Is the data collection request for default-on or default-off?

Default-on

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No new identifiers, only those already approved in the base Glean integration.

7. Is the data collection covered by the existing Firefox privacy notice?

Yes

8. Does the data collection use a third-party collection tool?

No

Result

data-review+

Comment 7

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

(In reply to Charlie Humphreys [:charlie] [:jeddai] from comment #4)

Should the application ID be monitor.cirrus instead to distinguish it more clearly from potential frontend data collection?

As Travis said, I believe the intent was for all the data to be collected by the same app id — plus it's worth noting that Cirrus technically is frontend data collection, just handled by a backend service. It's complicated 😬

Ah yeah, it is complicated. So we should make sure to be explicit when we talk about it. Cirrus vs Glean.js collection maybe.

With respect to the application ID: I'm not sure we can do that. The way the pipeline picks which schema to validate against is based on the application ID the payload is submitted under. Cirrus data and Glean.js data will have different schemas.
So they will initially end up in different datasets/tables, but we can build derived datasets as necessary on that.

Comment 8

[Charlie Humphreys [:charlie] [:jeddai]]

Ah gotcha, okay makes sense!

Comment 9

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Attachment: pr 617: Bug 1848664 - New app: monitor.cirrus

Comment 10

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

:charlie I added your email to the notification_emails list. Is there anyone else that should be responsible for this app?

Comment 11

[Charlie Humphreys [:charlie] [:jeddai]]

I think if you could also add [e-mail], [e-mail], and [e-mail] that should cover it, thanks!

Comment 12

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

badboy merged PR #617: "Bug 1848664 - New app: monitor.cirrus" in c32ad44.

Now waiting for the deploy.

Comment 13

[Charlie Humphreys [:charlie] [:jeddai]]

After a discussion today there's some updates we'd like to make to the entry in probe-scraper — namely updating the channels. Would you prefer to handle those in this ticket or a new ticket?

Comment 14

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

It's still open, let's continue to use this bug.

Comment 15

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

monitor.cirrus tables have been deployed (but due to other issues the dictionary isn't updated)

Comment 16

[Charlie Humphreys [:charlie] [:jeddai]]

Okay!

The channels Monitor is set up for with their Nimbus configuration are beta and release.

Comment 17

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

I assume both channels still send with the same app ID, right? The only difference is that they set the app_channel configuration option?

Comment 18

[Charlie Humphreys [:charlie] [:jeddai]]

Yep!

Comment 19

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Then that doesn't require any additional probe-scraper config.
We only need channel configuration there if the same app sends channels under different application IDs.

Comment 20

[Charlie Humphreys [:charlie] [:jeddai]]

Ohhhhhh I didn't realize that. Awesome, thanks!

Comment 21

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Forgot to close this. Deploy was done.