►
From YouTube: 2022-02-02 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
Let's,
let's
start
in
a
couple
of
minutes.
B
A
All
right,
so
I
think,
ted
thanks
thanks
for
putting
those
two
documents
together,
I
looked
at
them
just
very
briefly,
so
if
you
want
to
talk
about
that,
a
little
bit
go
for
it.
B
Yeah
totally,
let
me
just
do
a
quick
screen
share
here,
so
I
just
as
requested
put
together
two
things.
B
One
was
just
some
of
my
my
own
thoughts
of
how
to
model
clients
using
the
open,
telemetry
stuff
that
we
have
and
what's
missing,
kind
of
based
on
reviewing
all
the
great
work
you
all
have
been
doing,
and
the
other
piece
is
just
kind
of
a
review
of
the
whole
service
name
situation,
trying
to
kind
of
capture
all
the
ins
and
outs
of
the
service
resource
and
along
with
just
a
bit
of
extra
information,
around
kind
of
like
distributed,
tracing
and
distributed
system
analysis,
because
it
seemed
like
providing
some
of
that
as
context.
B
Maybe
for
some
people
would
be
helpful
so
just
to
quickly
go
over
this
stuff.
Looking
at
modeling
clients,
I
kind
of
focused
on
the
browser,
because
that's
what
is
this,
this
great
kind
of
very
thorough
table
of
all
the
different
kinds
of
events
that
could
happen
was
somewhat
browser
focused,
and
we
have
browser
instrumentation
that
I'm
aware
of
so
I
tried
to
kind
of
put
that
together,
but
the
basic
model
seems
to
be.
You
know
there's
some
kind
of
a
browser-based
request
like
a
get
request.
It's
loading,
the
page.
B
You
don't
have
great
access
to
modeling
this
on
the
client
side,
because
it's
something
that's
happening
kind
of
under
the
hood,
but
once
the
page
actually
loads,
it
is
possible
to
start
some
kind
of
session
right
at
the
beginning
and
then
begin
recording
various
kinds
of
page
load
and
user
interaction.
B
Events
generally
speaking,
when
kind
of
like
looking
over
how
to
model
these
things,
there's
kind
of
like
a
discussion
around
event
like
we
have
these
like
events
like
a
user
click-
or
you
know
the
document
has
loaded,
and
so
that's
an
event,
but
actually
for
a
lot
of
these
things.
The
way
we've
been
modeling
them.
That
seems
to
work
pretty
well
for
tracing
purposes
is
to
model
those
events
as
as
spans,
but
what
the
span
is
actually
measuring
is
not
necessarily
like
the
actual,
like
click
event
itself.
B
For
the
scroll
event,
though,
you
might
include
that
as
a
subspan,
what
you're,
really
trying
to
measure
there
and
encapsulate
in
that
span
are
all
of
the
event
handlers
that
fire
that's
kind
of
the
piece
of
timing
data
that's
relevant,
especially
in
terms
of
those
event.
Handlers
are
where,
generally
speaking,
transactions
transactions
are
going
to
kick
off,
distributed
transactions,
aka,
making
http
requests
and
things
like
that
to
server
side
components,
and
those
are
the
things
that
we
want.
B
B
B
B
But
you
could
probably
set
those
things
up
within
the
event
handlers.
B
Scenario,
I
think
some
actual
modeling
would
be
useful
for
would
be
modeling
these,
like
user
concepts
of
like
a
very
large
scale
span,
but
for
the
simpler
things
around
things
like
a
component
loading
and
needing
to
say
make
a
a
data
request
to
get
its
data
in
order
to
fill
itself
or
the
end
user,
pushing
a
button
that
causes,
you
know,
say
the
route
to
change,
and
then
more
data
needs
to
get
loaded
or
they're,
making
a
post
request
or
something
like
that.
B
A
lot
of
those
could
be
modeled
by
an
outer
span
that
encapsulates
the
event
handlers
all
the
event
handlers
that
fire.
So
whenever
they
fire
they're.
In
the
context
of
that
span,
we
actually
have
a
chunk
of
instrumentation
written
already
that
works
in
this
manner.
So
if
you
haven't
checked
this
stuff
out,
this
is
some
stuff.
You
can
actually
run
to
kind
of
get
a
sense
of.
You
know
what
I'm
not
saying
like
a
fancy
implementation.
B
All
user
event
handlers
be
modeled
like
this,
with
http
requests
being
auto
instrumented,
so
they're
gonna,
if
you
load
up
the
http
request,
module
and
the
user
interaction
module
and
set
these
up,
for
example,
you'll,
be
able
to
see
these
spans
chaining
together
in
a
parent
child
fashion
kind
of
automatically
there's
a
rudimentary
react,
instrumentation
that
measures
component
loading
and
reloading
and
for
the
kind
of
timing.
Events
that
you
would
capture
by
camping
on
the
the
new
kind
of
like
performance
observer
stuff
that
they've
added
to
the
browser.
B
B
So
I
would
say:
that's
probably
like,
like
the
biggest
takeaway,
I
would
say
if
you
haven't
played
around
with
just
loading
up
the
examples
in
these
repos.
That
might
be
a
good
thing
to
do
just
to
get
your
head
wrapped
around,
like
this
sort
of
like
trace,
span
model
of
doing
these
things,
I'm
not
saying
we
have
to
go
with
this
approach.
You
know
we
could
throw
it
away,
but
that's,
like
you
know,
a
great
place
to
get
started
with
like
one
concrete
way
of
doing
it.
B
I
could
get
into
like
a
lot
more
detail
about
these
things,
but
maybe
stop
there.
Real
quick
people
have
any
like
questions
or
comments
on
on
that
bit
right.
There.
A
Yes,
so
if
they're
modeled
as
spans,
I
think
what
will
happen
often
is
that
we
will
end
up
with
just
one
span
for
the
trace
id
for
a
single
trace
id
so
like
if
you,
if
these
are
actually
being
sent
to
like
tracing
trace
analysis
systems,
then
you'll
end
up
with
a
lot
of
just
like
single
single
span.
Traces.
B
Yes,
yes,
that
is
definitely
true,
and
so
these
things
that
I
I
think
I
really
what
I
looked
at
this.
There
were
like
these
two
big
buckets
that
things
tended
to
go
in.
One
was
modeling
event,
handlers
right,
either
things
being
triggered
by
the
the
end
user,
like
a
user
interaction
or
things
being
triggered
by
like
document
loads,
or
something
like
that.
B
But
at
the
end
of
the
day,
it's
sort
of
like
an
event
happens
that
a
bunch
of
event
handlers
may
have
been
attached
to
and
you're
trying
to
measure
all
those
event
handlers
and
those
things
may
definitely
have
a
high
chance
of
you
know,
making
http
requests
and
stuff
like
that.
There's
also
a
chance
that
you're
going
to
have
a
chunk
of
these
that
are
just
like
tiny,
nothing
things.
If
you
took
like
an
auto
instrumentation
approach
where
you
just
went
and
like
tackled
every
single,
you
know
user
interaction.
B
This
way,
there's
various
ways
to
to
deal
with
that,
but
but
those
could
definitely
be
modeled
by
spans
in
a
way
that
seems
logical
and
you
can
see
ways
of
actually
doing
it
here
now
for
things
like
long
tasks
and
these
other
kinds
of
timing
events,
what
they
struck
me
as
being
is
in
a
way
they
are
actually
spans
work
in
the
sense
that
you're
trying
to
do
latency
analysis,
and
even
though
it
is
just
like
a
single
span,
trace
a
lot
of
tracing
tools
or
trace-based
analysis
is
done
at
the
span
level.
B
B
Obviously,
something
like
a
service
diagram
wouldn't
be
very
relevant
to
these
things
and
looking
at
a
trace
graph,
wouldn't
necessarily
be
relevant
because
again
it's
like
this
one
span,
so
these
views
would
be
like
very
rinky
deep,
but
what
you
would
be
looking
at
would
be
things
like
latency
analysis
like
looking
at
what
is
your
average
latency,
for
you
know,
time
to
first
interaction
for
a
particular
page
type,
for
example,
and
then
looking
at
like
the
outliers,
you
know
what
is
like
the
p95
latency
there
for
time
to
interaction
and
then
being
able
to
actually
click
through
on
examples
of
those
things,
and
this
is
where,
if
we
have
some
form
of
session
modeling,
which
honestly,
I
think
gets
a
little
tricky
when
you
start
talking
about
sampling
and
things
like
that,
if
you're
trying
to
capture
like
complete
sessions
and
that's
the
thing
I
kind
of
have
questions
about
how
important
that
is,
but
there
would
be
a
way
potentially
from
that
one
span.
B
B
You
can
also
do
this
kind
of
like
a
correlation
analysis,
so
this
is
another
view
and
I'm
using
light
stuff
stuff
here,
just
because
it's
what
I
have
access
to,
but
you
know
I
feel,
like
all
of
these
tools
have
this
kind
of
stuff
in
it
to
varying
degrees.
This
is
just
what
I
could
take
screenshots
of,
but
one
example
is
here.
B
Maybe
if
I
can
like
zoom
in
here,
one
kind
of
analysis
that
you
can
do
when
you're,
just
looking
at
a
single
span
in
aggregate,
is
looking
at
this
latency
and
then
trying
to
look
at
what
kinds
of
resource
attributes
or
span
attributes
or
session
attributes
or
other
things
correlate
highly
with
say,
extreme
latency,
and
so
this
is
an
example
of
like
here's,
our
latency
spread
and
then
the
black
is
things
where
this
particular
kind
of
service
operation
was
highly
correlated
with
this
group,
like
this
correlates
with
this
group
of
spans
here
right
so
doing
this
kind
of
correlation
analysis.
B
Might
kick
you
into
understanding
where
to
look
next,
so
it's
like
very
slow
and
then
you're
like
wow.
It's
very
slow
when
it's
on
ios
version,
whatever
you
know
or
the
application,
you
know
service
version,
something
something
things
of
that
nature.
B
So
so
these
are
the
kind
of
things
where,
even
though
it
is
a
single
span.
Tracing
tools
today
can
do
really
useful
things
with
this.
You
can
set
up.
You
know,
like
alerts
off
of
this
kind
of
stuff,
and
and
that's
like
very
out
of
the
box
things
obviously
you'd
also
want
to
feed
this
into
some
kind
of
you
know,
rum
system,
but
just
looking
at
this
from
the
point
of
view
of
like
we're
living
in
the
future
now
and
we're
trying
to
actually
integrate
all
of
these
systems.
B
You
know
you
can
actually
just
like
click
buttons
to
get
from
one
place
to
another,
rather
than
you've
got
like
four
browser
tabs
open
and
you're
trying
to
sort
of
manually
paw
around.
So
that's
a
world
where
it's
like.
Well,
if
I
got
these
tracing
tools,
I
might
use
them
for
some
of
this
analysis
too.
B
So
that's
one
case
for
doing
them
as
spans.
Now
that
said,
because
they
are
these
one
shots
that
we
are
trying
to
to
do
this
kind
of
measuring
and
looking
at
them
in
aggregate.
The
other
thing
that
we
do
there
are
metrics
right.
So
a
lot
of
these
timing
events
actually
look
to
me
like
the
kind
of
structured
metrics
we're
doing
and
when
it
comes
to
doing
all
of
that
kind
of
aggregate
analysis,
we
have
specialized
tracing
tools.
B
B
So
I
could
see
these
things
being
modeled
as
metrics.
The
only
part
of
the
reason
why
they
seem
like
metrics
to
me,
as
opposed
to
say
log
events.
Is
these
events,
these
timing
events,
don't
seem
to
have
like
unique
per
event
information.
It's
not
like.
There
is
a
message
attached
to
this
event
that
has
that
may
like
be
totally
unique,
and
you
actually
care
about
that
particular
message.
B
They
will
have
dimensions
but
they're
the
kind
of
things
where
you
could
come
up
with
like
a
default
set
of
dimensions
of
like
these
are
the
dimensions
that
you
want
for
this
thing
and
if
you
wanted
different
dimensions,
that
would
be
like
a
kind
of
configuration.
You
would
be
loading,
but
it's
not
quite
the
same
thing
as
looking
at
logs
or
log
events
where
actually
the
presumption
is
you
know,
they're
gonna
actually
have
a
lot
of
high
cardinality
fields
and
surely
you
can?
B
You
can
totally
create
metrics
out
of
log
events,
but
it's
kind
of
like
this
extra
step,
so
you
could
do
it
that
way,
but
if
looking
at
these
things
in
aggregate
is
like
what's
important,
the
way
that
you
could
model
this
with
open
telemetry,
where
you
actually
gave
the
user.
All
of
that
information
like
these
are
the
dimensions
that
you
should
use
and
it's
just
out
of
the
box.
Gonna
do
all
of
that
stuff.
B
Modeling
them
as
metrics
would
be
a
way
to
to
give
the
user
all
of
that
with
the
open,
telemetry
tools
we
have
today,
if
you
did
them
as
log
events,
this
would
have
to
be
something
that
happened
somewhere
further
down
the
pipe
right,
and
so
that's
one
question
of
you
know
if
just
having
this
work
out
of
the
box
from
like
independent,
open,
telemetry's,
an
independent
telemetry
system,
so
we're
saying
like
we
want
a
really
high
quality
telemetry
system
and
not
take
the
road
of
like
I
just
spews
out
some
events,
and
it's
like
up
to
you
to
have
some
fancy
back
end.
B
That's
gonna
like
sort
out
what
to
do
with
them.
The
only
downside
I
see
to
this
is
it
does
seem
like
when
recreating
these
sessions.
You
might
want
to
be
plotting.
These
timing,
events
and
metrics
today
are
not
quite
like
logs,
in
the
sense
that
we're
assuming,
if
you
we're
trying
to
scoop
up
an
entire
session,
how
you
would
like
scoop
the
logs
up
in
as
part
of
that
is
kind
of
a
question.
B
It's
totally
possible
with
exemplars
on
metrics,
which
I'd
encourage
people
to
look
at.
You
can
associate
trace
ids
with
metrics
and
you
could
associate
a
session
id
with
metrics.
So
if
you
were
looking
at
a
metrics
graph
of
this,
you
could
then
click
through
from
that
metrics
graph
to
see
the
session.
B
But
the
problem-
and
this
also
is
there
for
traces
as
well.
Once
you
have
like
sampling
enabled,
we
would
need
to
talk
to
this
sampling
sig
about
like
what.
How
would
we
go?
How
would
we
develop
a
weighted
sampling
algorithm
that
was
session
aware
so
that.
B
You
can
be
sampling,
which
means
you
may
be
getting
incomplete
sessions,
but
you
are
trying
to
organize
this
work
and
weight
it
in
such
a
way
that
you
are
more
likely
to
get
a
complete
session,
and
we
do
some
of
this
work
today
for
traces,
because
just
looking
at
individual
traces,
we
actually
for
very
large
systems.
B
If
we
were
going
to
make
session
sampling
work
and
I'm
not
actually,
I'm
actually
curious
how
this
is
dealt
with
in
like
the
rum
client
world
today.
Maybe
that's
a
world
where
just
sampling
isn't
isn't
a
thing,
but
but
that
to
me
seems
like
kind
of
the
trickiest
bit.
But
if
we
can
solve.
C
B
C
So
I
have
a
couple
of
questions
on
on
the
decision.
I
mean
on
the
suggestion
of
using
spans
for
presenting
events.
C
Actually
I
kind
of
missed
it
in
the
beginning.
Could
you
walk
through
an
example?
Once
again,
let's
say
in
a
browser
session,
a
user
is
the
application,
is
not
making
any
network
requests,
but
you
know
user
is
clicking
a
button
and
it
is
let's
say
it's
a
single
page
application
and
it
is,
you
know
everything
is
loaded.
All
the
javascript
is
loaded
in
the
browser
and
is
just
navigating
through,
let's
say,
you're,
playing
a
game
you're
navigating
through
different.
C
You
know
pages
entirely
on
the
client
side
and
it
happens,
and
there
could
be
events
like
button
clicks.
You
know
there
could
be
javascript
errors,
there
could
be
page
transitions.
C
C
Could
you
explain
that
a
bit
and
second
question
is
assuming
that
we
go
ahead
with
using
spans
to
represent
events?
C
C
Do
you
think
there
would
be
any
confusion
in
the
long
term
that
you
know
the
events
is
being
represented
in
multiple
different
ways?
You
know
in
different.
You
know
in
different
places.
B
Yes,
so
there
is
independent
of
what
we're
doing
in
this
client
group.
There
is
this
issue
of
span
events
right
span.
Events
were
a
concept
that
predated
logs
logs
are
designed
to
be
able
to
model
span
events.
B
So
if
we
look
at,
if
I
just
pop
over
into
the
spec
here-
and
we
have
a
look
at
logs-
have
a
look
at
their
data
model,
there
is
a
trace
context
field
on
logs.
So
this
is
what
a
span
event
is
essentially
a
span
event
is
just
a
bag
of
attributes.
It's
just
a
log
that
is
attached
to
a
trace
context
like
this,
but
in
practice
now
there
are
two
places
in
our
data
model
where
these
would
show
up
right
like
these,
like
just
like.
B
Right,
you
know
you
have
these
events
here
which
are
going
to
be
attached
to
spans
as
events
right.
So
so,
just
today,
if
you
use
the
span
event
api
on
this
is
where
they'll
go.
They'll
go
into
this
data
structure
over
here
versus
logs
right,
which
is
over
here,
and
I
just
say,
like
putting
a
trace
severity
number
and
a
system
has
tracing
anyways.
Whatever.
B
B
So
this
is
this
is
something
that
has
not
been
resolved.
You
know,
but
the
most
basic
way
I
could
see
resolving
this
is
just
once
all
of
this
stuff
is
stable.
B
Whenever
you
call
the
span
event
api
like
it,
it
would
just
create
a
log
right.
It
would
just
start
creating
this
data
structure
rather
than
sticking
it
in
the
span,
event
data
structure,
and
then
we
would
mark
that
as
deprecated
going
forward,
and
we
would
just
be
using
this
log
data
model
as
like
a
unified
model
for
for
how
all
of
these
things
work.
B
In
the
long
run
they
they
got
to
converge,
yeah
they're,
going
to
converge
in
the
long
run.
That's
why
we
added
this
stuff
here.
You
know
that
was
very
intentional,
but
it's
like.
B
Also,
currently
we
don't
have
a
logging
api,
like
currently,
logging
isn't
like
quite
to
the
point
where
we're
doing
this
kind
of
work,
but
I
think
it
would
be
safe
to
say
that
in
the
future
you
could
just
think
of
using
the
span
event
api
as
being
no
different
than
using
a
logging
api,
in
other
words,
in
the
future.
B
B
There
wouldn't
be
a
difference
between
the
two,
except
that
the
logging
api
would
give
you
access
to
like
severity
and
like
a
bunch
of
other
things,
that
you
don't
necessarily
have
on
the
span,
so
so
that
that's
where
I
think
we
would
go
and
we
would
like
slowly
deprecate
the
like
span
event,
api
and
just
be
like
just
use
if
you're
logging
just
use
your
logger
and
it'll
be
trace
context.
Aware-
and
you
don't
have
to
use
this
thing
anymore,
yeah.
B
Yeah,
so
I
think
react
load
might
be
an
example
of
what
you're
talking
about
where
there's
not
necessarily
a
bunch
of
like
http
requests
going
on
we're
just
talking
about
dom
events
and
kind
of
like
single
page
app
style,
reloading
components.
B
So
this
is
an
example
of
how
that
works
today.
So
the
user
does
something
that
causes
a
component
to
unmount
and
remount,
so
you
would
get
a
mounting
event
would
occur.
B
You
have
some
event,
handlers
that
are
attached
to
that.
So,
like
page
rendering,
a
component
did
mount
callback
that
happens
here,
and
then
you
have
this
parent
span
that
is
recording
the
whole
overall
length
of
of
all
of
the
event
handlers
starting
till
the
final
event
handler
closes
and
finishes
its
business,
and
you
can
see
under
this.
You
know:
you've
got
these
events,
these
very
tiny
events
that
are
kind
of
peppered
throughout.
B
So
here's
like
another
example
updating
set
state
should
component
update,
render
get
snapshot
component
did
update
all
the
usual
like
react.
Life
cycle
stuff,
so
I
think,
is
it.
Is
this
the
kind
of
event
you'd
be?
You
were
thinking
of.
A
Okay,
I
would
say
like
there's,
certainly
certain
there's.
Definitely
certain
operations
like
that
that
have
logical
parenting
and
then
there
are
some
that
don't
like,
for
example,
like
certain
if
we
represent
some
of
the
timing,
events
as
spans,
so
they
may
happen,
like
you,
know
way
past,
like
the
document
load.
A
B
Yeah
I
mean
you
could
link
them
to
things
like
document
load,
but
it's
it's
a
little
obnoxious
right
like
if
you
know,
if
you
wanted
to
actually
model
that
as
a
span
tree,
it
is
possible
using
the
span
api
to
manually,
set
the
start
time
and
the
end
time
of
a
span.
So
you
don't
have
to
record
spans
live,
and
if
you
kept
a
handle
on
the
document
load
span,
then
you
would
be
able
to
later
when
you
kind
of
synthetically
construct.
This
span
attach
it
as
a
child
to
that
other
span.
B
So
you
can
do
that.
It
is
obnoxious,
though,
because
now
you're
juggling
a
bunch
of
like
span
state
by
hand
rather
than
just
using
zones
or,
like
you
know,
context
context-aware,
you
know
context
management,
so
you
could
do
it.
But
again,
I
want
to
stress,
I
feel
like
there
are
these
synthetic
timing
events
and
they
seem
to
be
in
a
separate
bucket
from
this
kind
of
event.
Handling
right,
like
there's
like
event
handling
that
is
kind
of
happening,
live
that
you
can
model
in
this
kind
of
straightforward
way.
B
B
They
are
these
things
that
you're
kind
of
piecing
together
asynchronously.
Whenever
the
you
know,
performance,
observer,
callback,
notices,
there's
like
some
free
cycles
and
then
it
it
like
barfs
out
some
information,
at
least
that
that
was
my
impression
about
how
those
things
worked.
C
B
This
is
the
react
load,
so
I
would
have
a
look
at
these
things.
This
does
include
like
a
long
tasks.
Example
of
modeling
one
of
these
kind
of
synthetic
timing,
events
using
spans.
B
Again,
I'm
I'm
not
totally
sure
that
the
way
these
timing
events
are
modeled
needs
to
be
the
same
way
that
regular
ui
interactions
and
other
kinds
of
like
normal
event
handling.
B
It
could
be
that
these
timing
events
are
modeled
in
a
way.
That's
that's
totally
different
from
from
regular
event.
Handlers
like,
for
example,
these
timing
events
might
just
be
metrics.
Maybe
that's
that's
really.
What
we're
talking
about
here
is
you?
Are
it's
not
like
a
timing
event?
It's
it's
a
latency
metric
on.
You
know
how
long
did
it
take
before
the
user
interacted
with
the
page,
but.
B
If
we
just
go
digging
into
this
stuff,
a
little
bit
you
can
see.
This
is
an
example,
so
you
get
this
like
performance
task
and
then
you're
starting
a
span.
It's
this
particular
kind
of
span
right.
Our
performance
type,
so
you'll
be
able
to
use
those
tracing
tools.
We
were
looking
at
earlier
and
then
this
thing
is
manually
setting
the
start
time
based
on
the
entry
start
time
from
that
span,
sets
a
whole
bunch
of
attributes
based
on
information.
B
It
was
able
to
to
grab
out
of
that
event
and
then
at
the
once.
It's
done
that
it
ends
the
span
manually,
setting
the
end
time
to
be
the
start
time
plus
the
duration,
and
then
it's
done
so.
This
is
like
a
totally
synthetic
span,
but
it
is
a
real
span.
It's
not
like
a
zero
duration
span,
so
this
isn't
like,
and
there
are
like
plenty
of
tracing
tools
where
you
know.
C
B
Because
what
you're
trying
to
actually
measure
here
is
latency
right.
You
have
this
like
long
task
and
you
are
trying
to
look
for
latency
outliers
right.
These
are
crazy,
long
tasks
happening
and
you
you
want
to
be
able
to
like
plot
a
distribution
and
be
like
what
are
these
like
super
crazy,
long
tasks
that
are
occurring
and
then
click
on
those
fans
and
get
a
bunch
of
attribute
information.
That
would
tell
you
something
about
these
crazy
long
events
so
that
you
could
go
fix
it.
C
What
I
understood
earlier
is
that
at
least
the
recommendation
is
that,
for
the
timing,
part
for
the
duration
part,
you
use
the
spans
start
and
end,
but
all
the
meta
information
should
go
into
the
span
event.
That
way
the
the
message
is
there
in
the
in
the
event
store
or
the
lock
store
in
the
back
end,
but
just
and
and
through
the
trace
id
correlation
for
the
purpose
of
timing.
You
know
you
come
back
to
the
span.
B
That
would
be
the
the
don't
duplicate
all
the
information
way
of
doing
it
right,
there's,
in
other
words,
there's
no
reason
why
a
roam
system
can't
ingest
this
tracing
data
as
well
and
turn
it
into
timing
events
or
whatever
it
is
that
it's
it's
currently
modeling
this
stuff
like
you,
could
extract
that
from
the
span,
because
at
the
end
of
the
day,
like
the
span,
is
just
another
data
structure
coming
in
on
that
otlp
stream.
B
B
That
would
be
the
thing
to
know
about,
but
it
seems
to
me
like
there
were
there's
gonna
be
stuff
in
the
spans
that
you're
gonna
want
regardless
right,
like
certainly
all
of
the
regular
event,
handlers
that
we
would
want
to
model
as
spans,
because
we're
trying
to
connect
them
up
to
you
know
distributed
traces.
B
You
could
also
like
follow
the
pattern
of
like
here's
a
spam
before
the
attributes
and
I'm
gonna
make
an
event
with
all
this
stuff
and
pack
it
on.
But
the
other
approach
would
just
be
to
to
ingest
the
span
data,
which
would
mean
you
know
the
spans
would
have
an
attribute.
B
You
know
they
have
like
a
like
a
some
kind
of
set
of
attributes.
You
would
be
keying
off
of
to
populate
populate
these
different
kinds
of
timing.
Events
in
your
back
end,
so
that's
okay,
yeah.
A
B
A
Span
on
its
own
doesn't
is
meaning
meaningless.
Metric
might
be
maybe
like
could
be
useful
here,
but
but
if
you're
looking
at
these
long
tasks
in
particular
like
they
don't
really
have
any
meaning
so.
B
Right,
and
so
these
are
getting,
these
are
what
you
would
be
using
resources.
Currently
in,
like
our
current
system,
you
would
be
using
all
of
those
resources
that
a
user
would
be
setting
to
essentially
be
somewhat
similar
to
a
session
right.
It
wouldn't
be
like
it's
coming
from
this
particular
user
session,
though
you
could
actually
kind
of
model
sessions
as
resources.
B
B
Can
do
it,
but
it's
like
we
don't
open
telemetry
at
the
data
model
level
doesn't
have
like
a
great
concept
for
like
changing
resources
and
that's
sort
of
what
a
session
almost
seems
like
to
me.
It's
like
session
concept.
Context
actually
to
me
seems
like
static
context
like
resource,
but
it's
it's
more
ephemeral
than
resources.
It
may
appear.
It
may
go
away.
B
Yeah,
I
mean
you
know:
yeah
resources
are
sort
of
like
you
would
think.
The
duration
of,
like
the
entire
page
being
active,
would
be
all
of
your
resources
or
for
like
a
long-running
ios
app.
It
would
be
as
long
as
that
until
that
app
reboots
it
would
have
the
same
resources
and
then,
when
it
reboots.
B
For
some
reason
it
would
get
a
new
instance
id,
for
example,
but
but
today
you,
you
do
have
a
bunch
of
attributes,
you
don't
have
a
user
session,
but
you
do
have
a
bunch
of
other
attributes
such
as
like
the
service
name
and
version
and
things
like
device
and
browser,
and
whatever
user
resources
they
might
be
setting
like
project
id
or
account
id
or
something
like
that,
and
so
you
can
be.
B
You
can
be
indexing
these
long
tasks
along
those
dimensions
and
that
that
wouldn't
be
totally
useless,
but
definitely
definitely
doesn't
seem
like
a
substitute
for
sessions,
but
but
it
would
also
be
worthwhile
to
to
have
a
look
at
what
stuff
is
useful,
but
is
somewhat
immutable,
and
so
you
would
model
it
as
a
resource
like
what
are
we
missing
out
of
our
our
current
resources?
B
So
we
go
back
to
the
specification
right
like
we
go
over.
You
know
to
resource
here
and
like
have
a
look
and
like
you
know
this
is
this
is
what
we
got.
You
know.
I
think
you
guys
have
looked
through
this.
We
have
this
service
stuff
where
we
we
hate
this
word
right,
but
that
this
information
is
super
valuable.
B
I
think
we're
in
agreement
that
knowing
the
version
is
like
really
valuable
thing.
Definitely
knowing
that,
like
all
of
your
extra
slow
tasks,
are
coming
from
a
particular
version
of
a
particular
kind
of
app,
you
know
would
tell
you
a
lot
and
we've
got
like
a
jillion
other
thing,
but
they
are
mostly
focused
on
server-side
environments.
B
Right,
like
you
know,
cloud
kubernetes,
you
know
host,
but
there
are
some
things
in
here
like
device,
for
example,
speaking
of
slow,
slow,
page
load,
so
you've
got
some
rudimentary
amount
of
device
information,
but
I
imagine
this
is
if
this
working
group
hasn't
looked
over
this
stuff.
This
is
like
I'm
sure,
an
area
where
there
is
more
information
to
be
had
than
what
is
like
currently
listed
in
these
resources.
B
That
would
be
helpful
to
to
load
up
on
the
client
side
and
the
great
thing
about
those
resources
is
they
are.
They
are
totally
present
for
all
of
this
modeling,
whether
it's
spans
or
metrics,
you
know
or
events
or
anything
else.
You
can
use
these
resources
as
dimensions
so.
A
C
A
B
You
absolutely
want
this
information
for
sure,
and
so
that's
what
I
tried
to
boop
boop.
Where
did
it
go
here
so
this
this
other.
B
That
I
popped
up
tried
to
be
just
sort
of
a
summary
of
the
ins
and
outs
of
the
service
name
conversation.
I
don't
know
that
I
represented
everybody's
like
point
of
view
here
correctly,
but
I
did
try
to
like
summarize
like
what
the
problems
are
and
like
what
the
constraints
are.
So
just
a
quick
just
just
to
review
this
real
quick.
I
tried
to
just
briefly
describe
what
are
these
service
resources
and
like
why?
Why
do
we
want
them?
Mentioning
that
we
have
these
other
additional
resources,
but
these
additional
resources?
B
You
know
they
are
kind
of
like
specific
for
different
kinds
of
environments,
but
the
service
resources
are
special,
because
this
is
the
the
bucket
of
stuff
where
we're
saying
like
it
doesn't
matter
what
kind
of
app
you
are
or
if
you're
running
on
a
computer
shaped
like
an
index
card
or
a
computer
shaped
like
a
pizza
box
that
this
information
is
is
universal.
B
Any
program
running
as
part
of
a
distributed
system
should
have
this
information
packed
onto
it.
We
can't
say
must
have
because,
unfortunately,
that's
not
always
feasible,
but
we
do
want
to
say,
like
really
should
have,
because
there's
a
lot
of
important
modeling
that
you're
going
to
want
to
do.
That
really
depends
on
knowing
things
like
the
name
and
the
version
of
your
app,
and
there
may
be
other
things
like
this
as
well.
So
everything
wants
this.
However,
there
are
some
issues
right
like
end.
B
Users
on
the
client
side
may
just
be
confused
by
this
terminology,
and
that
sucks
we
don't
want
to
have
a
confusing
experience,
especially
when
users
are
just
getting
started,
throwing
just
tripping
them
up
with
some
weird
terminology,
isn't
good.
We
could.
E
B
Renaming
it
yeah,
I
tried
to
go
into
like
the
different
possible
approaches
like
we
could
have
two
name
spaces
that
contain
the
exact
same
information.
B
I
tried
to
explain
why
the
open
telemetry
project
doesn't
like
that
kind
of
solution.
From
the
perspective
of
of
the
data
scientists
and
thinking
about
the
poor
data
scientists
who's
going
to
do
a
bunch
of
munching.
If
we
do
this
and
then
I
tried
to
go
into
well
what,
if
what?
B
B
You
know
spec
maintainers,
try
to
like
maybe
adopt
some
of
that
ethos.
Not
just
say
you
said
it's
possible.
So
if
I
just
dig
my
heels
in
we'll
just
do
it
this
way.
A
So
I
think,
like
just
the
one
comment
that
I
would
have
on
that
is
like
I
can
just
I
can
just
tell
you
like,
even
from
like
in
just
perspective
like
we,
we
need
to
be
able
to
identify
right.
Is
this?
Is
this
a
back-end
service?
This
is
a
client
service
and
like,
and
so
like.
A
That's
the
biggest
question
in
my
mind
like
in
the
end
like,
if
you
could,
if
you
leave
service
name
to
be
like
the
universal
name,
fine,
but
but
we
still
need
to
have
a
way
to
identify
like
the
different
types
of
telemetry
and
right
I
can.
I
can
tell
you
just
like,
as
a
like
from
like
a
new
relic
ingest.
B
Yeah,
I
I
get
it
like,
and
so
I
think
that
is
that's
part
of
like
putting
a
proposal
together
is
to
be
like
what
is
like
a
solution
that
would
be
efficient
for
systems
that
are
trying
to
shun
data
in
different
directions.
One
problem
with
having
both
app
and
service
contain
the
same
name.
B
For
example,
you
do
have
edge
cases
right
like
where
what,
if
like
both
app
and
service,
are
set,
you
know,
but
what
then,
and
but
I
definitely
agree
that,
like
it,
has
to
be
inexpensive
to
do
this
kind
of
switching
and
my
experience
is
like
sniffing
for
name
spaces
to
be
there
like.
Oh,
if
the
device
name
space
is
there
or
the
browser
name
space?
Is
there
then
put
in
this
bucket?
You
can
do
that,
but
that
that's
an
ex
that's
expensive,
it's
expensive
to
do
that,
and
so
the
ideal
is
like.
B
There's
there's
one
field
in
kind
of
id,
even
more,
ideally
a
one
field
in
like
a
known
position.
You
know
so
that
you
can.
You
can
do
this
kind
of
parsing
and
and
switching
efficiently,
and
so
I
definitely
agree
we
need
to
to
figure
out
what
that
should
look
like,
regardless
of
what
we
do
here.
A
So
we
have
like
two
minutes
left,
so
thank
you.
I
really
appreciate
that
you
put
together
these
these
write-ups.
I
think
it's.
These
are
great
summaries
and
what
I
would
like
to
do
is
is
decide
on
our
next
steps
like
how
do
we?
How
do
we
move
this
conversation
forward,
and
I
you
know
like
like,
for
example,
for
the
client
side
data
model
like
should
we
should
we
open
up
like
a
should?
A
We
choose
like
one
of
these
options
as
the
proposal
and
open
an
otap
so
that
you
know
more
more
comments
like
people
from
like
the
wider
community
can
comment.
Should
we
open
an
issue
with
listing
these
options
and
like
not
proposing
any,
but
in
order
to
again
like
first,
you
know,
get
comments
from
the
community
yeah.
Should
we
present
this
at
this
as
the
spec
in
the
specs
sig
or
like?
Is
there
more
investigation
or
discussion
in
this
internal
group
that
we
should
do.
B
So
those
are
great
questions.
I
think
everyone
is
always
happier
when
you
show
up
with
a
well
thought
out
workable
solution.
So
I
I
do
think
presenting
this
at
the
spec.
Sig
is
good,
maybe
turn
taking
this
or
something
like
it
and
turning
it
into
an
issue
would
be
helpful,
but
I
do
kind
of
believe
it's
just
gonna
boomerang
back
to
this
group,
because
everyone's
gonna
be
like
well
there's
a
client
group
like
what
do
you
want?
B
Well,
we
will
like
review
your
proposal
and
nitpick
it,
but
I
suspect
they
will
kind
of
like
look
to
us
to
make
one
what
I
might
suggest
to
be
a
starting
point
for
that
proposal.
B
If
it
seems
feasible,
would
be
to
point
out
that
so,
if
we're
going
to
say,
stick
with
the
service
name
space
in
the
data
protocol,
one
thing
that
has
to
get
resolved
is
what
you
brought
up
around
like
an
efficient
way
to
to
switch
and
right
now
we're
thinking,
client
server.
You
know
kind
of
switching,
there
might
be
other
types
in
there,
but
but
we
want
an
efficient
efficient
way
to
do
that,
even
if
we
went
with
like
both
app
and
service
being
there.
B
I
still
would
not
want
to
be
trying
to
sniff
that
out
by
looking
for
the
presence
of
those
name
spaces
like.
I
think
that
it's
just
that's
just
like
like
a
little
hacky,
and
we
just
know
from
experience
like
the
more
and
more
we
do
that,
like
the
worse,
it
gets
so
being
able
to
just
like
propose
a
field
name
that
could
be
used
for
that
kind
of
switching
and
what
some
good
values
would
be
and
then,
as
far.
A
Enum
so
like
this.
A
B
Well,
you
know:
we've
got,
we've
got
a
couple
of
schools
of
thoughts
here,
so
that
seems
like
the
kind
of
stuff
we
want
to
hash
out
with,
like
the
rest
of
the
spec
community,
because
those
those
are
maybe
broader
guidelines
that
we
want
to
figure
out,
but
but
I
still
think
there
needs
to
be
a
way
to
do
this.
That,
to
my
mind,
doesn't
the
the
smell
for
me
is
the
duplication
of
this
information
right.
B
I
think
it's
totally
cool
to
have
names,
you
know
have
name
spaces
like
device
and
browser
and-
and
these
may
be
present
or
not
present,
because
they're
totally
separate
things
with
different
information
in
them.
But
when
you
start
talking
about
it's
like,
I
might
put
the
name
and
version
in
like
a
couple
different
places
that
that
just
seems
odd,
odd
to
me.
Maybe
it's
okay,
but
it's
it
seems,
seems
strange.
B
So
I
do
wonder
like
as
a
possible
proposal,
and
maybe
it's
not
the
final
one
we
go
with
like.
Is
it
possible
to
just
leave
that
the
same
resolve
leave
that
unified
find
a
way
to
resolve
the
switching
issue
and
then,
as
far
as
like
the
end
user
who's,
the
person
who
started
all
of
this
nonsense?
B
I
think
in
general,
like
our
initialization
sdk
initialization
is
like
very
low
level
and
clunky
and
not
a
good
experience
for
first-time
users.
I
don't
know
if
you
all
have
tried
to
set
these
things
up,
but
it
is
very
much
a
tinkertoys
approach
right
now
we
are
creating
a
whole
bunch
of
like
providers
and
context
managers
like
all
this
other
stuff
and
like.
I
think
it
is
great
that
we
have
that
because
for
like
advanced
users,
you
may
really
want
to
dig
in.
B
B
You
know
where
you
just
put
in
a
tiny
amount
of
required
information,
and
if
you
don't
put
in
anything
else,
you
get
a
whole
bunch
of
defaults
set
up
automatically.
So
you
get
a
trace
provider,
metrics
provider-
and
you
know
w3c
context
propagator
and,
like
all
that
jazz
would
just
and.
B
B
Your
app
give
us
your
version,
and
you
could
call
this
whatever
you
wanted
to
in
this
configuration
language,
you
wouldn't
have
to
use
names
that
exactly
match
the
resources
that
were
set
and
when
they're,
when
they're
neck,
deep
and
open,
telemetry
and
super
deep
in
the
weeds,
then
they
can
discover
this
like
service
name
nonsense
and
be
annoyed
by
it.
But
that
would
be
like
way
later
after
they've,
like
gotten
used
to
how
things
work.
B
So
so
that
that's
that's
an
approach
that
we
could
take.
So
maybe
we
could
put
a
work
together
to
put
a
proposal
or
something
like
that
and
but
I
don't
want
to
say
that's
the
only
proposal
that
should
be
considered,
but
that's
that's
kind
of,
like
my
shot
as
a
way
to
maybe
make
everyone
happy
without
triggering
some
kind
of
thrash
or
migration
or
weirdness.
A
B
It's
my
take
we're
over
time.
Please,
please
think
about
it
and
I'm
happy
to
bring
some
of
this
up
at
the
next
spec
meeting
to
at
least
get
it.
A
Yeah,
I
can
I'm
happy
to
do
that
as
well.
You've
done
you've
done
this
right
up,
but
if
I
can
you
know,
as
a
rep
representing
the
client
side
group,
I
can
maybe
bring
that
topic
up.
B
You
know
tc
members
and
core
maintainers
and
just
just
figure
out
where
people
are
so
you're,
not
you
know
when
we
actually
make
the
otep
it's
avoided,
whatever
silly
landmine
could
be
resolved
in
a
conversation,
for
example,
how?
How
should
we
do
this?
Switching,
we
don't
it's
just
nice
to
to
know
where
people
stand
on
that
before
we
make
the
proposals
so.
A
Yeah,
I
might
also,
I
might
also
schedule
a
follow-up
meeting
to
this
with
with
the
rest
of
the
client
side,
folks
before
the
next
seg
meeting.
Just
because
it's
a
lot
of
information
again.
Thank
you,
but
it's
a
lot
of
information
and
I
think
people
have
to
digest
it
and
then
we
should
probably
discuss
further
and
have
like
everybody
a
chance
to
like
comment
from
their
perspective,
but
so
I
might
schedule
another
meeting
did
and
lastly,
about
the
client
side,
the
data
model.
A
B
I
I
feel
like
on
the
client
the
data
model,
there's
like
there's
still
there's
like
several
pieces.
I
guess-
and
I
I
think
I
would
love
personally
I
would
like
love
feedback
from
like.
I
think
it
would
be
great
if
this
group
kind
of
ingested
some
of
those
thoughts
looked
at
some
of
those
existing
things
and
brought
it
back
to.
B
There
was
like
an
earlier
document
that
you
all
made
that
I
thought
was
like
very
in-depth
and
well-written,
and
maybe
if
this
information
new
information
is
interesting,
it
could
be
used
to
maybe
update
that
document.
That
document
seems
like
a
much
better
bastion
of
information
and
then
once
we've
done
that
we
could,
we
could
pitch
it
to
to
other
maintainers
and
say:
hey
here's,
what
we're
we're
thinking.
B
You
know
what
what
do
you
think
about
sessions?
What
do
you
think
about
session
sampling?
You
know
what
do
you?
What
do
you
think
about
these
like
open
problems
that
that
we
have?
But
what
I'd
love
to
know
from
this
group
is
you
know
if
you
muck
about
with
spans
for
event
handler
modeling
event,
handlers
like?
Does
that
feel?
Okay?
If
you
look
at
the
instrumentation,
that's
that's
already
written
there
does
that.
Does
that
look
all
right
or
is
that
just
like?
B
A
B
Yeah
we
need
to
get
some
timing
information
about
that
yeah
I
mean,
I
think
that's
it
would
be,
maybe
that
I
think
that
is
actually
maybe
a
great
next
starting
point
is
you
know
I
tried
to
describe
how
to
do
some
of
these
things,
but
there's
actual
instrumentation.
You
can
just
like
boot
up
and
like
look
at,
and
it
would
be
great
if
people
hadn't
looked
at
that
stuff
yet
to
to
just
like
run
some
of
that
working
code
and
be
like
how.
B
A
A
Okay,
well,
we
are
well
over
time
so
again,
thank
you
and
well
I'll
I'll.
Add
something
on
the
agenda
for
the
next
specs
meeting.
B
All
the
hard
work
you're
doing
and
yeah
thanks
for
the
the
feedback
when
it
comes
yeah,
cool.