►
From YouTube: 2022-01-14 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
E
C
C
C
So
we
have
three
topics
under
the
date.
The
cloud
event
semantic
conventions
full
receive
instrumentation,
that
is
like
would
like
to
discuss
some
work
that
the
miller
did,
and
that
is
from
a
check
about
the
kafka
cluster
id.
I
saw
this
issue
so
maybe,
let's
start
out
with
cloud
events
then
talk
about
the
the
issue
track
submitted
and
then,
let's
I
think
we
can
use
the
rest
of
the
meeting
to
discuss
the
document
that
luke
midler
came
up
with,
because
I
think
that
will
take
take
most
of
our
time.
B
D
Yes,
yeah,
so
it's
just
that
I
got
some
approvals
there,
but
I
I
don't
know
what
else
ludmila
just
just
told
me
that
there's
some
unsolved
discussion,
so
I
I'm
always
not
100
sure
if
I
should
resolve
them
or
or
if
others
should,
but
I
guess
there's
there's
some
some
discussion
that
are,
I
guess,
probably
clear
at
this
point,
so
I
can
just
mark
them
as
resolved,
and
this
might
signal
signal
people
that
that
is
ready
to
be
merged
and
so
on.
D
A
I
think
you
should
go
ahead
and
resolve
those
conversations
if
they
are
resolved
if
they
aren't
poke
the
person
on
the.
A
To
confirm
with
you
that
they're
happy
with
what
you're
doing
but
yeah
you've
got
got
two
approvals,
so
that
should
be
enough
going
forwards.
I
mentioned
this
in
the
other
spec
meeting,
I'm
going
to
try
to
get
members
of
this
group
added
as
spec
approvers
for
the
semantic
convention
sections.
A
So
our
our
own
approvals
for
this
should
count
for
something
so
that
should
help
speed
up
in
the
future.
So
we're
not
getting.
Some
of
the
other
pr's
are
getting
stuck
on
review
from
from
other
people.
D
A
C
Awesome
then
check:
do
you
want
to
talk
about
your
issue
quickly.
F
Yeah
sure
so
I'm
new
to
the
this,
this
messaging's
sig
I
haven't
attended
before
this
came
about,
because
somebody.
F
Thank
you.
Thank
you.
I
work
on
the
open,
telemetry
java
project
there,
but
you
know
I
just
haven't
gotten
involved
in
messaging
from
a
semantic
convention
standpoint
much,
but
somebody
internally
that
is
working
on
some
instrumentation,
expressed
a
desire.
I
work
at
new
relic,
so
they
they
expect.
It
expressed
the
desire
to
include
this
cluster
id
because
we
have
customers
that
are
using
environments
that
have
multiple
kafka
clusters
in
them.
And
you
know
I
did
some
research
about
the
cluster
id.
F
C
Yeah,
I
also
think
it
should
be
a
no-brainer,
but
to
give
you
a
bit
of
context
where
we
are
at
with
our
work
group.
Currently,
we
are
basically
trying
to
get
the
semantic
conventions
were
currently
experimental
to
a
stable
state,
and
that
involves
some
refactoring
of
the
whole
spec
as
it
is
there
currently.
So
we
are
just
basically
discussing
like
for
the
very
basics
like
context,
propagation
span
structure
and
at
some
point,
hopefully
soon
in
the
future.
C
We
will
get
through
to
discussing
like
the
attributes
that
we
want
to
have
on
there,
and
I
would
prefer
them
to
to
discuss
this
issue
once
we
are
discussing
attributes.
F
Okay,
so
basically
you
don't
want
this
to
be
noise.
That
gets
in
the
way
of
the
other
stabilization
efforts
right
now
and
we
can
address
it.
You
know
once
some
of
the
other
issues
are
resolved.
C
Yes,
and
that
should
be
soon
because
we
plan
to
I
mean
our
goal
is
to
be
stable
at
the
end
of
q1
of
this
calendar
year
so
march.
So
I
I
I
hope
we
will
get
to
discussing
attributes
soon
and
I'm
not
sure
if
you
have
any
time
constraints
on
there.
C
If
you
can,
if
you're
willing
to
wait
that
long,
because
we
have
also
this
issue
tagged
and
are
also
then
basically
before
we
declare
stable,
we
will
check,
like
all
the
issues
that
attack
this
messaging
and
see
whether
whether
those
are
resolved
or
whether
those
then
can
be
restored
after
we
go
stable.
F
Yeah,
that
sounds
that
sounds
reasonable
to
me.
I
might
do
some
experimentation
with
the
java
instrumentation
to
see
how
reasonable
it
is
to
actually
capture
this
field,
and
you
know,
based
on
the
results
of
that,
I
can
provide
feedback
on
this
issue
as
well.
So
some
experimentation
would
be
great.
Okay,.
A
Yeah,
I
mean
we're
we're
definitely
interested
if
you
understand
kafka
in
kafka
feedback
in
general,
about,
like
johannes
mentioned,
about
the
actual,
like
in
general,
the
structure
of
the
spans
that
we're
providing
the
information
we're
providing
in
general
around.
B
A
But
beyond
just
like
you
know,
is
there
an
attribute
missing?
Is
there?
Is
there
anything
more
fundamental
about
the
way
we're
currently
capturing
that
information
that
could
be
improved?
So
definitely
any
kind
of
like
report
back
would
be
helpful.
There.
F
Yeah
so
my
my
day,
job
is
switched.
I
used
to
build
apps
and,
and
kafka
was
a
big
part
of
that,
and
but
I
work
on
open
telemetry
now,
but
you
know
just
some
initial
feedback,
because
everything
checked
out,
nothing
seemed
you
know
outlandish
to
me
in
my
like
initial
review
of
the
semantic
inventions
that
exist
so
so
far
so
good.
This
just
stuck
out
as
like
a
bit
of
an
omission
but
yeah
everything
seemed
reasonable
great.
Thank
you.
C
Awesome:
okay,
so
we
here
we
have
this
tag,
then
we
will
basically
discuss
this
and
edit,
I
think
very
likely
when
we
come
to
to
discussing
the
attributes
in
general,
sounds
good
thanks.
C
Then
we
have
this
document
that
miller
put
together
to
give
some
context.
We
were
there's
a
first,
a
draft
there's
a
first
first
draft
forward
for
the
for
the
consumer
side
instrumentation
for
semantic
conventions.
I
put
that
in
the
otap
and
based
on
that
kind
of
ludmilla
kind
of
reviewed
that
and
found
some
shortcomings
when
it
comes
to
a
pool
instrumentation.
E
Yeah
I
I
would
like
to
go
through
this
document
and
share
what
they
think
we
should
do.
E
E
Yep,
perfect,
okay,
so
the
thing
I'm
focusing
on
is
this
evade
client
that
receive
code.
So
this
is
what
people
write
with
many
systems
like
with
sqs
kafka,
there's
rabbit
tempe
with
azure
sdks.
So
this
I'm
thinking
about
this
as
more
from
the
code
perspective,
but
we
will
get
into
the
with
what
happens
inside.
E
E
We
have
to
start
and
stop
spends
within
the
scope
of
this
operation,
and
otherwise
it
will
be
very
unreliable
and
yes-
and
we
we
don't
know
what
happens
after
so
this
instrumenting
this
course
is
very
important,
because
this
is
the
only
thing
we
can
get
from
some
applications
in
terms
of
like
how
many
messages
they
were
received.
Did
you
achieve
anything
like
okay?
So
I
have
some
motivation.
Why
it's
important?
E
I
think
we
are
on
the
same
page
here,
otherwise
raise
your
hand
and
then
how
I
think
this
instrumentation
should
look
like
so
well.
E
So
we
ideally
we
have
this
received
spam
that
matches
client.receive
duration
and
outcome,
and
it
has
links
to
this
context
and
if
something
happens
underneath
so
like,
let's
say
it's,
the
sdk
pulls
messages
from
the
broker.
Then
the
the
transport
calls
they
will
naturally
appear
here.
We
won't
need
to
do
anything
special
to
make
it
happen.
E
So
the
let's
say
https
would
be
the
child
of
the
receive
operation,
but
it's
it's
a
different
instrumentation.
We
are
not
going
to
talk
about
it
here.
So
what
happens
that?
Additionally,
if
there
are
so
many
logs
written
by
sdk,
if
you
want
to
get
into
the
width
of
what
went
wrong,
then
they
will
also
be
correlated
right.
E
E
So
there
is
a
problem
with
this
approach
that
we
don't
have
links
at
the
start
time,
so
the
receive
starts
before
messages
are
received
right
and
even
with
privileged
systems.
They
it's
just
a
corner
case
that
the
the
messages
are
available
beforehand,
so
how
people
usually
do
this
receive.
E
They
give
you
the
users
tell
okay,
give
me
messages,
10
messages
during
10
seconds
time
out
right
and
if
you
got
9
and
10
never
arrived,
you
will
wait
10
seconds
and
then
you
will
get
your
nine
messages,
so
profit
doesn't
help
here
and
I
believe
we
shouldn't
have
a
special
case
for
it
and
anyway,
so
wing
said
start
time.
E
So
what
can
we
do
about
links
availability
at
start
time?
I
think
we
have
three
options
by
the
way.
Any
questions
comments,
anything
so
far.
E
Okay,
okay,
so
I
think
the
three
options
are,
we
are
going
to
delay
spawn
start.
It
has
some
significant
drawbacks,
we'll
guess
right
now
we
can
allow
adding
links
after
starting
span.
E
This
is
what
I'm
going
to
argue
for
and
the
third
options
we
can,
I
don't
know
hulk
it
around
with
more
expense
without
any
changes
to
tracing
step.
So
let
me
go
into
the
details
of
which
option.
E
So
this
is
option
one.
We
are
delaying
this
fast
start.
We
can
fake
start
time
so
like
it
will
look
natural
like
it
will
property
users,
but
if
something
happens
underneath
whether
it's
a
http
request
or
if
it's
a
log
record,
it
won't
be
correlated,
we
cannot
fake
it.
It
will
be
very
hard
to
pass
any
context
to
the
http
instrumentation
before
we
didn't
create
the
context.
E
So
this,
I
think
this
is
what
happens
now,
but
I
think,
though,
it's
more
like
an
option.
Sorry,
what
current
spec
has.
So
this
is
the
picture
I
showed
you
initially.
I
think
this
is
ideal
outcome.
The
option,
two,
if
we
add
links
after
stun,
starts
we'll
talk
about
the
drawbacks
about
sampling
a
second
later.
Let
me
show
you
the
options
three,
so
we
add
more
spence
and
we
say:
okay,
there
is
a
receive
span.
E
Okay,
so
this
this
is
something
we
can
do
today,
but
it
increases
user
bill
at
the
cost
of
this
receive
span,
it's
not
ideal,
but
I
think
we
can
go
with
it.
So
what
are
the
reasons
to
not
do
two?
E
E
If
we
let
add
links
after
we
cannot
make
a
different
sampling
decision,
then
at
least
this
is
way
more
difficult
discussion
than
anything
we
do
here.
I
think
anyway,
so
then,
let's
talk
about
sampling.
E
E
So
my
point
here,
I'm
trying
to
make
that
sampling
probably
is
bad
either
way,
and
I
would
like
to
ask
to
discuss
if
we
can
do
option
two
and
before
we
go
on.
I
would
like
to
share
a
few
more
things.
I
came
up
with,
let's
call
the
short
any
questions,
any
concerns
anything.
A
E
C
I
mean
there's,
there's
no
none
of
the
samplers
in
this
back
consider
links
currently,
but
I
can
tell
from
from
my
own
experience
like
when
my
team
really
recently
implemented
a
link-based
sampler
that
works
like
similar
to
the
parent-based
sampler
and
basically
make
sure
that
every
expanse
with
sampled
links
are
also
sampled.
C
So
that's
what
my
team
did.
Maybe
there
are
other
ones
out
there
and
it's
actually.
It
is
some
it's
some
thing.
That
is
it's
a
natural
thing
that
you,
it
seems
to
me,
diverge
to
when
you're
working
heavily
with
links
and
want
to
ensure
complete
phrases.
C
G
I
I
just
had
one
other
idea
about
a
model
that
might
work
and
it's
it's.
It
shares
some
similarities
to
option
three,
but
it's
not
quite
as
drawn
in
option
three,
where
each
message
that
like
so
the
way
I
see
it
is,
is
like
an
application
is
calling
receive
to
get
perhaps
many
messages
and
the
sdk
is
then
delivering
one
or
more
messages
up
to
the
application,
and
so
I
could
see
that,
where
the
delivery
span
drawn
there
is
has
links
to
all
the
messages.
I
could
imagine.
G
Each
message
that
is
being
delivered
is
its
own
span,
so
the
deliver
would
be
a
child
of
receive
and
it
would
have
a
single
link
to
its
create,
and
in
that
way,
if
you
had
asynchronous
delivery,
the
modeling
would
look
identical,
except
that
that
top
level
app
like
kind
of
application
received
call
a
span,
isn't
there,
so
the
modeling
is
the
same
for
asynchronous
and
synchronous.
G
It's
just
with
the
synchronous
call
that
could
return
a
batch.
You
have
a
an
additional
span
in
the
middle.
Does
that
work,
or
does
that?
Does
anybody
like
that
or
I
don't
know?
If
any,
does
people
understand
it?
First
of
all
what
I'm
saying.
C
I
mean
that
it's
an
interesting
option.
I
mean
I,
I
think
one
von
kong,
I
think
about
this
in
this
option-
is
that
where
there
might
be
quite
a
lot
of
more
spends,
because
when
you
receive
like
in
a
badge
when
you
receive
hundreds
of
messages,
you
have
like
hundreds
of
deliveries
plans,
I
mean
a
pro.
I
see
this
approach
is
that
it
makes
it
more
transparent,
makes
things
more
transparent.
C
If
we,
for
some
reason,
are
lacking
those
creation
contexts,
because
then
we
would
still
see
deliveries
bands
for
each
message,
we
would
not
have
the
link,
but
we
still
would
see.
Basically,
we
could
like
put
message
details
into
this
delivery
spans,
like
I
don't
know,
message,
message,
ids
or
other
things
that
would
help
us
to
identify
messages
without
having
this
creation
context
present.
G
Yeah,
I
mean
that's
what
I
like
about
it
too,
and
in
fact
there
you,
you
have
the
ability
to
include
like
message:
ids
that
might
not
be
available
and
create,
like
that,
are
relevant
to
a
messaging
system.
That
would
help
correlate
it
back
to
the
actual
message
itself.
E
D
Okay,
but
but
the
like
thinking
on
the
delivery
spend,
can
the
instrumentation
always
create
a
delivery
span?
Isn't
the
case
that
in
some
cases
you
cannot
create
as
well.
E
In
case
of
option
three,
like
it's
part
of
the
receive
instrumentation
right
once
messages
are
there,
it
can
always
create
a
delivery
span,
and
here
we
will
have
delivers
pen
when
we
just
when
there
is
a
push
model
right.
That's
what
we
discussed
I
think
months
ago
last
time,
so
the
your
semantics
might
match,
but
not
doesn't
have
to
right.
D
Because
the
sdk,
then
the
application
calls
this
receive
from
the
sdk,
and
the
idea
is
that
the
sdk
does
does
its
does
its
work
to
to
fetch
to
pull
this
meshes
whatever
manner
it
does
and
then
prior
to
actually
sending
the
the
result
of
the
application,
then
it
creates
this
delivery
span
right.
D
But
the
case
that
duan
just
explained-
and
we
will
just
loop
on
this
and
create
spam
for
each
and
and
pass
one,
but
but
what?
If
the
sdk
doesn't
want
to
to
pass
an
individual
message
as
a
list
that
wouldn't
work
as
well
right.
D
Right,
yeah!
No,
but
if
we,
if
we
go
with
this
route
of
creating
many,
then
that's
the
case.
We
have
to
change
to
do
this
right,
there's
no
way
around
to
create
one
delivery
to
each
message
right,
so
it
will
have
to
do
this.
Sir,.
D
If
you
go
to
the
line
to
the
code,
the
sample
code,
that
you
had
there
with
the
receipt,
so
my
application,
I
call
receive
right
so:
okay,
let's
say
client
receive,
which
is
the
sdk
code,
so
the
sdk
then
pulls
the
messages
and
and
whatever
and
then
it
needs
it
returns
me
this
press,
that's
this
list
of
messages
right,
but
at
that
point,
when
I
get
to
the
second
line,
the
delivery
spans,
they
are
they're
already
created
right
yeah.
It
was
it's
done
already.
D
So
in
order
to
do
that,
then
the
sdk
has
to
do
all
this
work
right
to
loop
into
the
messages
and
then
create
one
span
for
for
each
linking
to.
A
G
One
thing
you
mentioned
is
that
we
can
include
attributes
in
the
link
and
so
whether
it's
a
link
or
a
span
is
mostly
a
visualization.
I
think
there's
one
comment
you
made
and-
and
that
makes
sense
at
first
but
one
concern.
I
think
that
johanna
suggested
was,
if
you
don't
have
the
context
and
you
can't
create
the
link,
then
there's
no
ability
to
kind
of
communicate
those
attributes
and-
and
so
with
this
with
a
span,
you
don't
need
to
be
able
to
create
the
link
back
to
creation
context.
E
C
Yeah,
I
have
another
other
like
two
more
remarks
here
in
the
first
remark,
it
was
two
option
three
and
actually
another
com.
That
came
to
my
mind
for
option
three,
because
here
we
have
this
delivery
span,
but
then
again,
this
was
also
some
discussion
that
we
had
before
what
would
be
a
duration
for
this
delivery
span.
That
would
make
sense.
Basically,
I
think
we
do
not
have
really
like.
We
cannot
give
like
this
delivery
span,
a
semantically
kind
of
a
meaningful
duration.
C
We
just
basically
need
it
as
more
or
less
a
dummy
span
to
create
the
links
to
the
creation
contexts
and
that
that
smells
a
bit
fishy
to
me.
C
We
didn't
discuss
the
create
in
detail
yet
so
we
don't
have
that
written
down
yet,
but
I
think
I
mean
to
me
it
always
seems
a
bit
weird
to
have
like
yeah
star
spans
with
dummy
durations
and
they
know
like
backhand
systems
for
for
expansion,
for
example,
zero
duration.
C
It's
actually
like
there's
some
like
data
quality
warnings
go
off
if
you
get
if
if
those
bands
are
are
received,
so
I
think
we
should
try
to
avoid
that
and
and
and
so
that
that's
kind
of
a
an
additional
con
for
this
to
this
solution.
And
another
thing
I
just
that's
a
very
high
level
thing.
I
want
to
mention
here
just
to
make
it
clear
that
it
seems
here
then
for
for
push
and
pull
based.
As
the
case,
I
think
we
are,
we
are
basically.
C
I
think
we
all
kind
of
agree
that
this
delivery
span
makes
sense
that
basically
captures
this
duration
of
the
callback,
and
here
now
for
pull
based
sdks,
where
clients
basically
call
to
get
messages
from
the
sdk
we
are.
We
are
approaching
like
a
different
solution,
so
we
will
kind
of
have
most
likely
two,
maybe
slightly
different
instrumentation
solutions
in
the
end,
and
I
think
we
should.
E
C
Yes,
that
was,
I
was
trying
to
get
that.
I
think
we
have.
We
are
approaching
basically
two
different
instrumentation
solutions
there,
but
I
think
we
should
still
try,
while
keeping
the
meaningful
different
to
also
make
them
as
as
kind
of
coherent
as
possible,
so
that
they
don't
look
like
that.
We
don't
use
completely
different
terms
and
span
names
in
both,
but
maybe
try
to
keep
them
as
consistent
as
we
can
without
losing
clarity.
E
Yeah,
I
think
once
we
figure
out
the
other
pattern,
we
need
to
look
how
those
two
patterns
work
together,
because
there
is,
for
example,
there
is
a
kafka
java
library
and
you
can
only
do
pool,
but
then
there
is
a
spring
integration
which
also
does
the
delivery
and
processing.
So
you
will
end
up.
Users
will
end
up
with
both
patterns
in
the
same
place,.
A
I
have
a
question
or
just
a
clarification.
I
don't
think
the
push
model
has
this
problem,
but
with
this
pull
model,
is
it
also
the
case
that
we
can't
use
instrumentation
to
automatically
generate
all
of
these
spans
just
because
of
the
shape
of
the
code?
The
end
user
is,
is
forced
to
do
some
amount
of
manual
spam
management.
Is
that
the
case
or
or
am
I
misreading
the
code.
E
So
let's
say
we
pick
connections
here
right.
So
this
all
this
happens
magically
okay,
but
it
ends
with
the
receive
call.
So
if
those
messages
are
dropped
on
the
floor
with
exception
some
sort
of
user
code,
nothing
will
track
it.
At
least,
nothing
will
correlate
this
information
great
but
like
there
could
be
more
things
on
top.
E
A
C
I
mean,
I
think,
if
you
would
have
other
like
process
bands
or
saddle
spans.
Those
would
then
basically
be
like
maybe
siblings,
of
this
receive
span,
so
they
wouldn't
be
like
directly
parented,
but
it
would
kind
of
be
indirectly
connected,
maybe
via
skipping
relationships
and
maybe
also,
if
we
put
the
needles
back,
that
we
say.
Okay.
The
process
ban
should
also
link
to
the
create
context.
Then
they
would
also
basically
be
kind
of
one
would
be
able
to
correlate
them
via
this
shared
link
to
the
creation
context.
C
G
I
I
I'm
finding
as
we
implement
things
in
our
in
our
broker,
that,
like
just
by
the
nature
of
all
much
of
this
being
very
asynchronous,
that
most
spans
are
inherently
very
short
duration
like
if,
if
you're
doing
a
synchronous
thing,
and
then
this
is
an
example,
you're
synchronously
calling
received
it,
it's
very
logical
to
have
a
start
and
an
end.
But
much
of
what
you
do.
That's
asynchronous.
But
it's
a
an
interesting
thing
along
the
journey
of
a
message
through
your
system.
G
Sure
you're
executing
a
section
of
code
but
you're
rarely
blocking
and
waiting
on
something.
And
so
you
can
take
a
start
timestamp
when
you
start
running
that
and
you
do
something
and
you
take
a
timestamp
at
the
end
and
you're
probably
going
to
be,
like
I
don't
know,
50
or
100,
nanoseconds,
duration
and
and
that's
kind
of
the
nature
of
an
asynchronous
system.
And
I
I
I
don't
know
if
I
need.
We
need
to
discuss
that
right
now,
but
I
think
it's
an
issue
that
comes
up
with
with
asynchronous
systems.
G
I
don't
know
if
we
want
to
talk
about.
Is
that
kind
of
thing?
Okay,
or
is
that
a
problem?
I
don't
know
what
the
thinking
is
there.
D
C
I
think
the
one
of
the
key
points
is
here
that
yeah
you
can
have
like,
like
some
spans,
that
just
take
nanoseconds
and
that
probably
does
not
make
sense
once
you
have
lots
of
spans
because
then
just
to
spend
three
gets
very
unbuilding,
but
I
think
the
key
point
is
that
you
have
some
fixed
thing
that
you
measure
the
duration
of
and
for
those
bands.
C
G
G
But
if
we
had
to
deliver
spam
per
message
inside
of
receive,
if,
if
you're
blocking
up
to
10
seconds
and
got
nine
messages,
would
it
be
interesting
to
know
that
the
nine
the
first
nine
showed
up
at
the
very
beginning
of
the
call?
And
then
you
sat
there
for
nine
point,
nine
more
seconds
to
wait
for
the
tenth
one
and
then
returned
like
is
that
that
seems
like
it's
still
useful
information,
even
if
the
durations
of
the
delivery
spans
are
very
short.
G
And
I
think
the
problem,
though,
with
I
makes
sense
because
events
have
a
time
stamp
and
that's
what
we're
trying
to
capture
something
happening
at
a
point
in
time,
but
the
problem
with
a
lot
of
asynchronous
things.
Is
you
don't
know
when
the
next
thing
is
going
to
happen
and
long
spans
are
problems
right,
like
with
long
spans,
long
traces
are
problems,
and
so,
if,
if
something
takes
an
hour
or
two
right
first
to
happen,
do
I
keep
the
span
open?
G
G
It's
queued
up,
it's
delivered
at
some
point
in
the
time
in
the
future,
it
would
be
very
natural
to
have
one
span
of
it
traversing
through
and
events
that
when
it
when
it
was
persisted
when
it
wasn't
queued
when
it
when,
when
delivery
attempts
were
made
and
when
it
was
acknowledged
and
stuff
like
that,
but
but
that
can
take
you
know
that
could
take
days
or
you
know
you
don't
know
how
long
it'll
take
and
so.
H
Why
is
that?
Why
does
that
matter
like
if
I,
if
I
have
a
message
that
passes
through
a
broker
and
literally
just
takes
a
millisecond
or
it
because
there's
an
active
receiver
which
just
asks
for
it
or
the
message
is
being
sent
and
then
just
sits
there
for
a
day
and
then
the
act,
the
receiver
shows
up
and
pulls
it.
H
H
A
We
tend
to
not
want
to
use
spans
to
model
something
passive
is
one
answer.
A
There's
a
practical
answer
of
a
lot
of
these
systems
benefit
from
not
having
like
indefinitely
long
spans,
but
I
think
the
thing
we're
trying
to
the
the
model
in
general
we're
trying
to
go
for
is:
if
there's
some
active
processing
happening,
resources
are
being
consumed,
then
we're
using
spans
to
model
those
operations
and,
if
you're
talking
about
something
that's
more
passive
like
something
was,
you
know
put
in
some
cube,
but
it's
been
put
into
storage
or
otherwise
it's
it's.
It's
just
passively
sitting
there.
A
It's
not
it's
not
being
actively
processed.
At
some
point.
We
want
to
not
use
a
span
to
measure
those
kinds
of
periods,
so.
H
You
have
a
so
so
you
have
a
scenario
where
you're
choosing
to
only
process
data
at
two
times
a
day
because
you're
a
bank
and
even
though
you
could
do
things
faster,
it
actually
benefits
your
bottom
line.
If
you
don't
process
all
the
time,
so
you
get
a
ton
of
messages,
but
you
let
those
messages
pile
up
for
12
hours
and
then
you
choose
to
go
and
tap
into
the
messages
and
process
them.
So
that's
like
all
of
the
send
and
receive
operations
are
still
there
they're.
H
Arguably
long-lived
you
know,
depending
on
what
you're,
what
your,
what
your
perspective
is,
but
they're
still
a
overall
kind
of
between
producer
consumer,
one
activity.
A
B
H
A
H
A
I
think
I
correct
me
if
I'm
wrong,
but
I
believe
that
the
general
model
we're
going
with
is
that
when
things
go
into
a
broker
and
come
out
of
a
broker
like
where
that
that
is
considered
an
async
asynchronous
junction,
so
we're
not
trying
to
model
one
continuous
trace
that
goes
through
processing
on
this
side
and
through
the
brokers
and
then
processing.
On
the
other
side,
you
have
a
trace
on
one
side
of
the
processes
that
are
processing
messages
and
putting
them
into
the
broker.
H
Traces
together,
so
there's
a
there's,
a
control.
There's
a
control
transfer
happening
here.
Right,
there's
a
you
you,
the
producer
sends
a
message
with
the
intent
of
having
a
job
executed
and
then
a
consumer
picks
up
that
message
and
now
gets
the
command
of
executing
a
job,
formulates
a
reply.
Message
maybe
and
then
goes
and
sends
that
reply
message
to
an
indicated
reply
destination,
which
is
another
cue
and
then
ultimately,
that
reply
message
shows
up
at
the
at
the
producer.
H
That
now
knows
that
that
job
has
been
executed.
That
is
the
same
as
the
request
response
operation.
It's
just
running
through
an
asynchronous
path
and
may
take
may
take
a
day
while
a
typical
rpc
call
will
will
do
this
in
a
few
milliseconds.
So
I
believe
that
it's
valuable
to
trace
that
journey
completely.
A
I
think
we're
looking
at
in
this
working
group,
not
we're
not
currently
focusing
on
what
kind
of
tracing
data
with
the
the
brokers
and
other
pieces
of
infrastructure
emit.
Am
I
correct
in
that
johannes?
Like
we're?
Thinking
of
you
know
you
could
get
from
those
things
would
be.
We
want
to
circle
back
up.
C
We
have
like
operations
that
we
measure,
that
is
an
operation
where,
like
the
sdk
or
the
broker,
actually
does
something
we
create
a
spam
for
that,
and
we
have
an
obvious
also
like
other
things,
like
other
durations,
for
example,
a
duration,
where
message
just
sits
somewhere
and
waits
for
being
processed,
or
nobody
is
actively
doing
something
with
the
message,
and
we
have
those
like
operations
where
we
do
something
and
from
those
operations
where
we
do
something,
and
we
try
to
infer
the
duration
of
those
of
the
time.
C
For
example,
when
the
message
sits
somewhere
and
nothing
is
done
with
the
message
when
the
message
just
sits
somewhere,
we
don't
time
this
operation,
we
don't
kind
of
have
a
timer
running
that
that
measures.
How
long
is
the
massachusetts
sitting
there
and
trust
waiting
for
being
processed?
We
have
like
a
operation
that
puts
the
message
somewhere.
Then
we
have
operation
that
takes
the
message
from
somewhere
and
then
from
those
two.
C
We
can
infer
the
duration
that
the
message
was
just
sitting
and
waiting
for
being
processed,
and
I
I
think
those
those
durations
that
we
infer
like
where
about
how
long
the
message
is
kind
of
just
lying
some
somewhere
that
we
infer
from
the
other
from
two
other
operations.
We
cannot
make
any
assumptions
about
this
duration
as
kamen
says
that
can
be
nanoseconds.
That
can
be
days
so
I
think
from
these
durations.
A
Yes,
yes,
and
I
think
that
to
to
maybe
answer
dwayne's
question
when
it
comes
to
modeling
things
with
spans,
spans
are
kind
of
expensive
and
course
grade,
and
so,
if
you're
looking
at
an
operation
where
it's
going
to
take
nanoseconds
and-
and
it's
not
like
the
situation-
clemens
is
talking
about
where
it's
like
it
could
take
a
variable
amount
of
time
to
do
this
operation,
and
actually
you
would
want
to
measure
that
time
if
it's
an
operation
where
it's
like
this
reliably
takes
nanoseconds
to
do
and
as
an
operator
trying
to
debug
this
system,
I'm
never
going
to
care
about
this
span
right.
A
I'm
never
going
to
set
up
an
alert
and
look
at
the
distribution
of
times
that
the
span
takes
because
it's
just
it
might
be
a
conceptually
important
operation,
but
operationally
it's
it's
trivial
and
somewhat
reliable
in
how
long
it
would
take.
Then
those
kinds
of
things
we
tend
to
want
those
to
be
events
rather
than
spans,
because
the
duration
is
not
something
that
you
necessarily
care
about
you
care
about,
knowing
that
it
happened.
You
care
about
knowing
when
that
happened
relative
to
other
things,
you
care
about.
A
The
attributes
and
all
of
this
other
information,
as
far
as
like
being
able
to
do
graph
analysis
on
the
the
whole
thing,
but
because
fans
cost
money
and
they're
more
expensive
than
events.
If,
if
the
the
variation
in
duration
is,
is
not
likely
to
be
something,
the
operator
is,
I
would
say
strongly
not
likely
something
to
be
the
operators
interested
in.
Then
we
try
to
use
events
for,
for
those.
G
Okay,
but
I
assume,
though,
that
I
guess
for
an
event:
you
need
a
span
to
put
the
event
in.
That
is
right.
So,
if,
if,
if
you
have
a
single
thing,
you're
doing
all
on
its
own,
that's
one
of
these
very
quick
things
and
there
is
no
span.
Then
you
need
to
create
one
for
that.
Unfortunately,
but
that's
it's
good
good,
common
good
feedback,
because
there
are
other
like
there
are
some
of
those
situations
that
we've
run
into
there
are
other
ones
where
I
think
we
actually
could
use
could
use
events.
G
So
it's
it's
and
attach
it
to
another
span.
So
to
speak,
but
but.
A
I
I
I
should
say
there
even
in
that
situation,
if
you're
like
there's
no
span,
so
I
got
to
create
one
well
now
you
have
a
span
floating
in
space,
and
so
it
is
okay
for
instrumentation
to
say
I'm
going
to
get
the
current
span
whatever.
That
is
whatever
context.
I'm
doing
these
operations
in
and
then
gonna
write
these
events
to
that
that
span
so.
A
Right
right
and
then
maybe
there's
a
case
where
it's
like:
there's
no
span,
I
don't
know,
what's
going
on,
there's
just
no
spans
happening,
but
in
those
cases
well
it
wouldn't
quite
work.
This
way
right
now,
because
we're
using
span
events
but
in
the
future,
when
logging
is
put
into
our
system,
you
still
wouldn't
lose
that
information
right.
It
would
just
be
like
well,
there's
no
span
context
to
attach
these
events
to
I'm
still
going
to
give
you
the
events.
A
So
you
understood
that
those
events
came
out
of
this
process
and
perhaps
there's
something
weird
going
on
and
like
there
should
be
a
span
that
contextualize
these
events,
but
you
wouldn't
you
wouldn't
just
drop
that
data
on
the
on
the
floor,
which
would
be
the
case
right
now,
because
you
would
get
a
you
would
get
a
no-op
span
if
there
was
literally
no
active
span
and
you
just
asked
for
the
current
one,
but
but
but
in
general
it
there.
A
If
you
were
creating
spans
there,
where
there
would
be
no
parent
span,
because
in
both
cases,
you're
still
at
some
point,
they're
asking
hey,
give
me
the
current
span
from
the
context
and
then
I'm
gonna
do
to
attach
something
to
it:
either
I'm
gonna
attach
a
child
span
or
I'm
gonna
attach
an
event,
and
so
I
guess
what
I'm
saying
is:
if
you
don't
care
about
the
duration,
just
go
ahead
and
attach
events
to
that
that
current
span
and
if
it
doesn't
exist,
then
in
the
future.
Those
events
would
show
up
as
free-floating
events.
G
The
only
trickiest
with
the
current
span
is
that
implies,
it
hasn't
ended
yet
right
and
yeah
yeah
and
in
particular
they're,
like
you
know,
and
when
it
comes
to
asynchronous
things
like.
So
when
do
I
end
my
span?
That's
the
tricky
thing
and
because
you
kind
of
want
to
know
that
that's
the
catch
22
is,
you
want
to
know
something
happened,
but
in
order
to
be
able
to
push
out
that
it
happened,
you
have
to
end
it
right
and,
and
then
it's
hard
to
attach
other
events
to
it
and
right
and.
A
Hopefully
there
is
some
bounding
when
you
are
doing
asynchronous
stuff.
There
is
hopefully
some
kind
of
bounding
context
in
which
that
asynchronous
stuff
is
happening
right.
You
know
so
you're
doing
a
bunch
of
asynchronous
stuff,
but
there
is
something
waiting
for
it
at
the
end
to
be
done,
something
that
kicked
it
off
and
is
waiting
for
it
to
be
done
and
the
tricky
bit.
I
think
in
some
of
these
runtimes
is:
do
you
have
access
to
to
that
context?.
G
Yeah
the
problem
is
like
I
send
a
message
to
an
application.
When
is
he
going
to
acknowledge
it?
I
don't
know
I'd
love
that
to
be
one
span,
I
I
sent
it
and
it
got
acknowledged.
I
sent
it.
There
was
an
error,
but
it's
not
practical
to
know
how
long
an
application
might
take
and
we
just
let
them
take
forever
if
they
want
so
anyways.
I
don't
want
to
get
too
much
in
this.
All
this
has
been
helpful.
I
don't
want
to
get
too
much
into
you
know,
I'm
thinking
about
broker
stuff.
C
F
C
I
I
think,
let's
try
to
start
differently
like
option.
Three
actually
is.
C
I
I
was
thinking
that,
when
you
have,
when
you
have
like
option,
you
can
make
option
three
with
this,
like
a
mindset
that
you
wanna
have
like
the
events
or
like
the
spans
for
every
single
message,
like
delivery
or
or
retrieval,
you
can
make
that
a
subset
of
option.
Two,
if
you
want
so,
you
can
add
like
additional
information
to
option
two
and
and
basically
have
like
the
information
that
we
talked
about
now
that
we
could
back
into
option
three.
We
could
have
that
in
option.
C
Two
two
we
can
pack
this,
we
can't
just
like,
could
add
like
additional
spans
there
with
like
the
the
information,
and
I
think,
that's
probably
how
we
will
end
up
anyway
in
the
end
like
what
we
will
specify
in
the
spec.
That
is
just
like
the
smallest
common
denominator,
and
then
sdks
can
add
to
that
as
they
want,
if
they
think
it
makes
sense
to
add
like
an
event
for
each
message
that
is
retrieved.
C
So
I
think
it
makes
also
sense
to
like
keep
keep
that
in
mind
that
we
are
we're
trying
to
spec
out
something
here
that
every
sdk
can
implement
and
then
on
top
of
that,
sdks
can
elaborate
and
add
additional
thing
things.
But
I
I
have
the
strong
impression
here
that
option
two
is
actually
the
more
extensible
one
compared
to
option
three,
which
I
think
is
some
for
me
like
an
end,
and
on
top
of
that,
if
it
is
possible
to
if
the
spec
allows
it
to
add
links
later
on
then
option.
C
E
D
But
how?
But
how
would
would
the
the
context
from
the
receive
be
in
the
same,
let's
say:
scope
of
the
underlying
things
that
or
this
http
get
is
from
the
sdk
code
as
well.
E
So
the
receive
will
be
a
root
spell
probably
right:
yeah,
it
will
get
links
and
it
will
also
be
active.
So
if
http
happens
in
scope
of
this
call
or
grpc
or
I
don't
know
sql,
then
it
will
but.
D
E
C
I
think
another
problem
here
of
what
we
talked
before
about
having
like
those
delivery,
spans
or
delivery
events.
The
delivery
I
mean
if
we
talk
about
prefetch,
might
actually
happen
before
this
receive
span
starts.
C
So
we
cannot
even
like,
like
you
know,
in
a
sensible
way,
kind
of
add
all
those
like
retrieve
events
for
each
message
to
the
receive
span,
because
in
when,
when
this
is
a
prefetch
operation,
then
the
message
might
already
be
like
fetched
before
receive.
D
C
D
C
D
Lingering
there,
okay,
but
then
that
means
that
operations
that
are
are
done
by
the
application.
After
calling
receipt,
then
it's
they're
just
siblings,
of
the
receipt
right
there.
They
cannot.
They
cannot
be
childs
off.
Okay,.
D
Course,
yes,
and
I
guess
there
might
be
some
sdk
that
can
make
it
work
in
a
way
that
they're
they're
they're
chilled
childs
of
the
receive,
but
I'm
not
sure
because
amir
had
some
examples
where
he
said
he
present
the
struggles
of
of
doing
this
in,
for
example,
in
javascript
right,
but
but
it
might
be
that
in
some
languages
that
it
could
be
possible,
maybe
they'll
pass
a
callback
or
something
I
don't
know,
but
yeah,
okay
yeah,
I
think
option
two.
It
doesn't
sound
so
bad,
actually.
C
So
we
are
at
about
time
now
I
think,
is
an
action
item
for
next
week.
I
I
posted
a
link
to
an
issue
in
the
chat
that
was
actually
about
allowing
adding
links
after
spank
creation.
C
I
will
maybe
ping
some
people
try
to
reactivate
these
issues,
because
there
has
not
been
much
like
answers
on
this
issue
and
maybe
also
asking
this
back
meeting
about
opinions
about
allowing
span
span
creating
spam
links
after
spank
creation.
C
I
think
from
the
sampling
point
of
view,
if,
if
I
see
it,
if
you
see
it
similar
to
attributes
that
shouldn't
be
much
of
a
problem,
because
we
also
allow
adding
attributes
after
the
creation
and
also
attributes
go
into
the
sampling
decision,
so
we
are.
We
are
also
like
at
the
at
the
at
the
like
similar
situation
there
that
we
could
predict
that
you
could
argue.
Are
we
going
to
have
like
a
similar?
We
wanna
have
it
working
similar
for
links
to,
because
I
I
I
think
we
we
kind
of
agree.
C
At
least
I
didn't
see.
I
didn't
hear
like
any
any
any
voice
against
that,
but
they
say
approach
two
seems
to
be
the
simpler
and
more
extensible
and
if
we
wanna
add
more
details,
as
we
discussed
about,
you
could
do
that
on
top
of
option
two,
but
actually
without
us
kind
of
putting
it
into
the
spec.
That
could
be
then,
like
some
sdk
specific
extensions.
E
I
can
try
to
look
into
the
allowing
the
issue
you
posted
about
allowing
creating
links,
and
I
can
try
to
join
the
stock
meetings
and
get
the
impression
how
people
feel
about
it.
C
A
Nice
yeah,
I
strongly
support
trying
to
get
links
added,
not
be
something
that
you
just
add
at
the
beginning,
and
I
think
the
I
think
there's
just
some
realistic
limitations
to
being
able
to
to
use
links
and
upfront
sampling.
Like
I
think
that's
that's.