►
From YouTube: 2021-10-20 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
A
Do
oh
no,
I
I
haven't
requested
that
that
would
be
interesting,
but
also
probably
sad
to
say
yeah.
Is
there
a
recording
for
it?
I
hope
so.
There
was
some
kind
of
screw-up
from
what
we
understand
around
the
virtual
presentation
of
our
talk,
but
I
don't
know
if
it
means
that,
like
the
actual
recording
was
messed
up
or
if
it
was
something
about
like
live
streaming,
it
that
was
messed
up
but
but
I
kind
of
feel
like
it
was
the
latter.
I
feel,
like
the
av
guys,
probably
know
what
they're
doing.
A
D
Well,
once
once
it
becomes
available
yeah,
please
your
lead
good
me
love.
Please
share
it.
I'd
love
to
listen
in
because
I
I
didn't
attend
any
of
the
cubicon.
So
oh,
hey
dennis
see
you
added
to
the
agenda.
Did
you
want
to
start
your
demo
or.
E
Yep
I
can,
I
can
do
it
so
just
for
the
context.
Last
time
like
like
last
week,
last
last
tuesday,
we
were
discussing
the
way
how
we
can
instruments,
http
clients
or,
like
http
communication,
in
a
way
that
we
can
actually
see
http
client
side
retries.
E
So
I
showed
a
couple
of
examples
there
and
also
there
was
a
proposal
and
this
exact
proposal
I
also
have
visualized
today
so
also
would
like
to
get
some
feedback
on
this.
So
let
me
start
sharing.
E
Can
you
see
yep
yeah,
so
I
will
do
some
coding
here,
because
I
unfortunately
wasn't
able
to
prepare
screenshots,
but
it
should
be
straightforward.
E
So
the
the
overall
idea
here
is
that
we
have
a
client
site
and
a
server
side
and
basically
from
a
server
side,
we
have
a
special
kind
of
server
which
first
time
responds
with
four
or
four
and
then
then
second
time.
Second
time
it
responds
with,
with
some
like
a
200
response
and
the
cl
on
the
client
sides.
E
On
the
client
side,
we
have
a
simple
http
client,
like
a.net
http
client,
and
we
have
all
the
instrumentation
implemented
manually,
including
propagation
of
trace
parents
request
and
that's
basically
the
like
our
playgrounds.
That's
we
are
using
for
different
types
of
instrumentation,
so
the
way
how
how
spans
actually
can
be
constructed
so
last
time
with
this,
like
I'm
just
what
I
showed
last
time,
we
had
this
instrumentation
when
we
can
actually
kind
of
see
which
types
of
information
we
want
to.
E
We
want
to
visualize
so
for
this.
Actually
there
was
a
concept
or
there
is
a
concept.
That's
I
like
I
was
I
was
introducing
like
I
introduced
previously,
so
in
terms
of
logical
and
physical
spans
that
actually
logical
span
represents
top
level
span
for
physical
ones.
E
So,
every
time
like
when
we
do
some
call,
we
have
physical
span
created,
and
if
we
had
some
rich
rice,
then
we
also
would
like
to
kind
of
combine
them
together
and
then
that's
exactly
what's
what
we
see
in
terms
of
like
a
logical
span,
so
this
for
for
this
particular
example,
I
would
run
this
code
with
logical
and
physical
span
enabled
so
basically
we'll
see
both
of
them
and
also
explain
like
how
it
will
look
like
in
case
we
have
just
just
one.
E
So
this
is
the
span
that
we
have
here.
So
basically,
that's
the
like
the
instrumentation
result
that
we
have
here.
So
in
this
case,
we
we
had
like
a
first
time
response
with
codes
200.,
so
there
was
no
retries
and
since
we
have
logical
and
physical
span
enabled
in
this
time-
and
just
in
this
case,
we
have
this
information
kind
of
not
really
useful
in
this
case,
just
because
there
is
nothing
we
need
to
combine
with.
E
So
we
have
just
one
retry,
but
in
case,
if
we
go
here
and
just
change
a
code
to
change
the
code
a
bit,
so
we
have
from
the
server
side.
E
We
have
this
error
like
or
404
for
the
first
for
the
first
try,
then
the
visualization
will
be
the
following.
E
So
we
have
this
logical
span
and
actually,
in
this
case
it
makes
sense
just
because
we
have
two
rich
rice,
and
this
is
like
a
proper
visualization.
So
that's
something
that
we
would
like.
We
ideally
would
like
to
have
as
a
visualization
here.
So
we
have
this
like
a
logical
spam,
basically
saying
that
we
want
to
call
this
api
and
then
we
see
both
retries.
So
this
is
like
a
client-side
try
and
this
is
server-side
response
or
server-side
spam
and
again.
E
This
is
this
one
was
unsuccessful,
so
this
was
a
rich
way
and
this
this
time
it
was
successful.
So
that's
the
visualization
we
are
probably
would
like
to
to
have
most
but
like,
as
I
said
in
95
of
cases
when
we
don't
have
any
retries,
this
logical
spelling
will
be
just
kind
of
useless.
So
that's
that's
the
problem.
That's
we
would
like
to
solve
with
the
proposal
that
I
would
just
want
to
show
you,
but
in
the
meantime,
if
you
have
any
questions,
you
can
also.
E
E
Kinda,
so
we
can
make
it
actually,
we
can
make
it
conditional
so
in
case
so
there's
the
exam
another
example
I
have
so
in
case
we
have
some
retries.
We
actually
can
create
this
logical
spans,
so
this
can
be
the
the
proposal,
so
I
would
like
I
would.
I
will
show
you
what
I
mean
just
in
a
second,
so
I
will
go
here
once
again
and
you
see
this
is
like
a
number
of
spans.
Spans
are
the
same,
but
the
visualization
right
now
in
jager
is
different.
E
So
we
still
have
these
two
rich
rice,
but
since
this
one
is
conditional,
we
are
not
creating
this
right
away
in
the
very
beginning,
but
we
created
this
like,
after
all,
the
communication
already
happens,
but
what
we
can
do
here,
we
can
actually
create
links
to
the
to
these
previous
spans,
explicitly
saying
that
this
actually
the
spam
that
was
created
to
combine
these
two
to
kind
of
as
a
top
level
span
for
these
two
and
then
we
can
also
improve
the
visualization
putting
this
somewhere
on
the
top
saying
that
this
is
the
the
one
that
actually
was
logic
of
like
a
work
kind
of
represent
the
logical
one,
and
for
this
case
we
don't
need
to
provide
any
kind
of
configuration
just
because
we
can
do
it
like
right
away.
E
E
So
this
this
one
was
was
the
one
way
of
doing
this.
Another
way
that
we
just
discovered
when
we
had
another
meeting
that
actually,
instead
of
creating
this
logical
spam,
we
can
link
two
spans
together.
So,
for
example,
for
the
try
one,
we
don't
have
any
information
about
any
retries,
but
for
the
second
try
we
can
actually
put
this
link
to
the
previous
or
to
the
first
one.
E
So,
and
that's
that's
mostly
about
the
visualization,
then
so
here,
if
we
have
this
information
kind
of
some
retry
number
saying
this
is
like
a
retry
number
two.
So
this
is
the
second
try
and
a
link
to
the
previous
one.
Then
it
basically
means
that
we
have
a
retry
case
and
it
can
be
also
visualized
differently.
E
So
these
two
things
that
I
would
like
I
had
I
had
to
present
and
would
like
to
also
like
hear
some
feedback
from
you
guys.
A
Nice
yeah
thanks
for
doing
the
work,
I'd
love
to
hear
feedback
from
other
people,
but
I
will
say
I
don't
think
the
the
optional
span
is
in
practice
necessarily
going
to
be
very
useful.
A
Just
the
way
people
tend
to
want
to
monitor
things
and
set
up
dashboards
and
measure
latencies
having
spans
that
are
only
conditionally
present,
especially
based
on
like,
like
production,
behavior
like
that,
would
would
be
difficult,
I
think,
to
to
make
make
use
of,
in
other
words
like,
if
you're
trying
to
to
say
graph,
latency
and
like
looking
for
outliers.
If
you
have
a
span,
that's
only
present
like
a
logical
span.
A
That's
only
present,
sometimes
like
only
present,
when
there's
retries
for
example,
then
then
it
would
be
very
difficult
to
to
set
up
something
that
was
looking
for
that
kind
of
latency
skew
stuff
like
that.
So
that's
the
thing
to
think
about.
B
I
guess
the
the
interesting
part
here
is:
I
guess
we
want
to
have
number
of
tries
right,
so
this
is
kind
of
a
useful
metric
to
have
current
point.
For
example,
we
do
want
to
know
like
if
I'm
debugging
something
I
want
to
know
that
this
http
requests
were
tries
of
the
same
thing
right.
B
So
it's
just
the
way
to
let
users
know
right
yeah.
So
it's
it's
conditional
in
the
sense
that
if
there
were
tries
it's
there
right
so
otherwise,
how
would
you
know
and
how
to
represent
this
data?
Is
this
is
a
different
question.
Basically,
we
were
looking
for
the
feedback.
What
do
you
think
like
like?
If
it's
not
the
approach,
then
we
don't
have
a
solution,
a
good
solution,
how
to
even
say
there
were
tries.
A
Yeah,
I
guess
yeah
my
feedback.
There
would
be
to
maybe
think
about
not
just
the
structure
here,
but
the
the
kind
of
aggregate
analysis
people
are
trying
to
do
right.
The
kind
of
dashboards
people
are
trying
to
set
up
and
things
like
that,
and
what
what
structure
makes
that
work
in
in
most
tracing
tools
today,
the
the
structure,
the
reason
why
we
end
up
with
that
logical
span,
that's
redundant
sometimes
but
is
always
present-
is
because
that
gives
people
like
a
concrete
query
target
to
do
things
like
latency
analysis.
A
That
would
let
you
know
if
there
was
say
extended,
latency
happening
on
a
particular
endpoint
due
to
the
fact
that
there
were
a
bunch
of
retries
and
if
that
thing
was
was
only
conditionally
present,
then
you,
wouldn't
you
wouldn't
be
able
to
see
that
the
skew
of
latency
right,
because
you
would
only
be
getting
these
spans
present
for
when
there
were
multiple,
multiple
retries
and
I
like
that
links
are
an
interesting
way
to
model
it
of
like
there
could
be.
A
No,
your
approach
where
you're
saying,
like
maybe
there's,
there's
no
logical
span
that
sits
as
a
parent,
but
you
just
have
the
physical
spans
but
they're
linked,
so
that
you
know
that
they're
together
would
be
a
a
logical
way
to
model
it
but
yeah.
I
think
my
advice
would
be
to
to
think
about
how
people
are
going
to
try
to
set
up
latency
analysis
for
this
and
like
which,
which
data
structure
would
let
them
be
able
to
like
write
those
simple
queries
in
advance.
A
E
That
actually
makes
makes
a
lot
of
sense,
and
for
this
particular
example,
I
don't
have
this
latency
set
for
this
logical
span,
but
it's
something
that
I
just
missed,
probably
here
to
do
just
because,
since
I
like
in
the
client
side,
I
know
when
this
particular
try
happened,
so
I
can
actually
in
this
case
I
can
like
kind
of
save
this
date
or
store
store.
This
time
moment
like
a
timestamp
and
actually
in
case
we,
we
actually
have
some
retries.
E
In
terms
of
like
a
duration
analysis,
it
will
be
there,
so
even
in
this
case
and
then
as
the
milla
said
it
basically
mostly
about
the
visualization.
So
let's
imagine
that
we
have,
for
example,
jager
that
can
actually
represent
this
kind
of
stuff
as
a
tree
right.
So
in
case
we
have
this
conditional
logical
span
created
with
links
and
then,
since
we
have
all
the
information
available,
we
have
the
span
itself.
We
have
links
to
the
previous
spans.
Then
it
can
be
visualized.
So,
for
example,
in
jager
we
can.
E
We
can
do
this
visualization
and
basically
that's
the
way
how
we
can
see
the
the
picture
that
we
actually
expect
in
the
sea
right.
But
in
the
same
time
we
are
solving
this
problem.
That's
in
case
we
don't
have
any
retries.
We
just
need.
Don't
need
to
do
anything
else
right,
so
it
will
be
no
logical
conditional
span.
C
Yeah
I
would
like
to
like
continue
to
thought
that
that
started,
because
I
think
it's
a
it's
a
valid
thought
and
I
think
we're
making
some
things
as
dennis
said,
definitely
simpler,
but
I
think
what
that
was
talking
about,
and
I
mean
and
neuralic.
For
example,
you
can
create
dashboards
that
are
based
on
spans
and
you
can
query
spans
and
basically
like
when
I,
when
I
think
about
yeah,
I
have
a
dashboard.
C
And
then
I
think
the
question
that
is
raising
is
how
much
more
complicated
have
these
three
to
be
like,
depending
on
the
span
structure
that
we
offer
here,
because
if
just
if
I,
for
example,
want
to
count
okay,
how
many
http
requests
were
made
by
this
by
this
application,
and
I
just
think
on
the
spam
data
model,
then
here
I
would
have.
Actually.
I
would
need
to
know
quite
a
lot
to
know
which
span
is
logically,
which
span
is
physically.
C
A
Yeah,
there's
it
it
might
make
a
particular
tracecraft
look
cleaner,
but,
but
I
think
it
it'll
complicate
the
kind
of
querying
and
dashboards
people
want
to
do
likewise.
A
Having
the
logical
span
not
be
the
parent
of
the
other
spans
kind
of
goes
a
little
bit
against
the
the
the
trace
model
in
the
sense
of
so
you
have
tools
that
do
things
like
critical
path,
analysis,
for
example,
and
those
tools
would
potentially
get
confused
by
a
layout
of
having
a
logical
span
as
like
a
sibling,
that's
sort
of
linked
together,
potentially
because
they're
they're
not
they
would
not
be
able
to
understand
that.
A
B
That
it
sounds
like
from
what
current
solutions
do
they
want
this
arbitrary
logical,
http
call
duration,
which
is
a
function
of
your
retry
policy,
then
the
the
dependency
but
anyway,
then
it
sounds
like
we
think
it's
generally
useful
and
it
should
be
on
by
default.
Assuming
your
backhand
supports
it.
So
it's
like
that.
It's
either
or
you
have
it
or
you
don't
have
it.
A
Yeah
yeah
yeah,
it's
it's
definitely
I
think
the
present,
that's
what
I
should
say
the
president
of
having
a
logical
span
that
represents
the
entire
encapsulates
the
entire
logical
operation,
including
all
the
retries
and
everything,
is,
is
actually
like,
very
useful
to
to
users.
We
have
this
issue
of.
A
I
think
the
fact
that
we
seem
to
be
like
when
we
get
several
stacks
of
instrumentation
put
in.
It
seems
like,
maybe
that
what
counts,
as
that
logical
layer,
starts
to
become
redundant,
but
I
think
it's
something
ludmilla's
pointed
out.
It's
like
it's
like.
A
If
all
you
had
was
an
http
client,
then
I
think,
having
that
logical
span
there,
all
the
time
wouldn't
be
bad,
but
when
you
have
like
an
http
client
embedded
inside
of
like
some
kind
of
framework
that
then
had
some
other
logical
construct
right
on
top
of
it,
then
it
starts
to
look
like
you
just
have
these
like
layers
of
spans
that
are
measuring
essentially
the
same
thing
and
yeah,
but
I've.
What
I've
wondered
is
is
I
kind
of
maybe
an
alternative
approach
dennis
to
think
about.
Is
that
again,
like
optional
spans?
A
It
almost
it
always?
It
kind
of
comes
down
to
feeling,
like
log
levels,
to
me
with
this
stuff
to
some
degree
like.
I
think
you
would
always
want
there
to
be
a
logical
span
and
then
there's
like
this
question
of
like
sometimes
people
are
trying
to
dig
under
the
hood,
but
then
you
have
the
problem
of
like
your
your
span,
ids,
whether
you
want
each
slot,
each
actual
http
request
to
have
a
different
span
id
when
you
just
have
one
logical
span
to
pass.
A
All
of
those
would
have
the
same
span
id
for
better
or
worse,
which
is
probably
really
confusing.
So
I
don't
know
I
I
kind
of
wonder
if
we
end
up
with
a
situation
where
you
just
that's
just
the
way
this
stuff
looks,
and
maybe
it's
something
that
it's
maybe
here's
like
an
alternative
proposal.
This
is
taken
from
zipkin's
playbook,
which
is
instead
of
in
the
actual
data
structure,
trying
to
hide
this
stuff
or
making
it
optional.
Maybe
this
is
just
a
ui
element
like
does
that
make
sense
like?
A
A
B
A
E
Yeah
in
terms
of
cost,
actually
we're
just
doubling
the
cost
in
95
percent
of
cases
right
because
we're
adding
one
more
spam
yeah
and
that's
the
exact
problem
we
want.
We
tried
to
actually
cover
with
this
kind
of
logical
span
which
actually
links
and
this
one,
which
is
conditional.
Definitely
I
fully
agree
that
this
picture
that
we
have
as
a
tree
representation
is
something
that
users
probably
would
like
to
see
the
most
right.
The
thing
is
that
sometimes
it
just
kind
of
brings
a
lot
of
additional
overheads.
A
B
I'm
thinking
if
we
can
get
the
best
of
the
oral
world,
so
if
there
is
no
retries,
then
the
first
try
carries
all
the
properties
of
logical
span.
You
can
query
for
the
logical
spin
and
get
the
first
try.
If
there
is
more
than
one
try,
then
you
have
a
logical
spin
and
then,
when
you
query
it
you
get
both.
It
complicates
instrumentation
like
like
a
ton.
A
A
So
like
this
is
what
you
can
see
the
light
step
ui
here.
A
You
guys
see
that
yep.
So
this
is
like
a
typical
way.
People
would
make
a
query
they're
saying
you
know
for
this
particular
service.
I
care
about
this
particular
operation,
so
I'm
querying
by
span
name
here
and
then
I'm
looking
at
this
operation
broken
down
by
latency.
A
So
you
know
I
can
see
you
know
the
the
p50
p60.
I
can
see
all
the
things
that
are
then
these
outliers
here
and
like
the
p99,
and
so
I
can
see
what
are
my
extreme
outliers
versus
what
are
examples
of
average
latency
or
I
can
see
examples
of
extreme
latency,
but
in
order
to
do
that,
there
there
has
to
be
this.
This
span
has
to
be.
This
operation
has
to
be
consistent.
A
It
has
to
consistently
be
present.
It
has
to
consistently
measure
the
same
thing.
Otherwise
you
can't
you
can't
do
this
kind
of
latency
analysis,
and
this
is
like
probably
the
number
one
traditional
use
case
for
distributed
tracing
is
doing
this,
this
kind
of
stuff,
but
but
any
kind
of
dashboard.
You
would
want
to
set
up
you're,
probably
going
to
be
doing
a
query
like
this,
and
so
the
the
data
being
being
stable
is
is
probably
a
requirement.
A
I
think
we're
just
we're
stuck.
I
think
lumiel
has
like
really
pointed
it
out,
which
is
like
if
we
want
to
have
a
stable
logical
span,
so
that
this
querying
is
stable
even
when
there's
multiple
retries,
but
if
we
want
every
retry
to
have
its
own
span
id
you
just
end
up
with
this
span
sandwich
right
like
like
you
just
that
it
just
kind
of
like
falls
out
of
what
what
people
are
trying
to
do,
and
you
could
eliminate
the
you
could
eliminate
the
retrying
under
the
hood
and
have
all
the
spans.
A
E
I
just
wanted
to
add
here
that
in
case
we
don't
have
like
an
individual
trade
span
id
for
each
retries
and
in
case
we
have
like
a
server
a
like
a
service,
a
call
service
b
and
then
call
service
c.
Actually,
we
cannot
see
that
some
retries
failed
on
between
b
and
c
right,
because
there
is
no
like
a
propagation
of
the
of
the
span
id
so.
A
You
would
see
it
because
you
would
have
the
well,
you
would
have
the
server
spans
for
each
of
those
retries
and
then
you
would
have
span
events
on
the
client
side.
B
And
realistically
you're
using
the
timestamp
correlation
to
solve
the
problem
right
and
assuming
you,
you
kind
of
you-
have
both
sides
of
the
story.
It's
maybe
fine,
but
if
you're
calling
into
something
you
don't
own
like
this,
creates
a
potential
issue
for
getting
support
like
from
azure.
If
you
come
to
azure
support
and
give
them
ask
them
for
like
one
of
these,
five
requests
was
problematic.
Can
you
help
me?
B
I
I
don't
know,
maybe
like
they
will
try
to
do
their
best,
but
they
they
can't
parse
the
whole
universe
and
understand
that
there
were
five
tries
right.
So
it's
just
you're
it's
creating
some
bad
situation
for
users,
so
I
guess
there
could
be
different.
We
should
allow.
If,
if
we
do
this,
we
should
allow
different
things.
So,
let's
say
when
I
instrument
my
azure
sd
case,
I
want
to
spend
per
try.
I
also
have
a
logical
spend
regardless.
I
don't.
B
I
don't
want
to
use
the
http
logical
span,
it
doesn't
fit
my
needs
and
then,
if
it's
pure
http
instrumentation,
it
can
do
something
else,
but
still
is
it
creates
a
potential
supportability
whole.
A
Yeah,
I
think
it
would
be
worth
investigating
how
how
real
that
is.
Like
one
thing
I'm
curious
about,
is
I
actually
think
tracing
traditionally
worked
only
on
this
logical
level.
One
thing
that
might
be
interesting
would
be
to
investigate
some
other
tracing
systems
like
zipkin,
for
example,
and
double
check
how
they,
how
they
approach
this
problem,
like
did
the
other
tracing
systems?
Try
to
parse
out
these
logical
span,
these
physical
spans,
I
know
zipkin.
C
E
Yeah,
why
I
feel,
like
I
applied
this
concept
of
kind
of
verbosity
levels
and
just
provide
this
as
a
configuration
then.
So,
for
example,
in
case
of,
if
user
is
like
or
for
example,
if
we
have
azure
sdk,
for
example-
and
we
want
to
have
this
logical
span
present
like
up
every
time-
it
can
be
done
on
sdk
level
and
it
can
be
configured
on
a
http
client
sites
just
to
basically
have
only
physical,
physical,
physical
spans
only
yeah.
It
is
if
people
just
like
some.
E
Some
users
have
just
http
client,
but
they
still
want
to
have
the
same
kind
of
things
with
with
their
own
code.
They
can
enable
this
logical
spanner,
it
will
be
created
for
them
by
default
yeah,
and
this
can
probably
I
mean
this-
can
be
something
that
we
can
just
just
configure.
A
Yeah
but
but
we
have
to,
we
have
to
come
up
with
the
same
default.
I
think
that's
the
yeah
the
trick
right,
because
no
one
wants
to
configure
a
million
of
these
things
and
the
and
at
any
rate
we
have
to
pick
the
default,
and
maybe
the
default
is
like.
We
just
show
like
what
you're
saying,
net
and
azure.
A
So
because
that's
kind
of
like
the
other
knob
I
would
be
looking
at
right,
like
I'd,
be
looking
at
a
skew
and
latency
per
physical
request.
But
then
I
would
also
be
seeing
like
my
error
rates
tipping
up
ticking
up.
If
there
were,
if
there
were
like
a
bunch
of
retries
happening,
for
example,
or
something
like
that.
So
maybe
that's
actually
just
the
answers
like
it's
just
get
get
rid
of
this
logical
concept.
It's
just
physical
spans
at
the
http
level.
E
Yeah,
so
that
was
my
point
basically
like
by
default.
We
definitely
need
to
have
something
which
we
have
today
right,
just
to
have
backward
compatibility
and
the
same
behavior,
but
in
case,
if
people
just
don't
want
to
write
much
code
and
they
don't
want
to
instrument
their
own
code,
but
they
want
to
have
like
or
just
to
take
a
default,
http
client
and
configure
it
in
a
way
that
it
will
show
this.
E
A
Yeah,
I
don't
know,
I'm
coming
up,
I'm
really
coming
around
to
the
idea
that,
like
this
is
just
extra
cost
and
yeah
we
could,
we
could
add
it
as
an
option,
but
also
we
could.
We
could
just
roll
with
the
model
of
it's
just
physical
for
now
and
like
wait
and
see
if
people
really
need
that
option
I
would
be.
I
would
be
curious,
maybe
maybe
it's
not
actually
a
need.
A
I
know
he
needs
stability
in
terms
of
the
operations
that
are
present,
but
I
guess
I'm
it's
not
clear
to
me
that
that
we
need
a
logical
layer.
Maybe
that
was
just
maybe
that's
just
like
an
artifact
of
our
more
simplistic
assumptions
that
we
were
having
about
traces
in
the
past
and
not
really
like
something
anybody
needs.
A
A
We
could
we
could
also
like
keep
that
like
record,
that
that's
like
an
option
that
we
might
want
to
add,
but
wait
to
wait
to
add
it.
If
it
turns
out
people,
people
really
need
it.
B
Yeah
there
are
like
some
other
potential
solutions.
Let's
say
we
we
keep
logical.
Let's
say
we
think
it's
generally
useful.
My
main
worry
that
it
describes
your
retry
policy
back
off
more
than
anything
else
right
and
then
okay,
but
maybe
it's
useful.
Maybe
we
can
get
rid
of
the
physical
things.
Maybe
then
the
the
idea
is
that
okay
cloud
providers
usually
return
something
back
the
response
header.
If
it's
an
http
right,
they
don't
trust
the
trace
id.
You
generate
either
way
in
1080.
B
So
maybe
the
event
should
have
specific
attribute
that
holds
this
information.
Maybe
that's
an
approach
we
want
to
pursue
it's
just
it
feels
like.
If
we
have
this
context
propagation
mechanism,
it
should
work
in
the
same
way
as
everywhere
else.
A
C
What
what
was
the
exact
use
case
that
you
mentioned
like
that,
for
example,
I
have
a
failing,
http
request
and
then
I
go
like
to
the
basically
to
the
to
the
or
write
a
support
request
and
to
the
people
who
run
the
server,
and
then
I
put
like
the
tracer
id
and
span
id
there
and
then,
with
the
help
of
this
context,
and
they
kind
of
filter
out
the
http
requests
on
server
side
and
help.
Troubleshooting
is
this
kind
of
the
use
case
we're
talking
about
here.
C
Yeah,
I
mean,
I
think
the
two
cases
would
then
then
either
they
get
the
exact
id
of
this
one.
We
tried
it
failed
or
otherwise
with
when,
when
when
you
would
not
have
like
context
for
each
like
three
tries,
you
would
give,
they
would
basically
get
a
list
of
requests
that
came
through
through
and
basically
those
would
still
all
be
related
to
the
same
kind
of
logical,
logical
kind
of
request.
But
it
would
include
like
the
succeeded
and
the
failed.
A
I
I
think
the
physical
model
is
honestly
the
the
most
correct
right.
I
certainly
think,
like
the
the
logic,
only
model
where
you
have
the
same
span,
id
for
multiple
client
requests
is
like,
like
you're
saying
it's
slightly
odd,
and
we
should
have
a
look
at
this.
But
honestly,
I
do
think
in
in
real
world
scenarios,
when
you
have
like
an
http
client
and
it's
making
a
request
that
client
and
that
request
is
happening
in
the
context
of
some
kind
of
larger
logical
operation.
A
Right,
there's
always
going
to
be
like.
Why
are
you
making
this
request
and
then
what
are
you
doing
when
the
data
with
the
data
when
you
get
it
back
and
that
might
be
say
like
a
controller
in
a
web
server
or
it
might
be
on
like
the
client
as
part
of
like
a
user
action
on
the
client
side,
and
so
when
people
are
trying
to
do
latency,
analysis
and
stuff
like
that?
A
That
would
encapsulate
all
of
these
retries.
I
I'm
thinking
like
in
the
in
the
real
world.
There's
actually
always
this
other
operation
that
they
would
be
using
to
capture
that
stuff.
A
Like
the
operations
we
tend
to
look
at,
for
example,
when
we're
setting
up
these
queries
tend
to
be
server-side
right,
we
tend
to
use
like
the
the
default
is.
The
controller
action
in
your
web
framework
is
usually
the
operation
that
you're
picking
not
like
the
http
client
request
operation.
A
B
I
had
an
extra
argument
about
the
rapper
thing
and
I
I
want
to
run
by
all
of
you
and
hear
the
feedback,
my
impression
that
we,
when
we
instrument
http
client,
we
don't
know
how
it's
being
used
right.
People
can
use
interceptors
or
handlers
to
handle
retries
or
they
can
use
any
other
apis.
For
example,
in
there
is
a
python
annotation
to
retry
a
function,
or
there
is
a
concept
and
reactive
programming
to
retry
something.
So
we
don't
know
when
this
retro
wrapper
happens.
A
E
Sorry
go
ahead,
yeah,
sorry!
For
me,
this
kind
of
you
know
when
we're
talking
about
distributed
tracing
all
the
time.
I
have
this
idea
in
mind
that
we
have
like
a
two
different
orthogonal,
sometimes
things
so
from
the
one
side
we
want
to
provide
all
the
possibilities
actually
to
debug
the
applications
right.
So
that's
the
case.
I
think
mill
actually,
like
I
shared
that
we
need
to
provide
some
unique
spam
id,
so
the
person
can
just
go
and
see
this
particular
request,
or
some
particular
retry
and
potentially
the
whole
call
graph.
E
So
this
is
about
like
a
troubleshooting
or
debugging,
but
from
the
other
hand
we
also
would
like
to
use
the
same
data,
but
for
analysis
right.
So
we
want
to
do
some
aggregations.
We
want
to
do
like
extract
some
metrics
and
build
something
on
top
of
this.
So
looks
like
this
logical
thing
or
layering
thing
is
something
which
is
kind
of
required
for
troubleshooting,
but
it
actually
makes
it
difficult
for
analysis
right
just
because
we
are
taking.
E
We
are
having
so
much
data
and
we
have
this
different
layering,
so
we
need
to
filter
some
things
out
and
so
on
so-
and
this
is
j,
probably
the
topic
that
we
are
discussing
is
related
to
rich
rice,
but
we
have
the
same
for
redirects
and
for
some
other
cases
right
and
in
general
for
distributed
tracing
this.
These
two
concepts
are
always
like
a
following
one.
Like
a
one
I
mean
they
are
two
together
where
we
have
them
two
together
all
the
time.
E
So
it
looks
like
we
have
like
at
this
top
level
or
general
problem
that
probably
we
want
to
also
tackle-
and
in
case
of
in
this
particular
case
we
can
like
we
can
use
this
configuration
say
that
we
want
to
do
debugging
or
we
want
to
do
analysis
right.
So
that's
the
kind
of
way
how
we
instrument
our
like
our
code
so
like
for
debugging
purposes
mostly
or
for
analysis
purpose,
but
that's,
that's
probably
applicable
for
many
different
aspects
in
distributed
tracing.
So
that's
the
just
kind
of
thinking
out
loud.
A
A
Any
time
I
have
seen
us
try
to
get
fancy
with
the
data
we
produce,
where
we
try
to
make
like
presumptions
about
what
the
user
wants
or
or
modify
the
data
in
some
way
or
otherwise
start
kind
of
modeling
it
in
anything
other
than
just
exactly
and
precisely
describing
what
happened
it
always
bites.
Us
has
bit
me
every
time
we
have
gone
down
that
path
and
it
kind
of
feels
to
me
like
at
the
end
of
the
day,
the
the
best
solution
often
ends
up
being
to
just
as
simply
and
clearly
as
possible.
A
Have
the
telemetry
data
describe
what
exactly
is
going
on
and
to
have
the
analysis
tool
on
the
back
end
if
it
wants
to
do
any
further
analysis
about
trying
to
wrap
things
together
or
move
things
around
or
massage
the
data
or
present
it
in
some
interesting
way
that
that
should
be
done
later
by
an
analysis
tool,
but
it
shouldn't
be
done
by
the
telemetry
being
emitted,
because
if
you
do
things
there,
then
there's
no
there's
no
like
taking
it
back
or
getting
around
it.
A
At
that
point,
and
I
kind
of
wonder
I
used
to
think
about
like
logical
spans
and
how
people
were
trying
to
to
model
it
that
way,
but
the
more
we
talk
about
it
here,
the
more
it
feels
like.
A
Actually,
the
the
simple
correct
model
is
just
every
time.
It
makes
a
request
that
request
is
span
and
that's
the
even
though
you
could
have
a
kind
of
wrapping
layer
that
feels
like
overhead,
so
like
don't
don't
bother
with
that
layer
and
then
you're
just
very
clearly
and
simply
describing
what
an
http
client
is
doing.
A
If
there's
some
overhead,
an
http
client
had
that
was
not
captured
by
those
individual
requests,
maybe
you
would
be
losing
that
information
there,
but
I'm
not
sure.
If
that's
the
case
necessarily
I
mean
I'm
sure,
there's
some
really
complicated
ways.
Http
2
and
stuff
ends
up
working
that
what
we're
doing.
E
Here
doesn't
cover
that's
the
case.
I
actually
also
had
in
mind
so
basically
when
we
have
just
physical
instrumentation-
and
we
have
this
thrice,
basically
spam
per
try
the
default
behavior
in.net.
We
actually
don't
have
like
a
and
in
case
we
still
want
to
do
this
kind
of
additional
analysis
or
even
troubleshooting.
In
this
case,
we
we
are
losing
that
the
information
that
these
two
spans
are
part
of
the
same
kind
of
interaction,
so
they
are
just
retries
of
the
same.
The
same
request
right.
E
So
that's
why
we
came
up
with
this
idea
of
conditional
span.
So
in
case
we
def
we
do.
We
did
this
retries.
We
are
putting
this
additional
piece
of
data
just
because
of
this.
So
like
a
later,
some
system,
like
analysis
system
or
actually
visualization
system,
can
take.
They
can
take
this
piece
of
information
and
apply
it
in
a
way
that
it
actually
can
visualize
this.
These
two
things
as
a
retries
yeah.
So
that's
this
was
the
the
idea
and
it
might
be
meaningful
like
from
this
perspective,
it
might
make
sense.
A
But
I
actually
think
your
proposal
to
do
that
with
links
might
work
better
because
again,
the
conditional
stuff
that
is
like
that
is
bad
for
tracing
systems
for
for
in
general,
for
the
span
structure
to
be
shifting.
You
have
just
lots
and
lots
of
tools
that
do
structural
based
analysis,
and
so
I
think
we
want
to
be
really
careful
about
things
that
are
causing
the
span
structure
to
change
conditionally.
But
the
proposal
you
had
to
just
like-
maybe
you
just
have
physical
spans,
but
there's
a
special
kind
of
link
that
we
use.
A
E
Makes
sense-
and
this
is
this
idea-
also
like
a
like
a
raised
once
again,
so
basically,
we
still
have
the
same
kind
of
structure
span
structure,
but
we
are
adding
some
additional
information
in
terms
of
links,
yeah,
actually,
some
additional
attributes
kind
of
retry
number
or
try
number
right
yes,
and
using
this
data,
actually
we
can
construct
or
we
can
represent
the
siblings
as
a
tree
if,
if
needed
or
actually
when,
we
have
some
like
analysis
system,
we
also
can
kind
of,
like
kind
of
you
know,
put
them
as
a
just
one
thing
saying
that
we
had
just
this
this
this
one
like
a
logical
kind
of
thing,
and
all
these
additional
spans
are
just
retries
of
the
same
request.
A
Yeah
yeah,
I
mean
something
like
that
makes
sense
to
me.
I
mean
we're
eventually
gonna
run
to
this
problem,
where,
like
links
just
become
this
like
hammer
that
we're
gonna
start
using
for
for
everything
and
we're
gonna
need
to
figure
out
like
link
structure
and
how
that
should
work.
But
I
don't
know
this.
E
That
makes
sense
to
me
as
well,
so,
like
I'm,
actually
my
plan
for
the
next
time
to
play
with
this
as
well,
and
actually
I
can
now
come
up.
A
Yeah
and
I'm
sold
on
the
idea.
We
don't
need
the
logical
layer
now.
Personally,
maybe
other
people
aren't,
but
just
I
think
that
actually
came
out
of
this
overthinking
situation
where
we're
like.
Well,
what?
If
someone
just
has
an
http
client,
then
they
would
like
need
this
extra
structure,
but
that's
actually
us
just
overthinking
things
like
they're.
Never,
that's
not!
That's,
not
real,
like
they're,
that's
if
they
want
extra
context
about
what
all
this
stuff
is
happening
and
then
the
higher
that
operation.
A
That's
calling
this
thing
will
provide
that
context
and
then,
in
like
practice,
that's
that
layer
is
always
there
and
that's
part
of
why
we're
seeing
such
a
giant
sandwich
of
spans
show
up
in
like
these
real
world
applications
once
we
put
them
together.
So.
E
Yeah,
so
basically
that
looks
like
it:
it's
a
good
idea
to
start
with
simple
approach
for
at
least
for
the
semantic
conversions
like
a
document
1.0
and
then,
if
you
have
like
a
if
you
see
this
this,
like
a
practical
demand
or
practical
needs
from
from
the
from
someone
we
can
think
about
this
once
again,.
B
A
Yeah
redirects,
all
these
other
things
become
really
simple
to
model
now,
because
you're
just
modeling
what
happened?
Not
not
getting
fancy
about
it
and
link
them
together.
I
wonder
if,
in
some
cases
of
that,
http
layer
sandwich
go
away
too.
I
don't
know,
there's
probably
some
cases
where
you
have
these
layers
of
http
clients
that
are
like
layering
all
the
physical
retries,
but
I
I'm
guessing
at
least
in
some
situations
that
middleware
layer
is
not
doing
that
right,
like
I
don't
know
like
quite
how
this
stuff
works
in
java.
A
But
when
you
have
like
a
plugable
http
underlying
http
layer,
I
have
a
feeling
the
thing
that
sits
on
top
of
that
probably
is
just
like
a
logical,
something
or
other,
and
maybe
that
thing
just
doesn't
need
instrumentation.
In
some
cases,.
B
Yeah,
the
problem
there
is
everywhere
in
java
and
python
in
node,
I
think
we
always
instrument
the
logical
layer
yeah,
but
it's
a
multiple
logical
instrumentation.
So
I.
A
A
Yeah,
I
I'm
curious
whether
if
we
go
away
from
that
logical
layer
for
http,
does
that
actually,
just
we'll
probably
still
have
the
need
for
that
thing.
You're
working
on
food
villa
where
you
collapse
several
layers
of
duplicate
instrumentation,
but
I
wonder
if
also
just
there
are
some
cases
where
that
that
vanishes
yeah
it
just
it
just
means
whatever
you're
using
to
do
the
underlying
http
request.
A
C
That'd
be
awesome,
I
think
that
I
mean,
I
think
mila
I
mean
most
people
participating
in
the
work
group
approved
anyway.
So
it's
just.
We
are
getting
the
green
check
marks
from
the
official
and
you
have
two
two
already
so
two
still
missing:
okay,.
A
I'll
try
to
give
you
one
tomorrow
awesome.
Thank
you.
E
Actually,
it
will
be
also
good
to
to
have
the
similar
kind
of
review
for
http
tab
that
I
have,
because
it
also
outlines
the
overall
scope
and
basically
retry
is
just
like
a
point
in
this
code.
Awesome
awesome!
Okay,
thank
you.
Thank
you.