►
From YouTube: 2023-02-13 meeting
Description
Instrumentation: Messaging
A
B
B
Definitely
want
to
go
to
what
Amir
put
on
the
agenda
the
link
semantics
that
he
was
working
on
because
that's
on
there
that's
on
there
for
quite
some
time
now
and
we
never
got
to
it.
So
I
definitely
would
like
to
talk
about
that
today.
B
I
would
also
like
to
go
over
open
comments
on
the
old
tab
and
this
one
for,
like
some
questions
about
attributes,
I
think
that's
better
to
reserve
for
Thursday,
because
good
Miller
should
be
there
and
also
Tyler
put
the
point
on
here
on
to
the
agenda
clarifying
goals
for
messaging
sick
Maybe.
B
Maybe
we
can
start
out
with
that
and
then
Amir
I
would
like
to
time
box.
Maybe
the
last
30
minutes
to
talk
about
your
what
you
have
worked
on
for
links.
If
that
sounds
okay
for
everybody,
and
we
can
start
with
this
document
here,
the
Tyler
you
were
working
on.
C
Yeah
so
based
off
of
our
discussion
last
week,
I
felt
like
I
needed
to
kind
of
write
down
some
of
what
I
was
hoping
to
achieve
in
this
sig
and
I
feel
like
these
are
a
fairly.
You
know,
broad
overview
of
what
I
think
we
should
be
trying
to
achieve.
C
You
know,
100
of
the
use
cases,
but
I,
don't
think
that
we
should
be
trying
to
do
so
as
I
I
think
it's
okay
to
have
you
know
special
cases
or
edge
cases,
but
as
long
as
we
can
agree
on
what
the
the
default
broad
youth
Behavior
should
be,
then
I
think
that
we
can
generally
provide
a
good
experience
for
most
users,
the
the
primary
one
being
that
we
should
prioritize
parent-child
relationships
over
span
links
for
primary
message,
processing
in
hopes
to
allow
for
a
single
trace
across
multiple
hops
within
a
data
processing
pipeline.
C
I'm
talking
about
the
general
I
I'm,
not
talking
specifically
about
processing
spans,
because
I
I
didn't
really
take
that
formalization
I
I'm
speaking
more
in
in
Broad
terms,
saying
that
when,
when
looking
at
the
perspective
of
user
application
code
process
being
executed
across
multiple
different
steps
within
a
data
pipeline,
the
logic
that
the
the
user's
code
is
the
the
the
trace
that
is
being
captured
for
all
of
those
different
steps
should
generally
be
in
a
single
trace.
C
I'm,
not
necessarily
denoting
a
processing
span.
Or
you
know
the
the
consume.
The
receive
the
any
of
those
distinct
spans.
I
I'm,
trying
to
take
a
a
higher
level.
View
here.
B
A
B
C
C
And
so
one
of
the
let
me
let
me
cover
this
next
Point
really
quick
I
understand
that
this
is
very
difficult
in
a
lot
of
places,
and
so
what
I
wanted
to
do
for
us
to
enable
this
for
a
lot
of
instrumentation
is
the
second
point
of
providing
an
interface
or
some
layer
of
abstraction
that
users
can
Implement
in
their
code
to
make
it
easy
to
denote
that
okay
I'm
processing
an
individual
message.
C
Basically,
we
are,
we
would
take
up
the
slack
where
Frameworks
don't
provide
easy
mechanisms
for
that
single
message:
processing
semantic.
C
C
Does
that
make
sense,
I
mean
it
could
be
something
like
you
know.
They
add
an
annotation
like
in
a
Java
class
or
they
they
Implement
a
processing
class
that
is
based
off
of
some
interface
that
we
provide
and
that
would
be
published
as
a
consumable
dependency
that
they
use
directly
in
their
code.
A
C
I
and
I
get
that
and
that's
why
I'm
saying
you
know
this:
this
would
work
I
think
for
the
users
that
are
willing
to
modify
their
code,
but
I
I
accept
that
there
are
cases
where
users
can't
modify
their
code,
and
so
we
need
to
have
a
reasonable
fallback,
and
that's
where
I
am
willing
to
accept
that.
Okay,
we
can
fall
back
to
spend
links
when
necessary.
A
Yeah,
like
I
totally
support
like
adding
a
way
to
to
add
the
processing
into
the
applications
like
I,
think
it's
needed
and
I
think
the
processing
span
is,
has
a
lot
of
value
regarding
the
parent
child,
like
my
personal
opinion,
that
a
specification
should
allow
both
and
not
recommend
on
one
option
versus
the
other,
just
let
the
instrumentation
Library
choose
or
be
configured
to
to
allow
both
of
them.
I
think
there
are
a
lot
of
issues
where
it
might
be
problematic.
A
For
example,
if
the
instrumentation
Library
supports
both
a
batch
and
a
single
message
consuming,
then
the
shape
of
the
traces
might
look
different,
depending
on
which
operation
is
invoked
right
if
we
default
to
to
always
having
the
parent-child
relationship
also
I
think
mentally.
Some
people
treat
traces
like
following
the
execution
of
the
code
and
this
using
a
parent
child
instead
of
link
will
break
this
mental
model
right
because,
like
they
know
that
after
receive,
they
should
have
seen
the
process,
but
suddenly
it's
not
there
and
it
just.
A
It
just
creates
some
templates
of
of
traces
which
are
different
and
another
issue
like
if,
if
we
link
the
process
with
the
create
right,
then
after
we
create
a
message,
there
might
be
like
a
downstream
operations
like
sending
the
messages
with
HTTP
to
the
to
the
intermediate,
or
maybe
maybe
the
intermediate
or
itself
is
instrumented
and
like
the
generated
traces.
They
look
weird
they
look
like
and
like
they're,
not
connected
correctly.
Do
you
understand
what
I
mean
like
like.
A
B
Come
back
to
that
because
I
have
an
image
like
a
diagram
of
that
in
the
Otep,
but
maybe
Tyler
can
you
go
through
the
remaining
points
and
then
I
I
have
some
similar
kind
of
goals
in
the
Otep
summarized
as
the
motivation
for
the
current
old
step
and
then
maybe
I
will
go
through
those
and
we
can
compare
and
also
go
back
to
armiest
point
what
he
brought
up
today.
But
maybe
can
you
like
summarize
first,
the
remaining
three
points.
C
Sure
so,
in
summary,
you
know
we
should
default
to
using
parent
child
relationships
when
that's
not
possible
through
the
standard
interfaces
of
the
the
frame
framework.
We
should
provide
a
way
to.
You
know,
allow
the
users
to
do
so
easily
in
so
there
are
exceptions
where
you
know
single
best.
Semantic
processing
just
doesn't
make
sense,
I
think
the
primary
one
is
in
a
fan
in
scenario,
and
so
like
you're
getting
a
batch
of
messages.
C
C
C
C
We
want
to
force
a
separate
trace
and
so
like
allow
users
to
configure
such
or
add
a
heuristic
configuration
or
some
way
to
denote
that
we
should
break
the
trace
and
instead
of
doing
parent-child,
do
the
span,
link
and
start
a
new
Trace
so
give
users
that
control
and
then
finally,
if
the
the
single
message
semantics
can't
be
handled,
for
example,
like
Emir
said,
a
user
is
not
able
to
modify
their
code,
then
we
need
to
have
a
reasonable
fallback,
and
in
that
scenario,
I'm
fine,
accepting
span
links
and
more
independently
broken
traces.
B
Okay,
I
will
shortly
go
over.
What
we
have
summarized
do,
you
think,
is
a
bit
similar.
It's
not
that
that
nicely
split
up
in
bullet
points,
but
it's
basically
here
in
this
paragraph
that
kind
of
summarizes
the
requirements
that
went
into
this
Otep
and
I
mean
the
first
one
is
yeah
being
able
to
calculate
some
end-to-end
latency
of
processing,
a
message,
and
we
also
have
here
the
intermediaries
in
between,
like
the
Brokers
and
if,
inter
Brokers,
if
Brokers
are
not
instrumented.
B
This
should
not
impact
the
correlation
of
producer
and
consumer
stages
and,
on
the
other
hand,
if
Brokers
or
intermediaries
are
instrumented,
those
these
instrumentation
should
seamlessly
integrate
with
what
is
already
there
like
what
we
prescribed
here
in
this
old
tab,
so
intermediary
instrumentation
broker
instrumentation
is
out
of
scope,
but
if
it
should
be
possible
to
kind
of
integrate
that
seamlessly
somehow
with
the
producer
and
consumer
instrumentation
that
we
are
gonna
propose
here
and
we
are
also
integrating.
B
The
broker
should
not
require
any
changes
in
producer,
consumer
instrumentation,
and
it
should
not
change
the
relationship
between
producer
and
consumer
spans.
So
if,
for
example,
your
Kafka
broker
is
instrumented
your
trace
of
your
traces
from
the
consumer
and
the
producer
point
of
view,
the
spans
should
still
correlate
in
the
same
way.
Otherwise
SEI
you
kind
of,
have
see
very
different
results
depending
on
whether
the
protein
the
media
is
instrumented
or
is
not
instrumented,
and
then.
B
Lastly,
what
we
put
here
is
that
here
we
want
to
enable
sdks
messaging
sdks
to
provide
out
of
the
box
instrumentation
for
messaging
I
mean
we
see
that
with
I
mean
granted.
Http
is
like
less
complicated
case,
a
less
complex
case
in
terms
of
span
structure,
but
the
oven.
When
one
looks
at
HTTP
instrumentation
out
there
I
think
most
of
it
is
actually
coming
by
Auto
instrumentation.
It's
a
few
people
are
manually,
instrumenting
HTTP
course
most
is
done.
By
already
like
open
development,
integration
into
libraries
and
yeah.
B
The
goal
would
be
to
enable
something
similar
for
messaging.
That
kind
of
you
trust
your
have
your
messaging
SDK,
you
activate
open
Telemetry
and
you
get
like
saying
experience
out
of
the
box,
so
that
were
basically
our
like
our
main
goals
or
ideas.
Yeah,
you
should
be
able
to
have
some
kind
of
end-to-end
latency.
You
should
be
able
to
integrate
the
intermediary
instrumentation
and
yeah.
B
It
should
work
out
of
the
box
with
auto
instrumentation
for
or
with
already
instrumented
sdks,
without
any
further
need
from
from
the
from
the
user
to
instrument
and
the
to
go
quickly
to
amuse
point.
I
think
it's.
B
This
is
this
kind
of
complex
example.
We
have
here
where
there
is
basically
an
intermediary
like
a
broker
in
between
the
producer
and
the
consumer,
and
this
would
be
like
an
example.
Integration
I
mean
this
is
in
future
possibilities.
So
that's
not
really
like
specced
out
in
this
Otep,
but
idea
would
be
here
that
this
intermediary
somehow
integrates
with
producer
and
consumer
instrumentation,
without
kind
of
really
interfering
or
breaking
with
what
they
come
up
in
this
in
the
cell
tab
and
here
in
this
example,
it
works
because
here
we
prescribe
links.
B
So
we
have
the
producer
and
consumer
linked
here
and
basically
the
intermediaries
kind
of
integrated
here
with
parent
trial
relationships.
C
Right
so
going
back
to
my
document,
like
my
my
take
on
this,
is
I:
don't
really
have
strong
opinions
on
what
the
intermediate
intermediary,
how
that
is,
participating
within
the
trace
as
long
as
the
user
application
that
produced
the
the
message
is
part
of
the
same
Trace
as
the
processing
of
the
message.
So
let
me
know
that's
my
main
thing.
C
Because
I
think
it
results
in
a
much
better
experience
for
for
most
users,
where
you
know,
if
you're
looking
at
something
like
a
Zipkin
where
you've
got
where
you
select
a
trace,
you
you
want
to
be
able
to
see
all
of
that
processing
within
one
view.
Instead
of
having
to
select
individual
traces
and
try
to
understand
their
relationships
via
the
span,
links.
B
I
mean
we
had
discussions
similar
discussions
at
the
beginning
when
we
started
working
on
that
and
I
mean
the
conclusions
we
came
to
regarding
that
point.
Is
that
the
basically
from
open
Telemetry
point
of
view,
links
in
permanent
type
relationships
are
kind
of
those
first
class
citizens,
so
links
and
child
relationships
are
part
of
the
outlets
back.
However,
the
situation
looks
differently.
When
you
look
at
the
currently
existing
backhands,
so
I
think
sipkin
I,
don't
know,
I
think
it
has
a
very
rudimentary
support
for
links.
B
Jaeger
has
support
for
links,
but
it's
also
rudimentary.
So
you
cannot
really
visualize
that
in
the
same,
in
the
same
view,
at
the
last
time,
I
look
doesn't
support
Links
at
all,
Azure
Azure
monitor
the
Azure
solution
has
pretty
good
support
for
links,
so
they
basically
they
kind
of
have
an
integrated
view
where
you
can
actually
see
the
link.
Trace
is
kind
of
expanded,
so.
B
Expand
links
influenced
the
way
sampling
is
done.
That
depends
on
not
necessarily
I
mean
that
depends
on
how
you
how
you
sample.
What's.
C
That,
well
that's
what
I'm
saying
is
like
I
I,
think
that
it's,
it's
not
quite
honest
to
say
that
span
links
have
the
the
same
level
of
support
within
open
Telemetry.
As
you
know,
parent-child
relationships,
because
sampling
is
done
generally
based
off
of
the
trace
ID
and
by
virtue
of
them
being
separate
traces.
Therefore,
any
sampling
that
happens
is
going
to
result
in.
C
You
know
a
decent
chance
that
different
parts
of
the
trace
are
going
to
be
completely
missing
when
using
span
links.
C
B
Mean
I
I
think
the
point
here
is
that
there
is
no
like
out
of
the
box
sampler
yet
provided
by
open
Telemetry.
That
kind
of
has
like
a
link
there.
That
has
awareness
of
links.
I
mean
there
is
I
know
of
like
projects
that
Implement
custom
Samplers
I
mean
when
I
was
working
on.
That
basically
takes
does
the
same
as
like
the
current
parent-based
sampler,
but
also
takes
links
into
account.
B
So
I
agree
there
is
that
there
is
nothing
yet
provided
by
open,
Telemetry
out
of
the
box.
So
what
about.
A
B
I
was
referring
to
when
I
said,
both
the
first
class
citizens,
they
for
sure
their
differences
between
them
too,
but
they
are
first
get
citizens
from
the
modeling
point
of
view.
So
it's
not
an
open
Telemetry
says:
okay,
yeah
permanent
child
relationship
is
generally
kind
of
preferred
or
link
is
just
like
a
fallback
for
certain
scenarios
and
like
one
kind
of
direction
that
we
then
took
when
we
came
up
with
those
with
this
proposal.
Here
is
that
they
said:
okay,
we
we
don't
want
to
design
around
shortcomings
of
current
backends
that
are
out
there.
B
I
mean
we.
We
assume
that
support
of
links
will
improve
in
the
future.
That
links
will
be
used
more
and
more.
We
already
seated
now
and
we
assume
that
backhands
will
catch
up
and
provide
better
support
for
links,
and
that
also
was
one
more
or
less
thought
we
had
in
mind
when,
when
coming
up
with
the
design
in
that
document,
so
I
agree
that,
when
you
kind
of
want
a
solution
that
works
optimal
in
our
backends,
now
that
that
that
parent
trial
relationships
might
be
a
better
solution.
B
C
So
maybe
you
could
help
me
understand.
You
said
that
Azure
side
of
things
has
a
decent
support
for
span
links.
Maybe
in
a
future
meeting
you
could
maybe
give
an
example
or
a
demonstration
of
the
way
that
that
works.
B
So,
let's
see
I
think
here:
I
will
send
you
a
link
to
this
blog
post.
That
is
what
lootmiller,
what
Luke
Miller
wrote,
and
this
is
about
Azure,
SDK
instrumentation
and
about
azure,
and
here
you
will
see.
C
B
C
Copy
this
link
into
the
the
meeting
notes,
I.
B
Will
copy
the
link
in
the
meeting
notes?
And
yes,
so
you
have
information
about
links
and
you
see
like
a
screenshot
here
and
basically
you
see
the
this
one
here
and
this
process
pane
here
and
those
two
are
linked
together
and
here
in
between
you
have
this
time:
spending
queue
that
is
calculated
on
a
on
the
link,
but
yeah
I
will
send
you.
B
So
that
I
mean
that
was
one
of
our.
That
was
one
of
our
plots
that
he
said.
Okay,
we
don't
want
to
to
design
around
limitations
that
are
currently
there
on
the
back
end
implementation
site,
but
we
just
want
to
model
something
that
that
makes
the
sense
and
is
most
flexible,
with
with
the
with
the
current
open
Telemetry
kind
of
span
data
model
and
also
mean
one
main
main
goal
for
this
version.
One
here
that
they
come
up
with
I
mean
that
what
I
think
what
is
in
this
old
tab?
B
That
is
not
to
be
meant
to
be.
The
final
word:
it's
meant
to
be
stable,
but
it's
meant
to
be
extensible
and
there
is
definitely
thoughts
to
add
some,
maybe
recommendation
or
specifications
about
intermediary
instrumentation.
On
top
of
it.
There's
there's
people
who
are
interested
in
that,
but
I
think
there's
also
room
for
for
adding
processing
instrumentation
on
top
of
that
service.
B
The
with
what
we
have
currently
here
in
this
PR
I
think,
if
some,
if
some
implementer
or
some
messaging
SDK
here
some
users-
that's
okay,
but
they
want
to
have
all
my
process
plans
try
children
of
this
published
span.
B
That
is
definitely
possible
to
do
without
kind
of
violating
what
they
came
up
here
in
this
Otep.
So
that
is
also
one
thing
that
is
that,
okay,
with
this
first
shot
here,
there
are
still
many
unknowns
out
there.
We
want
two
kind
of
also
limit
instrumentals
and
users.
We
want
to
put
as
few
limits
as
possible
on
them
and
provide
like
the
a
basis
that
is
very
flexible
for
adding
other
stuff.
On
top
of
it.
C
Again
without
the
desire
for
flexibility-
and
you
know
a
lot
of
that
stems
from
needing
to
or
or
wanting
to,
you
know,
support
all
of
the
different
ways
that
messaging
systems
model
things
and,
as
a
result,
I
feel
like
that
it
loses
some
of
the
the
the
ease
of
understanding
in
the
process
like
you
can
make
something
super
flexible,
but
then,
as
a
result,
it
it
loses
some
of
the
the
richness
and
the
meaning
in
the
Pro
anyway.
B
Yes,
I
think
that
is,
that
is
the
conundrum
that
we
have
here.
I
mean
we
be
vote
of
course
like
to
like
specify
here
something
that
gives
like
a
rich
experience
in
in
every
case,
but
it's
hard
to
specify
something
in
general,
where
we
say
okay,
this
is
this
is
the
solution,
and
this
provides
like
a
rich
experience
in
every
case,
but
then
you
have
some
kind
of
SDK
or
some
messaging
system.
That's
something
different
and
you
make
it.
B
Then
you
make
it
impossible
for
this
system
to
kind
of
provide
anything
that
conforms
with
open
Telemetry.
So
here
our
approach
is
more
that
we
say:
okay,
we,
we
trust
here
we
specify
the
minimum
the
minimum,
that
is,
that
can
be
consistent
across
messaging
systems
that
allows
backends
reliably
to
correlate
producers
and
consumers,
and
we
then,
on
this
basis,
individual
messaging
systems
or
at
sdks
can
build
more
richer
or
can
build
richer
experiences.
On
top
of
that,
but
I
think
it's
a
bit
of
a
different
approach
than
what
you
had
you.
B
And
we,
basically,
when
we
came
up
with
this,
we
came
from
the
more
like
bottom-up
route.
We
say:
okay,
here
is
just
the
basics
that
everybody
should
be
able
to
do.
That
is
expected.
That
should
be
a
consistent
experiences
across
all
messaging
systems.
That's
something
that
backhands
can
rely
on
and
then,
on
top
of
that
kind
of
you
can
build
your
additional
capabilities
that
bring
you
as
close
to
this
ideal
solution,
as
you
can
get.
C
You
pasted
an
image,
you
explain
that
really
quick
and
then
I
think
we
can
shelf
this
discussion
and
continue
on
to
amir's
thing
like.
A
If
we
use
spell
and
child
relationship,
we
end
up
with
traces
looking
like
this,
so
we
have
the
produce
and
then
they
produce
in
order
to
send
a
message
to
the
queue
it
creates.
An
HTTP
span
as
a
child
right
and
then
the
consume
is
suddenly
also
a
child
of
the
bodus,
which
creates
this.
What
I
think
is
a
bit
of
a
confusing
Trace,
because
it
shows
the
HTTP
as
a
sibling
of
the
consume
and
it
doesn't
follow.
A
C
A
And
and
imagine
that
after
this
HTTP,
you
have
like
a
lot
of
more
stuff
like
the
Intermediate
intermediary,
like
doing
all
its
Jazz
inside,
like
having
more
spans
that
describe
about
this
message
like
a
flow
in
the
system
and
then
suddenly
the
consumer
like
connects
in
a
different
place.
A
So
this
is
one
comment
like
I
I,
don't
have
a
solid
opinion,
because
I
hear
users
all
the
time
they
they
ask
for
what
you're
suggesting,
because
it
makes
sense
to
them
like
it.
It
keeps
coming
back
again
and
again
for
three
years:
I've
been
maintaining
instrumentations
for
messaging
systems,
and
people
are
again
and
again
and
again
they
ask
for
it
so
I
understand
where
it's
coming
from,
but
we
should
like
await
all
the
the
pros
and
cons
for
both
options.
A
So
this
is
one
comment
and
the
other
comment
is
that
if
we
refer
parent
child
relationships
because
of
sampling,
so
it
does
solve
one
sampling
issue,
but
it
creates
another
because
if
you
have
like
a
sampler
for
the
receive
operation-
and
you
say
that
you
want
to
sample
the
receive
operation-
and
this
receive
has
some
processing
of
the
messages
that
were
received
and
suddenly
they
are
missing,
because
the
the
sampling
decision
is
based
on
like
the
the
producer
and
what
they
receive.
A
B
I
mean
what
I
will
definitely
do.
Tyler
I
will
hear
big
and
I
I
think
that
causes
some
confusion
that
we
have
here
in
all
the
diagrams
that
I
have
here.
B
We
have
here
process
plans,
kind
of
that
are
mostly
parented
to
like
the
delivery
spans
I
will
grade
it
out
or
will
remove
those
this
process
instrumentation,
because
it's
not
covered
in
this
in
this
Otep
and
it
kind
of
suggests,
like
already
a
design
that
is
kind
of
not
that
is
not
the
specs
out
here,
and
that
is
even
not
like
agreed
on
it.
Maybe
not
even
my
deal
so
I
will
in
this
diagrams
here.
B
I
will
try
to
stick
to
just
what
we
what
we,
what
we
specify
here
and
I
will
also
remove
this
ambient
span
and
move
the
process
bands,
because
I
think
that
confuses
people,
and
it
also
suggests
it
already
suggests
to
a
solution
that
may
be
it's
not
ideal
and
I
will
just
stick
to
those
bands
here
that
we
actually,
where
we
actually
give
directions
or
recommendations
here
in
this
in
this
cell
tab.
B
To
to
to
like
avoid
confusion
and
do
not
suggest
any
solution
that
is
not
agreed
upon
it,
maybe
not
ideal.
B
A
A
Can
you
see
it?
I
can
see
this
cool,
so
it's
not
a
very
formal.
Currently,
it's
like
a
proposal
and
I
once
I
get
some
feedback.
I
can
continue
and
make
it
more
formal,
there's
also
a
lot
of
things
that
I
don't
yet
know
what
to
do
with
them
and
I
want
to
discuss
together,
and
so
it's
kind
of
a
long
document,
but
I
copied
the
relevant
power
to
the
top.
A
If
you're
familiar
with
all
the
details
in
the
calendar
specification
in
some
cases,
it's
not
even
possible,
so
I
will
go
over
it
and
feel
free
to
to
tell
me
if
it's
not
clear
or
with
you
want
more
information,
so
I.
A
B
A
So
I'm
not
referring
to
any
like
class
of
spends.
It
can
be
like
any
Spanish
at
all
because,
like
the
what
I'm
suggesting
here
will
work,
regardless
of
a
specific
trade
structure
or
a
a
specific
operation,
it's
a
describe
things
in
a
higher
level
like
if
you
have
a
span,
and
you
want
to
record
a
message
on
it,
no
matter
what
span
it
is
and
what
message
it
is
like
how
you
do
it.
A
So
when
we
talk
about
Trace
structure,
then
we
know
that
we
have
like
a
specific
classes
and
types,
and
we
know
where
we
want
the
links
to
be
present,
but
in
the
lack
of
such
guidance,
this
should
still
work,
I
think
so
at
least
right
so
like
what
what
I
wrote
below
actually
like
I'm,
classifying
it
like
so
so,
there
is
like
an
arbitrary
span.
I
know
nothing
about
it.
A
So
I
think,
as
a
first
like,
even
even
this
field
is
not
very
clear
in
the
specification
like
what
makes
an
arbitrary
spell
a
messaging
span,
so
I
would
be
happy
to
clarify
it
in
the
spec,
but
it
doesn't
it's
not
the
core
thing
that
I
want
to
to
touch
him,
but
like
after
an
arbitrary
span,
is
classified
as
messaging
span,
then
we
need
to
a
way
to
record
the
messages
on
it
and
extract
messages
from
it
when
we
process
it
right.
A
So
what
I'm
basically
describing
is
that
we
have
two
ways
of
recording
messages
onto
a
spin,
so
one
is
spending
and
the
other
is
as
pen
attributes.
We
make
it
a
bit
larger
yeah,
so
we'll
go
over
it,
quick,
so
instrumentation
May
record
each
message
on
an
operation
Spanish
spend
link.
The
use
of
the
world
may
implies
that
it
can
choose
not
to
do
it,
and
we
know
that
there
could
be
a
lot
of
reasons
why
it
might
not
do
it
with
the
sampling.
Maybe
the
data
is
not
there.
A
Maybe
it's
not
interesting,
maybe
it's
too
expensive
to
record.
So
there
could
be
a
lot
of
reasons,
but
I
just
want
to
say
made
that
instrumentation
can
choose.
If
it
wants
to
do
it
or
not,
each
message
must
be
recorded
at
most
once
this
guarantees
the
that
we
can
iterate
over
the
links
and
get
like
a
deterministic
list
of
messages.
Because,
if
messages
repeat
then
we
can,
we
can
tell
for
sure,
like
a
unique
messages
on
the
spam.
A
This
paragraph
says
that
if
we
have
the
the
message
context,
then
it
should
go
into
the
link
context,
if
it's
possible
and
if
not,
we
should
write
some
invalid
context.
There
we
already
discussed,
discuss
it
a
lot
and
I
think
we
agreed
on
it
and
yeah.
So
given
like
an
arbitrary
span
and
we
go
into
the
links
array
and
start
there
like
going
over
the
links
So.
Currently,
there's
no
semantics.
A
So
I
want
to
suggest
adding
an
attribute,
a
link,
attribute
a
link
type
and
giving
it
the
value
message.
I'm,
not
I,
don't
really
care
if
it's
like
what
the
key
and
the
value
and
if
there
are
other
suggestion,
suggestions,
I'm
really
open
to
hear
them.
My
main
point
is
that
we
should
have
a
way
to
to
filter
the
links
away
and
extract
only
the
relevant
links
that
actually
describes
the
message
and
each
medicine.
A
Yes.
So
so,
when
I
look
at
the
like
span,
so
some
of
the
attributes,
they
refer
to
the
operation
itself
and
some
attributes
refer
to
a
message
right.
So
if
we
like
doing
receive
messages-
and
we
have
like
the
the
I-
don't
know
the
IP
of
the
vocal,
then
this
is
part
of
the.
This
is
an
attribute
of
the
operation,
but
some
other
attributes.
A
They
really
refer
to
the
message
and
I:
don't
know
how
to
be
formal
about
it,
but
I
I
think
you
know
what
it
means
in
practice,
and
so
what
I'm
saying.
C
A
Is
that
every
attribute
that
is
like
relates
to
a
message
and
not
to
the
operation?
It
should
go
into
a
link
attribute.
It
cannot
be
like
a
spin
attribute,
because
there
could
be
multiple
messages,
and
so
it
includes
all
the
attributes
in
the
namespaces
messaging.
Message
like
this
is
things
that
are
specific
to.
C
A
A
System
message
and
okay
and
and
of
course
it
means
that
everything
that's
relating
to
a
batch
cannot
go
into
the
link
to
be
a
link
attribute
right.
So
if
we
have
a
messaging
dot
patch
dot
something,
then
it
doesn't
make
sense
to
have
it
as
a
link
attribute.
So
we
should
avoid.
C
This
and
and
says
that
it's.
A
Not
it's
not
allowed.
B
The
current
messaging
semantic
conventions
say
that
that
the
measured
specific
attributes
may
be
added
or
recorded
on
links.
A
Yes,
so
Ludmila
did
a
great
work
and
part
of
it
is
is
already
in
the
spec.
A
That
I
I
think
it's
important
to
to
state.
Is
that
the
like
instrumentation,
when
it
records
the
link,
it
can
say
like
some
attributes,
maybe
on
the
other
side
of
the
link?
If
you
follow
the
link
and
look
at
the
span
attributes,
you
might
find
more
information
about
this
message.
But
since
this
we
don't,
we
can't
always
do
it
like
the
link.
Target
may
be
missing.
Then
instrumentation
should
like
record
everything
that
is
interesting
as
a
link
attribute
I
think
it's
important
to
state
that
yeah.
A
A
Yeah,
okay,
so
I'll
go
to
a
to
the
other
section
about
the
spin
attribute.
So
one
way
of
recording
a
message
as
a.
C
A
Link
and
the
other
way
is
via
spin
attributes,
so
so
recording
a
message
on
spend
attributes
is
Possible
only
for
a
single
message,
as
we
already
discussed
a
lot,
and
it
may
recall
these
messages
as
spin
attribute
so
also
here
like.
If
you
chooses
not
to
it's
allowed,
not
to
record
this
message
is
fan
attributes
or
it
can
choose
to
do
it
as
a
spend
link
or
it
can
choose
to
do
it
as
both
everything
all
the
combinations
are
okay
and
yeah.
A
So
these
are
the
the
namespaces
and
how
they,
how
they
behave
and-
and
this
is
a
I-
wrote
it
before
we
had
the
the
we
talked
with
Tyler
about
this
issue,
but
so
this
this,
what
it
says
I
can
specification,
says
that
the
propagated
context
should
be
recorded,
and
it
doesn't
say
how
so
I
suggest
that
we
explicitly
say
that
it
must
be
recorded,
is
either
a
parent
child
relationship
or
a
link
all
right,
and
what
I
want
to
suggest.
A
And
here
your
opinion
is
that
if
we
do
a
record
it
as
a
parent-child
relationship,
then
if
there
is
ambient
context
at
this
time
of
of
recording
the
spell,
then
I
want
to
suggest
specifying
a
link
to
the
ambient
context.
So
it
is
not
lost,
because
if
this
link
is
not
added,
then
it's
really
hard
later
to
to
complete
the
picture
and
understand
what
happened
in
yeah,
and
there
is
a
currently
like
an
open
question
that
I
don't
really
know
how
to
answer
it.
A
Maybe
there
was
a
this
other
about
the
guy
that
suggested
that
to
add
if
the
parent
is
remote
or
not,
because
currently,
if
we
have
a
span-
and
it
has
a
parent-
we
can't
really
tell
if
it's
the
ambient
context
or
if
we
took
the
propagated
context
and
set
it
as
the
parent
right.
So
we
need
some
way
to
distinguish
them.
It
can
be
either
with
the
spend
kind
or
with
this
new
flag
that
that
is
doesn't
open
audit
for,
but
we
must
have
a
way
to
do
it
yeah.
A
So
there's
some
text
here
that
needs
to
be
updated.
If
we
agree
on
it-
and
the
next
thing
is
that
I
want
to
be
able
to
to
have
like
an
algorithm
to
to
detect
unrecorded
messages.
So
if
we
record
messages
on
spends-
and
we
agree
that
we
can't
always
do
it-
I
want
to
to
be
able
to
like
to
have
the
ability
to
to
at
least
know
that
maybe
a
span
like
add
10
messages,
but
it
only
recorded
five
messages
right.
So
it's
very
easy.
A
If
we
have
the
messaging
batch
message
count,
then
we
know
how
many
messages
participated
in
the
operation
and
then,
if
we
go
to
the
links
or
to
the
span,
attributes
and
understand
what
messages
are
recorded
and
we
can
subduct
them
and
we
can
know
if
some
messages
are
lost
because
of
any
reason.
A
So
this
is
another
issue,
and
the
next
thing
is
that
I
want
to
be
able
to
like
giving
a
single
message
like
a
lot
of
users
they
want
to
like
they
have
a
message
in
hand
which
they
they
acquired.
Somehow
maybe
they
saw
it
on
one
span
or
maybe
they
they
enter
an
ID
and
they
found
it,
but
now
they
want
to
see
the
full
story
of
this
message
in
the
system
right.
A
C
A
A
Yes,
so
just
as
a
side
note
like,
if
we
like
we're
talking
about
like
giving
giving
a
message,
we
know
the
message,
context
right,
the
create
context
or
the
publish
context,
and
now
we
want
to
to
find
all
the
places
that
have
this
context.
So
if
we
have
both
links
and
parent-child
relationship,
then
we
must
do
a
complex
query
to
the
database
right,
because
this
context
can
either
be
on
a
link
or
it
can
be
a
parent
of
another
span,
and
these
are
two
options
and
each
query
must
take
them
both
into
account.
A
So
it
makes
the
the
life
of
the
backends
a
bit
complicated
and
not
impossible,
but
it
complicates
things
for
the
backends,
because
there's
more
options
and
another
thing
here.
Sometimes
we
don't
have
the
spend
contacts
because
we
don't
have
a
way
to
propagate
it
and
then
the
only
way
to
do
the
correlation
is
via
some
ideas
or
some
other
attributes
that
uniquely
identify
as
a
specific
message,
so
I.
A
We
can
benefit
if
the
spec
would
explicitly
state
that
if
the
propagated
context
is
not
available,
then
instrumentation
should
do
a
best
offer
a
best
effort
to
record
everything
that
can
be
used
to
identify
the
specific
message,
and
it
will
be
very
complicated
for
backends
to
like
trace
this
single
message
in
the
in
the
system
like
see
all
the
relevant
spans
related
to
it.
But
at
least
we
will
have
the
information
to
make
it
possible
and
the.
B
I
have
some
remarks,
I
mean
I
will
add
them
onto
the
document
as
comments
for
for
the
first
one
when
you
talked
about
spendings
in
general,
and
this
link
DOT
type
attribute
I
posted
a
link
in
the
chat.
There
is
like
some
or
there
was
some
discussion
going
on
some
time
ago
and
I
think
the
level
was
involved
too
about
adding
like
span
specific
semantic
conventions
and
I.
B
Think
that
this,
that
is,
it
seems
to
me
where,
although
you
are
proposal
is
heading
to
it's
basically
here
like
the
title,
semantic
convention
for
spend,
link,
names
and
I
think
that
is,
that
is
in
order
for
backends
to
better
visualize,
spans
and
and
denote
okay.
B
What
kind
of
what
meaning
does
this
band
have
and
yeah
at
the
I
think
he
already
proposes
like
a
link.name
attribute
and
the
yellow
middle
I
think
at
the
very
end,
we
proposes
something
that
is
pretty
close
to
what
I
mean
you're
proposed
in
your
document
like
a
link.type
and
The
Thinker
link.name
in
in
addition,
so
as
a
as
a
I
mean
you,
you
framed
it
like
as
a
as
a
as
a
messaging
specific
extension
that
link
type
is
messaging,
and
then
we
know
okay.
B
This
is
this
is
a
a
a
a
link
that
kind
of
refers
to
like
a
message
but
I
think
in
in
in
principle.
Then
it's
like
it's
a
it's
a
more
generic
concept,
because
link
type
could
also
be
something
different
and
then,
like
refer
like
I,
think
you,
you
suggested
an
ambient
in
one
in
one
instance
for
like
another
link
type,
but
there
might
be
a
there
might
be,
then
there
might
be
a
list
of
other
linked
types
that
dead
back
ends,
know
and
support
and
I.
B
Think
that
is
that
the
link
type
and
Link
name,
those
link
specific
semantic
conventions.
That
is
if
that
makes
it
into
like
the
hotel
semantic
conventions,
that's
kind
of
like
a
thing
separate
from
messaging,
but
that
is
then
utilized
by
messaging
and
I.
Think
if
I
definitely
think
there's
value
to
have
that
I
think
it's
not
strictly
necessary
for
the
messaging
1.0
I.
B
Think
that's
something
that
can
easily
done
in
later
steps
be
added
on
that,
but
I
definitely
think
there
is
value
and
I
I
wonder
if
you
would
be
interested
in
pushing
for
this
like
Channel
link
attributes
like
they
are
discussed
here
in
this
issue.
B
Yes,
but
but
I
think
it's
an
it's
an
interesting
overlap
and
I
wonder
if,
especially
what
Luke
Miller
proposed
in
the
last
comment.
B
If,
like
such
a
proposal,
but
also
I
mean
she
uses,
link
dot
kind,
instead,
I
think
you're,
proposing
ink.type,
but
that
doesn't
really
much
of
a
difference
and
I
wonder
if,
if
what
she
proposes
here,
kind
of
would
also
met
with
what
you
propose
in
your
document.
A
B
Yes-
and
maybe
you
can
add
your
thoughts
here
and
if
you
are
interested
in
working
on
that,
you
can
also
maybe
mention
here
that
you
would
be
interested
in
working
on
some
semantic
conventions
for
links,
and
then
we
can
see
what
kind
of
input
other
people
give
to
that
I.
Think
here
it
it's.
It
makes
sense
to
yeah
keep
this
at
a
more
generic
level,
and
your
messaging
is
one
special
case
that
we
can
say:
okay,
this
link
refers
to
messaging,
but
I.
B
Think
overall,
this
should
be
a
more
like
generic
approach
taken
to
typing
links,
and
this
I
think
it
came
up
in
other
discussions.
It
comes
up
again
and
again
and
I
guess
it's
very
valuable,
especially
for
backlinks
to
make
sense
of
links.
B
We
are
over
time
I'm.
Sorry,
we
only
had
again
20
minutes
to
discuss
your
Docker.
We'll
add
other
comments
on
your
document,
because
I
had
a
few
more
but
thanks
everybody
for
toward
training.
Today.
That
was
a
very
good
discussions
and
yeah,
hopefully
see
you
on
Thursday
cool.