1106030 - Kibana query to report active weekly, bi-weekly or monthly desktop client users

Status: RESOLVED WONTFIX

(Cloud Services :: Operations: Metrics/Monitoring, task)

Comment 1

[Katie Parlante]

Romain, how long do they need to have been in a room with another user for the call to count as "successful"?

Comment 2

[Romain Testard [:RT]]

I think we want here to report calls technically successful where both peers have the opportunity to communicate if they want to (we then have another bug for call duration distribution) - I mean by that no minimal duration.

That said I am not sure which events you are basing your reports on and if these events are a true reflection of "2 users in a room concurrently". There may be timeout values that we need to take into account to consider that both peers have had a chance to be in a room - Mark/Alexis is there such timeout we should consider to be guaranteed that if 2 peers have been together in a room for X seconds it means that technically the call was successful?

Comment 3

[Mark Banner (:standard8)]

(In reply to Romain Testard [:RT] from comment #2)
> That said I am not sure which events you are basing your reports on and if
> these events are a true reflection of "2 users in a room concurrently".
> There may be timeout values that we need to take into account to consider
> that both peers have had a chance to be in a room - Mark/Alexis is there
> such timeout we should consider to be guaranteed that if 2 peers have been
> together in a room for X seconds it means that technically the call was
> successful?

Currently the messages we get are:

- Room Join
- Room Refresh (iirc every 5 mins * 0.9 - the factor is inserted by the client to ensure we hit the refresh time)
- Room Leave

These will be received one set per user.

If there's no room leave after 5 minutes from a join or refresh, then the user crashed or had some other issue. We don't know at which part in that 5 minutes it happened.

Obviously to determine if two people are in the room at the same time, we need to analyse individual room tokens for when the room join -> room leave period for two users overlaps.

Comment 4

[Romain Testard [:RT]]

(In reply to Mark Banner (:standard8) from comment #3)
> (In reply to Romain Testard [:RT] from comment #2)
> > That said I am not sure which events you are basing your reports on and if
> > these events are a true reflection of "2 users in a room concurrently".
> > There may be timeout values that we need to take into account to consider
> > that both peers have had a chance to be in a room - Mark/Alexis is there
> > such timeout we should consider to be guaranteed that if 2 peers have been
> > together in a room for X seconds it means that technically the call was
> > successful?
> 
> Currently the messages we get are:
> 
> - Room Join
> - Room Refresh (iirc every 5 mins * 0.9 - the factor is inserted by the
> client to ensure we hit the refresh time)
> - Room Leave
> 
> These will be received one set per user.
> 
> If there's no room leave after 5 minutes from a join or refresh, then the
> user crashed or had some other issue. We don't know at which part in that 5
> minutes it happened.
> 
> Obviously to determine if two people are in the room at the same time, we
> need to analyse individual room tokens for when the room join -> room leave
> period for two users overlaps.

Thanks.

A = Count of overlaps when 2 peers have joined a room before the other peer leaves
B = Count of instances where 2 peers are in a room and one or 2 peers never left it OR one or 2 peers never generated a refresh

Valid count of room conversations = A - B

Sounds right?

Comment 5

[Alexis Metaireau (:alexis)]

On the server side, we know normally when a user joins and when a user leaves. This should be enough to find out how long 2 users where around.

Katie, do you agree on that?

Comment 6

[Katie Parlante]

(In reply to Alexis Metaireau (:alexis) from comment #5)
> On the server side, we know normally when a user joins and when a user
> leaves. This should be enough to find out how long 2 users where around.
> 
> Katie, do you agree on that?

Yes, we can track when a user joins/leaves, but we also need to count the case where we never see a leave event. In that case, perhaps we want to compare join/last refresh. We might be able to do this fairly easily with current logs using the heka sessionization stuff. 

For this case (recurring users) we're using the "participants" logging (
https://bugzilla.mozilla.org/show_bug.cgi?id=1124371). I do think we should be measuring the times ourselves as well (separate bug).

Comment 7

[Katie Parlante]

Here's a bug for doing something to collect/process that timing information: https://bugzilla.mozilla.org/show_bug.cgi?id=1126801

Comment 8

[Wesley Dawson [:whd]]

Reopen if necessary.