►
From YouTube: 2022-07-07 meeting
Description
Instrumentation: Messaging
A
A
Maybe
we
will
start,
I
saw
there's
a
question
from
aws
x-ray
site,
but
maybe
let's
start
with
this
one
here,
because
it's
very
short
there
is
the
just
to
give
an
update
here.
I
think
zhao
talked
with
tc
in
the
dc
meeting
about
this
pr
and
thanks
a
lot
for
out
that
moved
things
forward.
So
we
have
over
from
yuri
now-
and
I
think
carlos
left
some
comments
just
a
few
minutes
before
so
yeah.
That
seems
to
be
moving
forward.
A
B
D
A
A
A
So
in
this
group
we
try
kind
of
to
improve
on
those
and
what
you,
what
is
here
on
the
screen,
that's
what
we
came
up
with.
So
when
you
ask
what
is
the?
What
is
the
correct
one
currently,
officially,
the
old
one
is
still
kind
of
the
that's
what's
in
this
back
repository,
but
we
are
trying
to
replace
this
with
with
what
is
in
this
old
tab
and
what
is
here
on
the
screen.
A
A
The
the
main
motivation
here
is
that
this
process
spans
they
are,
you
could
say,
those
those
are
kind
of
in
the
user
space
more
or
less
like.
When
we
think
about
like
messaging
systems,
you
usually
have
some
kind
of
some
kind
of
sdk
that
you're
using
be
the
kafka,
sdk
or
event
of
sk
sdk,
or
maybe
a
sns
sdk,
and
the
goal
that
the
one
of
the
goals
that
we
had
was
that
we
said
okay
by
just
using
an
instrumented
sdk
and
without
the
user
doing
any
instrumentation.
A
It
should
be
possible
to
kind
of
get
get
a
valid
instrumentation,
so
to
make
it
easier
for
the
user,
the
user
just
grabs
the
sdk
and
says
okay,
I
want
to
turn
hotel
instrumentation
on
and
just
the
sdk
kind
of
is
able
to
create
the
spans
that
are
required
for
for
to
satisfy
those
semantic
conventions,
and
that
is
not
possible.
When
we
require
process
span
because
the
process
bands,
those
would
need
to
be
created
by
the
user.
A
A
I
mean
army
pointed
out
some
use
cases
where
you,
for
example,
for
some
message,
maybe
messages.
Maybe
you
don't
have
a
process
plan
at
all
because
you
drop
it
or
maybe
you
have
kind
of
some.
You
have
multiple
process
banks
for
a
single
message
or
for
batches
of
messages.
For
example,
you
kind
of
receive
a
batch
of
message
and
then
for
each
message.
You
do
some
transformation.
A
That
is
one
process
span
and
then
afterwards
for
each
message,
you
kind
of
you
store
it
somewhere
else
like
in
a
database
and
that's
another
process,
then
so,
basically
having
two
process.
Bands
working
on
this
whole
batch
of
messages-
and
it's
not
clear
kind
of
then
which
span
should
link
to
the
to
the
published
spans
or
to
the
producer
spans,
and
that's
why
we
say:
okay,
we
work
with
this
receive
spam.
A
This
receive
span
here
covers
the
the
duration
of
this
receive
operation
that
the
is
initiated
by
calling
the
sdk
that
is
kind
of
the,
for
example.
The
client
calls
into
the
sdk
and
says:
okay,
give
me
10
spans,
give
me
10
messages
and
sdk
returns
messages,
and
this
operation
is
covered
by
this
receive
spam,
and
this
is
then,
the
link
used
to
link
to
the
publish
spans
and
then
it's
up
to
the
user.
A
A
D
A
If
that's
true,
you
lose,
then
you
basically
here
just
have
the
batch
receive
and
with
pros
with
the
processbands.
That
would
be
then
up
to
the
user
kind
of
maybe
to
link
the
processband
to
the
right
message,
but
this
is
not
something
that
we
currently
require
in
the
in
in
in
this
proposed
spec.
Here.
D
They
can
process
this
five
time
in
five
different
ways,
one
put
into
the
like
for
long
analysis,
one
for
like
quick
summaries
or
something
yeah,
one
so
question
on
like
if
suppose,
customers
put
the
links
on
in
this
case,
they
actually
by
default,
get
this
experience
and
they
actually
enhance
it
and
say
that
okay,
let
me
allow
process
message,
one
to
link
to
the
pros
to
the
publish
message,
one
so
I'll
link
in
that
way.
Also,
our
these
sdks
are
already
generating
the
links
so
they're
like.
A
D
D
A
E
Maybe
a
suggestion:
maybe
we
can
adopt
the
language
for
attributes
where
we
say
it's
recommended,
which
means
it
should
be
on
by
default,
but
instrumentation
may,
if
they
want
to
make
it
configurable.
We
don't
specify
how
this
configuration
looks
like
at
this
moment,
but
we
just
say
it's:
it
can
be
configurable
and
it's
up
to
instrumentation
to
enable
this.
A
A
Maybe
add
this
as
a
comment
to
the
pull
request
and
then
maybe
there
is
discussion
there
and
if,
if
people
agree,
we
can
see
about
the
about
the
loosening
those
requirements
when
I
think
it's
anyway,
the
all
the
requirements
that
we
make
here,
none
of
them
is
a
must,
I
think,
the
strongest
to
use
it
should.
So
if
there
is
a
good
reason
to
do
it
differently.
A
E
Recommended
is
is
showed
it's
the
same
disabled.
I
have
a
question,
though
it
seems
it
may
be
vendor
specific,
so,
like
one
distraught
may
decide
to
drop
those
links
for
exporter
if
they
don't
want
them.
So
my
question
is
whether
it's
the
customer,
who
wants
none
of
the
vendors
to
export
this
links
or
it's
a
vendor
who
does
not
know
how
to
deal
with
them
and
if
it's
the
latter,
then
it
probably
can
be
done
later
in
the
pipeline
on
the
exporter
collector
somewhere
else.
B
Yes,
I
was
going
to
ask
the
same
thing
because
they
receive
spam
more
or
less.
I
guess
will
always
be
there,
because
it's
it's
a
relevant
thing
to
have
right,
I
mean
it's.
I
mean
I
would
imagine
that
it's
important
to
know
like
how
long
it
took
to
fetch
the
for
for
this
for
this,
for
this
pool
operation
to
to
to
like
how
long
it
took
right.
B
D
We
don't
support
as
any
linking
as
of
now.
We
are
working
on
a
project
too,
but
one
thing
actually
and
to
be
frank,
like
the
default
like
by
default,
actually
adding
a
link
to
the
receive
span
makes
sense.
One
thing
that
we
are
losing
is
this
end
to
end
latency.
Now
suppose,
if
you
take
this
example,
only
if
customers
want
to
follow
this
process
like
message,
one
via
the
link
from
this
link
is
going
to
the
receive
one
and
now
they
don't
know
which
spam
actually,
which
process
pen
process.
The
message.
B
B
The
the
the
processor
is
a
child
of
receive
right
and
then,
if
even
if
the
links
is
on
the
receive
the
the
customer
will
be
able
to
to
to
find
this,
because
they
would
click
on
the
process
that
says
pen
and
they
would
know
that
the
parent
is
received
and
then
it
will
find
the
links,
but
in
some
cases
the
the
receipt
like
you
call,
you
call
pull
and
there's
no
way
for
the
pool
to
be
a
parent
or
or
something
like
that
of
the
process.
Then
you
lose
it.
B
But
if,
for
example,
if
you
in
your
sdk
you
you,
your
ck
works
in
a
way
that
you
always
have
a
way
of
linking
the
or
or
having
the
process
having
access
to
the
process
operation
of
the
customer,
then
you
could
in
your
sdk.
You
could
add
the
links
there
as
well
or
or
make
this
structure
look
better
for
for
for
for
that
use,
because
I
think
that's
that
would
be
okay.
I
think
if
your
sdk
does
does
this,
if
it's
possible,
for
example,
try
the
links
on
the
process
yeah,
but.
F
B
E
It's
an
interesting
part
that
we
probably
need
an
aristic
to
tell
what
is
the
process
span
right?
So
if
it's
there,
then
we
can
have
some
tooling,
where
we
can
document
it
that
it's
possible
to
understand
the
intent
latency
in
this
case-
and
I
think
currently
it's
just
the
name
of
this
pen
and
maybe
it's
sufficient
niraj.
It
seems
that
this
heuristic
to
distinguish
the
receive
from
processes,
the
one
that
would
help
you
isn't
the
case.
A
I
think
what
mailer
says
is
that
when
you
link
receive-
and
you
also
link
process
to
publish
then
basically,
when
you
want
to
look
at
the
you,
get
that
and
latency.
You
look
at
the
publish
span
here,
but
then
you
have
two
outgoing
links
and
you
don't
really
know
which
one
to
follow
to
kind
of
to
kind
of
calculate
the
end-to-end
latency.
So
that
can
be
kind
of
confusing
to
have
two
links
outgoing
here
and
you
don't
know
which
one
is.
The
is
the
right
one.
D
That's
the
one
way
we
were
thinking
like
into
the
link
attribute.
Customers
can
define
that
this
is
the
higher
priority
or
this
is
the
process
span.
They
can
put
the
liking
that
links
attribute,
and
then
we
will
check
if
out
of
those
links,
if
both
are
pointing
to
the
same
trace.
But
one
actually
has
this
reserved
attribute
and
that's
saying
that
I'm
pointing
to
the
process,
and
then
we
start
following
the
process
link
and
we'll
kind
of
ignore
the
receive
one
for
end-to-end
latency.
I.
E
Think
we
don't
even
need
us
an
extra
attribute,
we
can
do
it
with
spam
kind,
and
this
way
it
can
be
common
pattern,
not
necessarily
for
just
messaging
semantic
conventions,
but
for
the
rest
of
the
things.
I
I'm
not
sure
I
don't
remember.
If
what
does
this
fun
kind
on
the
and
process,
but
assuming
they
are
different
and
they
probably
should
be.
This
can
be
the
series
statement.
A
A
A
So
that's
that
was
the
reason
why
we
said
okay
to
kind
of
we
don't
want
to
limit
any
of
those
cases
and
we
just
leave
it
kind
of
to
the
user
to
create
those
process
bands.
But
we
have
this
common
ground
of
this
receive
spanner.
We
say,
okay,
that
can
always
be
there.
That
is
common
for
all
scenarios.
E
A
E
What
I
want
to
say
that
if
sdks
do
the
processing,
maybe
this
is
how
they
do
it.
Just
an
idea:
we're
not
going
to
put
it
into
the
spec
and
if
they
don't,
maybe
they
should
provide
some
helpers,
or
this
is
the
sample
code.
We,
like
somebody,
can
provide
so
users
do
the
right
thing
and
then
there
in
this
free
form,
we
will
express
how
we
see
this
process
going
forward
and
then
we
can
make
sure
that
there
will
be
no
contradiction
between
receive
and
this
future
process
spans.
B
B
A
Yeah
I
mean
it
makes
definitely
I
mean
what
miller
said
before.
I
think
it
makes
definite
sense,
exploring
these
defense
scenarios,
because
it
kind
of
helps
us
to
kind
of
then
decide
whether
this
receive
linking
is
feasible
for
most
of
those
scenarios.
That
are,
I
mean
one
other
reason
for
having
the
links
on
the
receipt
is
just
that.
A
So
I
think
that
is
one.
We
are
one
thing
all
that
in
mind
that
basically
the
user
does
the
instrumentation.
It
all
just
turns
the
uses,
the
messaging
instrumentation
libraries-
and
I
think
that
is
the
use
case.
It
should
definitely
satisfy,
but
then
yeah,
there's
kind
of
the
power
user,
who
kind
of
wants
to
create
the
process
bands
and
wants
to
have
certain
links
on
there,
and
I
think,
that's
as
a
neural
archive
miller,
pointed
out.
That's
yet
unclear
how
that
integrates
with
this
minimal
receive
span
approach.
A
F
F
E
F
To
do
it,
I
think
what
we
should
do
is
to
accept
that
there
might
be
multiple
links
per
message,
each
one
describing
a
different
thing
and
decide
how
we
want
to
add
link
attributes
to
decorate
the
the
purpose
of
each
link.
So
it's
easy
to
follow
so,
for
example,
if
you
have
this
m1
this
message,
one
and
you
see
like
five
links-
you
see.
Okay,
this
is
where
it
was
set
up.
This
is
where
it
was
received.
These
are
the
three
places
it
was
processed.
F
This
is
how
I
imagine
it
would
be
easy
to
work.
I
don't
think
we
should
drop
the
receipt.
I
think
like
this
data,
this
instrumentation,
then
it
has
to
be
processed
and
if
we
allow
all
sorts
of
combinations
in
the
specification
like
you
can
do
this
and
this
and
you
can
drop
this
one
or
put
the
links
here.
Oh
like
as
if
we
have
too
many
combinations,
then
it
will
always
look
bad
in
the
back
ends,
because
there
could
be
a
lot
of
possibilities.
F
E
D
F
But
what
we
do
have
control
is
over
the
specification,
and
I
think
the
specification
should
be
very
clear
about
what
is
the
expected
way
to
do
things
like
if
we
allow
everything
that
it
will
be
such
a
headache
to
ingest
this
data
and
to
do
something
useful
with
it
later.
I
think
the
specifications
should
be
clear
that
receive
spam
should
have
links
and
should
always
be
present,
and
that's
our
okay.
A
I
mean
I,
I
do
a
certain
extent
also
share
this
opinion
because
yeah,
I
think
from
backhand
side.
As
you
said,
I'm
here
it's
kind
of
good
to
have
some
common
ground
that
can
rely
on
in
all
cases.
Basically,
what
is
the
goal
here
with
this
conventions?
What
you
can
rely
on
is
that
you
either
have
a
receive
or
a
deliver
spam,
and
this
will
hold
the
links
and
that's
basically
consistent
across
all
the
cases
that
they
can
can
that
we
came
up
here.
A
I
I
think,
I'm
not
at
all
adverse
to
saying:
okay,
we
can
have
process
bands
and
they
can
be
linked
to
public
spends
tools,
but
I
think
that
should
be
like
an
addition
to
this
receive
and
deliver
spendings
that
we
have-
and,
of
course
I
think
sdks
can
then
provide
options
to
turn
off
this
receive
spend
links,
but
I
think
it's
not
something
that
we
should
endorse
or
recommend
in
the
semantic
conventions.
I
think
that
is
probably
more
like
an
exception
for
very
special
use
cases.
A
A
A
A
I
mean
one
thing
we
could
possibly
do.
It
is
just
an
idea
to
hark
back
to
what
will
offer
that
we
say
okay,
that
kind
of
receive.
That
is
that
we
that
we
have
as
a
shoot.
That's
in
the
spec,
that's
kind
of
we
always
try
to
kind
of
have
this
there,
and
then
we
can.
We
could
like
add,
like
just
an
example
of
here.
F
A
I
mean
I
I
I
also
agree
with
you.
The
army,
I
mean
weird
like
in
in
azure.
We
have
similar
requirements
like
many
users
asks
for
this,
ask
for
this
end-to-end
latency,
but
it's
very
hard
to
define
what
it
is.
As
you
say
like
there's
this,
it's
easy
in
the
one-to-one
scenario,
but
the
other
message
can
be
published
like
to
several
cues,
and
then
you
have
several
outgoing
links
here
or
even
then.
A
F
B
A
D
It's
a
future
requirement
for
us.
We
don't
have
like
we,
we
are
discussing
and
exactly
what
amir
asks.
We
are
also
struggling
to
define
the
end-to-end
latency
like
to
the
customers.
Customers
might
have
so
many
scenarios,
so
it's
it's
very
tricky
to
actually
define
like
what
the
entrance
latency
will
look
like.
E
We
I
heard
some
internal
conversations
about
it
as
well,
and
I
hope
I
don't
disclose
an
internal
information,
but
basically,
since
there
are
very
a
lot
of
hopes
between
the
services
potentially
and
multiple
links
involved
right
on
every
end,
it's
just
impossible,
but
looking
at
spans
alone
to
tell
what
the
antenna
latency
is
and
where
is
the
end?
Okay,
we
can
maybe
say:
where
is
the
start?
E
So
the
way
of
thinking
about
it
I
heard
was
that
maybe
we
will
use
baggage
the
correlation
quantum
distributed
context
that
propagates,
along
with
traces,
those
with
spend,
trace,
parent
and
trace
date.
That
has
some
indication.
Okay.
This
was
a
start
and
okay
that
that
was
an
end
or
it
was
the
next
event
this
the
next
occurrence.
E
But
basically,
you
can't
calculate
tempo
and
latency
by
looking
at
the
traces
in
generic
case,
maybe
only
in
a
simple
case,
and
we
need
some
other
sort
of
signal
and
some
other
identifiers
that
identify
transaction
and
we
would
maybe
need
help
from
customers
to
indicate.
Where
is
the
start,
and
maybe
where
is
the
end?
E
C
A
Yeah
I
like
that
summary
ludmila.
It's,
I
think
also.
We
know
where
in
this
back
here,
we
have
like
this
set
out
as
a
requirement
that
we
want
to
support
end-to-end,
latency
calculations
and
also
think
that's
that's
good
and
feasible,
not
to
add
it
because
yeah,
it's
just
it's,
not
the
it's
not
achievable
by
by
this
messaging
semantic
conventions
alone.
B
I
think
we'll
we'll
learn
much
more
once
we
have
something
out
right
and,
and
people
tell
that
this.
This
is
not
working
or
or
with
more
use
cases,
and
more
and
more,
I
think
I
think
we
can.
We
can
probably
come
up
with
something
right
after
after
some.
Some
of
this
is
already
being
used
and
implemented.
B
B
A
Okay,
so
thanks
for
bringing
it
up
niraj
I
mean
I
think
what
we
saw
is
that
they
have
been
discussing.
What
is
current
model
that
we
set
out
here.
We,
at
least
in
a
discussion
today,
we
were
not
able
to
come
up
with
anything
better,
so
we
didn't
really
solve
the
problem.
We
were
not
able
to
come
up
with
anything
better,
so
we
will
just
probably
stay
with
this.
A
A
That's
it's
good
to
have
still
have
those
discussions,
because
I
think
it
also
helps
us
to
kind
of
yeah
put
the
things
into
question.
India
find
find
the
or
revisit
the
reasons
why
we
came
to
it,
because
I
think
we
will
have
those
discussions
in
in
the
near
future
again
when
we
put
this
into
a
pr
and
try
to
get
it
approved.
A
D
D
A
So
I
put
it
here
for
like
a
variety
of
systems
like
the
different
parts
that
don't
need
to
uniquely
identify
a
destination,
and
they
also
put
how
this
would
basically
map
to
the
existing
semantic
conventions.
Like
just
an
example
for
kafka,
you
would
have
a
list
of
servers
that
would
go
into
the
messaging.url
and
you
have
a
topic
name
and
that
would
go
into
messaging.destination
and
similar
for,
for
for
it's
a
pretty
similar
like
schema
for
most
of
the
systems,
rapid
mq
is
a
bit
different.
A
You
have
to
you,
don't
have
a
url,
you
have
a
project
id
and
then
you
have
a
topic
id
and
prompted
by
duan.
I
also
added
like
mqb
and
mqtt
proper,
and
also
for
those
kind
of
fit
this
kafka
model
or
knows
there.
You
have
a
server
address
for
both
that
would
go
into
messaging,
your
url
and
then
for
for
mqb.
You
have
a
they
call
it
node
name,
which
is
basically
the
keyword
topic
that
would
go
in
the
destination
and
for
mqtt.
A
A
And
this
corresponds
to
the
existing
messaging
destination,
which
is
defined
as
either
queue
or
topic
name,
and
we
say
this
is
a
required
attribute
and
this
captures
the
topic
queue
subtract,
node
name.
However,
you
want
to
call
it
kind
of
this.
This
kind
of
a
last
part
of
the
of
the
hierarchy
that
uniquely
identifies
identifies
the
destination
because
that
can
be
required
because
we
have
something
that
corresponds
to
messaging
destination
in
in
all
those
scenarios.
A
This
is
an
option
attribute
and
that
captures
the
url
or
server
name.
That
is
something
that
we
don't
have
in
all,
but
in
many
scenarios,
mqb
and
qtd
and
all
the
order
scenarios
here,
mr
ms,
is
a
special
thing,
but
basically
that's
something.
We
have
in
almost
all
scenarios
except
the
amazon
and
the
azure
azure
scenarios.
A
E
Sounds
natural
for
those
things
to
be
populated
and
then
for
event,
habit:
service
bus,
don't
worry,
they
have
a
clearly
defined
host
name
and
port,
no
worries
here
then,
if
we
do
this,
we
will
have
consistency
across
different
specs
right
and
I
believe
at
least
most
of
the
systems
will
have
some
notion
of
host.
Even
amazon.
A
E
E
E
A
B
E
So
if
we
have
a
host-
which
I
think
we
should
have,
I
want
to
run
my
queries
against,
let's
say
all
against
okay,
my
my
connection,
the
error
rate
over
this
whole
strike,
but
then,
if
we
have
not
peer
name,
which
is
generic,
where
would
we
put
potentially
some
extra
information,
like
account
name
in
this
endpoint
yeah?
It's
an
interesting
question.
A
A
E
A
I
mean
we
didn't
talk
about
the
exact
semantics
of
netbearp
and
that
pure
name.
Yet
it's
not
100
clear
to
me
yet.
So
that
would
also
be
part
of
this
of
this
discussion.
Whether
we
would
whether
we
want
to
have
both
or
we
can
kind
of
make
it
an
an
either
or
question,
and
we
can
say:
okay,
I
don't
need
to
be
either
one
of
one
or
the
other.
A
It's
it's
specified
as
connection
string,
whereas
I
think
connection
swing.
It's
a
I'm
pretty
sure
that
in
or
it's
a
good
question
actually
better
for,
like
the
when
you,
when
you
just
look
at
maybe
the
most
common,
like
kafka
use
case
where
you
have
a
list
of
servers
of
host
port
combinations.
Where
would
you
put
that?
A
E
E
A
E
A
So
then,
then
look
miller.
Does
it
sounds
feasible
to
you
that
we
say?
Okay,
we
have
a
messaging
destination
and
then
we
have
like
maybe
messaging.
We
have
the
host
that
is
connected
to.
I
think
that's
also
kind
of
common
to
order
scenarios.
Then
that
would
be
part
that
would
be
captured
by
netbearp
and
netpure
name.
E
A
Yes,
that
sounds
that
sounds
great.
Maybe
your
kenya
post
in
the
in
the
comment
here
and
also
correct
anything.
I
got
wrong
here
because
I
think
danielle
should
also
basically
revisit
this
like
messaging.url
kind
of
connection,
like
a
assignment
that
I
did
here,
because
it
seems
you're
not
hundred
percent
correct
there.
I'm
not
sure
if
actually
that
kafka
servers
would
all
go
into
messaging,
url.
A
A
But
there
we
are,
we
are
almost
at
the
end,
so
yeah,
maybe
you
can
you?
Can
you
can
have
a
look
over
this
one
comment
here
and
add
your
thoughts
here.
I
think
we
made
like
some,
at
least
for
me,
some
progress
today
with
figuring
out
the
or
figuring
out
some
kind
of
interdependencies
of
the
messaging
url
and
netbearp
net
peer
name
attributes.