►
From YouTube: 2022-02-24 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).
C
A
A
B
A
A
Yes,
so
not
a
real
location.
I
mean
we
have
a
like
a
efforts:
more
son,
he's
half
a
year
old
and
they're,
just
taking
off
some
apparent
leaf
time
and
yeah
using
it
to
make
her
house
baby
proof
as
he
starts
to
crawl
around.
So
he
will
do.
B
A
A
A
Starts
my
name
so
for
the
gender
today
amir
and
amir
last
time
he
he
showed
us
some
thoughts
or
some
concepts
for
a
producer
instrumentation,
and
they
said
that
for
this
week,
amy
and
ludmila.
They
offered
to
maybe
try
some
just
some
instrumentation
or
or
come
up
with
some
diagrams
for
us
to
get
a
better
idea
of
how
things
would
look.
A
It's
no
problem,
then
we
can
just
keep
discussing
through
it.
I
have
some
short
notes
about
the
discussions
regarding
adding
games
after
spank
creation.
That's
something
that
we
want
to
have
for
our
consumer
pool
scenario
instrumentation
and
so
just
to
give
an
overview
over
our
roadmap,
so
to
speak
or
of
items
that
we
need
to
discuss
here.
A
Thanks
to
them,
but
we
can
we
come
back
to
that.
Then
awesome.
A
E
A
Just
go
over
like
to
give
people
an
overview
of
where
we
are
here
and
then
we
can
get
started
so
producer
instrumentation,
that's
in
progress,
that's
what
we
are
currently
discussing
about,
and
here,
consumer
instrumentation,
like
the
poor
scenarios,
that
is
kind
of
still
marked
in
progress,
you're
painting,
some
clarifications
about
editing,
games
after
spank
creation
and
maybe
some
more
discussions
about
the
the
overall
proposal
itself.
But
those
things
are
currently
in
flight
and
then
the
last
thing
so
to
say
for
us
to
discuss
is
then
settlement.
E
Okay,
thank
you.
So
I
wanted
to
show
you
how
it
might
look
like
if
we
instrument
publisher,
either
with
spam
per
message
or
without
so
with
this
I'm
going
to
share
my
screen.
I
I
don't
want
to
show
code,
it
makes
no
sense,
but
it's
just
a
bunch
of
ugly
code.
Okay,
I'm
opening
something
else
here.
E
Okay,
so
if
you
remember
last
time
we
talked
about,
let's
say
we
have
batch
sent,
we
have
a
couple
of
messages
and
we
publish
them
as
in
one
batch.
E
I
can
zoom
in
if
you
want
okay
so
and
in
this
example,
I
have
those
spans
and
they
are
maybe
zooming
in
was
not
a
great
idea.
So
then
they
are
processed
separately
in
two
other
different
batches,
sorry
as
a
part
of
some
other
batches.
E
E
Okay,
so
in
jaeger,
similarly
right
jager
shows
published
as
a
child.
It's
not
a
child.
It's
just
a
visual
effect.
Publish
has
links
to
this
message
spends
right,
the
first
one,
the
second
one,
if
I
click
on
okay.
Actually
it
cannot
jager
cannot
show
me
the
consumer
side,
but
I
can
go
and
check.
I'm
sorry,
yeah.
E
Okay,
but
if
I
have
a
delivery
span
it
it
would
also
have
links
according
to
what
we
discussed
and
I
can
go
and
see
the
trace
for
this
pen.
Okay,
so
this
is
sorry
the
trace
for
the
link.
This
is
the
case.
There's
multiple
message,
spams
right
and
just
to
reiterate,
we
got
some
feedback
from
users
that
they're
not
happy
about
this
picture.
This
might
be
confusing
the
the
fact
that
publish
spend
how
it
appears
where
it
appears
like
it's
hard
to
visualize,
but
maybe
it's
just
a
visualization
problem.
A
A
E
I
don't
know
I
maybe
I
just
so
different.
Let
me
bring
it
back,
so
it's
a
great
question.
So
in
my
mock-up
I
actually
made
message
spent
to
finish
with
after
publish
completes
and
this.
This
shows
that
I
created
it
when
I
I
I
was
publishing
this
message,
but
because
I
have
to
start
the
span
after
I
start
that
one
to
create
a
link
right
on
on
this
pen,
so
they
are
meaningful
in
a
way
there
they
would
be.
E
A
E
E
A
Here
about
monitoring
is
that
that
one
message
spam
basically
started
before
the
publish
span,
and
I
think
they
wouldn't
expect
that
in
in
actual
use,
because
I
think
the
idea
is
that
we
are
published
a
patch
that
would
be
the
public
span
and
then,
after
that,
publish
or
during
or
after
the
publish
operation,
those
message
spans
are
created.
E
So
there
is
this
publish,
call
right
and
inside
this
call
if
we
were
what
we
do
currently
that
can
produce
this
picture.
Is
that
inside
this
call?
We
know?
Okay,
we
have
that
many
messages
and
we
can
create
this
pamper
message.
We
can
create
a
publish
stun,
we
can
create
links,
it
all
can
be
done
inside
the
publish
call.
E
B
I
other
questions,
so
the
message
spends
their
siblings
to
the
publish
span
right.
Why
not?
The
children
of
the
published.
B
B
E
E
Right
but
that's
a
good
point
that
maybe
next
time
I
can
try
and
like
create
links
conditionally
and
make
the
sense
children
of
publishers.
I
like
this
video.
C
Children
of
the
publish
is
because
it's
already
created
right
right
so,
like
or
or
do
you
I
mean
we
could
not,
we
could
create
a
spin
after,
but
but
if
we
create
a
span
together,
when
the
user
creates
the
message,
then
I
mean
I
guess
that
doesn't
because
I
don't
know,
for
example,
what
is
inside
the
message
so,
like
this
bank
context
is
inside
the
message
right,
I
guess,
and
in
some
points
maybe
you
can
modify
after,
but
in
some
others
you
cannot
write
because
it's
read-only
or
something
the
metadata.
E
Yeah
so
like
the
first
point,
should
we
create
a
span
when
the
user
creates
a
message?
Okay
right
in
the
message
constructor,
the
only
case
for
this
is
that
user.
Let's
say
they
created
message
and
they
never
sent
it
right
and
then
we
would
know
that
they
never
sent
it.
I
don't
know
how
important
this
case
is.
It
doesn't
look
like
it's
super
important
right
right
and
then
maybe
it's
worth
solving
and
then
we
will
have
to
create
something
in
the
message
probably
spend,
and
then
we
will
have
to
end
it
there.
E
C
C
Yeah,
but
would
wouldn't
that
be
become
inconsistent,
for
example,
because
it
would
the
trace
would
look
the
same
right
depending
on
the
case.
C
So
if
the
user
passes
a
context
or
some
whatever
else
already
populates
them
with
the
context
and
then
they
will
not
be
siblings
or
children,
but
if,
if
not
passed,
then
it
will
create
inside
the
publish,
then
they
will
be
children,
so
it
will
be
it
will.
It
will
not
be
consistent
right
depending
on
the
case.
A
Well,
I
think
I
don't
strictly
see
it
as
a
problem
because
it
just
also
into
trace
basically
shows
you
exactly
what
you're
doing
when
you're,
creating
when
you're
actually
creating
the
message
right
before
the
publish
you
see
it
in
the
trace
and
if
you
let
the
messaging
sdk
create
the
context
and
the
message.
You
also
see
that
in
the
trace,
so
it's
I
mean
it's
a
bit
similar
to
our
push,
pull
different
poor
models.
We
have
on
the
producer
side
also
here.
Basically,
the
trace
foot
mirror
what
you
are
doing.
A
So
I
think
that
might
be
okay,
because
I
mean
technically,
you
could
create
a
message
much
earlier
before
you
do
like
a
publish,
you
could
even
create
a
message,
maybe
in
a
different
trace.
A
Yes,
then,
basically
publish
in
an
other
trace
so
traces,
so
the
traces
that
you
see
in
the
end
can
look
very
differently
there,
but
they
actually
mirror
pretty
well.
What
is
going
on
in
your
application.
A
So
the
the
the
I
mean
for
me
to
learning
here
is
that
they
cannot
really
specify
like
a
consistent
relationship
between
the
publish
and
message
stance.
So
the
relationship
between
those
two
spans
might
differ
a
lot
depending
on
the
use
case.
C
Yeah
I
mean,
I
think,
that
that's
going
to
be
going
to
be
always
possible
right.
I
mean,
I
think,
for
the
publish.
We
are
not
too
much
affected
by
the
the
problem
of
or
the
limitation
of,
adding
links
after
creation
right
because
they
publish
we,
they
publish
them.
We
create
there
and
whatever
message
that
we
have
at
that
point,
we
can
just
add
links
to
it
right,
but
I'm
just
thinking
just
thinking.
C
For
example,
if
we
shouldn't
be
more
like
more,
like
add,
mark
more
constraint
because,
like
johanna
said,
for
example,
if
a
message
is
create
another
like
another
trace,
then
this
message
will
just
show
up
there.
I
mean
it
shows
what
the
application
is
doing,
but
maybe
we
maybe
we
we.
I
mean
our
rspec
says
that
the
the
message
span
is
created
inside
the
publish,
for
example,
it's
not
created
before
then
we
always
have
a
consistent
trace,
for
example,
in
this
case.
E
There
are
a
couple
of
cases,
the
first
one
is,
but
when
I'm
just
routing
right,
I
received
message
from
somewhere.
I
did
some
stuff
and
I
just
forwarded
some
rules
without
changing
the
message.
The
second
case
is,
for
example,
we
have
a
buffered
publisher,
we
give
its
pens.
Oh
sorry,
we
give
it
messages
and
then
once
it's
it's
ready,
it
publishes
them
in
buffers
right
and
then
publish
happens
somewhere
else
and
some
backgrounds
thread
users.
Don't
control.
C
C
A
Yeah,
it's
tricky
yeah
also
quickly,
look
miller,
because
I
think
one
critical
thing
that
we
have
to
provide
here.
We
also
have
to
provide
the
user
of
any
messaging
sdk
the
possibility
to
kind
of
create
this.
This
context
on
the
message
themselves
or
overwrite
this.
What
the
messaging
sdk
would
create,
because
if
you
always
say
okay,
you
call
publish
on
the
sdk
and
then
the
sdk
creates
those
spans
and
contexts.
Always
I
think
that
will
not
be
a
feasible
solution.
C
Now
I'm
I'm
just
like
I'm
just
using,
let's
say
the
developer
api
developer,
but
that's
what
I
did
like
most
of
my
my
years
of
my
my
my
career,
so
I
usually
only
like
I
started
hotel
a
few
few
months
ago,
but
usually
I
I
was
just
writing
back-end
services,
for
example-
and
I
mean
I
can
tell
you
that
probably
most
people
don't
care
about
this.
They
just
want
it
to
work.
So
they
just
say:
okay,
send
my
messages
and
create
this
plan.
For
me,
I'm
not
really
sure.
C
If
people
will,
I
don't
know,
adopt
or
even
like
that
they
have
to
take
care
of
this.
I
mean
I
know
in
some
cases
not
possible
because
of
the
limitations,
and
so
like
amir
showed
us,
but
if
we
have
some
defaults,
I
think
that
would
be
because
I
even
had
like
last
week
I
had
a
conversation
with
some
some
other
developers.
I
was
asking
something
related
like
we
needed
to
tell
how
things
are
currently
and
I
asked
some
of
them
like.
C
Can
you
please
try
to
instrument
your
app
with
this
and
tell
me
what
what?
What
was
your?
Like?
Your
experience
and
I
mean
three
of
them.
They
they
just
said
like
yeah,
it's
I
don't
know
it's
too
complicated.
I
don't
know
what
to
do.
What
is
this
and
so
on
so
like
and
then
they
just
like.
Okay,
I,
after
a
few
hours,
I
had
to
dig
into
the
spec,
and
so
on
that
I
found,
but
it
wasn't
really,
they
were
really
a
bit
like
thrown
off
by
it.
C
So
now,
why
do?
Why
would
I
use
this
and
not
use,
for
example,
the
azure
like
application
insight?
I
just
add
one
line,
everything
works,
so
they
should.
It
was
a
bit.
It
was
a
bit
yeah
yeah,
so
I
mean
I
know
what
we
tried
to
do
here,
but
yeah.
E
E
A
C
I
think
we
just
have
to
make
somehow
like
make
this
clear
or
or
in
respect
that
this
is
where
this
can
happen.
For
example,
like
we
did
being
called
events
like.
If
the
instrumentation
can
do
this,
he
will
do
it
should
do
it
and
otherwise
then
yeah
there's
there's
the
option
to
do
manually.
I
guess.
B
I
have
a
question
related
question:
is
the
published
span
mandatory
like?
Is
it
possible
that
public
spam
is
missing,
because
if
the
user
just
buffers
messages,
so
he's
calling
send
message,
send
message
and
then
something
internal
is
doing
the
publish
with
no
developer
api
and
interaction,
then,
are
we
expecting
the
public
span
in
this
scenario?.
B
Yeah,
so
I
always
imagined
it
as
like:
the
instrumentation
mirroring
the
public
api
of
the
library,
so
a
user
is
invoking
an
operation
on
the
on
the
library
and
and
that's
creates
expense,
but
in
this
case
well,
it's
internal.
So
it's
is
it
optional.
Is
it
required?
What
are
your
thoughts
about?
It.
B
E
Well,
I
think
maybe
there
is
a
first
question
if
we
want
message
stats
at
all
and
then,
if,
if
we
decide
that
yes,
we
have
to
have
them
done.
This
is
a
valid
question
and
if
links
are
optional,
then
the
only
place
we
can
put
all
these
message
attributes
our
message
spends
and
then,
if
message
spends
will
end
when
publish
ends,
then
yeah
we
actually
or
at
least
they
have
some
indication
that
it
happened
right,
maybe,
but
I
think
it
feels
a
bit
complicated
to
implement.
A
I'm
going
to
put
obvious
question
a
bit
differently
because
I
think
it
was
a
very
good
one
for
me
or
so
what's
coming
here.
To
my
mind
is
how
would
it
look
like
if
we
don't
send
batches
if
it
just
sends
single
messages,
so
we
would
basically
also
for
this
case
for
non-batch
cases
we
want
to.
We
would
want
to
have
two
spans
or
or
or
would
we
strive
to
just
have
one
span
for
those
cases.
B
I
studied
the
kafka
python
package
this
week
to
support
the
customer,
and
what
I
saw
there
is
that
the
api,
a
user,
can
just
call
like
a
send
message,
send
message,
send
message
and
then
the
library
buffers
those
messages
and
then
you
send
it
as
a
batch
when
a
timer
expires,
so
you
can
configure
how
much
time
you
want
to
batch
the
messages,
but
the
public
api
is
only
for
a
single
message,
so
I
was
kind
of
wondering
how
this
trace
should
look
like
I'm
not
sure.
What's.
B
My
answer
is
like
a
few
possibilities,
but
I'm
not
convinced
which
one
is
the
perfect
one.
C
But
but
if
we
in
the
case
of
a
single
message,
if
we
don't
have
the
message
spent,
then
we
either
put
the
attributes
that
would
put
in
the
message
span
into
the
publish,
pin
or
we'll
lose
them,
and
I
think
some
of
them
are
valuable
right,
like
the
message
id
or
where
is
it
going?
E
F
F
I
I
I
like
it
feels
like
we
designed
the
batch
scenario
first
and
then
to
me.
What's
most
important
is
what
does
an
individual
message
send
look
like
because
that's
what
a
lot
of
messaging
systems
work
with
and
and
so
it
it's
fine
to
start
here,
but
as
long
as
in
the
end,
we
don't
end
up
with
something
that's
relatively
complicated,
for
single
message,
publishers
and-
and
then
just
the
other
point.
F
I'd
like
to
make
with
regards
to
the
message
span
is
that
I
find
the
name
a
little
bit
awkward
to
under
understand
its
purpose
based
on
the
name
and
we
maybe
we
can
discuss
naming
later.
If,
if
and
when
we
decide,
we
want
the
span,
but
I
just
feel
like
it
should
better
express
what
that
span
is
for,
but
but
we
naming
can
come
later
if
we
want
to
decide
if
we
want
such
a
span.
First.
B
Yeah,
I
think,
discussed
it
last
week
that
this
span
it
doesn't
actually
trace
an
operation
in
the
system.
We
use
it
like
a
bit
of
a
hack
to
as
a
container
to
place
some
attributes
which
are
in
the
message
level
and-
and
that's
that's
one
of
the
reasons
that
I
don't
really
like
it
and
and
the
name
I
don't
like
it
as
well.
I
open
to
either
other
suggestions,
but.
F
Yeah
yeah
like
because
I
think
in
the
single
message
published
case,
you
know,
there's
nothing
wrong
with
putting
everything
about
the
message
in
the
in
in
that
one
span
that
publishes
one
message,
so
I
would
look
I
I
to
me.
It
makes
sense
that
that
you
have
additional
spans
to
track
this
extra
information
for
a
batch
publish,
but
for
a
single
message
published
I,
it
would
be
nice
if
there
weren't
two
separate
spans
for
this.
A
E
F
Yeah
and
and
like
jms
amtp
mqtt,
you
know
solace
as
an
example
yeah.
I
think
there
are
a
lot
of
messaging
systems
that
are
very
single
message.
Oriented
some
of
them
do
have
concepts
of
transactions
which
share
some
things
with
batches,
but
they're
very
different
than
I
hesitate
to
bring
them
into
the
same
conversation
so
yeah.
F
I
I
think
single
message
is
very
common
and
there
are
others
like,
like
you
know
the
ones
we're
talking
about
which
are
almost
exclusively
batch,
but
I
think
we
shouldn't
we
should
we
should
we
should
design.
We
should
have
single
message
in
mics.
I
think
it
is
very
common.
E
F
Yeah,
I'm
fine
with
that.
As
long
and
and
my
main
point
is
as
long
as
we
get
to
the
end
of
it,
and
we've
decided
what
we
want
to
do
for
batching,
that
the
single
message
case
doesn't
end
up
being
overly
complicated
because
of
batching.
That's
all,
and
I.
E
F
A
I
definitely
like
for
the
inside,
I
think,
makes
also
to
me
sense
because
they
are
also
for
me
for
me,
a
question
for
the
single
message
cases
yeah.
We
will.
We
have
two
spans
there.
Then
it's
the
same
questions
I
brought
up
before
for
the
single
message
case,
where
you
have
two
spans,
so
you
also
have
a
publish
message
spend
it
basically,
then
it
would
just
look
like
a
single
message
batch
basically,
or
do
we
somehow
want
to
distinguish
the
single
message
case
from
the
batch
case
and
make
it
look
somehow
different.
B
So
we're
discussing
discussing
a
lot
about
the
method
span
option,
but
there
are
also
other
alternatives.
So
ludmilla
did
you
also
prototype
the
other
alternatives,
like
a
link
to
a
to
a
span
with
like
to
spend
context
that
doesn't
exist.
B
E
Okay,
let
me
know
if
I
should
switch
back
okay,
so
this
is
the
case
with
no
messages
it's
not
rendered
properly,
because
it's
not
supported
on
the
back
end
right,
but
the
picture
we
see
here
is
almost
identical.
We
don't
see
message
spans,
we
see,
publish
and
the
azure
monitor
portal
doesn't
show
the
the
attributes
on
links,
but
they're
there
they
just
dropped.
You
still
see
there
were
two
deliveries,
it's
the
basically
the
visualization
question:
how
to
show
the
causation
here
right.
E
E
Right
and
if
there
were
links,
oh
sorry,
attributes
on
links,
we
would
be
able
to
see
okay,
so
here
we
would.
We
would
have
a
link
with
message
id
and
other
things,
and
here
we
would
have
links
with
this
things
right
in
the
sense
the
message
spans.
I
don't
feel
they
are
mandatory,
but
it's
because
there
is
no
partial
success
if
there.
If,
if
it
was
the
case,
then
one
message
was
published
here
successfully
and
other
wouldn't
there
would
be
no
way
to
to
tell
unless
we
will
do
more
stuff.
E
E
E
Like
I
mean
we
have
conflicting
requirements,
the
first
requirement
is
to
have
less
spans
because
they
are
confusing
and
useless,
especially
for
a
single
message
case.
E
B
C
And
then,
let's
say
the
fake
spain
context,
I
mean,
I
don't
know
how
that
will
be
supported
after
but
yeah
seems
a
bit
seems
a.
D
C
No
yeah,
I
know,
but
it's
like
you
said,
there's
a
two.
There
are
two
there's
two
requirements,
two
options,
but
one
of
them
solves
like
them
nicely
or.
A
I
mean
I,
I
got
some
ins,
some
good
insights
from
you
from
from
this
ludmilla,
because
I
think
what
I
what
I
see
here.
What
we
saw
in
the
first
case
is
that
we
said
okay.
We
also
need
to
provide
for
those
five
percent
that
we
talked
about.
We
need
to
provide
the
option
that
basically,
the
message
is
created
independently
of
this.
The
message
span
is
created
independently
of
this
published
span,
and
that
is
context
is
somehow
passed
to
the
published
span
and
then
used
there
to
link
to
this
measured
message
span.
A
So
I
cannot
actually
put
this
under
this
information
on
the
original
message
span
because
it
was
already
created
by
the
user
way
before
and
they
don't
even
have
access
to
this
pen.
A
E
Yeah
so
like
the
behavior
would
be
still
the
behavior
I
would
like
to
have.
Is
that
if
user
created
a
span
we
don't
know,
but
they
put
a
context
in
the
message,
and
presence
of
this
context
tells
us
if,
if
they
did
right,
then
if
there
is
a
context,
we
will
have
to
link
it
and
we
will
have
to
put
the
attributes
on
the
published
span
right.
But
if
there
wasn't,
then
we
control
the
whole
thing.
Can
we
it's
up
to
us
what
we
do,
but
we
can
do
just
the
same
thing.
A
Yes,
because
I
mean
one
thing
now
that
came
here
to
my
mind
is
that
I
mean
we
have
this
case
where
we
wanna
some
users
want
maybe
to
have
deeper
insight
and
have
a
spammer
message.
Maybe
some
users
just
don't
want
to
see
too
many
spams
and
just
on
that
one
span,
and
just
like
one
hybrid
idea
here
that
came
to
mind-
is
that
yeah?
By
default?
A
We
just
say:
okay,
there's
this
publish
operation
and
we
put
all
if
the
user
does
not
do
anything.
We
put
everything
on
this
publish
operation
and
we
use
the
publish
span
context
on
the
messages
that
we
send
out.
Basically,
that's
the
context
we
put
on
the
messages,
so
each
if
you
would
send
a
badge
each
batch
would
have
like
in
each
message
in
the
same
batch
would
have
the
same,
publish
context
on.
E
A
But
there's
always
the
possibility
if
a
user
doesn't
bound
that
the
user
can
create
custom
contexts
and
pass
these
in
with
the
messages,
and
then
we
would
use
those
contexts
that
the
user
gives
us
visit
with
each
message.
So
that
would
be
kind
of
a
hybrid
solution
that
basically
says:
okay
by
default,
you
have
one
published
spam.
That's
the
context
you're
using.
That
would
also
work
for
single
message
scenarios.
E
A
Yes,
that
is
true.
The
default
batching
experience
will
be
will
be
sub
optimal
in
the
sense
that
when
you
look
at
the
links
here,
you
cannot
really.
E
C
Why
do
you
do
you
say
that
so
I'm
just
trying
to
understand.
Why
do
you
say
that
for
batching
it
would
be
some
soup
optimal,
because
it
would
lack
the
information
of
the
that
specific
message
that
was
delivered
or
because,
if
the
batch
all
have
the
same
points
to
the
same,
publish
then
when,
when
looking
at
the
trace
for
the
consumer-
and
you
just
point
to
the
publish
but
lose
the
information
is
that
is
that
why
you
you
say-
or
this
is
all.
E
C
E
So
if
we
have
a
message
spent,
we
potentially
can
have
a
duration
on
it
and
the
status
right.
E
It
might
be
hard
to
implement,
but
I
don't
think
it's
super
hard.
It's
reasonable,
then,
in
this,
in
the
case
of
in
case
of
not
in
case
of
virtual
expanse,
we
can
have
an
event
which
says
when
specific
message
was
published,
it's
way
harder,
our
visualizations
to
do
in
case.
We
have
the
same
context,
follow
messages
we
can
still
have
events
saying
which
message
id
was
published
right
and.
A
A
A
Basically,
you
just
have
like
a
lots
of
of
links
going
through
different
through
different
consumers,
and
then
you
would
need
to
look
like
basically
into
the
attributes
to
find
out,
okay,
which
message
actually
was
processed
here,
because
in
a
badge
you
could
still
have
you
can
say
you
can
send
two
messages
in
a
badge
and
one
message
is,
then:
you
are
processed
three
times
by
three
different
consumers
and
one
message
is
processed,
maybe
not
at
all
and
then
by
just
looking
at
the
links
pointing
to
the
same
context,
it's
hard
to
say
kind
of
to
figure
that
out,
whereas
when
you
have
a
link
per
when
you
have
a
dedicated
context
for
spam,
you
just
immediately
see
okay,
there's
three
links
going
from
this
message
span,
but
there's
no
links
going
from
this
message
span.
C
The
case
that
you
mentioned
that
the
case
is
interesting.
I
think
so
the
one
that,
for
example,
sent
a
badge
and
one
message
is
not
processed,
but
then
in
this
case
I
wouldn't
be
able
to
see
because
it
wasn't
process,
so
nobody
actually
received
the
trace.
So
it
would
just
look
for
it
and
not
find,
and
you
would
assume
that
nobody
processed,
because
how
would
you
know
that,
like
in
the
batch
so
like?
A
Will
not
find
a
consumer
exactly
and
if
we,
if
we
have
here
everything
sampled,
then
we
can
assume
okay,
we
did
not.
This
message
was
not
processed.
A
Whereas
yeah
with
just
one
one
context
for
the
whole
batch,
these
kind
of
analysis
gets
much
harder.
I
mean
it's
still
possible
yeah,
you
can
put
attributes
on
links
or
you
can
have.
You
will
have
the
message.
Ideas
attribute
on
the
consumer
on
the
consumer's
plan
and
you
can
figure
it
out
that
way,
but
it
will
be
yeah.
It
will
be
harder
than
just
having
the
unique
context.
C
E
C
Yeah
yeah,
maybe
we
still
maybe
we'll
have
to
to
maybe
we'll
have
to
leave.
I
mean
maybe
there's
another
there's
a
third
option
that
we
don't
know
yet
but,
like
you
said,
but
you
know,
but
maybe
we
will.
We
actually
have
to
have
two
separate
cases,
one
for
single
and
one
which
doesn't
require
the
the
two
spans
just
one
and
the
batch
requires
something
else
that
we.
A
But,
but
I
still
think
that
is
a
an
important
question
for
us
to
answer
when
we
say:
okay,
a
single
context
for
for
like
we
got
the
same
context
for
the
whole
batch
or
dedicated
context
for
its
message,
actually
think
it's
good
for
maybe
good
to
think
in
order
to
answer
dania
about
what
exact
functionality
would
we
lose
for
the
user
if
we
go
with
one
context
per
for
the
whole
batch,
because
one
function
we
would
lose
is
that
we
don't
basically
cannot
say
from
the
link
structure
itself.
A
What
message
kind
of
was
was
kind
of
is
is
meant
by
this
link
that
goes
from
the
batch
to
the
to
the
consumer.
That's
definitely
a
functionality
we
lose.
A
I
mean
we
could
mitigate
that
by
just
putting
like,
I
don't
know,
a
message
ready
attribute
on
the
link,
but
the
other
question
is
then
how
feasible
it
is
for
users,
and
I
also
wonder
if
there
is
some
other
some
other
functionality
that
we
will
be
missing
out
on
if
we
don't
have
dedicated
context
for
and
spends
for
whatever
dedicated
context
for
each
each
message.
I,
for
example,
think
about
the
or
the
intermediary
instrumentation
and
requirements
there,
whether
they
might
benefit
from
dedicated
a
dedicated
context
for
each
message.
C
For
example,
if
I
send
a
badge
and
I
create
just
one
published
span
and
then
in
this
publish
span,
I
do
like,
with
amir
said,
like
an
array
of
all
the
ids
that
I'm
sending
in
the
badge,
for
example,
and
then
when
the
consumer,
for
example,
on
the
consumer
side,
when
it's
processing
the
messages
it
can
add,
for
example,
the
the
the
message
id
in
in
the
deliver
or
whatever
process
span,
and
then
this
way,
for
example,
when
you
look
at
the
the
consumer
and
the
published
span,
you
can
you
can
answer,
for
example,
how
many
messages
were
processed
from
this
sent
back,
for
example,
I
sent
three
messages
in
the
batch
and
then
I
look
at
the
consumer
span.
C
E
So
what
you're
saying
is
that
there
is
this
other
virtual
context,
the
message
id
represents
it
and
we
use
it
for
correlation
and
it's
a
valid
approach
and,
and
it
should
totally
work
if
we
put
enough
energy
into
making
that
kind
of
supported
right.
C
B
B
The
sampling
decision
might
be
lost
if
we
don't
give
each
message
its
own
context
so
like
it
doesn't.
B
D
Anyways
like
these,
like
especially
f
these
batch
situations
with
big
asynchronous
systems,
I'm
pretty
foggy
about
how
how
sampling
works
realistically
in
a
kind
of
like
chained
fashion,.
A
Yeah
nobody
I
talk
to
has
a
has
a
really
solid
idea
about
how
sampling
should
work
with
like
spam,
with
traces
that
are
connected
together
by
links
with
it
with
which
is
what
we're
working
here.
So
I
think
that
is
still
like
a
a
vast
open
topic,
but
it's
also
mean
for
for
for
amir
said,
basically
having
a
dedicated
context
for
each
span,
definitely
for
each
message,
basically
definitely
kind
of
maximizes
the
possibilities,
the
future
possibilities
for
this
kind
of
sampling.
So
that's
a
valid
point,
but
also
think
agrees
type.
B
B
D
E
D
The
the
main
purpose
of
sampling
is
cost
control
right
like
trying
to
to
control
costs
and
if
you
wait,
you're
sampling
towards
if
a
mess,
if
there's
a
message
in
there
that
says
it
should
be
sampled
and
then
you're
doing
a
lot
of
batch
processing.
How
do
you?
D
How
do
you
manage
a
consistent
sampling
priority?
Basically
right
like
it's,
it
seems
like.
If
you
wait
towards
towards
trying
to
to
preserve
sampling,
you
could
end
up
with
the
percentage
that
you
actually
drop,
producing
significantly
the
more
you're
the
more
these
messages
are
interacting
with
each
other
in
a
batch
context.
So.
A
It's
tricky.
We
saw
this.
If
you
do
a
net
king
calculation,
you
saw
you
have
a
sampling
rate
of
four
percent
and
on
the
consumer
side,
when
you
get
batches
with
an
average
size
of
100
and
by
average
you
will
have
one
message
in
there
that
is
tampered
and
you
will
sample
in
consumer
site.
Then
you
will
end
up
with
a
sampling
rate
of
factory
hundred
percent
there.
So
it's
really
it's
kind
of
I
I
I
didn't
talk
to
anybody
out
there
who
had
like
a
really
solid
approach
for
sampling
tear.
A
B
B
A
I
think
we
need
to
conclude
today.
We
are
one
minute
past,
so
thanks
a
lot
miller
for
preparing
that
that
I
think
helped
to
answer
some
questions,
but
also
brought
up
some
more
questions
for.
A
So
maybe,
let's,
let's
let's
continue
discussing
that
next
week.
I
think
we
have
some
like
common
understanding
emerging,
but
it
seems
to
me
we
need
the.
We
need
a
bit
more
time
to
kind
of
hone
on
that
and
come
to
some
come
to
some
like
solid
solution.
There
yeah,
but
but
thanks
a
lot
to
miller
for
preparing
that
that
was
great.