►
From YouTube: 2022-11-16 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
Okay,
let's
start
maybe
I
think
you
have
the
first
item.
E
Yeah,
no
I
think
I
generally
wanted
to
find
out
what
the
next
steps
are
on
on
this
PR
that
introduces
event.data,
I,
think
I
think
it.
It
aligns
with
Cloud
events,
and
you
know
that's
one
thing,
but
in
terms
of
implementing
it
it
needs
the
build
tools
to
allow
the
data
type
of
a
map
or
whatever
data
type
we
we
want
to
consider
for
it.
That
is
not
a
primitive
data
type.
So
how
do
we
go
about
that?
I.
B
Think
we
need
that
anyway,
because
we
say
that
the
logs
allow
it
so,
regardless
of
whether
we
decide
with
to
go
with
event.data,
we
still
I
believe
needed
for
the
logs
Maybe,
not
immediately.
Maybe
we
could
delay
that,
but
the
tool
eventually
likely
will
need
that.
But
for
the
event
of
data
to
be
honest,
I
I
personally
am
not
yet
convinced
I
I,
unfortunately,
I
didn't
have
time
to
look
into
the
cloud
events.
B
I
wanted
to
be
to
do
that
first
and
then
then
decide
for
myself
right,
but
I
don't
have
a
personal
opinion
on
this
topic
yet,
but
I'm
happy
to
to
continue
discussing
this
I
guess
if
anybody
has
any
other
thoughts.
D
Yeah
I
guess
one
thing
we
talked
about
last
week
is:
do
we
just
say
we
take
the
event.data
and
we
prefix
it
with
the
events,
I'm
quite
happy
with
that
as
a
potential
option
based
on
what
cloud
event
have
already
gone
and
defined
it's
more
than
what
we
need
for
the
rumsig,
but
I
think
it
would
serve
open,
telemetry
and
good
standing
for,
like
all
of
it,.
D
D
Yeah
yeah
yeah,
so
we're
effectively
decide
the
semantic
convention
for
using
a
cloud
event
is
yeah.
We
prefix
or
the
topic
yeah
yeah
on
that
I'm
actually
going
to
be
not
attending
the
next
two
meetings
so
I'm
out,
but
yeah
tiggered,
a
few.
You
know,
you're,
probably
one
of
the
biggest
people
to
go,
have
a
look
at
that
cloud
event.
So,
but
I'll
be
back
for
two
weeks.
So
after
two.
B
E
B
So
yeah,
with
regards
to
that
I
have
just
reopened
the
pr
which
was
about
supporting
mobs
throughout
today,
values
everywhere
it
was
a
draft.
It
got
closed
automatically.
So
I
turned
it
into
a
proper
PR.
It's
now
so
I'm
going
to
advertise
it
for
proper
review
for
by
everybody.
Let's
see
if
we
can
make
it
happen,
actually,
because
I
see
that
the
requests
are
coming
from
many
different
directions.
A
lot
of
people
want
this
need
this
for
the
for
a
variety
of
purposes.
F
From
my
understanding
tigrant,
what's
the
difference
between
this
PR
that
you
just
reopened
to
support
maps
and
heterogeneous
arrays,
and
what
what
navspr
was
that
I
think
eventually
got
closed
due
to
Stillness
that
tried
to,
but.
B
Tried
I
think
this
is.
This
is
more
far-reaching
this
one,
the
the
one
that
I
opened
Neville's,
trying
to
navigate
kind
of
within
the
limitations
that
we
had
this
this
Cuts
away,
all
those
those
limitations.
Instead,
that
does
that
they
are
universally
supported,
nested
maps,
all
sorts
of
arrays
and
all
all
kinds
of
things.
B
D
Yeah
my
first
version
tried
to
address
some
of
the
376
things
which
tigrants
PR
was
also
addressing
by
opening
the
door
rather
than
saying
it's
fully
supported
so
I'm
I'm,
all
for
saying
it's
probably
supported
so
I
have
actually
got
my
PR
reopened
again,
so
it
is
actually
sitting
there
but
I've
linked
to
tigrants.
B
Yeah,
so
this
goes
farther
than
that
right.
This
tries
to
go
all
the
way
to
where
we
want
it
to
be
in
terms
of
supporting
it
universally.
D
Yeah,
if
Tigris
gets
in
mind,
is
automatically
closed
right,
yeah
they're,
all
addressable,
although
there
may
still
be
some
clarification,
there's
probably
still
a
size
thing.
We
need
to
do,
but
that's
that'll
be
a
separation.
E
So
that's
from
me
so
for
the
ramsig
for
the
rubber
events.
We
are
looking
for
a
mechanism
to
even
Define
the
shape
of
an
event.
So
it's
just
asking
for
suggestions
any.
B
Ideas,
that's
going
to
be
some
some
form
of
semantic
conventions
right
so
essentially
you're
you're,
looking
to
expand
in
a
way
the
the
semantic
conventions
generator
to
to
give
you
more
I,
guess,
expressiveness
in
terms
of
how
you
specify
the
values.
Today,
it's
like
more
primitive.
Essentially,
the
values
are
just
numbers
strings
or
something
like
that.
But
for
the
for
the
events,
you
need
the
values
to
be
also
so
some
sort
of
more
complex
things
that
that's
that's
what
you.
E
Want
right,
no
I,
think
it's
more
than
that.
I
I
think
the
current
semantic
conventions
are
are
defined.
You
know
using
namespaces.
So,
for
example,
my
a
specific
event
can
have
attributes
from
multiple
different
name
spaces
and
different
events
could
use
the
same
attribute.
E
So
so
we
want
to
specify
that
hey
even
type
A
has
these
four
attributes
a
dot
b,
c
dot
d
or
something
and
then
even
type.
You
know
two
will
have
a
dot
b
again
and
then
some
e
dot
f
or
something.
D
It
might
be
a
better
explained.
The
events
themselves
are
completely
separate,
so
while
they
might
be
sharing,
you
know
some
of
the
common
attributes,
which
is
now
a
blocker
for
the
HTTP
semantic
conventions.
The
the
individual
events
themselves
aren't
aren't
directly
related,
so
like
you'd
have
a
PG
or
event
page
of
event.
Has
these
10
things
a
resource
timing
event
would
have
these.
You
know
12
things,
so
we
need
somewhere
to
define
those.
So
really
the
the
two
levels
that
we're
looking
at
is
the
shape
is
really
I.
D
G
This
does
seem
like
a
place
to
me
that
that
you
know
if
we
are
going
to
align
with
Cloud
events.
This
is
probably
going
to
be
important
because
they've
done
a
lot
of
this
stuff
like
they've,
got
a
an
event
schema,
so
I
think
we
want
to
at
least
be
compatible.
If
not
like
you
know,
it
seems
like
this
would
be
an
opportunity
for
us
to
kind
of
delegate
some
of
that
stuff
to
them.
D
H
H
A
B
Can
you
guys
do
this,
maybe
open
an
issue
and
show
some
examples
of
what
you
would
like
the
schema
to
Define
because
I'm
not
quite
sure?
What
is
it
that
you
want
to
do
that?
It's
not
possible
using
semantic
conventions.
It
seems
like
you're
saying
you
have
a
you:
have
a
certain
data
model
and
then
you
want
the
events
to
reference
bits
of
that
data
model.
If
I
understand
correctly
yeah.
D
D
Where
do
we
Define
that,
because
yeah,
as
Anthony
pointed
out,
it
is
the
domain
name
combination
that
each
event
will
Define
what
what
it
means,
whether
that's
using
Json
schema
or
whatever
that's
another
thing,
but
we
need
some
way
to
define
it
so
that
every
every
open,
Telemetry
user
can
use
that
same
event
and
go
and
reinvent
their
own
domain
name.
Combination.
B
Okay,
so
can
we
write
down
the
problem?
What
is
it
that
we're
trying
to
solve
in
an
issue
and
then
okay,
maybe
with
a
couple
of
examples
because
I'm
not
still
not
quite
sure?
What
is
it
that
we
want
to
achieve
and
then
I
think
yeah
if
David,
if
you're
saying
Cloud
events
do
something
like
that,
then
let's
definitely
consider.
Maybe
we
can
borrow
it
or
borrow
ideas,
maybe
or
borrow
wholesale
I,
don't
know.
G
I
may
misunderstand
too:
I'm,
certainly
not
an
expert
on
this,
but
but
I
just
want
to
make
sure
that
we
don't
create
a
definition
that
clashes
with
a
definition
that
they
have.
E
Okay,
I
I
I'll
go
through
the
cloud
events
schema
registry.
F
So
I'm
on
the
same
page,
so
the
issue
that
you
referenced
nav
was
was
that
number
two
933
or
the
pr
that
you
that
you
referenced
and.
F
The
it's
it's
by
Ramsey.
E
I
I
Is
it's
about
laying
the
foundation
for
the
following
structure?
Where
do
you
know
do
and
it
sort
of
starts
giving
you
examples
of
what
the
definition
might
look
like?
I
Ultimately,
you
want
to
you
know:
I,
guess
if
you
open
it,
there's
each
of
the
thing.
In
the
page
view,
area,
interaction
and
stuff,
we
hope
to
have
a
set
of
collection
of
attributes
that
is
defined,
probably
elsewhere.
I
It
could
be
linked
to
that
and
then
there
are
attributes
that
might
be
just
specific
to
one
of
these
event
type
stage
view,
for
example,
but
yeah.
That's
the
that's
the
idea.
F
So
if
I
understand
correctly,
then
so
you
know
these,
this
markdown
is
kind
of
expressing
in
some
form
or
another,
the
schema
that
you
expect
some
of
these
events
to
follow
yeah
but
you're
running
into
issues
representing
this
with
the
semantic
convention
yaml.
I
That
is
another
issue
too
that
we
need
to
solve
as
sort
of
an
apparel
thing
we
realize
we
need
to,
you
know,
start
with
the
yaml
and
then
the
MDS
are
generated
and
stuff,
and
this
tooling
around
it.
You
know
we
kind
of
tackle
it
like
this.
Let's
get
it
in
front
of
the
group.
Get
some
feedback
on.
Is
this
the
right
place?
To
put
it
in?
Is
this
right
way
to
organize
things,
because
we
we
realized?
I
This
is
the
first
time
that
I
attempted
to
do
some
sort
of
a
schema
for
traces
and
metrics.
The
the
thing
exists,
at
least
in
my
mind,
but
it's
not
not
very
clear
in
people's
people's
mind
about
romsky,
so
you
know
we
yeah.
So
that's
this
to
get
the
conversation
going,
but
ultimately
we
want
to
get
the
yaml
defined
in
things.
That's
a
separate
problem,
I
think
the
technical
problem,
if
it
solves
separately.
F
Okay,
gotcha,
so
how
to
organize
it
within
the
the
open,
Telemetry
specification
and
then
separately,
how
to
build
the
tooling
so
that
it's
Auto
generated
thanks.
B
Okay,
so
I
see
that
PR,
the
2933
has
some
examples.
I
don't
know
if
they're
sufficient
to
to
actually
tell
what
the
problem
is.
Maybe
out
there
in
the
pr
that's
fine,
too
or
open
an
issue
either
way
works
right,
but
I'd
like
to
understand
more
about
specifically
what
is
not
working
with
what
we
have
right,
maybe
also
or
what
are
the
limitations
in
the
generator
that
we
want
to
overcome?
If
you
have
that
already
in
the
pr
and
then
great
I'll
read
it
I
didn't
read
it
in
the
details.
B
B
So
next
attribute
limit
for
for
log
records.
C
Oh,
that's
mine
yeah,
this
PR
I
opened
a
while
back
and
I
guess
mainly
I'm,
just
asking
for
it
to
be
reopened.
If
somebody
has
that
Authority,
this
is
introducing
a
some
environment
variables
for
configuring.
The
attribute
limit,
it's
mainly
just
bringing
logs
into
parity
with
spans,
so
I'm,
hoping
that
it's
not
controversial
from
the
standpoint
of
introducing
new
environment
variables.
C
It's
had
a
few
eyes
so,
basically
just
asking
for
some
more
eyes
and
making
sure
that
folks
feel
this
is
good.
We
have
at
least
from
the
net
Sig.
We
have
had
customers
needing
this
needing
the
ability
to
configure
limits
on
attribute
size,
so
this
would
be
useful.
C
D
C
There,
and
especially
as
we
are
considering
you
know,
map
valued
attributes
for
both
spans
and
logs
I.
Think
that
there
probably
is
a
discussion
they're
related
to
attribute
limits
for
map
valued
attributes,
but
I'm,
hoping
that
that's
not
a
blocker
for
this
again.
Just
because
it's
bringing
bringing
things
into
conformance
with
the
current
spin
spec
yeah.
D
My
my
earlier
er
or
iterations
of
that
PR
were
trying
to
find
the
similar
thing
to
what
you
were
saying.
I
think
I
even
commented
on
those
about
max
depth
and
all
the
rest.
Somebody
Christian
got
me
to
pull
it
out
or
someone
else's
company,
but
yeah
they're.
C
C
If
there's
no
other
comments
or
discussion
there,
the
next
item
is
mine
is
well.
If
folks
are
ready
to
move
on.
A
C
Item
yeah.
The
next
item
is
just
comment
on
that
we
have
some
to
Do's
in
the
spec
for
the
log
record,
batching,
processor
and
I'm
putting
forth.
Maybe
the
like
the
low
hanging
fruit
kind
of
proposal
that
we
just
adopt
the
same
exact
defaults
for
the
batching
processor
configuration
options
as
we
have
for
the
span.
Patching
processor
I,
don't
know.
C
You
know
how
we,
as
a
community,
devise
those
defaults
for
spans.
I
can
imagine
you
know
there
might
be
some
questions.
Oh
that
they
may
be
should
be
different
for
log
records.
However,
if
there
is
any
feeling
about
that
I
guess
my
question
then,
would
be
what
kind
of
Investigation
would
folks
like
to
see
done
to
inform
that
decision,
or
should
we
just
adopt
the
same
defaults
just
for
consistency.
B
D
I
think
the
the
actual
transport
size
of
a
span
is
going
to
be
smaller
than
the
potential
transport
size
of
a
log.
So
I
think
we
probably
want
a
smaller
size
for
logs
a
smaller
time
for
logs,
so
that
we
flush
them
more
frequently.
B
D
Yeah
I
I,
don't
like
a
prologue
either,
but
but
for
spans
it
really
depends
like
if
you're
creating
a
few
spans.
That's
on
the
tube
cleaning,
a
lot
of
spans
Maybe
internally
I.
We
have
different
setups,
where
we
have
one
to
two
seconds
plus
time
for
our
internal
product.
Our
external
product
is
like
30
seconds,
but
we
also
have
internal
teams
that
can
figure
out
that
one
to
two
seconds
to
be.
B
B
D
F
B
Yeah
to
to
me,
I
expect
capabilities
like
live
tailing
right.
You
want
to
see
the
logs
almost
real
time.
Almost
real
time
means
that
I
guess
you
do
something
and
you
almost
immediately
see
it
on
a
human
time
scale
right!
That's
stop!
Second
to
me,
maybe
no
more
than
half
a
second
right.
It
doesn't
have
to
go
all
the
way
down
to
single
digit
or
even
double
digit
milliseconds,
but
go
above
a
few
hundred
milliseconds
and
it
no
longer
feels
like
it's
like
it's.
B
It's
a
it's,
a
life
sort
of
happening
in
life
mode
right
and
that's
a
that's
a
real
capability
that
some
products
have
live
tailing
you
want
to.
You
want
to
see
your
logs
as
they
happen
in
the
application.
D
D
B
F
There
any
prior
art
we
can
take
inspiration
from
so
the
you
know.
This.
The
spans
are
like
an
example
of
something
that
we
can
reference
I.
Think
it's
a
reasonable
thing
to
look
for
for
inspiration,
we're
saying
they're
a
bit
too
high.
Do
any
other
log
forwarding
systems
have
any
default
intervals
that
we
can
look
at.
A
C
To
say,
I
think
that
the
the
defaults
from
New
Relic
products,
I
I,
believe,
is
actually
five
seconds.
So
that
might
be
an
example
of
Prior.
But
yeah
I
hear
the
use
cases
for
needing
faster.
B
Right
right,
right,
I
I,
don't
see
a
huge
danger
of
going
too
low
here,
because
you're
not
you're,
most
likely
putting
something
like
a
collector
between
your
application
and
the
the
back
end,
which
then
can
budge
the
data
from
multiple
applications.
Typically,
that's
a
very,
very
typical
situation
right,
so
it's
unlikely
that
you're
going
to
be
causing
a
very
high
load
on
your
back
end
because
of
choosing
a
small
touching
interval
here
that.
F
That
that
has
been
the
inspiration
for
the
defaults
before
is
the
use
case
of
you
know
running
an
SDK
that
is
exporting
to
a
local
collector.
That's
why
the
gzip
is
disabled
by
default.
That's.
B
B
B
And
we're
not
consistent
here,
yeah
right,
we're
we're
setting
defaults
that
assume
this
goes
to
the
backhand
and
we
don't
want
to
overload
the
back
end
by
sending
too
many
small
requests.
But
this
is
not
consistent
with
our
messaging
earlier
that
you're
you're
absolutely
right.
We
said
the
default,
we're
making
we're
going
to
assume
that
the
default
configuration
is
to
send
to
a
local
collector.
So
this
five
second
patching
interval
is
pointless.
In
that
case,
it's
it's
harmful.
Actually,.
D
Yeah-
and
it
probably
depends
on
the
run
time,
so
maybe
we
have
recommended
defaults
like
for
a
client.
You
definitely
want
that
to
be
longer,
because
if
you've
got
browsers,
you
can
have
millions
of
browsers
going
directly
to
your
back
end.
There
won't
be
a
local
collector
running
in
the
browser.
B
We
have
that
actually
differentiation
for
some
other
environment
variables.
We
say
that
the
sigs
May
made
this
side
may
make
their
own
choices
depending
and
I
think
that
was
for
the
compression
actually,
so
we
set
the
gzip
may
be
chosen
as
a
default
by
by
JavaScript
or
something
like
that.
So
maybe
we
want
a
similar
wording
here
for
this
one.
F
Okay,
well,
let's
try
to
aggregate
some
some,
you
know
some
prior
art
like
we
can
reference
the
collector's
defaults
for
their
batch
processor.
We
can
try
to
see
what
maybe
fluent
bit
does
by
default.
The
Java
implementation
of
this
actually
uses
defaults
that
are
different
from
the
the
batchings.
The
batch
span.
Processor,
you
know,
just
as
a
historical
artifact
I'd
have
to
chase
down
what
you
know
the
git
history
to
figure
out
exactly
why,
but
my
guess
is
somebody
just
arbitrarily
chose.
F
C
C
B
Okay,
I
added
the
next
one,
it's
about
making
it
more
clear
that
we're
not
building
a
logging
API,
so
I
keep
hearing
questions
from
people
who
are
confused
by
what
we
have.
They
think
that
it
looks
like
a
logging
API
somewhat
a
bit.
It's
called
the
logger,
so
I
don't
know
what
sort
of
changes
we
need
to
do
there,
but
we
need
to
make
it
crystal
clear
that
this
is
not
the
case.
One
possible
approach
is
to
use
that
kind
of
the
more
recent
terminology
of
front-end
and
back
end.
B
I,
don't
think
it's
very
widespread,
but
some
logging
libraries
use
that
and
what
we're
building
is
really
a
back
end
right.
So
it's
so
what
is
also
sometimes
called
a
Handler
or
what
is
called
a
back
end.
So
maybe
we
use
those
words
to
make
it
clear
and
then
I
don't
know
what
else
we
can
do.
Maybe
another
alternate
would
be
to
to
rename
back
to
what
we
had
like
instead
of
logger
call
it
the
log
in
enter.
D
F
I've
included
a
link
in
the
document
that
to
our
current
phrasing
on
this
you
know
we
say
that
it
is
not
a
goal
of
open
Telemetry
to
ship
a
feature-rich
logging
Library.
So
that's,
but
you
know
it's
kind
of
buried
in
the
readme
and
if
you're
looking
at
the
log
API
document,
it's
not
it's.
B
B
Yeah
I
can
actually
take
this.
I
can
I
can
try
to
add
some
wording
there.
Let
me
assign
this
to
myself.
It's
already
assigned
to
me.
Okay,
I'll
create
a
PR.
F
I
added
this
issue:
yeah
yeah,
so
a
while
back,
we
had
a
PR
emerge
that
made
it
possible
for
log
record
processors
to
mutate
log
records,
and
you
know
this
is
essential
for
supporting
enriching
log
records
with
baggage
for
doing
things
like
redacting,
sensitive
information
from
logs
and
other
use
cases,
and
that
wasn't
possible
before
and
after
that,
PR
was
merged.
F
Bogdan
commented
on
that
PR
and
you
know,
took
issue
with
mutating
making
log
records
mutatable,
and
so
you
know,
I
I
just
want
to
put
this
issue
to
bed.
I
think
we
should
discuss
this
and
you
know
either
make
changes
or
accept
the
the
log
record
processor
as
it
is
today.
I
opened
this
issue
to
kind
of
track
that
conversation
I've
laid
out
a
couple
of
options.
They
may
not
be
the
complete
set
of
options,
but
yeah
take
a
look.
F
Let
me
know
what
you
think,
and
you
know
we
can
have
kind
of
a
record
of
this.
The
stance
on
this
on
this
topic.
B
F
Yeah
I
think
that's
super
reasonable.
It's
one
of
the
options
that
I've
laid
out
in
this
issue.
F
Yeah,
when
I,
when
I,
was
thinking
about
this
more
deeply
I
I
determined
that
you
could
actually
kind
of
you
could
have
a
lock
phrase
strategy
that
doesn't
require
upfront
Declaration
of
whether
it's
mutating,
so
the
implementation
could
track
whether
any
of
the
processors
actually
do
mutating
and
what
based
on
whether
or
not
any
mutation
has
occurred.
F
When
it
comes
time
to
for
the
batch
log
processor
to
do
the
handoff
to
log
exporter,
it
has
to
create,
like
an
immutable
copy
of
that
data,
to
hand
it
off
to
the
log
exporter,
and
you
know,
based
on
whether
any
mutations
have
occurred
or
not
you.
You
know
whether
you
need
to
take
a
lock
or
not
when
you're
transforming
that
to
an
immutable
copy.
F
B
F
B
F
No
I
guess
I'm,
just
I
I,
guess
I'm
just
enumerating
the
possibilities.
I
think
I'd
probably
be
most
in
favor
of
of
declaring
whether
they,
the
processor,
wants
to
mutate
the
data
because
of
the
Simplicity
and
implementation
that
it
provides.
But
you
know
in
the
spirit
of
just
you
know,
exploring
the
solution.
Space
I
included
another
option.
B
J
J
F
The
the
so
a
log
processor
declares
in
this
in
this
proposal.
A
log
processor
declares
whether
it
intends
to
mutate
the
data
or
not
and
based
on
whether
or
not
one
or
more
log
processors
intend
to
mutate
the
data.
The
implementation
can
change
to
either
be
a
lock
free
version
or
one
with
locks,
so
it
just
provides
like
a
hint
to
the
implementation
on
on.
Basically
the
performance
path
to
take.
B
F
Well,
so
you
could
actually
have
multiple
processors
that
do
asynchronous
operations
on
the
data.
So,
like
imagine
imagine
you
know
having
an
asynchronous
processor
at
the
head
of
your
pipeline
and
then
a
batch
processor
at
the
end
of
your
pipeline
and
this
asynchronous
processor,
you
know
cues
up
the
log
records
and
then
a
separate
thread
pulls
them
off
the
queue
and
performs
some
mutation
or
enrichment
to
them
and
then
later
down
the
the
batch
processor
is
similarly
doing
an
asynchronous
operation,
and
so
there
there's
there's
determinist
it's
it's
indeterministic.
B
Non-Deterministic,
why
are
why
are
we
allowing
that
that
doesn't
sound
like
a
good
design
to
me?
Why
is
it
not
just
a
sequential
operation
from
One
processor
to
another,
and
you
have
to
process
it
synchronously,
whether
you
you
have
a
queue
or
a
background
thread,
it
doesn't
matter
you're
blocking
your
whatever
method
is
called
when
we
hand
over
to
the
processor
and
you
return
when
it's
done
right
and
then
we
hand
it
over
to
the
next
processor.
So
the
result
was
a
single
owner
of
data.
F
You
know
it
for
performance
reasons:
they
they
batch
up
the
records
on
a
queue
and
then
they
do
as
little
work
as
possible
while
batching
them
up
and
then
a
separate
thread
later
pulls
them
off
that
cue
and
does
some
work
with
them.
So
there's.
A
B
Sure
sure,
but
I'm
saying
you
keep
the
data
ownership
and
you
you
when
so
there's
always
only
a
single
owner
of
data
right,
that's
what
we
did
in
the
collector.
The
batch
processor
works
exactly
like
that.
So
you
you
give
it
a
little
record.
It
says
yes,
I
I
took
the
ownership,
but
then
he
does
have
the
ownership
when,
when
it
needs
to
give
it
to
the
next
processor
or
to
the
to
the
exporter,
that's
what
happens
right
it.
B
It
can
return
asynchronously
right,
but
then
it
means
that
the
the
processor
now
owns
the
data
and
there's
no
need
to
lock
anything.
It
can
do
any
mutations
it
wants
and
then,
when
it
needs
to
hand
it
over
to
the
next
processor
or
to
the
exporter
it
gives
up,
gives
up
the
the
log
record
completely.
So
you
forget
the
log
record
right,
something
like
that.
F
So
so,
if
we
went
down
that
approach,
we'd
we'd
essentially
be
saying
that
you
know
log
processors
when
multiple
are
registered
are
called
synchronously
and
sequentially,
and
if
anybody
wants,
if
any
of
these
log
processors
want
to
do
anything
asynchronous
with
their
data,
it's
up
to
them
to
make
a
copy
of
that
data
so
that
they're
not
impacted
by
potential
processing
from
from
other
no.
B
That's
that's
not
what
I'm
saying?
No,
no,
that's
not
what
I'm
saying
yeah:
they
have
to
be
called
sequentially,
but
the
the
whoever
makes
the
call
doesn't
have
to
be
blocked
when
it
hands
over
the
data
until
the
processing
is
fully
finished.
It
doesn't
have
to
be
like
that
right.
We
don't
necessarily
have
to
block,
so
maybe
I
can.
So
are
you
familiar
with
how
the
collector
does
this
this
processing?
If
not,
that
I
can
maybe
show
you
where
it
happens
in
the
code,
maybe
I
can
show
you
some
sort
of
diagrams.
We
have.
B
B
J
I
just
want
to
say
I
think
you
guys
are
talking
about
the
same
thing
in
that
the
processor
is
synchronous,
if
you
do
add,
let's
say
a
log
record
into
a
batch,
and
you
want
to
then
modify
it
later
like
at
the
time
of
export,
you're
sort
of
taking
on
the
risk,
then
you're
modifying
data
that
could
impact
other
things.
So
I.
J
I
think
we
just
and
we
have
seen
customers
do
this
in.net,
for
example,
with
logs
we
have
users
that
are
running
these
regular
expression
engines
over
the
log
data
to
scrub
connection,
strings
and
credentials.
So
we
said
you
should
do
that
in
a
processor,
but
then
you're
going
to
delay
your
application
anytime,
it's
logging!
So
the
only
way
you
can
do
that
sort
of
asynchronously
is
just
use
a
batch
exporter
and
then,
as
you're
exporting
on
a
dedicated
thread,
run
that
logic
now
you're
going
to
run
in
there.
J
F
Essentially,
we
describe
the
pipeline
and
we
describe
ways
to
protect
yourself
from
non-deterministic
behavior,
and
you
know
part
of
the
that
protection
is
making
sure
that
you
know
if
you're
going
to
do
asynchronous
modification
of
this,
you
make
a
synchronous
copy
of
that
data.
First,
before
you
queue
it
up
to
process
it
asynchronously.
H
I
think
the
the
thing
that's
not
clear
to
me
here
is
whether
these
log
processors
act
as
a
pipeline,
or
are
they
a
set
of
independent
operations
on
the
same
data
like
with
with
the
spam
processors
on
the
the
trace
sdks,
they
operate
independently
on
the
same
data,
they're
called
sequentially
given
the
same
data,
but
they
don't
feed
one
into
the
other
and
they
they
receive
immutable
data.
So
they
don't
really
have
this
concern
because
they
can't
mutate
that
data,
but
is
the
expectation
that
processors
form
a
pipeline
or
do
all
processors
operate,
independent.
B
F
F
F
H
And
filter
and
redaction
processors
are
described
to
work
the
same
way,
at
least
in
in
the
trace.
Sdks,
that's
more
complicated
there,
because
you
need
to
make
a
writable
clone
of
the
read-only
data
that
you
get,
because
we
decided
that
these
these
couldn't
mutate
but
I
think
that's.
The
intent
is,
is
that
you
set
up
processor
chains
if
you
intend
for
a
set
of
processors
to
operate
on
the
same
data
sequentially
rather
than
operating
on
copies
of
the
same
data.
B
Yeah
I
I,
don't
see
how
you
do
it.
Otherwise,
if
you,
if
you
want
the
data
to
be
mutable
by
the
processor,
it
has
to
be
a
sequential
operation,
it
has
to
be
a
chain,
and
one
has
to
finish.
One
processor
has
to
finish
its
job
before
the
next
one
starts,
otherwise,
otherwise
you
end
up
with
concurrent
modification
or
you
end
up
with
copies,
which
have
different
modifications
done
to
them
and
clear.
What
do
you
do
after
that?.
F
B
B
F
Way,
you
have
to
do
it
in
traces
is
in
exporters,
so
you
have
to
create
a
series
of
exporters
that
kind
of
are
chain
and
exporters.
You
know
filter
out
data
and
call
the
next
exporter
that
they
delegate
to
at
least.
B
F
Yeah,
well
maybe
there's
a
way
to
with
this.
You
know
having
processors
required
to
specify
whether
they
mutated
data
that
there's
a
way
to
have.
You
know
you
know:
symmetry
spans
are
set
up,
but
still
allow
processors
in
the
log
pipeline
to
mutate
the
data.
So
there's
a
happy
medium
without
having
to
introduce
the
concept
of
a
processing
chain
where
processors
now
have
this
new
responsibility
to
call
the
next
one
in
the
chain.
H
B
Then
you
give
it
to
the
next
one:
that's
what
I
was
leading
to
why?
Why
do
we
even
need
this
in
the
first
place,
if
there
is
no
concurrent
modification
and
there
shouldn't
be
a
congruent?
The
reason
this
is
a
problem
in
the
collector
is
because
we
do
actually
have
pipelines
that
can
operate
in
parallel
and
the
same
data
may
be
fed
into
two
different
pipelines,
so
we
do
have
true
concurrency
there
here
in
the
SDK.
We
don't
allow
that
as
far
as
I
understand,
so
there
should
never
be
the
need
for
this.
C
H
B
In
the
exporters
we
we
say
that
it's
it's
exporters,
responsibility
to
do
the
cloning
if
they
modify,
because
most
exporters
don't
need
to
do
that,
whereas
for
the
processors
we
recognize
that
it's
very
common
to
meet
mutation,
so
it's
a
declared
capability
of
a
processor,
but
in
this
case
in
the
SDK
I,
don't
really
understand.
Why
is
it
necessary?
Like
use
the
ownership
model,
you
own,
the
data,
you
can
urate
it.
If
you
want,
you
don't
need
to
do
any
logging
or
anything
you're
done
with
mutation.
B
D
Yeah
I
agree:
I
think
we
should
Define
processing
chains
as
a
concept.
If
we
need
to
the
only
thing
I
can
potentially
think
of
that
might
be
is
if
you've
got
a
process
that
wants
to
like
book
the
request.
So
it's
like
a
t
processor,
but
then
it
would.
It
would
be
better
responsibility
to
clone
the
data
to
send
it
down
two
different
chains,
but
yeah
I
I,
definitely
like
internally.
In
all
our
products,
we
even
in
the
in
JavaScript.
F
All
the
problems
go
away.
If
you
only
have
a
single
asynchronous
processor,
so
a
single,
if
you,
if
only
one
processor,
is
queuing
up
these
records
and
then
processing
them
on
some
different
thread.
Then
you
know
and
then
that
processing
on
the
separate
thread
can
itself
be
synchronous,
and
you
don't
have
to
worry
about
that
performance
impact
of
doing
synchronous,
processing
from
the
applications
perspective.
F
That's
what
Mike
was
pointing
out
earlier,
and
so
maybe
the
batch
processor
just
needs
to
be
adjusted
to
have
a
configurable
set
of
of
like
operators
mutations
that
can
happen
after
the
after
the
entries
have
been
queued
up
to
be
processed
asynchronously
and
when
they're
being
pulled
off
that
queue
and
before
they're
sent
to
the
exporter.
H
F
So
if
the
batch
processor
is
at
the
head
of
your,
is,
let's
say
it's
the
only
processor,
you
have
it's
and
it's
at
the
head,
so
the
batch
processor
takes
log
records,
synchronously
cues
them
up,
and
let's
say
that
you
are
allowed
to
configure
a
batch
processor
with
one
or
more
additional
processors,
and
what
it's
going
to
do
is
it's
going
to
synchronously
queue
up
records
and
then,
when
it
pulls
them
off
the
QA
synchronously,
it
passes
them
to
that
queue
that
you've
you
know
configured
or
the
the
additional
processors
that
you've
configured
it
with,
and
so
those
now
can,
just
you
know,
operate
synchronously
without
having
to
worry
about
impacting
the
performance
of
the
application.
J
I
kind
of
like
that
I
have
a
need
right
now.
I
have
a
couple
customers
asking
about
filtering:
they
have
multiple
exporters
and
they
want
different
rules
for
which
exporters
send
like
high
priority
low
priority
volume
and
stuff
like
that
they're
trying
to
do
it
with
a
processor.
The
problem
is
that
processor
has
to
mutate
the
data
to
pass
it
along.
So
the
first
processor
says
I'm
going
to
filter
this
out.
Then
the
next
exporter
doesn't
have
an
opportunity
to
do
its
thing.
So.
J
B
J
B
That's
I,
don't
think,
that's
sustainable.
We
can't
replicate
the
entire
collector's
functionality
in
all
of
the
sdks.
There
is
a
reason
we
implemented
one
single
collector
right.
We
do
it
once
there's
so
many
things
that
you
can
do.
If
we
try
to
to
do
that
in
all
of
the
languages,
we
will
not
just
bloat
up
the
sdks,
but
it
will
also
be
an
enormous
amount
of
work
to
do
multiplied
by
the
by
the
number
of
languages.
Essentially,
I
think
we
should
avoid
avoid
that.
B
Yeah,
maybe
I
guess
we
we
should
have
only
maybe
it's
too
late,
I
guess
it's
too
late,
but
we
should
have
only
added
the
things
that
they
that
must
be
in
the
SDK
things
like
batching,
or
something
like
that
and
delegate
all
other
processing
functionality
to
The
Collector.
You
either
send,
as
is
directly
to
your
backend.
If
you,
if
you
don't,
want
to
use
the
collector
or
use
the
collector
and
do
the
processing
there
any
sort
of
mutation
or
filtering
or
anything
that
needs
to
be
done.
A
J
G
J
Must
provide
a
filtering
processor,
it
just
says,
like
one
of
the
use
cases
for
processors
is
like
filtering
yeah,
so
people
come
and
ask
like
okay.
How
do
I
do
that?
And
then
we
say:
okay,
if
you
want
to
filter
everything
from
your
pipeline,
you're
good,
any
extra,
more
complicated
logic,
there'd
be
dragons.
F
Well,
the
dragons
are
just
that
the
it
it
happens,
synchronously
on
the
calling
thread,
so
it
has
the
ability
potential
to
impact
the
performance
of
the
application.
J
Well,
I
mean
even
even
how
our
chain
is
set
up
right
so
like,
if
you
have
five
processors,
they're
all
going
to
get
called.
So
if
that
first
one
wants
to
filter
out
the
thing
it
doesn't
have
a
way
to
like
abort
the
chain.
All
it
can
do
is
like
set
the
recorded
flag
or
add
a
tag
like
you
have
to
sort
of
add
some
information
so
that
it
flows.
J
D
Like
an
app
inside,
we
have
affected
the
plug-in
chain
and
effectively.
It
is
the
responsibility
of
a
plug-in
to
call
the
next
plugin,
but
to
manage
that
I
also
have
a
higher.
You
know
an
overriding
processing
context
so
that
the
plugin
doesn't
actually
call
the
next
plug-in.
It
actually
calls
the
next
context
so
yeah.
So
if
a
player
wants
to
completely
drop
an
event,
it
just
stops
and
then
everything
else
stops
so
it
it
sounds
like
we.
D
We
probably
want
to
Define
that
for
the
logging
processes
and
say
you
know
either
the
batch
processor
was
at
the
head
or
we
just
say
that
you
know
this
is
how
they
should
be
implemented.
So
it
is
in
asynchronous
chain
where
processor
a
has
to
call
processor
B
rather
than
having
it
or
synchronous.
So
therefore,
process
array
could
call
processor,
B,
Secret
asynchronously,
all.
B
B
J
F
Kind
of
Best
of
Both
Worlds
situation-
you
can
do
synchronous
processing
if
you
want
to,
but
if
you
need
to
you
can
do
asynchronous
filtering
and
enrichment
as
well.
D
Would
it
be
possible
to
create
a
chain
log
processor,
and
just
so
you
have
that
as
the
head
so
effectively
you
enforcing
the
chain
without
strictly
important
chain.
You
have
a
processor
which
enforces
it
for
you.
So,
rather
than
saying
it's
embedded
in
the
battery
processor,
we
just
pull
it
out
and
say
to
Network
processing.
F
Yeah
and
that
could
be
possible
too.
F
So
we'll
see
I
think
everyone
should
chime
in
on
the
thread
with
these
different
or
on
the
issue.
With
these
different
ideas,
the
the
the
fear
in
my
head
is
like.
F
If
this
diverges
too
much
from
the
design
of
Trace
tracing,
it's
going
to
it's
going
to
be
a
big
discussion
and
there's
going
to
be
require
a
lot
of
justification
for
why
the
design
should
diverge,
because
you
know
on
the
design
diverges
it
needs
to
be
vetted
and
it's
going
to
have
impacts
on
on
ergonomics
for
for
users,
because
they're
going
to
have
to
become
acclimated
to
or
to
different
ideas
and
different
signals.
So
that's
that's,
probably
a
bigger
chunk
of
work.
F
But
we'll
see,
fortunately,
I
have
to
run
everyone.
So
I'll
talk
to
you
next
week.