►
From YouTube: 2022-02-09 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
A
Okay,
so
let's
let's
get
started
so
on
the
agenda.
I
I
just
have
my
agenda,
so
what
I
was.
What
I
would
like
to
do
today
is
like
we.
So
last
time
we
talked
we,
we
were
going
to
come,
come
to
this
meeting
with
some
more
concrete
examples,
and
so
so
I
did
that
from
the
browser
side
I
would
like
to
just.
A
I
would
like
to
demo
like
what
what's
possible
currently-
and
I
think
a
lot
of
you
are
familiar
familiar
with
this,
so
I
apologize
if
I,
if
I'm
like,
showing
things
that
you
already
know,
but
I
wanted
to
kind
of
show
it
as
as
kind
of
a
starting
point
for
discussion
and
then
then
I
would.
I
have
potential
proposal
that
I
think
you
know
that
I
think
maybe
from
my
perspective
might
work,
and
so
I
would
like
to
you
know,
talk
about
that
and
get
your
feedback.
A
Does
anyone
have
any
any
other
topics
before
I
get
started?
This
might
take
some
time.
E
Not
not
before
we
get
started,
but
but
maybe
afterwards
I
just
wanna
point
out
the
the
logging
sig
is
trying
to
sort
out.
You
know
some
final
bits
about
their
data
model
and
they
currently
seem
to
be
going
in
a
direction.
That's
maybe
opposite
of
the
direction
we
want.
So
maybe
at
the
end
of
this
we
should
figure
out.
If
we
have
a
an
idea
about
what
top
level
fields
we
might
need
to
make
processing
whatever
log-level
stuff.
E
A
So
I
have
some
some
notes
that
I'm
going
to
follow,
so
I
think
I
so
I've
been
thinking
about
the
things
that
you
that
you
presented
had
last
week
and
we
also
had
lots
and
lots
of
discussions
around
this.
I
think
many
that
many
times
we
have
a
draft
of
the
proposal
that
at
least
lists
a
bunch
of
options.
Now
you
know
we
went
through
different
types
of
events.
A
A
What
are
the
use
cases?
So
I
think
I
think
one
is
like
you
want
to
get
some.
You
want
to
get
some
information
across
all
sessions
like
and
on
those
types
of
that
type
of
telemetry,
like
is
definitely
makes
sense
as
metrics.
Those
are
things
like
the
timing.
How
long
does
my
application
take
to
start?
A
You
know
any
any
kind.
Any
types
of
those
events
that
have
timing
in
them
across
and
are
aggregated
should
be
as
metrics.
I
think
there
is
also
a
use
case
for
client-side
applications
to
participate
in
distributed
traces.
A
You
know
there's
there
is.
There
is
instrumentations,
obviously
that
for
like
http
calls
that
make
a
call
to
the
back
end,
so
you
want
to
be
able
to
for
those
client
spans
to
to
appear
as
a
part
of
those
traces.
A
So
you
can
tie
the
you
know
the
what
what
caused?
What
caused
all
those
operations
in
the
back
ends
from
from
the
client
side,
and
then
I
think,
the
the
unique
one,
the
unique
use
cases
that
are
for
for
client-side
telemetry
are
about
around
sessions
and
sessions.
I
think
we
are
useful
to
things
like
understanding
the
user,
behavior,
maybe
reproducing
some
some
scenario
by
retracing
the
steps
that
the
user
took
and
perhaps
also
correlating
different
types
of
events
so
like.
A
I
know
that,
from
from
the
browser
side,
for
example,
like
you
may
have
like
different
timing
events-
and
you
want
to
correlate
like
say
when
this
when
this,
when
this
timing
happens.
Like
then
like
this,
one
is
affected,
or
things
like
that,
and
it's
hard
to
do
that
with
metrics.
So
then,
then,
what
I
did
is
I
I
tried
to
look
at
the
different
types
of
events.
We
only
talked.
A
We
listed
all
those
examples,
so
I
think
that
the
ones
that
I
could
come
up
with
like
different,
like
classes
of
events
that
happen
in
in
client-side
applications
like
they're
definitely
network
calls
are
kind
of
special
part
distributed
tracing
no
question
about
that.
Those
should
be
represented
as
spans.
A
Then
I
think
the
next
one,
that's
particularly
of
interest,
is
user
interactions,
so
the
things
that
you
know
when
the
user
interacts
with
the
application
like.
How
do
we
capture
those
that's
the
question?
A
Then
there
are
timing
events
we
discussed
those
last
week
a
little
bit
so
things
like
those
are
particularly
important
during
the
startup
of
the
application,
and
then
there
are
errors,
and
perhaps
events
generated
by
the
by
the
runtime
environment,
such
as
such
long
tasks,
which
are
kind
of
also
unique,
and
then
there
could
be
custom
events
that
that
users
might
be
might
want
to
capture
themselves
that
represent.
A
That's
represent
something
unique
to
their
application,
for
example,
if
they
want
to
capture
like
a
business
event
of
something
being
added
to
a
shopping,
cart-
or
you
know
a
checkout
or
things
like
that.
So
so
I
just
wanted
to
that's
just
kind
of
mice
kind
of
playing
laying
the
ground
for
the
discussion.
So
my
so.
The
two
that
I
would
like
to
kind
of
focus
on
is
the
timing,
events
and
the
user
interactions.
A
And
again
you
you
all
are
familiar
with
this,
so
I'm
just
I'm
showing
something
that
you
already
showed,
but
I
just
wanted
to
show
a
couple
of
things
so
so
for
like
the
for
like
so
we
have
for
browser
instrumentation
we
have
like.
We
have
the
document
load,
plugin
or
instrumentation.
We
have
the
network
calls
instrumentation
and
we
have
the
user
interaction,
instrumentation
or
plugin,
so
so
for
document
load.
Let's
see,
I'm
gonna
do
five
minutes.
A
So
for
the
for
the
document
load
except
basically
so
you
have,
you
have
a
top
level
span.
That
represents
the
operation
of
loading,
the
document
and
then
there
are
child
spans
that
that
represent
actually
retrieving
each
of
the
resources.
So
these
this
child
pen,
second
child,
spend
here.
A
This
checking
second
child
span,
like
is
is
represents
loading
like
the
loading,
the
the
document
over
the
network,
and
this
one
is
some
resource,
but
the
top
level
top
level
one
is
is:
is
the
operation
of
loading
of
like
the
whole
operation.
That
includes
all
the
resources,
and
if
you
look
at
the
like,
we
we
already
right
now
are
adding
some
events
on
these
on
these
spans.
So
there
are
things
like
fetching.
A
Unloading
like
like
first
first
paints
down
content
down
content
loaded
event,
so
so
this
so
we're
already
adding
some
some
events,
some
timing,
events
on
on
this
span
right
and
then,
in
addition
to
that,
like
these,
these,
these
resources
also
have
timing
events,
and
these
come
from
the
resource.
Timing,
api
and
they're.
Like
things
like,
you
know
when,
like
the
domain
look
up
when,
when
did
that
happen,
when
when
did
the
fetch
start,
when
did
the
response
start?
This
thing's,
like
that.
A
So
so,
like
back
to
our
conversation
last
week
when
we
were
talking
about
well,
maybe
like
these.
These
timing
events
should
like
should
be
represented
as
spans
because
they
they
represent
latency.
Well,
I
think
my
counter
argument
is
like
we're
already
capturing
them,
as
as
events
right
now
like
the
ch
and
okay.
So
the
challenge
like,
if
you,
if
you,
if
you
imagine
like
that,
all
of
these
having
them
now
as
spans
instead,
then
you
know
like
I
think
I
think
that
would
not
really
make
sense
in
a
trace.
A
So
like
okay,
so
let
me
go
back
to
this,
so
so
we
have
so
they're
they're
like
in
browser.
There
are
many
types
of
these
events,
the
timing,
events
there
is
the
window
load,
it
just
happens
to
be
one
of
them
and
select
the
dock.
This
this
span
here
is
essentially
like
the
end
of
the
span.
Is
the
window
load
event,
but
but
the
the
order?
Sorry,
the
order
of
these
events
is
like
there
are,
like
other
events,
they're
like
there's
paint
events.
A
There
is
like
first
bite
time
to
interaction,
there's
largest
content
for
content
for
paint.
A
There
could
be
element,
timing,
events,
user
timing,
events
so
and
the
order
of
these
events
is
non-deterministic,
so
you
can't
you
can't
really
say,
like
I'm
gonna
wait
for
you
know,
I'm
gonna
open
a
span
and
wait
for
all
these
to
happen
so
that
I
can
record
them
as
spam
events.
So
some
of
them.
You
know,
I
think
you
know
some
of
them
here.
A
Can
you
can
say
some
of
them
will
always
happen
before
window
load,
but
some
of
them
will
not.
So
so
I
think
there's
there's
a
need
to
represent
these.
You
know
outside
of
the
span
and
I
think
the
you
know
I
just
listed
some
options,
but
I'm
not
gonna
go
through
them.
Now,
I'm
gonna
just
jump
jump
to
the
proposal,
then
the
other
thing
that
the
client-side
instrumentation
the
current
browser
instrumentation
has
is:
is
the
the
user
user
interaction
one?
A
A
This
click
trace,
so
the
top
level
the
top
level
span,
represents
the
user
interaction
and
then
then,
underneath
that
user
interaction
caused
and
a
network
request,
and
then
the
rest
of
these
spans
are
back
in
spans,
but
you
can
so
the
the
nice
thing
about
this
is
that
you
can
visualize
the
the
causality
of
the
user
interaction
with
the
network
and
what
you
know
like
what
it
costs
like
the
network
call,
but
I
think
the
the
challenge.
A
The
challenge
like
with
with
having
this
this
span
is
like
is,
is
knowing
so
okay,
it's
not
challenge
yeah,
it
is
so
the
challenge
the
challenge
is
knowing
how
to
determine
like
the
duration
and
like
what
does
that
span
actually
represent.
What
is
that?
What
does
that
duration?
Tell
you
so
this
this
you
know
like
the
current
instrumentation
is
looking
at
at,
like
all
the
all
the
work
that
was
started
and
it's
tracing
all.
A
You
know
it's
waiting
for
all
the
work
that
was
spawned
from
that
interaction
and
when
everything
is
ended,
then
then
it
will
end.
This
top
level
span
from
that
may
or
may
not
represent,
actually
what
the
user
experience
is
right
so
like
what
is
that?
What
did
that?
What
does
this
tell
you?
A
So
I
think
my
my
argument
here
is
that
my
twofold,
like
one,
is
that
the
the
having
the
user
interaction
representative
expands
in
my
opinion
makes
sense,
because,
because
you
want
to
represent
the
causality,
you
want
to
say
like
this.
This
interaction
calls
this
other
work,
but
but
the
duration
is
kind
of
questionable.
There
must
be.
A
There
might
be
some
instrumentations
that
can
reliably
say
this
is
what
it
represents,
but
some
instrumentations
like
may
not
be,
and
in
fact
like,
like
last
time
when,
when
we
talked
on
friday,
I
think
bryce,
who
was
talking
on
from
the
ios
perspective,
said
that
it's
not
possible
in
ios,
so
they
would
still.
You
know
they
would
still
need
a
way
to
capture
these
events.
A
A
Okay,
any
questions
or
comments
so
far.
If
I
jump
into
the
proposal.
A
Okay,
so
my
proposal
and
again
like
I'm,
not
saying
that
maybe
this
is
like
this
is
definitely
not
finalized,
but
I
wanted
to
just
like
throw
it
out
there
because,
like
we
have
lots
of
different
options
and
I
wanna
I
wanna
hear
like
if
this
would
or
would
not
work
so.
A
A
So
I
think
from
like
the
client
side,
like
the
special
thing
about
the
client-side
telemetry,
is
the
interaction,
the
the
interaction
events
and
perhaps
the
concept
of
a
session
as
well.
Like
again,
I'm
going
back
to
these
examples
like
in,
like
zip
code
novice
where
tracing
tracing
tool.
A
So
all
these
all
these
different
things
are
separate,
like
the
document
load
and
the
different
interactions
are
currently
visualized
as
separate
traces
in
this
they're
not
tied
in
any
way,
and
I
think
even
if
they
were
tied,
I
don't
think
they
would
fit
well
like
in
in
tracing
and
current
tracing
tools,
because
they're,
not
these
tracing
tools
are
not
built
to
visualize
or
analyze
sessions
right.
A
But
I
just
wanted
to
point
out
that
the
special
thing
about
client-side
is
the
interaction
events
and
sessions.
That's
what
kind
of
differentiates
this
from
from
tracing
interaction.
Events
can
include
anything
that
is
triggered
by
the
end
user,
interacting
with
the
application,
such
as,
like
obvious
events
like
clicks
and
tabs,
but
also
page
load,
page
load,
app,
startup,
visual
visibility,
change,
for
example.
A
So,
like
document
load
like,
I
would
see
that
as
an
interaction
because
the
user
initiated
initiated
like
the
document
load,
so
the
user
interacted,
but
in
some
way
with
the
application
at
the
beginning,
my
proposal
is
to
to
capture
interactions
as
spam
or
represent
them
as
fans.
The
reasons
are,
you
know
going
back
to.
My,
like
example,
is
that
you
want
to
capture
the
causality.
You
want
to
capture
like
what
affects
that
interaction
had
and.
A
So
those
spans,
if
you
capture
them
as
spans,
those
spans,
can
have
duration.
That
represents
the
operation
from
the
user
perspective
and
I'm
saying
can
because
in
some
cases
it
may
not
be
possible.
So
if
it's
not
possible,
then
it
is
a
lot
would
be
allowed
to
have
these
spans
have
zero
duration,
and
also
these
fans
may
participate
in
a
distributed
trace.
A
Other
events
are
similar
to
the
ex,
so,
okay,
so
the
time
going
back
to
the
timing
events
now
so,
in
my
opinion,
the
concept
of
those
events
is
similar
to
the
existing
concept
of
span
events.
So
we
already
again
like
we
are
already
capturing
these
events
on
on
spans
as
as
span
events,
they
they
don't
have.
They
don't
have
duration,
but
they
have
they
have
they
have
a
time
stamp.
That's
relative
to
to
that.
A
To
that
context,
the
context
of
spam
events
to
span,
I
think
the
the
context
of
events
outside
of
of
a
span
would
be
the
session.
So
I
would
my
proposal
would
be
to
represent
these
as
as
logs
they
may.
They
may
or
may
not
for
two
reasons,
so
one
is
they
may
or
may
not
be
associated
with
the
span.
A
A
I
mean
that's:
that's
how
it
was
that's
how
that
model
was
was
like
purposefully,
developed
right,
so
even
if
you
like,
if
even
if
you
go,
went
back
like
to
the
the
current
instrumentation,
where
we
have
a
bunch
of
events
like
on
the
document
load,
we
could
potentially
extract
them
and
capture
them
as
logs
and
still
tie
them
back
to
the
to
the
span.
That
represents
the
interaction
the
document
load,
interaction,
okay,
so
that
those
are
kind
of
the
two
ones
that
I
wanted
to
tackle
the
most
there
may
be
other.
A
You
know,
for
example,
like
the
http
calls
or
any
any
type
of
operation
that
can
either
participate
in
a
in
a
distributed
trace
or
that
that's
intended
to
measure
a
compute
operation
like
inside
inside
a
client
application,
so
you
can
still
have
trace
like
inside
a
client
application.
If
you
want
to
trace
code
in
the
client
side,
you
know
client-side
code.
So
before
I
move
forward
any
questions
about
this.
F
On
the
user
interactions,
when
you
represent
them
as
pants-
I
I
don't
know
if
you
mentioned
this
the
same
way,
but
I
I
am
thinking
that
the
actual
content
of
those
events
will
still
be
in
the
span.
Events
which
you
know
could
be
in
the
logs,
but
the
fact
that
they
are
related.
F
F
Not
that's,
that's
not
how
it
is
today
when
I
look
at
the
links
that
ted
gave
last
time
I
looked
at
a
few
of
them
all
the
data
is
in
the
span
attributes
itself,
not
necessarily.
B
F
Yeah
and
with
respect
to
the
timing
events-
I
I
don't
know
you're
not
explicitly
mentioning
here,
but
I
I
think
ted's
point
last
time
was
and
correct
me
from
wrong
that
they
should
be
represented
as
metrics
instead
of
as
events
right
from
you
know
the
source.
So
I
think
it's
possible
that
both.
A
F
Go
ahead
yeah
now,
when
we
talk
about
both,
I
was
thinking
given
that
matrix
has
this
concept
of
exemplars.
You
know
we
should
leverage
that
I
mean
we
could
leverage
that,
where
you
know
you
could
still
send
a
you
know
a
few
events.
E
E
Open
telemetry
can
be
efficient
at
extracting
metrics
from
events,
because
this
and
metrics
from
spans
as
well,
because
this
is
actually
maybe
just
like
a
broad.
A
broader
thing
we
want
to
be
doing
in
general
is
like
dynamically
generating
metrics
from
events
and
traces.
So
the
question
I'm
posing
to
him
is
like
well.
E
How
would
you
want
to
adjust
our
events
and
spams
data
model
to
potentially
make
it
more
efficient
to
extract
metrics
out
of
these
things,
but
it
seems
like
that
that
might
work
be
a
little
less
hackneyed
than
than
going
the
other
way
of
making
these
things
metrics
like
like
it,
it
seems
like
it
makes
treating
them
as
events
a
lot
harder
from
talking
to
him
like
like,
like,
I
think
the
people
trying
to
reconstruct
these
sessions
will
just
probably
be
a
lot
saner
if
they're,
not
just
just
because
the
way
the
sampling
works
with
things
like
like
you
just
have
so
many
different
kinds
of
sampling,
falling
floating
around
and
exemplars
would
be
separate
form
of
sampling
from
all
the
other
sampling
you're
doing,
and
so
it
just
it
seemed
like
that.
E
Part
was
actually
maybe
a
headache
that
we'd
want
to
avoid
sampling,
makes
everything
complicated.
A
Yeah
yeah
I
mean
I,
so
I
have
the
next.
That's
exactly
my
next.
Two
topics
is
around
session
and
sampling,
which
I
I
don't
have
answers
for,
but
what
I,
what
I
kind
of
envisioned
right
now
was
was
that
you
know
like
in
the
worst
case,
we
always
gener
generate
metrics
for
these
timing
events
and
then,
if
we
have
some
kind
of
sampling
mechanism
for
sessions
then
like.
If
the
session
is
sampled,
then
you
would
capture
those
events
as
well.
A
F
Yeah
we
could
talk
about
sessions
itself.
You
know
how
to
represent
sessions.
That
was
one
of
the
topics.
B
D
B
F
Know
asked
in
on
slack
last
night
that
if
we
were
to
represent
them
as
a
trace,
the
spans
could
only
be
part
of
one
trace
right.
So
the
the
network
calls
the
api
calls
are
already
part
of
you
know
other
traces.
F
E
Well,
you,
you
would
start,
you
would
have
to
be
able
to
start
a
parent
span
say
right
at
the
beginning
of
your
session,
and
then
all
of
these
other
traces
would
then
become
children
of
that
parent
span.
But
for
a
couple
of
reasons,
I
think
that
that
would
be
problematic.
E
There's
there's
just
the
the
data
modeling
aspect
of
tightly
coupling
them
all
into
one
trace.
You
now
have
one
gigantic,
potentially
never
ending
trace,
because
sessions
can
go
on
for
a
really
long
time,
but
on
a
more
practical
matter,
just
the
way
spans
are
generated
right
where
they
have
a
start
and
an
end,
and
then
you're
flushing
them
out
of
the
system
when
they
end
that
doesn't
really
line
up
very
well.
With
a
lot
of
session
edge
cases.
E
Sessions
can
persist
across
things
like
page
reloads
sessions,
don't
have
a
clear
end
point
right,
like
sometimes
the
user
might
just
close
the
browser
window
and
other
times
they
may
just
like
wander
off
and
never
come
back
and
the
way
we
spans
are
currently
implemented.
That
would
it
would
just
make
it
really
difficult
to
actually
figure
out
when
to
end
that
session
span
and
and
how
to
send
it
so
yeah.
I
can
understand.
D
That
we
expect
currently
in
the
end
of
the
expanse
yeah
but
yeah,
but
maybe
we
could
have
some
kind
of
I
mean
we
were
talking
about
zero
duration
expanse
for
some
for
some
of
our
use
cases,
maybe
having
some
time
of
open-ended
span
that
you
that
it
exports
everything
that
comes
out
from
that
something
like
that,
instead
of
only
at
the
end,
it
might
work.
D
For
that
I
mean,
I
think
it's
an
implementation
problem
that
one
of
exporting
and
saving
the
data
and
yeah
it's
true
that
living
longer
than
a
reload
or
even
a
day
after
when
you
connect
or
you
resume
your
session
that
can
be
difficult
to
handle
but
yeah.
Maybe
it's
just
an
implementation
issue,
not
a
concept
issue.
D
E
I
mean
it,
it's
it's
not
impossible.
I
think
it's
just
a
question
of
like
what's
what's
the
most
straightforward
approach
and
it
does
seem
like
sessions,
don't
actually
need
start
and
end
times
on
their
own.
I
could
be
wrong
about
that.
It
doesn't
seem
like
you're
trying
to
measure
the
latency
of
a
user
session.
E
So
even
though
a
span
and
a
session
seems
like
similar
closures,
I
think
there's
there's
some
meaningful
differences
between
what
you're
you're
trying
to
do
with
them,
and
given
that
there's
also
some
practical
differences
it
might,
it
might
be
just
more
effective
to
to
to
model
sessions
as
as,
like
another
context
that
things
can
be
attached
to
that.
E
But
again,
that's
that's
just
my
my
instinct
from
having
worked
with
the
tracing
stuff
for
a
long
time,
so
create
a
new
entity
for
that
a
new
entity
or
it's
yeah
yeah,
either
an
entirely
new
entity
or
we're
saying
like
we're
just
having
a
context
and
we're
attaching
session
ids
to
as
attributes
on
on
everything.
Okay,
I.
F
E
I
would
say
modeling
a
session
as
a
span
is
just
right
now
at
least
probably
the
most
difficult
way
to
go
about
implementing
it.
E
It
would
have
a
lot
of
shortcomings
and
would
require
quite
a
bit
of
deep
changes
to
how
things
work
to
make
it
work.
So
it
just
seems
like
that's
that
that
would
be
the
long
road
to
to
doing
it.
A
The
the
other
argument
that
I
would
have
against
that
is
that
the
current
tracing
tools
are
not
built
to
analyze
sessions.
They're
able
to
analyze,
like
you
know,
short
short
traces
so
like
what
would
be
the
benefit
of
representing
a
session
as
a
span.
D
We
could
use
baggage
to
send
that
also
in
the
network
request.
Maybe
if
we
have
a
context
so
pass
that
there,
but
that
would
be
a
something
that
it
will
solve.
E
Yeah,
I
think
it's
definitely
interesting
to
send
session
information
as
as
baggage,
potentially
it's
just
more
of
a
question
of,
but
even
if
we're
doing
it
as
baggage,
that's
a
bit
different
than
did
modeling
the
session
as
a
span.
F
I
want
to
understand
this
baggage
thing.
A
little
more
backage
is
typically,
you
know,
equivalent
to
a
context,
propagation
right.
You
propagate
data
across
services,
whereas
for
sessions
so
far
at
least
at
least
in
in
the
product
at
cisco.
It
has
been
entirely
on
the
client
side.
When
we
talk
about
end
user
sessions,
we
only
talk
about
how
the
end
users,
you
know
navigate
across
you
know
the
end
user
application.
F
The
are
when
you
talk
about
baggage.
Are
you
talking
about
propagating
the
session
context
across
services
so
that
you
also
include
the
behavior
of
the
back
end
aspects
in
the
sessions.
E
Yeah,
the
so
baggage
is
just
a
general
purpose.
Context
propagation
tool
in
open,
telemetry
so
on
its
own
baggage,
doesn't
do
anything
but
allow
you
to
propagate
values,
down
the
transaction
and
it's
often
useful
to
propagate
indexes
for
being
able
to
to
correlate
data
or
add
dimensions
to
metrics.
E
Add
them
as
attributes
to
spans
things
like
that.
So
it's
pretty
common
for
people
to
like
common
things.
People
use
baggage
for
to
attach
to
data
structures
downstream.
Are
things
like
user
id
account
id
project
id
those
kinds
of
things
session
id
seems
like
a
natural
thing.
People
would
want,
but
I
agree
it's
not
it's.
E
It's
not
part
of
like
the
it's
not
like
a
requirement
for
core
functionality
of
existing
tools.
Yeah.
I
will
say,
though,
when
we're
doing
this
modeling,
we
do
it's
very
common
for
traces
metrics
like
all
these
different
groups
to
to
be
like.
Well,
you
know
the
the
current
backend
for
x
doesn't
only
looks
at
this
one
slice
of
data.
E
It
doesn't
look
at
these
other
slices
of
data
and
I
do
think
we
need
to
make
sure
our
model
that
we
come
up
with
is
going
to
be
fairly
efficient
for
existing
backends
to
be
able
to
ingest,
but
at
the
same
time
I
wrote
an
o'reilly
report
about
it,
a
few
people
linked,
so
I
won't
go
into
like
a
big
spiel
here,
but
but
I
do
think
the
way
we
have
like
carved
these
things
up
into
these
data
silos
is
something
that's
going
to
change.
It's
not
actually
a
great
way
to
do.
E
You
know
people
need
to
do
some
kind
of
monitoring,
so
they
go
build
a
tool
to
do
that
monitoring
and
they
build
client
instrumentation
that
feeds
stuff
into
that
tool,
and
so
they
just
naturally
get
built
as
these
kind
of
like
separate
things,
but
you
can
see
going
forwards
if
you
have
a
data
model
where
it's
all
connected
into
a
unified
graph,
so
the
data
level,
regardless
of
what
you're
doing
with
it.
You
have
a
unified
graph
of
data.
E
Then
it
becomes
possible
to
build
new
tools
that
maybe
look
at
this
data
in
a
different
way
and
maybe
have
a
more
cohesive
picture
and
when
you
in
particular,
when
you
want
to
apply
machine
learning
to
this
stuff,
to
find
correlations
between
various
things
you
you
need
to
have
that
data
unified,
because
otherwise
you
just
can't
you
can't
do
it
because
and
it
has
to
go
through
some
human's
head
to
make
the
the
correlations.
So
so
that's
just
a
thing.
E
We
should
keep
in
mind
when
we're
when
we're
designing
this
stuff,
on
the
one
hand,
make
sure
it's
efficient
for
existing
tools,
but
on
the
other
hand,
make
sure,
since
open
telemetry
is
now
generating
all
of
this
data
that
it's
it
actually
is
connected
into
a
unified
graph
in
some
way.
So
yes,
thanks.
F
So
that
thing
is
just
reiterating
what
you
said:
this
session
itself
is
only
available
as
a
context
similar
to
a
trace
context,
and
there
is
no
object
for
trace
itself.
Right
trace
is
only
present
as
an
id
in
the
spans
so
similar
to
that.
Even
for
a
session
you
know.
F
Maybe
when
you
start
a
new
session,
you
could
emit
an
event
saying:
hey
session
has
started,
but
it's
just
another
event,
part
of
the
same
session,
part
of
the
new
session,
but
otherwise
the
session
is
only
available
as
an
id
in
the
you
know
different.
You
know.
Other
objects.
E
I'm
I'm
curious
whether
sessions
need
attributes.
I
actually
for
the
record.
I
mean
I'm
not
pushing
on
this
right
now,
but
I
do
think
not
having
trace
attributes
is,
is
a
hole
in
our
model
right
now
that
the
people
are
like
end.
Users
today
want
something
like
trace
attributes,
and
this
is
actually
a
common
use
for
baggage,
because
you
don't
have
a
way
of
saying
this
is
an
attribute
on
this
trace.
E
What
people
end
up
having
to
do
is
taking
that
attribute
and
attaching
it
to
every
single
span
in
the
trace
which
which
works
is
now
just
a
span
attribute,
but
the
the
overhead
of
doing
that
is
significant
compared
to
just
if
we
had
the
concept
of
a
trace
attribute
that
could
be
sent
once
and
then
you
know
indexed
on
the
back
end
and
I
do
wonder
whether
sessions
are
going
to
end
up
being
like
the
simple
way
we
could
do
it
today
at
open
telemetry.
E
Is
you
have
a
session
that
you
can
put
in
context
or
context
manager,
and
then
you
can
write
a
span
processor
and
a
log
processor
that
every
time
you
start
a
span
and
every
time
you
create
an
event.
It
just
looks
in
the
context
and
if
there's
a
session
id
it
attaches
it
as
an
attribute
to
the
span
or
the
event
or
the
spanner
the
log.
E
So
we
could
totally
do
that
today.
We
just
have
to
figure
out
the
little
bit
of
like
how
do
you
make
sure
that
session
gets
injected
in
and
like
the
parent
context,
that
all
that,
like
the
background
context
that
all
the
other
contacts
come
out
of
or
something
like
that,
that
there'd
be
a
little
bit
of
tricky
there,
but
but
that
would
be
it
and
then
you
would
have
it
as
an
attribute
on
all
of
these
things.
E
E
That
that
would
be
great,
obviously
that's
like
less
efficient
than
going
the
next
step
and
saying
you
know
sorry,
if
it's
just
an
id,
then
it's
probably
no
more.
The
efficiency
is
probably
the
same
of
just
stapling
as
an
id
as
an
attribute
on
everything.
E
However,
if
you
want
to
start
associating
more
attributes
with
a
session,
then
you
also
need
to
add
some
kind
of
session
object
that
that
we're
going
to
emit
and
probably
would
want
how
you
attach
sessions
to
these
other
items,
to
be
something
more
like
a
field,
a
protobuf
field
and
not
an
attribute,
but
to
to
me
that
as
far
as
implementing
sessions,
I'm
guessing
that's
probably
the
easiest
way.
Forwards
is
just
starting
with
attributes
and
then
and
then
seeing
if
we
need
more
info,
but.
B
E
Yeah
is
that
the
same
martin,
with
with
you
guys.
A
Yeah,
the
only
thing
that
I
can
that
I
can
think
of
is
like.
Would
there
be
things
like,
like
a
user
user,
identifying
information
that
you
might
want
to
capture
along
with
the
session
yeah.
F
F
It's
just
that
you
know
it
could
be
derived
on
the
back
end
and
you
know
optionally.
You
know
we
could
send
it
as
yet
another
event
and
another
event,
type
from
you
know
from
the
agent
itself
from
the
source
yeah,
where
you
put
all
the
general
electric
resource
like
information
like
who
is
this
user?
F
Yeah
and
you
would
still
need
an
id
in
each
of
the
objects,
so
if
it
because
at
the
end
you
want
to
know
which
session
your
events
are
part
of,
so
you
need
a
reference.
F
So
since
we're
talking
about
just
an
id
in
each
of
the
objects,
it's
okay
to
send
it
in
individual
spans
rather
at
the
resource
level,
and
it's
also
possible
that
each
of
these
you
know,
could
be
part
of
multiple
sessions
simultaneously.
So
if,
let's
say
we
expose
sessions
as
an
api
to
customers,
you
know
they
could,
let's
say
a
checkout
transaction.
You
know
that
could
be
you
know
they
could.
F
They
could
define
a
custom
event,
sorry
custom
session,
they
could
define
begin
and
end
of
custom
sessions,
and
in
that
case
you
know
your
your
spans
could
be
part
of
multiple
sessions
and
in
that
case,
a
separate
session
start
and
session
end.
Having
them
explicitly
would
still
be
helpful.
It's
just
that.
You
know
we
should
be
ready
to.
You
know
not
see
them
because
of
the
natural
reasons
we
know
of
where
you
know
the
end
is
not
guaranteed.
E
Yeah
yeah,
if
we
make
an
api
for
us
to
be
able
to
create
sessions
and
all
a
session
is,
is
like
basically,
a
set
of
attributes
like
if
you
say
a
session
is
just
a
set
of
attributes,
that's
going
to
be
attached
to
every
log
and
span,
and
maybe
metrics
too.
I
don't
know
totally
how
we
do
that.
Maybe
that's
exemplars
we're
just
saying
everything
when
this
context
is
available.
E
This
is
just
attributes
that
are
going
to
get
attached
to
everything
and
the
default
one
we're
going
to
create
in
all
the
instrumentation
we
hand
the
end
users
we'll
have
you
know
we'll
define
an
attribute
called
you
know,
session
like
a
semantic
convention,
namespace
called
session
and
session.id
and,
like
anything
else
and
that'll,
be
like
the
official
session
that
we're
using
in
our
instrumentation,
but
once
we've
done
that
work,
you're
right,
there's,
no
reason
why
you
can't
give
that
to
the
end
users
and
say
here:
you
know,
create
your
own
bounding
context.
E
If
you
want,
if
you,
if
you
want
to
use
this
tool
to
like
attach
whatever
these
attributes
are-
and
you
just
want
them
attached
to
like
all
this
stuff
for
for
this
period,
you
know
like
here's,
a
tool
for
for
doing
that,
because
all
it's
doing
is
just
attaching
attributes
so
yeah.
You
could
expose
that
to
end
users,
if
you
wanted
to.
F
And,
and
by
the
way,
I
think
the
only
reason
I
mean
you
initially
propose
putting
them
in
resources
right.
That
is
fine.
I
only
mentioned
about
putting
them
as
attributes
in
the
spans
is
because
you
mentioned
the
resources
are,
are
not
mutable
right.
You
know.
E
E
Yes,
they
don't
they
don't
change,
and
so
there's
plenty
of
things
like
you
mentioned,
like
browser
user
id
and
stuff
like
that,
there's
a
bunch
of
stuff
that
maybe
doesn't
doesn't
change
dynamically
and
and
so
you
could
put
them
as
resources.
But
enough
of
this
stuff
does.
E
But
the
thing
we're
missing
right
now
and
we're
missing
it
for
traces
as
well.
Is
these
things
that
are
somewhat
dynamic,
but
it's
just
it's
just
kind
of
inefficient
to
to
staple
them
like
if,
if
the
amount
of
information
you're
trying
to
attach
in
this
manner
starts
to
pile
up,
then
you
just
have
like
an
overhead
that
you're
paying
of
doing
this
look
up
and
doing
this
attachment
on
to
every
single
thing
versus
resources
which
are
efficient
right
now,
because
you
just
you
just
the
resources
are
just
part
of
the
the
batch
right.
E
They
they
go
out
with
the
batch
of
data
right,
they're,
they're
more
like
metadata
on
the
the
connection
that
the
data
is
streaming
through,
and
so
I
just
I
just
feel
like
there's
an
efficiency
thing
that
could
be
had
at
some
point
for
something
like
trace,
attributes
and
session
attributes,
because
we
do.
We
do
at
least
with
trace
attributes
we're
seeing
we're
seeing
users
want
this.
I
even
saw
datadog
implemented
a
thing
called
like
trace
tags
or
whatever
that
just
seemed
like
that
that
concept.
F
E
Yeah,
there's
no
reason
why
you
can't
put
all
that
stuff
in
as
an
event
and
then
capture
it
that
way
totally
100,
and
then
you
just
it's
just
yeah,
and
then
you
just
have
to
unpack
the
attributes
of
all
of
these
objects.
In
order
to
to
find
this
session
id.
E
This
concept
could
be
moved
out
of
the
attributes
into
a
top
level
field,
just
because
top
level
fields
and
protobuf
the
fixed
lengths
fields,
you
don't
have
to
do
any
parsing
or
scanning
right
in
order
to
to
find
that,
and
often
on
the
back
end
right.
E
These
things
are
are
flying
in
really
fast
and
these
top-level
indices
you
may
want
to
be
grabbing
those
things
like
span
id
and
trace
id
so
that
you
can,
you
can
do
some
indexing
without
trying
to
parse
or
dig
into
the
the
attributes
which
are
variable
length,
data
structure.
So
I
guess
my
point
is
like
there's
some
like
efficiency
improvements
we
could
make
incrementally,
but
none
of
that
stuff
actually
changes
the
model
that
you're
proposing
right
now.
That's
just
like.
E
I
think
we
could
take
this
model
of
putting
this
in
a
context
and
attaching
those
attributes
session
ideas,
attributes
everywhere
and
go
out
there
and
try
to
solve
the
implementation
issues
of
like
well.
How
do
you
know?
How
do
you
make
sure
that
it's
in
the
context,
but
it's
like
there's,
actually
not
a
huge
amount
of
work?
The
only
thing
you
have
to
do.
We
already
have
a
general
purpose.
Context
object,
that's
flowing
around
that
you
can
put
this
session
id.
E
E
So
then,
you've
solved
like
the
session
problem
and
then
just
the
other
problem
is
what
martin's
been
working
on
about
like
okay.
Well,
then,
in
like
practical
terms,
we
just
have
to
decide
which
of
these
things
we
want
to
model
we're
going
to
make
an
event
which
ones
are
going
to
be
spans,
but
but
that's
actually
not
not
a
heck
of
a
lot
of
work
like
it's
not
actually
very
far
from
from
what
we
currently
have,
which
is
making
me
happy.
I
was
a
little
concerned.
E
C
E
Oh
yeah,
well,
first
martin.
Does
this
all
make
sense
to
you?
Do
you
feel
like
like
it
seems
like
you're,
you're
kind
of
driving
this
this
proposal?
I'm
I'm
not
sure
what
you
want
to
do
is
as
next
steps,
but.
A
Yeah,
I
was,
I
wanted
to
get
your
input.
I
think
my
my
next
step
that
I
envisioned
was
be
to
open
an
old
tap
that
specifically
around
data
model
for
client-side
instrumentation
and
where
we
would
propose
this
and
list
list
options
that
we
considered
in
this
in
this
seg
and
get
get
feedback
from
the
community.
E
A
So
I've
never
done
this
before
so
like.
Is
that,
like
just
like
a
example
like
repo
like
where
people
can
can
like
run
themselves,
that
kind
of
demonstrates
like
what
things
will
be
coming
out
from
an
example:
application.
E
Yeah
yeah,
it
would
be
an
example,
and
you
would
then
create
an
additional
package
if,
if,
if
this
can
be
modeled,
what
you
want
to
show
people
is
like
this
thing:
we're
modeling
could
be
modeled
like
sessions
or
whatever
we
need
to
add
could
be
modeled
as
like.
Just
this
additional
package,
we're
adding.
E
That
then
makes
use
of
our
context,
management
and
and,
like
a
span
processor
like
here's,
the
pieces,
we
have
to
add
and
kind
of
clarifying
whether
we
need
to
just
can
we
model
this
by
adding
plugins
to
our
existing
stuff?
Where
do
we
need
to
add
like
a
new
thing
and
where
would
we
actually
have?
Did
you
have
to
actually
fork
open
telemetry
and
make
a
make
a
change
to
something
that
already
exists?
E
That's
so
that
yeah
people
can
boot
up
an
example
repo
and
then
just
see,
see
like
what
the
proposed
code
change
would
be,
and
probably
javascript
is
the
place
to
do
this,
because
that's
very
common,
so
people
be
able
to
understand
it
a
bit
better
and
also
it's
like
probably
the
most
problematic
environment
for
trying
to
implement.
B
E
B
E
A
E
F
And
ted
with
respect
to
the
log
sig
meeting
at
11
o'clock.
F
Do
you
want
to
like
propose
some
parity
between
the
span
events
and
logs?
Is
that
the
intention.
E
So
yeah,
I
think
there
are
two
two
things
that
we
need:
that
logs
don't
have
one
is
this
concept
of
a
name,
and
then
another
is
a
thing,
that's
totally
missing
anywhere,
which
is
an
event
type,
so
two
top
level
fields.
I'm
thinking
we
would
need,
maybe
I'm
wrong
about
the
type,
but
we
certainly
need
a
name
right
like
if
you're
going
to
be
able
to
just
like
spans,
have
a
name.
It
seems
like
these
ui
events
need
to
have
a
way
that
you're
indexing
them
like
a
primary.
E
What
we
call
a
name
is
basically
the
primary
index
on
the
event,
if
that
makes
sense
and
yeah
actually
yeah,
you
want
that
as.
F
F
E
E
F
E
E
Something
if
you're
having
to
crack
open
these
attributes
in
order
to
decide
which
back
end
to
go
to
like
that's,
that's
inefficient.
It
seems
like
you
would
want
an
efficient
way
to
do
that.
Switching
so
so,
so
I'm
going
to
go
there
and
kind
of
suggest
that
that
those
are
two
things
we
probably
want
from
from
this
group.
A
A
A
A
The
counter
argument
was
well
like
if
you,
if
you
need
like
a
client-side
event
name,
you
could
just
add
it
as
a
as
an
attribute
right,
like
a
semantic.
E
Yeah
yeah
and
I'm
gonna
go
there
and
try
to
argue
that,
like
no,
the
same
way
spans
have
a
name
that,
literally
that
exact
same
concept,
events
need.
You
need
a
primary
index
that
you're
using
to
classify
these
events,
because
you're
going
to
look
at
these
events
in
aggregate
you're,
not
they're,
not
just
logs.
E
These
are
things
that
you
look
at
in
aggregate,
and
so
that
means
you're
going
to
have
a
primary
index
and
then
you're
using
their
attributes
some
of
their
attributes
as
as
dimensions
in
some
way
and
so
the
same
thing
we're
doing
with
spans.
We
we
want
events
to
have
and
basically,
if
an
event
doesn't
have
a
name
and
doesn't
have
a
type,
then
that's
a
log.
A
log
is
an
event
with
no
name.