►
From YouTube: 2022-10-06 meeting
Description
Instrumentation: Messaging
A
A
A
B
B
Don't
forget
to
add
your
name,
I
post
the
agenda
link
on
the
chat.
D
B
B
So
if
you
have
any
topics,
feel
free
to
add
to
the
agenda
I
added
a
few
that
I
could
pick
up.
I
was
a
bit
busy
week,
so
I
didn't
have
much
time
to
prepare
too
much,
but
I.
Remember
that
last
time
we
had
this
stuff
from
Niraj,
but
we
didn't
get
to
it
so
I
put
here
at
the
top,
so
we
can
start
with
it
is
here:
yes,
yes,
hello,
so
feel
free
to
to
yeah
go
ahead.
E
So
this
is
a
topic
that
we
earlier
discussed
and
just
wanted
to
follow
up
on
this
one
and
how
we
should
proceed
on
this
so
with
the
current
specs,
because
links
are
attached
to
the
receiving
span.
So
one
issue
with
that
is,
if
there
are
multiple
messages,
are
received
together,
they
all
point
to
one
receives
10.
our
day.
These
messages
can
be
processed
different,
like
one
message
could
be
put
in
database
and
other,
like
message
could
be
put
into
the
queue.
E
So
it's
hard
to
actually
track
that
how
these
individual
messages
were
processed,
like
which
one
went
to
like
suppose,
database
which
one
went
to
Q
and
because
the
links
are
attached
at
the
receiving
level
and
have
you
we
said:
okay,
let's
maybe
put
it
as
a
separate
story
or
separate
us
apart
from
the
current
specs,
we
are
doing
because
it's
kind
of
enhancement
so
wanted
to
follow
up
on
this
one,
this
particular
topic
and
is
there
something
I
can
help?
B
Okay,
yeah,
so
I
think
what
we
have
been
discussed
so
far
is
like
I,
said
the
receiving
so
we'll
add
the
links
from
the
context
that's
inside
of
messages
to
this.
So
until
then,
then
we
we
are
covered
right,
but
then
for
the
processing.
It
gets
a
bit
more
tricky
right
because
that's
pretty
much
most
of
the
time,
I
guess
it's
outside
of
the
of
the
library
that
can
be
instrumented
automatically.
B
But
if
you're
acting
on
a
message-
and
the
message
still
has
a
context
so
potentially
the
the
standard
has
been
created
for,
for
example,
for
putting
this
message
on
a
database
or
for
doing
anything
else
with
it
or
for
another
new
method.
That
was
immediately
because
of
this
one,
so
potentially
with
the
context
from
the
message
any
other
spanner
to
create.
B
Apart
from
this,
you
can
still
attach
links
to
it
for
for
the
same
context,
so
all
the
operations
will
be
somehow
linked,
so
you'll
be
able
to
see
them,
but
I
don't
think
we
discussed
much
about
this.
Apart
from
from
the
receive
I
think,
we
discussed
definitely
discussed
the
processing
and
we
landed
in
a
point
where
we
say
like
it's
really
tricky
for
us
to
especially
put
something
like
this
in
the
spec,
because
in
some
SDK
some
languages
is
possible
to
create
a
processing
span
from
the
instrumentation
library,
for
example.
B
B
If
you're
dealing
with
a
message,
look
for
the
context
from
the
message
and
add
links.
F
I
mean
I
think
this
discussion
a
bit
overlaps
with
any
of
it
is
other
the
second
Point
like
this
Trace
structural
tip,
and
then
they
are
near
us.
You
were
asking
how
to
best
proceed
in
that
area.
I
mean.
Maybe
we
could
continue
working
on
this
old
Tab
and
for
I.
Think
a
first
step.
Would
you
agree
actually
on
the
motivation
section
of
this
old
tab
that
we
say?
Okay,
what
kind
of
goals
do
we
want
to
achieve
with
this
kind
of
trade
structure
and
then
I
think
there's
certain
like
motivations?
F
The
urban
is
that
we
can
correlate
producer
and
consumer
traces.
The
other
one
is
that
we
can
integrate
the
intermediary
instrumentation
and
the
third
one
is
that
we
can
that
we
can
somehow
deduce
end-to-end
latency
for
message
processing,
because
that
is
just
a
requirement
that
comes
up
again
and
again
and
I.
E
Sure
yeah
I
think
one
of
the
like
also
motivation
is
like
I
agree
like
and
along
with
the
tracking
a
message
it's
major
like
latencies,
also
because
the
one
message,
the
same
message
can
be
put
in
queue
and
same
message
could
be
put
into
database.
Now
we
have
two
Paths
of
the
same
message:
how
does
customers
actually
get
a
flexibility
that
which
end
to
end
latency
they
want
to
monitor
or
observe
or
to
if
they
want
to?
Maybe
both
then
how
like
they
should
do
that
so
yeah,
okay,
I'm.
A
A
I
guess
that's
part
of
the
processing
of
the
message,
not
the
receiving
end
so
because
we
have
receive
and
we
have
process
and
that's
something
that
I
think
was
scheduled
for
this.
For
us
to
talk
to
that
and
the
message
latency
from
a
perspective
should
be
from
the
one
that
is
sent
until
the
moment.
It
arrives
to
the
destiny,
everything
that
happens
on
the
destiny
itself.
It
should
be
well
it's
processing
and
it
shouldn't
be
related
with
the
transmission.
Latency
I,
don't
know.
E
Maybe
one
thing
I
want
to
clarify
when
we
talk
about
the
latency
generally
elect
end-to-end
latency,
specifically
it's
a
starting
like
it's
starting
point
is
the
when
this
request
originated,
maybe
front
end
and
ends
and
is
where
actually
the
request
was
fully
processed.
It's
like
it
went
via
multiple
lessons:
multiple
hosts,
multiple
micro
Services,
multiple
queues
Maybe,
so
it's
actually
maybe
from
maybe
I'm
using
in
AWS
terms
but
Lambda
to
Q
to
another
Lambda
to
another
q,
so
it
actually
when
customers
are
looking
for
end-to-end
latency.
F
F
I
think
we
have
two
kinds
of
latencies
here.
You
have
a
need
to
keep.
A
part
of
first
is
just
the
the
latency
from
basically
publishing
the
message
to
the
intermediary
to
receiving
the
message
from
the
intermediary.
Some
I
think
that's,
basically
you
have
often
you
have
an
acute
time
for
publishing
and
then,
when
you
pull
or
get
the
message
from
the
intermediary,
you
kind
of
trust
your
comparison
in
queue
time
and
you
have
like
you
have
the
time.
F
Basically,
the
passed
in
between
the
producer
handed
a
message
off
and
the
consumer
kind
of
received
a
message
that
is
wrong,
like
a
term
for
latency
that
we
have
here
and
I.
Think
the
other
term
is
just
from
the
customer
point
of
view
the
end-to-end
latency
from
as
nearer
said
from
when
the
request
originated
until
it
was
actually
completed,
and
there
might
be
messaging
in
between
the
customer
doesn't
often
even
care.
F
But
there's
often
me
a
asynchronous
processes
in
between
between
the
receiver
receiving
of
the
request
and
finally
kind
of
finishing
handing
the
request,
and
that
is
the
other
like
more
how
to
say
more
overarching
a
definition
of
latency
and
I
think
we
need
to
keep
post
apart
and
actually
a
good
point.
Also
in
the
old
tip,
okay
clarify
what
latency
do
we
wanna
kind
of
what
kind
of
latency
calculations
do
we
want
to
support
or
enable.
A
So
usually,
this
would
be
the
the
trace
duration,
so
we
start
to
trace
and
then
it
ends
and
it
has
a
start,
an
outcome
and
it
has
many
spans
in
the
middle.
But
all
are
part
of
the
same
Trace.
But
on
the
case
of
the
messages,
I
believe
that
we
have
cases
where
the
beginning
and
the
end
and
the
the
produce,
the
production
of
the
message
and
its
consumption
might
be
in
different
traces
because
they
are
just
linked
and.
B
I
think
it
has
to
has
to
go.
It
has
some
some
sort
of
heuristics
right
on
on
the
back
end
processing
this
that
he
understands
that
there's
like
two
traces
involved
and
needs
to
calculate
this
in
this
in
this
manner.
B
B
Because
if
a
message
go
through
multiple
place
like
like
describing
it
becomes
harder
and
harder
to
actually
calculate
the
the
entire.
Let's
say
time
where
the
message
was
still
not
fully
finished
or
processed
like
that,
and
then,
for
example,
you
might
want
to
know
if
a
message
goes
from
home
producer
and
goes
from
goes
to
three
different
consumers.
Do
you
calculate
the
end-to-end
latency
from
when
all
the
three
consumers
finished
or
when
only
one
or
do
you
want
to
split
by
consumer?
B
For
example,
do
you
want
to
know
the
latest
for
this
consumer
or
the
one
I
need
for
all
of
them,
so
it
it
can
get
quite
complicated.
I
just
have
a
question:
do
you
know
Niraj?
If
so
in
does
does
Amazon
has
anything
like
this
today
in
their
service
that
they
can
calculate
this
latency
or
or
is
this
something
that.
E
Yeah,
we
don't
have
that
yet,
okay,
so
we
are.
We
are
trying
to
put
that
in
maybe
like
the
hotels
back
so
that
we
can
follow
that.
F
A
So
we
have
one
Trace
from
the
origin,
one
trace
on
the
end
part,
but
on
the
on
the
receiving
of
the
processing
part,
we
might
generate
other
messages
that
are
related
to
the
same
operation
that
can
continue
on
and
on
and
on
and
with
a
trace.
We
know
when
it
ends,
but
with
this
pattern,
where
we
link
things
together,
we
don't
really
know
where
this
ends,
because
it
can
go
forever
well,
not
forever,
but.
B
I
mean
you
could
you
could?
Potentially,
this
is
already
like
detail,
but
you
could
like
the
idea
of
having
the
links
is
that,
for
example,
you
can
then
search
for
all
these
links
right.
So,
for
example,
you
can
search
for
all
these
links
in
the
in
the
platform
or
the
in
the
database.
B
Where
you
have
your
your
Trace
data
in
then,
you
can,
for
example,
find
or
find
all
the
spans
that
are
that
have
has
this
link
for
the
specific
message
and
then
potentially
all
of
this
are
part
of
a
bigger
trace,
and
then
you
can
get
the
duration
from
that
and
then
sum
up
all
together
and
then
maybe
you
will
know,
but
this
is
already
like
something
that
is
yeah
yeah.
It
would
depend
how
the
how
the
back
end
interpret
this
and
build
this.
This
thing
there.
E
A
B
D
D
It
seems
like
the
general
and
to
end
latency
problem.
It's
not
it's.
It
gets
worse
with
messaging.
This
is
beyond
one
Trace
right,
but
it's
not
strict
the
messaging
problem
to
solve
and
we
need
to
take
into
account
other
things
and
if
we
can
like
clarify
what
the
centered
latency
is
at
all,
how
it's
measured.
Maybe
it's
per
service
person,
I,
don't
know,
and
then
it's
it's
a
great
place
to
put
it
into
the
general
stack
meeting,
because
it's
just
a
question
about
links
and
tracing
rather
than
specific
to
messaging.
F
Yeah
I
agree
with
Miller,
because
I
mean
the
the
actual
problem.
Here
is
that
yeah
we
are
talking
about
like
highly
asynchronous
scenarios,
and
there
is
basically
no
like
tracing
solution
here
to
have
latency
for
those
calculations
for
those
asynchronous
scenarios
for
synchronous
scenarios.
It's
nice
because
there
is
a
Bruno
set.
You
just
have
everything
in
a
single
Choice,
usually
and
trust
your
Trace
duration
can
be
your
end-to-end
latency.
But
if
you
have
your
multiple
choices
involved,
things
get
trickier
and
I.
Think.
F
Currently,
our
messaging
is
one
of
the
only
like
popular
scenarios
where
we,
where
we
come
across,
that
that's
why
it's
often
seen
as
a
as
a
messaging
problem.
F
So
you
see
also
traditional
Miller
that
we
just
try
to
come
up
like
apart
from
messaging,
like
with
a
more
generic
formulation
of
this
problem,
just
not
not
focused
on
messaging
but
focused
on
asynchronous
scenarios
and
instrumentation
of
those
scenarios
in
general.
D
Right,
it
would
be
nice
to
have
some
write-up
with
like
suggestions
for
to
like
the
suggested
answers
to
these
questions
right.
How
do
we
measure
and
take
items?
How
do
we
Define
it
and
from
there
we
can
probably
move
forward
into
the
messaging
space.
E
D
Cool
because
this
is
tricky
right,
so
formally
wait,
I'm
trying
to
say
it,
I,
don't
know
if
I'm,
a
good
reason,
I,
really
I
believe
this
is
a
very
important
scenario.
It's
just
not.
Our
group
is
not
the
right
Forum
to
deliver
it
because
with
its
General
concern
and
then
if
this
is
something
that
you
folks
are
looking
for,
it
seems
maybe
there
is
some
interest
for
Microsoft
I'm
sure
there
are
other
community
members
who
would
be
interested
in
this.
D
Just
don't
know
how
to
approach
it
and
maybe
trying
to
find
them
and
starting
with
either
GitHub
issue
or
an
otap
can
be
a
good
start
to
like
find
people
who
are
interested
in
this
effort
and
try
to
Define
these
things
in
just
the
API
spec
language
that
or
maybe
start
from
user
scenario
saying
okay.
This
is
how
I
want
users
to
get
this
to
use
this
feature
right
and
then,
if
you
take
a
look
at
any
Otep,
you
can
have
an
idea.
D
There
is
a
template,
you
can
feel
it
and
you
can
send
a
PR
and
people
interested
people
will
come
and
review
it
and
we
can
see
how
to
move
on
from
there.
Does
it
help
at
all.
E
No
yeah
definitely
definitely
thanks
and
do
you
feel,
like
tracking
a
message
end
to
end
and
end-to-end
latency.
These
are
kind
of
same
topic,
or
do
you
feel
these
are
different
ones
like
taking
a
message
and
to
end
is
also
part
of
generic
or
tap.
D
Yeah,
so
this
is
an
example
of
General
and
templates
right,
but
it
won't
answer.
Questions
like
specific
messaging
things
want
to
answer
your
question
about
the
database
versus
queue
right,
so
we
we
don't
know
where
the
operation
ended
and
the
Cure
and
the
database.
It's
more
like
a
generic
question.
A
But
we
might,
we
might
need
to
go
a
bit
deeper
because
we
need
to
search
where
the
latency,
the
request
latency
or
how
it's
defined
to
understand
if
it's
more
related
with
our
end-to-end
definition
that
we
are
looking
here
for
for
messages
already
or
if
it's,
if
it's
very
specific,
because
we
might
be
in
a
case
where
the
latency
that
we
are
trying
to
Define
dozens
much
what
the
specification
tries
because
I
imagine
that
they
wanted
to
calculate
this
latency
based
on
the
the
trace
and
for
our
case
the
traces
are
not
a
solution.
B
Yeah
but
I
guess,
but
this
one,
but
this
also
applies
to
to,
for
example,
this
other
asynchronous
that
doesn't
necessarily
have
to
do
anything
with
messages
like
the
cloud
event.
For
example,
you
can
still
you
can
you
can
use
that
and
the
events
can
go
via
normal
HTTP,
no
queues,
nothing,
but
you
still
have
the
same
problem,
because
one
event
can
affect
the
other
end.
Then
you
don't
know
when
the
actual
thing
the
actual
thing
ended,
so
I
think
the
idea
of
asking
in
a
broader
form,
I
think,
makes
sense.
B
Apart
from
the
options
that
would
be
Dimension,
you
can
also,
if
you
don't
know
like,
if
there's
anybody
interested
in
this,
you
can
also
ask
on
the
slack
channel,
for
example,
just
ask
generally,
if
there's
anybody
interested
in
this
did.
C
B
Have
this
problem,
how
you
would
how
to
get
started
in
discussing
it
or
something?
Yeah
could
also
join,
for
example,
to
expect
this
back
meeting
what.
B
Tuesday-
and
they
just
put
an
agenda,
say
I
want
to
talk
about
this.
Do
you
guys
have
an
answer
for
this
already
something
like
that.
B
Yeah
because
the
the
spec
meeting
usually
there's
a
lot
of
folks
from
different
with
different
expertise
in
different
areas
and
yeah.
If
you
have
your
your
point,
there
just
be
prepared
to
present
it
and
and
and
present
it
in
a
in
a
way
that
can
be
understood
by
everybody
and
then
might
get
some
pointers.
How
to
proceed
or
something
like
that.
B
B
A
D
B
D
B
All
right:
okay!
Yes,
the
next
thing
that
I
added
on
the
agenda
was
yeah.
The
pr
from
Johannes
I
just
started.
Looking
at
it
today,
I
didn't
have
much
time,
but
I'll
continuing
I'll
continue
looking
looking
at
it,
then.
F
Yeah,
this
is
still
like
anyway,
in
a
draft
State
and
I.
Think.
The
main
purpose
of
this
PR
is
just
that
we
kind
of
can
move
away
from
this
big
192
and
maybe
retire
this
big
one
and
I
think
having
the
things
more
like
distilled
like
the
span
structure
stuff
in
this
PR.
F
That
I
think
will
help
us
to
identify
open
questions,
because
also
when,
like
you're
writing
things
down,
I
I
I
stumbled
across,
like
some
still
things
that
are
open
and
done
key
or
like
we
had
the
latency
question
before
different
kinds
of
latencies.
I
will
add
that
in
the
PR,
but
I
think
for
start.
F
If
people
in
this
meeting,
if
you
have
maybe
at
least
could
have
a
look
at
just
a
beginning,
like
the
motivation
section,
that's
kind
of
yeah,
more
or
less
like
a
mission
statement,
and
we
trust
you
up
before
we
go
into
all
the
details
of
of
the
of
spans
and
links
and
whatever
that
we
just
can
agree
on
your
like
what?
What
are
our
goals
when
working
on
this
and
then
maybe
I
thought
Miller
said.
Maybe
then
one
step
will
be
to
say.
F
Okay,
yeah,
it's
not
just
looking
at
messaging,
is
not
enough
to
like
reach
these
goals.
We'll
have
to
go
like
get
more
General
and
talk
about
asynchronous
scenarios
in
general.
Maybe
that
will
be
like
a
next
step
or
the
thing
from
us
from
messaging
site
just
coming
up
with
this
motivation
and
this
goals
that
we
have.
That
would
be
a
great
first
step.
F
So
if
you
are
yet
just
could
just
have
a
look
at
that
and
add
your
thoughts
there
and
maybe
then
we
can
discuss
or
continue
discussion
in
a
PR
or
in
next
week's
meeting.
F
B
How
do
you,
how
do
you
want
us
to
voice,
for
example,
just
leaving
comments
that
we
agree
with
this
statement.
F
If
you
I
mean,
if
you,
if
you're
on
regions,
if
you
just
just
add
your
thoughts
like
if
you
don't
agree
with
something
or
think
something
is
missing
edit
there
and
then
maybe
yeah,
we
can
come
to
like
like
an
like
a
agreement
or
compromise
in
the
pr.
Otherwise
they
can
discuss
next
week.
B
B
B
All
right,
so,
yes,
let's,
please
take
a
look
at
this.
If
you
can
yeah
and
then
we
discuss
next
week,
the
last
thing
that
I
put
here
I
yeah
last
time.
Last
week
we
discussed
we
started
discussing
about
the
single
message
scenario
and
more
specifically,
where
we
had
the
attributes
to
the
spin
where
we,
when
we
are
working
on
a
single
message
and
we
we
ended
up
without
not
having
any
any
conclusion.
B
So
I
just
put
it
here,
so
we
can
continue,
continue
discussing
it
so
yeah
again,
there
is
the
there's,
the
pros
and
cons
of
of
each
each
alternative,
the
pros
of
of
so
we
discussed
single
message
scenarios
and
then
we
can
on
the
receipt.
B
For
example,
when
we
receive
the
message
we
can
add,
for
example,
the
message
ID
and
the
destination
and
or
in
this
case
The
Source
on
this
receive
span
in
the
same
case
in
the
producer,
when
doing
the
publish,
we
can
add
the
message
ID
on
the
publish
span
or
we
can
add-
or
we
can
add
the
link
and
add
the
attributes
to
the
link
because
yeah
so
the
pros
for
that
is
using
the
link.
There
is
because
it
will
be
the
same
as
when
working
with
batches.
B
So,
if
you
remember,
when
we
talk
about
batching,
we
need
to
have
a
we
need
to
add
links,
because
we
need
to
have
a
place
to
wait
to
a
place
to
put
the
message
specific
attributes.
B
So
the
pros
is
that
they
stay
the
same
when
you're
dealing
with
the
patch
or
a
single
message,
and
the
con
is
yeah
to
me,
seeing
that
is
just
an
overhead
that
people
will
have
there
and
they
will
get
this
link
and
not
really
sure
I
actually
talked
to
some
people
internally
here
and
I
I
mentioned
that
this
is
being
discussing.
B
Some
people
were
also
confused
already.
They
said
like,
but
what
do
I
need
the
link,
if
I'm,
just
working
on
a
single
message,
can
I
just
have
this
event
directly?
Why
do
I
need
this
like
this
extra
layer
of
interaction,
for
example,
so
people
might
might
I
think
people
might
will
challenge
this
in
a
specific
way?
So,
but
the.
B
That
for
backend,
for
example,
it
might
be
simpler
because
they
don't
have
to
have
two
handling
of
different
things,
which
is
arguable,
I
guess.
But
it
is
one
concern.
D
Then
there
is
a
back
end
which
pays
the
price
if
there
was
four
links
anyway,
but
then
there
are
users.
So
if
we
prioritize
users
higher
than
instrumentations
and
backgrounds,
then
we
should
make
it
simple
in
simple
cases,
and
then
we
were
also
making
it
simple
for
instrumentations
for
them
who
can
right
and
then
we
basically
only
make
things
maybe
I'm,
not
even
convinced,
but
maybe
we
make
things
harder
for
the
back
ends.
But
that's
okay.
Users
should
not
pay
this
price.
B
Yes,
I
I
am
with
you
on
this
I.
Think
yes,
and
then
we
also
have
to
think
that
it
will
kind
of
break
the
existing
things,
because
everybody
everybody
that
already
has
some
sort
of
instrumentation
for
their
messaging
things
and
they
work
on
single
message
and
is
this,
for
example,
change
or
something
like
that.
Then
it
could
start
start
stop
working,
because
if
the
backend
doesn't
support,
attributes
or
links
yet-
and
things
like
that,
so.
E
You
know
I
suppose,
if
I
take
the
example
of
AWS
in
X,
like
sqs
to
Lambda
or
sqs
to
ec2,
consumers
can
configure
that
I
will
receive
one
message
at
a
time
if
respective
of
like
how
many
messages
are
into
the
even
Q
actually
has
multiple
messages.
But
consumers
are
configured
to
pick
one
message
at
a
time:
maximum
and
there's
another
one
message
scenario
where
the
messages
are
coming
very
slow,
so
consumers,
even
though
it
wastes
try
to
batch,
but
there's
only
one
message
available.
E
So
sometimes
message
comes,
it
might
actually
batch
multiple
messages,
but
most
of
the
time
it's
a
single
message.
So
are
we
covering
like?
Are
we
saying
like
in
all
the
cases?
If
consumer
receives
one
message?
That's
that's
what
one
message
means,
or
is
it
something
that
consumer
is
configured
to
pick
maximum?
One
message.
D
So
I
think
there
are
two
clear
scenarios:
one
is
my
SDK
only
supports
single
receive.
Then
we
are
probably
all
on
the
same
page
that
don't
use
links
just
take
it
as
a
parent.
Then
there
is
another
case
where
I
my
SDK
supports
batch
and
I
receive
the
batch.
So
it's
clearly
should
be
transfer
links
right,
but
then
there
is
this
middle
case.
D
E
And
one
more
question
on
the
in
the
when
consumers
are
configured
to
actually
receive
one
maximum
one
message
at
a
time
this
on
the
review
spend
the
new
Trace
has
already
started
I'm,
assuming
because
it
has
to
record
that
receiving
call.
D
There
are
two
problems
here:
the
first
one
is:
if
it's
not
necessarily
the
case
that
the
receive
call
is
an
explicit
code
could
be
push
based
right.
Then
there
is
no
code.
There
is
no
context
the
ambient
context,
and
then
we
can
just
take
parent.
But
if
it's
a
pool
call
then
receive
in
this
case
is
a
new
Trace
which
might
have
links,
but
then
there
could
be,
for
example,
the
Lambda
processing
right.
D
E
So,
on
the
oh
yeah
on
the
receive
side
like
I
I.
Sorry,
thanks
for
clarifying
there's
a
two
pool
and
posts.
So
in
the
pool
case
there
is
a
receive
span
and
receive
span
already
started
a
new
Trace.
So
in
that
case,
will
we
use
links
and
like
attributes
is
one
part?
Definitely,
but
does?
Will
it
that
receive
span
have
a
link
that
is
that
will
point
to
the
its
Upstream
Trace
to
actually
record
that
what
were
the
parent,
Trace
identities.
D
Yes,
ideally,
yes,
there
are
some
limitations
on
links,
but
we
hope
we
can
somehow
resolve
them
or
work
around
them
and
receive
is
a
part
of
it
right
there.
Ideally,
you
received,
and
you
do
something
with
these
messages,
so
either
is
the
SDK
or
user,
who
also
creates
another
span
to
process
the
message.
E
B
I'm
a
bit
confused
when
you
say
attach
the
entire
interested.
What
what
you
mean,
the
a
trace
that
is
already
happening
when
the
receipt
happens
or
what
is
the
actual
parent
when
you
say
on,
receive.
E
B
Not
really
no,
so
that
is
the
discussion
here,
because
if
it's
a
single
message
like
let
me
said
if,
if
I'm
using,
for
example,
SDK
that
only
supports
receiving
a
single
message,
not
an
array
or
something
like
that,
then
we
don't
necessarily
need
to
have
a
link,
because
the
message
attributes
can
be
added
on
the
receive
spin
directly
and
then
it
will
need
a
link.
For
example,
in.
C
That
case
I
I
do
think
you
want
to
link
to
the
context
of
the
received
message.
So
I
I
don't
know
if
the
attribute
should
go
on
that
link,
because
of
perhaps
you
know
it's
not
as
well
supported,
but
I
do
think
it's
nice,
because
otherwise
you
have
two
separate
traces.
Oh.
F
Still
in
this
case
need
to
link,
but
without
the
attributes
and
I
just
wanna
like
add
some
thoughts
from
from
my
set
here
to
the
link
to
the
attributes
and
Link
questions
and
I
I
I
I
think
I
missed
some
of
the
discussions
because
there
was
here.
I
know
when
I
was
gone,
discussions
about
which
attributes
are
message
specific
and
which
attributes
are
like
not
message
specific
and
then
the
measured
specific
attributes
might
be
different
for
each
message
and
that's
why
we
need
to
put
it
on
link,
for
example,
twice
a
possibility.
F
The
different,
like
destinations
can
be
in
the
same
batch
method
to
send
to
different
destinations
can
be
received
in
the
same
batch.
So
you
need
to
distinguish,
but
I
even
think
there
might
be
many
cases
where
even
for
a
bet,
you
don't
need
to
distinguish
and
Order
attributes
are
the
same.
Of
course,
maybe
there's
message
ID,
but
that
is
not
in
our
like
required
attributes,
and
maybe
it's
not
put
on
there.
A
Sorry,
what
I
was
thinking
is
that,
okay,
we
have
all
these
different
scenarios.
Sometimes
the
the
the
the
properties
go
one
place,
then
they
go
on
a
different
one
and
it's
not
clear
at
all
why
the
the
attributes
end
up
on
the
links
or
in
the
other.
A
If
we
have
the
spec
and
we
have
all
the
options,
it's
it's
easy,
but
if
we
are
consuming
these
and
are
viewing
it,
it
becomes
confusing
shouldn't.
We
add
some
attribute
or
something
where
it
says.
D
I
think
the
rule
of
thumb
for
the
back
content
for,
however,
they
translate
it
into
their
ux
or
to
users,
is
to
just
merge
when
they
investigate
specific
link
or
specific
messages
to
the
merge
attributes
that
there
are
corresponding
span
and
attributes
that
that
one
corresponding
link,
then
there
is
no
need
for
extra
attribute
and
it's
just
something
that
back-ends
can
make
nicer.
They
can
do
it
themselves.
They
can
provide
users
with
some
additional
features
that
do
it
and
we
keep
it
simple.
D
No,
no,
no
like,
for
example,
I'm
I'm,
a
user
I'm
investigating
some
problem
and
I
have
a
received
span
with
two
links
right.
So
there
are
some
attributes
that
are
on
the
span,
like
broker
name
here,
name
anything
else.
There
are
attributes
that
the
message,
for
example,
message
ID.
D
E
B
Yeah,
so
it's
not
a
recommendation,
but
they
will
have
the
data
and
that
they
can
present
the
data
like
the
attributes,
in
whatever
shape
they
prefer
right.
So
it
became
make
some
nice
UI
and
but
the
data
will
be
there.
So
if
it's
a
batch,
it
will
be,
some
attributes
will
be
on
the
receive
span,
the
the
common
ones
and
and
the
ones
that
are
specific
might
be
on
on
the
links
and
they
can
just
find
a
way
to
present
them.
B
Yeah,
but
but
what
Johanna
said
that
maybe
a
batch
is
let's
say,
homogeneous
and
all
the
attributes
are
the
same.
There's
no,
no
different
things
in
the
same,
so
that
could
make
it
all
of
them
go
go
on
the
same,
but
I
don't
know
if
there
is
any
like
heuristics
that
we
could
add
to
the
respect
that
instrumentations
could
could
see
this
and
could,
for
example,
know
at
the
point
of
creating
the
receipt
that
they
should
add.
B
The
links
there
or
or
should
not
because
dispatch
is,
is
composed
of
messages
all
the
same.
Something
like
this
yeah
and
I
think
the
the
the
message
idea
I
think
it's
required
now
now
right,
you
know
no
I,
think
no!
It's
not.
B
D
B
F
And
I
mean
there's
another
question
here
that
that
just
comes
to
remind
that
when
we
say
okay
yeah,
we
put
the
attributes
on
the
links,
but
I
mean
there
is
basis
and
we
have
some
where
we're
just
we're.
Just
the
consumer
side
is
instrumented
and
not
the
producer
side.
F
So
if
trust
the
consumer
site
is
it's
just
the
consumer
side
is
instrumented
and
you
receive,
let's
say
a
batch
of
messages.
Then
there
is
no
context
on
these
messages
and
there's
no
context
to
link
to
so
what
what
what
I'm
doing
this
in
this
case.
D
And
yet
there
are
three
options:
right,
the
first
one.
There
are
two
options:
the
first
one
is
still
add.
Links
to
invalid
content.
Extend
the
other
option
is
third
event.
It
feels
to
me
that
that
the
first
option
has
some
problems
with
invalid
context.
The
second
option
has
a
problem
with
inconsistent
Theory.
So,
but
maybe
the
problem
was
inconsistency
is
solved
by
Always
setting
an
event
on
the
receive
staff,
because
we
can't
add
links
at
the
start
right
and
then
maybe
the
answer
is
okay.
D
Events
everywhere
and
events
will
have
span
context
conventions
for
the
events,
API
communities
working
out.
Yes,
we
will
need
to
dive
a
bit
different.
It
is
and
investigate,
and
try
to
come
up
with
some
proposals
and
objections.
F
Yes,
I
agree,
I
mean
if
we,
if
we
say
either
the
thing
can
be
on
span
attributes
or
on
link
attributes.
That's
ours,
that's
already
a
lot,
but
if
you
say
it
can
be
on
span
attribute
some
link
attributes
or
it
can
be
an
event
that
is,
that
is
definitely
I.
Think
too
much
for
right
and
basically
everywhere
for
anywhere
else.
B
E
B
B
No
I,
don't
think
so.
I
I
think
it
was
just
merged
recently,
but
I
I
might
be
wrong,
but
I
don't
think
there
is
any
convention
for
this.
No
I'll
take
a
look
yeah,
but
if
there
is
then
that
might
be,
there
might
be
a
way
out
instead
of
of
links
but
yeah,
then
it's
another
thing
that
is
also
not
supported
by
anybody,
because
links
are
getting
a
bit
more
attention
and
against
baby
starts
supporting
them.
And
then,
if
we
switch
to
to
events,
then
it's
another
thing.
D
B
Yeah
yeah,
but
I
guess
the
case
when
there's
no
like
the
producer
is
not
instrumented
yeah.
It
might
be
also
common.
I
guess
that
this
is
the
case,
and
maybe
we
will
have
actually
to
end
it
up
with
three
recommendations
and
yeah,
because
I
mean
what
can
you
do
right,
it's
creating
a
invalid
context,
just
for
the
sake
of
it.
Also,
it's
not
that
great
yeah
just
just
to
keep
just
so
we
keep
the
link.
B
F
I
mean
one
one
question
still
like
more
like
from
the
high
level
point
of
view.
I
have
here,
is
that
basically
we
said
yeah
there
might
be
cases
even
for
batteries
where
we
can.
We
can
put
all
the
attributes
on
the
span,
because
they're
consistent
and
there
might
be
cases
where
we
are
have
attributes
that
are
different-
will
be
different
for
the
span
so
where
to
put
them
I
would
wonder
about
your
estimates
about
the
about?
F
How
often
would
we
see
those
cases
like
for
the
case
where
we
have
a
batch
and
we
cannot
put
everything
on
a
single
span?
Would
this
be
the
exception,
or
would
this
be
actually
to
rule,
and
the
exception
would
be
that
they
say?
Okay,
no.
We
need
to
have
different
attributes
for
each
message
message
in
the
patch
here
and
we
cannot,
like
trust,
use,
band
attributes.
F
D
Thank
you,
I
I
can
speak
from
Azure
messaging
services
and
on
the
producer
side
we
very
rarely
have
any
message
specific
attributes,
but
on
the
consumer
side
we
kind
of
always
have
them
so,
for
example,
the
message
ID,
maybe
not
for
event
Hub,
but
for
service
box.
We
have
a
message
ID.
We
have
delivery
count
which
I
think
is
extremely
useful.
D
If
we
switch
to
just
general
imp,
they
also
have
message
ID,
like
everyone.
Every
system
I
looked
into,
has
some
sort
of
message.
Id,
and
also
there
are
things
like
correlation
ID
that
are
specific
to
scenarios.
There
are
some
routing
things
similar
to
routing
key
in
Revit
that
are
per
message.
D
C
Well,
I
think
in
the
case
of
message,
ID
like
the
JMS
message:
ID
is
set
by
an
application
before
it
sends
the
message
and
so
in
a
jail.
You
know
if
I
guess,
maybe
JMS
things
were
batches,
but
it
depends
what
we
mean
by
message:
ID.
If
it's
an
application
layer
message
ID,
as
is
the
case
with
JMS,
then
it
might
be
unique
per
message.
But
if
you're
talking
about
the
messaging
infrastructures
assigned
message
ID,
it
probably
doesn't
get
assigned
until
a
broker
receives
it,
in
which
case
it
wouldn't
be
there
on
send.
C
But
I
do
want
to
discuss
message
IDs
more
when
we
get
into
discussing
attributes
because
I
think
there's
the
concept
of
application
layer,
message,
IDs
and
messaging
system
message:
IDs
that
are
two
distinct
Concepts
foreign.
D
F
B
E
It's
just
trying
to
understand
that
statement,
because
if
you
are
saying
in
even
for
single
message,
there
will
be
links
to
point
to
the
parent
side,
a
producer
side,
traces,
and
then
it
means
that
anyhow,
like
customers
will
have
like
kind
of
in
they
have
to
interact
with
links
and
how
simple
instrumentation,
because
now,
because
I'm,
assuming
instrumentation,
need
to
take
care
of
both
like
the
for
one
message
and
for
like
batches.
So
it
means
like
they
might
be.
Writing
two
implementations
right.
D
D
Yeah-
and
there
is
a
second
case
regarding
attributes
right
regardless
of
whether
we
created
the
link
or
links
or
many
or
where
do
we
put
attributes,
so
it
seems
currently
for
users
and
for
backends.
If
we
put
l,
we
cannot
span,
it
will
be
more
beneficial
because
none
of
the
backends
supports
links
and
attributes.
D
D
F
Specific
one
minute
left
I
just
wanted
us
to
question
how
we,
how
we
go
about
the
further
attribute
discussions.
Are
we
also
planning
to
kind
of
split
out
a
separate
out
tip,
or
are
we
gonna
continue
in
the
existing
Otep,
or
are
we
just
keeping
notes
somewhere
else
I
think
we
talked
about
issues
or,
like
those
notes,
last
time,
just
wondering
how
we
how
we
plan
to
proceed
there.
D
So
if
I
have
a
suggestion
and
I
already
started
doing
this,
I
I
wasn't
great
at
keeping
it
up.
I
have
a
CML
file
and
the
spark
generated
and
the
pull
request.
This
allows
to
capture
all
those
things
there
and
maybe
next
time
we
can
review
it
and
details
and
see
if
our
level
of
consensus
is
a
captured
it
correctly.
In
this
thing,
then
we
don't
need
to
actually
write
any
text.
We
can
just
update
the
yaml
and
update
edit
to
update
the
table,
and
then
it's
already
strictly
described
in
a
formal
way.