►
From YouTube: 2023-01-26 meeting
Description
Instrumentation: Messaging
B
A
B
So
I
saw
johannes's
comment
on
the
slack
message:
the
slack
Channel
and
do
you
do
you
have
the
same
opinion
as
him
like
you,
don't
like
the
idea
of
having
a
configuration
to
change
the
the
parent
child
situation.
A
A
A
We
make
it
hard
an
inconsistent,
but
also
we
remove
some
certainty
from
backends.
A
So
like,
if,
if
it's
okay,
then
yeah
but
in
general,
I
would
try
to
avoid
it
with
that
I'm,
not
against
it.
For
sure.
B
Okay,
so
I
guess.
Let
me
just
reiterate
a
little
bit
of
my
motivation
for
trying
to
to
do.
This
I
feel
like
there
are
cases
where
links
actually
could
I
I
need
to
go
to
the
door
for
just
a
second
I'll,
be
right
back
of.
A
B
Sorry
about
that
joys
of
working
from
home
anyway
kind
of
the
the
motivation
I
have
for
wanting
to
have
that
to
be
configurable
is
because
I
I
totally
understand
in
in
a
lot
of
cases.
Having
a
link
is
probably
preferable,
especially
like
for
a
batch
situation,
but
I
do
think
that
there
are
cases
where
having
the
Affinity
to
the
original
to
the
remote
span.
B
A
It's
even
worse
than
that,
so
I
was
the
one
who
brought
the
need
to
have
parent-child
relationships
because
well
in
Azure,
monitor
it
supports
links
well,
the
visualization
is
reasonably
good,
but
what
customers
complain
about?
They
cannot
queries
right
and
it's
also
confusing
for
them,
because,
okay,
there
are
now
three
different
Trace
ideas
and
those
things
why
right
so
yeah
I
totally
get
why
Church
relationships
are
better
and
I
really
want
them
to
be.
There.
B
A
What
about
embed
context?
What
if
you
have
mdn
context
in
place,
it's
unlikely,
but.
B
So
like,
for
example,
with
a
batch
right,
so
that
scenario
could
work
just
fine
for
a
batch
as
well.
You
have
the
the
parent
child
go
to
the
remote
spam,
and
then
you
use
the
span
link
to
kind
of
group
all
of
the
related
spans
within
a
batch.
A
A
So,
for
example,
I
received
five
messages
from
Kafka
uh-huh,
not
that
not
received
I.
It's
the
push
mechanism
and
Kafka
does
not
support
it,
but
anyway,
so
my
library
that
I
instrument
is
going
to.
A
Like
so,
we
have
two
different
mechanism
and
the
stuff
one
is
pull
right.
Another
one
is
push,
so
one
user
goes
ahead
and
pulls
messages
from
oh
okay.
It
doesn't
matter
in
this
case
anyway.
So
let's
say
user
goes
and
pulls
five
messages
from
the
broker.
A
So
when
they
get
this
messages
back,
we
want
to
create
the
receive
span.
If
this
messages
are
pushed
to
the
user
application,
we
create
delivery
spend.
But
the
result
is
the
same
thing
right
to
differ.
There
is
a
span
created
which
represents
a
receive
or
delivery
of
five
messages.
Right
then,
an
instrumentation
Library
level.
Well,
it's
a
batch.
You
don't
know
there
is
no
parent.
There
are
equally
the
things,
but.
B
So
maybe
I
I
should
clarify
a
little
bit
here.
The
the
point
at
which
I
feel
like
this.
What
I'm
proposing
is
most
important
is
when
you
have
specific
handling
for
a
given
message.
So
like
a
message
Handler,
where
you
are
doing
the
processing
for
that
message,.
B
This
weekend,
so
you
can
have
a
batch
so
like,
for
example,
with
Kafka
the
the
common
way
to
do.
Kafka
is
you
have
a
a
consumer
that
gets
a
batch
of
messages
and
and
then
it
iterates
through
each
of
those
messages
and
calls
a
Handler
on
them
and
it
then
it
goes
on
and
gets
the
next
batch
right.
So
it
does
this
in
a
loop
yeah,
but
like
this
is
how
the
underlying
framework
kind
of
behaves
right,
yeah.
A
Yeah
so
like
for
the
case
when
you
like
the
the
receiver
delivery
will
be
backed
case,
but
then
we're
talking
about
in
gbgo
message,
processing
right
where,
yes,
we
can
do
parent
child,
but
what
they
need
is
for
the
case
where
we
have
we're
dealing
with
batching.
A
B
Okay,
so
so
then
we
are
in
agreement,
then,
that
for
process
the
the
the
parent
of
the
process
span
should
be
the
remote
span
and
not
the
ambient
span.
A
So
for
practice,
then
this
is
interesting
because
in
I
think
majority
of
cases
we
expect
the
user
to
create
it.
B
I,
don't
think
that
that
is
something
that
I
mean.
There's
a
lot
of
Frameworks
that
give
you
the
ability
to
that
Define,
the
the
Handler
as
part
of
the
framework
so
like,
for
example,
in
in
Java
there
is
the
JMS
spec
and
in
the
spec
there
is
a
message
listener
defined
as
part
of
the
interface.
A
Yeah,
so
a
H,
but
like
the
way
of
thinking
there
was
that
we
cannot
guarantee
like
instrumentation,
does
not
guarantee
and
Jim.
We
can
use
JMS
in
different
ways
right.
You
can
receive
messages
and
then
protest
them
in
the
loop
and
user
code
right
yeah.
B
A
You
can
use
Kafka
integrate.
Oh
sorry,
you
can
use
spring
integration
that
would
to
push
them
to
you.
So
basically,
yes,
practice
plan
will
be
there,
sometimes,
but
probably
not
all
the
times.
So
we
didn't
expect
it
out,
but.
B
We
can
we
have
more
specification
around
that
processing
span
such
that,
if
it's
a,
if,
if
the
instrumentation
is
available,
is
able
to
Define
it
that
the
relationship
should
be
parent
child
to
the
remote
spin.
A
Can
be
a
processing
spend
you
can
have
I,
don't
know
aggregation,
you
can
aggregate
100
messages,
I,
don't
know
temperature
measurements
into
one
right.
So,
yes,
processing.
There
are
also
cases
like,
for
example,
people
do
this
optimization
on
Azure
functions
you
pay
for
invocations
and
if
you
receive
a
badge
and
then
invoke
per
message,
then
you
pay
more
than
if
you
invoke
a
batch
right
and
then.
A
Yeah
so
like
on
the
Lambda
site
or
function
site.
Well,
the
best
we
can
do
is
create
the
batch
processing
span
right.
B
Right
so
I
I
agree
in
those
Frameworks
like
Azure
and
Lambda,
the
the
Frameworks
that
the
cloud
providers
give
don't
really
have
good
affordance
for
this
processing
span
like
what
I'm
suggesting,
but
that
doesn't
mean
that
I
think
that
we
shouldn't
spec
it
out
so
like
when
it's
possible.
This
is
how
you
should
do
it
yeah
so
like,
for
example,
with
with
processing
like
what
you
just
said
with
Azure
and
the
the
functions
when
it's
processing
a
batch
in
theory.
You
know
somebody
writing.
B
It
just
would
likely
have
to
be
more
of
a
custom
style
instrumentation,
rather
than
something
that
can
be
generically
defined.
A
Great
yeah
I
I,
actually
like
your
idea
about
speaking
out
purchasing
span
because
I
have
this
situation.
In
my
SD
case,
where
we
have
ability
to,
we
have
an
API
that
allows
users
to
practice
individual
messages
and
with
what
I'm
creating
now
is
some
somewhat
custom.
So
yeah
I
support
this
idea.
Yeah.
B
And,
and
so
like
going
back
to,
for
example,
the
the
Kafka
example
the
way
that
I
handled
this
at
datadog
instrumentation
when
I
wrote,
that
is
so
the
Kafka
instrument,
the
Kafka
Java
framework,
has
a
similar
problem.
It
gives
you
back
a
list,
and
so
what
I
actually
did
there
is,
rather
than
instrumenting
a
particular
framework.
B
Sorry,
an
interface
I
instrumented,
the
the
list
that
gets
returned,
such
that,
if
you
use
an
iterator
on
that
list,
each
time
that
it's
iterating
through
an
individual
element,
it's
treating
that,
like
it's
doing
a
processing
span
and
so
for
the
the
most
common
case
of
somebody
just
iterating
through
the
list
of
messages,
that's
returned
by
Kafka.
Each
of
those
messages
is
then
treated
like
a
processing
of
that
individual
message.
A
A
Tried
to
do
it
myself
for
functions,
but
the
problems
I
am
just
curious,
how
you
solve
them.
A
B
So
the
way
that
I
did
that
with
the
iterator
and
I
can
show
you
the
code
is
once
it
starts
iterating
that
list
it's
going
to
have
that
Span
in
scope
until
the
next
time
that
it
calls
the
iterator
to
get
the
next
element.
B
B
So
it
always
checks
to
see
if
it
has
a
next
and
then,
if
it
does,
then
it
calls
to
get
the
next
one.
A
B
Should
totally,
but
all
I'm
asking
is
that
the
specification
allows
for
this
kind
of
thing,
not
that
it
requires
it,
but
that
it
allows
for
it.
B
So
and
I
guess
the
the
the
best
way
to
do
that
is
through
the
the
processing
spam.
B
A
Yeah
when
we
get
there
so
I
kind
of
assume
that
yes,
I
I
like
the
idea
and
then
I
run
further
and
start
talking
about
batching,
so
then
for
processing
span.
I
just
want
to
be
specific,
you're
saying
that,
okay,
if
it's
possible
to
have
a
processing
span,
it
can
be
badged,
it
can
be
individual,
but
then,
if
it's
badged
it
should
be
linked,
because
there
is
no
other
way
so.
A
A
B
A
B
I
was
saying
with
Kafka:
you
have
to
instrument
the
list
or
with,
for
example,
with
Lambda
functions
or
Azure
functions
in
theory,
you're
going
to
have
to
iterate
through
that
list,
somehow
you're
not
going
to
just
arbitrarily
pick
okay
I'm
going
to
only
process.
This.
A
But
like
in
case
of
azure
functions,
this
hap
the
thing
that
processes
this
iterations
happen
in
a
different
process
and
this
list
is
sent
over
grpc
to
this
worker.
So
what
I'm
saying
then?
No!
You
cannot
reliably
instrument
individual
messages
for
batch
processing
and
we
cannot
require
this.
B
So
then,
in
that
case,
I
would
suggest
that
you
have
two
different
types
of
spans.
You
have
a
a
batch
span
and
a
processing
span.
A
But
what
for,
for
example,
I,
have
a
streaming
application
where
I
receive
a
batch
of
messages,
I
still
realized
them
and
upload
to
Cold
Storage.
There
is
no
individual
processing
coming
from
the
user
standpoint.
It's
batch
all
way
through
right.
B
A
A
A
The
list,
otherwise,
how
would
you
do
this
in
any
case
we're
talking
about
just
messaging
here
and
from
instrumentation
from
sdks
and
from
instrumentation
libraries
standpoint?
There's
your
control
and
when
you
you
see
that
this
list
of
messages
is
the
is,
is
passed
to
user
application
right.
You
cannot
know
what
happens
further
than
that,
and
you
cannot
require
individual
processing
spans
for
instrumentation
for
for
messaging
instrumentation.
B
Okay,
so
maybe
the
what
we
need
to
say
here
is
that
we
can't
so
the
what
we
Define
here
isn't
going
to
cover
a
hundred
percent
of
cases
right,
so
they're
always
going
to
be
edge
cases
and
honestly,
that
is
true
with
most
of
open
telemetries
specifications,
but
I
think
that
we
should
still
try
to
provide
the
best
experience
for
the
90
case.
A
Yeah
and
I
think
the
statement
like
the
following
would
would
be
good
enough.
So
if
instrumented
Library
as
an
API
that
practices
messages
right,
it
knows
when
the
processing
starts
and
ends.
Forget
the
list.
Instrumentation
we're
talking
about
the
SDK
API
right
sure.
C
A
If
SDK
API
has
something
like
this,
or
maybe
it's
a
spring
framework,
but
then
it's
true
instrumentation
for
a
spring
integration.
Basically,
if
on
the
API
level,
this
SDK
supports
processing,
but
it
has
some
API
that
processes.
Then
we
recommend
the
instrumentation
Library
should
instrument
process
yeah.
That's
it.
B
And
that
process
span
should
have
a
link
to
the
ambience
band,
with
the
parent
being
the
remote
span.
A
So
wait:
let's
stop
here
for
a
second
all
right,
so
yeah
there
is
a
processing
span.
We
can
also
say
that
users
are
encouraged
to
create
processing
expense
for
individual
messages
if
necessary
or
when
there
is
no
API
like
that
or
if
they
don't
use
it
if
they
use
some
other
API
okay,
so
we
have
a
private
spend.
So,
let's
talk
about
participant
I
continue
to
try
to
remove
batching
from
our
table
and
say
for
batching
links
or
remote
messages,
because
there
are
plenty
of
them
and
there's
just
one
ambient
context.
B
I
would
suggest
that
there
are
two
different
types
of
spans
right,
so
one
is
a
batch
and
then
the
other
is
a
processing
span,
so
with
a
processing
span.
That
is
only
used
when
you
are
dealing
with
an
individual
message
and.
A
A
A
Yes,
so
basically,
if
you
can
instrument
individual
messages,
do
it?
If
you
can
instrument
batch
processing,
do
it,
and
if
something
is
a
list,
instrumentation
is
just
not
covered
by
the
messaging
specification
right.
We
cannot
assume
that
it's
possible.
B
A
B
Yeah
so
since
Johannes
wants
to
have
no
configuration,
then
I
think
that
the
the
way
it
should
be
defined
in
the
specification
is
the
for
a
processing
spam.
The
the
ambient
context
is
always
set
as
the
link
as
a
span
link
and
the
parent
child
should
always
be
set
as
the
remote
span.
B
A
In
processing
scenarios
well,
the
situation
I
can
assume
http
push
scenario
right
broker
pushes
a
message
to
me
over
http,
so
I
have
a
parent,
which
is
the
HTTP
request
from
Brokers,
which
can
be
totally
unrelated
from
anything
that
I'm
processing
right
and
then,
if
I
process,
a
message
it
deliver
it
to
me
is
to
http
and
it
has
messaging
semantics.
Then.
Yes,
accidentally
instead
of
my
good
and
nice
remote
context,
I
get
this
unrelated
broker
initiated
call
as
a
parent,
so
I
agree.
A
It's
less
convenient
I
think
he
I'm,
probably
not
the
right
person
to
talk
about
it,
because
I
would
also
prefer
Your
solution,
but
they
tried
to
push
for
it
in
the
past
and
I
think
the
consistency
won.
So
maybe
we
can
bring
it
back
and
say:
okay,
they're,
not
two
of
us
and
show.
Is
the
community
yeah?
What
do
you
think
how
we
should
proceed
here.
C
Yeah,
it's
really
tricky
and
especially
without
something
to
visualize.
It's
really
hard
to
follow,
but
yeah
I'm
also
also
thinking,
for
example,
that
we
keep
mixing
the
two
cases.
The
batch
in
the
other
and
I
I
feel
that
we
don't
get
any
progress.
I
think
I
have
said
in
the
other
meeting
the
other
day,
yeah
I
think
we
should
just
focus
on
one
like
just
single
message
and
get
the
separate
through
and
and
find
the
problems
and
solve
them.
B
So
I
I
guess
there
is
a
special
case.
Where
you
have
a
single
message
batch
then
you
could
inherently
default
to
having
a
a
processing
span,
but
I
think
that
that
could
be
dangerous
because
it
might
be
inconsistent.
C
Yeah
and
we
discussed
the
taking
the
very
very
early
beginning
that
in
some
languages
it's
not
even
possible
to
do
the
processing
because,
depending
on
on
which
is,
if
it's
a
pull
or
push
based,
then
maybe
the
instrumentation
doesn't
have
access
to
the
processing
code.
B
Okay,
so
the
other
special
case
that
I
think
might
be
worth
discussing
is
in
the
scenario
where
you
have
a
a
processing
span,
but
they're
the
remote
context
does
not
have
a
valid
span,
and
in
that
case
you
could
certainly
argue
that
maybe
it
does
make
sense
to
have
the
the
local
the
the
ambient
span
be
the
parent.
C
A
I
the
problem
with
it
that
it's
it
becomes
difficult.
It
becomes
inconsistent
right,
so
users
don't
know
they.
At
the
same
in
the
same
SDK
and
the
same
instrumentation
library
was
the
same.
Like
their
code
doesn't
change,
they
can
get
different
experience
so
for
a
single
message.
A
If,
if
you
accidentally
receive
one
message,
then
it's
apparent:
if
you
receive
more
than
one,
then
it's
on
the
link
and
if
you
receive
none,
then,
instead
of
ambient
context
being
on
the
link,
it's
apparent
I
assume
that
it's
also
a
problem
for
backends,
because
they
would
like
to
understand
at
least
something
about
it.
Beyond.
C
Visualization,
but
is
it
the
case
that
I
mean
I,
don't
know
what
all
the
apis
look
like,
but
like
if
I,
if
I'm
using
a
system
then
and
I
an
API
I
think
you
mentioned
that
maybe
the
Azure
API
is
sdks,
there's
an
API
for
sending
a
single
message
or
or
multiple
in
the
same
SDK.
C
But
if
I'm,
if
I'm,
using
the
the
API
to
send
multiple
messages,
even
though
it's
just
one
I
would
think,
maybe
that
in
that
way
it
would
always
be
a
link.
But
this
is
like
really
just
a
single
message,
not
a
bet
that
contains
one.
Then
I
think
the
experience
would
not
be
that
much
mix,
because
I
imagine
that
people
that
are
using
messaging
system
in
their
in
their
apps
and
and
it's
just
they
always
operate
with
a
single
method.
C
B
Don't
think
that's
true,
because
you
have
some
some
cases
so
like,
for
example,
AWS
sqs,
Lambda
handlers,
the
the
API
by
default
is
a
list
and
the
batching
size.
The
batching
scenario
is
defined
in
configuration
so
whether
it's
always
one
or
if
you
do
have
batching
it's
a
it's
the
configuration
it's.
B
B
So
if
it's
def
I
mean
if
the
interface
of
the
ins
of
the
framework
is
defined
as
a
single
message,
then
yes,
you
can.
You
can
make
that
assumption.
C
Yeah
I
know
that
I
think
that
will
be
bad.
Yes,
if
it's
just
one,
but
if
you
know
that
the
API
is
is
a
list,
then
I
will
tweet
it
always
as
a
batch
and
always
use
links.
But
if
it's
just
a
single
pass,
not
not
an
array,
then
it
would
use
the
parent,
parent
and
child.
A
A
I'm
fine
with
the
dominant
problem,
I
I
have
with
it
that
one
of
our
sdks,
which
is
a
Kafka.
It
supports
two
apis
to
process
messages.
One
single
message,
one
badge,
and
it
might
mean
a
bit
more
work
for
me
to
instrument
them
differently
because
internally
they
are
mostly
the
same,
but
I
I
can
live
with
it.
It's
not
a
big
deal,
especially
if
it
improves
user
experience.
C
A
B
I
I
also
agree:
I
I,
don't
think
that
we
should
be
treating
them
specifically
differently
if
they
have
one
or
multiple,
but
I
think
the
main
thing
that
I
want
I
I,
don't
have
a
super
strong
opinion
on
that.
To
be
honest,
like
that's
just
my
my
gut
feeling,
the
thing
I
do
have
a
strong
opinion
on.
Is
the
the
processing
span
and
being
able
to
have
a
better
experience
with
more
linking
of
of
a
whole
Trace
together
by
using
the
parent
child.
B
B
I
think
that
it
creates
a
bad
experience
if
you
have
all
of
those
systems
linked
together,
the
processing
of
that
message
chain
via
links,
because
it's
broken
up
and
there's
sampling
inconsistencies.
Whereas
if
you
have
the
parent-child
relationship,
you
can
display
it
all
in
a
single
trace.
A
I
agree
with
you
totally,
but
I
don't
think
there
is
just
one
way
to
achieve
it.
So.
B
If
we,
if
we
push
this
processing
span
and
having
that
be
a
little
bit
more
formalized
and
available,
then
I
think
it's
possible.
A
Yeah
yeah,
what
I
mean
is
that
the
ways
to
achieve
it
and
I
don't
think
this?
Isn't
this
necessarily
has
to
be
substitution,
links
and
parent?
What
they
tried
to
explain
in
on
the
slack
gives
you
the
same.
A
B
Don't
I
don't
care
so
much
about
that
either
way.
The
main
thing
I'm
suggesting
is
that
for
processing
spans,
the
parent
should
always
be
the
remote
spam,
with
the
exception
of
potentially
and
I.
Don't
care
so
much
about
this
either
way.
If
there
is
no
pair,
if
there
is
no
remote
span
context,
then
it
could
be
the
ambient
span,
but.
A
There
isn't
inconsistency
there,
okay,
so
we
are
dealing
with
one
message,
but
as
a
user
depending
on
whether
there
was
a
con,
but
there
there
was
a
remote
context
and
whether
there
was
an
ambient
context.
I
can
end
up
with
not
understanding
who
is
my
parent.
Sometimes
it's
remote.
Sometimes
it's
ambient,
probably
a
random
thing
that
they
didn't
intended
to
be.
C
Yeah,
maybe
maybe
the
case
we
can
indicate
with
some
like
written
event,
for
example
in
the
process
in
Spain
that
the
the
remote
remote
span
is
not
available,
and
that's
that
you
might
like
yeah
at
least
give
some
idea
what.
Why
is
that
the
case?
And
then,
if
there
is
no?
If
there
is
the
remote
context,
then
we
just
use
it
in
no
event.
But
if
you
fall
back
into
this
like
ambient,
then
you
add
an
event
and
at
least
there's
some
indication.
What's
going
on,
I
think.
C
B
A
Yeah,
so
what
I'm
saying
that,
having
both
link
and
parent
makes
it
non-ambiguous
right
if
I
have
a
link,
I
had
a
remote
parent,
but
I
also
can
have
a
another
parent,
which
means
that
there
was
an
ambient
context,
which
is
probably
a
mistake
and
well
maybe
this.
This
should
be
configurable,
maybe
but
I'm.
Sorry,
if
I
have
a
remote
parent.
A
Sorry,
if
I
had
a
link,
if
I
have
a
link,
I
had
the
remote
con
remote
message
right.
The
remote
message
had
a
context,
then
in
most
cases
it
should
also
be
a
parent
and
then
it's
clear
there
is
one
trace
for
everything
and
also
link
which
says
where
it
came
from.
A
A
C
C
C
I
mean
did
we
discuss
also
in
in
that
it,
for
example,
in
this,
is
it
pool
base
I,
always
confused
them,
that
you
will
have
a
a
a
an
ambient
context
and
that
might
be
valuable
to
have
as
a
as
the
like
initiated
of
the.
C
So
like,
for
example,
the
the
the
the
app
says
give
me
the
messages
and
then
that
will
trigger
the
SDK
to
pull
the
message
and
that
will
create
a
context.
They
will
create
a
span
and
then
it
would
deliver
to
the
to
the
Handler
of
the
the
method
or
something.
And
then
at
that
point
you
might
have
already.
The
the
NBN
context
is
the
poor
of
the
messaging
SDK
or
something.
A
Yeah
and
I
think
we
can.
We
can
try
to
do
it
in
the
following
way.
So
we
will
say:
okay
if
we
are
SDK,
you
know
how
that
that
you
wanted
to
be
a
parent
right.
That
he'd
know
that
I,
don't
know
users
subscribe
at
the
startup
and
then
it
happens
then
go
for
it.
Don't
use
ambient
context.
I
don't
know,
warn
if
it's
there
try
to
log
warning
no
open
Telemetry
involved.
Well,
maybe,
but
through
the
login
API,
just
say
that
something
is
wrong.
You
shouldn't
have
ambient
context
here.
A
Discarded
I,
don't
know,
but
then,
if
on
your
SDK,
you
know
that
it
can
be
both
where
you
can
have
well
attended
context,
then
you
may
provide
configuration
to
users,
but
probably
the
default
should
be.
This
is
an
interesting
question.
I
would
argue
that
the
default
should
be
ambient,
because
it's
just
the
consistent
with
everything
else
in
up
in
Telemetry
World,
which.
B
Context,
star
links
with
with
regards
to
a
batch
processing
span
I
think
that
they,
they
should
be
completely
different
spans
I,
think
that
if
you
have,
for
example,
a
message
system
where
you
receive
a
batch,
that
should
be
one
type
of
span,
maybe
like
batch,
for
example,
and
then
when
you
are
within
that
batch,
say
you
take
each
individual
message
and
process
it
individually.
A
C
C
Discussed
like
we
also
discussed
I,
think
some
time.
C
Like
this,
in
this
case
like
having,
for
example,
why
are
iterating
to
the
messages
and
and
so
on,
I
think
we
did
we
not
like
having
like
a
lot
of
processing
spans,
because
there
was
someone
saying
that
it
could.
The
best
could
could
have
like
1000
messages
in
that
creating
1000
1000
processes.
10
would
not
be
ideal,
I
think
I,
remember
well,.
B
Yeah
there's
certainly
cases
where
I
think
that
having
individual
message
for
messages
for
each
sorry,
individual
spans
for
each
message
would
probably
be
a
little.
B
Or
excessive,
but
that's
not
all
cases,
I
think
there
are
plenty
of
cases
where
having
individual
messages
are
very
valuable,
so
having
the
ability
to
have
them
is
is
important,
but
I
agree
that
being
able
to
turn
them
off
is
also
potentially
valuable.
B
This
also
goes
back
to
why
for
processing
spans,
it
might
be
valuable
to
actually
so
here's
what
I
would
suggest
the
processing
span
should
always
follow
the
the
remote
span
context
for
parent.
Then
it
would
also
have
the
similar
sampling
characteristics.
B
So,
when
processing
a
batch,
if
your
overall
system
has
a
low
sampling
rate,
then
you're
not
going
to
generate
spans
for
each
message
in
that
batch.
B
Unless
you,
you
have
one
Trace
that
generated
all
of
those
messages.
B
Anyway,
I
I
think
I
still
do
feel
strongly
that
the
processing
should
be
an
individual
message
and
if
you
have
batching
that
that
should
be
a
different
type
of
message,
because
then
the
specification
can
be
very
clear
about
the
processing
span.
Having
a
the
the
parent
be
the
remote
span.
A
Well,
we're
still
we're,
for
example,
for
publish.
We
have
the
same
operation,
the
same
format
of
span
name,
but
the
specific
attributes
that
can
distinguish
batching
from
non-ledging
and
I.
Don't
think
we
should
introduce
a
precedence
of
inconsistency,
I,
don't
understand
why
they
should
be
quite
different,
but
they
can
have
different
rules
like
their
mentally.
There
are
different
kinds
of
spans,
but
from
spec
perspective,
there's
pen
spans
that
are
different
in
terms
of
links
and
specific
attributes,
but
nothing
else.
B
Okay,
if,
if,
if
everyone
wants
to
have
both
batch
and
individual
processing,
be
both
the
same
kind
of
processing
spin,
that's
fine
whatever.
A
Yeah
and
there
I
still
would
like
to
have
different
cases
because
most
of
the
sdks,
my
assumption
would
know
that
parent
is
preferable.
So
basically
it's
an
SDK.
The
instrumentation
Library
choice
to
make
it
parent
or
use
ambient,
but
if
there
is
an
ambient,
an
SDK
on
the
SDK
level,
it
can
be
valid,
we
don't
know
yes,
then
we
should
somehow
spec
it
out.
We
should
say
what
to
do
in
this
case.
B
So
I
think
we're
running
short
on
time.
Ludmila.
Do
you
want
to
go
through
and
update
the
the
meeting
notes
with
kind
of
a
summary
of
Because
I?
Think
you
probably
have
a
better
perspective
on
you
know
what
we've
decided
going
forward
and
how
to
get
Johannes
on
board
with
that.
A
B
Okay,
was
there
anything
else,
I
I
think
I
see
another
agenda
item
from
you,
yo,
yes,.
C
B
C
Yeah
just
quickly
mentioned
this,
there's
a
there's,
this
old
tab.
Now
that
is
open
for
defining
a
procedure.
There
is
a
depth
proposal
for
defining
defining
experimental
semantic
conventions.
I
think
this.
This
is
benefit
or
beneficial
for
us,
because
our
semantic
conversions
are
going
to
be
experimental,
I
guess
for
quite
some
time.
C
So
there
is
this
there.
It's
it's.
C
But
they
didn't
have
much
much
eye
or
many
eyes
on
it.
So
since
we're
talking
all
about
semantic
conventions,
that's
not
mentioning
to
you!
So
maybe
you
can.
You
know.
What's.
C
Yes,
I
think
it's
a
effort
with
with
with
Dan
and
also
Josh,
that
is
leading
the
semantic
convention.
Stabilization
group.
C
A
Yeah
I'll
take
a
look.
Thank
you.
I
had
one
small
agenda
item.
There
is
a
person
who
is
adding
some
attributes
to
remittin
Q
an
optional
once
I
took
a
look.
I
left
my
comments.
I
have
no
objections
with
the
direction
the
spirit
goes
to,
but
we
can't
wait
for
more
folks
to
appear
and
approve
it
too,
or
you
can
go
ahead
and
approve
his
full
request
when
he
is
ready.
What
do
you
think
we
should
do.
A
C
Let's
see
yeah
I
I
I'll
try
to
read
it
tomorrow
and
then,
if
I
have
something
I
I
would
have
but
I'm,
not
a
rapid,
mq
expert.
So
not
sure
if
I
can
add
too
much
but
I'll
take
a
look.
It's.
A
Pretty
straightforward
and
there
is
a
magically:
oh
okay,
so
I
will
leave
another
comment
there,
but
it's
it's
really
straightforward.
He
just
follows
some
revitation
documentation
here.
C
C
All
right,
cool,
just
redundant
I'll,
take
a
look
at
the
notes.
Once
you
wrote
it
down
so
yeah.