►
From YouTube: 2022-07-28 meeting
Description
Instrumentation: Messaging
B
B
All
right,
so,
let's
take
a
look
at
the
agenda,
oh
yeah,
so
I'm
not
sure
if
we
look
at
the
project
board
every
time.
I
think
we
forgot
last
time
last
time,
but
I
looked
at
now
seems
to
be
up
to
date
we're
talking
about
the
attributes,
I
guess
in
general,
and
just
the
old
type
in
general.
B
What
I
did
change
is
I
created
two
new
items
here,
one
for
this
pr
that
johannes
wanted
me
to
open
to
put
the
text
from
the
old
tab
that
was
merged
into
the
spec.
So
I
added
this
here
and
another
one
for
the
proposed
new
spain
structure
that
johannes
wanted
to
do
it.
I
think
he
said
that
he
will
do
it
probably
once
he's
back
yeah.
C
A
B
B
We
started
discussing
more
about
this
again
about
the
stainless
context
and
if
we
should
create
a
context,
it
would,
if
there's
a
span
or
not-
and
I
I
was
thinking
if
this
out
that
was
merged
now
that
we
need
to
open
a
pr
for
the
spec
if
that
would
be
affected
by
this,
let's
say
unknown
that
we
have
now,
because
I
imagine
that
people
might
ask
this.
B
What
is
this
context
that
you
want
me
to
add
here,
and
I
don't
think
it's
clearly
the
finder
I
I
I
didn't
have
time
to
take
a
look
again
to
throw
it
on
it
today,
but
I
was
just
thinking
if
you,
if
you
yeah,
have
something
in
mind
or
I
I
think
it
might
be
relevant
now
that
we
at
least
have
an
idea
here
before
I
open
the
stack
pr
or
I
can
just
open,
spec
pr
and
start
this
and
leave
the
discussion.
Go
there
either
way.
B
Yes,
because
I
think
in
the
old
tab
here
just
quickly
open
it,
because
I
think
in
delta
app
here
we
said
that
yeah,
there's
this
terminology
and
so
on,
but
I
think
johannes
put
it
in
the
there's.
A
producer
should
attach
a
message
create
a
context
to
spend
each
message,
but
we're
not
it's
a
bit
vague
right.
So
I
think
it
was
on
purpose
actually.
So
we
could
get
away
with
just
putting
this
here
and
and
say
that
we're
still
discussing
this
and
see
the
reaction
there
on
the
spec.
B
C
I
mean
I
added
some
comments
here
last
week
and
or
maybe
it
was
earlier
this
week.
I
forget
where
my
comments
stemmed
from
looking
at
implementing
some
of
the
stuff
in
in
our
broker,
and,
like
I
mean
brokers
more
so
than
clients
are
obvious,
are
very
focused
on
performance
and
scale
issues,
and
so,
like
you
know,
every
bite
of
memory
you
have
to
add
is
a
concern,
and
you
know
so
the
more
free
form
we
make.
C
This
message
creation
context,
the
less
you
can
assume
in
an
implementation
right,
and
so
it
would
be
nice
sort
of
where
I
was
steering.
My
comments
was
that
it'd
be
nice.
If
we
just
said
that
every
s
every
time
you
send
a
message
that
you'll
have
a
span
for
the
for
that
messages,
send
operation
and
that
send
span
serves,
as
this
producer
span
that
you
can
correlate
back
to
on
the
consumer
side.
C
If
we
allow
it
to
be
just
any
context
that
anybody
can
set
anywhere,
you
know,
then
then
you
have
multiple
spans,
that
brokers
might
need
to
track,
and
that's
and
the
contacts
themselves
aren't
that
large.
You
know
it's
for
the
most
part:
it's
like
you
know.
C
The
trace
id
span,
id
and
sampled
flag
are
kind
of
you
know,
25,
bytes
or
whatever,
but
the
trace
date
can
be
arbitrarily
long
and
you
should
support
at
least
512
bytes,
I
think,
is
what
the
spec
says
and
that
and
those
things
like
512
just
kind
of
the
possibility
that
could
be
there
is
a
problem,
and
so,
if
you
have
to
support
two
of
these
512
byte
things
with
two
different
contexts,
it's
a
lot
more
resources
than
if,
if
you
could
insist,
there's
just
one
span
that
serves
the
same
purpose
so
yeah
and
I
don't
want
to
get
too
much
into
the
details.
C
But
that's
where
I
think
it'd
be
nice,
and
I
I
think
that
one
of
that
this
may
have
come
up
a
long
time
ago,
and
one
of
the
big
concerns
was
with
using
a
sense
band
for
something
like
this
was
that
the
sense
man
might
be
a
batch
and
it
might
not
be
unique
to
the
message,
but
I
think
some
of
our
discussions
last
week
we're
taking
us
down
the
path
like
well
geez.
Even
when
we're
sending
a
batch,
you
know
why
don't
we?
C
So
I
I
don't
know
how
much
we
care,
although
I'm
saying,
is
the
more
general
that
we
leave
it.
The
more
restrictions
it
poses
on
implementations,
right,
like
the
more
like
implementations,
have
to
allow
anything
have
to
allow
for
for
multiple
contexts.
B
So
if
I,
if
I
got
it
right
so
I
I
read
this,
I
think
last
week
or
so
I
also
read
it
again
today.
So
if,
if
I
go,
what
would
you
mention
in
point
point
two
here:
is
it's
pretty
much
what
we?
What
the
the
tab
there
says
right
that
you
create
one
one
span
context
for
each
message:
put
it
there
and
that.
C
Is
well
no
like,
but
the
otep
doesn't
say
that
it's
that
it's,
that
is
a
spanish,
it
just
says,
there's
a
context.
It
doesn't
say
the
context
of
the
context.
If
you
will
like
what
it's
a
child
of.
Is
it
an
application
context?
Is
it
like
a
an
sdk,
auto
instrumentation
context,
and
they
so
they
make
they.
C
We
say
nothing
about
how
it
gets
there
and
that
that's
more
ambiguous
than
if
we
said
every
time
you
send
a
message:
it
should
have
a
sense
ban
and
that
messages
sense
span
is
used
to
correlate
producers
and
consumers
like
that
to
me
is
the.
B
C
B
Okay
yeah,
so
for
the
one
message
scenario:
if
we
don't
have
that,
I
think
we
did
have.
I
don't.
I
don't
remember,
but
I'm
pretty
sure
that
we
did
discuss
that.
If
it's
just
one
message,
not
a
badge,
then
the
same
span
is
the
same,
so
you
can
use
the
same
span
and
you
put
that
inside
a
message
and
yeah.
It
always
fine.
I
think
we
didn't
david,
didn't
discuss
this
too
much,
because
it
is
easy
right.
So
there's
there's
no
much
to
to
get
wrong.
I
guess
yeah.
B
So
I
I
believe
there
was
maybe
in
the
old
tap
the
other
one
that
was
married
by
baby,
because
what
I
linked,
I
think,
a
link
a
bit
down
here
is
maybe
yes,
because,
johannes
in
the
display
so
tab
now
it
says
the
grid
for
every
single
message
creates
fans
can
be
created
during
the
publish
can
be
created,
dependent
of
the
publish
and
like
like
we,
we
know
already.
C
B
We
would
yeah
because,
for
example,
the
the
the
create
spam
or
create
context
it
it
can.
It
can
either
be
created
by
the
by
the
application
owner.
So
the
the
the
the
person
writing
the
the
the
code
so
like,
for
example,
you
can
create
a
message
and
create
this
fan
or
as
part
of
creating
the
new
message.
It
already
creates
this
fan
for
you
something
like
this,
for
example,
if
it,
if
the
method
is
just
an
object,
you
say
like
new
my
type
and
as
part
of
this,
the
context
is
created
right.
B
B
I
think
I
think
I
found
it
so
it
says
you
so
publish
pen
should
be
created
for
operations,
provide
the
message
for
sending
or
publish
to
an
intermediary.
A
single
publish
can
account
for
a
single
message
or
multiple
messages.
B
C
B
B
C
B
A
B
Of
on
your
own
right
and
it
you
can
create
the
expense
for
you.
B
It
would
be
nice
to
not
require
people
to
do
this,
because
it's
something
that
it's
like
a
cross,
it's
a
cross,
cut
cutting
concern.
I
shouldn't
know
shouldn't
probably
shouldn't
care
about
this
right
yeah,
but
I
want
to
just
quickly.
I
just
want
to
go
quickly
to
the
agenda
here,
because
I'm
not
sure
if
I
missed
something
yeah
okay,
so
we
can
continue
discussing
because
the
next
thing
I
just
want
to
check
if
somebody
anybody
else
edits
something
else.
B
B
So
what
he's
saying
saying
is
that
the
great
because
we
keep
saying
that
grace
plan
is
zero
duration
right
or
the
great
great
context?
Is
you
do
issue?
But
what
he
means
here
is
that
the
creation,
the
creation
context,
could
also
not
it's
not
necessarily
situation,
because
it
could.
It
could
measure
the
actual
the
creation
of
the
message
right,
for
example,
what
he
says
he
like
there's
there's
some
there's
applications,
and
I
also
draw
an
example
here.
B
For
example,
you
have
an
app
api
or
something
that
receives
a
request
to.
I
don't
know,
schedule
something
right:
a
scatter
birthday
for
a
user
so
like
in.
In
order
to
create
this
message
or
to
to
publish
this
match,
it
needs
some
data
right,
so
it
then
needs
to
grab.
Some,
for
example,
needs
to
grab
the
user
birth
date
here.
B
So
in
this
case,
you
you
could,
for
example,
start
the
create
span
here,
fetch
the
data,
and
then
you
build
the
message
with
the
data
that
you
got
and
then
this
great
span
is
it
says
over,
and
then
you
pass
the
matches
on
right.
So
the
this.
The
thing
that
happens
in
these
two
steps
here
is
part
of
the
creation.
Let's
say
it's
a
great
great
span
here.
B
It's
in
this
fetching
here,
for
example,
could
be
fetching
something
from
the
database
or
something
so
it
could
measure
something
it
could
be
a
like
a
business
operation
that
is
happening
or
caused.
Your
your
application
to
happen,
because
you
receive
something,
then
this
will
create
a
message
as
an
effect
or
something
so
it
it.
It's
got
an
interesting
take
and
it's
not
the
great
space
not
necessary
can
always
be
as
well
as
zero
duration.
I
think
this
is
a
good
argument
that
we
can.
C
I
I
think,
I
think,
for
sure
that
makes
a
lot
of
sense
like
in
because
in
the
case
of
describing
what
the
creation
span
is,
is
a
span.
It's
an
application
span
that
yes
measuring
something
the
context
in
which
the
message
was
created.
I
guess
I
think,
where
the
the
idea
of
createspan
being
is
your
duration
span
came
from,
is
if
an
api
were
to
inject
the
span
as
part
of
a
like
factory,
dot,
create
message
method
right,
that's
just.
C
An
object
maybe
grabbing
something
at
a
pool
or
allocating
some
memory.
It's
returning
an
object,
then
it's
zero
duration,
but
if
the
context
is
a
span
that
is,
is
like
measuring
some
application
operation,
then
I
think
yeah
absolutely
and
in
some
diagrams
that
I
drew
for
like
the
architecture,
I'm
working
on
right
now
show
exactly
that,
like
a
link
back
to
some
application
operation
as
the
creation
span,
I
guess
I'm
just
wondering
how
valuable
that
is
versus
having
a
link
back
to
something
that's
easily
auto
instrumented
right.
It's
not
easy
like!
C
Is
it
like
that's
up
to
the
application,
then,
if
they
have,
if
they
have
the
creation
span,
and
they
have
to
inject
into
the
message,
it's
nice
to
always
have
you
know,
auto
installation,
auto
instrumentation
be
able
to
take
care
of
all
of
the
shoulds
within
the
specification.
That's
sort
of
a
recurring
theme
in
our
discussions
right
is
that
we
like
we
don't
rely
on
the
application
to
create
a
process
span
or
whatever
right.
So
that's
why
we
put
the
link
in
the
deliver,
because
we
don't
know
if
applications
will
create
process.
B
Exactly
yeah,
and-
and
this
is
exactly
what
christian
says
here
so
because
he
says
like-
I
think
there
is
an
argument
for
changing
the
concept
of
creation
to
make
these
stages
more
symmetrical.
B
So
it
kind
of
corresponds
to
like
a
published,
corresponds
to
a
receive
or
a
deliverer,
and
a
crate
should
correspond
to
a
process
which,
which
makes
sense
right.
You
create
something
because
at
some
point
it's
going
to
be
processed,
and
so
what
it
says
is.
I
think
it
makes
sense
that
the
crate
should
track
the
logical
application
level
business
of
creating
the
message
creating
the
data
right
and
in
some
cases
I
agree
that
some
cases,
just
what
you
said
like
it's
just
a
factory
that
just
it's
like
a
I
don't
know.
B
Nano
second
thing
is
to
create
the
the
the
create
the
object,
and
then
you
create
the
spin
as
part
of
that,
then
it's
pretty
much
zero
duration
doesn't
matter,
doesn't
matter
anything
right,
but
if
there
is
some
actually
some
sort
of
business
logic
in
in
relates
to
creating
the
message.
Then
the
great
spin
has
a
little
bit
more
meaning.
B
But
what
he
said
as
well
is
that
the
great
house
could
be
could
be
used
to
this
part
I
didn't
get,
but
if
I
got
it
right,
it
says
that
it
could
be
used
for
for
like
for
acting
that,
the
the
so
this
great
span
could
be
also
be
measured
to
to
use
to
measure
how
long
it
took
until
it
was
act
or
something
but
but
yeah
that's
a
bit
of
of
a
stretch.
I
think
it
sounds
like.
B
A
A
B
A
B
Yeah
yeah,
I
agree,
you
know
it's,
it's
a
yeah,
it's
a
tricky
thing.
I
I
that's
what
I
was
also
thinking
about
the
merged,
app
and
and
how
that
would
look
like
when
we
opened
the
the
actual
pr
in
the
spec
because
yeah,
okay,
we
need
a
context.
It's
it's
clear
that
we,
I
guess
we
all
agree
that
we
need
some
unique
thing
to
be
attached
to
each
message,
but
this
what
it
is
is
kind
of
trickier.
C
Yeah-
and
I
think
one
comment
that
he's
making
here
as
well-
is
that
you
know
there's
kind
of
layers
to
all
of
this.
Like
he's,
I
think
he's
saying,
create
and
process
are
more
tightly
coupled,
whereas
publish
and
deliver
are
kind
of
like
the
lower
layer-
and
I
I
know
we
talked
about
this
and
we
knew
that
creating
the
link
sort
of
from
the
liver
to
the
creation
span
was
sort
of
like
a
weird
thing.
It
should
be
processed
to
creation
span,
which
couldn't
rely
on
that
process.
Yeah.
B
C
You
know
context
like
in
your
your
example:
the
scheduling
a
birthday
there's
some
span,
that's
a
parent,
maybe
of
the
send.
Then
you
know
you're
kind
of
one
parent-child
relationship
away
from
seeing
that
so
it
to
me
and
because
to
me
it
feels
like
what
the
goal
is.
What
I
always
the
way
I
explain
it
to
other
people
is
that
the
purpose
of
this
link
is
to
kind
of
for
for
app
for
use
cases
where
you
don't
care
about
the
transport
level.
Details
of
all
of
this,
like
send,
receives
and
receive
maybe
went
through.
C
Multiple
hops
of
a
transport
could
be.
You
know,
15
20
spans
there.
You
don't
care
about
that.
You
just
kind
of
care
about.
Where
did
it
come
from
it's
a
way
of
bypassing
all
the
details,
so
I
think
I
think,
by
creating
a
link
to
something
that's
at
most
sort
of
one
hop
away
from
that
that
maybe
application
layer
context
is
pretty
good,
and
you
don't
have
this
weird
kind
of
sdk
to
application
layer
link
that
that
I
think
I
agree
to
me.
It
felt
weird.
C
I
understood
why
we
did
it
because
and
but
I
just
wonder
why
we
don't
have
the
per
message.
Send
you
know
spam
that
we
can
link
producers
and
consumers
with.
C
Of
well
so,
if
we
talk
about
a
single
message,
send
it's
just
that
span
right.
It's
a
send
spam
right
and
then
sort
of
what
I
was
proposing
in
my
comment
is
that
well
how
about,
if
you're
sending
a
batch
you
you
don't
create
a
sense
man,
you
create
a
batch,
send
or
send
batch
span
or
some
right
and
and
in
that
you
would.
The
attributes
might
look
a
little
different,
but
it's
stuff
that
applies
to
everything
in
the
span.
C
C
B
But
but
does
does
this
mean,
then
that
in
an
instrumentation
would
because
I
I
saw
your
case
where
you
you
mentioned
that
some
maybe
some
sdks
they
just
the
batch-
is
just
a
like
a
like
a
synthetic
sugar
thing
that
it
just
actually
just
loops
through
the
message
and
do
those
individual
sense.
Something
like
this.
C
C
But
but
I
I
I
was
trying
to
think:
why
would
a
messaging
system
do
it
differently
right?
Why
would
they
treat
treat
it
as
a
batch
as
one
unit
and
I'm
guessing
that's
for
messaging
protocols
that
aren't
streaming
where
you
send
a
batch
and
you
kind
of
do
nothing
until
you
get
an
acknowledgement
and
then
you
carry
on,
and
so
you
use
a
batch
as
a
way.
Instead
of
saying,
send
one
message:
get
an
acknowledgement,
send
another
message:
you
get
an
acknowledgement
which
is
very
inefficient.
C
I
can't
think
of
a
reason
to
treat
the
batch
as
an
atomic
unit
other
than
for,
and
I've
mentioned
this
before,
and
I've
realized
with
the
complications
of
batches,
it's
best
to
limit
the
scope
here,
but
other
than
for
transactional
scenarios
right.
C
But
if
we
were
to
address
transactions-
which
I
think
would
be
nice,
if
this
did
it's
more
complicated
than
just
dealing
with
set
batch
sends
and
batch
receives,
because
what
a
transaction
is,
it's
a
combination
of
from
multiple
producers
and
consumers
all
under
one
session
umbrella,
everything
that's
been
sent
by
all
the
producers
and
consumed
by
all
the
consumers
in
that
session,
as
one
unit
and
that's
like,
and
what
I
like
months
ago
suggested
is
what
batch
then
sounds
like
a
subset
of
the
transaction
problem?
C
A
I
can
give
you
a
few
cases
where
batch
is
not
related
to
transactions
at
all.
I
would
mention
very
weird
reasons
why
people
do
batching
and
in
my
case
we
do
batching
in
a
way
that
we
pack
all
the
messages
from
users
into
one
amqp
message
and
we
send
it
over.
So
we
will
get
back
one
act
and
this
would
do
for
the
bandwidth
consumption
yeah.
And
if
I
talk
about
why
people
do
batching,
one
of
the
very
popular
examples
is
people
receive
a
stream.
A
They
process
messages,
they
must
massage
them
and
they
forward
them
further.
So
they
get
a
batch
of
independent
things.
They
do
something
and
they
just
like.
I
don't
know.
Maybe
they
write
them
to
database
or
something
or
aggregate
or
do
anything
they
also
do
batching
because
they
want
to
save.
For
example,
azure
functions
you
pay
per
executions
and
people
like
to
receive
or
send
batches,
because
they
want
to
save
an
executions
and
do
as
as
little
executions
as
they
can.
C
Yeah,
I
I
agree
with
you,
because
the
other
thing
that
occurred
to
me
is
that
it's
it's
along
the
lines.
What
you're
saying
is
that,
if
it's
very
inefficient
to
pull
and
push
one
message
at
a
time
which
is
what
you're
referring
to
in
a
lot
of
your
scenarios,
whether
it's
bandwidth,
whether
it's
paying
for
execution
or
whatever
it
is,
you
know,
there's
there
may
be
efficiencies
to
be
gained.
C
If
there's
kind
of
you
know
obstacles
in
the
way,
whether
it's
many
layers
of
software
or
a
cost
or
or
whatever
it
is,
I
I
understand,
but
but
it's
it
seems
like.
C
I
mean
for
all
the
for
a
lot
of
those
scenarios.
It
seems
much
very
much
like
a
convenience
thing
of
you
know
like
there's
still
the
individual
messages
or
the
things
that
you're
interested
in
tracing.
Isn't
it
like.
C
C
But,
but
so
I
mean
I
I
I
want
to
tangent
there
a
little
bit
with
transactions
and
and
and
I
don't
mean
to
say
that
the
semantics
would
all
be
the
same,
but
I
think
the
way
you
would
express
a
transaction
is
probably
like
in
terms
of
span
structure.
Everything
else,
I
think,
would
probably
be
fine
for
representing
a
batch
of
producers
or
consumed
messages,
but
maybe
not
like
we.
You
know,
I
I'm
not
suggesting
we
go
there
now
right
like
we
want
to
get
something
done
here.
C
I
think,
is
the
goal
and
we
can
extend
it
later
so
for
sure
I
I'm
not
trying
to
increase
the
scope
or
anything
like
that,
but
I
I
I
feel
like
having
some
umbrella
for
a
batch
for
each
individual
message
underneath
yeah
like
exactly
yeah
what
you're
showing
there
is.
It
makes
a
lot
of
sense.
I
think
this
is
something
we
talked
about
last
week.
That
I
think,
makes
sense.
Our
biggest
concern
was
what,
if
those
individual
message
send
spans
are
kind
of
zero
duration
right.
That's
the
big
concern.
B
So
you
mean,
when
you
say
that
umbrella
and
great
descent,
why
the
same
spin
should
be
the
great
great
context,
you're
saying
something
like
this
right.
So.
C
Like
I
guess,
I
guess,
if
you're
delivering
a
batch
right,
this
is
like
to
mirror
that,
on
the
other
side,
there
needs
to
be
some
individual
span
per
message
being
delivered
as
well,
so
that
you,
because
I
think
the
the
links
from
deliver
to
send
should
be
one
to
one
on
a
message
basis.
B
Because
what
we
have
today
is,
I
think,
it's
something
similar,
but
it's
only
one.
Let
me
just
open
here.
B
I
also
wanted
to
take
some
time
to
go
through
the
documented
ludmina
prepared
now.
But
let's
just
look
at
this
quickly.
B
Right
so
the
yeah,
the
examples
I
think
it's,
I
think
it's
rather
similar
to
what
you're
saying,
but
I
think
the
only
let's
say
semantics
is
that,
instead
of
calling
it
great,
it
will
be
descend
more
or
less,
but,
as
I
said,
it
could
be
that
this
is
also
is
also
just
an
artificial
thing
right.
It
can
just
be
just
like
a
zero
duration
thing
as
well.
B
C
C
Do
we
need
what
are
we,
I
don't
think
we've
defined
anywhere
anything
we
would
put
in
the
createspan.
Have
we.
B
A
B
No
no,
but
I
mean
the
message
id
is
missing.
That's
all
in
this.
C
That's
isn't
that
well
yeah.
This
is
where
we're
talking
about
last
week
is
yeah
in
a
batch,
and
where
do
we
put
the
per
message
stuff
and
exactly?
I
don't
think
the
createspan
is
the
right
place
for
that
either
because
you
probably
don't
know
the
message
id.
When
you
create
a
message
it's
often
assigned
when
you
send
it
right
and
many
many
things
inside
the
message
wouldn't
be
like
you
create
it,
but
then
you
have
to
set
x
set
y
right,
get
it
ready
for
send,
which
is
what
defines
the
attributes.
A
Yeah,
I
I
really
want
to
go
through
about
it
in
my
document.
B
Yeah
should.
Should
I
give
you
presentee
control,
so
you
can
go
through
it
or.
A
A
A
Perfect
yeah,
so
I
just
want
to
reiterate
a
few
approaches
we
talked
about
and
today
and
on
other
occasions.
So
this
is,
the
solution
was
that
we
just
saw
the
publish
span
and
create
message
spans
right.
So
assuming
we
create
a
spam
per
message,
then
we
would
have.
A
So
it
would
be
nice
if
we
could
put
this
attributes
on
links
instead,
right,
so
links
have
attributes,
and
then
it
would
mean
that.
However,
the
context,
however,
this
context
appeared
on
the
message
we
created
this
pen
or
we
created
context
users
created
context.
We
can
associate
publish
spam
and
provide
all
the
details
at
this
time.
Since
the
publish
span
is
created
by
the
client,
sdk
or
author
instrumentation,
maybe
it
should
be
created
at
the
time
when
message
id
is
already
known
right.
B
C
A
So,
first
of
all,
imagine
that
you
like
the
simplest
example.
I
forward
messages
to
multiple
brokers.
I
created
this
message
context
somewhere
on
service
a
and
then
it
was
sent
to
service
b
and
c
and
all
of
them
participated
in
processing
this
message:
they
took
it.
Maybe
they
I
don't
know
aggregated
it
and
sent
forward
right
so
that
when
the
creation
contact,
the
creation
span
is
created,
we
don't
know
and
also
users
might
want
to
say.
A
Okay,
I
don't
know,
I
got
this
item
from
database
and
for
some
reason
I
want
to
use
context
associated
written
on
the
database
with
this
message
that
I'm
sending
forward
right.
So,
let's
separate
context,
let's
give
applications
a
possibility
to
write
their
own
context
on
the
message
right
and
then
we
as
an
instrumentation.
We
don't
need
to
create
this
message
span
every
time,
because
there
is
already
context
on
the
message.
B
B
I
think
the
the
one
of
the
nice
things
I
think
it's
somewhere
in
in
the
document
in
your
in
your
document
when
I
read,
is
that
if
we,
if
we
want,
if
we
require
the
attributes
so
like
the
semantic
attributes
that
we're
defining,
if
we
required
it
to
be
on
the
span
on
the
creates
on
the
grid
context,
then
the
explanation
has
to
add
it
or
the
user
right.
B
B
I
think
right
where,
whereas,
if
you,
if
we
follow
what
the
middle
said
and
let
them
create
the
contact
that
they
put
whatever
they
want,
but
then
we,
when
the
message
is
going
to
be
sent,
then
the
instrumentation
knows
because
it
should
follow
the
spec
right
should
be
if
it
if
he
wants
to
be.
If
he
wants
to
be
open
to
leverage
already,
let's
say
like
that,
then
he
knows
or
should
know
what.
B
C
C
A
B
I
agree
as
well
yeah
I
I
think
I
think
we
we
can
have
a
a
separate,
let's
say
a
separate
trace
for
when
it's
a
batch
and
for
when
it's
a
single
method,
then
I
agree
that
should
be.
On
the
same.
I
think
that
should
be
fine
right
to
have
two,
let's
say
branches,
of
of
ways
of
doing
things.
A
A
You
get
one
from
user
and
you
can
link
to
it
or
you
create
one
unique
context
yourself,
and
then
we
seem
to
stay
cost
effective
from
telemetry
collection.
Standpoint
would
create
less
spans,
it's
less
verbals.
C
So
yeah
my
opinion
on
this
is
that,
if
my
to
my
understanding,
this
kind
of
isn't
necessarily
a
legal
thing
to
do,
according
to
you
know
the
current
open
telemetry
specifications
and
it's
best,
we
shy
away
from
from
things
like
that.
C
B
In
this
it
is
spot
because
it's
just
an
object
or
some
blob
of
data
right,
but
but
I
think
the
real
problem
is
that
nobody
links
also
probably
is
the
same,
but
I
don't
think
anything
you
will
will
be
able
to
understand
this
right
or
to
produce
any
any
meaningful
traits
with
this
today.
B
All
right,
I
think
you
had
some
screenshots,
I
guess
but
we'll
get
to
it.
A
Yeah,
we
can
also
click
through
jager,
but,
like
I
wanted
sorry,
the
the
one
thing
I
had
in
mind
that
maybe
if
this
is
so
bad-
and
this
is
so
illegal
and
people
don't
agree,
and
if
maybe,
if
it's
too
hard
for
backhands
there
could
be
an
event
or
that
notifies
about
it,
which
event
is
a
zero
duration
span
like
it's
from
the
data
structure.
They
are
different,
but
semantically
they
are
the
same.
C
A
B
A
A
Right
which
attributes
right?
How
do
you
name
them
like
things
like
that
right
so
like
there
is
a
there
is
no
convention
and
we
can
go
and
create
convention
right.
So
regard
like
my
point
is
there
is
a
lack
of
mostly
spec
work
for
each
of
these
problems
right,
it's
not
an
implementation
problem
or
api
problem.
It's
like
the
spec
does
not
define,
does
not
legalize
things
like
that.
B
But
I,
but
I
didn't
get
with
the
what
you
meant.
Maybe
I
didn't
understand
with
the
semantics
for
the
span
events
so,
for
example,.
A
B
Like
in
this
case,
for
example,
at
your
show,
you
have
the
publish
stand
and
then,
for
example,
if
we
don't
want
to
have
a
context
or
a
spin
whatever,
then
we
just
add
events
for
for
the
message
specific.
So
the
message
message
specific
attributes.
We
add
events
to
this
published
then,
but
the
problem
is
that
you're
saying
that
it's
since
it's
not
a
link
right,
then
there's
no
way
for
you
to
navigate
between
those
right.
A
B
B
Because
the
the,
if
we,
if
we,
if
we
add
events
to
the
to
the
publish
span
each
event,
for
example,
if
each
event
represents
some
asset,
that
we
can
add
the
method
attributes
like
this,
this,
the
the
attribute
key
that
we're
defining
here,
we
can
add
those,
for
example,
message
id.
We
can
add
those
to
the
span
event
right
and
that
should
be
okay.
A
C
A
And
like
the
last
option,
I
also
is
just
to
entertain
that
we
can
have
hooray
on
the
published
span,
but
I
think
we
all
agree.
This
is
not
the
great
choice,
maybe
it's
some
very
edge
case
like,
for
example,
if
messaging
system
does
not
support
context,
propagation
and
I'm
aware
a
couple
of
them
that
don't
maybe
this
could
be
like
the
best
experience
we
provide.
But
let's
not
talk
much
about
it.
B
A
Okay,
so
the
the
demo,
so
we
can
also
click
for
vigor.
So
I'm
aware
of
two
back
ends
that
support
links
it's
jager
to
some
extent
and
azure
monitor.
So
this
is
maybe
now
so.
This
is
the
process
part.
A
B
A
A
Right,
yeah,
yeah
and
message
it's
referenced
by
by
send
from
this
view,
like
from
the
upstream
from
message.
Jager
does
not
allow
me
to
navigate
to
the
processing
so
references
here.
They
are
actually
it's
the
the
child
of
ambient
context
and
it
has
a
link
to
message
right.
So
if
even
if
those
two
were
in
different
contexts,
they
would
be
correlated.
But
anyway,
I'm
related.
A
B
A
A
parent
shell,
okay,
so
we
saw
the
approach
was
spam
per
message.
So
let
me
show
you
the
the
context
per
message
but
now
span.
So
we
start
at
the
same
place.
Consumer.
A
A
So
if
I
click
it,
it
brings
me
to
the
trace
id
which
it
knows,
but
there
is
no
span
id
right,
so
it
doesn't
find
it
didn't,
find
the
span
id.
And
here
what
I
see
there
is
a
send
and
it's
this
the
proper
ambient
context
and
yeah.
I
cannot
go
from
here
to
the
consumer,
but
I
couldn't
anyway
right
because
it's
just
how
yogurt
works.
It
doesn't
have
any
indexing
process
at
all.
B
B
B
C
Yeah,
I
think,
isn't
it
hard
that
it's
hard
for
the
user
to
find
it
on
the
producer
side
right
like
it,
it'll
take
you
to
the
trace,
but
if
that
was
a
very
long
trace
in
itself
and
hard
to
figure
out
where
in
that
trace,
the
the
similar
reference
was,
you
could
go
searching
for
it,
but
it's
not
very
yeah.
I
guess
not
very
user
friendly
right,
it's
possible,
but
it's
not
very
user
friendly.
A
B
A
B
A
But
yeah,
so
still,
this
is
the
question
of
navigation
and
ui,
so
the
jager
could
have
a
ui.
That
brings
you
to
this
and
because
it
knows
where
this
message
was
sent
from.
C
Like
what,
if
that,
I
guess,
if
there's
two
rough
references
like
one
and
two
one
in
each
trace,
that
has
a
reference
to
the
same
non-existent
span,
then
that's,
I
guess
it
could
maybe
in
fury
or
interested
in
this.
But
if
something
in
this
trace
had
you
know,
if
there's
five
different
spans
that
all
had
a
reference
to
this
same
context,
which
of
those
five
are
you
interested
in.
A
A
B
A
A
B
Yes,
no,
but
I
mean
from
from
from
the
options
we
have
like
having
the
having
the
full
flash
to
span,
seems
that
the
most
fast
way
for
for
people
to
to
implement
better
searching,
better
uis
right.
But
it
comes
with.
B
That's
just
my
assumption.
Right,
yeah.
A
Yeah
so
I
I
asked
someone
on
our
portal
team
to
to
give
me
some
rough
idea
of
how
what
would
be
the
difference.
The
person
is
sick,
so
they
they
can't
reply
yet,
but
let's
see
what
they
say.
B
A
B
A
The
line
of
code
because
I'm
really
curious
now
well,
I
have
that
in
sdk
instrumentation
I
don't
have
a
codebursa.
A
B
Yeah
but
like
there
is
this
context,
something
that
you
create
manually
or
you
just
use
any
existing,
let's
say
hacky
eye
or
something
because,
for
example,.
A
Okay,
so
this
is
my
code.
Let
me
remove
all
the
irrelevant
things
here,
so
this
is
irrelevant.
So
I
create
the
service
bus
message
so
how
our
sdk
works,
that,
if
I
add
the
context
and
the
message
then
it
it
works,
then
it
does
not
create
a
per
message
span.
A
So
I
faked
this
context
here,
but
I
can
in
dot
net
we
call
activity,
expand
context
activity
context,
so
this
is
how
I
create
it.
So
this
is
my
spam
context.
A
So
in
java
it's
a
bit
more
interesting
because
you
can
create
spam
context,
but
you
need
to
generate
random
things
yourself,
which
not
super
straightforward,
but
if
but
instrumentations
should
be
able
to
do
this
and
like
given
some
idea
how
to
do
random
properly.
It's
just
enough
to
to
do
the
thing
right.
C
B
Had
like
the
the
parent
was
there,
if
you
created
this
new
context
and
used
the
trace
id
from
the
parent,
would
they
be
better
linked
and
when
you
click,
he
goes
to
the
correct
one.
B
Like
because
in
in
your
in
in
your
jager
example,
the
the
message
or
the
the
spaying
next
context
came
from,
went
to
nowhere
right.
But
if
you
create
this,
so
this
line
27
that
you
have
now.
If
you
create
that
and
as
as
trace
id
you
get
that
recently
from
the
parent
activity.
Is
it
linked
better
then
or.
A
So
this
is
currently
follows
my
parent
activity
right,
so
I
created.
B
A
And-
and
this
is
my
parent-
the
ambient
context
right
and
I
create
a
child
of
it,
so
it's
got
a
bit
convoluted
but
anyway,
so
this
is
the
activity
face
id
yeah,
so
you
see
I
I
use
my
parent
tracing.
It
doesn't
have
to
be
right.
Even
if
it's
created
in
a
different
context,
the
different
trace
id
linking
would
still
work.
A
B
A
Yeah
and
I
wanted
to
quickly
show
you
what
applications
the
azure
monitor
portal
provides
the
half
indexing
so
and
my
idea
was
okay,
how
broken
this
experience
would
be
without
a
spend.
We
should
assume
it's
broken
right,
it's
not
expected
to
work
and
it
will
need
change.
Of
course
they
wanted
to
show
you.
So
this
is
how
the
proper
thing
looks
with
span.
So
we
have
this
ambient
context.
We
have
a
message
here.
A
A
This
is
a
processing
message
and
it
has
a
link
to
this
message
and
then
this
is
just
a
fake
time
spent
in
queue
thing
and
all
the
times
here
doesn't
matter.
Okay,
and
this
is
actually
a
sent
call.
Maybe
there
are
better
ways
to
show
it,
but
it
shows
all
the
information
and
it's
linked.
A
A
But
you
see
all
the
spans
are
still
here
and
they
are
correlated,
and
my
assumption
is
that
even
without
much
work
on
the
back
end,
it
should
be
doable.
But
I
will
get
confirmation
from
our
folks
on
this
and
we
should
probably
ask
more
people
and
see
how
it
will
go.
I
hope
amir
can
provide
us
more
insights
because
he's
working
on
the
back
end
too
yeah.
B
Do
try
to
do
something
yeah
probably
need
to.
It
would
be
good
if
there
is
a
a
small
app
to
just
try
it
out
things
and
and
see
how
I
would
but
I
I
can
try
to
try
to
do
something
like
it.
It's
similar
and
see
how
it
looks
like
us.
A
C
Sorry,
so
what
you,
what
you'd
like
to
do
is,
if
is
conceptually
treat
two
links
to
the
same
missing
thing
as
effectively
a
link
to
each
other?
Is
that
kind
of
what
and
but
that's
what
the
back
ends
kind
of
don't
do
right
now.
A
So
there
are
options
right.
So
what
we
know
there
are
two
things
that
link
to
the
same
thing:
that's
missing,
right
and
backhands
can
understand.
We
can
have
some
semantics,
then,
okay,
there.
Now
this
is
a
messaging
semantics
that
if
we
write
spec
this
way
we
give,
but
if
then
backhands
would
be
prepared.
Okay,
we
have
we,
we
can
have
context
without
a
span
and
we
can
have
two
things
or,
and
things
link
into
this
context.
C
I
guess
the
problem
with
having
it
be
a
span
is
like
what
what
like
there's
it
spans,
have
certain
required
things
like
a
name
and
a
start
time
and
then
time
and
now
we're
saying
well,
you
have
to
represent
the
span
without
things
that
are
required,
and
so
you
have
to
come
up
with
a
new
concept.
C
Really,
it
feels
like
what
we're
really
trying
to
do
is
create
a
link
to
the
it's,
an
awkward
way
of
creating
a
link
to
that
afraid
of
the
message
span
or
the
thing
like
the
thing
on
the
side
that
had
the
link
we're
trying
to
create
a
link
to
that
span,
at
which
point
like.
Why?
Don't
we
just
create
a
link
to
that
spam?.
A
B
A
B
C
C
A
B
C
B
Right
put,
or
is
it
just
like
its
purpose
is
just
so
so
it's
able
to
link
or
like
like,
for
example,
the
attributes.
Where
would
we
put
the
attributes
on
on
links
then,
and
not
not
in
this
context,
right.
A
B
B
A
B
B
A
connection
between
between
them,
but
on
the
consumer,
you
don't
need
the
attributes
right,
because
that
I'm
thinking
that
after
after
it
goes
through
the
producer
in
the
consumer,
then
you
don't
have
much
chances
of
getting
the
attributes.
Or
I
mean
you
you,
I
guess
you
have.
You
just
have
to
read
the
message
and
then
and
then
put
the
attributes
again.
I
guess
yeah.
A
B
Right
well,
we
are,
we.
Are
we
passed
10
minutes
now?
I
don't
want
to
haunt
you
too
much
all
right.
I
I
think
we
need
to
probably
continue
this
I'll
see
if
I,
if
I
can,
if
I
can,
if
you
can
share
the
app,
I
don't
know
how,
but
we
can
talk
on
slack
or
I
can
also
do
something.
That's
not
a
problem
and
then
I
can
try.
B
I
can
try
something
internally
and
also
maybe
try
to
get
some
feedback
on
this.
If
this
is
something
that
yeah,
it's
completely
frowned
upon
right
now,
right.
A
B
To
gauge
things
today,
I
have
no
idea.
A
Yeah
me
neither,
I
can
share
the
app
do.
You
have
treasure
subscription.
B
B
B
Yeah,
thanks
for
preparing
to
talk
more
in
the
the
the
demos,
was
really
helpful.