►
From YouTube: 2021-07-22 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).
A
A
A
Oh,
so
we
got
a
couple
couple
items
for
review:
the
the
same
usual
items.
I
see.
We've
got
alex
knott
from
facebook
here
today.
Hey
alex,
welcome
to
the
sampling
segment,
hey.
C
Thanks
yeah
yuri
mentioned
this
group
to
me
and
invited
me
to
come,
and
I'm
yeah
I'm
just
really
mostly
interested
today
to
kind
of
listen
to
whatever
you
guys
are
talking
about
since
we're
thinking
about
sampling
ourselves,
obviously
so
just
kind
of
wanted
to
align
on
what
the
latest
greatest
thinking
is,
and
I'm
also
joined
here
by
my
colleague
matt,
but
he's
off
screen.
I
can't
get
the
conference
room
to
to
connect
properly
so
anyway,
we'll
mostly
be
listening
today
and
if
folks
have
questions,
I'm
happy
to
answer
them
too.
A
Great
awesome,
yeah,
absolutely
well.
We've
got
two
items
on
the
agenda.
The
first
item-
I
I
think,
is
really
quick,
so
jaeger
would
like
to
have
a
remote
sampling
merged
in.
A
I
think
this
is
a
fairly
trivial
decision,
in
the
sense
that
this
the
goal
here
is
just
to
enable
the
existing
remote
sampling
algorithm
for
the
jaeger
sampling
plug-in,
in
which
case
it's
just
a
backwards
compatibility
issue.
A
A
I
see
carlos
just
popped
in
hey
carlos,
hey.
What's
up
hey,
we
were
just
getting
into
this
jaeger,
remote
sampling,
spec
pr,
and
I
was
asking
whether
it
seems
like
it's
correct
me
if
I'm
wrong
carlos
but
seems
like
this
is
just
just
for
backwards.
Compatibility
for
jaeger,
like
existing
jager
functionality,
correct.
D
Yeah,
that's
my
impression
all
along.
I
think
that,
based
on
paul
paul's
comments,
this
is
not
something
to
look
forward
to
like
in
the
future.
It's
just
for
existing
users.
A
Okay,
so
in
that
case
I
think
it's
it's
fairly
trivial
to
to
merge,
but
sampling
group
people
be
great
people
here
could
do
it
once
over.
E
So
yuri
asks
the
sort
of
big
question
here,
which
is
that,
like
this
is
a
narrow
spec
that
almost
tries
to
walk
around
the
spec
to
say
that
there's
a
whole
body
of
stuff
that
you
could
do
that
wasn't
specked
out
before
and
now
you
can
just
bring
it
in
and
it's
still
not
specked
out
and
that's
like
so
yuri's
question
is
shouldn't.
A
That's
a
that's
a
great
point.
My
presumption
here,
though,
is
that
that
this
is
just
backwards,
compatibility
for
the
jaeger
sampler
specifically
and
that
it's
fate
accompli
right,
like
that,
that
format
is
already
defined
over
in
jaeger.
If
you're
going
to
implement
this,
you
don't
get
to
make
it
up.
You
have
to
go
implement
what
jaeger's
currently
using
over
there.
So,
but
as
a
good
point,
it
should
at
least
point
to
something
on
yeager's
side.
A
Yeah,
but
you
get
what
I'm
saying
right,
like
my
presumption
is
like
this
is
already
spec.
So
it's
not
there
isn't
room
for
discussion
about
about
what
this
particular
config
language
looks
like,
however,
when
it
comes
to
like
this
is
just
for
the
jaeger
sampling
plugin,
like
we're
talking
about
something,
that's
more
like
what
we'd
like
to
say.
Moving
forward
is
like
standard
sampling,
stuff
baked
in
to
open
telemetry,
regardless
of
if
you're,
using
jaeger
or
not.
A
So
this
is
what
we
want
to
define
in
this
working
group
are
things
that
are
going
to
supersede
this
this
plug-in
so
that
in
the
future
you
would
never
run
it,
but
in
order
for
jaeger
to
dump
their
clients
and
move
over
to
using
open
telemetry
clients,
they
need
to
have
backwards
compatibility
with
their
current
stuff.
E
A
D
Can't
yeah
in
this
specific
sorry,
in
this
specific
case,
we
can
ask
jagger
to
jury
specifically
to
tell
us
where
this
is
defined.
As
you
mentioned
earlier,
there
must
be
specific
place:
specific
set
of
users
existing
users
that
could
force
us
to
support
them.
You
know
in
a
legacy
way,
if
there's
nothing
and
they
want
to
support
those
users
through
something
new,
then
what
josh
mentioned
would
apply.
So
we
should
probably
ask
them
for
details
about
that.
D
A
I'm
not
super
familiar
with
what
jaeger's
doing,
but
I
think
that's
a
good
point,
there's
stuff
that
jaeger's
done
up
to
this
point.
I
think
there's
a
fair
amount
of
sampling
stuff,
that's
actually
just
like
they
haven't
actually
implemented
it.
Yet
they
just
think
it
would
be
a
good
idea
and
I
don't
think
we
should
be
adding
anything
that's
in
in
that
category.
In
fact,
I
might
say,
jaeger
should
stop
designing
that
stuff
over
there.
If
we're
gonna
be
trying
to
design
standard
stuff
over
here.
E
Yeah
that
gets
to
my
concern
is
that,
like
when
a
new
user
enters
the
space
and
says,
looks
around
and
sees
that
there's
this,
the
jager
standpoint
they're,
probably
gonna,
start
using
it,
and
then
they
ask
their
vendor.
Why
don't
you
support
this
thing
that
otel
puts
in
the
standards
the
jaeger
sampler?
So
can
I
use
that
and
will
you
like,
like
I
feel
like
it's
the
moment
this
pr
merges
vendors
are
going
to
be
expected
to
support
the
acre
sampler
and
I
don't
even
know
exactly
what
its
specs
are.
E
On
the
other
hand,
I
we
spent
a
lot
last
meeting
talking
extensively
about
probabilities,
which
all
I
care
about
really
from
a
vendor's
perspective
is,
can
I
count
these
spans
as
they
come
through?
I
would
love
you
to
be
able
to
use
your
jaeger
sample
as
long
as
I
get
probabilities
from
my
perspective,
but
it
is
a
user
feature
getting
to
configure
a
sampler,
and
you
know
I
think
users
are
going
to
start
doing
it
and
then
the
ability
to
write
a
standard
or
a
spec
will
be
lost.
F
Just
looking
at
the
the
otep,
it's
like
they're
populating
the
hotel,
tracer
sampler
field,
with
a
very
specific
jaeger
remote,
where
all
the
others
are
like,
always
always
off,
trace
parent
based,
etc.
A
Yeah,
I
think,
that's
fair.
We've
we've
definitely
taken
we're
gonna
hit,
you
know,
environment,
variable
saturation
point
somewhere
along
the
line,
and
so
I
hate
environment
variables
as
a
form
of
configuration,
but
I
think
for
this
one
though
they're,
just
following
the
convention
of
what
they've
been
doing
for
all
the
the
jaeger
stuff
and
it's.
E
Basically,
just
a
configurable
sampler,
it
says
the
sampler
will
be
determined
by
a
data
file
that
will
be
loaded
and
I'm
saying
that
what
yuri's
question
is
is
like
this
is
referring
to
a
spec,
that's
just
like
by
reference,
not
not
anywhere,
so
that
you're
gonna
load
this
spec
and
do
some
sampling
yep
like
the
b3
propagator,
it's
a
legacy.
E
I
get
it,
but
I'm
just
a
little
worried
that
you
know
not
having
the
hotel
kind
of
answer
that
question
directly
means
it
will
become
a
de
facto
answer,
yeah,
which
is
fine,
we're
just
not
we're
not
looking
at
it.
E
Are
all
questions
worth
worth
raising
in
that
and
nev
your
point
about
multiple
samplers?
It
was
mentioned
briefly
in
one
of
my
o-tests
and
it
it
seemed
to
create
more
more
trouble
and
more
confusion
than
it
was
benefiting
anybody.
So
I
removed
the
idea
from
the
proposal
or
the
draft
language
that
I
had
written,
but
it
it
stands
to
reason
that
you
can
do
multiple
sampling
and-
and
you
know
people
know
how
to
do
that
and
I'm
not
sure
we
need
to
spec
anything
in
there
in
that
area.
F
This
question
to
it
like:
if
please
go
ahead
now
sorry,
we've
got
lag
happening
yeah,
so
yeah
having
multiple
simple
ic
is
problematic,
but
it's
then,
how
do
we
go
about
configuring
that?
So,
if
we
have
this
as
custom,
do
we
have
custom
one
custom,
two
custom,
three
or
you
know,
do
we
say
we've
got
the
standard
hotel
set.
You
know
parent,
based,
etc
and
custom.
A
You
would
need
to
have
this
sampler
plug-in
installed
right
for
this
thing
to
work,
which
is
a
bit
different
than
speaking
in
something
directly
into
the
sdk
that
has
several
sampling
strategies.
A
So
I
think
that's
a
bit
why
it
would
be
a
separate
piece
of
configuration
but
anyways,
I
I
don't.
I
don't.
I
think
long
story
short.
I
don't
want
anything
happening
with
this
particular
legacy:
jaeger
thing
to
define
what
we're
going
to
do
going
forwards.
A
E
A
Yeah,
well,
they
they
need
it,
because
this
this
stuff
exists
today
in
jager
right.
That's,
that's!
That's
what
I
believe.
Maybe
that's
the
thing
we
should
clarify.
If
this
stuff
doesn't
exist
today
in
yeager,
then
you
know
we
should
say
hold
off
on
it.
But
my
impression
is
this
is
one
of
the
things
they
already
have
and
it's
actually
a
blocker
for
them.
Adopting
the
open,
telemetry
clients
is
because
they've
got
this
core
feature
to
jager
that
doesn't
have
any
support
in
open,
telemetry
right
now,
and
so
they
need
to
get
get
well.
A
E
E
A
A
That's
why
we
have
the
word
jaeger,
all
over
it
and
all
of
the
environment
variables
and
everything
else
it's
like
this
is
only
this
is
only
for
backwards,
compatibility
with
each
other
today
and
what
we're
doing
in
this
group
is
defining
how
it's
going
to
work
going
forwards,
but
I.
G
A
D
Actually,
one
one
question
that
we
should
ask
again
just
for
clarification
purposes
to
pavel.
He
said
that
he
wanted
to
add
this
in
this
pr,
because
there
are
existing
users
and
he
is
afraid
that
the
native
hotel
sampling
solution
will
take
a
little
while.
So
maybe
I
don't
know,
if
that's
really
the
case,
what
if
they
hold
to
this
a
little
bit
longer,
we
should
probably
talk
to
paul
and
try
to
have
him
come
to
the
next
meeting
or
something
you
know
what.
But
what
are
the
expectations?
H
So
I
I
have
a
question
I
mean
I
don't
fully
follow
the
entire
discussion,
but
I
know
that
what
we're
doing
is
that,
like
for
the
azure,
monitor
sampling
algorithms,
they
do
not
align
with
the
open
telemetry.
So
what
we're
actually
doing
this
semester
is
that
we're
creating
a
public
that
plug-in
to
which
any
azure
monitor
user
can
select
the
hotel
sampler?
H
So
that
way
we
can
get
consistent
sampling
right,
because,
right
now
we
can't
get
consistent
sampling
because
the
algorithms
are
different,
and
so
is
this
something
similar
to
that
when
you're
talking
about
existing
jaeger
users,
because
that's
how
we're
trying
to
solve
the
sampling
one
of
the
sampling
issues
that
we
have
between
you
know
our
vendor
specific
algorithms
versus
you
know
the
vendor
neutral
of
hotel,
and
so
how
does
jaeger's
proposal?
Because
I
haven't
read
it?
My
apologies?
H
A
A
A
But
you
could
ship
in
azure
distro
of
open
telemetry
that
just
was
just
open
telemetry,
but
with
the
plugins
you
need
for
to
work
with
audio
included.
So
so
the
only
difference
here
is
we've
committed
to
saying
out
of
the
box
like
we're
required
to
support
plugins
for
the
existing
open
source
systems.
So
the
three
systems
that
open
telemetry
is.
A
A
To
jager
or
prometheus
and
say
you
guys
have
to
maintain
this
stuff
yourself,
we're
saying
we
want
to
make
sure
open.
Telemetry
is
compatible
with
these
open
source
systems,
so
so
they
need
plugins.
Then
we're
going
to
make
sure
those
plugins
are
are
available
to
people.
So
that's
that's
the
only
the
only
difference,
and
because
we're
saying
it's
a
requirement
that
that
the
core
teams
maintain
these
plugins.
That
means
it
has
to
go.
A
The
definition
of
these
plugins
has
to
be
in
the
spec,
whereas
with
azure
we're
not
saying
that
the
core
teams
are
required
to
maintain
this
plug-in.
So
the
audio
team
maintains
this
plug-in,
so
they
don't,
they
don't
need
to
be
in
the
spec.
You
guys
can
put
them
wherever
going
forwards.
What
we
want
to
do
is
come
up
with
something
that
is
like
open,
telemetry,
sampling.
A
The
same
way,
we
have
otlp
for
our
own
data
format
so
that
there's
a
format
we've
defined
as
a
inspect
out
and
implemented
that
azure
and
others
could
then
begin
to
use
in
the
future
say
like
okay,
now
that
this
is
defined
in
open,
telemetry
we're
going
to
start
consuming
otlp
data,
we're
going
to
start
supporting.
You
know
these
sampling,
algorithms,
etc,
and-
and
we
feel
confident
that
that's
that's
a
stable
target
for
us
to
commit
to
supporting,
because
it's
controlled
by
open
telemetry.
A
So
it's
not
like
some
other
outside
group
can
come
along
and
be
like.
No
now
we've
made
a
bunch
of
backwards,
incompatible
changes
to
this
or
did
something
weird,
so
you
don't
have
to
be
committed
to
supporting
any
of
the
jaeger
stuff
just
because
it's
in
there
just
likewise,
you
don't
have
to
commit
to
supporting
b3
or
anything
outside
of
the
core
open,
telemetry
stuff.
It's.
G
A
A
I'm
just
the
the
point
I'm
making
is
that
we
we're,
on
the
hook
for
supporting
a
thing
that
they've
this
is
like
backwards
compatible,
so
we
don't
get
to
define
what
this
looks
like
any
more
than
we
get
to
define
what
e3
headers
look
like
or
something
it's
just
about
supporting
existing
industry
stuff,
but
it
also
should
be
off
in
the
corner
with
the
word
jager
plastered
all
on
top
of
it,
it's
not
a
requirement
that
that
this
comes
baked
into
core.
You
know
like
this
thing
uses
grpc.
A
A
Yes,
yeah:
we've
we've
committed
to
allowing
jaeger
to
switch
over
to
using
open
telemetry
as
their
as
their
default
clients
and
end
of
life,
their
current
set
of
clients
and
their
the
one
final
thing
that
they
need
in
order
to
be
able
to
do
that
is,
is
to
have
this
remote
sampling
stuff
baked
in
because
this
is
the
thing
their
clients
currently
do,
that
isn't
isn't
a
concept
in
open
telemetry
and
once
we
have
our
own
standard
version
of
this
stuff,
they're
willing
to
switch
over
to
having
their
back
and
support
that
the
same
way
they're
baking,
the
collector
you
know
as
the
as
the
front
end
to
their
back
end
and
all
that
kind
of
stuff.
A
E
A
E
A
A
I
would
recommend
bringing
it
up
in
the
in
the
in
the
thread
to
me.
I
think
it's
they're
totally
separate
things
and-
and
it
doesn't
block
us
from
writing
our
own
remote
sampling
and
them
adopting
that
going
forwards
in
the
future,
any
more
than
it
blocks
jaeger
having
their
own
data
format
didn't
block,
but
I
still
think
we're.
E
A
I
think
I
think
you're
being
hysterical
josh
and
I
want
to
move
on
frankly
right
all
right.
Let's
move
on
to
the
stuff
we're
actually
trying
to
spec
out,
so
we've
got
something
passed
over.
A
Do
you
want
to
stay
on
the
subject?
I
got
zero.
You
had
to
go
now:
ted
yeah.
I
I
think
I
I'm
really
gonna
be
blunt
with
you
josh.
I
think
you're
being
hysterical
and
you're
you're,
making
a
huge
deal
out
of
something
that
actually
isn't
a
huge
deal
like.
I
hear
your
complaint
and
you
should
you
should
log
it
there,
but
I
I
do
think
that
it's
it's
not
something
that
the
jaeger
team
is
planning
on,
like
not
supporting
what
we're
doing
going
forward
or
that
we're
not
going
to
write
a
remote
sampling
stuff.
A
It's
just
existing
back
ends
won't
be
able
to
talk
to
the
open,
telemetry
clients
today,
unless
they
they
have
the
ability
to
port
their
sampler
plugins
over.
So
it's
just
it's
just
it's
just
us.
It's
just
us
making
good
on
our
support
promises
to
to
jaeger.
I
don't
think
they're
trying
to
do
something
weird.
They
don't
think
it's
going
to
become
some
standards,
we're
stuck
with.
D
We'll
see:
okay,
yeah
george,
let
me
follow
back
up
with
you
about
that
fear.
Let's
try
to
focus
the
rest
of
the
hour
on
moving
on
and
I
promise
you.
I
will
try
to
support
your
position
about
not
making
this
a
thing.
So
now,
let's,
let's
do
this
now.
A
Yeah,
I
think
we
should
move
forward
with
our
own
concept
of
remote
sampling
and
I
know
pavel
and
yuri
and
people
from
the
jaeger
team.
I
think
this
might
be
why
alex
is
on
the
call.
Is
they
have
ideas
about
what
is
good
and
what
is
bad
about
their
current
stuff
and
they
want
to
make
an
improved
version
of
it,
but
they
want
that
improved
version
of
it
to
be
a
backwards
and
compatible
thing.
A
That
is
open
telemetry,
like
the
open,
telemetry
version
of
this
stuff,
rather
than
continuing
to
iterate
on
this
stuff
on
the
jager
side.
So
this
is
purely
like
legacy
support
it's
what
they
see
this
as,
but
I
gotta
run
so
I'll,
stop
being
contentious
here
and
I'll
see
you
guys
in
the
next
meeting.
A
E
Well,
we've
had
a
disagreement.
I
will.
I
will
stop
saying
that
thing
and
I'll
wait
to
be
seen
to
see
whether
I
was
right
or
wrong,
but
I
do
think
there
are
separate
topics
at
work
here
in
sampling,
and
I-
and
I,
if
I
may,
since
ted
now,
is
off
the
call
bringing
us
back
to
the
notes
and
I
had
dropped
my
own
topic
there.
E
There's
this
otep
148,
it's
been
open
for
a
long
time,
it's
grown
and
grown
to
address
questions,
and
I
want
to
remind
people
that
oteps
were
meant
as
a
sort
of
foundation
for
future
discussion
and
for
future
development
of
the
hotel
space.
I
think
I've
met
the
bar
and
it's
too
long
for
most
people
to
read
at
this
point,
so
the
few
people
who
have
read
it.
I
would
like
to
just
approve
it:
we'll
merge
it
and
nothing
is
binding.
E
In
that
document,
we
move
on
to
write
a
spec,
and
you
know
yuri
put
some
sort
of
questions
in
the
document,
and
I
asked
him
about
it
yesterday
and
I
think
that
the
point
of
yes
last
week's
meeting
was,
I
don't
think
anyone
wants
to
to
spec
out
propagated
probabilities.
It's
it's
a
dead
topic.
So,
even
though
I
wrote
up
how
to
do
it
like
it's
just
a
proposal,
that's
now
dead
and
I
think
we
should
merge
it
and
move
on
and
forget
it.
E
You
know
forget
that
half
of
it
half
the
document
is
like
historical
perspective
and
not
active.
So
anyway,
my
request
is,
I
don't
think,
there's
anything
contentious
left
there
can
be
nitpicks.
I
will
address
the
last
remaining
issues
as
many
of
them
as
there
are.
I
will
happy
to
happily
refer
to
ottmar's
work
and
add
another
addendum
about
partial
sampling
thing
and
and
and
write
up
our
conclusion,
which
is
trace:
id
ratio,
sampling,
no
propagation
and
and
there's
a
future
problem
about
incompleteness
that
we
talked
about
last
week.
E
D
And
by
the
way,
even
if,
if
if
some
of
you
are
not
like
part
of
the
community,
please
prove
that
in
any
case
like
it
often
happens
that
we
need
experts
that
we
don't
have
in
the
in
the
core
open
telemetry.
But
we
need
to
make
sure
that
other
experts
they
they
said
this
is
good
to
go.
So
please
approve
that,
even
if
you
are
not
like
an
approver
or
something
just
go
on,
go
for
it.
E
That
was
all
I
had,
because
I
truly
don't
believe
there's
anything
worth
discussing
in
this
group
left
in
that
document.
It
just
explores
a
lot
of
options
and
leaves
it
for
the
next
step.
E
The
agenda
is
now
finished,
I
don't
know
if
anyone
else
would
like
to
add
to
it
or
raise
a
topic
or
actually
just
open
up
the
one
that
we
left
behind
half
five
minutes
ago,
which
is
whether
hotel
is
has
an
appetite
to
spec
its
own
remote.
E
E
H
Time
I
had
more
of
a
question
josh,
just
a
general
topic
on
sampling
for
the
group
is
that,
like
I
know,
it
seems
like
right
now,
as
what
ted
was
saying
is
that
for
each
sdk,
sig
they're
able
to
go
ahead
and
define
what
sampling
that
they
want
to
be
able
to
support
like
there's
various
plugins
and
whatnot,
and
I
think
one
of
the
challenges
and
why
I
joined
here
is
that
what
I
want
to
be
able
to
get
to
is
we
have
that
defined
spec
one
for
the
config,
but
two
what
are
going
to
be
the
set
of
like
predefined,
built-in
samplers
within
open
telemetry,
that
we
want
all
the
vendors
to
use
right?
H
And
I'm
just
curious
like
how
close
are
we
to
having
those
discussions
or
defining
that?
Because,
at
least
from
my
perspective,
I
want
to
reduce
the
amount
of
you
know:
legacy
support
that
our
teams
have
to
do
and
really
want
to
use
the
open
source
samplers.
But
right
now
like,
for
example,
I
we
have
an
intern
who's.
Trying
to
you
know
we
have
them
on
a
a
project,
and
you
know
the
built-in
samplers
that
are
in
the
net.
H
Sdk
repo
doesn't
support
some
of
the
things
that
we
need
and
we're
gonna
have
to
build
a
custom
sampler.
Just
for
you
know
the
project,
but
then
that's
not
gonna,
be
something
that
is
would
probably
be
contribute
back
to
the
community,
because
it's
very
specific
for
this
one.
You
know
intern
project,
and
so
those
are
things
that
I
just
kind
of
want
to
avoid
long
term.
E
Maybe
you
could
spend
a
minute
or
two
telling
us
more
about
the
sampling
that
you're
trying
to
match,
because
this
has
been
one
of
the
biggest
problems
in
this
group
in
the
past.
Is
it
like
there's
different
approaches
that
are
so
different?
It's
like
really
hard
to
fit
them.
In
the
same
conversation.
H
Is
that
like
for
the
application
insights,
which
is
falls
under
azure,
monitor
it
uses
tail-based
sampling
right
and,
as
we
look
here
most
of
the
stuff
that
I
saw
out
outside
of
the
hotel
collector,
because
I
do
see
that
there's
a
tail
big
sampler
in
the
hotel
collector,
but
for
the
other
sdks
I
don't
see
that
it's
all
head-based
parent-based,
it
still
uses
you
know
the
different
techniques
or
whatnot,
but
that
in
itself,
if
you're
thinking
about
a
just
this
single
stack
trace.
H
If
each
component
is
using
like
if
the
first
one
is
using
head
base
and
next
one
is
using
tail
base,
there's
no
way
real
or
vice
versa.
It's
going
to
be
really
hard
to
make
sure
that
we're
sampling
in
based
on
the
the
producer
side
that
the
producer
is
saying.
Here's
like
10
spans
that
we're
sampling
in
how
does
the
consumer
know
hey.
H
I
need
to
go
ahead
and
main
respect
that
and
sample
those
same
ones
in
if
the
algorithms
are
different
and
just
on
the
offset
you
know,
head-based
versus
tail-based
are
just
so
different
right,
and
so,
where
would
we
want
to
invest
in
as
a
vendor
versus
the
the
community?
And
I
think
that's
the
real
problem
that
we
want
to
solve
is
making
sure
that
you
have
consistent
sampling,
regardless
of
what
the
techniques
are.
H
I
I
think
that
is
just
you
know,
what's
going
to
be
best
from
like
cost
reduction
those
types
of
things,
but
we
just
can't
ensure
end
users
that
they're
going
to
have
complete
traces
at
this
point.
E
E
That
was
the
topic
that
was
at
hand
and
the
other
sense,
the
the
the
other
that
I
wrote
kind
of
exploded
in
a
way
that
I
wasn't
hoping
it
would
into
this
lengthy
document
about
kind
of
the
same
issue
that
you
described,
which
is
that
tracing
is
a
little
special
because
you
make
this
head
decision
up
front
and
then
you
and
then
later
on,
you
might
want
to
re-sample
and
and
that's
a
technique
that
people
know
about,
and
but
it
changes,
probabilities
and
stuff
like
that.
E
So
one
one
avenue
is
to
talk
about
how
to
just
literally
convey
that
information
which
is
kind
of
what
I
was
trying
to
do,
but
it
doesn't
talk
about
how
to
choose
which
policy
you're
using,
and
that
was
a
jaeger
sampler
does
all
that
stuff.
E
So,
in
some
sense,
everything
we've
talked
about
here
is
trying
to
answer
the
questions
that
you're
that
you're
kind
of
arrived
with,
and
so
maybe
the
I
maybe
the
answer
is
in
the
documents
that
we
have
already
there's.
E
This
notion
called
trace
id
ratio
sampler,
which
is
meant
to
be
the
consistent
sampling
approach
that
we
all
agree
to,
and
it's
been
strongly
supported
by
atmar
who's
on
the
call
here
who
also
posted
a
research
report
this
week.
That
gives
even
more
like
weight
to
that
approach.
It
doesn't
absolutely
solve
the
incompleteness
problem,
however,
so
that
was
also
discussed
last
week.
I
my
goal.
My
hope
my
belief
is
that
the
trace
id
ratio
sampling,
roughly
speaking,
addresses
the
concern
about
consistency
that
you
had.
E
H
E
H
E
It's
it's
sort
of
so
long
at
this
point.
If
I
sit
down
to
proofread
it
I'm
going
to
like
get
halfway
through
and
like
get
it
interrupted
by
something
and
then
like
resume
halfway
through
and
like
they'll
be
typos,
because
I
didn't
read
through
continuously,
like
I
don't
know
like,
I
can
spend
more
time
on
it,
but
I
don't
think
it's
benefiting
anybody
now
that
we've
kind
of
circled
around
it
enough
times
with
a
few
of
the.
B
E
B
Also
more
to
prevent
people
from
approving
it
right
because
there's
more
contentious
issues
but
michael,
if
you
haven't,
read
the
otep.
Actually,
if
you
read
it
through
and
it
does
sound
like
a
good
basis
for
the
stuff
that
you're
talking
about
giving
it
a
thumbs
up
could
be.
You
know
something
that
would
help
yeah.
But
okay,
we'll
do.
E
And
then
microsoft
had
has
had
people
proposing
things
about
sampling
in
the
past.
I
know
lumila
wrote
an
otep
135
or
something
like
that.
Is
this
the
same
description
that
were
the
same?
Yes,.
H
Yeah
I
mean
that
was
one
that
was
one
of
the
the
issues
that
she
had
brought
up.
I
know
there
hasn't.
I
haven't
looked
at
that
one
in
a
while,
but
yes
I
mean
that's
one
of
the
the
topics
there
there's
a
there's.
I
mean
we
can
there's
no
point
in
enumerating
them
all
here.
I
think
at
the
end
of
the
day,
it's
like.
Okay,
generally,
I
get
the
focus
of
what
we're
trying
to
do
here
and
then
having
the
right
folks.
H
You
know
submitting
whether
it's
a
no
tap
or
prs
or
whatnot
for
discussion.
I
think
that'll
be
a
better
approach.
E
Okay,
that
sounds
sounds
good
and
just
affirmatively
believe
that
the
trace
id
ratio
sampler
is
the
is
the
thing
that
nudemilla
was
kind
of
asking
for
us
to
finish
up
and
opmars
also
supported
it.
If
you
read
through
this
paper
like
roughly
speaking,
we
need
to
have
a
consistent
random
number
associated
with
everything
and
there's
lots
of
lots
of
good
math.
E
You
can
do
once
you
have
that
and
whether
it's
a
true
random
number
or
whether
it's
hashed
from
the
trace
id
is
sort
of
an
open
question,
but
either
way
like
everyone
wants
that,
and
I
think
we're
going
to
move
forward
with
trace
id
ratio
sampling
being
fully
specced
in
a
way
that
we
can
all
benefit
from
it,
and
that
leaves
so
many
other
options
for
sampling.
But
at
least
we'll
have
a
common.
E
With
that,
we've
reached
the
end
of
our
agenda.
I
know
opmar's
here
and
if
you'd
like
to
spend
a
moment
talking
about
your
research,
I
certainly
would
love
to
hear
it,
but
I
don't.
C
E
But
yeah,
please
tell
us
something.
I
truly
can
say
that
I
read
some
of
some
of
your
report.
I
got
to
the
middle
and
run
out
of
time,
so
there's
some
derivations
and
so
on
that
I
sort
of
skimmed
over.
But
I
got
the
big
big
idea
and.
G
So
it
was
my
understanding.
Basically
what
what
was
the
motivation
about
this
research
work
was
to
the
question,
for
example,
if
you
want
to
count
the
number
of
choices
which
touched
some
service
e
and
some
other
service
b
right,
if
you
want
to
count
those,
and
especially
if
you're
sampling
and
if
you're,
not
using
headpiece
sampling,
because
then
it's
easy
of
course,
but
we
if
you
do
not
want
to
apply
one
sampling
rate
on
everything
but
more.
G
If
you
want
to
be
more
adaptive
using
different
sampling
rates
like
the
razer
d
ratio,
sampling
basically
would
allow,
then
there's
the
question:
how
to
to
estimate
those
number
how
many
choices
touched
seriously
and
service
b
right,
and
so
this
paper
basically
generalizes
that
a
little
bit
but
yeah,
and
so
you
can
also
estimate
other
things.
G
Other
quantities
like
if
you
want
to
calculate
the
average
three
step
or
whatever,
but
most
important
for
us,
is
answering
the
question:
how
many
traces
touch
different
regions
in
your
system
and
if
you're
using
different
sampling
rates,
then
it
gets
complicated,
especially
if
you're
not
consistently
sampling.
So
it's
basically
a
must
to
have
razor
d
ratio
based
sampling.
I
think,
if
you're
not
using
trace
id
ratio
based
sampling
and
you
are
using
different
sampling
rates
in
your
system.
G
E
I
don't
have
any
specific
questions,
but
I
really
want
to
thank
you.
I
had
never
kind
of
thought
through
some
of
the
ways
to
use
sampling
through
traces.
The
way
you
have
and
it's
great
to
be
able
to
to
sort
of
firmly
say
how
we
can
use
this
data
to
count
things
like
what
number
of
traces
were
there
that
had
a
grandchild
and
a
parent
without
the
intermediate
nodes.
Being
there,
that's
really
great.
So
this
partial.
G
Trace
sampling
basically
can
be
seen
as
a
generalization
of
head
based
sampling.
So
because,
if
you
propagate
the
sampling
rate
of
the
head
to
all
children,
then
they
can
use
the
same
sampling
rate
and
by
definition
you
would
have
the
same
effect
as
at
this
sampling.
So
basically,
this
approach
kawas
also
had
base
sampling.
So
if
you're
propagating
the
sampling
rate
of
of
of
parents
to
children,
I
mean
this.
This
is
possible
it
if
you're
a
restricting
to
to
discrete
sampling
rates.
G
So
the
question
which
I
have
is:
do
we
need
something
else
than
gracity
ratio
based
sampling
and
if
we
do
not
need
something
else,
then
we
could
think
of
redefining
the
sample
interface,
because
what
what
the
sampler
does
basically
is
just
returning
a
sampling
rate
for
a
specific
span,
so
it
can
be
different
for
every
span
right
so
that
that's
what
the
sample
basically
has
to
do
and
if
the
sampling
decision
is
basically
just
a
comparison
with
the
random
number
and
the
sampling
rate.
G
So
if
we,
if
we
code
yeah,
if
we
could
agree
on
on
this
kind
of
sampling
decision-
and
we
could
think
of
redefining
the
sample
interface,
which
just
returns,
the
sampling
rate
for
every
span
and
and
the
sampling
decision-
could
be
built
in
in
open
telemetry.
G
So
then,
of
course,
we
could
support
different
samples
because
we,
the
the
the
the
return
value
of
the
sample,
is
the
sampling
rate,
and
this
is
everything
what
we
need
for
you
know,
extrapolation
and
so
on
so
and
as
said,
you
can
also
implement
a
realized,
parent-based
sampling
or
head-based
sampling.
With
this
approach,
what
you
need
is,
of
course,
the
sampling
rate
of
the
parent,
which
has
to
be
propagated
somehow.
G
But
if
you
have
that,
then
the
sample
apparently
sampler
could
just
return
the
sampling
rate
which
it
received
from
its
parents,
and
you
have
the
same
effect.
Basically
so
I
mean
this
would
yeah
would
simplify
things
a
lot
if
we
say
the
sample
rate
just
returns,
the
sampling
rate
and
nothing
else,
and
because
then
samples
are
also
forced
to
define
the
sampling
rate.
And
so
it's
always
there,
this
sampling
rate,
and
so
we
always
have
the
sampling
rate
for
the
span
or
the
adjusted
count.
E
Agrees
on
death,
but
well,
I
think
that
everyone
won't
because
there's
so
many
people
who
are
out
there
thinking
that
sampling
is
just
a
way
to
choose
spans
and,
and
so
you
can
return
one
and
you
want
to
have
the
span
and
zero
when
you
don't
want
to
have
a
span.
I
get
that,
but
it
seems
like
there's
a
not
a
great
appetite
for
propagating
probability,
so
so
the
parent
sampler
is
going
to
have
to
return
one
or
zero.
But
that's
not
the
probability
we
should
return
in.
G
I'm,
what
do
you
think
I
mean
currently
is
the
parent-based
sampler
just
uses
the
sampling
decision
of
the
parent
right
so
and
if
you
are
receiving
the
same
random
number,
which
is
necessary
if
you're
using
traceability
ratio
based
sampling
and
if
you
also
use
receiving
the
sampling
rate
which
was
chosen
for
the
root
span,
then
you
immediately
see
if
the
parent
was
sampled
or
not,
and
so
you
can
derive
the
same
decision.
The
same
consistent
decision
for
spain's
of
of
all
children
trying
to
spends,
and
so
what
you
get
basically
is
is.
E
G
Because
we
don't
know
for
the
parent,
the
problem
with
the
parent-based
sample
is
that
it
does
not
attach
the
sampling
probability
to
the
span
right.
So
it's
a
you
have
to
collect
all
spans
somewhere
and
then
you
can
find
the
sampling
probability
from
the
from
its
roots.
Then,
so
you
have
to
first
compose.
E
So
if
we
have,
the
parent-based
sampled
span
could
encode
something
like
adjust
count
of
like
see
parent
like
literally
this,
the
text
could
be
see
parent
and
then,
and
then
you
you
would
know
that
you
have
to
assemble
that
trace
to
get
to
get
a
suggested
count
because
it
was
using
the
parent
sampler.
I
think
that's
like
fine
approach,
because
we're
going
to
tell
people
not
to
do
it
anyway,.
E
G
We
also
have
to
think
about
propagating
the
the
random
number.
Somehow
I
mean,
of
course
you
can
use
the
trace3d
and
hash
them
everywhere,
but
this
will
be
quite
complicated.
I
mean
we
need
a
hash
algorithm
which
is
consistently
implemented
on
all
languages,
which
is
not
easy.
I
would
say
to
find
one
which
I
agree
gives
the
same.
H
G
So
the
the
solution
which
was
proposed
by
luke
miller-
what's
the
name,
I
think.
G
H
G
G
Quite
overhead,
I
would
say,
because
you
have
need
to
hash
the
trees
at
d
at
for
every
span
I
mean
hashing
is
not
free.
So
if
you
would
generate
this
is
a
random
number
at
roots,
then
this
would
be
much
cheaper
because,
yes,
I
mean,
as
described
in
my
paper,
you
you
you
could
just
and
you,
if
you're,
restricting
to
powers
of
one
half
sampling
rates,
then
you
just
need
to
send
one
byte
yeah.
G
D
E
I
get
it
well
that
that
this
last
topic,
I
think,
is
one
that
is
is
probably
the
next
big
discussion
for
us.
I
think
yuri
has
been
pushing
back
on
anything
anytime.
E
I
said:
let's
propagate
probability,
he
pushes
back
because
the
entire
world
has
been
working
without
it
first
for
a
while,
but
if
we
have
to
choose,
I
think
it
sounds
like
we
have
to
choose
between
hashing
trace
ids
with
a
spec,
that's
going
to
be
really
hard
to
get
right
or
with
propagating
random
numbers
which
might
be
easier
than
propagating
sampling
rates.
E
I
think
people
there's
just
a
little
bit
more
math
involved
if
you're
saying
that
you
have
to
propagate
a
probability
as
opposed
to
a
random
number,
but
I
guess
this
requires
a
little
more
thought.
E
We're
approaching
the
end
of
the
hour
and
ted
begs
us
to
cut
off
before
the
next
hour
starts.
So
maybe
we
should
I've
made
a
note
to
myself
about
what
otmar
just
said.
It
sounds
like
we,
we
could
post
another
issue.
A
new
issue
is
to
finish
the
trace
id
ratio.
Sampler.
We
need
one
of
the
two
things
probably
get
a
random
number
or
a
consistent,
well-specced
out
hash
function,
neither
which
looks
great,
but
at
least
it's
we're
narrowing
down
on
those
questions.
E
I
I
took
too
many
action
items
earlier
in
the
week
and
I'm
not
promising
to
get
it
done,
but
I've
made
a
note
and
if
it
doesn't
happen
by
next
week,
it'll
still
be
there
and
I'll
still
have
my
note.
I
think
we
should
go
now.
I
can
probably
help
you.
I
can.