►
From YouTube: 2022-10-19 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
So
While
others
Join
one.
You
know
a
side
update
for
you.
You
know
I
I,
don't
know
if
you
are
following.
What's
going
on
in
the
log,
Sig
I
think
there
is
and
attempt
to
rename
events
to
schematized,
logs
or
structured
logs
or
schema
based
logs,
which
I
am
not
in
favor
of
along
with
a
few
others.
A
It's
just
a
name
terminology,
so
it
doesn't
really
matter
as
much
but
just
wanted
to
let
you
know
in
case
it
if
it
really
comes
to.
A
Matters
because
I
was
thinking
that
all
the
existing
vendors
have
custom
apis
to
send
events,
so
your
customer
facing
documentation
and
terminology
will
have
to
change
as
well.
A
Okay
right.
So
if
this
is
not
something
that
you
know
just
a
few
of
us
decide,
this
is
something
that
should
be
taken
up
by
the
user
research
right.
There
is
a
team
called
user
research
that
is
talking
to
the
users
of
open
telemetry
right
and
John.
Watson
had
a
very
valid
point
that
if
you
say
open,
Telemetry
has
an
events.
Api
99
of
the
users
will
understand
right,
whereas
if
you
say
open,
Telemetry
is
schematized
log
API,
it's
not
clear
how
many
people
get
it.
A
B
A
We
were
talking
about
an
attempt
to
rename
events
to
something
else
in
the
lock
Sig.
A
A
That
events
and
logs
have
a
small
difference
so
so
that
difference
is
accepted.
You
know,
I
think
that
difference
is
acknowledged,
but
in
terms
of
terminology
you
know
I
think
a
few
of
them
are
suggesting
that
we
don't
call
it
events,
because
it's
overloaded,
I,
don't
exactly
understand
the
problem
statement,
but
I
think
today,
most
of
the
vendors
already
have
something
called
an
events.
Api
that
end
users
are
our
customers
and
their
customers.
I
think
they
understand
are
rather
yeah
just
customers.
A
C
C
A
C
Yeah
I
mean
I
I
liked
events,
because
specifically
because
we
have
span
offense
and
that
to
me
is
what
we're.
What
we're
doing
is
we're
we're
lifting
this
thing
out
of
like
like
it
is
supposed
to
be
equivalent
to
span
events
effectively.
If
a
trace
is
around
like
you
should
be,
you
should
be
able
to
have
a
one.
You
should
be
able
to
to
translate
span
events
into
events
and
events
into
span
events
without
without
any
trouble,
yeah.
A
A
A
Yeah
logsig
it's
at
10
o'clock.
Today,
okay,
let's
see
I'll.
A
Yeah,
the
alternative
is,
is
not
you
know
fixed,
it's
just
that.
You
know
they
wanted
something
other
than
an
event.
So.
C
Is
there
a,
is
there
a
plan?
Do
you
know
if
there's
a
plan
to
have
a
log
API,
that's
separate
from
this
event,
API.
A
We
we
did
oh
so
I,
oh
maybe
there
is
one
happened,
while
you're
you're
away.
C
A
You
did
yeah,
okay,
so
yeah.
There
was
a
lot
of
back
and
forth
on.
On
that
point.
We
we
wanted
an
events
API,
but
then
the
events
API
was
so
close
to
the
logs
SDK
that
it
was
eventually
decided
that
we'll
have
a
logs
API
as
well.
Okay,
so
there
is
a
events
and
logs
API
is
what
it's
called
today,
they're
very
structurally,
very
similar
for
events
API.
A
It's
not
supposed
to
be
used
directly,
but
instead
you
know
the
log
appenders
you
know
should
use
that
API.
So
so
end
users.
When
writing
applications.
You
know
they
should
continue
to
write
in
their
native
using
their
log,
API
I,
see
and
then
and
then
they
will.
If
they
have
Technologies
like
log
upenders
that
are
used
to
route
your
logs
to
different
destinations,
then
there
you
use
the
logs
APN
because
open
Telemetry,
you
know
they
didn't
want
to
introduce
yet
another
logs
API,
because
they're
already
several.
C
But
okay
for
I'm
wondering
was
it
brought
up
for
people
who
are
writing
shared
libraries,
like
writing
instrumentation
code,
for
example,.
B
They
did
say
that,
like
that
I
get
like
the
API
combines,
both
logs
and
API,
and
events
apis
and
there's
like
a
recommendation
that,
like
the
logs
API,
should
not
be
used
by
instrumentations
yeah,
okay.
Well,
it
should
only
be
used
for
appenders,
but,
like
nobody
stops,
you
can
stop
people
to
to
use
it.
But
it's
like.
C
Yeah
I
I,
wonder
I
mean
so
there's
like
applications
and
application,
instrumentation,
I,
I
guess
what
I
was
just
curious.
If
it's
been
brought
up
for
share
shared
code
right
like
instrument,
Library
instrumentation,
that's
gonna
get
installed
in
like
a
bunch
of
different
applications
where
you
know
installing
I.
A
Think
I
think
the
point
was
that
the
existing
logging
libraries
have
far
richer
configuration
abilities
that
we
didn't
want
to
get
into
sure
I.
B
C
C
There
is
no
like,
like
add,
adding
a
logging
library
is
like
an
additional
dependency
where
you
could
end
up
creating
dependency
conflicts
and
things
like
that,
but
anyways,
whatever
I'll
ask
in
the
I'll,
read
the
docs
and
then
ask
in
the
login.
My
guess
is
like
in
that
it's
like
okay
to
use
our
logging
API.
C
A
Okay,
so
I
guess
we
can
continue
our
discussion
from
us
today
and
and
to
summarize,
where
we
were
I
think
we
have
listed
most
of
the
events.
A
A
E
D
E
I'd
like
to
quickly
comment
to
you
know,
answer
the
questions.
Do
we
all
agree,
and
you
know
believe
that
we've
already
gone
through
all
of
the
events
and
have
them
in
a
decent
shape?
You
know
some
of
the
events.
Yes,
I
believe
we
still
have
to
go
through
and
drain
what
we
listed
out
there
yeah.
A
Yeah,
of
course,
it's
not
perfect,
yet
I
think
I
I
personally
have
questions
on
the
user.
Interaction
I
have
listed
down
questions
right
and.
A
E
A
So
that
that's
fine,
so
that
you
know
for
things
that
need
to
be,
you
know
taken
up,
you
know
we
can
work
the
work
on
them
offline,
like
especially
following
up
with
the
specs.
E
Yeah
sounds
good
yeah,
yeah,
I'm
I'm,
fine
with
that
I
just
wanted
to
make
sure
that
we
are
not
under
the
impression
that
yeah
that
work
is
done
and
we're
moving
on
with
the
next
steps.
You
know
clearly.
E
Defining
events:
okay,
cool
yeah:
now
you
were
gonna
talk,
while
I.
D
A
A
So
so
we
have
listed
on
the
left
side.
We
have
a
bunch
of
events,
I
think
the
page
load
span
and
resource
timing
are
empty
and
and
I
think
there
is
work
to
be
done
on
I,
think,
maybe
Martin
and
I.
You
know
we
could
work
offline,
the
the
performance
events,
you
know
we
wanted
to
capture
it
from
from
your
other
table.
B
A
Is
a
events,
API
I
think
the
reason
I
I
couldn't
capture
this
in
this
table?
Was
you
know
it?
It
missed
some
of
the
like
I
I,
wasn't
clear
like
the
the
First
Column
I
I
felt
like
it
didn't,
have
all
the
parameters,
let's
say
for
the
navigation
performance,
so
I'd
like
to
go
through
it
more
carefully,
maybe
with
the
help
of
someone.
So
this
is
one
page.
That's
missing.
A
And
with
respect
to
page
view
and
Page
load
span,
I
think
I
think
we
could
keep
one
event
for
now
and
when
we
get
to
the
point
where
we
decide,
you
know
that
we
are
going
to
send
both
a
span
and
an
event.
You
know
what
goes
in
what
so
I'm
thinking
of
you
know
deleting
the
page
load
span
for
now.
Would
that
be
okay
with.
B
A
Okay,
so
with
that,
then
we
so
we.
A
So
far
we
have
resource
and
the
resource
we
split
into
fixed
attributes
and
varying
attributes
and
varying
attributes
is,
is
for
for
Ted
I.
Think
this
we
are.
We
are
depending
on
some
Solution
on
the
ephemeral
attributes,
we'll
talk
about
it
in
a
minute,
but
we
do
have
like
five
to
six
different
attributes
that
we
that
fit.
You
know
this
section,
then
we
have
page
view.
You
know
the
resource,
timing,
Ajax
exception
and
user
action.
You
know
there
are
these
different
events
that
we
have
already
you
know
defined.
A
Let
me
write
down,
so
what
are
some
if
I
were
to
put
stuck
dependencies?
We
need.
A
A
I
think
nested
attributes
I
saw.
You
know
there
is
a
PR
that
is
introducing
support
for
attribute
values
being
Maps.
A
A
Even
domain
I
think
we
can
skip
because
what
what
about
event
domain
I
think
it's
is
already
there.
It's
gonna
move
from
instrumentation
scope
to
the
individual
log
record.
B
But
yeah
I'm,
just
I'm
just
trying
to
like
is
there.
Is
there
anything
in
the
spec
like
when
you're,
creating
the
the
logger
or
that
you
you
can
provide
event
domain
I
can't
remember
like
on
that.
A
No,
so
if
you
think
of
it,
this
way
right,
it's
already
part
of
the
spec
right.
So
if
there
are
any
changes,
we
will
will
accommodate
them
we'll
adapt
to
those
changes.
Oh.
D
So
I
think
to
answer
your
question:
Martin
the
simplistically
incentives.
Please
correct
me:
if
I
get
this
wrong
the
way
the
domain
is
set,
is
you
effectively
ask
the
logging
API
to
give
you
an
emitter
for
a
domain
and
then
once
you've
got
that
that
emitter,
you
just
commit
events
and
then
the
domain's
already
added
automatically
added
part
of
that.
B
A
Where
the
domain
should
go,
okay
and
and
so
some
some
text-
Will
Change
there
like
today,
it
goes
into
the
instrumentation
scope
as
an
attribute
and
but
the
changes
being
suggested
now
it
will
start
going
into
individual
log
record.
B
D
Well,
in
terms
of
dependencies-
that's
probably
it,
but
we
and
ourselves
need
to
I
think
we
have
the
discussion
of
how
the
event
data
is
sent.
Oh
yeah
yeah
there's
several
discussions,
so
I
would
like
to
see
it
all
as
event
data.
So
therefore
everything
does
not
have
a
prefix,
but
there
are
some
issues
with
doing
that.
One
of
them
being
nested
attribute
support
in
terms
of
like
mapping
it
from
a
load
event
to
a
span
event.
D
The
other
one
is,
if
you
end
up
with
a
map
of
attributes,
attributes
when
converted
to
Json
are
awful
because
it
comes
this
object.
That
has
you
know
a
name
and
a
name
attribute
and
their
name
and
the
value
key,
and
then
the
the
value
along
with
the
type
and
all
the
rest.
So
it's
not
as
efficient
as
it
could
be.
D
So
then
we
say
well
do
we
say
the
event.
Data
is
effectively
just
a
Json
encoded
string,
which
then
gets
us
around
the
nested
attribute
issue,
because,
whether
it's
in
a
span
event
or
a
log
event,
it's
just
there,
but
you
still
don't
have
the
extra
prefix
that
you
needed
or
do
we
not
go
for
event
data
at
all
and
we
prefix
everything
and
put
them
as
top
level
attributes.
So
I
think
they're.
The
three
options:
I'm
thinking
that
okay?
How
do
we
send
the
individual
things
that
we've
now
identified.
A
And
we
don't
have
any
GitHub
issue
on
this
topic
right.
We
never
talked
about
this
in
detail
in
the.
D
Past
no
yeah,
we
went
to
the
point
of
saying:
well
what
did
we
put
in
this
object?
Where
now
we
have
several
events?
We
know
what
we
want
to
put
or
what
we
want
to
represent
the
event,
and
now
it's
okay,
so
well
now
we
have
these
fields
to
represent
the
event
where
we
want
to
put
them,
which
is
really
what
this
discussions.
A
Yeah
I,
I
I
think
we
we
should
take
it
up.
One
quick
comment
I'd
like
to
make
is:
whenever
we
talked
about
this
in
the
past
it
I.
You
know,
I
I
felt
sad
that
this
is
in
a
little
odd,
because
the
whole
even
data,
you
know
we,
we
decided
to
you,
know,
reuse.
The
log
signal
log
record
signal,
but
now
we
are
ending
up
putting
all
the
event
information
in
the
attributes.
A
If
we
were
to
model
events
separately,
then
that
whole
thing
is
now
as
is
being
moved
into
attributes
in
in
the
model
that
you're
suggesting.
D
Well
in
in
one
of
the
three
that
I've
suggesting
yeah
yeah,
exactly,
which
is
why
I
think
we
need
to
have
the
discussion,
because
there
are
all
these
different
ways
so
but
yeah
the
third
one
is
the
least
profitable,
but
just
dumping
it
back
in
batteries.
Okay,.
E
While
the
next
step
is
real,
quick
on
the
main
stuff
right,
so
do
you
know,
did
we
did
we
say
we
will
rename
that
or
will
it
be
the
same?
You
know
field
name
domain,
whether
it
shows
up
in
scope
are
as
an
attribute
yeah.
A
A
Yeah
yeah
yeah,
unfortunately,
I
think
there
are
strong
opinions
on
on
what.
E
B
A
But
is
there
a
reason
to
not
go
with
the
first
one
if,
once
the
nested
attributes
support
is
available.
D
No,
so
the
only
issue
that
I
have
is
effectively
the
size
of
the
general
adjacent,
but
we've
talked
about
that
several
times
and
there
are
a
few
draw
options
we
can
use
to
get
around
that
which
include
the
compression
it
really
comes
down
to
if
we
end
up
net
with
nested
attributes
only
in
logs,
which
is
where
we
are
right
now,
when
we
map
from
a
log
event
and
say:
okay,
you
can
send
this
event
as
a
log
event
or
a
span
event.
D
Then,
as
part
of
a
span
event,
it's
going
to
have
to
be
option
two
and
then
someone's
gonna
have
to
decode
it,
but
maybe
it's
option
two
only
for
the
span
of
it.
So
in
the
log
event,
it's
still
the
nested
attributes.
A
Sorry
I'm
not
following
so
you're
talking
about
span
events
when
mapped
to
Standalone
events.
D
D
D
The
changes
come
in
then
we're
shiny,
but
it's
really
the
the
fallback
case.
So
if
if
the
net
attributes
proposal
gets
knocked
down,
okay,
which
is
what
mine
has
been
getting
to
say,
no,
it's
logs
only.
A
And
I
thought
I
thought:
I
saw
a
prayer
from
tigran
suggesting
the
necessary
support
everywhere.
D
Yeah
and
and
my
PR
originally
was
trying
to
open
the
same
door,
because
I
was
also
trying
to
address
376.,
correct
and
the
comments
that
I
got
back
on
that
were
no,
no,
no,
no!
No!
No!
No
well,
certainly
so
I'm.
Just
saying:
beware!
It
may
end
up
going
the
same
direction.
So
if
it
does,
then
the
fallback
would
be
yeah.
A
Yeah,
but
even
even
if
it's
logs,
only
the
implementations
today
don't
support
it
right,
it's
only
in
the
spec
as
of
now
so.
D
It
would
be
that
it
would
be
the
next
generation
of
sdks
that
would
have
to
implement
that
yeah
right.
C
D
One
of
the
big
people
will
be
pushing
back
on
my
PR,
even
though
I've
pretty
much
addressed
every
one
of
his
comments,
including
undo
a
big
chunk
of
376.
That
I
was
trying
to
address,
and
then
I
had
someone
else
come
in
which
I
don't
remember,
saying.
No,
no
I
should
go
back.
The
other
way,
which
was
going
back
to
what
Christian
was
saying.
I
shouldn't
be
doing
it
so,
okay,
so
yeah,
it's
it's
not
going
to
be
a
straightforward
for.
C
C
Painful,
it's
that
not
yet
the
record
trying
to
define
context
propagation
in
open
tracing
the
first
time
we
did
it.
We've
we
eventually
broke
GitHub.
We
had
so
many
comments
on
the
issue
that
GitHub
eventually
would
no
longer
load.
It
just
gave
us
a
pink
unicorn
foreign.
D
Yeah,
so
so,
ideally,
we
end
up
with
natural
treatment.
Support
I
mean
my
proposal
would
be
option
one.
Let's
say
it
does
have
a
little
bit
of
a
downside
for
the
current
Jason
encoding,
which
I
think
Martin.
You
created
a
test
or
a
tool
that
dropped
out
what
what
the
event
looked
like
today
for
a
span
event.
That
really
highlighted
that
for
me,
which
is
little
people,
because
the
way
it
actually
gets
encoded
as
Json
it's
it's
not
just
a
simple
key
value.
D
It's
it's
an
object
which
has
multiple
key
values
where
the
key
is
like
name
and
then
the
name
and
then
value
and
the
value
is
then
an
object
as
well,
which
has
the
value
and
then
the
type
so
eventually
I
I
would
like
and
I
think
we're
talking
years
down
the
track
to
say.
D
Okay,
we
have
a
V2
Json,
which
is
is
a
little
bit
more
optimal
rather
than
just
a
straight
conversion,
but
I
I,
don't
think
it's
worth
finding
that
bike
today,
we'll
see
how
the
converting
to
binary
Proto
and
then,
which
is
what
pervy
is
doing
and
then
compression
how
about
that
might
solve
it.
For
us
anyway,
but
this
long
term.
A
B
A
What
are
I
think
the
nested
attributes
and
the
event
data
attribute.
There
is
some
motion
so
we'll
see
how
we
know
where
that
goes.
The
ephemeral
resource
attributes
is
stuck,
but
there
was
a
recent
discussion
Ted
for
for
your
reference.
It
came
up
again
in
another
discussion.
There
was
a
long
back
and
forth
conversation
between
tigran
and
Josh
where
they
talked
about.
A
You
know
what
are
some
identifying
attributes
for
a
metric
so
today,
today
it's
all
from
the
resource,
but
it's
it's
not
entirely.
You
know
correct,
so
they
they
want
to
it's
only
a
subset
of
those
resource,
attributes
that
identify
the
metrics,
so
they
they
want
to
separate
out
identifying
attributes
from
the
rest
of
the
attributes
so
when,
but
that
discussion
hasn't
proceeded
further,
it's
just
you
know.
One
discussion,
I
think
I
should
I'll
find.
C
This
called
the
semantic
conventions
working
group
which
makes
every
other
Monday
after
the
maintainers
meeting
yeah.
So
that's
another
Forum
to
discuss
this
stuff.
A
So
so
we
need
some
movement
on
on
that
topic
because
I
think
so
in
our
other
document.
So
we
listed.
B
C
C
Yeah
I
I
totally
agree.
We
need
to
it's.
We
we
either
pull
create
like
a
new
top
level
section
right.
Besides
resources
that
lets
us
do
this,
we
create
a
new
top
level
section
called
like
identifying
attributes
or
we
we
just
use.
C
C
Now,
in
both
directions
for
defining
this,
which
I
think
is,
is
helpful
because
before
people
were
just
saying
you
know
no,
let's
not
change
anything.
So
now
at
least
there's
interest
from
like
both
camps
in
defining
this
better
but
I'm,
not
yeah.
I'll.
Try
to
see
if
we
can
get
that
discussion
to
move
to
move
quickly
on
the
mechanics
of
this
I.
D
Yeah
that
was
just
I'm,
pretty
sure
my
what
I
was
talking
about
earlier,
like
once,
we
Define
the
event,
because
you
know
there
are
going
to
be
people
who
want
to
pass
an
event
as
a
span
event.
So
we
need
to
have
a
way
to
the
map.
What
we're
doing
is
an
event
to
a
span
of
it
because
as
the
bit
I
caught
from
Ted
they're
equivalent
and
once
we
have
that
way,
it's
also
the
reverse.
So
yeah
you
can
go
from
a
log
event
to
a
span
event.
D
As
a
path
forward,
because
today
that's
that's,
all
I
have
I
think
we
need
to
Define
it.
Even
if
it's
not
100
mapping,
we
need
to
say
this
is
the
recommendation,
but
then
this
is
how
you
would
conceptualize.
How
was
the
back
end
if
they're
currently
receiving
and
process
processing
span
events
today?
How
would
they
do
the
same
thing
for
a
long
event,.
A
Yeah
but
I
I
got
a
feeling
that,
within
our
team
itself,
we
have
slightly
differing
opinions
on
whether
some
of
these
events
should
be
spans
or
span
events
or
log
events
right
well.
A
So
in
that
case,
if
we
were
to
you
know
one
way
you
know
one.
Obviously
the
the
first
option
is
to
you
know
we
all
agree,
discuss
more
and
agree
on
something
common
yeah,
but
the
other
option
is
that
we
built
configuration
so
that
you
know
each
of
us
can
use
different
configuration
to
to
emit
the
same
Telemetry
in
different
form.
Yeah.
D
And
I
guess
like
this,
has
been
brought
up
several
times.
I,
don't
think
we're
actually
that
far
apart,
so
conceptually
I.
Think
of
all
of
these
as
events
and
because
I
want
that
last
bullet
point
I
want
to
be
on
that
an
event
to
so
it
can
be
included
in
a
span
event
to
me,
a
span
is
just
a
grouping
mechanism
to
keep
all
this
stuff
together,
so
whether
it's
then
sent
as
a
span
event
or
as
a
log
event
which
is
linked
to
that
that
Trace
ID
conceptually
it's
still
the
same
thing.
D
So
yeah
I,
don't
think
we're
that
far
apart,
which
is
why
I
kept
saying,
let's
just
concentrate
on
the
on
the
event,
object
itself
and
then
once
we
Define
that,
then
you
know
we
could
just
say
it's
an
event
and
whether
we
include
it
as
a
log
event
or
a
suspend
event.
D
A
So
you're
saying
that
eventually
we'll
pick
only
one
of
these
two
in
in
either
cases,
it's
an
event.
The.
E
C
No
data
loss
because,
when
you're
recording
a
log
event,
you'll
still
be
recording
the
span
context
right
like
you
won't,
you
won't
lose
that
information.
I
would
suggest
that
at
that
point,
what
we
want
to
do
is
deprecate
the
span.
Events
API
once
this
stuff
is
stable,
not
remove
it.
We
can't
remove
it,
but
just
deprecate
it
and
say:
like
we
have
this
more
gen.
C
We
now
have
like
an
events
API,
so
you
you
don't
need
to
use
this
thing
anymore,
but
under
the
hood
in
our
processing
pipeline,
we're
going
to
need
processors
that
move
this
information
from
one
place
to
the
other.
Just
because
there's
often
there's
different
backends
right,
like
people
may
still
be
teeing
they're
tracing
stream
off
to
one
back
end
and
they're
they're
logging,
an
event
stream
off
to
other
back
ends,
and
they
may
want
to
be
putting
this
information
in
one
place
versus
the
other
or
in
in
both
places.
C
C
Like
like
some
like
Collective
processors
and
things,
and
people
actually
already
have
written
plugins
that
do
this
stuff
anyways
today
with
converting
logs
into
span
events
and
vice
versa,
but
yeah
yeah
but
I
I
think
the
the
bigger
point
is.
We
should
recommend
going
forwards.
People
don't
use
the
span,
events
anymore.
We
should
just
mark
it
as
like
deprecated
and
say
like
there's.
No,
there's
no
need
to
use
this
so.
A
A
You
know
there
is
some
stateful
processing.
You
know
we'll
have
to
do
on
the
back
and
it
things
get
complicated.
So
you
know
you
get
one,
the
other
one.
You
have
to
wait
for
it.
You
know
you
have
to
you
wait
for
a
window
of
time.
If
it
doesn't
come,
no,
it's.
How
do
you
handle
it?
So
I
would
in
a
stream
processing
system
where
you
want
to
wait
for
two
messages
to
arrive.
D
That
depends
how
you
store
the
event.
So
if
you
store
the
span
events
today
with
the
span,
then
yes,
you
have
that
problem.
If
you
Hive
out
the
span
events
into
their
own
records,
then
you're
already
doing
grouping
in
the
back
end,
which
most
systems
should
be
doing,
because
if,
if
you're
trying
to
map
multiple
spans
together,
then
you're
you're
doing
that
grouping
mechanism
anyway,
so
yeah
it
does
complicate
yeah.
A
Yeah
I
think
yeah
that
I
have
seen
some
processing
pipeline
the
injection
pipelines
where,
when
the
data
arrives,
you
you
do
all
the
processing
and
then
eventually
at
the
end.
You
know
it
goes
to
the
storage,
but
whereas
if
it
goes
to
the
storage
and
then
you
query
from
it,
then
then
I
agree
with
you.
It's
it's
it'll
be
easier,
but
but
then
we
can't,
we
don't
know
yeah.
B
A
E
Are
some
one
well
one
one
extra
thing
I'd
like
to
throw
out
there
for
us
to
consider
is
that
you
know
those
problems
that
Santosh
described
are
real
I,
don't
think
we
should
what's
the
right
word
I'm
going
to
use
it,
anyways
don't
get
offended,
you
know,
Fuller,
says
thinking
putting
into
span.
Events
would
solve
the
problem
100
for
us
our
use
case
at
least
I
believe
for
browsers.
There's
a
limit
and
I
would
like
to
kind
of
think
about.
E
When
the
you
know,
I
think
what
we're
thinking
is,
if
they
all
go
as
a
batch,
then
streaming
systems
can
process
them
in
one
shot.
If
it's
all
available
for
browsers
because
of
the
size
limit,
we
may
have
to
chop
the
thing.
I
don't
know
if
they're
gonna
be
a
badge
at
that
point
anymore,
they'll
anyway
be
separate
things.
They
might
even
end
up
in
two
different
actualization
instances.
If
you.
D
E
Exactly
yeah,
you
have
to
think
about
splitting
them
at
that
point,
then,
post
processing
is
your
only
way
and
the
moment
you
go
to
post
processing
the
guarantees
of
having
everything
is
gone,
so
we
should
consider
that
also
for,
for
you
know
times,
this
problem
gets.
You
know
exaggerated
quite
a
bit,
so
that's.
E
Yeah,
so
you
know
the
the
the
data
loss
is
going
to
be
there.
You
know
we
may
be
able
to.
You
know,
build
stuff
together
at
the
at
the
yeah
post.
Processing
is
probably
the
you
know,
in
my
mind
at
least
you
know
might
be
biased
because
of
some
existing
implementations
and
stuff.
That's
what
I
believe
would
work
on
most
of
the
use
cases.
Yeah.
E
C
A
C
For
logs,
frankly,
which
is
just
like-
and
this
is
the
thing
I
brought
up
with
the
logging
group
before.
C
And
if
that's
the
case,
you
probably
want
to
to
you,
you're
your
your
span,
ID
and
your
Trace
ID
or
like
primary
indexes
for
these
logs
and
events
like,
even
if
you're,
not
putting
them
into
a
tracing
system.
I
feel
like
logging
systems
or
whatever
are
going
to
to
they're
all
retrofitting
themselves
today
to
be
able
to
to
to
index
by
by
at
least
Trace
ID,
because
it's
like.
D
C
To
look
at
your
logs
without
that
index
and
people
are
realizing
that
and
so
there's
just
a
question
of
like
in
our
data
structure
like
when
we're
recording
this
information,
regardless
which
API
goes
in
like.
Are
we
grouping
them
all
under
the
span
when
we're
sending
it
or
are
we
just
recording
them
separately
in
a
a
another
stream
where
we're
repeating
the
span,
contacts
and
every
one
of
them?
C
That's
kind
of
how
the
the
logging
data
structure
has
been
designed
today
is
that
it's
it's
like
repeated
information,
I
think,
with
the
assumption
that
you
know
compression
and
stuff
like
that,
would
would
eliminate
issues
that
come
with
it,
but
but
I
think
it's
a
thing.
We
can
talk
to
that
that
group
about,
but
it
might
be
fine
to,
but
I
guess
my
point
is
I
would
prefer
it
to
to
if,
if
we
say
by
default,
all
of
these
events
go
to
the
logging
side.
C
A
Yeah
and
there's
one
more
thing
that
bothers
me
once
in
a
while
is
like
we
don't
so
we
have
so
metrics
has
a
very
different
database
requirements,
the
store
you
know
how
it's
queried,
so
metrics
clearly
is
going
to
end
up
in
a
different
data
store,
whereas
spans
and
events
are.
Are
they
going
to
be,
and
you
know,
are
they
going
to
go
into
one
database
or
two
separate
databases?
How
are
people
designing
it
that
you
know
the
open,
Telemetry
clients?
C
You
mentioned
database,
but
I
think
that
just
to
split
a
hair,
there's
there's
two
there's
like
it's
all
going
into
one
product
versus
all
going
into
multiple
products:
yeah
yeah,
if
it's
all
going
into
one
product,
yes
on
the
back
end,
is
probably
getting
shoveled
into
a
bunch
of
different
places,
but
it's
it's
still
possible
to
you
know
for
the
back
end,
to
figure
out
what
it
would
like
to
do
with
this
information,
where
the
end
user
really
will
have
to
like
put
some
configuration
into
something
like
a
collector
is
when
they're
actually
teeing
it
off
to
two
separate,
totally
separate
products.
C
A
Know,
yeah,
and,
and
that
is
the
challenge
right,
I-
think
if
the
logs
go
to,
let's
say
Splunk,
you
know
the
the
database
features
for
logs
could
be
different
from
you
know
what
you
want
on
events
totally.
C
But
also
like
some
of
these
tracing
systems
have
very
limited
or
poor
support
for
for
span
event
like
things
like
they
weren't,
expecting
you
to
put
all
your
logs
there
yeah,
so
so
I
feel
like
it's
it's
one
of
those
things
where,
where
the
end
users
going
to
have
to
configure
this
based
on
where
the
data
is
actually
going
what's
lucky
is,
if
especially,
if
you
get
nested
attributes
in
there,
it's.
C
We
should
at
least
pick
what
the
what
the
default
behavior
is
for
open,
Telemetry
and
for
me
the
least
surprising
thing
would
be
if
all
of
the
events
ended
up
in
the
event
stream,
regardless
of
which
API
was
used
to
create
them,
and
that's
just
because
we
we
have
some
logs
and
events
that
won't
have
span
contacts,
and
so
they
can't
go
in
the
the
tracing
stream,
which
is
sort
of
how
we
like
ended
up
with
this
other
stream.
So
that's
my
feeling,
but.
C
If,
in
Practical
terms,
that
turns
out
to
just
be
like
really
annoying
and
actually
the
practically
speaking
the
the
behavior
everyone
wants
is
to
make
these
things
span
events,
if
possible,
then
you
know
I,
guess
that
would
be.
It
would
be
fine,
and
then
we
just
say
you
know
if
something
shows
up
in
this
other
stream,
it's
like
just
the
stuff
that
doesn't
have
spans,
but
I,
don't
I,
don't
know
I.
It
would
be
great
to
maybe
just
get
a
get
get
wider
input
from
people
as
to
what
what
they
think
the
right.
B
C
What
I've
seen
most
send
users
wanting
honestly
is
one
they
want,
however,
they're
storing
their
logs.
They
need
that
index
right,
like
the
log.
Anyone
who's
providing
a
logging
product
like
has
to
figure
out
how
to
index
by
like
Trace
ID,
and
once
you
figure
that
out
what
most
people
want.
Is
they
want
all
of
this
information
to
go
into
that
system?
C
They
don't
necessarily
want
it
in
their
tracing
system,
because
what
they're
then
doing
is
one
way
or
the
other
they're
just
correlating
between
these
two
systems
and
if
they
have
to
do
it
by
hand,
because
it's
two
separate
products
like
what
they
do
usually
is
they
take
the
TR
they're,
seeing
some
tracing
in
their
tracing
system
and
then
they
like.
C
They
want
the
details,
so
they
like
copy
paste,
the
they
take
the
trace
ID
from
that
system
and
they
paste
it
into
their
search
in
their
logging
system
yeah,
and
if
the
situation
was
like
some
of
the
logs
and
events
were
like
in
this
system
and
some
were
in
the
other
system.
That's
actually
like
the
most
annoying
situation
for
them.
E
And
then
another
thing
in
my
mind
might
be
a
naive
comment
here.
The
sampling
would
probably
be
you
know
impacting
this
also
right,
if
they're,
if
they're
too
separate
and
then
for
logs,
it's
just
a
sampling
and
then
you'll
be
something
is
scratching
your
head,
because
I
sampled,
that
thing
it
should
be
in,
but
you
know,
because
it
stands,
are
sent
to
that.
The
log
is
missing.
You
know,
those
kind
of
things
could
be
very
annoying.
I
think.
C
B
C
I
mean
the
way
people
currently
do
it
is
they
they
heavily
sample
their
traces
because
they're
paying
through
the
nose
on
storing
every
single
log,
because
they
like
can't
get
out
of
log
storage,
because
they've
put
some
kind
of
Bean
counting
you
know
or
accreditation,
or
something
right
like
that.
That's
been
my
experience
like
talking
to
people.
Is
they
they
think
of
the
tracing
system
they
sample
heavily
and
they
don't
think
about
sampling
logs,
because
they've
never
had
a
trace
ID,
which
is
like
the
thing.
C
C
But
if
that's
the
case
like,
then
you
definitely
want
all
those
span.
Events
to
be
in
your
your
logging
stream
right,
like
you,
wouldn't
want
you
wouldn't
want
like
an
arbitrary
subset
of
your
of
your
events
to
to
be
missing.
C
Just
because
you
you
were
sampling,
your
your
tracing
system
and
that
sampling
usually
has
more
less
to
do
with,
like
the
cost
of
sending
the
data
and
more
to
do
with,
like
the
the
kind
of
an
analysis
being
done
on
those
traces
is
like
heavier
than
what
you're
doing
with
with
your
your
logs,
potentially
anyways.
My
my
vote
would
be
like,
let's
just
make
them
all
like.
C
C
To
have
to
be
processing
those
those
events,
anyways
like
right,
I,
think
rum
systems,
I
will
I
I,
guess
think
life
is
changing
for
you,
guys
for
great
problem
systems.
You're
gonna
start
caring
about
traces
coming
out
of
the
browser
where
I
think
in
the
past
rum
systems
like
didn't.
If
there
was
tracing
going
on
in
the
client
that
information
didn't
make
it
into
the
the
rum
system.
It
was
just
like
events.
B
A
Yeah,
but
no,
you
know
in
our
case
I
think
it
applies.
What
you're
saying
yeah
yeah.
B
B
A
Right
so
we
are
at
the
end
of
the
time,
so
so
yeah.
So
let's
follow
up
on
on
these
things
and
maybe
next
week
I
think
we
can
get
back
to
talk
about
this
schema.
E
A
So
these
two
are
certainly
you
know.
Currently
active
topics
on
the
ephemeral
attributes
is
I
think
maybe
Ted
you
can.