►
From YouTube: 2021-08-26 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
B
C
This
hi
everyone.
I
think
we
could
start
in
a
minute.
C
I
started
writing
up
an
agenda
from
things
that
have
been
discussed
in
the
past
week.
That
would
take
another
minute
and
if
you
have.
A
C
D
E
I
can
hear
you
yuri
okay,
okay,
yeah
yeah,
so
when,
in
the
very
first
meetings
we
we
had
the
discussion
about
unblocking
jaeger's
decay,
migration
to
open
telemetry.
So
this
was
one
of
the
goals,
but
we,
I
don't
think
we've
made
a
lot
of
progress
on
that
and
instead,
we've
been
doing
like
a
lot
of
other
work.
So
that's
why
this
is
kind
of
the.
Why
I'm
asking
like?
Should
we
should
we
set
the
goals
clearly
and
try
to
sort
of
track
progress
along
those
goals.
A
Yeah
that'd
be
great,
I
mean
I
feel
like
we
need
jaeger
people
to
come
to
the
meeting,
though,
and
we
had
a
couple
people
at
the
beginning,
but
they
they
dropped
off.
C
But
yeah
I've
come
to
the
sig
with
a
goal
to
deliver
my
employer,
what
they've
asked
for,
which
is
ways
to
count
probability
sample
spans
and
the
other
big
topic
that
has
been
open
and
I'm
I'm
here
to
discuss
if
people
want,
but
I
don't
feel
like
charging
forward
myself
with.
Is
this
remotely
configured
sampling
topic
or
the
like
sampling
policy
configuration?
C
A
I
think
we
did
decide,
though
yuri
was
that
it
was
totally
fine
for
the
jaeger
to
to
include
a
jaeger
plug-in
that
handled
a
jaeger
sampling
plug-in
that
handled
all
of
yeager's
current
behavior.
A
We
didn't
want
to
automatically
make
that
the
like
a
default
part
of
open
telemetry,
because
it
seems
like
there's
a
number
of
remote
configuration
opportunities
for
open,
telemetry
beyond
just
sampling,
so
we
didn't
want
to
to
stick
in
one
that
was
sampling
specific,
but
we
didn't
want
to
block
jaeger
from
including
a
plug-in
in
open
telemetry
that
did
everything
they
needed
to
do.
A
I
think
the
only
request
was
to
ensure
that
when
it
goes
into
the
spec,
it
just
be
like
specked
out
what
what
that
should
actually
do
or
or
point
to
a
spec
somewhere
rather
than
just
say,
like
include
jaeger,
remote
sampling,
or
something
like
that.
A
Okay,
yeah.
But-
but
I
admit
I
I
haven't
been
tracking
the
the
the
issues
for
getting
that
that
approved.
I
don't
know
if
that's
been
been
hung
up
or
not.
C
Well,
no
one
has
come
back
to
this
group
and
discussed
sampling
configuration
as
a
topic,
and
I'm
I'm
always
open
to
it
here,
and
I've
pointed
out
how
metrics
has
gotten
into
the
weeds
and
maybe
sidetracked,
talking
about
view
configuration.
C
But
I
know
now
that
we
have
jaeger
and
and
the
aws
x-ray
team,
both
asking
for
sampling
configuration
remotely
seems
like
we
could
move
forward
in
a
in
a
like
a
standard
type
way
talking
about
it.
I
think
that
would
be
a
nice
item,
for
I
don't
know
who
should
lead,
because
there's
sort
of
two
systems
out
there.
A
One
thing
we
shouldn't
I
just
I
felt
like
the
decision
was
like
us
figuring
this
out
for
open
telemetry
in
general,
shouldn't
shouldn't
be
a
blocker
for
including
a
jaeger
plug-in
that
worked
with
the
existing
like
jager
back-end,
like
it's
totally
fine
for
the
jaeger
sampling
plug-in
to
come
with
a
little
control
plane
if
that
gets
jager
unblocked,
rather
than
waiting
for
like
open
telemetry
to
figure
out
what
it
wants
and
then
jager
adopting
that
in
the
back
end,
but
I
do
think
we
should
figure
it
out.
I
think
josh.
A
You
have
a
good
point
of
like
what
what
sig
should
we
be
talking
about
this
in?
I
think
there's
just,
and
I
think
we
could
divide
that
into
two
parts.
One
is
the
configuration
language
that
we
want
for
various
things,
as
you've
mentioned,
there's
an
issue
around
targeting
that
that
comes
up
in
a
couple
of
different
scenarios.
A
One
that
I
wanted
to
bring
up
here
that
was
coming
from
the
instrumentation
group
is
instrumentation.
Suppression
is
the
thing
people
are
currently
doing
through
sampling
like
we're,
trying
to
figure
out
what
kind
of
configuration
does
instrumentation
need
to
offer
like
when
you
install
a
piece
of
instrumentation
where
you're
not
writing
it,
but
you're,
just
installing
it
like
the
stuff.
We
offer
like
what
kind
of
configuration
options
it
should
offer
and
one
of
the
most
common
thing
people
ask
for
are
suppressing,
like
I
don't
I
want
to.
A
I
don't
want
this
health
check,
for
example,
but
it
started
to
feel
like
that
was
if,
and
that
seemed
to
be
the
the
biggest
piece
of
configuration
that
people
wanted,
but
it
didn't
necessarily
seem
like
we
wanted
every
piece
of
instrumentation
to
implement
some
fancy
targeting
system
for
turning
things
on
and
off.
It
seemed
more
like
a
thing
we're
doing
currently
through
sampling,
plug-ins
and
today,
people
do
that
today
they
use
the
the
sampler
as
their
place
for
force
suppressing
pieces
of
information.
A
Right
place
long
term,
but
the
point
is,
it
seems
like
we
need
a
language
for
allowing
people
to
target
pieces
of
instrumentation
and
just
how
how
complicated
that
should
be.
So
I
wanted
to
bring
that
up
here
and
I
know
josh.
This
is
similar
to
the
the
what's
going
on
in
metrics,
which
is
this
targeting.
You
need
a
targeting
language
for
being
able
to
say
when
you
see
this
pattern,
I
want
to
yeah.
C
C
Probably
you
know,
trace
id
and
parent,
then
we'll
get
the
information
that
we
want
and
we'll
close
the
to
do
in
the
spec,
which
is
like
another
item
that
we
we
can
sort
of
check
off.
So
in
that
factorization,
this
group
just
talks
about
probability
and
propagation
and
span
data
and
another.
Another
larger
group
could
talk
about
views,
but
I
don't
have
it
doesn't
have
to
be
that
way.
We
can
talk
about
that
here.
I'm
just
trying
to
say
there
is
a
separation.
I
think
sure
I.
A
Think
we
need
to
talk
about
it
somewhere,
but
yuri.
I
wanted
to
tie
that
back
in
real,
quick
with
jaeger,
because
I
think,
besides
having
like
a
remote
control
plane,
the
the
two
things
that
jager
has
I
understand
around
sampling
are
that
are
controllable.
One
is
probabilistic
sampling.
We
have
those
specs
going
in
and
the
other
was
like
a
floor
right.
The
ability
to
define
some
kind
of
floor.
A
To
ensure
that,
like
a
minimal
number
of
spans
show
up-
and
I
wasn't
sure
if
that
thing
had
some
kind
of
targeting
language
or
if
that
was
like
just
generic
like
just
a
generic
value,
you
said
of
some
kind.
E
It's
a
very
bespoke
schema,
which
is
sort
of
tightly
coupled
to
this
exact
sampling
techniques
like
probabilistic
versus
like
a
floor,
is
explicitly
a
rate
limiting
setting.
A
Okay,
so
do
you
think
this
is
rate
limiting
should
be
like
actually
tied
into
the
sampling
algorithms
that
were
we're
proposing
you're
saying
it's?
Not
it's
not
a
separate
a
separate
sampling
system.
It's
tied
in
with
it
should
be
part
like.
If
we're
going
to
include
this,
it
should
be
included
as
part
of
each
type
of
sampling
algorithm
that
we're
we're
adding
to
open
telemetry.
E
You
probably
I
mean
the
way
this
is
done.
Is
it's
sort
of
it's
a
composite
sampler
in
jager,
because
it
it
also
so
it
kind
of
orchestrates
a
whole
bunch
of
different
samplers,
depending
on
which
end
point
you
are
using
right
and
and
so
for
each
endpoint.
You,
you
get
your
own
probabilistic
sampler
and
the
the
the
lower
bounds.
Probably
like
I.
I
don't
remember
whether
it's
parent
point
or
global,
it
might
be
parent
point
as
well.
E
A
C
Well,
yeah,
so
I've
I've
been
trying
to
hold
off
on
any
non-probabilistic
samplers
being
tied
into
the
spec
because
it
gives
us.
The
problem
that
you
just
described
is
that
you
get
this
span
that
I
can't
count
now
by
the
spec.
Essentially,
and
so
I
I'm
we've,
we've
got
ideas
out
there
and
prototypes,
showing
like
ways
that
you
can
probabilistic
leave
rate
limit,
and
I
I
also
would
like
to
keep
that
conversation
a
little
bit
separate.
C
I
can
accept
a
probability,
a
non-probabilistic
rate
limiter
and
there's
a
there's,
a
data
way
to
encoding
for
that
in
the
data
format
that
we've
proposed,
which
say
give
me
an
unknown
adjustment
count
if
you're
going
to
do
that
because
it
is
unknown.
So
so
if
we
have
to
have
that,
we
can
and
lightstep
will
say,
don't
do
that
because
we
can't
count
them.
C
But
that
is
a
separate
topic.
The
rate
limited
question
and-
and
we've
got
several
pieces
of
like
prototype
and
discussion
there,
but
I
think
that's
just
keeps
that
separate
as
well
for
the
benefit
of
everyone.
C
E
Well,
george,
to
to
clarify
the
rate
limiting
it's
it's,
it
works
in
opposite
direction
right.
It
guarantees
the
minimum
amount
of
traces
collected
rather
than
limiting
the
on
on
upper
bound
and
the
so
the
fact
that
it
would
say
unknown,
sampling
count.
That
is
perfectly
fine,
because
the
only
purpose
of
that
lower
bound
sampler
was
to
make
sure
that
the
adaptive
back
end
is
aware
of
different
endpoints,
because
otherwise
you
never
sample
them
with
default
rates.
C
Yeah,
I
I
understand
I
and
I
think
no
objections
to
to
this
either
so.
C
C
C
So
I
hope
that
maybe
helps
I
I'll
stop
saying
no,
no
rate
limiting
if
we
can,
if
we
could
just
move
forward
with
the
basics
that
we
have
start
talking
about
composite
samplers
start
talking
about
finishing
the
two
oteps
and
stuff
and
then
there's
this
topic
of
rate
limiting
and
it's
pretty
deep
and
we
can
and
it's
different
when
you're
doing
it
at
the
head
and
different
when
you're
doing
it
at
the
tail.
For
example,.
C
I
hope
we've
kind
of
skirted
around
the
original
topic
in
the
agenda,
which
is
yuri's
question
here,
and
I
I
don't
know
what
the
action
item
should
be
like
how
do
like.
Maybe
the
next
meeting
of
the
this
or
maybe
the
end
of
this
meeting
can
be
entirely
about
how
to
get
composite
sampling.
C
E
C
I
I
don't
have
a
prior
art
for
sampling.
I
mean
to
me
this
reminds
me
of
the
area
of
mail.
Filtering
like
this
has
been
a
25-year.
You
know
expert.
This
is
there.
There
are
groups
who
expert
who
specialize
in
this
and
they've
been
writing
mail
filtering
logic,
so
I
can't
even
remember
their
names
all
those
mail
programs
that
you
have
like
dot
files
in
your
home
directory,
for
that
gives
you
a
bunch
of
filters
and
there's
always
a
rule
that
says:
do
you
stop
here
or
do
you
keep
evaluating?
C
You
know
like
like
that
is
to
me
there
are
prior
there's
prior
art
in
other
fields
and
I've.
I
keep
saying
when
we
talk
about
this
in
views
or
in
metrics
like
this
is
not
a
telemetry
project,
this
non-observability
project.
This
is
purely
complicated
configuration
project
which
which
bothers
me,
because
it's
not
my
area
either.
B
A
Okay,
so
does
this
list
in
the
agenda
look
correct
here.
A
To
the
list,
this
goals
so
on
our
agenda,
we've
got
unblocking
jaeger's,
sdk,
probabilistic
sampling
span,
counting
mechanisms,
remote
configuration
language.
A
C
C
E
Maybe
so
I
the
spec
is:
is
changes
merged
just
to
say
that
there
is
this
remote
jaeger
remote
as
a
as
a
key
for
the
sampler
and
then
I
know
pavel
was
working
on
a
java
circle
that
java
already
had
the
implementation,
but
it
wasn't
wired
into
the
sdk
by
default,
and
so
he
was
working
on
that.
I
don't
know
if
that
pr
was
merged
or
not.
E
Okay,
so
like
once
that's
like
this
is
kind
of
would
be
a
very
good
milestone,
because
I
think
once
the
java
supports
the
jaeger
remote
sampler,
that
is
completely
sufficient
to
decommission
at
least
java
sdk
and
jaeger,
because
they're,
like
other
sdks,
have
more
complex.
Samplers
like
this
composite
samplers
exists
in
well,
not
composite,
but
sort
of
there's
more
advanced
samplers,
basically,
which
are
based
on
tags
of
the
spans
like
in
the
go
and
node.js.
E
But
yeah
java
is
pretty
simple
and
python
is
also
pretty
simple
so
like.
If
we
support
python,
then
this
is
two
down
and
that's
a
large
maintenance.
A
C
Josh
go
for
it
sure,
so
I
just
quickly.
I
think
it
might
benefit
from
discussion.
I'm
going
to
pull
up
the
20ps,
and
I
have
one
here
this.
This
otep
168
hasn't
received
any
recent
comments,
which
is
why
I'm
not
going
to
talk
about
it,
but
the
it
does
have
the
answer
to
one
of
the
questions
on
the
170..
So
that's
why
I'm
bringing
it
up?
I
haven't
read
this
comment
yet
a
lot
more,
but
I'm
referring
to
these
these
points
of
feedback
from
yesterday.
C
I
just
the
one
so
first
comment
here
is
about:
what
can
we
take
action
on
based
on
this
otep?
Well,
the
one
I
had
envisioned
is.
We
could
actually
extend
the
proto
and
release
a
new
protocol,
and
then
users
who
are
not
using
otel
sdks
but
are
trying
to
send
to
an
otlp
receiver,
could
begin
writing
their
own
implementation
of
this.
C
So
it's
it's
a
definitely
not
a
big
use
case,
but
there
are
customers
that
we
know
who
are
sending
otlp,
who
are
not
using
hotel,
sdks
and
who
are
asking
for
sampling.
So
there's
a
little
bit
we
can
do
there
and,
however
168
does
try
and
give
those
descriptions
that
were
asked
for.
So
I'm
going
to
pull
that
up.
C
Behavior
of
the
trace
id
based
ratio
ratio
ratio-
sampler
is
it
gets
a
configuration
which
is
a
power
of
two
this.
If
it's
new
root
it
does
this
behavior.
If
it's
not,
does
that
behavior,
it
will
always.
It
will
set
the
sample
bit
when
s
is
less
than
r
less
than
equal
r.
So
that's
the
spec
for
that
now
I
haven't
written
the
spec
language
to
update
the
sample
respect,
but
it's
sort
of
implied
by
this
anyway.
C
E
Well,
josh,
I
think
what
what
I
meant
was
yeah,
that
that
is
fine.
What
I
meant
was
that,
without
the
changes
to
the
sampler
api,
there's
right
now,
no
way
to
actually
return
that
adjusted
count
to
the
tracer,
so
it
can
record
it
on
a
span.
C
C
We
can't
directly
do
this
and
I
see
your
point:
okay,
so
some
kind
of
spec
change
for
the
sampler
spi.
If
you
will
saying
you
have
to
return
an
integer,
which
is
the
spec
value
for
this
field,
in
addition
to
all
the
other
things
that
you're
returning,
I
think
would
probably
take
care
of
it.
C
Yeah,
I
don't
think
anyone's
gonna
really
like
that.
Okay,
that
was
thank
you
for
clarifying.
I
I
would
I'm
trying
to
limit
the
revisions
to
the
oteps
they're
standing.
So
if
you
wouldn't
mind
me
writing
a
new
ot
with
just
new
text,
maybe
that
would
help.
I
would
take
that
up
after
this
meeting
before
the
next
one
and
then
the
last
thing
that
I
thought
was
worth
discussing
in
the
group
here
is
this
question
about
zero
versus
unknown?
I
wanted
to
call
out
a
few
examples
and
then
I
could.
C
I
could
spend
more
time
in
the
coming
week
on
that.
On
that
too,
we
talked
about
how
the
parent
sampler
is
the
one
that
really
is
being
addressed
with
this
propagation
of
head's
probability.
So
if
you
don't
know
head
probability,
then
unknown
is
the
right
answer.
Also,
this
covers
all
the
legacy
spans
that
won't
have
a
value
for
that
field,
so
unknown
can
mean
I've.
I'm
legacy
before
the
spec
was
written
unknown
can
also
mean
I
was
a
parent
sampler.
C
C
I
see
an
unknown,
I'm
going
to
tell
the
user
that
they're
doing
something.
That's
misconfigured.
I
cannot
count
these
spans.
I
have
an
unknown
count.
That's
one
way
we
could
handle
it.
The
other
way
we
could
handle
it
is
perform
trace
assembly
find
that
root
span.
Hopefully
it's
got
an
adjusted
count
and
then
assume
that
my
adjust
account
is
the
same
as
my
root
span.
C
So
that's
another
option
that
we
have
is
go
find
that
route
and
see
if
it
has
an
adjusted
account
and
we're
not
giving
the
the
consumer
a
way
to
know
whether
unknown
means
legacy
with
with
with
completely
unknown
like
the
root,
doesn't
even
know
its
own
adjusted
count
versus
I'm
a
I'm
a
child,
and
I
need
to
find
my
root
so
that's
up
in
the
air
and
then
the
cases
where
we
might
want
a
route
to
encode
an
unknown
probability.
C
Those
are
a
little
bit
more
esoteric,
but
I
could
certainly
walk
through
right
now,
just
quickly
in
cases
where
you're
doing
something
like
a
reservoir
sample
and
you
have
a
fixed
window
of
time.
So
it's
let's
say
it's
one
minute
over
one
minute:
I'm
gonna,
I'm
gonna
sample
100
spans,
that's
a
reservoir,
so
if
I
have
less
than
100
spans
in
that
minute,
they
all
pass
through.
They
all
have
an
adjusted
count
of
one
and
I
had
to
sample
all
of
them.
C
At
the
end
of
my
minute,
some
of
my
spans
will
have
been
in
the
reservoir
for
a
while
and
then
kicked
out
of
the
reservoir
because
more
spans
happen
than
100.
the
spans
that
are
kicked
out
of
my
reservoir.
Before
the
end
of
the
minute,
they
can
be
recorded
with
an
adjusted
count
of
zero.
You
know
their
adjusted
count
was
zero
because
they
got
sampled
out
and
yet
you
started
sampling
them.
You,
their
children,
are
recorded,
maybe
you'd
like
to
have
a
complete
trace
in
this
scheme.
C
C
This
is
the
type
of
thing
that
one
could
do
it's
more
applicable
in
a
tail
sampler
than
in
a
head.
Sampler,
it's,
but
in
any
case
reservoir
sampling
is
basically
you
have
a
variable
probability
until
the
very
end
of
your
window
and
that's
why
you
end
up
with
some
zeros.
So
I
just
wanted
to
encode
to
permit
a
user
to
encode
a
zero
versus
an
unknown.
The
other
case
where
you
get
that
is,
if
you
have
a
root
which
is
never
sampled,
it's
going
to
propagate
to
its
child.
C
That's
my
probabilistic
sampler
and
then
I'm
also
going
to
capture
any
error.
I
just
encode
it
any
error,
meaning
is
if
there
was
a
log
event.
You
know
an
event
on
that
span.
That
said,
I'm
exceptional
something
special
is
happening
here.
You
could
just
encode
it
with
a
zero.
The
consumer
can
see
it.
It
counts
for
zero
probabilistically
speaking,
but
it's
there.
You
can
see
it.
Okay,
that's
the
other
use
for
xero
that
I
have
in
mind.
E
C
I
will
respond
to
these
in
the
writing,
so
others
can
see.
I
just
want
to
make
sure
that
we
have
the
discussion
so
that
that
so
we
can
resolve
that
one
yeah.
C
Was
it
for
my
my
agenda
point
here?
The
rest
of
this
agenda
was
me,
proposing
we
talked
more
about
composite
sampler,
specs
or
ted.
Proposing
the
same,
I
think.
C
Thank
yuri
I'll
I'll
follow
up
on
those
two
piers
two
people
are
dropping
off.
I
don't
know
if
that
vacuums
us
out
of
this
meeting
ted
if
you'd
like
to
talk
sampling.
I
know
atmar
you're
here
and
I
like
to
talk
to
you
when
you're
here.
The
only
thing
I
could
imagine
talking
about
is
this
new.
This
new
sampling
reservoir
thing.
You've.
You
put
some
code
up
for
I'm
probably
only
one
interested
in
it,
I'm
not
sure
ted.
C
Do
you
want
to
talk
about
the
more
pressing
matters
before
open
geometry?
I
think
as
much
as
I
like,
the
research-
that's,
maybe
not
the
most
important.
A
I'm
not
sure
what
what
else
is
more
more
pressing.
Here
I
mean
we've
talked
about
the
open
oak
taps
for
remotely
configured
sampling
like
I
do
think
this
group
should
come
up
with
that,
but
it
would
be
good
to
get
input
from
my.
C
My
input
on
that
is
that
that
sampling
can
be
treated
as
completely
separate
or
orthogonal
to
the
compositeness,
so
we're
going
to
define
leafs
in
this
tree
of
sample
or
composite
samplers.
Those
will
be
specked
out
the
one
before
they're
there,
maybe
a
fifth,
which
is
the
one
that
I
think
we
can
talk
about
right
now.
C
The
fifth
is
that
rate,
limited
idea,
which
is
where
we
get
into
this
research
potentially
and
then
that
composite
sampler
is
really
the
the
thing
that
runs
when
you
see
a
span
and
and
decides
whether
which
sampler
to
use
and
which
probability.
Therefore,
so
that
composite
is
all
about
views
and
configuration,
and
so
it.
B
B
A
C
And
we've
seen
examples
in
the
world
like
a
jaeger
sampler
like
the
aws
x-ray
sampler,
which
are
essentially
predicates
over
the
operation
name
or
the
span
name
plus
any
of
the
starting
attributes
is
the
way
I've
seen
these
done,
and
there
are
two
that
matter
in
the
world:
it's
the
aws
x-ray
system,
plus
the
jaeger
remote
ex.
You
know
system
and
they're
very
similar.
As
far
as
I
can
tell.
A
So
so
I
think
this
this
solves
my
problem
that
was
coming
up
in
in
the
instrumentation
sig
around
instrumentation
suppression.
A
If
we're
gonna
have
a
predicate
language
that
is
going
to
allow,
you
know
attribute
based
selection,
like
some
kind
of
pattern
matching
on
the
values
of
attributes,
including
the
span
name,
and
I
agree
they
need
to
be
there
at
the
start.
It
seems,
or
it's
a
little
silly,
so
maybe
not,
but
then
effectively
this
issue
of
instrumentation
suppression,
like
I
don't
want
this
health
check
or
I
want
to
turn
off
neti.
A
A
So
that
to
me
sounds
like
this
is
all
if
we're
going
to
build
something
like
that
anyways
for
sampling.
That
would
solve
that
issue
for
instrumentation
suppression,
in
other
words,
instrumentation
suppression,
is
just
another
form
of
sampling.
Where
you're
saying,
if
you
see
this
pattern
100,
you
know
zero
percent
sampling
like
just
yeah.
That's.
C
That's
the
way
I
would
treat
this,
and
so
it
becomes
pretty
separate.
You
know,
like
we've,
got
these
four
or
five
base
samplers,
and
really
it's
two
or
three
or
maybe,
and
then
your
your
configuration
has
to
do
this.
It's
process
this
predicate
and
what
you
said
was
like.
Are
there
wild
cards?
Are
there
patterns
like
that's
where
it
gets
tricky
and
that's
where
yeah?
I
think
the
debate
debate
will
happen.
A
Because
I
I
have
some
concerns
around
just
the
the
efficiency
of
this
stuff.
It's
good
to
know
existing
systems
do
it,
but
I
guess
that
would
be
my
question
of
like
how
like
I
think
we
do
need
to
put
some
thought
into
what
that
looks
like.
C
It
is
because
of
limitations
and
what's
available
today,
and
so
what
I'm
the
example
I'm
thinking
of
is
today
there
are
no
reservoir
samplers
and
there
are
maybe
these
rate
limit
samplers
or,
for
example,
we
were
calling
it
like.
We
need
something
like
that,
and
since
it's
not
there,
what
people
are
doing
instead
is
saying.
Oh,
I
need
this
like
really
fancy
way
to
do.
Regular
expressions
on
my
span
name
because
there's
a
pattern
and
if
you
perform
your
regular
expression
on
every
span,
which
is
super
expensive
by
the
way.
C
You
can
then
extract
this
pattern
and
decide
which
of
my
samplers.
It
should
fall
into
and
I'm
what
I'm
fearing
is
that
people
are
asking
for,
what's
obvious,
what's
also
very
expensive
when
there
might
be
something
better
for
them
and
the
thing
that
I'm
thinking
of
which
is
vague,
but
a
little
bit
you
know
hopefully
could
solve.
Our
problem
is
like
if
there
was
a
sampler
which
was
more
of
a
reservoir
thing,
where
you're
saying
I'm
never
going
to
send
more
than
100
spans
per
per.
C
Second,
then,
okay,
so
if
you
have
a
budget
of
100
per
second-
and
you
see,
there
are
more
than
100
per
second
and
90
of
them
are
health
checks.
The
natural
thing
to
do
is
to
start
down
waiting
those
health
checks,
meaning
if
you're,
if
you
have
a
fixed
size
sample
and
you
can
be
adaptive
somehow.
Maybe
this
isn't
a
problem
like,
but
we
we
don't
have
a
way
to
do
a
fixed
size
sample
and
we
don't
have
a
way
to
be
adaptive.
C
C
So
users
come
in
saying
all
they
can
imagine,
which
is
you
have
a
way
to
set
fixed
probability.
I
want
to
set
very
low
probability
on
this
stuff,
that's
happening
frequently,
and
I
want
to
set
high,
probably
on
stuff
that
happens
infrequently
and
that
to
me,
there's
like
a
more
natural
expression
of
that
same
rule,
which
is
please
give
everything
good
representation
in
a
sample.
That's
over
everything
and-
and
I
think
I
tend
to
think
of
inverse
weighting,
so
we've
talked
about
it
briefly.
B
C
B
Yeah
regarding
this,
this
approach,
I
think
it
only
works
if
you
just
have
one
attribute
you're
interested
in
so
if
I
think
if
it
gets
two-dimensional
or
even
more,
if
you
have
more
attributes,
then
I
think
this
approach
won't
work.
I
think
yeah
I
mean-
and
this
is,
I
think,
often
the
case
yeah.
From
my
experience.
We
often
have
multiple
dimensions
on
spans.
We
are
interested
in
and.
B
C
Deny
that
I
I'm
sort
of
I'm
proposing
something
quite
simple
that
would
be
like
a
assuming
this
set
of
span
names
is
fixed.
Please
adjust
sampling
rates
to
get
all
spans
covered,
like
that's
the
type
of
logic,
I'm
imagining
and
all
spans
covered
will
not
apply
to
every
dimension
that
you
know.
You
start
looking
at
multivariate
math
and
everyone
there's
this
phrase:
the
cursive
dimensionality
that
comes
back
and
over
again
and
yeah,
the
more
dimensions
the
combinatorially
harder
it
gets.
B
I
I
mean
I
agree
with
you
that
we
we
need
some
yeah
span,
attribute
dependent
sampling
rates
or
sampling
buffers
or
whatever.
However,
you
have
infinite
possibilities
to
write
such
a
same
pleasure
it.
It
will
be
really
hard
to
to
find
something.
What
what
would
make
it.
In
this
background,
I
think
so,
I
think
you're.
C
Probably
right
about
that,
so
at
least
we've
I've
said
that
and
now
we
can
proceed
to
do
the
dumb
thing,
which
is
to
give
people
regular
expressions.
I
guess
maybe,
but
this
is
where
we
should
have
jager
and
x-ray
at
the
table,
because
they
have
examples.
A
I
don't
know
if
that
relates
to
any
of
spans
or,
like
anything,
we're
talking
about,
because
I
haven't
been
to
the
metrics
meeting,
but
I
guess
what
I'm
saying
is,
I
wonder:
are
there
other
things
people
want
to
do
besides
sampling
that
involve
some
form
of
targeting
when
you
start
a
span,
when
you
know
I
just
have
some
kind
of
selector
so
that
when
I
start
a
span
and
see
certain
patterns,
I
want
to
do
stuff.
A
A
I
don't
want
to
end
up
in
a
system
where,
where
this
is
happening
like
several
times
over
when
when
a
span
starts
some
form
of
like
pattern
matching
on
the
span
to
decide
what
to
do
things,
I
don't
know
if
anyone
knows
of,
like
other
other
use
cases
when
that
would
come
up,
but
at
any
rate,
I
think
we
should
ideally
have
have
one
form
of
pattern.
Matching
that
happens
once
that
we
decide
is
efficient
enough,
like
whatever
balance
we
can
come
up
with
between.
A
C
I
think
I
totally
hear
you,
I
don't
think
we're
the
right
people
to
answer
this
question.
Like
you
know,
lightstep
has
a
product
called
streams
and
I
know
what
our
predicates
look
like
and
it's
it's
boolean
filters.
You
know,
but
we
don't
do
or
we
don't
do
disjunctions.
We
only
do
conjunctions.
So
it's
like
a
list,
a
conjunction,
that's
what
we
have
that's
our
support
and.
A
A
And
which
is
kind
of
my
point,
maybe
there's
some
subset
like
you-
can
just
get
conjunctions.
You
can
just
get
certain
kinds
of
pattern
matching
like.
Is
there
a
efficient,
more
basic
algorithm
that
actually
gives
people
enough
control
to
do
most
of
the
things
they
want
to
do
without
taking
the
hit
of
of
full
regular
expressions?
A
C
A
An
example
of
this
is,
you
know
you
shouldn't
be
looking
at
the
the
url
right.
You
should
be
looking
at
like
the
route
right
route
attribute,
for
example,
and
just
like
doing
a
basic
matching
on
that,
if
that's
possible,
rather
than
trying
to
drive
a
route
using
regular
expressions
from
a
url
that
that
kind
of
thing
but
anyways,
I
don't
want
to
waste
more
time
on
mars,
yeah.
C
C
For
for
remote
sampling,
composite
sampling,
configurat,
like
it's
it's
view,
selection,
it's
a
little
bit
more
than
sampling
right,
like
I
think,
you're
in
in
metrics,
you
can
choose,
we've
talked
about
choosing
exporter
based
on
this
as
well,
and
the
the
corresponding
idea
in
spans
is
like.
What's
your
aggregator
like?
What
are
you
aggregating
when
you
choose
after
you
choose
the
span
selection,
now,
there's
an
aggregation
happening
and
usually
for
span.
C
A
All
right
well
I'll
bring
that
up.
I
didn't
lose
you,
no,
it
didn't
make
sense.
It's
just
I
mean
I'm,
I'm
just
worried.
It's
going
to
be
a
sprawling
conversation.
A
You're
going
to
have
bugs
and
other
people
being
like,
no,
this
is
all
getting
like
too
complicated,
but
what
was
I
gonna
say
I
think
as
far
as
like
remote
configuration
stuff,
I
do
think
it
is
this
group's
responsibility
to
come
up
with,
like
the
configuration
language
we
want
for
samplers.
A
The
broader
thing
is
just
the
mechanism
right
like
what
is
there's
just
like.
What
are
your
configuration
options?
You
want
to
expose
remotely
or
let's
say,
like
runtime
configuration,
I
think
that's
what
we
really
mean
when
we
say
remotely
yeah
but
then
the
other
question.
That's
I
think
beyond
this
group
is:
what's
the
the
mechanism
for
feeding
and
sdk
configuration
updates,
because
we're
going
to
want
to
there's
going
to
be
a
variety
of
plugins
and
other
things
that
are
going
to
have.
C
C
A
I'll
bring
that
stuff
up
at
the
next
spec
meeting.
My
my
one
final
thing
before
you
guys
can
talk
about
whatever
you
want
is,
unfortunately
there's
another
sig
starting
up
at
exactly
this
time
around
semantic
conventions
for
messaging,
and
I
need
to
go
help
get
that
thing
running,
which
means
I
won't
be
able
to
come
to
the
future
meetings
of
this
sampling
sig
if
it
continues
to
meet
at
this
time.
C
We
could
perhaps
rename
this
to
be
the
span
view
configuration
sig,
I'm
not
sure
that
that
will
help
anybody,
but
I
feel
like
we've,
we've
grinded
to
the
end
of
probability
sampling
right
now.
I
don't
think
there's
a
lot
to
talk
about.
C
C
I've
been
working
on
histogram
stuff,
which
is
new
topic
and
omar,
and
I
can
talk
about
it,
but
I
don't
feel
like
it.
I'd
rather
continue
on
email,
yeah
sure
all
right.
Thank
you
all.
I
think
it's
been
good
we're
going
to
talk
about
view
configuration
in
the
general
meeting
next
tuesday
yeah
all
right
cool
thanks,
dad
bye,
everyone.