►
From YouTube: 2022-09-22 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
D
D
C
D
C
C
Like
survey
exercise,
I
guess
I
would
wonder
if,
like
anyone
that
has
like
reviewed
the
notes
or
otherwise
like
had
any
other
like
observations
or
reactions,
to
some
of
the
descriptions
of
how
these
other
things
work,
that
we
you
know,
we
talked
about
x-ray
like
the
existing
hotel,
stuff
and
refinery,
because
I
understand
that,
like
is
new
information
to
many
of
us.
A
lot
of
us
have
like
some
familiarity
with
some
of
those,
but
I
know
I
didn't
have
familiarity
with
all
of
them.
C
A
C
C
But
I
don't
know
I
don't
read
many
oteps
truthfully,
so
I
don't
know
if,
if
there
is
like
a
convention
of
like
you
know
putting
things
in
an
appendix
on
otecs
or
like
linking
to
like
somewhere
else
when
there's
like
supplementary
information,
that
like
establishes
some
of
the
like
motivations
or
ideas,
but
it's
just
like
a
lot
of
information,
I
don't
know
joshua.
I
know
you
haven't
seen
what
what
we're
talking
about
concretely
yet,
but
obviously
that'd,
be
interesting.
C
D
D
A
lot
of
times
that,
when
we're
dealing
with
such
large
issues,
having
an
oh
chap,
just
to
like
put
some
text
in
that
you
can
point
to
the
next
one
is
pretty
helpful.
I
would
say
in
the
in
the
vein
of
kotep
170.
I
think
it
was
which
took
for
168
170.,
just
more
material
to
help
if
someone
comes
in
kind
of
cold
and
wants
to
get
a
lay
of
the
land
that
those
would
probably
help
them
in
this
too
yeah.
D
Yeah
I
get
it.
I
think
how
about,
if
I
take
a
review
promise
to
review
this
in
the
next
few
days
a
week
or
so
and
figure
out
what
I
would
recommend.
So
I
keep
without
looking
closely.
I
don't
I
don't
see
a
problem
like
having
this
sort
of
appendix
giant
appendix
you
know.
One
thing
is
you
could
just
attach
it
to
one
of
the
existing
oteps
that
says
and
here's
more
information
you
know
just
like
that's
one
way
we
could
go
I'll.
Take
a
look
sure.
Thank
you.
C
E
B
C
C
I
think
I
might
be
interested
in
like
changing
this,
like
just
recasting
it
from
being
like
a
score
to
just
like
honestly
what
it
is
in
simpler
terms
and
more
familiar
terms
is
like
a
sort
of
continuous
estimation
of
the,
like.
You
know,
incoming
rate
of
spams
of
that
kind,
and
that
is
a
little
bit
ambiguous,
but
how,
where
that
sort
of
abstraction
was
derived
from
was
there
are
a
couple
systems
today
that
you
know
attempt
to
do
like
not
unlike
what
you
programmed
in
java
a
little
while
back.
C
B
C
I
think,
maybe
at
this
point
I've
like
shared
enough
of
like
the
sort
of
contextual
information
that
had
been
only
in
my
head,
such
that
I
think
I
can
probably
move
forward
now
on,
like
sharing
the
actual
like
early
starting
discussion
of
like
an
actual
concrete,
like
design
conversation
of
our
answer
to
the
like
sampler
configuration
problem.
Knowing
what
you
know
we
would
minimally
need
to
support
or
like
what
our
would-be
customers
are
like
accustomed
to
doing
for
these
other
systems.
C
C
A
C
It's
actually
not
obvious
to
me
is
that
life
closely
related
to
the
problem
of
like,
like
you
said,
we
must
not
require
that
all
choices
are
complete
and
does
that
relate
to
like
when
I
read
that
sentence,
I
thought
of
you
know
imagining
if
I
had
some
kind
of
like
very
high
volume
system,
like
perhaps
there's
like
diminishing
and
like
no
business
value
after
a
certain
point
of
like
collecting
this
information.
Is
that
kind
of
what
you
had
in
mind
with
like
not
requiring
that
all
traces
are
complete.
C
C
These
are
sort
of
things
that
I
would
have
in
my
head
as
a
as
like
desirable
things.
So
in
this
context,
I'm
not
attempting
to
state
you
know:
capabilities
of
the
like
underlying
technology,
so
much
as
like
you
know,
from
a
from
a
customer
or
like
a
user's
perspective,
like
features
that
are
are
valuable.
C
C
A
A
C
A
A
A
A
C
Is
like
yeah,
and
I
get
why
like
in
practice
like,
I
totally
like,
not
follow
your
reasoning
that,
like
in
practice,
you
really
want
partial
traces
to
ensure
that
you
know
you
get
these
like
low
low
volume
but
important
sub
pieces.
I
think
I
could
just
as
well
say
like
I
could
read
this
one
and
say
collect
as
little
data
as
possible.
Are
you
kidding
me?
C
A
C
C
C
Are
you
following
that?
Like
I'm
not
saying
like
you
know,
we
should
never.
We
should
like
forsake.
You
know
like
caring
about
people
who,
like
there,
there
will
be
some
people
for
whom
they'll
be
something
like
they
can't.
You
know,
run
all
the
collectors
necessary
or
whatever
they're
like
they
don't
have
enough
memory
to
like
buffer
things
for
tail
sampling.
C
A
Well,
it
ties
a
little
bit
to
my
other
comments
which,
which
we
we
haven't
discussed.
Yet
this
is
about
the
limits
of
of
systems.
Technological
limits
use
singled
out
storage
limits
as
valid
ones,
but
I
wanted
to
indicate
that
there
are
some
other
limits
well,
first
of
all,
in
the
tracer
right,
so
the
tracer,
quite
often
especially
with
high
volume,
cannot
really
afford
to
have
100
sampling
because
it
is
memory
it
consumes
memory,
cpu
and
network,
and
produces
not
only
overhead
but
also
can
cause
crashes
and
especially
in
spikes.
A
So
when
the
traffic
spikes
and
the
system
crashes
because
of
the
tracer
of
being
overloaded,
so
so
in
general,
I
believe
that
any
practical
application
of
open,
telemetry
with
respect
to
sampling
will
use
both
head-based
sampling
and
tail-based
sampling
because
they
serve
two
different
purposes
in
general.
Head-Based
sampling,
in
my
opinion,
is
necessary
to
protect
the
application
from
being
overloaded,
so
we
collect
as
much
data
as
we
can,
but
not
more
than
that
and
it
can
it.
It
should
be
less
sensitive
to
context
because
the
context
is
very
often
unknown.
A
Yeah
and
tail-based
sampling
is
the
more
intelligent
sampling
where
you
really
care
about
configuration
much
more
and
you
you
have
some
freedom
to
choose,
and
these
two
two
sampling
types
needs
to
be
balanced
it.
We
cannot
say
that
one
is
more
important
than
the
other,
because
they
both
are
very
important.
C
That
is
my
presumption
and,
if
that
were
true,
then,
like
I
think
my
like
sentiment
behind
the
statement
here
was
like
assuming
they
won't
be
sort
of
worked
on
simultaneously
and
like
delivered
simultaneously
that
just
like,
as
a
matter
of
sequencing.
The
two
I
had
like
a
weekly
held
opinion
that
tail
sampling
would
be
more
valuable
to
deliver
to
people
earlier,
but
I'm
curious
if
how
how
you
two
feel
about
that
presumption?
If
maybe
it's
not
even
true,
maybe
yeah.
A
A
So
from
that
perspective,
it's
definitely
okay.
If
we
were
to
construct
the
overall
sampling
architecture.
I
I
think
this.
This
would
be
a
problem
and
on
on
the
other,
slightly
other
topic,
you
know
in
some
other
place,
you
were
right.
Foolish
indicated
that
sampling
management
should
be
kind
of
automatic
as
much
as
possible
without
manual
interventions.
A
C
C
Do
you
think
peter?
Is
it
possible
that
you
you
mentioned?
You
know
resource
costs
of
like
within
my
own
infrastructure,
of
of
collection
as
like
a
sort
of
counterpart
to
like
downstream
systems
that
I
am
not
quite
the
owner
of
those
things
have
limits
too,
but
like
the
infrastructure
that
I
own
has
limits
too.
I
think
I
intended
these
concerns
to
be
sort
of
in
scope
of
this.
First.
Yes,.
C
Yeah,
okay,
I
think
I
might
move
like
this
nested
point
like
t
like
your
with
your
suggestion,
like
broaden
this
thing
and
then
kind
of
move
this
point
into
that
one
now
that
number
two
is
broader
to
include
both
systems
that
are
not
in
my
lake
direct
control
as
it
is
currently
and
with
your
feedback
systems
that,
like
are
in
my
purview
yeah.
That
makes
that's
that's
a
better
way
to
collect
these
ideas.
Thank
you
I'll.
Do
that.
C
C
D
D
D
C
D
What
they
meant
was
they
have
a
contract
for
so
many
spams
per
month.
I
guess
I
mean
I'm,
I
think
I'm
ex
I'm
some
other
placeholder,
but
and
and
and
what
we're
dealing
with
is
is
customer
has
too
many
spans.
They
would
like
to
bring
it
down
to
to
meet
our
quota,
and
but
it's
we're
talking
about
not
much
sampling
to
get
there.
We're
talking
about
one
two,
one
and
three
one
and
four
one
and
five
and
that's
about
it,
and
the
problem
is
that
I
can
only
do
one
and
two.
D
I
can
do
one
and
four,
but
I
can't
do
one
three
one
and
four
one
like
so
so
this
issue
had
just
sort
of
stuck
there
for
a
long
time
doing
nothing,
and
then
it
came
up
again,
so
I'm
kind
of
bringing
it
up
here.
For
the
same
reason,
the
people
who
are
bringing
this
up
come
from
the
go
sig.
They
were
pretty
unaware
of
the
work
on
probability,
sampling,
daniel
dalai
works
at
dynatrace
with
atmar
and
has
been
representing,
I
think,
kalyana.
You
know
him
from
the
w3c
group.
D
He
he
brought
the
context
back
from
the
w3c
group
to
us,
and
so
I
was
asking
questions
well,
I
I
believe
our
plan
of
action
here
was,
we
will
add
this
randomized
bit
to
the
future
trace
context
version.
If
you
have
random
bits
now,
all
of
those
caveats
about
the
powers
of
two
sampling
may
fall
away.
D
I'm
saying
may
because
I'm
asking
for
sort
of
a
design
here
and
what
I'm,
what
I'm
aware
of
is
that
we've
discussed
in
this
group
suppose
I
want
75
sampling
once
we
have
like
lots
of
random
bits
available
which
is
sort
of
a
an
assumption,
I'm
using
because
that's
the
way
the
w3c
group
went
so
suppose.
I
have
56
bits
of
random
randomness.
D
D
If
we
set
that
threshold
to
three
out
of
four
you,
you
will
get
three
out
of
four
sampling
here
and
if
we
specify
exactly
how
to
turn
56
random
bits
into
a
number,
then
we
can
portably
consistently
make
that
decision
across
all
the
the
clients
so
what's
being
asked
for
is
for
us
to
finish
specifying
an
algorithm
that
would
calculate
probability
sampling
from
those
bits
now.
I
think
this
opens
the
door
for
us
to
kind
of
finish
our
work
in
the.
D
I
feel
that
I'm
I
haven't
been
to
this
meeting
for
a
few
months
now
and
I'm
feeling
a
little
rusty.
But
let
me
try
and
explain
what
I'm
saying
the
once
we
have
randomness
in
the
trace
id
now
we
don't
need
an
r
variable
anymore,
and
the
question
comes:
what's
your
p
variable
and
the
p
variable
with
spec
for
powers
of
two
we've
talked
about?
Having
other
variables
that
would
convey
other
probabilities
still
consistently
and
the
the
two
that
come
to
mind.
D
I
can
imagine
two
other
ways
to
express
sampling
and
I
think
there's
only
two
that
I
can
think
of
one
is
to
express
the
threshold
or
the
the
what's
being
called
upper
bound
here
as
a
as
56
bits.
In
other
words,
you've
got
56
bits
of
randomness.
I've
got
56
bits
of
probability
and
we
can
follow
the
rules.
In
other
words,
if
we
specify
how
to
compute
how
how
do
we
convey
a
sampling
threshold?
D
Now
we
have
56
bits
of
sampling
probability
available
and
it's
straightforward
to
do
it.
That
way,
however,
is
is
a
number
that
humans
cannot
read
and
use
very
easily,
because
75
turns
into
a
56-bit
fraction
representing
the
number
0.75,
and
I
can't
read
that,
and
I
don't
think
anyone
can
read
that.
However,
what
we
do
know
is
that
commonly
people
want
to
say
I'm
going
to
do
one
in
seven
sampling
and
the
number
seven
is
the
user
visible
number
that
actually
means
something,
not
one
over
seven.
D
If
we
were
to
convey
adjusted
count
with
a
consistent
probability,
sampling
scheme,
it's
either
going
to
be
a
threshold
or
an
adjusted
count.
I
think
those
are
the
two
options
and
I
prefer
the
adjusted
count,
which
is
the
inverse
of
the
sampling
threshold,
but
I
believe
this
issue
here
in
front
of
us
is
asking
us
to
specify
how
to
calculate.
D
A
threshold
consistently
across
hotel
sdks
so
that
we
can
both
count
adjusted
counts
and
have
non
powers
of
two
sampling.
That's
what
I'm
asking
for
I
finished
saying
it.
I
don't
think
I
said
it
very
well.
We've
talked
about
a
c
variable,
which
is
the
one
that's
most
natural
to
me.
So
if
I
say
c
equals
15.
That
means
I'm
probability
sampling
at
one
in
15
and
I
and
I
fell
under
the
threshold
according
to
the
randomness.
D
That's
kind
of
what
I'm
after
I
think
c
is
the
one
that
will
be
used
or
understandable,
although
it
means
inverting
something
and
there's
loss
of
precision
like
you
know,
fractions
are
hard
anyway.
That's
all
I
had
to
say
I'm
hoping
that
this
group
has
some
context
on
that
and
has
some
ideas
about
what
to
do.
D
D
D
And
just
to
just
to
follow
this
to
the
end,
it's
basically
pretty
fresh.
I
I
don't.
I
think
that
this
is
calling
for
something
to
be
done
and
I
don't
think
anyone's
going
to
do
it
unless
we
do
it
here,
and
I
think
I'm
just.
I
think
I
think
it
might
happen
very
slowly,
but
it
will
happen
probably
and-
and
it's
probably
we're
the
ones
who
could
make
recommendations
about
c
versus
whether
thresholds
are
easier
but
unreadable.
D
D
C
C
D
I
think,
through
the
thought,
experiment
at
the
time
was:
how
would
I
modify
the
collector's
current
probability
sampling
plug-in
to
do
this,
and
I
I
I
think,
you're
right.
We
don't
necessarily
need
for
or
it's
not
a
must,
and
it's
not
necessarily
required
that
the
humans
can
read
it.
It's
maybe
just
nice
to
have
or
it
it
makes
people
comfortable
to
like
have
a
thing
there
that
they
can
understand.
If
they
see
it.
B
D
D
Okay,
I,
I
think,
that's
the
kind
of
feedback
I
was
looking
for,
despite
the
fact
that
humans
can
read
c
values
that
that
is
as
messy
and
tricky
because
of
precision
issues,
and
maybe
I
haven't
thought
about
it,
but
like
I
think
I
could
read
a
binary
fraction
at
some
level.
Just
because
I
got
well.
I
think
I
can
read
binary
fractions
pretty
well,
but
only
from
working
on
exponential
histograms.
So
maybe.
B
D
D
Yeah,
I
feel
like
that
can
be
a
recommendation
that
is
sort
of
like.
If
your
vendor
doesn't
accept
fractional
accounts,
then
you
should
not
use
anything
other
than
an
integer
reciprocal
or
something
like
that.
But
I
know
that
that's
that's
a
debate
that
is,
I'm
not
the
first
person
to
enter
this
debate
like
lightstep
added
support
for
fractional
counts
and
its
histograms
recently,
but
it
is
I've
seen
a
lot
of
argument
over
that
feature.
D
D
C
You
said
something
which
was
like,
I
think,
referring
to
like
a
conversation
you
had
nine
months
ago.
You
said
you
know
you
can
like
do
this
probabilistic,
like
selection
of
a
power
of
two
that'll
like
over
many
trials
net
out
to
average,
and
they
were
whoever
you
were
speaking
with
they're
suggesting
to
is
unsatisfied
with
that,
and
I
wonder,
do
you
recall
was-
was
the
reason
for
their
for
their
unsatisfaction
that,
like
that,
was
more
code
for
them
to
write
or
like?
Was
it
something
deeper
than
that.
D
I
think
it
was
not
deeper
than
that.
I
think
it
was
more
of
a
like.
I
just
have
this
thing:
I've
always
done,
which
is
one
seven
sampling,
and
why
can't?
I
still
do
that
and
we
were
like
well,
you
could
flip
the
coins
and
like
one
one
and
seven
is
halfway
between
one
and
eight
and
one
and
four
like
you
know,
like
that's
the
kind
of
logic
which
is
just
like
nah,
I
don't
need
that.
I
just
want
one
seven
or
whatever.
C
So
what
do
you
think
then?
So
how
has
this
notion
of
this?
This
technique
been
floated
in
the
in
the
github
thread,
because
I
wonder
like,
and
the
reason
for
my
question
was
like
if
it
were
like
an
implementation
detail
that,
like
was
part
of
the
the
interface
to
trace
id
ratio.
Sampler
and
like
it
wasn't
extra
code
for
users
to
write
like.
Would
it
be
fine.
D
D
D
I
think
the
probably
the
best
outcome
would
be
trace.
Id
ratio,
sampler
gets
updated
to
say
to
be
consistent
with
the
probability
sampling
propagation
that
we've
done,
which
means
specifying
how
to
make
a
big
endian,
integer
or
whatever,
and
like
turn
the
trace
id
into
a
number
so
that
you
can
threshold
it
and
that
it'll
come
with
caveats
saying
something
like
if
you
are
configuring
a
sampling
probability
that
is
not
an
integer
reciprocal,
so
the
recipient
may
have
trouble
counting
it
exactly.
I
think,
is
kind
of
where
we
would
end
up.
D
Yeah,
maybe
that's
I'm
sure,
someone
with
a
perfectionist
will
come
in
and
say,
but
I
don't
know
how
to
express
one
and
seven
exactly
because
it's
there's
no
exact
floating
point
number
that
equals
one
and
seven
or
whatever.
And
I
hope
that
that
is
like
there's
a
rounding
question
or
something
like
that.
But.
D
C
E
E
D
But
I'm
I'm
not
enthusiastic
about
that
really
anymore.
It
just
seems
like
picking
fights
where
they
don't
belong,
so
the
the
rollout,
then,
would
be
something
like
hotel
fixes
its
trace
id
ratio
based
sample
problem
problem
so
that
it's
consistent
without
probability,
counting
or
without
propagating
probability
and
independently.
D
We've
specced
out
how
to
do
the
same
sampling
with
probability,
propagation
using
p
variables,
or
maybe
a
new
variable
for
threshold.
I
think
a
new
variable
for
threshold
will
help
sell
it,
but
it
shouldn't
be
necessary
and
then
vendors
have
to
support
it
and
I'm
going
to
be
honest.
Flight
step
never
went
and
implemented
the
trace
date
thing
and
partly
because
I
think
they
were
expecting
me
to
do
it,
but
I
was
expecting
them
to
do
it
and
no
one
did
it.
So
that's
just
honesty.
D
We're
kind
of
I
think
part
of
the
reason
is
that
we
just
having
a
consistent
probability.
Sampler
is
like
a
leaf
in
in
that.
If
else
branch
that
spencer
showed
us
earlier
and
people
need
the
fels
branch
too,
and
unless
they
have
the
fels
branch,
they
don't
have
useful
sampling
from
from
what
we've
done
so
far,
I
think.
E
Okay,
I
I
got
most
of
it.
I
think
the
last
part
I
missed
is
it's
up
to
the
different
sdk
owners
and
maintenance
to
go
build
support
for
that
consistent
probability,
sampler.
That
proposal
that
you
already
put
together
right.
I
know,
for
example,
there
is
a
java
one
that
I
think
omar
and
trust.
Yeah
just
did
something,
and
then
I
know,
and.
D
Sharp
is,
and
I
wrote,
the
I
wrote
one
and
go
and-
and
I
I
mean
like
that
is
available
to
the
extent
that
someone
could
try
to
use
it.
It's
still
marked
experimental,
I
feel
like
we
need
to
see
users
carrying
before
we
pull
it
out
of
experimental
and
I've.
I
think
my
my
guess
is
that
the
perceived
cost
of
propagating
our
values
was
very
high
and
that
may
have
led
us
to
kind
of
like
pause.
D
While
we
waited
for
a
w3c
to
add
that
random
to
add
that
randomness
bit,
because
otherwise
you're
adding
cost
to
an
unsampled
trace
context,
which
is
a
little
bit
offensive
to
people
it's
only
when
we're
sampling.
Now,
if
you
have
randomness
bit,
you
only
need
to
add
cost
to
a
sample
trace,
which
is
much
better.