1142165 - Create a specification for Telemetry "session stitching" and "client stitching"

Status: RESOLVED INCOMPLETE

(Cloud Services Graveyard :: Metrics: Pipeline, defect)

Description

[Mark Reid [:mreid]]

In order to provide output that is more amenable to analysis, we need a specification for how to combine session fragments into full sessions, and how to combine a set of client submissions into a single document per client.

Session stitching may be a subset of client stitching, or they may be different ways of combining the data.  If they are to be different, we should create a separate bug for each one.

Comment 1

["Saptarshi Guha[:joy]"]

I would like to mention that we have two types of session-fragment-for-a-stable-id aggregation

1. A single record that is the collection(be it set/vector/array/list/ whatever) of all session fragments for that stable-id. There is no concept of order  - it is a set of session fragments.

2. A way of combining the fragments in some other order e.g. by time or by day etc. 

Number (1) is straightforward(at least it appears to be). (2) needs discussion as to how to combine.

Regards
Saptarshi

Comment 2

[Mark Reid [:mreid]]

(In reply to "Saptarshi Guha[:joy]" from comment #1)
> I would like to mention that we have two types of
> session-fragment-for-a-stable-id aggregation
> 
> 1. A single record that is the collection(be it set/vector/array/list/
> whatever) of all session fragments for that stable-id. There is no concept
> of order  - it is a set of session fragments.
Concatenating several submissions into a single set is a form of stitching, but I agree that this task is clear and doesn't require discussion.

> 2. A way of combining the fragments in some other order e.g. by time or by
> day etc. 
This part is what this bug is intended to determine. We need requirements from people who would like the data stitched together into various larger views.

Comment 3

[Benjamin Smedberg]

Discussed this today: the by-profileID API will for the moment be returning a sequence of raw payloads, which is also what will be available on the client. We'll experiment with different ways to stitch that together using postprocessing scripts, but we don't need to come to a single solution for that problem yet.

Thus I'm going to mark this INCOMPLETE as it's not something we need to directly track.