►
From YouTube: 2020-09-11 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
Morning,
see
maybe
some
new
faces
should
we
do
round
of
introduction
sweet?
Well,
I'm
ted
young.
I
work
at
lightstep
and
I'm
on
the
governance
committee
for
open
telemetry
and
I've
been
trying
to
help
shepherd
this
sampling
section
of
open
telemetry
over
the
finish
line,
but
looking
for
lots
of
help
and
support
from
the
people
who
are
in
need
of
sampling.
B
Awesome,
hey
everyone.
My
name
is
paul
osmond.
I
work
for
honeycomb.
On
the
instrumentation
side,
I've
contributed
to
various
projects
in
open
telemetry,
mostly
the
collector.
I
helped
get
our
our
exporter
in
there
into
the
contra
repo.
B
My
team
is
now
able
to
start
focusing
a
bit
on
our
sampling
story
and
how
it
works
with
open
telemetry.
We
have
you
know
various
forms
of
sampling,
supported
in
our
sdks,
of
course,
and
in
our
we
have
a
project
called
sam
proxy,
which
you
can
think
of
as
like
a
clustered
egress
that
does
sampling
and
so
yeah.
I
thought
I'd
stop
in
catch
up
on
how
the
group's
doing
and
see
if
there's
areas
where
I
can
help
out
the
stage.
B
My
team's
at
right
now
is
where
it's
pretty
early
still,
but
we're
building
out
kind
of
a
feature
matrix
of
like
all
the
various
ways
that
you
know
our
customers
are
doing
sampling
and
then
trying
to
figure
out
like
how
do
those
map
to
what's
currently
in
open
telemetry,
and
you
know
if
there
are
any
gaps
so
far.
It
looks
pretty
good,
but
I
mean
there's
some
things
with
the
collector
versus
sam
proxy.
That
I
know
are
in
progress
but
yeah.
That's
where
we're
at
sweet.
A
And
then
bautick
you
want
to
yeah.
Am
I
pronouncing
your
name
correctly.
C
Yeah
hey,
this
is
vartik,
so
I
work
with
aws,
so
I
recently
started
attending
the
sampling
sig
meetings
because
we
we
are
trying
to
like,
as
ted
mentioned
like
we
might
need
the
custom,
samplers
and
configurations,
and
so
so
just
wanted
to
like
keep
up
to
date
with
where
we
are
and
how
can
we
like,
contribute
or
like
configured
with
our
existing
module.
A
Yeah
great
good
to
have
you
back
so
to
to
maybe
more
for
paul
just
to
give
you
the
state
of
affairs
there,
oh
and
if
you
all
wouldn't
mind
going
to
the
the
working
group,
you
can
just
fill
our
names
in
here
sorry
working
group,
the
notes.
What
am
I
saying
if
you
wouldn't
mind,
just
filling
your
name
in
there
we
like
to
keep
track.
A
And
there
are
some
handy
links
in
there.
There
is
a
label
called
sampling
in
the
spec,
so
that's
super
useful
and
you
can
also
add
to
that.
A
release
required
for
ga
and
that'll
be
the
the
list
of
stuff
that
we're
trying
to
hit.
So
so,
if
you're
trying
to
track
what's
actually
going
on
in
sampling,
that's
that's
the
thing
to
track.
There
are
also
a
couple
of
proposals
open.
A
We
call
them
oteps
and
I
need
to
actually
go
through
those
and
see
if
they're
still
up
to
date,
so
that's
sort
of
where
it
is
and
as
far
as
like
the
direction
of
sampling
in
open,
telemetry,
there's
sort
of
two
parts
to
it.
I
think
one
part
is
what
I
might
call
standard
sampling.
I
have
cat
drama
going
on
over
here,
hang
on
one
second,.
A
A
You
can
turn
on
the
problem
with
that
approach
is
like
everything
that
involves
standardizing
as
it
requires
everyone
to
come
to
an
agreement,
and
sampling
is
one
of
those
areas
where,
especially
because
everyone
already
has
an
existing
system,
it's
hard
for
everyone
to
come
to
an
agreement
on
those
things,
because
even
if
we
invent
something
new,
that's
a
good
idea.
It
wouldn't
actually
integrate
with
what
people
are
doing
now
yeah.
So,
in
order
to
to
get
there,
we
have
sampling
plugins.
A
So,
in
addition
to
an
exporter,
you
can
provide
a
sampler
and
what
we
want
to
ensure
before
ga
is
that
that
sampling,
plug-in
interface
is
sufficient
for
the
kind
of
sampling
your
back
ends
are
currently
doing,
and
so
my
standing
request
has
been
for
people
who
do
have
sampling
concerns
to
to
try
to
implement
that
sampling,
plug-in
and
and
come
back
with
feedback
for
for
what's
missing
on
it
and
what
it
needs
and
unfortunately,
people
keep
showing
up,
and
then
I
say
so
have
you
made
one
and
they're
like
not
yet
or
whatever
so
so
that
that's?
A
My
only
real
concern
is
that
we're
going
to
get
a
bunch
of
feedback
like
you
know
at
the
last
minute
or
like
everyone's
going
to
implement
this
after
ga
or
something
sad
like
that?
So
that's
that's
the
one
thing
I'd
like
to
to
avoid
and
speaking
of
which
baatek
is
there
any
update
on
this
front
at
x-ray?
Have
you
all
managed
to
implement
a
sampling
plugin,
yet.
C
Not
yet
I
I
just
wanted
to
ask
like
so
since
I
just
started
I,
as
per
my
understanding,
we
currently
don't
have
like
I
I
remember
you
mentioned
like
it's,
it's
a
good
to
have
like
feedback
so
that
we
can
work
according
to
that.
B
C
Currently,
I
I
guess
we
currently
don't
have
any
like
any
kind
of
implementation
that
that
can
help
us
to
like
give
a
proper
feedback,
but
I
I
think
I
can
initiate
those
efforts
in
terms
of
like,
since
I
just
started.
So
can
you
like
point
me
some
pointers
on
like
how
can
we
like
what
kind
of
things
to
be
like
is
good
for
feedback,
and
we
should
like
focus
on
that.
While
we
are
implementing
those
stuff.
A
Yeah,
so
I
think,
in
order
for
x-ray
to
connect
to
open
telemetry,
there's
two
approaches:
one
is
to
build
an
x-ray
exporter.
The
other
is
to
have
x-rays,
start
ingesting
otlp
format
natively.
Now
I
presume
that
second
option
is
more
work.
I
and
I
don't
know
where
that
is,
but
the
first
is
to
to
get
an
exporter
out
the
door
which
I
believe
has
been
done.
I've
definitely
seen
blog
posts
and
things
coming
out
of
aws
about
this.
A
I
know
there's
been
some
team
shuffling
around
stuff,
but
but
that
would
be
my
suggestion
is
to
to
find
out
where
that
current
work
is,
and
I've
been
trying
to
push
this
concept
of
calling
these
things
distros,
where
you
may
have
to
actually
attach
not
just
an
exporter,
but
maybe
you
know
a
set
of
plugins
like
exporters
samplers,
there
may
be
configuration
options
that
you
need
to
set
that
are
kind
of
buried,
and
so
what
I'm
suggesting
people
do
right
now
is
is
take
open,
telemetry
and
wrap
it
up
in
something
that's
easy
for
your
customers
to
install
we're
doing
this.
A
At
light
step,
we
we're
going
we're
otlp
native
we've
been
putting
a
lot
of
effort
into
doing
that,
but
even
with
that,
we
still
need
a
little
layer
that
makes
it
easier
to
configure.
For
example,
we
have
something
called
an
access
token,
which
is
like
a
header
you
have
to
set
and
you
can
set
those
grpc
headers,
but
it's
kind
of
like
buried,
so
we're
just
making
it
nice
easy
layers
so
that
it's
sort
of
a
one-liner
to
get
started.
A
So
that's
my
suggestion
for
people
right
now
is
to
make
make
a
distro
and
whatever
thing
that
makes
sense,
and
then
we
can
start
listing
them
on
the
website
when
we
kind
of
do
an
overhaul
there.
A
So
it's
just
super
easy
for
people
to
get
started
and
then
over
time
you
know
maybe
less
and
less
is
needed
in
that
distro
and
I
would
suggest
going
that
route
because
you
also
want
to
be
able
to
have
people
who
have
set
up
open,
telemetry,
vanilla,
be
able
to
to
kind
of
just
point
point
point
at
you
and
and
start
sending
you
data.
So
in
the
long
run,
I'd
suggest
people
take
that
route.
A
C
A
Times
at
this
point,
so
I'm
feeling
good
about
those.
It's
just
these
samplers,
I'm
feeling
concerned,
because
I
have
yet
to
really
see
any
sampler
implementations
come
out,
even
though
I
have
seen
you
know.
I
know
from
liz
that
you
know,
honeycomb
is
has
does
some
cool
sampling
stuff
and
I
know
audrey
has
sampling
that
they
need,
and
I
know
aws
has
sampling
that
they
need.
A
So
so
that's
really
the
thing
we
want
to
look
at
and
one
thing
I
will
recommend
if
you're
going
to
implement
the
samplers
is
you
may
need
to
propagate
information
related
to
your
sampling
decisions
and
priorities
and
stuff?
Like
that,
the
place
you
want
to
put
that
information
is
in
what's
called
trace
state.
A
So
I
think,
are
you
both
familiar
with
trace
state?
Okay,
great,
so
just
wanted
to
call
that
out,
and
I
think
the
it
was
pointed
out.
I
need
to
follow
up
on
this.
That
trace
state
may
not
have
an
accessible
api
yeah
in
the
sampler
and
so
stuff,
like
that.
That's
making
me
worried
because
I'm
like
that's
a
super
basic
need
and
I'm
not
hearing
a
lot
of
feedback.
A
So
I
just
I'm
just
worried
that
it's
that
people
are
not
actually
exercising
this
and-
and
I
don't
want
to
really
be
guessing
at
what
people
need,
but
the
other
needs
might
be.
Does
the
sampler
have
the
right
hooks?
Is
it?
Is
it
observing
the
right
things?
Is
it
called
at
the
right
time,
and
the
third
thing
is
that
does
the
sampler
have
the
right,
knobs
and
abilities
like?
Is
it
the
degree
to
which
it
needs
to
influence
what
the
sdk
is
doing?
Can
it
do
that?
A
B
A
There
is
so
there's
the
you
know,
it's
fairly
straightforward.
I
mean
I
think
we
actually
want
to
contribute
back
the
little
configuration
layer
we've
made,
but
we'll
we'll
have
that
done
by
like
the
end
of
the
month.
So
we'll
have
a
thing
that
you
know
is
maybe
like
an
example
that
people
can
start
from,
but
you
know
right
now:
it's
just
the
sort
of
getting
started
with
open,
telemetry
stuff.
The
the
main
thing
I
would
suggest
is
do
not
do
not
fork
open.
A
Telemetry
like
it
is
feasible
to
fork
the
sdk.
That's
that's
a
thing
that
we
tried
to
preserve,
but
I
would
call
that
a
fork,
not
a
distro,
so
yeah,
I
would
say.
C
A
I
mean,
I
think
this
is
obvious,
but
just
to
clarify
you
want
to
make
sure
everything
you're
doing
is
is
on
top
of
it,
and
I
would
also
suggest
ensuring
that
you
don't
in
the
process
of
packing
packaging.
It
up
cut
the
end
user
off
from
being
able
to
to
continue
to
configure
it.
I
don't
know
how
that
would
happen,
but
yeah,
but
you
want
to
if
they
want
to
start
from
yours,
but
then
add
some
more
stuff
or
make
some
changes
you
just
probably
let
them
do
that.
Yeah.
B
So
similar
to
the
exporter
model,
where
I
mean
I
know
that,
there's
a
variety
of
ways
that
people
have
done
this,
but
we've
even
just
got
our
own
repo
and
it's
its
own
go
module.
It
just
keeps
in
release
lockstep
with
the
open,
telemetry
sdk.
A
Exactly
just
just
something
that
that
that
just
wraps
things
up
in
in
the
particular
example,
this
is
what
really
drove
it
was
the
need
for
multiple
plug-ins
right.
If
you
need,
if
it's
before
it
was
mostly
people
just
were
installing
exporters.
So
it
was
fine
where
it's
like.
A
You
just
release
your
exporter
and
then
plug
it
in,
but
now
that
it's
like
multiple
plugins
and
some
configuration
and
other
things,
it's
easy
to
see
that
an
end
user
following
instructions
could
miss
some
of
that
and
it's
like
what
happens
if
they
install
the
exporter,
but
not
the
sampler
right
like
so
it
that's
that's
the
main
driver
for
for
having
something
like
a
distro.
In
my
mind,
it's
just
to
just
ensure
that
they
don't
have
an
easy
way
of
getting
into
some
some
half
half
state.
B
Yeah
this
seems
like
really
good
timing
for
us
to
start
working
on
this.
We
we
just
wrapped
up
adding
support
for
trace
context,
headers
and
trace
state
headers
in
our
b
lines.
Actually
in
our
in
our
sdks
and
the
intended
use
case,
there
is
to
provide
that
on-ramp
for
customers
who
are
already
using
v-lines
if
they
want
to
take
one
of
their
services
and
swap
it
out
with
open
telemetry,
they
can
keep
their
trace
contacts
propagation,
intact
and
whatnot.
B
So
so
we've
been
kicking
the
tires
on
on
that
spec
on
the
w3c
trace
contact
spec
so
now,
actually
going
and
building
some
of
the
equivalent,
like
you
know,
sample
applications,
but
using
only
open,
telemetry,
sdks
and
pluggable.
Samplers
seems
like
a
good
time
for
us
to
do
that.
A
Yeah
sweet
because
the
you
know
the
spec
freeze
is
coming
very
quick.
We
wanted
to
have
tracing,
have
a
spec
freeze
by
this
week,
potentially
the
end
of
next
week,
like
that's
generally,
where
we're
going.
I
do
think
samplers
are
a
little
exempt
in
the
sense
that
they
are
in
the
sdk,
but
the
api,
we're
freezing.
So
we're
really
trying
to
move
quickly
to
locking
this
spec
down
so
that
everyone
can
focus
on
implementing
so
that
we
can
ga.
So
we
don't.
A
Spec
to
be
a
moving
target
for
everybody,
and
I
think
it's
like
mostly
there,
but
the
sample
is
like
the
one
piece
of
the
sdk
that
I'm
worried
about
where
people
are
going
to
implement
it
and
be
like,
but
the
flip
side
is
like.
Well,
it's
it's
a
plug-in
interface,
so
those
don't
break
nearly
as
much
stuff
if
we
do
have
to
make
a
breaking
change
to
it.
A
That's
just
six
plug-in
authors
who
get
grumpy
and
have
to
to
do
something
funky,
but
you
know
the
the
api
we're
not
breaking,
but
on
the
other
hand,
we
don't
want
sampling
to
really
be
exposing
the
api
at
all
yeah
like
something
the
end
user
is
trying
to
to
manipulate
and
control.
A
So
so
I
feel
confident
in
that
front,
but
I
am
still
just.
I
just
want
to
keep
reiterating
that.
I'm
nervous
that
I'm
not
seeing
implementations
yeah.
B
Yeah,
so
the
thing
the
thing
we'll
try
to
focus
on
is,
like
I
said:
we've
we've
got
that
product
feature
matrix
now
of
what
our
stuff
does
so
building
out,
implementations
that
do
the
same
thing
and
really
trying
to
find
those.
Like
you
know,
cases
like
trace
state
in
a
you
know,
distributed
sampling
use
case.
You
know.
Are
we
able
to
set
that
bit
on
the
tray
state
field
and
stuff
like
that?
B
A
That
that's
number
one
and
then
yeah
longer
term.
It
would
be
great
to
I
think,
bake
in
better
concepts
of
sampling.
I
do
think
it
would
be.
I
do
think
some
concepts,
not
that
everyone
has
to
use
them,
but
they
could
be
defined
in
a
standard
way,
especially
basic
stuff
like
priority,
but
but
even
there
it's
it's
hard.
Where
we're
like.
Let's
do
sampling
priority,
you
can
look
in
there
and
you
know
I
think
something
I
was
like
cool.
So
so
we
do
from
zero
to
a
thousand
and
other
people
are
like.
A
Well,
we
were
thinking
zero
to
a
hundred,
and
so
so
it's
I
have
found
sampling
is
the
biggest
bike
shed
in
all
of
this,
because
it's
maybe
less
related
to
the
telemetry
system
and
more
related
to
the
analysis
system.
Almost
everything
else
is
like
we're
just
describing
the
data
and
shuffling
it
off
to
you.
B
Really
for
anybody,
I
I
suspect
the
same
I
mean
you
know.
Honeycomb
has
our
own
header
that
we
had
before
we
introduced
support
for
trace
context
and
we
didn't
we've,
never
included
a
sampling
field
in
that
header
format.
And
you
know
a
lot
of
our
customers
are
doing
distributed
sampling
and
it's
just
never
coming
up
like.
A
Yeah
yeah
I
mean
I,
I
do
see
how
you
know
people
may
want
to
propagate
this
stuff
versus
you
know
configuring
things,
but
again,
that's
like
how
is
your
system
set
up?
Do
you
have
some
schmancy
control
plane
that,
like
auto
updates
all
your
stuff
and
people
click
on
a
ui?
Well,
okay,
you
probably
don't
need
some
header
to
send
this
stuff.
Also,
like
please
add
that
to
open
telemetry.
A
A
But
nevertheless
this
is
one
of
those
things
that
winds
its
way
into
the
mix,
because
you
have
to
do
it
at
runtime,
so
yeah,
so
yeah,
maybe
there's
a
way.
We
can
find
some
way
to
do
standardize
some
of
these
concepts.
That
would
work
but
well
enough
for
everyone
that
you
wouldn't
necessarily
need
a
plug-in.
You
would
just
have
a
configuration
option
where
you
say
hey
when
you
start
this
thing
up,
you
know
configure
the
sampling
to
priority
or
whatever,
and
even
then
you
might
still
want
to
have
a
little
wrapper.
A
B
That's
what
I
feel
like
that
makes
sense,
yeah,
cool
and-
and
this
is
mostly
this
is
all
related
like
the
the
timelines
are
all
related
to
the
sdks
right,
like
the
collector,
we're
kind
of
keeping
as
a
separate
thing.
For
now.
I
assume.
A
Yeah,
well
I
mean
we're
trying
to
to
ga
everything,
but
yes,
the
the
collector
you
know
is,
I
would
say,
farther
along
because
it's
you
know
it's
it's
one
implementation.
It
has
one
job
yeah.
A
So
the
main
thing
related
to
that,
though,
is
the
the
otlp
protocol
right,
because
there
is
some
tension
there
around
people
wanting
to
roll
the
collector
into
production,
which
means
that
protocol
is
going
into
production,
but
we're
still
realizing.
We
need
features,
we're
still
changing
things
around
based
on
feedback
there.
So
there
is
actually
some
tension
around
the
fact
that
the
collector's
out
in
production
sooner.
A
Else:
yeah,
for
example,
like
we're
reorganizing
the
status
codes
and
how
we
handle
errors
right
now.
Like
that's
the
other
thing,
I'm
trying
to
push
over
the
finish
line
and,
of
course
it's
going
to
affect
the
protocol
so
we're
starting
to
feel
that
need
for
backwards,
compatibility
and
stuff,
which
is,
I
think,
actually
a
good
thing,
because
it's
getting
us
to
think
about
that
stuff,
but
yeah
yeah,
but.
B
A
A
We
think
we
can
collectively
call
that
all
a
1.0
at
some
point
and
that's
the
thing
we
really
want
to
get
to
and
then
everything
else
we're
going
to
add
from
that
point
where
the
logs
or
control
planes
or
whatever
that's
all
going
to
be
experimental,
and
so
the
first
step
in
ga
will
get
is
just
getting
the
spec
1.0
and
then
once
that
happens,
then
it'll
be
sort
of
like
each
language
will
ga
once
they've
got
a
release
candidate
and
then
you
know,
go
go
ga
and
we're
kind
of
assuming
slash,
hoping
that
there'll
be
like
a
cadre
of
languages.
A
That
sort
of
do
that
around
the
same
time
yeah,
but
it
the
the
ga
event
to
a
certain
degree
is
like
the
spec
and
then
each
language
will
kind
of
dribble
out.
A
So
so
that
that's
the
plan
and
we're
hoping
to
to
get
that
all
done
this
year.
Not
every
language
released
this
year,
but
at
least
some
of
them
ga
this
year,
but
it
is
difficult.
This
project
famously
has
has
not
come
close
to
meeting
any
proposed
deadline
we
have
ever
set
for
it
yeah
a
lot
of
groups.
A
A
So
so
whatever,
but
I
did,
I
did
claim
we
wanted
to
start
sun
setting
open
tracing
and
open
census
by
kubecon
north
america.
I
did
not
specify
which
kubecon
north
america
so,
but
I'm
hoping
it's
this
one
yeah
nice
cool,
yeah,
so
anyways,
that's
where
we're
at
with
sampling,
I'm
happy
to
we've
got
30
minutes.
I'm
happy
to
ask
answer
any
other
questions
about
open
telemetry,
since
it
seems
like
you're.
C
C
Yeah,
I
was
just
wondering
whether,
like
for
sampling,
do
we
have
like
any
kind
of
like
open
telemetry
sample
will
be
having
like
any
kind
of
default
sampling
or
like?
Will
it
be
like
the
custom
configuration
like
where
you
can,
where,
basically,
you
can
set
like
the
default
sampling,
as
well
as
the
like,
multiple
samplings,
basically
so,.
A
There
is
the
ability
to
just
have
it
respect
the
sampled
flag.
That's
the
main
thing:
that's
in
there
right
now
is
you
can
turn
that
on.
So,
if
you
look
at
I'll
just
post
this
here,
the
current
built-in
sampler
api
derp.
B
B
A
Yeah,
it's
cool,
there's
some
built-in
ones
and
that'll
help.
Maybe
future
systems
right.
Someone
comes
along
and
they
want
to
build
some
cool
pool
off
of
open
telemetry.
Then
you
know
they
can
just
pick
from
these
things,
but
I
don't
think
those
help
like
any
of
the
current
systems
too
much.
As
far
as
I'm
aware.
A
C
I
think
custom
samplers
makes
much
more
sense
because,
like
sampling
is
something
that
basically
depends
on
where
you
are
running
your
application
right.
If
you
are
running
on
different
clouds,
then,
and
and
how
you
are
running
your
application,
if
you're
running
your
applications
within
multiple
instances,
then
how?
How
do
you
plan
to
do
sampling?
So
it's
pretty
much,
I
feel
the
need
for
sampling
is
like
values.
A
It's
definitely
not
a
mix
and
match
thing
where
you
pick
some
analysis
tool,
and
then
you
select
what
kind
of
sampling
algorithm
you
would
like.
You
know
they
seem
yeah
as
far
as
I
can
tell
at
least
today
pretty
pretty
tied
together,
I
could
see
future
systems
once
you
know.
We
have
some
like
actually
interesting
or
useful
sampling
types
baked
in.
A
A
But
my
concern
is
that
they're
they're
fairly
simple
right,
like
they
just
use,
they
just
use
that
sampling
bit.
I
believe,
and
I'm
concerned
that
other
samplers
will
need
more
than
what
these
things
currently
do.
C
And
just
to
like,
create
it
on
one
of
the
like
just
to
be
clear
on
one
of
the
point
that
you
mentioned,
like
you
mentioned
like
that,
like
the
sampling
bit
inside,
the
tray
state
is
not
like.
Basically,
we
we
won't
be
providing
any
kind
of
apis
right
to
change
that.
A
No,
no,
I
don't
believe
that
is
something
that
should
be
exposed
to
the
application
developer.
That's
that's
just
a
recipe
for
all
kinds
of
trouble,
and
it's
also
well
there's
two
reasons:
one:
it's
a
recipe
for
trouble
because
in
general
you
should
not
be
mucking
about
like
that.
Right
like
that,
just
sounds
bad
and
two.
We
don't
this
stuff
is
not
universal.
A
It's
again
it's
about
what
is
the
underlying
system
doing
not
about
how
am
I
recording
what
my
application
is
doing
and
geez
we're
really
trying
to
keep
the
api
focused
on
that
entirely
on
I'm
just
describing
my
system,
I'm
just
propagating
stuff
through
my
system
and
to
leave
out
anything
that
leaks
implementation,
details
and
since
there's
no
universal
concept
of
sampling.
If
anything
about
sampling
got
into
that
api,
it
would
just
be
trouble
right,
because
how
how
can
you
have
some
kind
of
common
representation
there?
A
A
Usually
for
people
to
be
like,
I
want
to
do
something:
that's
kind
of
expensive
to
record
a
value,
but
if,
if
you're
just
dropping
the
data
on
the
floor,
then
I
don't
want
to
bother
so
I
think
that's
the
only
feature,
but
that's
more
about
like
not
even
sampling
but
like
is
there
an
sdk
installed,
and
so
I
think
the
language
we're
trying
to
use
there
is
more
like
is:
is
the
tracer
on
or
not
yeah
not
like?
Is
it
sampling
or
not?
Yeah.
A
Yeah
that
that's
that's
the
way
I
think
most
systems
work
either.
You
know
everything
is
just
configured
flat
across
the
board
about
sampling
in
some
way,
but
generally
you
have
to
propagate
something
like
if
you
want
to
get
consistent
sampling
across
a
tray.
So
you
don't
propagate
something
like
that.
Then
it's
not
useful
to
to
you
want
to
sample
at
the
trace
level,
not
at
the
span
level
right.
So
that
was
an
initial
thing.
I
saw
for
systems
that
didn't
didn't,
have
a
concept
of
propagating
that
kind
of
sampler.
C
A
And
so
to
a
certain
degree,
that
bit
can
be
useful
in
the
sense
that
if
the
sampling
decision
you're
making
is
is
just
at
the
at
the
head,
you're,
just
like
flip
a
coin
or
whatever
it
is,
we
do
and
we've
decided
it's
on
or
off.
So
you
you
can
see
that
be
be
useful
for
people,
but
in
practice
you
know
we're
seeing
things
more
like
sampling
priority
and
like
there's,
there's
a
little
more
nuance
there
than
just
flipping
a
coin:
we're
rolling
a
10,
24
sided
dice
or
whatever.
It
is.
B
Yeah
swings
yeah,
our
customers
definitely
have
a
mix,
but
it's
like
I
mentioned
tail
sampling
for
us
is
strictly
the
sam
proxy,
so
folks
will
install
a
separate
piece
of
software
to
do
that
which
maybe
eventually.
A
We've
got
like
a
similar
architecture,
they
run
a
you
know,
we
call
them
satellites,
but
they
run,
they
run
a
thing
and
the
sampling
sampling
decisions
happen
there
and
you
know
as
long
as
that's
local
network,
then
you
know
the
the
costs
and
overheads
of
that
you
know
are
totally
acceptable.
I
think
for
almost
everybody,
because
that's
been
our
experience.
B
A
A
Well,
maybe
that's
that
then
you
can
find
me
on
gitter
so
feel
free
to
dm
me
there
if
you're,
hitting
any
road
blocks
or
have
any
further
questions,
and
please
maybe
start
tracking
those
sampling
issues
and
oteps,
just
to
kind
of
see
where
the
current
current
state
of
play
is
yeah
sounds
good.
I'm
looking
forward
to
kicking
the
tires
awesome
great
well
nice
to
meet
you
paul
good,
to
see
you
again,
patrick
yeah,.