►
From YouTube: 2022-09-29 meeting
Description
Instrumentation: Messaging
D
C
A
B
D
A
B
Yes,
I'll
just
repeat
again:
the
meeting
agenda
link
is
in
the
Zoom
chat.
Please
add
your
name
there
in
any
topic
that
you
want
to
discuss
today.
B
I,
oh
well,
first
I
need
to
share
my
screen.
Excuse
me
there
we
go
yes,
so
I
went
through
some
things
and
I
added
here
to
the
agenda.
So
so,
let's
go
through
then.
So
the
first
thing
that
I
wanted
to
get
your
ideas
on
it.
B
We
have
our
project
board
there
and
I
think
we
didn't
look
at
it
too
much
in
the
past,
but
I
I
was
thinking
that,
if,
if
we
shouldn't
use
it
to
to
track,
for
example,
decisions
or
or
things
that
we
talk
about,
but
because
we
talk
about
and
I
I'm
trying
to
keep
notes
on
the
document,
but
sometimes
it's
hard
to
find
them
so
I
was
thinking,
for
example,
if
we,
if
there
is
a
clear
thing
that
we
need
to
let's
say
as
a
group
talk
about
and
decide,
for
example,
I
use
an
example
there
this
case
here
that
if
we
should
use
events
to
add
attributes
to
when
a
message
has
no
context,
I
think
this
was
a
discussion
that
happened
and
Christian
mentioned
this.
B
And
so
this
is
just
an
example.
But
I
was
thinking.
Maybe
we
should
create
a
ticket
or
item
on
the
board
and
then
once
we
have
a
decision,
we
we
just
put
the
decision
there.
So
if
we
have
to
forward
back
to
it,
then
we
have
a
place
so,
for
example,
I
I
added
this
item
here
now,
because
I
think
we
still
think
we
discussed
a
lot
but
I
don't
remember
if
we
did
any.
If
we
came
up
with
the
conclusion
or
as
a
group,
we
decide
on
our
way
to
do
it.
B
But,
for
example,
we
need
to
decide
and
I
added
this
to
the
agenda
today,
but
we
need
to
decide.
For
example,
where
do
we
record
attributes
when
it's
a
single
message
scenario?
Do
we
record,
for
example,
always
on
the
recorded
always
as
a
link,
or
do
we
record
on
the
on
the
spin
it's
sending,
because
it's
just
one
so
so
this
is
an
example
for,
like
I
said
so,
I
use
I
put,
let's
say
the
decision
that
we
want
to
do
and
then
once
we
do
it,
we
can.
B
We
can
record
here
what
we
decided
and
then
I
guess
this
can
be
used,
for
example,
to
create
issues
and
then
appear
based
on
it
to
update
the
document
or
something
like
that,
not
sure
what
to
use
your
idea.
But
I
was
struggling
to
to
find
like
decision
that
we
agreed
on
something,
especially,
for
example,
this
one.
E
I
mean
that
sounds
good
to
me.
We
should
definitely
capture
our
decisions
somewhere,
yeah,
whether
it's
in
in
an
Otep
or
in
this
sport.
E
B
I'm
not
sure
if
what
you
think
I
want
to
talk
about,
sometimes
I
struggle
to
find
things,
and
we
have
to
be
diligent
in
keeping
notes
so
yeah
I
I
was
reflecting
I
I
think
the
board
might
offer
a
visual
way
to
actually
see
the
things
okay.
So
if,
if
anybody
has
any
no
doesn't
like
this,
then
we
can
also
discuss
but
I
guess
we
can
do
this
way
right.
B
So
the
other
thing
that
happened
this
week
is
the
past
week
is
I
joined
the
spec
call
this
week
because
of
something
else
but
I
joined
and
in
the
end
it
was
a
discussion
about
this
new
initiative
that
they
are
having
for
that.
The
group
is
having
for
the
working
for
the
for
the
semantic
convection
stabilization
in
all
that
and
what
was
discussed
so
someone
joined
the
meeting
and
they
have
several
PRS
now
open
for
adding
metrics
semantic
conventions
and
they
asked
if
their
PRS
are
blocked.
B
Now,
because
of
this
new
preparation
in
in
DC
members
wanted
to
hold
on
on
things
a
bit
until
things
are
are
stabilized.
So
there
was
a
lot
of
back
and
forth
on
this,
but
the
resolution
more
or
less,
if
you
can
call
it
like
that,
was
that
Josh
zero.
So
the
against
the
person
driving
this
effort
now
wrote
guidance,
because
the
group
agreed
that
we
shouldn't
block
PRS
if
they
don't
need
to
be
blocked.
B
So
this
was
the
case
with
this
person
had
like
six
PRS
and
he
actually
he
actually
demanded,
or
he
asked
an
answer
from
the
group
from
the
DC
saying
like
is
my
PR
block
now
I
just
want
to
know
if
it's
blocked,
if
I
should
do
something,
and
so
there
was
this
guidance
now
so
Josh
wrote
this
guidance
on
the
on
the
issue
here.
B
That
kind
of
gives
on
an
idea
which
thing
might
be
impacted
by
this
work.
It
might
be
blocked.
For
example,
the
link
is
here
so
I'm
not
gonna,
go
into
details
of
this
I
just
wanted
to.
Let
you
know
about
this
and
I
think
at
least
API
that
I
have
now
for
the
cement
for
the
context,
propagation
moving
from
the
Otep
I.
B
Think
that
is
not
impacted
anymore,
because
we
don't
touch
so
the
the
too
long
didn't
read
of
the
discussion
was
that
if
there
is
something
related
to
metrics
that
is
shared,
so
any
attribute
that
is
going
to
be
related
to
a
metric
that
is
shared
between
any
other
signal
might
be
a
problem
because
of
cardinality.
So
they
want
to
take
care
of
that
and
they're
working
on
defining
what
the
resource
identity
is
and
how
it
relates
to
the
signals
and
how
its
attributes.
B
So,
if
we
touch
any
of
those
things,
then
they
might
be
impacted
as
well.
So
this
is
what
this
one
here
for
so
I
think
it's
mostly
around
attributes
and
metrics
and
how
they
relate
to
each
other,
so
I
think
for
now
we're
not
impacted
by
this.
So
we
should
be
good.
So
what
I
did
is
I
after
the
meeting
I
did
digest
this
a
bit
and
then
I
I.
B
Let
the
folks
that
added
this
triage
needs
more
info
to
my
PR,
so
the
eye
Organization
for
my
PR
for
the
context
propagation
and
they
added
this
label
here,
which
means
that
it
was
kind
of
blocked
and
that's
what
Riley
said
here
that
they're
discuss
in
this
and
so
on.
So
so
that's
what
he
said
here.
That
is
because
it
is
the
initiative
Etc.
So
then
I
now
that
there
is
this
guidance.
B
I
just
forwarded
back
to
him
into
this
other
user,
that
they
should
be
good
and
they
should
not
be
blocked
or
they
should
review
this
now,
because
we
should
not
be
blocked
by
this
anymore.
So
hopefully
it
is.
Hopefully
this
moves
forwards
itself,
I
solved
all
the
comments
that
we
had
and
I
saw
that
Carlos
approved
as
well.
B
The
contextual
application,
VR
so
I
think
look.
It
look,
looks
good
now,
I
re-requested
review
from
all
of
you,
because
I
changed
the
text
a
bit
and
and
added
some
I
added
the
the
timing,
knowledge
for
producers,
consumers
and
and
intermediaries,
because
we
didn't
have
it
before,
and
that
was
that
was
after
some
of
you
already
approved.
So
I
request
just
to
be
clear.
B
So
if
you
can
take
another
look,
please
that
should
be
the
final
one
and
I
guess
then
we
can
I
can
ask
the
PC
I
can
request
the
DC
members
to
take
a
look,
because
we
should
have
enough
people
here
that
are
in
the
group.
I
also
asked
Paulo
to
review
again.
He
said
he
will
take
a
look,
so
I
think
we
should
be
good.
B
All
right
and
I
guess
this
gives
us
an
idea
in
the
future
what
we're
working
on
now,
if,
if
it
will
be
impacted
with
the
what
type
of
rewriting
and
the
attributes
so
I,
believe
that
we,
it's
not
gonna,
be
impacted
by
this.
But
we'll
see.
E
I
mean
I,
don't
want
to
like
then
as
to
open
another
can
of
worms
here,
but
I
think
we
really
in
certain
ways
be
affected
with
our
attribute
discussions,
because
I
think
at
some
point
there
will
be
or
there
should
be,
like
metrics
semantic
conventions
for
messaging,
yes
and
I,
think
we
will
very
likely
share
attributes,
I
mean
I,
guess
we
want
to
share
attributes,
they
are
between
traces
and
metrics
and
then
yeah
I'll
be.
At
that
point
we
will
run
into
all
those
yeah
into.
E
Question
whether
we,
whether
we
even
can
or
want
to
declare
the
tracing
part
stable
without
having
an
idea
about
metrics
I,
think
we
actually
also
need
to
have
at
least
the
rustity
of
metrics
and
attributes
and
or
cardinality
restrictions,
so
that
we
so
that
we
kind
of
actually
can
make
the
tracing
Parts,
stable,
yeah.
B
B
Yes,
I
asked
the
beginning,
but
people
were
quiet
so.
A
B
A
B
Yes,
we
are
basically
working
on.
Let
me
open
here
see
if
I
can
find
this
easily
we're
working
on
I,
say
two
big
things
now
there
is,
there
is
one
old
tab,
so
the
first
thing
that
I
was
discussing
there
is
this
PR,
which
is
basically
integrates
a
notepad
that
Johannes
worked
in
the
past
in
the
specification,
so
this
defines
how
context
propagation
in
the
so
how
context
propagation
Works
in
messages
systems.
So
this
is
the
one
of
the
tags
that
we're
currently
working
on
now.
B
So
if
you
could
take
a
look,
this
would
be.
This
would
be
great
I'll
pass
the
paste,
the
link
on
the
chat
as
well.
E
Made
a
great
starting
point,
probably
to
get
like
into
our
work,
is
and
I'm
not
sure
if
you've
already
done
this
like
reading
the
existing
messaging
semantic
conventions
in
the
open,
Telemetry
specification,
that
is
like
an
existing
document,
that's
in
a
in
a
experimental
state
currently,
and
that
has
that
has
several
shortcomings
and
beer
basically
is
a
group.
We
are
trying
to
improve
this
document
and
to
bring
it
to
a
stable
state
that
is
our
menu.
That
is
currently
our
main
aim.
E
E
So
if
you
want
to
kind
of
get
started
with
the
work,
we're
doing,
I
would
recommend
you
start
with
this
document
that
this
basically
just
status
quo,
and
we
are,
we
are
kind
of
working
to
to
improve
this
and
to
bring
it
to
a
to
a
stable
state.
Okay
and
then
we
have
several
oteps.
Currently
there's
like
you
saw
some
in
the
in
our
meeting,
notes
and
I.
Think
that
would
be
the
next
good
step
that
then
you
will
stop
that.
E
There
is
a
hotel
messaging
group,
so
I
recommend
you
joining
this
group
and
then
we
can.
We
can
share
all
the
links
with
you
before
the
specification
and
for
the
old
tips,
and
maybe
we
can.
We
can
do
that
on
slack,
it's
more
more
efficient,
I
think
and
you
can
also
like
during
the
week.
You
can
ask
any
kind
of
questions.
I
think
there
are
lots
of
people
on
the
messaging
Channel
foreign.
B
E
It's
a
it's
Hotel,
minus
messaging.
Yes,.
F
Hi
guys
sorry
I
only
was
able
to
join
now.
I
want
to
thank
clever
for
for
getting
forwards
to
and
joining
the
the
group
thanks
very
much.
B
Right
I
cannot
share
the
link
of
the
group.
Without
put
you
just.
B
Right
they
put
everything
on
the
chat,
so
there's
a
pointer
for
you
too,
to
look
at
okay.
Let's
go
back
yeah,
so
I
I
will
try
to
put
maybe
some
links
here.
I,
don't
know
if
that's
possible,
but
one
thing
that
I
wanted
to
ask
I,
don't
know
if
you
know
Johannes,
but
I
think
this
document
was
shared
in
the
past
with
the
this
group
here.
Do
you
know
if
they
still
use
this
document
for
their
stuff
I've.
B
Okay,
I'll
just
leave
it
in
because
I
don't
want
to
remove
stuff,
okay,
good,
to
know
all
right,
so
this
was
this
yeah.
So
this
guidance
and
the
other
thing
that
I
think
we
discussed
some
time
ago
is
to
get
some
feedback
about
your
tap
and
the
work
I'll
be
done
that
we
have
been
doing
with
some
of
the
folks
that
wrote
the
initial
messaging
document,
so
I
I
had
a
quick
chat
with
Christian.
So
this
is
this.
B
This
is
his
GitHub
username
and
the
topic
of
of
the
Otep
and
and
the
breaking
changes
that
we
we
will
have
to
introduce
and
his
his
point
was
that
I
think
he
also
put
this
in
the
old
tab
as
a
comment,
but
he
mentioned
that
the
the
Otep
calls
is
stabilizing,
but
it's
actually
rewriting
everything,
so
we're
kind
of
rewriting
the
whole
current
document,
and
he
thinks
that
it's
probably
not
the
best
way
to
do
it.
B
So
he
suggested
that
we,
if
we
want
to,
for
example,
the
priority,
is
to
stabilize
the
current
document.
Then
we
could
just
clarify
things
in
the
existing
document,
but
not
add
too
many
changes
or
or
overhaul
like
like
he
says,
but
he
seems
to
to
see
to
think
or
or
The
Impressions
that
we
actually
want
to
overhaul
it
and
recreated
in
in
and
so
on,
which
I
agree.
But
he
said
he
thinks
that
maybe
what
we
should
like
an
idea
that
he
suggested.
B
Maybe
we
identically
also
discussed
about
this-
that
we
put
all
this
new
work
in
a
separate
new
document,
at
least
the
one
that
is
there,
that
we
have
today
there,
because
that
way
we
could
work
on
the
other
one,
let's
say
more
freely,
and
then
we
don't
immediately
introduce
breaking
changes
to
the
existing
Docker,
because
maybe
that
will
break
even
existing
back-ends
existing
instrumentation.
If
we,
for
example,
change
the
attributes
or
the
name
spaces
and
so
on,
so
we
could.
B
We
could
create
a
new,
a
new
dock
so
like
this
was
the
lunch
hour
here.
So
instead
of
a
stabilizer,
we
could
create
a
new
document
which
will
take
over
from
the
from
the
current.
That's
basically
idea,
and
then
the
document
can
still
stay
there.
For
for
for
some
period
or
something,
and
then
people
that
are
okay
with
adopting
breaking
changes,
they
can
look
at
the
for
the
new
document,
while
the
others
can
still
have
the
old
and
have
some
time
to
migrate
or
something
like
that.
B
B
B
Yeah
and
I
think
glutamine
or
someone
else
in
some
other
weeks.
We
discussed
this
that
we,
for
example,
we
could
add
a
new
document
that
is
specific
for
batching
and
we
leave
the
current
one,
as
as
it
is
for
for
a
single
message,
and
we
just
kind
of
clarify
things
there
and
in
the
D1
we
add
all
the
things
related
to
batching
and
that
there
is
maybe
most
of
the
breaking
things
will
happen
there,
but
yeah.
That
might
be
also
breaking
things
in
the
single
message,
depending
how
we
organize
the
attribute.
B
So,
but
we
already
kind
of
thought
about
discussed
about
having
a
new
document.
For
example,
yeah.
F
So
I
like
that
approach,
especially
because
if
we
are
doing
incremental
changes
on
what's
in
there,
people
will
see
it
moving
all
the
time
and
migration
paths
will
not
be
always
clear
and
we
might.
We
might
introduce
conflicting
message,
well,
not
messages
but
go
fitting
guidelines.
F
This
way
with
a
separated
document,
we
won't
have
to
to
keep
as
much
work
on
that
reconciliation
process
between
what's
in
there
and
the
the
new
thing,
and
we
can
focus
more
on
how
we
want
to
to
move
forward
and
later
well
think
about
how
to
migrate
from
from,
what's
in
there
to
to
the
new,
if
that's
the
case
in
a
consistent
way,.
B
E
D
It
feels
yeah
I
also
like
this
proposal.
It
feels
so
we
need
some
way
to
distinguish
them,
though
different
namespace
are
specific
attributes
version
I
think.
Ideally,
we
would
have
a
version
per
semantic
convention,
but
it's
not
there.
So
we
can
just
come
up
for
some
holistic
and
make
sure
it
won't
like
introduce
problems
and
backends
who
want
to
support
those
for
the
time
beings.
A
E
B
This
is
something
that
we
could
ask
in
the
spec
meeting.
I,
don't
know
if
that
would
be
the
right
Forum
to
ask
like
just
not
any
detail,
but
just
ask
that
we
have
the
current
document
that
we
want
to
when
we
are
working
on
improving
it,
but
that
will
cause
somewhat
breaking
changes
and
how
they
think
we
should
move
forward
and
that
we
have
have
thought
about
this
approach
if
what
they
think
so.
E
D
E
B
E
That
would
be
great
input,
I
mean
in
another.
Maybe
four
big
solution,
I
thought
about
this-
that
we
are
choose
that
we
trust
here,
maybe
put
up
a
draft
PR
will
be
done
in
this
draft
PR
that
can
be
longer
running
and
in
this
prb
kind
of
overhaul
the
existing
conventions
and
basically
there
we
can
like
collect
changes
but
yeah
it's.
That
seems
definitely
to
be
a
more
a
more
like
it's
not
so
nice
to
work
with
the
draft
PR
approach
than
with
just
having
a
complete
new
version
side
by
side.
A
D
But
also
I
think
we're.
There
are
two
strategies
to
work
in
the
space.
We
can
come
up
with
more
or
less
complete
guidance,
and
we
will
keep
a
few
to-do's
for
controversial
things
and
then
like
create
this
version
too,
or
we
can
go
in
small
steps,
but
considering
how
slow
things
are
was
the
spec
review?
D
Maybe
we
we
can
bundle
this
more
or
less
complete
document
and
then
get
it
merged
and
then
there's
no
changes
over
it's
the
controversial
topics
that
I
can
just
move
faster
respects.
B
B
All
right.
So
I'll
try
to
think
more
and
I'll
ask
more
around
and
yeah.
Maybe
I'll
open
an
issue
with
the
thoughts
and
then
we
can
bring
this
to
the
others
to
see
what
some
guidance
that
they
can
give
us.
E
Yeah,
but,
but
to
pick
here,
I
chose
to
clarify
from
you
think
that
is
only
the
step.
Basically
after
we
got
like
related
oteps
merged,
so
we
might
have
still
those
out
tips
for
attributes
and
for
kind
of
span
structure
and
then
and
then,
after
those
oteps
approach.
Basically,
we
are
having
this.
This
messaging
me
too,
based
on
our
tips.
B
E
D
B
D
And
we
can
capture
all
the
decisions
in
this
pack,
so
I
guess
creating
a
stack
and
using
it
to
find
the
gaps
in
the
bathtub
and
like
Mark,
this
controversial
places
and
make
a
decision.
So
we
can
just
use
the
what's
missing
because
in
in
this
draft
spec
as
the
agenda
for
things
to
discuss,
so
we
don't
go
in
some
random
discussions
about
complicated
question
scenarios.
B
Right:
yeah!
Yes,
if
we
can
make
the
the
drive
not
full
of
discussions.
Oh
that
might
be
tricky.
Yes,.
B
All
right
yeah,
so
the
I
guess
that
what
that
means
is
that
we
have
this
little
tab
that
we're
currently
working
and
then
I
guess.
But
this
was
already
the
idea.
Why
that
we
split
it
kind
of
split
it
in
two
ways,
one
for
the
attributes,
part
and
the
other
for
the
span,
structure,
guidance,
thread
and
examples,
and
so
on
then
we'll
mostly
have
most
likely
have
to
do
full
tabs.
That
then,
will
become
part
of
this
new
V2
spec
draft
right.
B
B
Okay,
right.
B
So
with
the
current
attempt
to
do,
we
want
to
I
think
there's
several
comments.
Still
there
see
if
there's
anything
to
impactful,
I,
guess
or
something
that
we
should,
that
we
didn't
address
and
then,
if
not,
then
we
can
I,
guess
start
splitting
it
and
creating
creating
new
ones.
B
Okay,
I'll
put
a
I
will
try
to
continue
asking
more
Gathering
more
information
for
this.
B
B
One
yes,
so
I
was
looking
at
it
today
again
and
then
I
was
looking
at
the
open
discussions
and
I
think
this
one
here
that
is
still
open
is
about.
If
we,
if
we
add
the
attributes
so
when
we're
dealing
with
single
message
message,
if
we
add
the
attributes
on
the
span
that
let's
say
the
publisher
that
receives
pen
or
we
create
a
link
like
we
will
mostly
likely
do
for
Badges
and
I,
think
we
didn't
get
to
a
disc
decision
on
this
point.
B
So
what
we
do
into
this
two
cases
are
like
when
a
single
message
do
we
also
use
links
to
make
it
consistent
or
do
we
I,
don't
use
links
in
this
case
and
just
add
directly
to
the
spin,
because
I
think
this
this?
This
will
help
driving
this,
and
we
we've
been
discussing
one
thing
that
I.
Why
I
thought
about
this
is
because,
in
the
document
I
mean
just
find
it
here.
B
In
the
in
the
markdown
now
there's
the
new
table
right
for
the
per
message
attributes.
So
there's
this
part
here
that
says
that
can
describe
a
message.
So
all
my
separate
can
describe
a
batch
of
messages
for
batch
operating
operations.
Attributes
cannot
be
set
on
the
correspondence
band
that
we
already
know
this
and
maybe
instead
it
may
may
instead
be
set
on
the
link,
but
it
doesn't
say
where
they
should
be
when
it's
a
single
message
right.
B
So
it's
kind
of
in
the
air
and
if
we
know
when
we're
going
to
do
it,
then
we
can
add
this
information
here
like
for
batches
to
do
this.
For
for
single
to
that.
But
I
think
it's
something
that
we
discussed
multiple
times,
but
we
never
said.
Okay,
we
will
do
it
this
way,
we'll
we'll
do
it
I'm,
not
sure
if
we
are
armed
with
all
the
tools
that
we
need
to
decide
this
now,
but
I
I
really
think
that
we
should
lay
on
this
at
some
point.
D
Probably
didn't
talk
share.
The
decision
about
my
impression
was
that
we
decided
that
we
recommend
attributes
to
be
on
on
a
span
when
it's
possible.
It
should
be
possible
when
there
is
just
one
message
and
I
think
it's
because
we
want
to
like.
D
We
want
current
backlance
to
to
be
able
to
work
with
respect
at
all,
because
there
are
no
back-ends
that
support
attributes
and
it
would
be
difficult
to
do
to
make
any
other
decision,
but
for
a
bad
chain
the
only
option
is
to
put
them
on
links
or
we
will
figure
out.
Maybe
events
we'll
see.
B
A
I'm
still
trying
to
figure
out
some
things
why
you
guys
have
like
a
different
properties
for
each
provider,
but
usually
in
the
batching
case,
I
would
say
it's
better
to
put
like
on
each
message,
because
the
broker
May
decided
to
put
in
different
partitions
literally
distribute
the
messages
and
sometimes
like
the
broker,
may
get
like
its
internal
representation
in
in
the
Telemetry.
You
know
what
happened
to
this
message
was
distributed
here
and
there
so
I.
A
A
D
You
receive
from
all
petitions
your
API
receives
from
all
partitions,
but
messages
are
coming
from
different
partitions
right.
So,
like
the
question
is
where,
in
the
open
Telemetry
structure,
how
do
we
represent
this
information?.
D
So,
for
example,
I
don't
have
a
producer.
Telemetry
I
only
have
consumer
Telemetry
I
want
to
know
that
message
came
in
where
it
came
in
from
and
I,
don't
know
the
the
specific
broker,
attributes
or
delivery
counter
stuff
like
that.
They
are
per
message
right
and
they
receive
in
batch
and
I
have
one
span
that
represents
this
receive
operation,
but
they
have
two
messages
so
wait.
D
We
cannot
put
the
specific
message
properties
right
on
the
span
right,
because
there's
one
stand
to
messages,
so
we
the
open,
Telemetry
I'm,
not
sure
how
familiar
you
are.
Stop
me.
If
you
don't
need
this
information
in
up
in
Telemetry,
we
have
links
and
links
describe
like
the
the
relationships
between
traces
or
Spence
without,
like
parent
child
right,
I
can
say:
okay
I
received
the
messages
I'm
related
to
the
context
in
these
messages,
and
this
this
is
done
with
links
and
links,
can
have
attributes
and
we're.
D
We
don't
really
have
full
understanding
on
how
we
are
going
to
do
this.
There
are
some
problems,
don't
let's
not
talk
about
them,
but
the
idea
here
that
we
will
stamp
the
per
message
attributes
on
those
things,
but
the
broker
like
this
call
things.
Okay,
I'm,
probably
don't
get
messages
from
different
Brokers.
D
Then
the
broker
would
go
and
spend
plus
everything.
That's
common
across
all
messages.
A
D
Oh,
the
yeah
and
the
the
per
system
properties
is
to
accommodate
common
things,
for
example,
I
work
on
Azure,
and
we
have
some
attributes
specific
to
Azure.
For
example,
we
have
delivery
count
in
one
of
the
messaging
systems
and
I
would
like
the
the
industry
to
know
that
we
have
this
property,
so
anyone
who
is
building
experience
specific
to
Azure
can
take
it
into
account.
The
users
can
find
this
documentation
and
build
queries
on
top
of
that.
F
Do
we
want
to
standardize
some
of
these
properties
across
vendors
and
create
like
translation
layer
for
the
vendors
pretty
much
like
I?
Don't
know
a
messaging
attribute
extractor
for
each
one
of
these
vendors,
but
each
side.
A
This
this
knowledge
of
those
properties.
At
some
point,
we
need
to
be
like
an
implementation
specific
right,
so
you
don't
intend,
like
a
people
to
know,
to
follow
or
spend,
do
not
need
to
know
like
the
message
Kafka
key
like
it.
You
need
to
have
some
translation
in
terms
of
the
the
open,
Telemetry,
I,
think
Hotel.
B
Yeah,
so
the
so
the
the
idea
of
this
specific
things
here
is
that
people
write
instrumentation
for
Apache,
Cafe,
Kafka
libraries,
for
example.
They
know
like
what
attributes
they
they
have
to
create
and
and
what
their
names
are
right.
So
potentially
these
parts
here
are
on
their
own
files
on
their
own.
B
A
B
Not
it's
it's
to
describe
the
operation
that
this
library
is
doing
right.
So,
for
example,
if
I
make
a
query
or
if
I
send
a
message-
and
there
is
some
information
particularly
specific
for
that
system
like
a
little
bit
I
said
something
about
Azure
that
is
important
for
or
is,
is
relevant
only
for
Azure.
Then
there
is
attributes
for
this,
and
the
attributes
are
here
in
the
specification,
because
the
the
observous
project
go
is
that
all
instrumentations
have
the
same
semantic
right.
B
They
know
the
same
attributes
they
use
the
same
keys
and
so
on,
because
otherwise
it
becomes
a
mess
right.
So
I
cannot
switch
from
one
back
end
to
another
because
in
one
back
end
is
called
some
something
some
some
key
like
that,
and
the
other
is
called
something
else
or
if
I
switch
libraries,
one
Library
I'll
do
implements
one
way
and
the
other
implements
the
other
way.
So
the
attributes
are
are
part
of
this
because
of
this
right.
So
so
we
have
some
consistency
in
in
some
semantic
on
on
the
things.
B
But
but
for
example,
we
don't
capture
everything
that
this
particular,
for
example
vendor
like
Azure.
Does
they
can
still
put
whatever
they
want
in
into
their
libraries
and
not
here?
But
this
is
something
that
I
guess.
The
community
thought
that
is
like
the
minimal
that
is
important
for
these
messages
systems
and
they
want
to
have
this
standardized.
So
that's
here.
E
I'm
gonna
I
think
there
there
are.
There
are
two
layers
that
that
you
need
to
keep
apart.
I
mean
the
first
layer,
and
that
is
what
we
are
currently
mostly
focus
on
is
basically
having
generic
messaging
attributes
that
are
independent
of
of
messaging
systems.
So
that's
what
you
see
here.
Those
are
attributes
that
basically
are
have
the
same
semantic
meaning
for
regardless
of
what
system
you're
using.
E
However,
by
definition
there
you
only
can
go.
You
can
go
to
like
the
yeah,
the
least
common
denominator.
So
you
only
have
like
a
subset
of
information
that
maybe
you
want
to
have
for
a
specific
messaging
system,
I
mean
when
you
have
it
on
the
Kafka.
You
might
be
interested
you
about
petition.
Is
this
measured?
What's
this
message
read
from,
but
this
cannot
be
a
generic
attribute,
because
the
other
concept
of
partition
doesn't
exist
for
other
messaging
systems.
E
So
that's
this
first
division
that
you
have
like
the
real
messaging
system:
independent
attributes,
the
generic
ones-
and
this
is
kind
of
this
common
layer.
And
then
you
have
this
basically
messaging
system,
specific
attributes
here
that
is
the
second
layer,
and
that
is
that
is
information
specific
to
the
messaging
system
that
is
related
and
bound
to
this
messaging
system
that
is
codified
here
and
why
it's
codified.
Here,
that's
also
for
consistence,
because
let's
say
you
have
I,
don't
know
a
Kafka
library
in
I,
don't
know
Python
and
you
have
a
Kafka
library
in
Java.
E
A
So
I
I
guess
I'm
trying
to
figure
out
what
what
is
I
I
came
here
with
the
perception
that
you
guys
were
trying
to
standardize
a
way
to
capture
events
that
are
broker
worth
generating.
In
that
sense,
you
specify
what
properties
you
need
to
to
have
the
broker,
injecting
on
the
on
the
to
have
the
context
propagation.
A
F
Let
me
clarify
some
things
and
the
guys
please
correct
me
if
I'm
wrong,
so
my
understanding
is
that
we
need
these
semantic
conventions,
regardless
of
if
it's
a
client
producer
receiver
a
broker
wherever.
So,
if
the
data
that
we
are
capturing
has
that
semantic
value,
it
should
use
that
key
right
now
we
are
foxing
more
on
the
producer.
Receiver
ends
of
those
messages
and
not
yet
on
the
broker
and
guidelines
for
Brokers
will
come
in
the
near
future.
F
C
I
want
to
go
back
to
the
original
issue
like
well.
The
attributes
should
be
set
like
regardless,
if
they're
generic
or
like
a
specific
for
messaging
system,
so
like
I,
think
like
for
batching.
We
know
that
we
want
to
create
links
right
and
for
single
message.
We
I
think
if
I'm
not
mistaken,
we
didn't
decide
if
we
want
to
always
create
links,
sometimes
create
links,
make
it
optional
like
that,
can
be
very
a
lot
of
variations,
but
even
for
single
message.
C
Sometimes
we
will
have
to
create
a
link
if
there's
ambient
context
right
so
now
the
question
is:
do
we
want
consistency,
because
if
instrumentation
libraries
sometimes
plays
the
attributes
on
the
links
and
sometimes
place
it
on
the
spin
and
then
the
user,
they
like
get
confused,
they
have
to
jump
like.
Sometimes
it
can
be
here.
Sometimes
it
can
be.
There
I
think
it's
not
the
best
experience
and
it's
also
very
out
for
backends,
because
they
now
have
to
like
have
complex
logic,
to
extract
these
values
from
various
places.
C
D
B
But
but
when
I
so
in
the
message
so
in
the
consumer,
when
I
received
the
the
message,
then
we
said
we
will
create
this
receive
span
right
and
then
the
question
is:
do
we
attach
the
message
specific
attributes
to
this
receive
span
or
do
we
create
a
link
on
it
and
then
add
the
attributes
there?
But
if
we
have
already
so
on
the
moment
where
we
receive
the
the
message,
so
we
create
the
receipts,
then
does
it
doesn't
matter?
C
Yes,
so
my
point
about
the
attributes
is
that
we
know
that
for
a
batch
scenarios
we
will
for
sure
have
links
right
and
then
for
single
message.
We
might
have
links
and
we
might
not
have
links
right.
So
even
for
a
single
message,
we
have
like
two
two
options,
and
so
so
it's
not
clear
that
for
a
single
message.
D
A
Think,
oh
sorry,
one
thing
that
could,
of
course
the
problem
is
the
inconsistency
something
similar,
but
Amir
has
also
touched
so
suppose
this
there
are
now
two
two
kind
of
scenarios
where,
if
like
consumer
receives
single
message,
puts
it
at
the
span
level
and
send
to
the
back
end
now
next
time
it
receives
two
messages:
it
puts
that
into
the
links
and
sent
to
the
back
end.
B
But
I
just
wanted
to
to
make
it
clear
that
we
already
have
the
single
system
today
right.
So
today
the
current
specification
says
we
should
add
to
the
span
the
attributes,
and
if
we
specify
the
batching,
which
we
have
to
do
with
the
links,
then
we
will
have
an
inconsistence
already
and
there's
no
way
out
of
it
right.
D
Yeah
well
I
think
we
can
forget
the
current
stock
right.
We
are
just
discussed
that
it's
it's
the
past.
We
don't
need
to
keep
consistent
with
it.
B
Yeah
but
but
we
will
break
all
the
back-ends
that
currently
do
this.
If
we
move
to
links
on
the
on
the
standard
two
bits
for
single
methods,
right,
nothing
will
work
anymore.
Yes,.
D
B
D
A
Go
ahead,
31,
quick
question
on
the
current
one:
what
is
the
sorry
experience
if
they're
the
if
this
Library
like
receives
two
two
messages
like
we
don't
generate
links?
We
just
pick
one.
D
So
yeah
the
current
spec
does
not
even
there
is
no
way
to
put
the
attributes
per
message
per
message
regarding
inconsistency,
so
my
understanding
that
in
the
back
end
and
user
approach
would
be
to
merge
per
message,
attributes
and
spend
attributes
together,
and
this
this
combination
would
be
the
what
they
need
to
everything
they
need
to
know
about
this
message
to
me
it
sounds
pretty
much
consistent
and
it
will
always
be
true.
D
B
See,
okay,
yeah
I
I
haven't
thought
about
that
like
if
I
click
on
the
receive-
and
there
is
a
patch,
then
I
would
see
all
the
attributes
that
came
in
the
battery
in
the
single
view,
I
didn't
think
about
it.
Maybe
I
I
was
just
thinking.
I
would
click
around
in
HD
video
link
and
go
to
that
attributes.
Yeah.
D
A
Okay,
this
is
okay,
yeah,
that's
a
fair
point.
Definitely
I
was
like
I,
think
I'm,
just
trying
to
think
like
how
they
can
write
some
logic
or
some
user
can
come
up
with
some
scripts.
They
might
find
look
at
these
kind
of
attributes.
I
will
find
it
to
the
span,
and
these
kind
of
activists
that
you
were
just
discussing
I
will
find
into
the
links
I'm,
not
sure
if
they
will,
because
yeah
they
did
it's
not
like,
they
can
simply
merge
it.
Because
links
attributes
are
kind
of
a
list.
A
F
F
D
Because
there's
no
way
up
around
it
right,
so
if
you
have
a
batch
of
thousand
messages,
maybe
you
should
configure
your
tracing
in
the
way
that
it
doesn't
even
capture
those
such
events
right,
regardless
of
where
we
could
damage
the
question
like
do
we
put
them
at
all?
I
think
this.
This
question
is
is
a
different
one,
so
we
have
one
message
in
the
batch
where
we
put
its
attributes.
Yes,.
D
And
it
tells
to
me
that
it's
it
would
be
I
I
can
share
my
communications
with
customers.
So
what
we
do
on
the
received
side,
we
create
a
link
per
context
we
received
and
they
every
once
in
a
while
I
get
a
question
from
customer.
Why
do
you
create
like
why
my
spends
are
not
correlated
I?
Don't
cannot
write.
Query
I
always
receive
one
message:
I,
don't
understand
what
links
are
so.
D
A
D
If
it
was
ambient
context
and
receive
it's
very
unlikely,
somebody
has
ambient
contacts
and
if
they
have,
they
probably
did
something
wrong.
So
I
don't
think
we
can
guarantee.
There
will
be
links
for
a
single
scenario,
at
least
that
there
will
be
a
huge
adoption
for
this,
and
we
should
at
least
allow
the
stamp
per
message
attributes
on
span
and
I
think
we
should
even
make
it
a
recommendation
that
if
there
is
a
single
message,
all
attributes
should
appear
on
spam.
This
is
my
condition
on
this.
Yes,.
B
B
Like
that
approach
as
well,
I
I
understand
that
that
it
might
be
complicated,
for
example,
because
there
is
different
ways
but
I
think
if
you
think
on
the
user,
I
mean
if
I'm
looking,
why
do
I
have
a
link
if
just
one
message
right,
it's
yeah
but
I,
think
we
cannot
make
a
decision
right
now,
but
I
think
I'll
put
this
again
next
week
on
the
agenda.
So
we
keep
discussing
it
because
I
think
we
should
nail
on
this
and
I
I
as
I
suspected
I.
B
Don't
think
we
had
a
decision,
so
it's
good
that
we
discussed
more
today,
so
I'll
put
this
next
week
and
and
we'll
see,
I
will
ping
on
the
chat,
because
I'm
not
sure
if
next
week,
I
will
have
time
to
prepare,
but
I'll
I'll
I'll.
Let
you
know
in
advance:
yes,
I
have
to
do
some
stuff,
but
I
I'll.
Let
you
know
if,
if
that
is
the
case,
all
right
yeah
and
we
didn't
get
to
your
point.
B
Neither
sorry
I'll
also
put
this
there
at
the
top
last
week
next
week,
so
we
we
make
sure
to
go
through
it.
If
you
have
anything
to
prepare
to
to
present
for
this,
then
yeah
feel
free
to.
B
Yeah,
this
is
I,
guess
part
of
what
we're
trying
to
to
to
spec
out
the
the
links
and
so
on,
because
with
the
links
we'll
be
able
to
follow
the
message
end
to
end
without
the
intermediaries
and
and
broker
instrumentation.
But
from
producer
you
will
be
able
to
see
all
the
consumers
in
everywhere.
It
ended
up
to
not
sure
if
that's
what
you
mean
with
the
end-to-end,
but.