►
From YouTube: 2022-12-14 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
Thank
you.
Okay,
let's
start
with
the
agenda,
what
do
we
have
there.
B
So
the
first
one
is
specify
how
to
uniquely
identify
a
log
record.
C
B
A
C
This
I
I
can
quickly
speak
about
it.
So
maybe
maybe
this
is
more
kind
of
a
question,
so
maybe
I
missed
something
in
respect.
So
what
I
was
looking
for
this?
This
is
I.
Try
to
give
some
details
in
the
issues,
something
that
that
I
can
use
like
a
trace,
ID
or
a
span
ID
to
to
uniquely
identify
a
lock
record.
C
Did
the
use
case.
I'm
I'm,
specifically
looking
at
right
now,
is
that
I
want
to
identify
the
same
log
line
in
in
two
different
backends
right,
so
that
I
can
say
like
just
to
to
make
an
example.
At
an
Ops
person
says
like
hey:
I
got
got
the
following
log
line
and
once
it
hand
it
over
to
a
developer,
to
to
look
at
this
and
right
now.
C
What
I
have
to
do
is
saying,
like
hey
here's,
the
point
in
time:
here's
maybe
some
meta
information
to
to
uniquely
identify
it,
and
so
I
was
wondering
like.
Is
there
anything
that
open
Telemetry
logging
is
providing
like
a
span
ID
or
a
trace
ID
that
that
allows
this
kind
of
unit
unique
identification?
There's
a
few
more
things
that
could
be
valuable
to
to
have
something
like
that.
Like
I,
don't
know
doing
some
linking
like
like
we
do
with
response
right
now,
so
yeah.
B
There
is
a
there
is
already
an
open
issue
about
that
was
open
long
ago.
Okay,
okay,.
B
Yeah
I'll
link
it
from
here
no
worries
I,
don't
think
we
have
any
I
guess
conclusion
on
that,
because
it's
still
open
or
but
I
guess.
The
last
message
I
see
there
was
from
me
saying:
let's
have
a
semantic
convention
to
record
that
that
ID
log
record
ID
and
that's
where
it
stayed
there.
So,
okay,
we're
open
to.
B
B
So
we
are
very
briefly
debated
about
adding
it
as
a
field
to
the
data
model,
and
then
we
said
we
probably
don't
need
to,
and
then
the
last
message
I
see
was
that
right
so
that
maybe
it
needs
to
be
a
semantic
convention.
I
think
that's
an
option
right.
That's
that's
still
a
not
not
a
bad
option
to
to
do
that.
Now
we
can
add
it
as
a
as
a
convention.
Lots
of
old
data
sources
are
probably
not
going
to
have
this
right,
so
the
the
ones
that
we
generate
using
open,
Telemetry
sdks.
B
We
can
guarantee
that
they
include
what
an
ID
that's
fine,
but
the
old
data
sources
that
we
we
listed
from
elsewhere
and
convert
into
the
open
Plenty
data
model.
They
probably
won't
have
a
field
like
that.
So
I
guess
that
was
also
what
maybe
influenced
the
decision
not
to
have
it
as
a
first
class
field
in
the
data
model.
B
I
think
that's
where
we
are
right,
so
probably
I
would
say
it's.
Maybe
it's
probably
also
fine
to
to
add
it
to
the
data
model,
but
depending
on
how
how
frequently
we
believe
this
is
going
to
to
be
occurring
in
the
ones
that
we
generate
versus
the
ones
that
we
need
from
elsewhere
from
third-party
logs,
it
may
or
may
not
be
I
guess
the
best
use
of
the
of
the
space
in
the
in
the
in
log
records,
I!
Guess
when,
when
let's
say
it's
typically
missing
right.
C
Okay,
no,
no,
that
makes
sense
I
mean
I
was
thinking
about
the
same
that
if
I
have
an
existing
logging
system,
it
has
no
ID,
but
but
even
if
I
can
enrich
it
in
The
Collector
right,
even
if
I
can
say,
like
hey
I,
add
an
an
processor
and
it's
like
hey
every
lock
line,
I
get
that
has
no
lock
ID
I,
give
it
one
and
then
I
can
send
it
out
to
multiple
backends
that
that
would
already
be
be
good
enough.
I
guess:
yeah
yeah,
that's!
Okay!.
C
That's
I
will
give
it
another
look
yeah.
B
B
D
Yeah
yeah
sorry,
I
I
have
a
standing
conflict
with
this
meeting,
so
I'm
not
normally
able
to
attend.
But
I
was
talking
to
the
client
realm
working
group
and
they
said
there
was
discussion
about
abandoning
having
our
own
event
API
and
just
adopting
Cloud
events
instead,
I'm
not
sure
if
that's
like
a
game
of
telephone,
but
I
wanted
to
show
up
and
advocate
for
the
idea
that
we
should
have
our
own
zero
dependency
zero
cost.
D
Api,
though
we
should
definitely
be
fully
compatible
with
Cloud
events,
both
in
terms
of
ingesting
Cloud
event,
data
through
a
log
appender
and
being
able
to
convert
to
you
know
Cloud
event,
data
in
The,
Collector.
B
Yeah
we
entertained
that
idea.
I
think
the
the
thinking
was
that
we're
not
abandoning
it
we're
just
pausing
it
a
bit
to
try
to
understand
better
by
by
looking
at
some
other
apis
and
learning
from
those
and
maybe
implementing
Bridges
from
from
some
other
existing
apis
to
open,
Telemetry
sdks
and
then
after
we
learn
from
from
some
of
those
other
apis.
We
introduce
our
own
right.
It
wasn't
about
permanently
abandoning
our
efforts
here.
Okay,.
D
B
A
B
A
B
B
I
don't
know
if
this
thinking
still
is
the
right
thing
to
do
whether
we
do
really
want
to
pause
the
events
API
or
or
continue
with
what
we
have
at
least
experimentally
right.
So
it's
now
it's
on
separate
experimental
page.
It
doesn't
block
us
from
declaring
the
the
the
raw
low
level
logging
API
s
stable,
which
we
wanted
to
do
so
now
now
they
are
separate.
So
maybe
maybe
that's
fine
as
well
right,
so
I
don't
know
if
anybody
has
any
additional
thinking
on
this.
D
Yeah
I
mean
I,
think
I
would
say
just
because
for
expediency's
sake,
the
we
want
to
kick
the
semantic
conventions
into
high
gear
and
I
would
love
to
get
a
lot
of
attention
on
the
work.
The
the
browser
rum
people
are
doing
and
like
like
the
beginning
of
next
year.
If
we
could
do
kind
of
a
concentrated
push
to
to
kind
of
focus
on
their
work
and
the
the
work
the
messaging
group
is
doing
and
get
them
kind
of
over
the
finish
line.
That
would
be
great
with
some
things.
D
I
want
to
talk
to
the
TC
about
which,
which
would
mean
paying
attention
to
Cloud
events,
but
also
it
would
be
helpful
if,
if
we
could
continue
to
experiment
with
our
own
events
API,
since
we're
probably
going
to
need
something
like
that
in
the
end.
B
E
I
I
think
Martin's
got
the
next.
One
was
around
that
exact
situation
where,
because
the
logs
event,
API
got
split,
just
looking
for
guidance
on
how
we
progress
that
further,
so.
B
So
if
we
do
that,
let's
say
we
say:
okay,
here's
the
experimental
events
API
along
with
the
domain
name
attributes
they
are
all
experimental.
You
start
experimenting
with
it
like
there's
an
implementation
of
that,
let's
say
in
JavaScript,
but
then
how
much
does
that
lock
Us
in
into
that
that
API,
when
you
start
actually
implementing
the
browser
instrumentation?
B
B
E
You're
saying
yeah,
it
will
be
experimental
in
the
JSC,
especially
now
that
we've
split
the
logging
from
the
client,
so
I
I,
guess
Martin
chime
in
if,
if
I'm
misrepresenting
you,
so
if
we
go
ahead
and
build
the
logging
API
based
on
on
stable,
we
can
then
have
the
experimental
client
event
API,
as
we've
got
it
defined.
E
B
E
B
What
if
you
implement
that
experiment
for
events
API,
all
your
own
right
without
it
being
part
of
the
spec
and
then
what
I'm
suggesting?
Is
you
take
the
responsibility
of
of
of
using
that
experimental
thing
right,
so
other
otherwise,
I
I
would
feel
really
bad
if
you
guys
start
writing
thousands
and
thousands
of
lines
of
code,
and
then
we
tell
you
months
after
that.
You
know
what
this
is
the
wrong
thing.
You
shouldn't
have
taken
a
dependency
on
that.
That's
what
I
try
to
avoid.
F
D
But
it
seems
to
me,
though,
that,
like
this
is
our
primary
use
case
for
having
an
events
API
and
we
want
to
drive
development
of
our
own
apis
based
on
our
own
real
world
use
cases.
So
I
guess
I
would
almost
push
back
and
be
like.
Why
would
we
suddenly
change
our
minds
completely
about
what
this
API
should
look
like,
based
on
something
other
than
the
work,
we're
doing
to
try
to
solve
the
use
cases
that
we
have
for
it?
D
G
Ted,
so
you
and
some
and
a
bunch
of
folks
want
to
make
progress
on
the
semantic
conventions
and
somehow
that
that
progress
is
being
gated
by
progress
on
a
very
experimental
and
still
influx
feature.
Like
events,
I
I,
don't
understand
that
there's
lots
of
semantic
inventions
that
don't
have
such
dependencies
so
yeah
those
be
the
focus
before
you
know
the
focus
on
one
that
is
so
tenuous
it.
It's
because.
D
Who've
been
working
on
solving
that
for
a
while,
and
the
only
reason
there's
a
blocker
is
that
you
just
end
up
in
a
situation
where
traces
are
too
heavyweight
to
deal
with
a
lot
of
what
you
end
up
doing
in
the
client
or
at
any
rate,
they're,
not
the
appropriate
object,
and
so
what
you
end
up
wanting
is
logs,
but
the
kind
of
logs
we're
talking
about
are
actually
events,
in
other
words,
they're
logs
that
are
specifically
designed
to
to
be
comparable
to
each
other
right
on
a
back
end.
D
G
Just
sounds
like
it's
not
the
low-hanging
fruit
in
the
in
the
semantic
inventions.
Progress
line
of
work
like
the
low-hanging
fruit
is
just
taking
the
ones
that
are
already
established
and
have
already
been
prototyped
in
a
variety
of
languages.
Taking
those
over
the
Finish
Line
like
why
Why
Try
to
progress
on
one
that
is,
is
essentially
completely
Greenfield.
D
Well,
we're
I
mean
it's
parallelization,
not
serialization,
like
I
totally
agree.
For
example,
like
looks
like
we're
getting
enough
people
who,
like
such
as
AWS
and
Lambda,
who
are
interested
in
working
out
the
the
issues
we
have
with
like
our
fast
conventions,
and
so
like
that
can
kick
off.
This
work
doesn't
block
us
from
from
working
on
other
conventions,
but
it's
like
a
totally
separate
group
of
people
and
I
would
say.
D
G
Yeah
I
know
I
know,
I
was
okay,
so
as
long
as
it's
not
as
long
as
it's
not
in
cereal,
because
the
impression
that
I
was
getting
yesterday
from
the
the
proposal
for
semantic
conventions
was
like
to
approach.
You
know
groups
of
them
in
stages.
So,
like
stage
one
tackle
deep.
Three
then
stage
two
tackle
these
three,
and
so
it
seemed
like
there
was
at
least
some
element
of
that.
That
was
cereal.
D
Well,
I
mean
there's
a
limit
to
our
our
bandwidth
and
there's
also
the
reality
of
like.
Do
we
have
the
right
people
together,
but.
D
A
B
B
Guys
I
think
it's
it's
totally
fine
right,
there's
no
need
to
serialize.
Here
you
have
the
capacity
and
passion
to
work
on
the
client-side
instrumentation.
That's
totally
fine
right!
If
that
comes
before
something
else,
yeah
that
existed
earlier.
But
that's
fine
I
see
no
problem
with
that.
The
the
thing
that
I
I'm,
not
sure
I
understand
is:
why
are
you
blocked
on
logging
Sig,
giving
a
public
or
defining
a
public
specification
for
an
events
API
to
write
your
your
implementations
of
implementation?
That's
the
part
that
I
don't
understand.
B
So
it's
part
of
the
convention,
Implement,
your
private
internal
API
in
your
instrumentation
Library,
call
that
API
internally
throughout
wherever
you
need
to
instrument
something
and
later
when
there
is
a
public
API
defined
by
whether
it's
logging,
Sig
or
someone
else,
maybe
I,
don't
know
you
can
switch
to
that
right.
So
maybe
do
that
some
sort
of
refactoring
and
and
switch
to
that,
but
I
I,
don't
want
to
be
locked
into
the
decision
because
you
are
in
a
rush
to
produce
an
instrumentation.
That's
that's!
The
problem.
I
see.
G
G
I
B
D
Of
my
friends
how
the
hell
is
that
different
from
doing
the
work
to
prototype
what
our
events
API
should
be
like.
Why
would
this
logging
group
go
off
in
another
Direction
talking
about
an
events
API
without
input
from
the
people
who
are
trying
to
actually
solve
the
problems
that
we
decided?
We
needed
events
API
for
in
the
first
place
like
it
seems
very
weird
to
take
this
working
group
and
kind
of
shove
them
to
the
sidelines
like
that,
like
shouldn't,
they
be
part
of
this
working
group
providing
input
into
that
API.
B
Absolutely
yes,
of
course,
I'm
not
suggesting
to
do
that.
I'm
saying
there
is
no
need
for
you
to
wait
for
some
sort
of
like
public
approval
from
the
logging
seek
to
do
what
you
want
to
do
right.
You
can
design
your
API
your
events
API.
The
way
that
you
believe
is
best
for
your
needs
and
and
use
it
in
your
implementations
and
and
after
using
it,
you
can
come
to
the
logging
seek
or
be
part
of
the
logging
seek
right.
B
J
Actually,
if
I
may
say
something,
so
this
is
just
a
applies,
you
know
personally,
but
what
I
have
noticed
is
compared
to
Java.
You
know
things,
you
know,
for
me
at
least
you
know
go
slower
on
the
JavaScript
side,
so
so
we
haven't
made
much
progress
in
actually
trying
out.
J
You
know
something
end
to
end,
although
you
know
the
events,
API
has
been
there
for
a
few
months
now
so
I
think
we
it's
fine
in
a
way
we
can
go
ahead
with
the
the
private
layer
on
top
of
the
log
API
I.
Think
at
this
point
the
only
little
concern
is
the
you
know,
the
you
know,
moving
away
from
the
domain
and
combining
it
with
the
you
know
with
the
name.
J
So
things
take
longer
and
for
some
reason
and
and
then,
if,
if
things
change,
then
it
will
be.
You
know
a
lot
of
change
in
the
kind
of
thinking,
yeah.
E
If
I
can
add
a
little
bit
more
to
that,
so
our
prerequisite
is
the
fact
that
we
have
that
we
need
a
logging
API.
So
we
can
create
log
events
right
now.
Javascript
doesn't
have
a
login
implementation,
so
we
need
to
build
that
logging
implementation.
So
we
can
then
build
the
client
events
on
top
of
that.
So
the
fact
that
we
had
the
logging
API
and
the
and
the
events
API
combined
previously
that
that
was
one
of
the
blockers.
A
B
B
Cool
so
I
think
we
all
feel
a
lot
more
confident
about
the
the
logging
API
part
now
and
I.
Think
it's
we're
okay
to
give
it
a
green
light
for
every
language
seek
to
go
ahead
and
implement
it.
It
may
still
be
an
experimental
implementation,
but
we
feel
more
confident
about
it
that
we're
not
going
to
change
our
mind
at
significantly
completely
rewrite
that
API
right
redesign
it
so
and
and
because
you
will
have
that
login
API.
B
B
You
were
always
here,
I
guess
interested
in
hearing
your
your
your
ex
about
your
experience
using
that
login
API
and
turning
and
generating
the
events
on
top
of
it,
I'm
guessing
that
you
are
going
to
Define
some
sort
of
a
private
API
internally
right,
so
just
so
that
you
don't
have
to
repeatedly
do
that
login
generation
at
the
call
site
whenever
you
need
to
generate
an
event,
and
that
would
actually
shape
the
API
you
can.
You
can
then
tell
the
blogging
seek.
This
is
what
we
did.
B
B
J
Actually,
there
might
be
a
little
confusion,
Ted
I
think
you
know
what
we
need
is
not
just
you
know,
focus
on
the
events.
Api
I
think
we're
good
on
that.
The
overall
I
think
there
are
a
few
other
topics.
You
know
that
are
that
need
to
be
addressed,
which
are
I.
Think
couple
of
things
you
know
one
is
that
ephemeral
resource
attributes
and
second
thing
is:
you
know
finalizing
this
event.data,
the
nested
attributes.
I
think
these
are
the
two
things
we
need
help
on.
D
Kick
this
off
with
Tegan
you
asking
whether
or
not
people
would
be
fine
with
rewriting
their
work.
If
we
chose
a
different,
API
and
I
just
want
to
emphasize
that
like
that,
that
will
have
to
happen
right
like
if
we
decide
that
we're
going
to
have
an
events.
Api
that's
different
than
what's
in
our
prototypes,
and
you
know
the
Prototype
will
either
have
to
conform
to
our
public
API
spec.
G
Yeah,
it
totally
does
I
think
one
of
one
of
the
problems
we
faced
with
this
event,
API,
is
that
we
haven't
had
we've
been
we've
been
in
abstract
space,
the
whole
time
we've
talked,
we've
been
talking
about
what
what
use
cases
might
be,
and
we
need
to
get
concrete.
We
need
to
have
prototypes,
they
need
to
actually
exercise
apis
to.
B
B
D
That
and
that's
all
I
ask
I
was
just
oh,
maybe
just
confused
by
what
was
being
proposed,
like
we
have
an
experimental
API,
we're
going
to
be
building
prototypes
that
are
going
to
try
to
use
that
and
that's
gonna
feed
back
input
if
it
doesn't
work
like
we're
going
to
come
back
and
say
like
these
are
the
problems
with
the
experimental
API
and
it
would
be
if
they're
we
have
plans
for,
like
other
places,
to
use
this
outside
of
the
browser.
B
D
E
So
I
I
guess
part
of
this
is
being
driven
by
tigrigno.
Two
triple
nine
issue
considered
the
leading
events.
Api
recommend,
Cloud
events
right
are.
B
G
No
I
I
think
I
think
that
was
a
good
issue.
Actually,
so
you
know
I
think
it
was
worth
entertaining
the
idea
of
getting
rid
of
the
event
API
altogether
and
relying
on
some
some
language
agnostic,
third
party,
that
we
could
do
for
this,
but
I
think
the
feedback
that
we're
getting
kind
of
overwhelmingly.
Is
that
folks
want
an
open,
Telemetry
branded,
simple
event:
API
yeah.
I
G
I
To
make
sure
that
this
happens
so
I
think
it's
really
good,
but
you
know
the
one
thing
also
I
just
want
to
kind
of
call
out
is
that
we
do
have
a
drive
for
the
client-side
events,
but
we
know
that
we
also
have
other
events
that
we
need
to
accommodate,
and
that
was
the
other
reason
that
the
cloud
events
came
in
is
making
sure
that
we
don't
back
ourselves
into
a
corner
and
not
be
able
to
implement
those
things.
Yeah.
D
That
definitely
one
of
the
prototypes
we
should
be
doing
you
know,
ideally
in
parallel,
is
like
yeah.
What
kind
of
data
would
be
coming
in
from
cloud
events,
and
is
it
straightforward
to
be
able
to
do
a
a
transparent
transform
right?
Can
it
easily
come
in
through
our
API
and
then
get
spat
out
and
convert
it
back
to
Cloud
events
in
The
Collector,
without
without
losing
anything
or
having
any
real
trouble.
D
B
Anyway,
I'll
I'll
change
the
the
one
about
the
cloud
events
API
to
make
it
clearer.
I,
guess
we're
all
on
the
same
page
here
that
it's
not
a
replacement
for
the
events,
API
right
to
make
sure
that's
not
the
impression
from
that.
What's
the
next
one
related
Define,
the
shape
of
the
event,
the
event
data,
okay,
so.
E
Yes,
so
that
was
I
I
paused
that
because
I
went
on
holidays
for
two
weeks
and
I'm
also
about
to
go
off
for
another
three,
so
it's
going
to
be
generated
before
I
can
pick
that
up
again,
but
in
there
I
do
have
references
to
the
cloud
event
data.
E
E
So
it's
really
a
case
of
how
far
do
we
want
to
take
that?
Do
we
just
want
to
have
the
event.data
or
do
we
want
to
say,
let's
introduce
event.data
in
the
data
schema
and
then,
from
a
an
event
perspective.
We
could
have
a
schema.
B
E
Me
try
to
read
yeah.
Thank
you
yeah!
It's
in
there.
It's
a
one
of
a
result.
Comment!
That's
because,
ideally,
we
want
to
Define
an
event.
So
an
event
can
be
passed
as
a
log
event
or
a
span
event
and
span
events
doesn't
don't
doesn't
have
volume.
A
E
So
if
we
Define
an
event,
so
if
we
say
your
browser
page
view,
event
looks
like
this,
there
is
nobody
to
put
that
in
a
span
event.
If
someone
wants
to
send
it
as
a
span
again.
G
E
That's
a
bigger
discussion.
So
if
we
can
and
correct
me
if
I'm
wrong
here,
ideally
a
span
event
will
become
a
log
event,
but
right
now,
because
we
have
expand
events
defined
the
reason
we're
using
log
events
is,
we
need
nested
attributes
span
events,
don't
support
nested
attributes.
So
if
we
say
long-term
span,
events
are
going
away,
then
no,
we
don't
need
that
mapping
and
potentially
we
could
use
body.
D
I
I
I
totally
get
the
the
question
Jack
and
there's
there's
two
ways
to
look
at
it.
One
is
like
span.
Events
is
a
bit
older
and
going
forwards.
We
now
have
a
fully
fledged
log
stream,
so
everything
could
just
go
in
that
direction.
It
would
be
simpler.
You
have
a
SIM.
The
only
reason
why
you
couldn't
go
the
other
way
is,
we
would
need
to
add
nested
attributes.
D
So
on
one
hand,
it's
it's
straightforward
to
say,
span,
events
should
be
deprecated
and
should
just
get
converted
into
logs
going
forwards
with
an
attached
span
context
the
only
like
all
span
events,
the
only
Wrinkle
in
that
is
that
some
end
users
may
want
maybe
teeing
off
their
logs
into
one
analysis,
tool
and
they're
traces
into
another
analysis
tool,
and
they
want
all
of
the
logs
and
events
that
have
a
trace
context
associated
with
them
to
also
show
up
in
their
their
Trace
tool.
D
And
if
we
have
logs
capable
of
defining
nested
attributes
that
you
can't
Define
on
the
data
model
level
for
span
events,
then
that's
that's
a
problem
whether
or
not
we
need
to
add
a
new
span
event
API
that
can
deal
with
nested
logs
is
separate,
so
maybe
the
the
short
way
of
saying
it
is
like
I
If.
We
want
these
things
that
we
may
want
to
ensure
that
our
span
events,
data
model
can
support
nested
attributes.
G
Yeah,
because,
where
I'm
coming
from
is
so,
it
seems
on
its
face
that
it
would
be
pretty
useful
to
be
able
to
put
to
use
the
the
log
body
which
supports
complex,
structured
data.
If,
if,
if
you
can
put
event
data
in
the
log
body,
do
you
still
need
complex
attributes
on
log
records?
G
G
B
I,
don't
think
so.
There
are
features
that
are
that
are
that
will
benefit
from
being
an
attribute,
but
so
it
it's
not
a
single
thing
that
you
want
to
record
and
you
put
in
a
body.
There
are
multiple
things
that
may
have
complex
nested
structure
like
source
and
destination.
Right,
for
example,
that's
a
pair.
You
want
to
record
and
each
may
contain
some
sort
of
complexity,
inner
complexity.
There
right
the
source
may
have
a
name,
an
IP
address,
whatever
right,
multiple
attributes
there
and
and
a
destination
so
having
a
single
place.
B
A
D
Yeah
but
I
would
say
the
the
span
events
thing
is
I
would
call
that
a
like
a
a
backwards
compatibility
issue
of
the
data
model
layer.
If
that
makes
sense,
I
don't
think
we
need
to
do
any
work
on
the
API
layer
or
anything
above
being
able
to
do
this
translation
in
The
Collector
or
something
like
that,
and
even
in
those
cases,
it's
a
little
questionable,
because
there's
plenty
of
tracing
backends
that
themselves
can't
handle
a
lot
of
nested
data
structures.
I'm,
pretty
sure
I
could
be
wrong
about
that.
E
D
Right
like
like
it,
it
might
be
fine
going
forwards
to
say
you
should
tee
your
logs
off
to
your
logging
back
end
and
then
send
the
the
full
logging
event
streams
to
your
tracing
back
end
and
your
tracing
back
end
should
know
how
to
deal
with
those
event.
Streams
right
might
be
another
way
it
gets
solved.
I,
don't
think
this
should
I.
Don't
think
that
issue
should
bubble
up
past
that
trying
to
resolve
getting
this
stuff
into
an
existing
tracing
back
end.
B
I,
ask
a
question:
do
you
do
you
actually
intend
to
record
this
data
as
spam
events
or
that's
just
hypothetical.
E
There
is
some
due
to
the
lack
of
logging.
There
is
a
lot
of
instrumentations
that
effectively
create
zero
length
spans
and
try
and
simulate
this.
So
at
the
moment,
it's
it's
forward
migration,
but
once
we
go
and
Define
what
the
events
are,
people
are
going
to
ask
for
that
backward
migration.
So
really
it's
a
case
of
trying
to
define
the
event
definition
so
that
we
have
a
way
to
map
A
to
B.
So.
E
E
Which
is
why
I
said
a
separate,
instrumentation
or
you
know,
effectively
have
another
version
based
on
config
about
which
way
it
does
so.
It
would
maintain
backward
compatibility
for
those
end
users
and
vendors
that
happen
to
use
the
existing
method
and
need
time
to
effectively
migrate.
Their
back
ends.
B
My
question
was
your
new
instrumentation
that
will
output
the
the
client
events
in
the
form
of
log
records,
Standalone
log
records
and
we'll
put
the
data
into
an
attribute
named
event.data.
Will
that
new
instrumentation
have
a
have
an
option
to
be
configured
by
the
end
user
to
instead
put
the
exact
same
data
inside
a
span
event?
E
The
discussion,
my
preference,
is
no,
we
would
actually
have
a
separate
instrumentation
because
otherwise,
you
end
up
with
for
extra
code
bloat
in
the
the
only
half
that's
going
to
get
used.
Okay,.
D
D
So
it's
like
a,
however,
that
that
conversion
happens
it's
more
complex
than
just
flipping
a
switch
and
saying
these
are
span.
Events
versus
log
events,
you
know,
that'll
that'll,
have
to
be,
and
probably
those
things
are
expecting
the
data
to
be
serialized
in
some
form
because
it
didn't
support
there.
J
Is
there
is
one
other
thing
we
are
considering,
though,
the
the
whole
data
will
still
be
in
an
event
whether
that
event
itself
will
be
a
standalone
event
or
a
span
event.
You
know
that
could
come
through
a
configuration
depending
on
what
the
vendors
want.
J
J
So
basically
there
will
be
two
things
for
sure:
a
span
there
will
be
a
span,
there'll
be
an
event
whether
that
event
will
be
inside
the
span
or
a
separate.
You
know
that
is
what
we
are
possibly
could
be.
A
config.
D
I
mean
you
can
solve
that.
Like
I
mean
you
can
just
record
those
as
events
with
the
spam
context
attached
and
then
Downstream
in
your
gateway
or
your
collector,
convert
those
to
span
events
rather
than
like
push
all
of
that
code
up
to
the
the
browser
that
would
be
like
another
way
to
to
keep
the
what
goes
into
the
browser
simpler.
J
Yeah,
the
the
specific
reasoning
is
like
we.
We
are
trying
to
attach
some
timing,
information
about
the
span
and
the
browser
provides
that
a
little
later
so
and
the
question
is:
do
we
do
we
wait
until
browser
provides
that
information
or
or
do
we,
you
know,
send
out
the
span
first
and
then
the
you
know
the
timing
as
timing
inference
are
additional
event
separately.
B
Let
me
ask
another
question:
so
let's
say
we
adopt
this:
this
schema
where
you
have
event.data
and
you
have
the
event
domain
and
event.
Name
are
those
three
attributes,
the
only
ones
that
you
will
record
on
a
on
a
browser
event
or
there
will
be
or
will
be
more
like?
Is
it
just
the
the
three
so.
E
To
define
the
fact
that
this
is
an
event
that
is
the
only
trade
there
will
be
some
events
where
we
may
leverage
the
existing
semantic
conventions
of
the
top
level
attributes
in
or
as
resources,
I.E,
the
fair,
more
resources
and
stuff
like
that,
but
primarily
yeah.
We
we
just
need
a
way
to
identify.
This
is
an
event,
so
the
back
ends
can
say:
okay,
this
is
an
event,
and
then
everyone
deals
with
it
the
same
and
at
the
moment
that
is
domain
name
and
data.
B
B
We
we
don't
have
a
name
field
as
a
top
level
field,
although
we
discussed
it
so
we're
going
to
have
attributes
called
event,
name
attribute,
called
event,
data
and
an
event
domain.
It
looks
as
if
we
we
didn't
design
it
properly,
you're
forced
to
kind
of
put
the
data
you
you
need
somewhere
in
the
the
attributes,
because
the
data
model
is
not
a
good
fit
I.
D
I
mean
it
also
sounds
strange
to
me
to
have
an
event
that
data
field,
except
in
the
cases
where
you're
literally
taking
some
kind
of
event,
data
that
was
generated
by
another
system
right,
like
you're,
just
pulling
this
event
out
of
the
browser,
the
browser
hands
you
this
Json
blob.
That
represents
this
timing
event,
and
you
want
to
just
put
it
somewhere
without
having
to
do
any
kind
of
like
extra
work
or
translation.
D
It
makes
sense
to
have
that.
Feel,
though
I
do
wonder
if
that
couldn't
just
be
the
reusing
the
body
field,
if
that's
structured,
yeah,.
E
I
I
guess
leveraging
from
that.
If
we
said
okay,
it's
event,
name
data
and
body
and
then
promote
backward
compatibility
perspective
in
terms
of
defining
the
event
once
we
say
okay,
if,
if
you
represent
this
as
a
span
event,
then
it's
event,
name
event,
data
and
the
body,
sorry
event,
domain
event,
name
and
the
body
becomes
event
data
as
a
inverted
Jason
Glover,
that's
one
another
possibility.
E
I
think
Santos
just
already
working
on
some
definitions
and
we
talked
about
adding
examples
there.
So
I
might
leave
Santosh.
Do
that
because
I
I
I'm
not
going
to
have
a
lot
of
bandwidth
between
now
and.
B
B
So
one
down
side
of
recording
everything
under
the
event
data
is
going
to
be
that
that
it's
it's
a
bit
harder
to
use,
for
example,
The
Collector
to
do
any
sort
of
processing.
We
have
something
called
attributes
processor
which
which
makes
it
easy
to
add
attributes,
remove
attributes
reduct
the
attributes,
but
it
only
works
with
the
attributes
which
we,
you
can't
tell
it
to
go
inside
an
attribute
and
do
those
sorts
of
operations.
So
if
everything
is
recorded
under
an
event.data,
you
can't
do
much
there.
B
You
can
just
delete
the
entire
event.data
or
add
the
entire
event
of
data,
but
supposedly
you
would
want
to
be
able
to
do
I
guess
a
bit
more
expressive
things
there
and
it's
it's
not
going
to
be
possible
today
with
the
collector
I.
Don't
know
if
the
transform
processor,
the
one
that
is
when
the
new
one
will
allow
you
to
do
that,
then,
if
it
does,
then
maybe
it's
not
big
deal,
but
what
exists?
What
I
know
exists
today?
The
attributes
processor
becomes
almost
useless
for
for
the
events
right.
You
can't
do
much
there.
G
B
Yeah
you
can
tell
it
to
to
remove
an
attribute
by
name.
You
can
tell
it
to
honor
that
add
an
attribute.
You
can
provide
a
value.
I,
don't
remember!
If
complex
values
are
possible
today,
but
and
then
you
can
tell
it
to
copy
an
attribute
from
another
attribute
right
things
like
that.
So
when
things,
when
you
have
a
flat
structure
like
the
attributes,
are
just
you're
just
data
in
attributes,
that's
probably
good
enough.
If
you
put
everything
under
event.data
and
a
processor
like
that
is
almost
useless,
you
can't
do
much
using
it.
E
Yeah
that
almost
sounds
like
an
argument
for
saying:
okay
well,
we'll
also
consume
the
cloud
events.
Data
schema
so
that
the
back
end
can
see.
Okay,
if
there
was
a
schema,
defined
and
I
know,
and
it's
a
schema
that
I
understand,
then
they
can
use
that
to
effectively
decode
the
event.data,
which
is
what
the
event
the
kind
of
data
scheme
is
for.
B
E
J
Yeah,
actually,
this
is
specific
to
the
browse
the
rum
instrumentation,
but
all
the
ram
data
will
not
go
through
collectors
because
it
comes
from
the
internet.
It
directly
goes
to
the
vendors
backends
and
there
they
can
choose
to
use
collectors
or
they
can
choose
to
not
use
collectors,
but
there
will
not
be
a
collector.
E
Would
go
up
to
the
vendor
to
have
effectively
the
global
endpoint
that
receives
all
the
yeah,
all
the
requests
from
browsers,
which
could
be
Millions,
hundreds
of
millions,
thousands
of
millions
Euro
Etc,
whether
they
happen
to
use
collector
or
not.
At.
J
Think
of
you
know
you're
accessing
from
your
browser.
Why
would
you
run
a
collector.
D
D
J
A
J
Applies
only
to
the
to
the
rum
events,
but
in
general
yeah,
that's
a
valid
concern.
B
Okay,
can
we
move
forward
guys?
We
don't
have
a
lot
of
time.
We
have
a
few
more
items
there.
Let's
continue
the
event
of
data
discussion
on
the
pr
Martin.
You
have
the
next
one.
F
Yeah,
this
is
very
much
right,
so
we've
been
already
talking
talking
about,
but
I've
been
working
on.
The
implementation
of
the
logs
events,
API
and
SDK
in
JavaScript,
and
so
the
API
has
been
you
know,
as
Santosh
mentioned
has
been
implemented,
implemented
at
emerged
since
September,
but
since
then
it
has
changed.
It's
been
split
into
the
logs
and
events,
API
two
separate
things
so
I
guess
we
would
like
to
start
working
on
the
SDK
and
the
the
Prototype.
F
B
So
what
we're
just
discussing
right,
we
I
think
we
feel
more
confident
about
the
logging.
Api
part,
yeah,
I
I
think
it's
not
a
bad
idea
to
have
an
experimental
implementation
of
that
with
the
events.
Api
I
think
it's
also
fine
to
implement
it
as
an
experimental
thing,
but
maybe
maybe
don't
expose
it
to
the
end
users
use
it
internally
to
hide
it
in
a
way
right.
You
can
shape
it
exactly
the
same
way.
B
It
is
as
it
is
defined
in
respect
today,
but
don't
let
other
people
to
build
on
top
of
it
right,
just
use
it
yourself
to
get
a
sense
of
how
well
the
the
API
works
for
for
the
for
the
client,
instrumentation
use
case
and
and
then
hopefully,
we'll
have
some
feedback,
some
learnings
from
that
and
and
we'll
apply
to
the
spec
after
that.
Maybe
then
only
start
to
expose
the
events,
API
I'm
saying
even
as
experimental,
don't
expose
it
to
end
users.
I,
don't
want
other
people
to
build
start
building
stuff.
E
F
So
so
part
of
the
reason
that
I'm
also
asking
is
because
we
already
had
external
contributors,
who
or
other
contributors
who
are
pointing
to
the
events
API
spec
and
saying
like
this
doesn't
match
like
I,
want
to
update
it.
So
yeah.
B
That's
that's
what
I'm
also
worried
about
right?
It's
not
just
us
open
Telemetry.
Some
some
other
contributors
may
want
to
start
writing
instrumentation
and
and
when
a
lot
of
people
do
that
we'll
just
we
will
be
just
locked
in
right,
we're
not
going
to
be
able
to
easily
break
and
delete
all
of
that
right
anymore.
F
D
I
I
guess
I
guess
what
I'm
saying
is
like
yeah
like
can
we
it
would
be
great
to
keep
what's
in
if
we
keep
anything
in
the
spec
to
keep
that
in
sync,
with
the
prototyping
that
we're
trying
to
do
because
I
am
concerned
about
these
things
getting
disconnected
with
each
other.
It
seems
like
what
people
are
trying
to
do
and
the
rum
said.
May
is
like
an
important
use
case,
but
it's
not
clear
How
It
lines
up
with
everything
else,
we're
trying
to
do
and
I
mean.
D
D
D
B
So
I
guess
going
back
to
Martin's
question
I
think
we
all
agree
here
that
logging
API
is
in
a
better
shape
and
it's
not
a
bad
idea
to
to
start
changing
what
you
have
the
implementation.
You
have
to
start
matching
the
spec
there
with
the
events
API.
Maybe
let's
continue
the
discussion,
but
maybe
that's
fine
as
well
right.
Maybe
you
can
go
ahead.
A
B
H
I'll
try
to
be
super
quick
here,
mostly
I'm,
just
asking
for
more
reviews
on
this
issue
for
context.
Very
briefly.
This
is
basically
just
a
clarification
to
say
that
logs
that
are
emitted
by
third-party
applications.
H
If
they
are
structured,
then
that
structured
body
or
that
structured
content
should
go
into
the
log
body,
and
this
is
just
kind
of
a
clarification
because
The
Collector
is
a
first
party
application,
but
it
often
consumes
logs
from
third-party
applications,
and
if
you
you,
one
could
interpret
the
current
wording
to
say
that
the
collector
should
always
Place
structured
content
into
attributes,
but
I
think
with
this
clarification,
it's
no
longer
confusing
at
all.
So.