►
From YouTube: 2023-01-04 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
B
B
Thank
you,
so
we
don't
have
the
Regular
folks
yet
so,
if
you
folks
have
any
topics
to
discuss,
we
can
go
at
otherwise
we
can
end
the
meeting.
C
C
If
the
computer
hibernates,
then
the
start
time
is
very
in
the
like
in
the
past,
so
I
wonder
if
there's
some
like
advancement
in
it
in
this
area,
but
I
didn't
have
the
chance
to
to
read
all
of
like
all
of
the
pr,
and
it's
like
very
like
long
and
complex
right.
C
B
I'm
not
too
familiar
with
with
that
topic
myself,
I
I,
yeah
I
have
seen
some
discussion
about
it
too.
On
GitHub.
B
Yeah,
the
agenda
of
this
working
group
is
to
write
down
the
specification
around
everything,
browser
and
and
even
the
mobile,
so
so
I
think
when
we
get
to
that
stage,
I
think
in
a
few
months,
hopefully
in
a
few
weeks,
I
think
we
we
should
write
down.
B
Maybe
Martin
knows
about
it.
I
think
Martin
has
joined,
hi
Martin,
happy.
B
Hey
there's
a
question
about
you
know
the
expected
behavior
when
you
know
somebody
hibernates
their
laptop
in
the
middle
of
a
span.
C
Yeah,
in
my
case,
the
usages
with
the
performance
object
and
the
it
uses
the
last
last
time
it
was
hibernated,
so
I
had
spans.
That
are
the
start.
Time
is
two
weeks
like
ahead
like
before
two
weeks
past.
C
So
I
think
it
was
for
all
instrumentations,
not
something
specific,
but
I
can
check.
D
B
So
it
also
depends
on
the
expectations
of
the
back
ends.
For
example,
in
our
case
you
know,
I
I
will
have
to
double
check,
but
let's
say
if
the
back
ends
you
know
are
not
interested
in
any.
You
know
data
Beyond,
let's
say
let's
say
hypothetically
in
an
hour,
then
you
know
when
you
wake
up
and
you
find
spans
that
are
older
than
one
hour.
You
know
you
can.
You
can
discard.
B
D
D
So
like
it
captures
everything
else,
as
events
essentially
and
the
like,
the
document
load
is
probably
the
biggest
the
big
one,
but
I
mean
yeah
I
mean
it
happens
like
so
I.
D
So
sorry,
I'm,
gonna
rambling,
but
it
happens
that
that
certain
metrics
can
be
can
represent
values
that
are
not
real,
like
like,
for
example,
like
the
largest
content
for
paint
like
if
you
you
know,
if
you
yeah,
if
your
computer
shuts
down
you
come
back
to
the
same
session
and
then
you
know,
like
the
biggest
biggest
element
paints
to
the
window
to
the
screen,
like
you
know,
hours
later,
since
you
started
that
is
captured
because
that's
that's
what
happens?
D
D
The
instrumentation
itself
doesn't
doesn't
take
those
values
out.
They
simply
rub
them.
B
D
B
But
the
question
is
like:
what
does
this
the
client
side
on
the
browser
side?
What
does
the
instrumentation
send
in
the
for
the
timestamps?
What
time
stamp
does
it
use
for
the
end.
D
Yeah
I
mean
it
would
be
the
actual
time
stamp.
I
mean
it's,
it's
relative.
B
B
So
assuming
the
performance
objects
and
I'll
give
you
the
right
information,
then
it's
a
matter
of
whether
you
want
to
export
an
old,
a
really
old
span
or
not.
You
know
that
span
itself.
My
you
know
will
have
credit
info,
but
whether
it's
relevant
now
or
not
that
that
really
depends
on
you
know
the
capabilities
of
your
backends
yeah.
B
But
if
the,
if
the
performance
information
is
selfish,
is
wrong,
then
I
I,
don't
know
what
we
can
do
you
know,
I
I
would
just
drop
that.
Assuming
that
you
know
not
many
end,
users
will
be
doing
that
simultaneously.
So
the
loss
of
information
is
not
much.
D
Yeah
yeah
I
guess
my
question
would
be
like
how
how
much
of
a
problem
is
this
I
wouldn't
expect
that
to
happen
very
often.
C
Right
yeah,
for
me,
it
happened.
I
just
started
to
play
around
with
the
with
the
web
SDK,
and
it's
happened
to
me
like
the
first
time
that
I
tried
to
play
with
it.
Maybe
you
know
it's
an
outlier,
like
you
said.
B
Hibernate,
the
laptop
and
you
know
open
it
an
hour
later
for
the
span
time
stamps
be
one
hour
apart.
C
So,
for
me
it
was
two
weeks
apart
and
start
time
for
two
weeks
passed.
B
Sorry,
can
you
repeat
that
last
statement,
the
the
start
and
end
time
stamps
for
two
weeks
apart?
Yes,.
C
They
know
the
duration
was
fine,
but
the
start
time
was
two
weeks
pass.
So
maybe
I
like
you
said
I
need
to
fix
it
on
the
UI
or
on
the
back
end
or
maybe
I
can
somehow.
C
Create
a
span
with
a
different
like
when
I'm
constructing
this
pen,
I
can
add,
like
the
date
now
or
something
like
that,
I'm,
not
sure.
Yet
what
I
can
do
with
it,
because
right
now,
it's
very
problematic
for
me,
because
I
have
like
dispenser
not
describing
like
what
like
I,
can't
search
them,
for
example,
because
the
timestamp
is
is
not
accurate,
like
really
not
accurate,
not
like.
D
Well,
I
guess
I
guess
my
my
first
thought
it
would
be
like
to
not
fix
it
in
the
instrumentation,
but
in
the
back
end,
because
the
instrumentation
is
just
observing
what
it
act.
You
know
it
captures
what
it
observes
and
then
the
back
end
should
say:
okay,
this
doesn't
seem
reasonable.
So
this
is
an
outlier
that
we
should
not
include.
D
B
So
do
you
do
you
know
which
was
the
GitHub
ticket
Maybe?
D
Yeah,
it's
very
interesting
that
it
that
you
that
it
happened
to
you
like
right
away,
I
would
I
would
expect
it
would
be
hard
to
reproduce
it's
because
Ajax
calls
typically
are
pretty
quick,
so
I'm
kind
of
surprised
that
it's
a
that
it's
a
issue
that
seems
like
a
you.
B
B
D
C
I
sent
here
the
a
comment:
I
added
that
you
can
see
here.
The
the
performance
now
result
the
time
origin
and
the
date
like
the
how
how
much
farther
apart
like
it's.
This,
for
example,
happened,
I,
think
in
27
in
December
and
the
and
the
performance
now
is
from
the
11th
in
December
just
one
example
and
I
like
I'll,
add
the
thing
this
PR
is
also
related.
A
C
D
A
C
C
This
is
what's
being
used
and
for
some
reason
it's
it's
not
it's
like
not
accurate.
I
also
saw
like
PRS
on
other
sdks.
It
has
been
this
issue,
for
example
in
Sentry
SDK.
They
have
similar
implementation
and
similar
issues.
So
it's
interesting,
but
as
I
understand
the
status
right
now,
it's
it's
there
is
it's
an
open
discussion
for
a
long
time
about
this
problem
and
no
solution
that
is
selected
yet,
as
I
understand.
D
Okay,
let
me
let
me
read
this
and
but
let
me
take
a
look
at
this.
C
B
Think
we
would
like
to
continue
that
and
then
more
folks.
D
D
B
Yeah
I
think
I
I,
think
I
mentioned
in
in
a
slack
comment.
I
think
I
think
I
would
not
worry
too
much
about
the
API
itself.
Now
you
know,
because
we
we
are
not
able
to
use
the
logging
API
today
because
the
SDK
doesn't
exist.
D
B
D
Guess
the
first
thing
that
I'm
trying
to
decide
is
because
I
want
to
continue
working
on
the
logs
SDK
The
Lost
logs
SDK
needs
to
implement
the
API,
and
if
the
events
API
is
in
there,
then
you
know
it's
we're
going
to.
You
need
to
implement
it
right.
B
The
but
the
event
API
itself
is
is
a
purely
wrapper
over
log
API
right,
so
you,
which
means
that
when
we
create
events
using
the
event
API,
if
the
instrumentation
uses
events
API
the
the
end
user,
you
know
will
still
be
exporting
them
using
the
log
SDK
yeah
yeah.
So
the
log
SDK
only
needs
to
know
about
the
log
API.
D
But
okay,
so
that's
yes!
So
so
so
right
now
the
logs
API
has
the
events
API
in
the
same
package.
Oh
packaging,
wise,
okay
and-
and
there
is
I-
would
like
to
separate
it,
but
others
think
that
it
should
be
stay
the
same,
because
the
spec,
currently
you
know,
has
it
described
in
a
certain
way
like
the
spec
right.
The
spec
right
now
for
events
API
basically
says
that
it's
just
a
syntactic
sugar
on
on
top
of
the
logs
API.
D
B
A
D
D
I'm
gonna
have
to
I,
have
a
new
laptop
I'm
gonna
have
to
like
relog
into
Zoom,
but
so
give
me
a
moment.
I'll
be
right.
Back
yeah.
D
D
Okay?
So
so
we
have,
let's
say:
okay,
so
here
is
currently
t.
D
B
D
And
then
we
have
so
there's
a
there
is
an
class
for
log
record
and
separate
class
for
log
event.
The
way
that's
implemented
right
now
is
that
the
log
record
obviously
is
straightforward.
Log
event
has
only
the
fields
that
apply
to
to
events
so
which,
which
I
think
is.
What
is
the
right
is,
is
the
right
thing
to
do,
because
the
API
should
help
you
capture
only
the
things
that
you
want
to
capture
right,
because
otherwise,
otherwise,
why
even
have
events
API?
You
could
just
use
log
records.
D
So
here
is
this:
this
person
has
an
open
PR
per
day,
where
they
are
proposing.
Basically,
that
they're
saying
the
spec
I
want
to
update
the
the
API
based
on
the
current
spec,
and
so
they
are
separating
the.
D
B
So
I
think
the
the
yeah
I
think
the
this
is
different
from
how
it
is
done
in
Java
for.
B
I
I
think
they.
If
we
go
back
to
you,
know
your
current
code,
where
you
have
a
logger.mit
event,
yeah
yeah
I
think
the
way
the
Java
API
you
know
handles.
This
is
through
the
builders
right,
the
Builder
pattern,
and
when
you
build
an
event
that
Builder
only
allows
you
to
set
Fields
yeah
that
are
relevant
for
an
event,
for
example,
but
but
even
there
today,
they
don't
as
far
as
I.
B
Remember
correctly,
I
think
they
don't
prohibit
you
to
set
other
fields,
let's
say
body
right,
so
that
that's
that's
a
gap
today,
I
I
think
it
occurred
to
me
sometime
but
I
it
slipped
my
mind
so
that
Gap
exists
even
in
in
Java,
where
you
know
you
can
create
an
event
with
by
you
know,
with
Fields
not
relevant
to
events.
You
know
you
can
set
those
yeah
and-
and
that
is
the
problem
you
try
to
handle
and
you
are
running
into
other
issues.
B
D
B
So
let
me
ask
you
one:
you.
D
B
Crude
method,
if,
if
that's
a
reasonable
and
I
know,
this
is
a
not
a
good
suggestion,
but
let's
say
you
know
from
from
you
know:
API
perspective
you
allow,
but
during
run
time
you
check
and
and
then
through
an
error.
If,
if
the,
if
the
user
tries
to
set
fields,
are
not
relevant
API
to
the
events.
D
Well,
the
the
problem
here
I
mean
what
I'm
thinking
here
is
like
once
we
start
using
the
API
in
instrumentations,
then
we'll
probably
be
probably
hard
to
change
at
that
point.
B
Yeah,
actually
the
issue
is
you
know.
Typically,
when
we
talk
about
object,
abstractions,
you
know
you,
your
base,
classes
has
fewer
fields
and
your
derived
class
has
more
Fields
right
here.
It's
the
opposite,
so
your
log
record,
your
your
derived
class,
which
is
an
event
so
event,
is
a
log
record,
but
you
know
it
cannot
use
all
the
fields
right.
B
No
I
I
agree,
but
but
in
open
Telemetry
you
know
you
know
an.
A
B
Is
a
log
record
right
and
even
T
is
a
log
record.
It's
just
that.
You
know
you
want
to
prevent
like
current
feels
from
being
said
and
and
therefore
just
do
a
runtime
yeah,
you
know
check
I,
think
that
would
be
more
cleaner.
In
my
opinion,
it
will
also
keep
it
consistent
with
with
how
it's
going
to
be
in
other
languages
and
and
even
the
spec.
B
Yeah,
so
so
even
the
when
the
when
the
event
logger
emits
an
event.
At
that
point,
you
check.
For
example,
you
know
whether
it
is
setting
fields
or
that
it's
not
supposed
to
set.
D
B
So
this
is
a
a
spec
question,
though
yeah.
This
is
a
spec
question,
so
if
the
spec
can
clarify,
then
then
that
will
answer
so.
D
You'll
see
the
last.
The
last
discussion
we've
had
during
the
log
sake
and
I
think
you
were
there
is
is
Tegan
was
saying
that
we
should
come
up
with
our
with
a
proposal
for
the
events
API,
that
we
think
we
need
and
then
then
use
it
as
an
example
to
you
know,
to
bring
it
to
the
spec
and
discussion,
because
I
think
this.
This
spec
for
the
API
Is
Not
Great,
currently.
B
No,
but
from
a
pure
software
design
perspective,
things
are
also
getting
complicated
right.
If,
if
we
go
the
way
you
know
you're
suggesting
where
you
split
the
the
data
model
for
events
and
logs,
so
either
we
keep
them
completely
separate,
and
if
we
are
going
to
you
know,
reuse
any
part
of
the
code
between
the
two,
then
they
better,
you
know
be
related.
C
D
B
Well,
we
didn't
have
an
option
right,
the
log
record,
although
the
protobuf
Has
a
Field
called
name
it
was,
it
was
removed
in
the
spec.
D
Right
right,
so
so
so
this
the
way
that
this
API
is
written,
it's
taking
an
a
name
as
an
as
a
parameter,
but
then
it
would
just
behind
the
scenes.
It
would
just
copy
it
into
the
log
record.
Yeah.
B
Api
yeah
so
so
give
or
take
you
know.
This
is
not
a
clean
design
for
sure
Martin
I
think
we
have
to
go
with
compromises
because
I
think
I
think
the
the
the
root
of
this
you
know.
All
this
is
is
is
the
fact
that
you
know
the
events
are
being
represented.
Using
lock
records
in
open,
Telemetry,
right,
I
think
that
fact
itself
is,
is
causing
so
much
confusion
all
over.
So
we
better
accept
some
faults,
accept
them,
as
you
know,
truth
and
and
then
put
it
on
top
of
it.
D
Okay,
so
like
so
going
back
to
my
original
question,
you
know
like
one
of
the
options.
One
of
the
options
is
to
have
a
separate
package
just
for
the
events,
API
would
still
have.
D
It
would
still
be
like
the
implementation
would
still
use
to
log
log
SDK,
but
it
would
be
separate
from
the
logs
API
package.
B
They
will
it
give
us
anything,
I
mean
what
what
will
it
give
us
by
having
a
separate
package.
So
let's
say
somebody
wants
to
only
emit
events.
You
know
they
will
import
the
events
API
package.
C
B
D
B
Lot,
yeah,
so
that
the
fact
cannot
be
you
know,
taken.
D
B
B
Yeah,
that
is
fine
yeah,
that
that
part
I,
yeah
I,
didn't
realize
yeah.
You
can
in
fact
the
original
event
API
that
John
Watson
had
in
in
one
of
these
Planck
packages
it
it
took
only
the
name
and
attributes.
Okay,
that
we
had
discussed
in
one
of
the
very
early
meetings,
yeah
yeah.
B
Yeah
I
mean,
let
me
know
offline
too,
like
if
we
want,
you
know
we
can
talk
anytime,
don't
have
to
wait
till
next
week,
yeah
I
think
yesterday,
Ted
was
they're
in
the
call
I
just
tattoo
of
us
and
I
think
he
he's
going
to
get
somebody
from
TC
and
and
federal
timeline
that
we
need
to
make
progress
in
six
weeks.
So
I
think
it's
it's
better.
If
we
speed
up
log,
says
decay
in
some
way.
That
way,
you
know
we
can
demonstrate
some
end-to-end
examples.
B
B
D
B
Okay,
all
right
I'll
add
these
two
to
the
notes.
If
there
isn't
anything
else,
we
can
stop
here.