►
From YouTube: 2022-03-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
All
right
good
morning,
so
we
can,
we
can
get
started.
A
And
and
the
next
steps
were
going
to
be
update
the
draft
for
the
otep,
which
I
have
filled
in
the
the
proposal
section
in
that
draft
document,
and
what
I
would
just
ask
is
if
everyone
could
please
take
a
look
at
it
in
the
review
before
before
we
before
we
post
it
as
a
pr.
A
A
A
So
I
talked
about
basically
that
the
unique
things
about
client-side
telemetry
is
the
concept
of
sessions
which
are
very
long,
and
there
are
lots
of
things
that
can
happen
in
the
session
and
we
believe
that
the
best
way
to
cap
to
capture
these
events
that
happen
in
the
session
is
by
using
log
the
log
signal.
A
Then
what
I
do
here
is
in
the
events
that
I
have
actually
so
what
I'm
so
I'm
kind
of
describing
like
the
different
signals
and
how
they
would
be
used
in
client-side,
telemetry,
like
so
most
of
them,
would
fit
under
logs
or
events
and
here's
a
list
of
examples
this.
This
came
out
from
our
research
like
where
we
listed
all
the
different
types
of
events,
so
that
includes
interactions
things
like
clicks
and
tabs
environment
changes
like
network
connectivity
or
in
mobile
like
low
battery,
for
example,
timing
events.
We
discussed.
A
And
errors
mobile
app
crash,
so
things
like
that
that
are
essentially
things
that
errors
that
are
not
linked,
that
are
not
linked
to
spans
things
like
route
changes
and
custom
events,
and
and
so
on.
A
So
I'm
the
so
we
so
like
in,
if,
if
like
so
basically
going
back
to
our
proposal
like
if,
if
we
could
capture
these
things
as
span
events,
if
there
was
a
span
but
there's
not
always
a
span,
so
the
proposal
is
to
capture
these,
as
as
logs
and
since
logs
have
span,
span
id
and
trace
id
fields,
they
can
be
linked
to
a
span
if
there
is
one.
So
if
the
sdk
also
creates
a
span
like
these
events
can
be
tied
to
the
span.
A
And
then
that
I
added
a
section
about
interactions,
because
I
think
that
was
kind
of
the
biggest
one.
With
the
question
mark,
some,
some
existing
sdks
have
existing
instrumentations
for
interactions
that
are
based
on
spans,
but
what
I'm
arguing
here
is
that
we
should
the
actual
event
of
the
interaction
should
be
should
be
captured
as
as
a
log
and
then,
if
the
sdk
is
capable
of
of
capturing
causality
or
duration
for
for
the
for
the
interaction
that
it
can
do
that,
but
but
it
doesn't
have
to
so
like
we.
A
We
got
the
feedback
from
from
mobile
folks
that,
like
in
swift,
for
example,
it's
not
possible
to
associate
the
interactions.
Events
with
the
the
effect,
so
in
that
case
like
they,
would
just
be
generating
the
event.
A
In
the
case
of
like
browser
you
would
have,
you
would
have
the
event
of
of
what
the
interaction
like
the
click
and
then
you
would
have.
You
could
also
have
a
span
that
that
represents
like
the
duration
of
the
effect
of
the
of
the
event
had
so,
and
then
I'm
I
I'm
giving
some.
You
know
some
some
reasons
for
why
this
makes
sense.
You
know
things
like
you
know
it
is
these.
A
These
instrumentations
can
be
expensive
and
they
can
also
lead
to
data
loss
in
case
where
maybe
the
span
is
open
for
too
long
and
the
user
terminates
the
session.
A
And
then
I
also
included
a
section
on
sampling,
I'm
not
sure
if
I,
if
you
need
to
include
it
in
the
other,
but
I
did
want
to
talk
about
it
because
and
it's
actually,
I
I'm
interested
in
your
in
your
feedback
here.
So
we
talked
about
some.
Some
some
types
of
data
makes
sense
to
to
capture
as
metrics
like
right,
so
we
have
like
things
like
page
loads.
A
For
example,
like
you,
wanna
see
the
the
aggregated
values
over
over
all
sessions,
but
but
the
it
is
not
clear
like
if
that's,
if
that's
necessarily
the
ideal
solution,
because
because
metrics
like
the
the
client,
you
know,
the
client
instances
are
distributed,
distributed
across
many
different
devices,
so
like
aggregation
in
the
client,
doesn't
really
give
you
any
benefit
and
if
you're
going
to
capture
log
anyway,
then
why?
Why
capture
it
twice
I
mean
so.
A
The
maybe
like
the
the
the
alternative
option
would
be
to
capture
log,
which
is
essentially
from
from
instrumentation
perspective.
A
You
know
has
the
same
cost
as
as
capturing
a
single
metric
value
and
then
the
back
end
could
decide
what
to
do
with
it,
whether
to
create
a
metric
or
use
it
in
a
trace
or
whichever
and
then
I
also
also
have
sections
on
traces
and
metrics
yeah.
I
don't
have
the
sectional
metrics
here
so
traces
just
because
we're
capturing
things
as
as
events
doesn't
mean
that
the
spans
should
not
be
generated
like
for
certain
things.
A
They
do
make
sense
like,
for
example,
network
calls,
or
maybe
like
the
inter
user
interactions,
but
again
like
the.
I
think
the
purpose
of
these
signals
is
a
little
bit
different
than
the
logs
in
that
they
would.
A
They
would
be
displayed
in
tracing,
obviously
in
tracing
tools
like
and
to
associate
a
client
client
work
with
the
back-end
work,
for
example,
or
if
you
wanted
to
actually
trace
client-side
code.
So
things
like
sampling
sampling,
like
has
you
know,
applies
there
like
in,
like
the
trace
kind
of
sense.
A
You
know
when
we
discussed
in
the
past,
which
was
used
span
like
zero
duration,
spans
or
maybe
use
use,
just
span
events,
or
there
was
there's
also
the
potential
of
using
a
completely
new
signal.
So
I'm
gonna
just
stop
here
and
and
see
like
if
anyone
has
anything
from
what
I
just
said
like.
If
you
want
to
talk
about.
C
I
think
span
events
are
getting
folded
into
blogs.
Okay
yeah,
when,
when
logs
are,
are
complete.
If,
if
there's
a
span
context
available
when
you,
when
you
make
the
log
it'll
be
associated
with
the
log-
and
I
did
go
to
the
that
group-
and
there
was,
there-
was
general
interest
and
or
acceptance
of
the
idea
of
like
having
an
event
api.
D
C
A
Does
that,
does
that
mean
adding
the
name
field
back
to
logs,
or
would
it
be
done
using
semantic
conventions.
C
Semantic
conventions
was
was
the
idea
we
we
had
a
back
and
forth
around
whether
there
was
any
needed
optimization
to
be
had
around
making
it
a
field
instead
of
an
attribute,
and
they
felt
like
no
tigran
had
done
a
lot
of
work
on
on
that
kind
of
protobuf
parsing
optimization.
He
didn't,
he
didn't
think
it
was
worth
it
so
so
it'll
just
be
a
convention,
but
that
doesn't
mean
we
can't
add
a
convenience
api
so
that
it's
you
know
it's.
It
feels
nice.
A
Okay,
yeah
that
that
you
probably
haven't
seen
like
we
we've
been
working
on
the
poc
and
which,
where
we
actually
do
capture
logs,
so
we
prototype
like
a
really
just
in
a
rough
draft
of
a
logging
api.
A
C
A
If
not,
that
I
would
at
least
ask
please
review
it
and
comment,
and
I
think
I
think
the
goal
would
be
like
to
to
actually
open
an
ulta
pr
soon.
A
The
other
topic
on
the
agenda
that
I
have
is
I
open
the
pr
to
to
add
browser
attributes
with
the
intent
of
capturing
things,
like
name
and
version
vendor
like
brand
version
and
things
for
the
browser.
A
The
what
I
and
also
like,
we
thought
that
the
browser
attributes
would
be
used
to
identify
the
the
type
of
telemetry
like
the
presence
of
browser
attributes
it
turns
out
to
so.
The
comments
that
I
received
was
that
maybe
we
could
use
process
runtime
instead,
and
it
turns
out
that
for
javascript
process,
runtime
name
actually
has
a
browser
value
when
it
comes
from
browser.
D
I
still
feel
that
having
a
browser
name
space
is
helpful,
because
we
wanted
some
ways
to
distinguish
messages
coming
from
the
client
side
versus
messages
that
come
from
the
back
end.
So
I
was
thinking
of
using
you
know,
messages
that
contain
attributes,
starting
with
browser
or
device.
You
know
you
use
that
to
distinguish
these
are
coming
from
the
client
side
and
having
a
browser
namespace
you
know
like
given
these
are
semantic
conventions.
It's
it's
okay
to
have
some
redundancy,
because
then
it's
going
to
be
crystal
clear
to
anyone
in
the
future.
D
A
Okay,
so
I
mean
what
I
what
I
would
ask
if
you
please,
can
look
at
that
pr.
There
is
a
discussion
about
this
already,
so
if
you
have
an
opinion,
if
you
can
make
comments,
okay,
thank
you.
C
C
A
Yeah
I
mean
so,
I
think
the
that's
right,
so
I
think
the
pro
the
for,
like
browser,
name
and
browser
version,
it
seems
like
they
were
suggesting
to
use
process,
but
the
process,
runtime
name-
is
already
used
for
something
else.
C
All
of
that
information
could
potentially
be
captured,
especially
when
you
start
thinking
about
like
headless,
browsers
and
stuff
like
that.
So
it's
fine
to
have
a
browser
named
space
to
talk
about
the
browser
specifically
and
not
not
reuse,
those
those
other
things,
except
for
the
things
where
it
is
literally
meaning.
The
same
thing
like
os
like
the
os
stuff,
you're
capturing
it's
like
should
go
in
the
os
stuff,
but
but
I
kind
of
agree.
C
We
shouldn't
just
be
like
specking
by
convenience
like
there's
something
that
looks
kind
of
like
a
browser
called
a
process.
Let's
reuse,
it.
A
C
A
C
Just
I
think
you
know
the
only
question
I
had
was
kind
of
around
session.
C
It
seems
like
you
want
to
use
resource
to
capture
the
the
session,
and
so
that
kind
of.
C
What
one
approach
there
is
to
sort
of
open
this
larger
can
of
worms
around
making
resources,
mutable,
essentially
right
right
right
now,
resources
are
immutable
and
they're,
and
as
part
of
that,
there
is
no
resource
api,
so
the
the
plus
side
there
is,
you
know
we
intentionally
kind
of
kept
all
that
hidden.
So
you
know
if
we
wanted
to
add
some
kind
of
like
resource
api,
but
we
would
have
to
hash
out
a
little
bit
what
it
actually
means
to
to
mutate
resources.
C
Like
under
the
hood,
the
whole
architecture
kind
of
assumes
they're
immutable,
for
example,
we
capture
resources
and
then
over
otlp,
like
information,
is
going
out
in
batches
and
each
batch
has
the
resources
attached
to
it.
I
believe,
and
so
details
like
if
resources
change,
how
does
that?
C
B
When
you
think
it
patch
like
resource
and
then
resource
pens
like,
if
you
have
two
different
resources,
it
has
a
way
to
like
send
them
properly
like
for
one
batch
of
one,
like
everything
that
has
this.
One
resource
gets
sent
in
one
batch
and.
B
C
Yeah,
but
I
I
guess
what
I'm
saying
is
as
part
if,
if
we
want
to
have
mutable
resources,
be
the
solution
to
how
we
handle
sessions,
I
do
think
it
solves
potentially
some
other
problems
like
it's
very
nice,
for
resources
to
be
immutable.
But
you
know
we
could
we
could
bite
the
bullet
and
say
like
these
are
things
that
can
change
over
the
life
of
a
process.
C
But
just
if
that's
part
of
the
proposal,
then
I
think
the
proposal
needs
to
think
through
as
part
of
getting
the
proposal
finalized
like
thinking
through
the
mechanics
of
having
resources
be
mutable
and
and
laying
out
a
proposal
for
that.
Just
would
need
to
be
part
of
it,
probably
is
a
separate
quote
because
that's
its
own,
like
ball
of
wax.
A
C
Yeah
exactly
and
you
know
so,
the
way
the
way
we
like
to
do
that
in
open
telemetry
is,
if
there's
there's
just
one
piece,
that's
really
contentious.
We
try
to
see
if
it's
possible
to
separate
that
piece
out
and
and
accept
the
rest
of
it
it.
C
It
seems,
like
that's,
that's
feasible
in
this
case
I
mean
like
you
need
sessions,
but
it
does
seem,
like
the
rest
of
the
proposal,
doesn't
directly
interact
with
with
sessions
in
a
way
where,
if
we
figured
out
session
management
later
it
would,
you
know,
be
regrettable
that
we
accepted
the
rest
of
it.
C
So
that
would
be
my
guess
as
to
the
best
way
to
go
forward
yeah.
So
so
that
might
be
a
thing
you
put
into
this
otep.
Is
that,
like
session
there's?
No,
you
know
just
layout
that,
like
right
now,
they're
just
not
the
only
place
to
put
in
a
session.
C
C
A
third
option
would
be
some
totally
new
concept,
but
but
you
could
lay
out
in
this
proposal
that
that's
you
know
that
could
be
done
as
like
a
separate,
separate
otep,
and
then
we
could
start
with
an
otep
for
for
mutable
resources.
C
C
A
Yeah,
the
other,
the
other
topic
that
I
thought
might
be
content
might
maybe
be
discussed
elsewhere
is
is
sampling,
but.
C
Yeah
yeah,
I
guess
my
my
suggestion
is
to
put
this
stuff
into
this
otep,
but
because
we
know
there
are
some
contentious
areas
to
to
point
for
the
place
where
you
think
it
could
be
pulled
out.
You
know
point
that
out
for
the
places
where
it
seems
like
it's
all
stuck
together,
maybe
maybe
point
out
that,
like
it's
just
good
to
kind
of
anticipate,
so
the
way
it's
gonna
get
get
picked
apart,
that'll
help
help
the
people
reviewing
it.
C
A
C
Yeah
yeah,
we
can
call
it,
but
thank
you
so
much
for
doing
all
this
work
martin
and
like
driving
it
over
driving
it
to
completion.
I
think
this
is
a
really
solid
proposal.
A
Yeah
I
wanted
to
ask
about
the
prototype
the
way
we
did
the
way
we
what
we,
what
we
worked
on
was
it's
not
it's,
not
something
that
users
can
install
in
their
own
applications.
It's
like
a
demo
application
that
has
yeah
and
that's
is
that
sufficient?
I.
C
Think
so
I
would
maybe
just
in
read
me
point
out
what
the
different
pieces
are,
so
people
can
can
navigate
around
to
it
right,
like
you,
you'd
find
a
logs
api.
You
know
so
like
point
out,
you
need
to
do
that
here.
It
is,
if
you
know,
different
places
in
the
code
where
it
shows
off
like
one
of
the
maybe
just
like
tie
the
the
the
the
headline
items
you
were
proposing
in
the
otep.
Just
have
those
easily
be
just
examples
of
those
things
be
easily
referenceable
in
the
code.
C
B
B
B
A
B
C
Yeah,
this
is
a
thing
to
bring
up
with
the
log
sig,
I'm
not
sure
if
they
think
this
gets
solved
with
compression
or
something
else.
C
B
B
A
C
B
C
B
C
The
one
I
mean
it's
essentially
the
it's
like
the
very
nature
of
calling
something
a
span
event
right
is
at
the
data
structure
level.
C
You
know
you
can
just
embed
them
in
the
span
and
then
you
don't
have
to
do
this
kind
of
repetition
and
it's
sort
of
like
one
or
the
other
right
like
either
are
you.
These
are
like
embedded
objects
in
in
the
tracing
stream
of
otlp
coming
out
and
your
you're
fishing
them
out
of
there
later,
you
know,
and
maybe
like
or
you're
recording
them,
as
as
events
in
the
log
structure,
in
which
case
you
know,
they're
they
each
have
the
span
context
is,
is
duplicated.
B
Well,
you
know,
clients
problem,
not
ours,
it's
their
bandwidth.
C
Yeah
I
mean
you
know,
but
I
mean
there's,
there's
no
reason
you
can't
say
I
mean
we're
never
going
to
kill
off
spam
events.
Let
me
put
that
away
like
we're,
not
gonna
ever
like.
We
might
decide
to
to
deprecate
them
and
suggest
people
not
not
use
them
anymore
and
under
the
hood,
but
I
do
think
there's.
C
There
is
always
a
technical
option
available
under
the
hood
either
to
go
both
ways
like
basically
have
an
sdk
setting
that
says
you
know
when
someone
records
a
log.
C
Do
you
want
that
as
a
span
event,
or
do
you
want
that
as
as
a
log,
because
under
the
hood
you
know
you'll
be
able
to
open
the
contact?
Stop
you,
you
see,
you
have
a
span,
and
so
you
always
have
the
option
of
recording
it
there.
C
The
only
downside
of
span
events
right
now
I
would
say:
is
they
don't
they
don't
have
a
concept
of
things
like
log
level
and
stuff
like
that?
But
it'd
be
easy
enough
to
add
those
attributes.
C
So,
at
any
rate,
it's
it's
it's
possible
to
to
to
record
them
either
direction.
It's
not
a
decision.
C
We
we
have
to
to
make
right
now,
like
does
that
make
sense
like,
even
if,
even
if
people
write
the
instrumentation
using
the
log
api,
you
can
still
have
it,
be
a
they're
not
inputting
the
span,
ids
and
stuff
when
they
do
that
it
happens
under
the
hood,
so
it
can
be
an
sdk
setting
as
to
which
way
you
actually
record
it.
C
So
if
it
is
like
some
kind
of
like
performance
boost
when
they're
sending
data
to
some
particular
back
end,
if
that
back
end
knows
how
to
pull
all
that
information
out
of
spam
events,
and
like
the
overhead
of
you
know,
the
spam
ids
is
like
something
you
want
to
get
rid
of.
You
know
it
could
be
just
like
a
configuration
that
they
set
to
reduce
the
overhead.
So.
C
A
A
No,
I
was
going
to
say
like
in
in
addition
to
the
overhead,
there
is
also
the
potential
implication
of
on
the
analysis
tools,
because,
like
some,
some
events
will
have
different
significance.
You
know
like
these.
These
events,
for
example,
like
martin,
said
they.
They
only
make
sense
in
the
context
of
that
span,
while
other,
while
other
logs
will
have.
C
A
C
A
You
know
if
the
if
the
like
analysis
tool
like
is
taking
all
events
for
the
session
and
displaying
them,
let's
say
like
as
a
session
replay
then
like
it
would
need
to
know
like
these.
These
logs,
you
know,
are
in
the
context
of
the
resource,
and
maybe
I
don't
display
them.
A
C
C
D
C
C
But
you
know-
hopefully
hopefully
it's
still,
there's
still
like
an
efficient
way
to
to
translate
this
stuff
into
existing
tools.
I
know
that's
a
thing
you're,
you
know
you
guys
are
trying
to
do.
Is
I'm
sure
some
people
in
this
call
are
trying
to
do.
Is
you
know,
be
able
to
feed
this
new
data
into
you
know
an
existing
analysis
tool
that
has
its
own
way
of
like
recording
at
all.
So
you
know
if,
if
there's
some
way
about
how
we're
doing
it,
that's
making
that
really
expensive.
C
C
C
C
C
I
mean
it's
not
nothing,
obviously,
but
just
like
it.
Just
strikes
me
that
these
these
logs
are
like
pretty
heavyweight
with
all
the
other
attributes
and
things
going
on
with
them,
so
like
they're,
they're
heavyweight
enough
that
we
have
to,
I
think,
be
a
little
cautious
like
as
always
with
vlogs,
about
like
how
many
of
them.
C
You
know
how
like
like
what?
What
is
the
production
overhead
of
rolling
out
the
instrumentation,
we're
providing
people,
and
I
don't
know
that
the
the
repeated
span
id
would
necessarily
be
significant
enough
to
change
the
the
calculus
there.
C
C
A
So
is
the
logging
sick,
actively
working
on
this
proposal
like
to
replace
blogs
with
spanish,
just
replace
spam
events
with
vlogs.
C
I
I've
been
poking
poking
them
about
it,
so
the
the
last
time
I
went
it.
Basically,
yes,
they
they
were
they.
They
were
down
with
the
idea
of
logs
being
being
events.
Essentially,
I
think
that
was
an
open
question
they
had
about
whether
they
wanted
to
to
say
that,
like
you
could
have
things
that
were
just
like
straight-up
events
and-
and
they
are
like
fine
with
it-
I
don't
think
it
it's
like.
C
D
C
Hash
out
like
lot,
the
log
data
model
is
basically
a
superset
of
the
span
event
data
model,
so
you
just
have
to
decide.
C
You
just
need
a
proposal
to
kind
of
explain
what
the
default
values
are
for
the
information
you
don't
record
span
event,
but
that
all
seems
like
pretty
straightforward,
like
they
would
like
what
log
level
do
they
have
well
info
because
span
events,
don't
have
a
log
level,
so
they're
info
events,
except
for
exceptions.
If
you
use
the
record
exception,
you
know
api.
That
thing
can
can
go
in
with
a
different
log
level,
but
I
think
that's
the.
D
C
That's
like
the
only
real
work
that
would
have
to
be
done
is
just
to
define
the
semantic
conventions
for
this
stuff
essentially,
but
if
we're
more
interested
in
it
than
they
are,
that
might
be
some
some
work
we
want
to
want
to
take
on.
But
I
don't
I
don't
see
it
as
like
being
very
contentious.
A
Okay,
I
do
have
one
more
topic
or
question
for
you
ted.
Actually,
so
we
last
week
we
talked,
we
talked
about
maybe
wanting
to
start
creating
issues.
So
we
can,
you
know
from
for
some
topics
we
want
to
tackle
and
is
there
is
there
a
label
that
we
can
use
to
distinguish,
or
we
can?
Can
you
add
one
for
us.
C
Yeah
yeah,
let's,
let's
have
a
look
and
by
the
way
this
is
I
you
know
I
mentioned
you
know
calling
out
the
re
resource
meetup
like
the
things
this
your
otep's
gonna
change.
One
is
like
resource
mutability,
potentially
the
other
one
is
like
sampling,
some
open
questions
there
I
do
think
yeah.
The
third
one
to
point
out
is
just
you
want
to
explicitly
point
out,
there's
no
logs
api
and
we
want
an
event
api.
So
that's
that's
like
a
third
like
otep
that
essentially
has
to
get
written
right.
C
Proposal
logs
and
an
events,
api,
yeah
yeah,
you
know
we
don't
have
one.
So
so
that's
like
kind
of
the
third
piece.
That's
that's
gonna
end
up
being
kind
of
its
own
own
thing.
Okay,.
C
Is
it
part
of
so
so
we
have
these.
Don't
change
right.