►
From YouTube: 2022-04-06 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
A
B
C
So
from
from
the
la
can
you
all
hear
me.
C
Okay,
thank
you.
So
from
last
week
I
think
we
had
another
meeting
on
tuesday.
C
Unfortunately,
it's
not
on
the
hotel
calendar,
the
public
calendar,
so
I
I'll
check
with
martin
if
there
was
whether
he
recorded
that
meeting.
I
don't
remember
now,
but
in
that
meeting
we
discussed
sessions
in
some
details.
I
have
a
write-up
on
sessions
now
I
think
if
I
I
don't
know,
if
all
of
you
went
through
that
write-up,
you
know
if
you
could
go
through
it.
You
know
that
will
be
great.
A
D
A
Be
good
to
it
yeah
it's
there!
Let
me
share
my
screen.
D
D
D
C
So
so
I'm
I'm
I'm
supposed
to
you
know,
build
a
prototype
to
you
know
demonstrate
what
I
discussed
in
their
sessions
right
up.
I
have
not
worked
on
it
yet,
but
hopefully
next
time
we
meet
I'll
have
something
to
show
so
by
then.
If
you
know
this
could
go
through
that
write
up,
and
you
know,
give
your
comments
that
will
be
great
and
on
the
events
api.
I
have
started
the
discussing
with
the
logs
sig
on
on
the
possibility
of
an
events
api.
C
I
think
if
there
is
a
general
agreement
that
you
know
it
will
be
good
to
have
an
api
for
events,
but
what
is
not
clear
is
whether
it
should
be
extended
for
logs
as
well.
C
So
it
might
take
a
little
while
for
that
discussion
to
settle
based
on
my
understanding,
because
on
one
hand
they
they
want
to
consider
logs
and
events
as
being
you
know
the
same,
not
just
similar
but
the
same,
whereas
you
know
they
don't
want
to
have
an
end
user
callable
api
for
logs
and
and
we
need
it
for
events.
C
So
that
I
expect
you
know
that
to
go
a
little,
you
know
longer.
I
I
will
see
if
anybody
is
interested,
please,
you
know,
go
through
this
right
up
as
well
and
and
you
know
you
can
attend
the
last
thing.
That's
at
10
o'clock
today.
C
One
second:
in
the
logs
data
model-
I
I
want
to
quickly
go
through,
which
ones
are
are
we
going
to
use
and
which
ones
we
are
not
going
to
use
for
our
purpose.
So
I
feel
like
these
three.
You
know
we
should
stay
away
and
only
use
attributes
for
everything,
the
time
stamp
and
attributes
the
body
civility
number
severity
text.
C
You
know
they
I
think
are
originally
meant
for
logs,
because
in
the
logs
api
you
know,
two
things
are
fundamental.
There
is
a
log
level,
which
is
the
severity
number
or
of
the
severity
level
is,
is
fundamental
to
the
logs
api,
whereas
for
events
it
can
be
there,
but
it
is
not
always
present.
C
It's
not
a
fundamental
property
of
events,
and-
and
you
know
you
can
correct
me
if
I'm
wrong
and
the
the
log
message
itself
goes
in
body
and
attributes
is
meant
for
anything
additional,
whereas
in
in
our
case
you
know,
we
could
choose
to
put
the
event
content
in
the
body,
but
I
I
just
feel
like
you
know,
attributes
would
be
you
know
sufficient.
C
So
I
would
like
to
hear
any
comments
on
that.
So
if
you
know
based
on
that,
I
feel
like
you
know,
we
could
have
an
ad
a
rapper
helper
api.
You
know
not
necessarily
anything
official,
something
like
this.
Where
let's
say
you
have
a
method
called
you
know,
add
browser
event
and
you
give
the
event
name
and
attributes.
You
know
you
would
you
would
build
the
event
like
this.
D
Yeah,
so
my
only
question
around
attributes
is:
is
the
as
you've
got
there,
the
flattening
of
the
name
browser.event.name,
that's
like
extremely
inefficient
for
from
a
browser
perspective
in
terms
of
passing
it
so
can
an
attribute
have
an
encoded
value
or
a
blob
like
which
effect
is
what
the
body
is
right.
D
So
I
I
would
be
very
much
against
you
know,
saying:
okay,
everything
is
going
to
have
to
be
flat
and
enumerated
out
as
an
attribute
name
because
from
a
serialization
perspective
and
from
a
performance
perspective
in
terms
of
creating
the
object
to
be
serialized,
especially
in
a
browser,
it's
just
going
to
be
stupid
and
then
the
size
of
potential
events
is
going
to
be
excessive.
B
I
do
think
things
like
event.
Name
can
be,
can
just
be
part
of
the
api
like
like
you,
can
have
special
keys
for
things
like
event,
name
set
event,
name.
D
Well,
no
so
certain
keys,
like
the
name
or
the
type
of
event
fine,
but
in
terms
of
the
body
of
the
of
the
thing
of
the
event
that
we're
talking
about
that's
where
it
gets
really
messy,
because
if
you've
got
a
very
expensive
object,
something
simple
so
say
the
the
browser
performance
object,
which
effectively
has
a
lot
of
attributes.
D
D
Yeah
or
performance
data,
so
if
we
said
okay,
we
have
you
know
this
is
the
name
of
the
event.
This
is
the
type
of
the
event,
and
then
we
just
have
just
using
body
to
say
body
is
the
serialized
thing
of
the
event.
So
therefore
you
you
know
we
have
like
event.type
or
one
thing
that
josh
was
talking
about
last
week.
Is
the
blogs
has
the
concept
of
the
schema?
D
So
if
we
can
hijack
the
schema
and
say
okay,
the
schema
identifies
the
content,
then
the
body
can
be
decoded
by
that
I'm
making
an
assumption
there.
I
haven't
looked
at
the
logs
api.
B
B
You
know
other
than
name,
and
you
know
browser.performancedata
or
whatever
the
the
particular
attribute,
rather
than
like
event
type
performance
data
body
is
the
blob
you
would
just
have
like
attribute
name
performance
data,
and
the
value
of
that
would
be
the
blob.
Does
that
make
sense.
D
C
D
Do
today,
yeah
so
yeah
give
me
a
bit
we
can
yeah.
We
can
move
the
discussion
on
my.
B
Totally-
and
this
also
comes
up
with
recording
things
like
exceptions,
right
and
stuff
like
that,
where
the
the
body.
B
What's
happening
santosh,
I
kind
of
agree
with
tigran's
recommendation.
I
don't
you're
you're
kind
of
name-spacing
all
of
this
by
browser
and
mobile,
and
I
don't
I
don't
see
why
we
need
that.
C
C
Need
a
larger
justification
on
why
we
need
to
have
you
know
such
a
such
an
attribute?
You
know
because
it
it's
you
know
it
could
mean
several
things
so
for
for
a
higher
chance
of
you
know
getting
an
approval,
you
know
they.
I
mean
they
recommended
that
you
know
use
something
that
is
very
specific
to
your
situation.
C
That
way,
you
know,
there's
not
going
to
be.
You
know
much
resistance,
so
it's
it's
just
for
that
reason,
so
I
could
go
back
to
even
dot
names.
B
B
Is
that
an
event
has
a
name
and
possibly
doesn't
have
some
other
attributes
right
and
the
log
had
doesn't
have
a
name
essentially
like
if
you,
if
you
give
logs
a
name
name
being
the
same
kind
of
concept,
is
a
span
name
you're
saying
these
logs
are
now
of
a
type
that
are
like
indexable
and
comparable
to
each
other
in
some
way,
and
as
soon
as
you're
saying
you're
gonna
do
that
with
them?
B
I
feel
like
you're,
now
saying
it's
an
event
and
that's
kind
of
like
the
definition
of
an
event
yeah.
So
I
can.
I
can
go
help
help
make
that
argument
and
yeah.
We
still
have
to
sort
out
things
like
like
log
level
and
stuff
like
that,
but
I
think
if
those
fields
are
optional,
it
can
be
fair
to
say
that
maybe
events
don't
have
to
put
them
there
or
they
just
default
to
info
or
something
like
that.
B
B
C
But
then
the
confusion
is
that
tomorrow
you
know,
if
somebody
wants
to
you
know,
put
severity
for
events.
Should
that
go
into
an
attribute,
or
should
that
be
you
know
since
this
year?
The
reason
I'm
asking
is
it's
kind
of
odd
that
the
name
is
an
attribute.
Severity
is
a
field
for
logs.
I
can
understand,
because
there
is
no
name.
There
is
only
severality.
It
makes
sense
to
be
at
the
top
level
as
a
field,
whereas
for
events
it
feels
hard
to
have
one
as
an
attribute
one.
As
a.
B
I
so
I
proposed
this
to
them
and
they
were
weird
about
adding
more
fields,
essentially.
C
B
C
Yeah
yeah,
I
think
the
name
being
an
attribute
is
okay.
Now
you
know
sh.
Should
we
keep
the
name
as
an
attribute
but
severity
as
a
field
or
or
even
should
also
use
an
attribute
for
severity?
You
know
when
request.
B
B
Okay,
you
know,
at
the
end
of
the
day,
tigran's
argument
to
me
was
sort
of
like
saying:
there's
no
difference
between
fields
or
attributes,
in
which
case
it's
like.
Why
do
we
have
fields,
but
I
I
kind
of
feel
like
we
should
go.
The
other
direction
actually,
which
is
that
name,
is
something
special
and
should
be
pulled
out
of
the
attribute
field,
but
whatever
it's
fine,
so
sometimes
with
spans.
That
name
field
turns
out
to
be
really
annoying
and
problematic,
but
so
maybe
the
same
prevents
but
anyways.
C
Okay
and
with
respect
to
body,
looks
like
you,
you
feel
like
we
should
use
body
for
events
and
not
put
the
even
data.
B
B
There's
no
generic
field,
that's
like
the
the
blob
body
of
this
thing.
It's
just
like
every
blob
of
data
you
want
to
attach
to
an
event.
You
just
need
to
give
it
a
name,
and
so
one
name
is
like
log.
You
know
message
right
for
log
messages,
but
you
don't.
We,
I
think,
we're
just
kind
of
a
little
used
to
overloading
we're
so
used
to
like
shoveling
structured
data
into
like
an
unstructured
log
format
that
we
we
tend
to
to
just
overload
that.
B
But
there's
no
reason
why
you
know
we
can't
just
rather
than
have
the
key
body
just
give
the
key
something
specific
to
whatever
the
blob
of
data.
Is
that
we're
trying
to
attach-
and
it
also
allows
us
if
we
end
up
wanting
to
attach
more
than
one
blob
of
data
to
an
event
for
some
reason
you
can
do
it
and
you
know
you've
lowered
your
your
pursing
issues
right
as
soon
as
you
want
to
attach
more
than
one
thing
you
you're
gonna
have
to
have
some
structure
where
you
can
parse
it
anyways.
So.
C
Okay,
so
I
think
then
nev
is
putting
it
differently,
though
I
think
he
correct
me
if
I'm
wrong,
I
think
you
are.
You
are
suggesting
that
you
should
use
body
right
or
as
equivalent
to
this
data,
that
you
pasted.
D
Or
an
attribute
that
we
can
encode
so
like
I've
gone
through
like
the
list,
you
can
see
the
different
types
of
things
that
are
in
the
in
the
data
content
yeah
and
like
the
base
type
is
the
thing
that
really
says:
okay,
how
does
the
back
end
decode
the
rest
of
the
the
data
which
is
the
equivalent
of
the
schema
thing
that
josh
was
talking
about
last
week,
yeah
so
really.
D
C
D
C
One
question
so
the
id:
what
is
it
unique
for
our
object
here.
C
C
So,
if
we
decide
to,
you
know,
use
metric
instruments
to
send
the
measurements,
then
that
would
be
completely.
You
know
separate
signals
separate.
C
You
know,
entry
in
the
payloads
in
the
payload.
D
Yeah
from
a
browser
perspective,
I
I
wouldn't
even
consider
dragging
in
the
metric
api.
Okay,
I
I
would
you
know
most
browser
level.
Metrics
are
just
a
case
of
this
is
my
data
and
I
want
to
send
it,
but
there
is
no
accumulator
and
histogram
needs,
and
if
there
is,
people
can
go,
build
that
themselves
quite
frankly
and
just
send
them
as
a
single
thing
yeah
that
may
be
different
from
from
a
client
app
perspective.
C
Well,
the
argument
that
I
had
in
mind
for
that
for
for
as
a
case
for
you
know,
using
metrics,
is
that
some
of
these
web
vitals
they,
you
know
you-
will
use
them
eventually
for
constructing
metrics
on
the
back
end
right
and
then
throw
away
the
you
know
the
data
data
that
comes
in,
whereas
there
are
some
other
cases
where
you
need
them,
both
as
an
event
and
as
a
metric.
Let's
say
you
know
a
page
load
right.
How
long
did
the
page
load
take?
C
You
want
to
retain
that
as
an
event
to
show
in
your
session
timeline.
So
if,
if
let's
say
this
requirement
of
you
know
retaining
it
as
an
event
is
not
there
for
some
of
these
items,
then
you
know
by
sending
them
as
metric
instruments
right
from
the
source.
It
makes
it
easy
on
the
back
end
pipelines
to
you
know
just
send
it
to
the
you
know,
metric
authorization
pipelines
to
you
know
put
them
together,
build
build.
You
know
the
larger
metric,
whatever
yeah.
D
So
so
one
of
the
data
elements
that
I've
dropped
in
here
is
a
metric
looks
like
it's
the
fourth
last
one
where
the
the
base
type
is
called
metric
data.
So
you
can
see
there
it's
a
case
that
this
is
just
a
derived
metric
where
it's
effectively
it's
an
array
of
metrics.
D
D
So
if
it's
a
case
of
what
you're
talking
about
is
that's
what
this
is
from
an
application
insight
perspective
where
we
effectively
allow
people
to
send
metric
data,
so
the
back
end
stores
it
as
metric
data
and
then
the
the
the
portal
can
then
go
and
you
know
create
histograms
and
you
know,
do
accumulations
and
averages
and
all
the
rest
from
that
data,
but
it's
not
stored
specifically
as
an
event,
because
it
base
type
is
metric
data.
D
So
I
think
that's
the
same
thing
as
what
you're
talking
about,
but
if
this
is
just
sent
as
an
event,
at
least
from
the
the
stream
perspective,
like
everything
gets
sent
as
the
the
same
type
of
base
data
object
like
I've,
I've
pruned
out
a
lot
of
common
stuff
that
keeps
getting
repeated
and-
and
this
is
just
the
stuff
that
is
different
between
the
different
types
of
events.
D
B
So
I
got
I
got
a
couple
questions
now
for
for
most
of
this
stuff
that
nested
putting
the
metric
stuff
aside.
Would
you
want,
like
page
view,
performance
data,
for
example?
Would
you
would
you
want
all
of
that
information
stored
as
like
a
json
blob
in
a
single
field
for
performance
reasons,
or
are
you
saying
like
that?
That
would
be
obnoxious
you
you
just
you
want.
You
want
a
deeply
structured,
protobuf.
D
Well,
deeply
structured
protobuf
is
problematic
because
effectively
these
these
values
here
mostly
come
from
the
browser.
So
simplistically
we
just
get,
you
know
window.performance,
and
then
we
just
go
jason
stringify.
So
if
a
browser
adds
a
new
field,
it
just
magically
starts
being
sent
down
and
stored
in
the
backend.
D
Yeah
because
otherwise
you
end
up
with
your
browser,
introduces
over
it
adds
removes
field
x
and
you've
got
to
go,
define
it
in
protobuf,
and
then
you
get
a
version
for
it.
I
don't
want
to
get
into
that.
Yeah.
B
D
Yeah
well,
one
of
the
things
you
see
in
every
single
one
of
these
is
properties
and
measurements
properties
is,
is
effectively
from
a
from
a
javascript
perspective,
just
an
object.
It's
a
key
value
pair
map,
which
could
be
a
nested
set
of
key
value
pairs
that
the
user
supplies
for
whatever
purposes
they
like.
We,
we
don't
control
the
content
of
that
in
any
way,
shape
or
form.
D
So
we
have
teams
within
microsoft
where
that
properties
can
contain
a
bunch
of
stuff
like
in
the
case
of
teams.
There's
one
team
when
you're,
actually
on
a
phone
call,
a
single
event
is
greater
than
64k
because
of
all
the
extra
stuff
they
put
in
that
properties
object,
which
they
completely
control.
D
Okay,
so
yeah
properties
itself
is
completely
unstructured.
From
our
perspective,
there's
no
way
we
can
define
a
schema
that
would
work
for
everyone.
B
Right
now,
would
those
people
be
fine
with
that
being
flat,
or
is
that
or.
D
Well,
at
the
end
of
the
day,
they
end
up
querying
it
in
a
database,
so
our
backend
does
flatten
out
the
object
into
like
you
know
the
the
full
keys
from
a
cindy
perspective.
There's
no
way
we
would
want
to
do
that.
It's
just
like
it
can
be
like
10
levels
deep,
and
so
you
end
up
with
a
key.
That's
repeated.
C
So
you
could,
you
could
have
an
attributes
value
as
a
blob
right.
D
So
we
could
say
so
one
of
the
things
I'm
thinking
is:
we
we
define
a
set
of
I'm
going
to
call
it
schemas,
there's
probably
another
word
for
it,
where
we
can
define
different
types
of
data
and
we
can
define
a
set
of
common
stuff.
D
D
But
that
data
just
goes
out
the
door
based
on
whatever
schema
we
come
up
with,
which
should
be
flexible.
B
D
B
C
It's
broader
than
what
it
means
literally,
I
think
I
I
also
used
to
think
that
it
only
refers
to
the
naming
conventions,
but
I
think
it
also.
You
know.
B
Refers
to
the
structural
conventions,
it
means
schema,
I
think
maybe
they
were
hair
splitting
when
they
came
up
with
that
name,
because
you're
saying
the
schema
within
the
context
of
like
a
data
structure
that
you're
not
you're,
not
defining
that
data.
B
So
I
think
some
people,
maybe
hair
split
about
whether
the
the
schema
is
like
the
the
otp
level,
data
structure,
yeah
and
we're
saying
like
within
otlp.
You
don't
you're,
not
redefining
that
defining
the
the
schema
for
each
type
of
structured
data
that
you're
sending
yeah
and
and
so
we
we
call
those
semantic
conventions.
But
that's
that's
what
it
means,
basically
yeah.
So.
D
So
internally,
in
microsoft,
we
have
a
common
schema
definition,
yes,
which
riley
sort
of
owns
yeah,
and
then
we
have
a
yeah.
So
we
have.
We
have
a
mapping
from
hotel
semantic
conventions
to
our
common
schema,
but
effectively
it
is
just
you
know,
defining
what
they
are.
B
And
then
there's
also,
I
should
mention:
there's
elastic
common
schema,
which
again
yeah.
These
are
all
we
call
these
semantic
conventions.
Maybe
we
could
change
that,
but
that's
that's.
What
we
would
do
is
go
in
and
say
yeah
for
each
one
of
these
common
common
event
types
before
that
the
browser
admits
like
this
is
what
you
should
send.
So
everyone
knows
what
to
expect
in
what
field,
and
that's
also
where
you
can
define
what
gets
you
know
sent
as
a
json
blob
versus
like
its
own
set
of
attributes.
B
B
The
presumption
is
all
of
this
stuff
is
getting
stored
in
a
database,
that's
flat
like
a
column,
storage
system,
and
so
they
want
to
like
discourage
people
on
some
level
from
designing
their
semantic
conventions
and
their
event,
data
to
be
like
deeply
nested,
because
it's
just
like
not
going
to
end
up
that
way
when,
when
you
get
it,
but
the
flip
side,
I
think,
is
the
efficiency
mattering
the
way
it
does
for
actually
sending
this.
This
yeah.
D
Like
I've
just
placed
it
in
the
comments,
well
generally
the
common
stuff,
so
this
is
included
on
every
event
that
goes
out
the
door.
It
does
change
slightly
based
on
the
type,
but
it
takes
just
as
much
cpu
to
generate.
It
actually
takes
more
cpu
to
generate
the
object
that
we
then
convert
into
json
for
this
section
alone
than
it
does
for
all
the
other
bits,
because
we
have
to
generate
those
flat
keys.
B
And
if
we're
in
a
world
where,
like
deeply
nested
stuff,
that's
coming
in,
is
generally
coming
in
from
like
some
external
source,
where
what
we
want
to
do
at
the
end
of
the
day
is
just
blob
it
up
yeah,
then
I
think
we're
fine.
B
I
think
we
only
have
to
really
start
poking
at
our
protocol
if,
if
we
start
saying
like
like
no,
actually,
we
need
the
ability
to
construct
this
stuff
ourselves
in
a
way.
That's
this
deeply
nested.
B
B
Yeah
and
then
you
can't
at
that
point,
you're,
maybe
stuck
with
guessing
whether
you
have
a
json
blob
or
not
that
that's
the
only
like
squiggle
I
can,
I
can
think
of,
but
you
can
certainly
have
an
api
that
by
default,
if
what
somebody
does
is
give
you
event,
name
foo
and
the
value
is
an
object.
B
You
know-
or
you
know,
like
a
piece
of
structured
data
that
that
we
do
the
right
thing,
yeah
and
maybe
the
answer
is
to
to
add
like
an
additional
key
right
next
to
that,
one
that
just
finds
that
something
yeah
it
defines
the
encoding
essentially
yeah
like
this
is
something
so
I
think
I
think,
there's
a
way
to
get
around
it,
that
that
wouldn't
murder
us
on
performance,
yep.
C
So
so
a
couple
things
so
for
for
defining
the
schema
of
the
individual
events.
Let's
say
we
have
a
we
would
list
down.
Hey
here
are
the
different,
even
types
that
that
you
know
our
default
instrumentation
generates
and
for
each
even
type
you
list
you
know
here
are
the
different
attributes.
C
You
know
that
you
know
will
be
there.
That
should
be
sufficient
right.
D
Yeah,
I
I
think
if
we
we
go
through
and
we
we
define
so
probably
one,
not
the
one
like
I
don't
know
how
many
different
companies
we
got
represented
in
this
meeting,
we'll
probably
go
through
and
define
the
different
types
of
events
that
we
that
we
all
play
with
and
then
map
out
the
the
fields
and
then
let's
just
try
and
make
them
common.
D
So
from
a
semantic
convention
perspective,
so
from
anything,
camera
from
hotel
always
looks
like.
If
it's
I
don't
know
some
random
event,
then
it's
going
to
have
these
particular
keys
or
it
should
have
these
particular
keys
or
may
have
these
particular
keys.
And
then
we
just
define
from
that
perspective,
and
then
we
say-
and
this
is
how
it
goes
out
the
door
and
then
you
know,
potentially
we
could
have
okay.
D
These
are
these
are
the
refined
sets
of
types
that
we
know
about
yeah,
but
vendors
can
extend
it
and
then
maybe
come
up
with
a
naming
convention
so
that
you
know
if
it's
a
vendor-specific
event,
it
gets
a
specific
name,
so
they
can
then
decode
it.
However,
they
like.
C
Yeah,
so
so
I'm
assuming
we
do
that
now,
I
want
to
confirm
on
this
from
in
terms
of
the
log
data
model.
Can
we
just
can
we
say
that
we
will
be
using
attributes
only
and
not
bodies.
D
My
only
thing
is
as
long
as
an
attribute
can
be
an
ob,
the
value
of
an
attribute
can
be
an
object
and
it
doesn't
have
a
size
limit
on
the
on
its
value.
So,
even
if
it,
if
we
just
say
it's
going
to
be
a
string
and
we're
going
to
json
encode
it
is
there
a
size
limit
today
on
the
value.
D
D
B
And
for
for
what
it's
worth,
the
I'm
looking
at
the
log
data
model
and
it
does
allow
deeply
nested
structures
in
it.
Okay,
so.
C
B
B
Yeah,
you
just
don't
want
to
put
those
objects
at
like
the
root
level,
essentially
like
what
you're
doing
in
your
your
model
yeah
each
each
one
of
them
needs
to
be
under
its
own
key
yeah.
I
should
mention
you
know
the
only
thing
you
pointed
out
there.
I
totally
agree
with
you
that
we
should
be
using
events
for
all
of
this,
and
if
someone
wants
to
like
count
them
or
do
something
they
can
do
that
later,
we
should
make
sure
you
know
they're
structured
in
such
a
way
that
it's
easy
to
do
that.
B
D
Yeah
yeah
because,
like
you're
yeah,
when
you,
when
you're
playing
with
clients,
you've
got
millions
of
clients,
you
don't
want
to
count
things
on
an
individual
client
basis.
You
want
to
count
them
based
on
okay,
based
on
these
million
million
users.
You
know
this
percentage
of
is
getting
this
time
frame,
whatever
yeah.
B
You
you
did
have
one
that
was
like
where
it
was
like
actually
literally
metric
data
yeah
and
I
think
for
the
ones
where
we're
saying,
like
literally
we
are
trying
to
shovel
metrics
data
out
the
door
it.
It
does
seem
reasonable
to
me
that
that
should
go
out
as
like
structured
metrics
data
in
otlp,
and
I'm
just
wondering
if
there's
a
way
to
do
that
that
you
know
avoids.
B
D
B
Yeah
I
should
see
where
that
landed.
We
we
used
to
have
something
like
that.
We
were
calling
them
measurements,
I
think,
was
the
thing
josh
wanted
originally
where
it
was
like
yeah,
here's
just
the
here's,
just
the
measurements,
but
we're
not
telling
you
what
what
to
do
with
them.
Like
a
lower
level,
api.
D
Yeah
for
us
that's
generated
by
a
function
called
your
custom
metric
like
we
don't
define
the
metrics
at
all.
We
just
say
you
can
give
it
a
value.
A
standard
deviation,
the
average
whatever,
which
is
where
the
kind
comes
in.
But
you
define
what
it
is.
We
don't
care
we're
just
sending
to
the
back
end
and
then
the
back
end
will
then
do
with
magic.
C
There
is
one
thing
we
should
note
is
that
this,
even
if
we
are
not
encoding
these,
this
data
as
metrics,
nothing
prevents
end
users
developers
to
to
to
use
the
hotel
api
to
create
their
metrics
and
and
then
send
it.
C
D
Just
the
size
of
the
source
code
required
to
create
just
right,
the
sdk
yeah
like
in
in
a
browser
sizes
everything
so
like
the
amount
of
the
api
and
the
sdk,
so
the
code
required
to
send
out
a
metric
which
most
people
won't
do
based
on
what
we
see
or
they're,
only
sending
out
a
couple
of
minor
ones.
D
D
B
I
I
do
think
yeah
separate
separate
from
this
discussion
about,
like
you
know,
should
we
send
any
metrics
or
not,
there's
like
clearly
a
need
to
fork
off
the
browser
sdk
from
the
node
sdk,
essentially
like
like
that,
that
team
has
been
taking
the
approach
of
where
engineering
resources
are
our
bottlenecks.
So
we
want
to
reuse
as
much
code
as
possible,
but
I'm
sure
certain
that
the
side
effect
of
that
approach
is
that
the
browser
sdk
is
like
not
optimized
for
not.
D
B
B
Yeah
and
there's
so
yeah,
and
you
can't
you
can't
have
both
right,
like
you,
can't
have
an
sdk
that
leverages
libraries
and
does
a
whole
bunch
of
code
reuse
across
like
multiple
use
cases
and
something
that's
designed
to
have
like
the
smallest
code.
Footprint
like
those
those
are
like
opposite
goals.
B
So
I
think
the
answer
there
is
to
look
at
like
you
know
now
that
things
are
like
stable
in
hotel
or
like
assuming
metrics
and
logs
like
the
apis
are
stable,
then,
like
it's
time
to
do
the
work
to
completely
fork
the
browser
sdk
off
of
the
the
node
sdk
or
essentially
build
a
new
browser.
Sdk.
B
For
being
used
in
the
browsers
yeah
for
sure
and
and
maybe
as
part
of
that
work,
we
can
also
look
at
you
know.
My
hope
would
be
that,
on
the
other
side
of
doing
that,
adding
the
the
metrics
part
of
it
isn't
onerous,
but
maybe
it
would
be.
D
Well,
if
someone
really
wants
to
you
know,
I
I
think
we
should
have
the
option
but
yeah.
I
would
prefer
to
see
something
simple
like
because
firing
metrics
from
a
browser
really
is
a
yeah
as
simple
as
this
you're
sending
off
a
small
amount
of
data.
I'd
prefer
to
see
that
as
as
the
option
for
sending
it
as
an
event,
let's
put
it
that
way.
B
This
sorry,
real
quick
just
I
would
say
my
one
request-
would
be
that
for
us
when
we're,
if
at
all
possible
for
the
all
of
the
common
schema
stuff,
we're
defining
that
we
we
swerve
away
from
defining
a
metric
data
kind
of
thing
like
in
my
ideal
world.
That
stuff
is
like
something
like
an
end
user
wants
to
do,
but
I
I
don't
know
if
there's
like
any
reason
for
us
to
be
doing
that
with
the
like
standard
data
we're
producing
out
of
our
instrumentation.
D
Yeah,
I
think
we,
if
we
can
just
say
we
have
the
option
of
sending
metric
data
like
I've
gotten
this
sample
here,
but
the
shape
of
it
is
the
exact
same
shape
that
the
the
adjacent
hotel
key
metric
would
look
like.
I
don't
have
to
redefine
that
if
we
don't
need
to
exactly
like,
if
someone
really
wants
to
send
a
histogram
out
of
the
browser,
fine
go
and
construct
the
histogram
in
the
browser
and
send
it
as
a
custom
metric
data
or
go
and
drag
in
the
metrics
api.
B
Yeah,
but
we
at
least
could
maybe
try
to
put
ourselves
in
a
position
where
we're
not
sending
any
of
these.
So
even
if
the
answer
is,
you
want
to
send
some
metrics,
you
have
to
drag
in
the
metrics
api
or
like
this,
like
lightweight
version
of
the
metrics
api,
or
you
know
whatever
it
is
that
either
way,
that's
still
something
they're
dragging
in
because
they
want
to
do
this
extra
thing
by
default,
the
instrumentation
we
supply
to
people
doesn't
doesn't
drag
in
any
of
that
stuff.
C
I
don't
know
enough
about
the
matrix
api,
but
I
have
a
feeling
that
you
know
it's
more
than
just
the
data.
It
also
tells
you
what
is
the
type
of
the
the
aggregation
temporality
right.
I
think
it
also
that
there
is
more
than
just
the
numbers.
It
also
has.
You
know
how
the
data
should
be.
You
know
interpreted
when
when,
when
it's
processed
by
the
the
back-end
systems
so-
and
that
is
why
you
know
it's
good-
to
use
the
metrics
api.
C
So
so,
if
we
don't
use
the
matrix
api,
you
know
we
might
need
at
least
an
equivalent
interface
to
you
know
to
standardize
how
the
metrics
are
and
are
you
know?
Serialized
I
mean
what
all
information
you
need
to
capture
so
so
that
you
know
at
least
for
custom
metrics.
When
customers
define
those
metrics,
you
know
they
provide
all
the
required
information
there.
B
Yeah,
like
I
guess,
that's
what
I'm
requesting,
I
don't
want
us
to
start
redefining
a
metrics
protocol
in
events
like
if
someone
wants
to
send
a
metric,
we
have
a
metric
system,
we've
defined
for
doing
that.
If
it's
missing
a
lower
level
api
that
allows
you
to
just
shovel
some
data
out.
B
You
know
we
can
look
at
that,
but
but
I
would
I'd
really
like
us
to
to
not
end
up
with,
like
that'll,
be
like
this
weird
squiggle,
if
metrics
are,
are
showing
up
in
the
event
like
in
basically
in
the
logging
portion
of
the
of
otlp
like
if
we're
gonna
send
something,
that's
just
explicitly
a
measurement
and
nothing
more
like.
I
really
think
yeah.
We
should
figure
out
a
way
for
that
to
go
and
structured
as
otlp
metric
metric
data
of
some
kind,
and
but
I
also
think
like.
B
B
You
can
create
common
collector
processors,
for
example.
You
could
create
metrics
collector
processors
that
will
turn
those
events
into
metrics
like
if
there's
some
standard
set
of
metrics
somebody
wants
to
get.
They
do
that
in
a
collector,
or
they
can
do
that
in
their
back
end.
B
You
know
like
the
their,
which
is
probably
where
it's
gonna
happen
for
for
most
of
these,
like
you
know
professional
systems,
but
but
we
we
don't
need
to
be
defining
metrics
in
our
instrumentation,
like
in
general,
I'm
a
little
bit
weirded
out
about
defining
metrics
in
our
instrumentation,
where
people
are
like,
even
on
the
server
side,
where
they're
like
we
want
to.
B
You
know,
emit
http
metrics
for
these
like
http
events
and
spans
that
are
happening,
and
we
can
do
that
on
the
server
side,
because
there's
room
to
do
it,
but
to
a
certain
degree
like
you,
could
always
just
derive
that
stuff
from
the
data
we're
already
sending
so
like
I,
I
haven't
seen
a
place
yet
where
it
was
like
really
necessary
for
us
to
be
sending
metrics
out
of
our
instrumentation.
B
It's
just
like
on
the
server
side.
Sometimes
like
that's,
actually
an
optimization.
You
want
to
make
where
it's
a
little
more
optimal
to
just
you
already
know:
you're
gonna
want
these
metrics
so
rather
than
dynamically
construct
them
later
down
the
chain,
just
like
also
admit
it
as
a
metric
right
now
hard-coded
and
be
done
with
it.
B
D
Yeah
a
good
example
that
is
for
the
back
end.
You
know
you
want
to
collect
memory,
usage
and
cpu
usage,
because
you're
going
to
use
that
to
figure
out
where
you're
going
to
scale
up
on
a
browser.
D
You
don't
want
to
collect
that
because
well,
everyone's
machine
is
different,
so
your
cpu
and
your
memory,
it
doesn't
make
sense
to
to
join
that
back
together
and
unless,
of
course,
you
happen
to
grab
the
memory
at
the
very
start,
and
then
you
sample
it
halfway
through
to
figure
out
the
delta,
but
then
you're
just
collecting
a
measurement,
and
you
send
that
back
as
a
measurement.
So.
B
D
And
you
need
like,
when
I
was
on
the
identity
team,
we
needed
to
keep
track
of
the
number
of
open
ports,
memory
usage,
all
the
rest
as
well
as
based
on
the
region.
So
we
knew
whether
to
you
know
how
many
additional
machines
we
need
to
scale
up
the
system
automatically.
That's
just
when
you're
monitoring,
back-end
systems,
that's
completely
different
than
when
you're
monitoring
funding.
B
Okay,
one
one
final
note,
just
a
reminder:
we're
muji
merging
in
the
elastic
common
schema
elastic
has
their
own
semantic
conventions
essentially
and
they've
had
a
schema
for
a
while,
and
they
came
to
open
telemetry
and
we're
like.
B
We
would
like
to
just
merge
with
you
guys,
as
far
as
like
all
the
schema
stuff,
because
it's
just
like
a
better
world
when
more
of
us
are
agreeing
on
one
schema
than
having
like
multiple
standards
and
their
approach
is
they're
willing
to
do
the
work
of
looking
at
where
the
schemas
are
different
and,
in
those
cases,
basically
basically
like
using
the
open,
telemetry
version.
B
If,
if
there's
some
difference
in
like
naming
conventions
and
stuff
like
that,
but
they
I
think
on
the
because
elastic
is
like
more
traditionally
like
a
logging
system,
it
wasn't
a
tracing
system.
B
There
wasn't
like
a
heck
of
a
lot
of
overlap
there,
but
for
the
stuff
we're
doing
there,
there
might
be
so
when
it
comes
to
you
know,
defining
like
this,
the
conventions
you
know
the
schema
for
for
browser,
mobile
events
and
stuff,
like
that,
I
would
suggest
people
just
have
like
a
look
see
at
the
elastic
common
schema
and
just
see
what's
in
there
today
in
our
ideal
world
like
the
stuff,
they
have
is
already
there
and
is
like
acceptable
to
us
as
far
as
like
what
we
would
want
and
because
that's
by
default,
I
think
what
we're
gonna
we're
gonna
end
up
with
so
obviously
like
we
can.
B
D
B
Currently,
if
you
google,
it
that's
like
on
their
website,
but
they're
they're
gonna
merge
that
in
with
open
telemetry,
I
believe
it's
a
plan
right.
So
what
they'll
do
is
they
will
release
one
final
version
of
elastic
common
schema
that
is
like
migrated
over
to
you
know
what
the
merged
version
would
look
like
and
then,
from
that
point
onwards
anything
they're
publishing
over
there
would
be
downstream
of
work
being
done
over
over
here
in
open
telemetry.
So
if
they
want
to
continue
to
adjust
their
schema,
they
would
be
doing
it
here.
B
I
believe
that's
a
plan,
but
that's
that's.
That's
still
a
little
loose
that
that
hasn't
like
it's
been
proposed
by
elastic,
but
I
don't
nothing.
Concrete's
happened
yet.
D
Yeah,
like
our
long
term
plan,
is
to
try
and
standardize
so
that,
whether
someone's
coming
to
us
or
going
from
us
effectively
for
them,
they
should
be
changing
the
back
end
where
they're
sending
their
data,
or
you
know
that
they
have
a
forking
mechanism,
so
it
actually
sends
it
to
both
so
that
this
part
of
their
migration
they
can
validate
that.
You
know
vendor
a
is
doing
what
been
to
b
is
as
well.
B
Yeah
yeah
and
in
the
case
of
like
the
elastic
universe,
they're
they're
migrating
over
to
open
telemetry
as
far
as
their
pipeline
anyway.
So
that's
part
of
why
they're
doing
it
so,
like
long
term,
they're
gonna,
you
know
deprecate
their
own
clients
and
agents,
and
things
like
that.