►
From YouTube: 2022-03-16 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).
B
A
A
I
was,
I
was
wondering
like
if,
if
some
people
will
miss
the
meeting.
A
Okay,
well,
we
can
just.
I
think
we
have
just
a
couple
of
things
that
we
have
been
working
on
this
last
week,
so
we
can
just
talk
about
it
and.
A
Yeah,
let's,
let's
get
started
so
I
did
put
one
thing
on
the
agenda
and
that's
so
just
you
know
just
a
quick
update
on
the
proposal.
A
I
have
shared
it
with
a
bunch
of
people
thanks
for
anyone
who
commented,
I've
also
shared
it
with
the
with
the
aws
team
who
was
published.
You
know
opened
the
alternate
the
proposal
for
introducing
used
new
signal
last
summer,
and
so
quinn
has
joined
us
today
and
I
also
got
so.
I
got
a
bunch
of
comments
on
that
on
that
pr,
I'm
sorry
nothing
on
the
pr
the
draft
and
I
think
the
biggest
one.
A
The
one
topic
that
I
that
I
have
that
I
wanted
to
talk
about
quickly
is:
it
seems,
like
the
there's,
a
feeling
that
the
draft
doesn't
have
enough
details,
and
I
so
I
wanted
to
originally
just
focus
on
this
talking
about
the
signals,
but
perhaps
we
need
to
tell
you
we
need
to
include
some
some
more
detailed
information
about
what
the
kind
of
the
shape
of
the
the
events
that
we
send
looks
like.
So
what
I
did
in
the
proposal
again,
I'm
gonna
show
my
screen
really.
A
The
the
table
that
we
had
in
that
plan
document,
which
goes
through
all
the
fields
on
the
log
data
model
and
let's
select
which
ones
would
be
used
and
which
ones
would
not
be
used,
and
then
I
also
talked
about
a
little
bit
about
semantic
conventions
for
attributes.
A
So
this
is
this
is
essentially
our
thinking
that
we
will,
we
will
define,
we
will
use
semantic
conventions
for
different
to
define
different
types
of
event
types
I
this.
This
is
something
that
I
that
I
don't
think
it's
needs
to
be
in
my
opinion
needs
to
be
finalized,
but
I
think
at
the
very
least,
there's
gonna
be
two
common
fields.
A
A
A
So
I
included
those
examples
in
this
right
here
so
like
the
shape
of,
for
example,
js
error
would
be,
you
know
you
have
the
resource,
and
then
you
have
attributes
in
the
attributes
you
would
define
you
know
you
would
always
include
this
client
event
type
attribute
which
would
be
defined
in
the
spec,
and
the
presence
of
this
attribute,
I'm
thinking
would
would
be
an
an
indication
to
to
the
backhands
that
this
is
not
a
log.
A
This
is
a
client,
you
know
ram
ram
event,
and
then
the
value
of
the
of
this
attribute
would
would
tell
you
like
which
type
of
the
event
it
is
and
then
then
each
event
type
would
have.
Potentially
you
know
its
own
set
of
of
attributes.
That
would
also
might
be
defined
in
the
semantic
climation.
So
this
is
like
the
the
exception
or
error.
One
is
is
a
good
example,
because
there
already
is
a
set
of
semantic
conventions
for
exception.
A
It's
it's.
I
think
it
was
originally
intended
for
events
span
events,
but
you
know,
I
think
the
same
would
apply
here.
I
think,
and
so
in
the
in
the
case
of
span,
events
like
the
value
exception
is
in
the
spec
says
that
the
span
event
name
should
be
exception
and
then
it
should
have
these
additional
attributes.
A
So
I'm
following
kind
of
that
precedent
here
and
then,
like
the
same
pattern,
would
be
used
for
other
types
like
if
we
wanted
to
define
semantic
conventions
for
interactions,
for
example
where
so
that,
like
the
type
would
be
interaction,
and
we
would
have
like
a
set
of
standard
attributes
to
to
capture
the
details
about
the
interaction.
So
it
could
be
things
like
the
type
element
information.
A
C
D
Having
the
attribute
names
really
long,
just
makes
it
hard
for
both
front
and
back
end,
which
is,
I
guess
where
a
new
signal
would
come
in
handy
because
you
could
then
say
it's
a
json
encoded
field
name
so
you're
not
repeating
like
interaction.element
for
every
sub
element.
D
D
You
may
end
up
getting
like
events
that
are
like
just
really
complex,
like
I
know,
for
from
for
our
side
from
app
insights,
it's
we
have
some
teams
that
generate
you
know
json
blobs,
which
jason
blobs
not
repeating
the
same
name,
which
are
like
you
know
up
to
64k
in
size.
D
So
having
the
names
exploded
like
this,
would
just
make
it
even
larger,
and
when
you
consider
we've
got
like
a
during
unload,
you've
got,
send
beacons
and
beacon
has
a
limit
on
the
actual
maximum
size,
the
smaller
we
can
make
it
the
the
more
events
we
can
get
out
the
door.
D
A
A
Yeah
I
mean
so
the
you
know,
so
I
just
we've
been
working
on
this
for
a
while,
and
I
think
that
originally,
like
the
we
gotta
push
back
on
introducing
new
signal
that,
like
I
think,
people
in
general
felt
like
like
the
the
existing
signals,
would
be
sufficient
to
represent
client
side.
D
A
Yeah
yeah,
I
wonder
if
there's
a
if
there's
any
any
kind
of
serialization
that
can
that
could
not
repeat
like
the
the
strings.
D
D
Just
the
event
as
a
whole,
like
even
the
exception
you
like,
except
dot
message,
exception,
stack,
etc.
So
it's
just
if
we
can
avoid
repeating
or
having
to
construct
names
like
the
client
type,
that's
unavoidable.
We
need
a
signal
that
says
this
is
a
client
message,
but
for
the
rest
of
it,
if
you've
got
attributes
getting
coded,
it
would
just
be
really
nice
if
it's
not
fully
expanded.
E
Yeah,
that's
fair,
I
I
know
I'm
the
newbie
here
but
I'll,
throw
out
an
opinion
that,
like
I
don't
think,
a
new
signal
is
completely
crazy
from
the
client
side
like
I
do
think
like
stuff,
that's
going
to
be
browser
specific
is
pretty
unique,
so
I'm
still
playing
a
little
bit
of
ketchup
here,
but
I'm
definitely
interested
in
digging
in
to
understand
a
bit
more.
Some
of
the
background
here,
because
especially
you
know,
I
know
for
us
that
would
be
a
concern
as
far
as
performance.
A
E
Yeah
I
mean,
I
guess
just
like
any
event
from
the
front
end
like
I'm:
gonna
have
to
get
buy-in
from
my
kind
of
users
of
our
observability
platform
and
so
like
every
bit
of
you
know,
throughput
matters
right,
you
know
for
us,
and
so
like
uniqueness.
I
guess
in
hotel
signal
is
like
something
on
the
table
for
us.
I
would
say
you
know.
I
also
believe
in,
like
you
know,
in
general,
we
don't
need
to
reinvent
the
wheel
either,
but
but
like
I.
B
E
Like
I
might
be
kind
of
you
know
just
talking
out
of
my
butt
here,
a
little
bit
but
but
yeah.
I
know
I'm
excited
to
get
to
know
this
stuff
a
little
bit
more
to
like
more
fully
form
that
opinion
to
hopefully
be
helpful.
A
Yeah,
so
I
think
I
think
the
crux
of
this
proposal
is
is
to
to
to
just
focus
on
the
fact
that
would
be
we're
proposing
using
logs
or
events
as
opposed
to
as
opposed
to
spans
and
spans
with
tracing,
which,
for
reasons
for
reasons
such
as
you
know,
performance
and
like
the
trace,
tracing
and
metrics
could
be,
can
have
a
lot
of
overhead
in
the
client
and
also
also
like
the
client
sessions
can
can
terminate
at
any
point.
A
I
wonder
if
yeah,
I'm
kind
of
I'm
not
sure
like
if,
if
we
necessarily
need
a
new
signal,
just
because
of
performance
and
like
I
think,
if,
like
the
stance
of
the
open
telemetry
community
is,
is
that
logs
are
the
same
as
events
you
know,
I
wonder
like
if
those
performance
concerns
could
be
addressed
by
either
having
like
a
like
a
browser-specific
sdk
on
top
of
the
api.
A
You
know
right
now
like,
for
example,
js
js
sdks.
The
current
js
sdk
is
shared,
has
a
lot
of
shared
code
between
node
and
browser.
So
if
there
was
like
a
more
performance,
optimized
sdk
for
browser
only
and
like
for
the
size-
I
I
wonder
like
if
that
could
be
handled
in
like
the
different
types
of
exporters,.
E
Yeah,
I
think,
like
an
intermediary
layer
could
be
fine.
I
don't
know
that
the
actual
like
entity
needs
reinvented,
but
it
could
be
that
how
it's
transmitted
from
the
browser,
like
maybe
there's
some
like
api
change,
specifically
like
on
that
end
of
things
where
it
still
ends
up
in
a
normalized
format,
as
a
log
like
that
could
be
totally
fine
but
more
either
like
sdk
specific
or
some
like
intermediary
api.
A
Yeah-
and
I
think
also
the
the
other
thing
about
the
serialization-
is
that,
like
we
feel
like
there
could
be
potential
like
custom,
custom
attributes
or
custom
events
that
that
users
send.
So
I
don't
think
I
think
this
schema
could
potentially
be
difficult
to
manage
like
if
it
was
like
one
schema.
A
A
Yeah,
so
the
other,
the
other
thing
that
we're
also
working
on
and
trying
to
figure
out
how
to
represent
sessions
in
the
current
data
model.
So,
like
one
of
the
options
like
here
like
in
this
proposal,
we
have
the
session
id
attribute,
which
is
included
in
every
sig
in
every
data
point
every
event:
every
yeah
every
span,
every
log,
which
means
a
lot
of
duplication
and
to
your
concern.
It
would
actually
have
also
impact
on
the
size.
B
D
Sorry
like
for
me,
I
I
I
deal
with
both
the
the
public
application
insights
and
an
internal
variant
where
effectively
on
any
one
page,
like
your
office
teams,
there's
actually
multiple
teams
involved
all
sending
out
their
own
set
of
telemetry
all
with
their
own
set
of
session
ids
and
effectively.
We've
got
a
affected
internal
variant
that
packages
all
these
into
a
effectively
a
single
collector.
If
you
like
it
internally,
it's
called
the
post
channel
so
effectively.
D
The
batched
events
can
actually
be
from
different
teams
going
out
the
door.
So
even
if
you
had
the
session
id
as
a
resource
that
still
gets
duplicated
in
those
particular
cases,
but
we
have
the
same
thing
in
in.
We
have
a
an
instrumentation
key
which
identifies
to
the
back
end,
who
the
telemetry
belongs
to,
and
that
gets
repeated
in
every
single
one,
every
single
event
with
the
same
problem
so
and
it's
actually
good.
B
B
D
Yeah,
especially
during
page
unload
and
with
chrome,
enforcing
the
send
beacon
limit
of
it's,
not
just
a
64k
payload,
it's
a
64k
outstanding
payload,
so
you
could
actually
have
like
one
send
beacon,
that's
32k,
another,
that's
10,
another,
that's
32
and
effectively.
You
only
ever
send
the
first
two
if
the
browser
hasn't
sent
the
first
one
yet
as
opposed
to
something
like
firefox
that'll
accept
all
three.
D
Yeah
page
unload
is
is
a
painful
thing,
especially
with
page
redirects
and
I've
been
burnt
several
times
on
that
now.
B
B
D
B
D
A
So
some
math
view:
do
you
feel
strongly
about
this
about
using
a
different
signal
type
like
we're
really
close
like
to
to
opening
this?
This
old
tab.
B
D
Things
yeah,
no,
because
I
think
a
little
which
is
linked
to
in
the
in
the
proposal
has
been
open
for
a
while
from
a
brow
browser
perspective
and
isolating
it
and
saying:
okay,
we're
gonna,
create
an
sdk,
that's
small,
and
just
has
this
other
separate
signal
that
would
be
ideal
because
effectively,
you
just
drag
in
effectively
the
root
api.
D
Hopefully
most
of
it
gets
tree
shaking
away
for
the
the
stuff
you
we
don't
need,
and
then
we
just
have
this
other
signal,
yeah,
sort
of
client
event
or
something
failing
that.
D
What
I've
just
mentioned
with
the
you
know,
packaging
into
the
log
and
then
trying
to
keep
the
name
small
foot
in
terms
of
how
it's
encoded
going
out.
The
door
would
be
another
option
but
yeah
it's
really
looking
at
the
design
and
trying
to
keep
the
design
in
line
with
the
requirements
of
a
browser
where
it's
it's
not
just
the
outbound
signal.
It's
it's.
D
The
code
required
to
create,
said
outbound
signal
and
then
the
performance
of
that,
because,
ideally,
if
we
can
use
json
stringify
to
package
it
up,
that
saves
all
the
potential
security
issues
of
writing.
Your
own
compressor,
your
packager,
if
you
just
have
an
object
and
say
stringify
and
away
you
go
if
you're.
If
you
end
up
supporting
a
browser
that
doesn't
support
it,
then
that's
the
polyfill,
but
I
think
the
further
from
the
js
perspective
they're
only
supporting
latest
browsers
anyway.
So
it's
always
a
native
serializer.
F
Hi
everybody
I
joined
halfway
through
your
meeting
and
I'm
just
going
to
be
honest.
Why
just
so
many
conflicts
at
the
8
o'clock
morning
time
slot
for
open
telemetry.
I
know
that
there's
been
a
request
to
have
a
tc
member,
join
and
sponsor
this
group,
so
I
interests
me,
but
it's
always
conflicting.
So
I
I
just
joined
and
started
listening.
I
just
wanted
to
say
hi.
I
have
a
background
that,
like
I
heard
someone
talking
about
sending
spans
as
two
log
messages
I've
been
through
that
territory.
F
Definitely
I
so
I
was
listening.
I
I
thought
if
I
could
help
you
in
any
way,
strengthen
your
your
group
proposal
and
or
connect
with
other
parts
of
open
telemetry.
I'm
I'm
I'm
here
to
talk.
F
I
I
don't
want
to
make
you
rehash
the
entire
conversation,
though
I
wanna
one
thing,
though
this
is
my
first
comment
from
listening
to
that
five
minutes
was
you
know
as
a
server
author,
I
don't,
I
literally
don't
write
javascript
and
I've
never
instrumented
a
javascript
application,
so
you
shouldn't
listen
to
me
much,
but
as
a
server
author,
I've
also
had
a
desire
to
have
infinite
duration,
spans
or
sessions
that
last
much
longer
than
my
vendor
will
will
support
or
honor
a
span.
F
So
I'm
certainly
familiar
with
the
idea
of
the
desire
to
have
an
indefinite
span
or
a
span
that
users
forget
to
close
so
that
it
looks
indefinite,
but
it
wasn't
meant
to
be
a
definite
spans
that
go
missing
because
they're
never
closed
or
stopped
is
a
real
problem
and,
and
so
are
the
memory
leaks
associated
with
those,
and
so
when
open
intellimetry
first
began.
F
In
my
my
background,
I
wanted
what
we
call
the
stateless
sdk,
which
would
be
the
state,
the
sdk
that
has
no
state
across
sessions
right,
because
it's
a
design
that
sometimes
is
really
important,
and
then
in
that,
in
that
framing
of
the
problem,
you
can't
have
memory
to
keep
a
span,
a
line.
You
just
log,
your
spam
start
and
you
log
your
spam
stop
and
you
hope
that
those
messages
arrive
in
the
same
place.
F
Otherwise
the
reassembly
problem
gets
much
harder,
but
it
so
so.
From
that
framing
of
the
question
I
would
actually
like
to
see
perhaps
a
model
where
a
span
can
just
have
a
continuation.
So
I'm
I've
reached
one
minute
here.
I've
got
a
buffer
and
I
got
to
get
rid
of
this
buffer
because
a
it
might
be
that
the
user
forgotten
and
it's
going
to
be
dead
forever.
F
It
also
might
be
that
this
is
a
long
running
request
and
I'd
like
to
start
observing
it
now,
even
though
it's
going
to
keep
running
for
10
minutes
so
so
I
would
personally
be
enthusiastic
to
see
someone
propose
a
linking
between
the
span
and
log
data
models
to
say
that
this
is
a
span,
but
we
are
going
to
log
it
by
starts
and
stops,
and
it
can
be
reassembled
and
transformed
from
logs
back
into
spans.
F
Just
one
idea.
I
want
to
give
you
all
if
it
stops
you
from
creating
a
client
event.
Data
type,
perhaps
just
call
that
a
log
and
give
it
a
schema.
That
says
this
is
the
start
of
a
span,
and
if
you
match
it
up
with
the
stop
of
a
span,
you
can
transform
it
into
a
span.
F
And-
and
I
would
say
that
as
far
as
user
interaction,
you
see
that
there's
a
latency
measurement
recorded
or
you
know
defined
by
the
start
and
the
stop
so
that
you
could
have
and
the
the
background
for
me
was.
You
know
I'm
like
writing
offline
analysis
and
I'm
writing
a
I'm
debugging.
This
up
piece
of
software.
That's
logging,
detailed
debugging
information
and
I'm
going
to
go
after
the
fact
and
query
my
logs.
F
Now
I
can
track
durations
by
querying
those
logs,
so
they
were
spans
and
modeled
as
a
spam
that
were
decomposed
into
log
messages,
and
I
think
I
mean
I'm-
I
mean
I'm
really
building
on
my
experience
as
a
like
working
at
google,
where,
yes,
this
leaked
memory
problem
was
real
because
it
was
c
plus
plus
so
spans
spans
that
were
forgotten
could
crash
your
server
and
the
memory
costs
associated
with
span
storage
compared
with
the
cpu
cost
of
writing.
F
Bytes
over
a
wire
didn't
work
out
very
well,
so
it
was
almost
better
to
pay
more
cpu
and
less
memory
to
immediately
serialize
every
debugging
message:
yeah
you're
not
going
to
store
anything
in
memory,
you're
going
to
pay
more
cpu
cost,
but
every
message
has
exactly
a
predictable
amount
of
time
like
you're.
Never
going
to
like
I
gotta
go,
allocate
some
memory
here
or
oh,
I
gotta
flush,
something
out
and
I'm
gonna
pause
you
for
a
second,
it's
just
like
statelessly
write
your
bites
and
that's
a
good
model
for
some
for
some.
F
So
that's
where
I
came
into
open,
telemetry
thinking,
I'd
like
to
see
a
streaming
sdk
be
possible,
not
necessarily
the
default
but
be
possible,
and
some
of
our
earliest
api
decisions
were
informed
by
that
so
like.
Why
can't
I
read
the
value
of
an
attribute
from
a
span
because
it
might
be
stateless
and
you
shouldn't
ever
be
able
to
read
the
value
of
a
span
because
it
might
have
been
logged
ten
minutes
ago,
and
you
don't
have
that
memory.
That's
the
kind
of
thing
that
we
were
talking
about
early
on,
I'm
not
sure.
D
Yeah
from
a
browser
perspective,
I
I
can't
think
of
where
you'd
need
to
start
and
stop
a
span
like
if
you've
got
a
spa.
So
a
single
page
app.
The
page
view
is
probably
the
closest
thing
that
comes
to
mind
where
you
want
to
log
the
fact
that
okay,
I'm
the
user,
is
now
on
this
page,
and
if
you
follow
the
span
that
process
you'd
say:
okay,
well,
let's
start
the
span
and
when
they
navigate
away
or
the
page
unloads
we
stop
the
spam.
D
But
to
do
that,
there
may
have
been
like
a
million
events
in
between,
so
that
you
might
want
to
link
to
that
page
view
which-
and
they
may
have
been
on
that
page
for
like
days
so
it
you
know
it
doesn't
really
work
to
to
have
a
single
span.
For
that
particular
case,
the
way
we
do
it
with
app
insights.
Is
we
effectively
log
and
say:
okay,
we've
we're
now
heading
on
on
this
page
itself
and
if
they
happen
to
either
unload
or
navigate
away.
D
That
comes
out
as
another
page
view,
which
starts
a
new
page
id
effectively
and
then
every
event
that
comes
after
that
is
tagged
with
that
page
id,
which
is
how
the
backend
then
links
it
together,
rather
than
having
a
single
span
that
encompasses
it
all,
which
technically
is
the
same
thing,
because
you've
got
the
the
same
id
yeah,
the
the
the
browsers
I
I've
seen
like
in
the
case
of
teams,
for
example,
teams
uses
the
our
sdk
under
the
covers,
because
it's
it's
electron.
F
You
understand,
requests,
I
guess
and
and
yet
I've
certainly
had-
and
I
mean
there
was
this
interface-
that
we
called
the
operation
span
or
something
like
that
back
at
google,
and
it
was
just
like
I'm
going
to
create
a
thing:
that's
resonant
in
memory
and
until
it's
not
messed
up
in
memory
it
it's
got
a
span
associated
with
it
because
I'm
going
to
be
debugging
it
and
it
wasn't
really
meant
to
be
a
span
that
was
going
to
be
like
captured
at
the
very
end
of
this
indefinite
run
and
then
reported.
F
It
was
meant
to
be
a
sort
of
sub-log
of
events
that
happen
associated
with
this
one
object
in
memory
and
I'm
using
a
span
because
it's
the
most
convenient
closest
thing
in
the
in
in
the
repertoire
that
we
have
to
to
record
a
sequence
of
events
that
are
a
sub
population
of
all
the
events
and
and
yet,
but
you
can't
write
that
span
out
because
it
never
finishes.
F
What
I've
wanted
to
do
is
just
write
the
span
out
once
a
minute
and
say:
there's
no
stop
here.
This
is
a
started
span.
I'm
gonna,
I'm
gonna
flush.
My
started
span.
I
might
flush
it
again.
F
I
might
keep
flushing
my
span
once
a
minute
for
the
next
hour
until
it
actually
finishes
and
then
a
vendor
that
cared
about
that
type
of
span
could,
but
I
don't
think
many
products
will
be
built
for
that.
However,
you
know
when
you
want
to
debug
something
and
you
can
write
a
query
over
your
log.
Maybe
that's
still
useful,
not
sure.
E
F
Yeah
maybe
there's
like,
for
example,
I'm
thinking
outside
the
current
confines.
If
there
we
have
this
notion
of
a
span
kind,
if
there
was
a
span
kind
that
said
session,
maybe
you
could
record
it
without
a
stop
time
or
something
like
that.
I
don't
know,
of
course,
it's
possible
to
create
new
data
types,
maybe
when
they're
so
close
to
existing
data
types,
it's
worth
kind
of
modifying
existing,
but
I'm
not
sure.
D
Yeah,
it
probably
depends
on
the
event,
because
really,
if
you
look
at
the
browser,
you're
you're
recording
a
bunch
of
events,
some
of
those
events
have
a
duration
of
zero
because
hey
there
was
an
exception
that
happened.
The
user
clicked
on
this
button,
we're
done,
but
there
are
other
ones
where
you
do
have
the
duration.
So,
like
the
page
view,
I
I've
got
an
ajax
request:
it
took
x,
milliseconds,
well,
hopefully
milliseconds,
not
minutes,
etc.
F
Is
this
group
really
trying
to
create
like
analytics
events?
Is
that
is
that
what's
happening
here
I
mean
I'm
trying
to
figure
out
like
when
I
say
analytics
events,
I'm
thinking
of
there's
a
whole
industry
out
there.
That's
not
usually
considered
observability
you're
firing
off
events
about
client
performance
pageviews.
All
this
stuff,
it
usually
has
a
lot
more
pii
in
it
than
the
typical
observability
data
is.
F
Is
that
roughly
speaking,
the
data
we're
talking
about
and
and
is
the
question
whether
those
should
be
represented
as
spans
or
as
logs?
Those
sound
like
logs
to
me
more
and
any
accidental
association
with
a
spam
may
be
not
very
useful.
Is
that
is
that
kind
of
the
thinking
here.
A
Yes,
so
josh,
like
we've,
been
working
on
a
proposal
for
how
to
capture
client-side
data
for
from
browser
and
mobile
like
I'll
link
this
in
the
in
the
chat.
If
you
want
to
look
at
look
at
this,
basically,
what
we're
like
the
we're
thinking
like
any
any
type
of
data,
that's
coming
out
of
client
side
like
things
like
you
know,
like
start
of
the
session
start
of
like
navigation,
start
timing.
A
Events,
like
you,
know
all
the
all
the
events,
timing,
events
that
happen
in
browser
like
window
load
but
like
web
vitals
and
then
interactions
like
user
clicking
or
interacting
with
the
page,
would
be
events.
Individual
events,
errors
that
are
not
tied
to
you
know,
like
spans,
so
yeah,
pretty
much.
Everything
like
in
this
proposal
we're
proposing
that
the
data
is
like
streaming
using
log,
the
log
data
model,
and
then
it
is
optional
like
the
sdk.
A
If,
if
it
can,
it
can
also
it
might,
it
might
choose
to
create
spans
as
well
for
certain
things
and
you
could,
then
you
know
you
could
then
provide
more
context
for
those
logs
by
having
a
span
and
then
the
span
could
be
like
an
http
call
which,
like,
as
never
said,
makes
sense
as
a
span,
but
it
could
also
be
like
a
like
interaction,
like
effect
of
an
interaction,
for
example,.
D
Yeah
so
probably
answer
your
question
more
simply,
josh.
It's
both
the
we
have
some
events
that
have
pii
and
we
have
lots
of
events
that
don't
you
know
yeah.
There
will
be
some
sort
of
linking
of
you
know,
and
so
it's
not
there's
not
just
the
session
id,
but
potentially
a
user
id
and
that
may
or
may
not
be
anonymized
depending
on
the
the
customer.
We
have
some
people
who
use
aad
or
authentication
actually
send
because
it's
an
internal
company
app.
D
F
This
sounds
good,
I
I
would
I
don't
have.
I
don't
feel
like
I
should
say
less
and
listen
more
here.
I
will
take
a
look
at
your
document.
I
just
wanted
to
to
share
that
exciting
idea
to
me
would
be
potentially
that
these
data
models
are
connected.
You,
whether
you're,
writing
out
individual
logs
or
buffering
them
and
writing
out
spam.
F
It's
kind
of
the
same
data,
and
I
I'm
excited
about
the
idea
that,
with
schema,
url
or
submitted
conventions,
we
could
have
an
option
to
record
spans
using
logs
and
then
and
and
then
hopefully
that
connection
helps
us
see
how
to
be
to.
F
It
will
record
tiny
little
events
whenever
it
needs
to,
and
the
session
id
will
be
there
and
you
can
reassemble
them
into
a
span
so
that
the
data
model
looks
like
the
thing
that
we
think
of
which
is
request,
oriented
workflow,
where
there's
a
bunch
of
events
and
attributes
all
associated
with
context
and
all
that
stuff
and
and
then
we
haven't
said
metrics,
but
in
certain
sort
of
like
I
mean
I
don't
like
thinking
grand
unification
here,
but
even
today,
if
I'm
writing
a
server
side,
application
and
I've
got
a
span
and
I'm
issuing
metrics
from
within
my
span
context.
F
There's
almost
no
current
way
to
tie
those
together
and
and
and
wouldn't
it
be
nice.
This
is
like
a
same
hypothetical.
Really
it's
like.
Wouldn't
it
be
nice
if
I
could
turn
off
metric
reporting
and
have
all
my
metric
updates
be
bundled
in
my
spam
so
that
all
the
span,
all
the
metric
uptakes
for
a
particular
span
context
would
be
aggregated
by
span
rather
than
by
time
across
all
all
requests.
And
then
I
could
write
out
spans.
F
I'd
still
have
all
the
same
metric
signal
and
I
could
aggregate
them
downstream,
but
I
would
now
have
this.
Encapsulation
of
there
was
a
span
that
encapsulated
all
these
events
and
all
these
metrics
and
all
these
attributes
and
a
timing
measurement
and,
and
then
we're
just
saying,
because
we
want
to
be
stateless.
We
can't
record
those
fans
as
spans
we're
going
to
record
them
as
tiny
little
events
and
reassemble
them
downstream.
F
Take
a
look
at
your
document.
I
should
stop
talking.
The
other
thing
is
I
I'm
I'm
interested
in
this.
I
know
that
we
want
sponsors
and
tc
members
to
join
more
meetings.
This
was
just
overlaps
with
the
prometheus
working
group,
which
I've
been
sponsoring
for
much
much
longer,
so
I
I
can't
promise
to
be
here,
but
I'm
at
least
I
wanted
to
tune
in
and
learn
a
little
bit
about
what
you're
doing
so.
I
can
have
more
context
when
this
comes
up
before
the
larger
group.
So
thank
you.
F
A
Yeah
so
josh,
I
think,
like
we're,
we'll
probably
need
guidance
from
the
tc
on
like,
what's
which
direction
we
should
focus
in,
because
there
was
a
proposal
for
a
new
signal
last
summer
from
aws
and
that
didn't
that
it
got
pushed
back
from
a
lot
of
people
that
you
know
saying
that
we
could
we
could.
A
The
existing
signals
could
be
used
to
represent
client-side
and
there
are
lots
of
different
ideas
and-
and
also,
I
think,
one
of
the
pushback
one
of
the
arguments
was
that
introducing
a
new
signal
would
will
take
a
long
long
time
so
so,
like
what
we
tried,
we've
been
trying
to
do
like
the
last
few
months
is
to
come
up
with
a
proposal.
That's
using
the
existing
signals,
and
that's
what
this
this
document
that
I
shared
with.
You
is
cool.
F
Well,
I'll,
take
a
look
at
it
outside
this
meeting.
Okay,
the
prometheus
meeting
usually
lasts
about
half
an
hour,
so
maybe
a
week
from
now
I'll
join
halfway
through
your
meeting
or
something
like
that.
But
I'll
take
a
look
at
it
before
then.
Okay
sounds
good.
D
F
Yeah,
I
well
I'm
I'm
so
used
to
it
now.
I've
got
three
eight
o'clock
in
a
row
every
week
and
it's
been
that
way
forever.
But
but
there's
always
like
two
two
at
eight
o'clock
and
open
telemetry
and
have
to
choose
yep.
F
Well
I'll
read
the
document.
Thank
you.
A
Sounds
good?
Are
there
any
other
topics
that
anyone
wants
to
discuss.
B
E
Yeah,
sorry,
I'm
coming
in
a
little
sideways.
I'm
I'm
new
at
shopify
and
kind
of
helping
try
to
head
up
some
of
our
side
of
stuff
with
you
know:
client-side
integration
right
like
where
we're
deeper
on,
like
the
hotel,
ruby
side
and
you
know
kind
of
the
back
end
tracing.
E
But
you
know
I'm
definitely
interested
in
helping
both
contribute
here
to
this
stuff,
as
well
as
like
figure
out
how
it
fits
in
for
us
to
shopify
like
we
have
a
lot
of
these,
I
would
say
like
signals
and
different
things
in
different
formats
and
with
different
tools.
Now
you
know
and
we
as
much
as
possible
would
love
to
like
unify
it
with
our
like
hotel
stuff.
E
So
I'm
kind
of
looking
to
chart
that
course
a
little
bit
one
other
thing,
maybe
I'll
share
that
might
be
interesting
here
is
I
was
prototyping
a
solution
to
basically
add
some
context
to
a
spam
where
I
was
instrumenting
an
application
with
kind
of
like
a
scope
tags
in
a
component
tree
that
would
get
like
kind
of
serialized
like
a
dot,
syntax
sort
of
string,
and
then
it
would
just
be
appended
as
an
attribute
to
the
root
span
on
like
the
incoming
request
of
the
server,
and
that's
like
one
of
our
like
more
immediate
needs
is
like.
E
We
just
need
some
like
simple,
like
context
from
the
client
side
of
where
calls
happening
like
even
without
you
know,
complexity
of
like
multiple
spans
and
stuff.
Like
that,
we
don't
really
need
a
ton
of
detail
there.
We
just
need
some
like
basic,
calling
context
to
be
captured
a
little
bit
more
elegantly.
C
And
let
me
introduce
myself
as
well:
I
was
I
wrote,
the
original
proposal
with
elite
last
year
for
the
for
the
new
signal.
Unfortunately,
we
got
pretty
busy
and
we
weren't
really
able
to
follow
up
on
that
last
fall.
So
I'm
I'm
really
happy
that
martin
and
others
were
able
to
kind
of
take
up
the
torch.
For
that,
I
will
say
that
the
idea
of
wrapping
spans
in
in
an
event
and
being
able
to
kind
of
complete
it
in
the
collections
side
is
is
kind
of
interesting.
C
We
we
actually
do
something
similar.
Currently
I
mean
on
the
client
side
too.
It's
a
little
bit
more
unreliable.
You
don't
really
know
when
you're
gonna
kind
of
crash
your
end
and
so
yeah,
I'm
not
sure,
that's
yeah
and
that
might
even
fit
within
the
current
proposal.
C
If
you
have
an
event,
then
you
know
you
can
wrap
arbitrary
things,
including
expanse
and
events
and
potentially
add
things
or
reconstruct
them
in
stream
on
the
server
side
too.
So
yeah,
that's
all
right!
That's
an
interesting
idea,
one
that
I've
heard
from
from
people
over
here
like
anthony
on
our
site
too
so
yeah
very
interesting.
D
And
I
guess
me
I'm
from
microsoft,
I'm
on
the
sdk
observability
team,
so
I'm
primarily
focused
on
javascript
on
the
client.
So
you
know
azure,
monitor
application
insights,
that
that's
me,
we
have
an
internal
version
where
I
support
teams
office
and
all
the
rest.
It's
an
extension
of
application,
insights
yeah,
so
the
our
sdk
team
encompasses
multiple
things
like
I.
I
focus
on
javascript,
another
team
member
focuses
on
node
trusk
focuses
on
java.
Layton
focuses
on
python,
we're
all
part
of
the
same
team.
D
Prior
to
this,
I
was
on
the
identity
team,
doing
effective,
both
front
and
back
end
collection
of
telemetry,
which
is
why
I
moved
to
observability.
Prior
to
that.
I
did
very
similar
things
in
in
hotmail
and
windows
8,
so
been
floating
around
the
client
side.
Telemetry
a
lot
been
looking.
D
I've
been
been
hovering
in
in
the
the
open
telemetry
group
for
probably
about
18
months
done
some
stuff
in
the
in
the
javascript
sig,
but
yeah,
mostly
I'm
looking
to
see
how
to
roll
this
into
the
client
side,
which
is
problematic
with
the
sizes
and
what
we've
got
today.
G
Hey
y'all,
I'm
usually
pretty
quiet
in
these
meetings,
still
getting
my
bearings
still
soaking
it
in,
but
I'm
dustin
posey,
I'm
a
product
manager
for
observability
at
workkiva,
we're
working
on
a
hotel,
dart
implementation
and
similar
to
andy
kind
of
organizationally.
We're
on
a
journey
for
consolidating
our
instrumentation
and
monitoring
technologies
and
are
are
really
focused
on
kind
of
becoming
vendor
independent
in
those
areas
and
lowering
the
cost
of
change.
When
we
need
to
switch
out
a
given
vendor
or
given
capability.
G
I
have
a
personal
super
deep
interest
in
client
side
observability
browser
and
find
these
discussions
fascinating.
A
Oh
nice,
nice
meeting,
you
all
and
it's
I'm
glad
that
you're
coming
but
there's
interest.
I
think
hopefully
this
this
work
will
get
some
traction
and
we
can.
We
can
come
up
with
the
solution
soon.
A
Okay,
cool
yeah.
I
think
we're
almost
that
time.
So
again,
thanks
for
coming
and
talk
to
you
next
week,
thanks
thanks
mark.