If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add % of sessions for ghost_windows to error_aggregates

RESOLVED FIXED

Status

Cloud Services
Mission Control
P1
normal
RESOLVED FIXED
2 months ago
26 days ago

People

(Reporter: frank, Assigned: mdoglio)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 months ago
This is a quantum release criteria. Will need count of total sessions, and count of sessions with ghost_windows.
(Reporter)

Updated

2 months ago
Assignee: nobody → fbertsch
Points: --- → 3
Priority: -- → P1
(Reporter)

Comment 1

2 months ago
We are running into two problems here:

1. Looking at the current notebook which processes this metric for Quantum RC [0], it uses % of subsessions, not % of sessions. I'm not sure we can guarantee that these two metrics will be the same; subsessions will be skewed towards longer sessions.

2. We don't actually have the session_id in main_summary, meaning the best we could do is compute this value moving forward. We could do a backfill but this is difficult and expensive . [If it is important we correct this, it certainly can be done.]

Now, in conjunction with each other, these issues solve itself - if we decide that % of subsessions is acceptable, then we can compute this value historically.

Stuart, Harald mentioned you might have some idea about this?

[0] Bsmedberg's daily latency metrics notebook
Flags: needinfo?(sphilp)
[Taking this while :sphilp is out]

Frank, it seems hard to make that decision without better knowing the impact.

- Are there alternatives, like usage hours?
- Is there an analysis that compares subsessions to sessions.
- One step further, is it possible to have a simple analysis that compares the aggregate of % of subsessions aggregate with % of sessions?
Flags: needinfo?(fbertsch)

Comment 3

2 months ago
Are there valid reason to reset these counts on certain subsession splits? I can see something like an environment change, like installing a new addon, causing an increase in ghost windows for that new subsession could be pretty valuable information. Though we expect ghost windows will decrease with the move to webextensions, there seems to be some debate there and having this data would be useful. Perhaps there are other reasons too, like is there any risk of losing session data that more frequent subsession/aborted/daily pings might help collect? I'm not sure if we suspect ghost windows to be related to uptime, but that could also be useful to understand as well.

I think subsession would be acceptable, but I also don't know BDS's reasoning for wanting sessions. Is this something that can wait until he is back from PTO (14th) or do we need to answer this this week?
Flags: needinfo?(sphilp)
(Reporter)

Comment 4

2 months ago
(In reply to :Harald Kirschner :digitarald from comment #2)
> Frank, it seems hard to make that decision without better knowing the impact.
> 
> - Are there alternatives, like usage hours?

Certainly, we could have a rate of Ghost Windows, with the denominator being session_hours. Alternatively, if we make the numerator sessions_hours and the denominator # of Ghost Windows, we could get MTBF.

> - Is there an analysis that compares subsessions to sessions.
> - One step further, is it possible to have a simple analysis that compares
> the aggregate of % of subsessions aggregate with % of sessions?

We don't have any analysis like this, but certainly makes sense to investigate the differences between the two.
Flags: needinfo?(fbertsch)
(Reporter)

Comment 5

2 months ago
Sphilp & Digitarald - 

I'm moving this to MC because we should implement this in error_aggregates. We will be doing a backfill (see bug 1388351). This means we can use % of sessions as intended, without making any tradeoffs.

This implementation will parallel HLL Client Counts, where we can have one HLL that is count of distinct client-sessions, and another that is a Filtered HLL count of client-sessions with ghost_windows > 0. Then we can use the same calculation as client_counts to find % of sessions with ghost_windows > 0.
Assignee: fbertsch → nobody
Blocks: 1388351
Component: Datasets: General → Mission Control
Product: Data Platform and Tools → Cloud Services
Summary: Add % of sessions for ghost_windows to quantum_rc → Add % of sessions for ghost_windows to error_aggregates
(Reporter)

Updated

26 days ago
Assignee: nobody → mdoglio
Status: NEW → RESOLVED
Last Resolved: 26 days ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.