►
From YouTube: 2021-08-12 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
B
Unfortunately,
I
have
a
conflict,
so
there's
one
thing
that
I
absolutely
want
to
discuss
and
then
there's
one
thing
that
we
can
discuss,
but
I
think
we
can
also
take
that
offline
around
the
data
model,
specifically
around
trying
to
make
progress
on
non-monotonic
sums,
but
I
think
that
that
basically
I
can
take
offline
and
just
talk
between
josh
and
bogdan
and
myself,
because
those
are
the
three
the
three
involved
in
the
in
the
pr
that
you
know
has
a
confidence.
B
Oh
okay,
so
the
first
thing
I
wanted
to
talk
so
riley
you
know
made
the
the
pr
for
the
exporter,
which
already
has
some
reviews
quickly.
So
let
me
get
the
link
in
there
in
the
notes
and
what
I
wanted
to
talk
about
was.
If
you
look
at
the
the
current
exporter
pr
explorer
discussions,
here's
the
link
come
on
computer.
B
If
you
look
at
this
so
yeah
right
now,
there's
an
interface,
sorry,
there's
there's
an
interface
proposed
that
has
an
export
that
takes
a
batch.
It's
it's,
the!
B
What
you
were
just
showing
is
what
I
wanted
to
show
so
there's
an
interface
that
takes
an
export
which
is
a
batch
right
which
gets
pushed
and
then
in
the
specification
there's
this
notion
of
pull
versus
push
metrics
and
like
a
pull
exporter
versus
a
push
exporter.
But
from
what
I
understand
that
interface
that's
described
is
a
push-based
interface.
C
C
B
C
B
C
B
Okay,
I
guess
my
only
ask
would
be
then:
let's
make
that
pr
just
be
about
push-based
exporting
and
all
the
notions
about
push
versus
pool
and
supporting
both
of
them.
I
would
like
to
hold
that
until
we
have
the
pool
based
interface.
C
Defined
I
see
I'm
actually
thinking
push
and
pull.
Exporters
should
have
the
same
interface
and
all
of
them
are
full
based.
So
basically
you
have
something
you
can
feed
the
data,
but
I
I
see
what
you're
saying
so
I
I'm
fine
with
just
focusing
on
the
offer
for
now
later.
If
we
can
unify
the
model,
I
can
do
another
pr.
B
B
When
asked
and
there's
something
that
decides
to
transfer
the
data
right,
the
the
difference
is
the
difference
between
pool
versus
push
is
for
pool.
We
need
someone
to
say:
go.
Give
me
metrics
right
now,
yeah
versus
push,
you
don't
care.
Someone
else
makes
that
decision
right
yeah,
but
that
that
that
hook
to
say
give
me
data
right
now
is
the
bit.
I
don't
see
in
the
current
interface.
D
Sounds
like
you're
agreeing
if
we
take
out
pull-based
exporters
from
this
pr
and
agree
to
talk
about
metrics
reader
in
the
near
future.
Yeah.
My
perspective
here
was
that
josh
in
recent
weeks,
you've
asked
us
to
not
try
to
pin
down
the
sdk
to
do
a
particular
implementation,
and
I
feel
like
we're
almost
there
again
and
I
don't
want
to
do
that.
I
have
in
the
go
prototype,
have
a
push-based
path
and
I
also
have
a
reader-type
interface
and
I
don't
want
to
force
everyone
to
have
that
same
particular
organization.
D
D
For
the
instruments
that
are
producing
one
output,
like
all
the
asynchronous
ones,
you
only
have
one
observation
and
two
exports
and
for
the
delta
to
cumulative
that
has
to
happen.
That
only
happens
for
part
of
the
export
path
like
if
you're
reading
cumulative
you
end
up
getting
one
piece
of
state
and
if
you're
push.
If,
if
you
actually,
I
was
trying
to
say
earlier
that
I'm
not
trying
to
pin
down
the
sdk
in
both
of
the
exporters.
D
B
So
so
that's
kind
of
what
I'm
getting
at
here.
I
I
only
want
to
define
the
interface
for
how
someone's
going
to
write
an
exporter
right
like
we
assume
that
people
are
going
to
be
writing
exporters,
and
so
the
question
I
ask
myself
reading
the
spec
is:
can
I
write
the
ltlp
push-based
exporter
and
can
I
write
a
prometheus
pool
based
exporter
and
the
second
thing
I
think
the
answer
right
now
is
no
or
if
I
do
it,
I'm
doing
a
push-to-pull
conversion
with
what's
written.
B
The
second
thing
is:
there's
things
in
the
specification
about
how
this
should
support,
pool
and
push
exporters,
and
what's
weird
about
that,
is
there's
only
one
interface
to
find.
So
I,
when
I,
when
I'm
basically
asking
with
this
pr,
is
what
should
I
expect
in
this
pr
what's
coming
later,
and
and
what
do
we
eliminate
it
to?
B
Because
if
you
take
the
pr-
and
you
just
say-
here's
the
interface
for
push
and
we
take
out
all
the
verbage
around
push
versus
pull
for
now
and
then
that
that's
a
separate
pr
where
we
can
look
at
pool
and
we
can
evaluate
them.
I'm
totally
fine
with
that,
but
but
the
way
it's
written
now
I
think
it's
it's
unclear
to
me
how
I'd
implement
prometheus
as
a
receiver
as
an
exporter,
and
it's
unclear
that
the
distinction
between
push
versus
pool
is
meaningful
right
now
and
that's
fine.
C
I
agree
with
you
josh
that
that's
a
good
point
by
the
way
I
want
to
mention
something
so
put
something
in
your
brain
for
now
so
for
in-memory
exporter
and
console
exporter,
I
try
to
model
that
in
a
way,
so
it
can
be
an
exporter
that
works
for
both
push
and
pull
model.
So
imagine
you
have
a
console
exporter.
C
I
I
would
say
you
can
say:
hey
console
exporter,
please
export
the
data
every
10
seconds
or
you
can
say,
console
exporter,
do
nothing
I'll
I'll
type
enter
in
my
console
and
whenever
I
press
the
enter
key,
you
just
go
and
give
me
all
the
current
metrics
and
the
second
scenario
when
you
press
a
key,
you
got
all
the
metrics,
it's
exactly
the
same
as
premises
like
the
external
input.
You
trigger
something
and
I
think
it
it.
It
would
be
a
bad
thing.
C
If,
if
I
come
up
with
a
something
like
hey
for
console
exporter,
you
actually
have
to
implement
two
one
is
the
push
console
exporter.
Another
is
cool.
I
want
to
have
like
people
just
write
one
interface
and
implement
that
once
so
it
can
work
in
both
scenarios.
That's
what
I'm
trying
to
do
and
I
I
think
I've
figured
out
a
way
it's
just
I
haven't.
I
probably
I've
been
slow,
I'm
trying
to
explain
how
we
could
do
that,
but
but
josh
I
I
believe,
with
the
current
interface,
we
should
be
able
to
cover
the
premises.
B
No,
I
I
think
I
honestly
like
what
you
have
today.
I
could
implement
the
prometheus
exporter
with
it,
but
it's
not
a
pull-based
exporter
right,
like
what
I
would
do
is.
I
would
have
this
push-based
exporter
with
the
interface
that's
defined
today,
and
I
would
have
to
store
things
locally
and
I
can
see
how
to
implement
that.
If
you.
A
B
Maybe
that
makes
sense
as
well,
but
the
the
I
see
a
way
to
take
push-based
exporters
and
turn
them
into
pool
yeah
the
interfa.
If
you
want
to
unify
that
interface
and
have
push
and
pull
be
the
same
interface,
I
I
I'm
really
interested
to
see
what
you
have
there,
but
I
also
don't
want
to
block
this
on
that.
I
think
the
interface
you
have
right
now
is
perfect
for
push-based.
If
that's
all
we
expose
initially,
and
we
do,
we
do
a
push-to-pull
conversion.
That's
also
fine.
B
D
A
You
know
yeah,
I
think
I
think
I
my
question
is:
is
there
another
poll
based
export
exporter
out
there
that
we
need
to
worry
about
aside
from
prometheus,
and
is
there
some
exporter
that
accepts
both?
That
can
work
identically?
Both
push
and
pull?
I
mean
I
know
prometheus-
has
some
sort
of
push
support,
but
I
think
that
could
be
covered
just
by
the
transformation
rather
than
having
to
have
a
simple,
unified
interface.
D
Every
example
of
this
in
the
prometheus
sidecar
I
actually
use
the
hotel
go
sdk
there
and
it
does.
It
does
health
checking
of
itself
by
reading
its
own
metrics
it
serializes
them
and
passes
them
to
the
parent
process,
which
then
does
the
health
check
and
and
kills
the
process
and
so
on.
So
it's
a
real
use
case.
B
Yeah
and
I've
been
using
prometheus
exporter
as
kind
of
a
a
workaround
in
the
in
the
near
term,
where
I
just
turned
that
one
on
to
do
my
local
health
checks,
but
it's
missing
a
bunch
of
otlp
data
right,
so
it'd
be
a
little
bit
better
for
me.
If
I
had
an
otlp
version
where
I
get
like
the
resource
and
that
sort
of
thing
out
instead
of
just
prometheus
but
again
that
you
asked
like
any
other
exporter,
I'd
argue
it's
kind
of
almost
the
same
or
at
least
functionally.
D
You
could
imagine
wanting
to
pull
otlp
in
part
of
a
like
resource
discovery
of
the
future
very
easily.
You
know,
rather
than
forcing
us
to
use
the
prometheus
protocol
to
pull
metrics
out
of
the
process.
Let's
just
use
otlp
and
then
the
question
is:
do
you
want
a
point
in
time
which
is
the
prometheus
model,
or
do
you
want
a
stream
of
updates
at
which
point
you're,
really
just
pushing
deltas
through
a
channel
you've
established
and
and
that's
the
next-
a
push
export?
D
D
C
Okay,
so
what
I
I
will
do
with
with
the
exporter,
pr
is
I'll
scoop
down
a
little
bit
I'll
I'll.
Just
mention
in
memory
explorer
will
be
a
push
and
pull
exporter,
but
currently
the
pull
exporter
part
is
tbd,
we'll
cover
in
the
next
pr
and
then
I'll
change.
The
wording
saying
this
interface
is
for
push
exporter.
C
Only
full
exporter
will
be
covered
later
and
after
we
merge
this
pr
I'll,
send
the
second
pr
to
clarify
the
matrix
reader
and
how
I'm
thinking
we
can
potentially
use
the
same
interface
for
both
both
push,
and
I
think
in
that
we
also
have
some
prototype.
I
can
work
with
ceo
to
extract
some
example,
for
people
to
understand
would
that
be?
Okay,.
B
Yeah
yeah,
I
mean
I,
I
think
most
of
the
languages
have
a
metric
reader
thing
right
now,
but
I
I'm
more
than
happy
with
that.
My
key
point
here
is:
what
can
users
extend
and
what
does
that
interface?
Look
like
that's
what
I
want
to
have
at
least
a
notion
of
in
this
answer
right.
So
if
we're
expecting
users
to
be
able
to
add
their
own
pool
based
exporters,
what
are
they?
Otherwise?
B
C
C
And
does
that
finish,
your
topic
josh.
C
I
had
to
comment
on
that
pr,
so
awesome
I
I
have
a.
I
have
a
question
on
victor's
pr.
Sorry
I
was
looking
at
that
last
night.
I
I
think
was
not
clear
to
me
is
that
the
aggregator
is
a
like
h2
element,
so
it
seems
it's
a
it's
a
the
sibling
like
node,
comparing
to
like
meter
provider
and
other
concepts.
C
It's
not
clear
to
me
is
that
supposed
to
be
a
type
or
interface,
or
it's
just
a
concept,
or
it's
something
that
concretely,
we
expect
that
sdk
to
implement,
expose
my
my
gut
feeling
is
it's
just
a
concept
and
it
can
be
used
as
a
configuration
parameter
on
the
view
it.
It
will
not
have
any
any
like
public
type
exposed,
but
in
the
individual
language
might
decide.
Okay
for
options.
I
want
to
give
a
strong
type.
It's
their
choice.
It's
not
specked
out.
C
E
So
so
I
think
the
the
direction
that
you
know
we
discussed
is
that
we
wanted
just
to
focus
on
the
configuration
for
the
view
right,
and
so
so,
if
we
take
it
from
that
perspective,
then
from
the
view
we
need
a
way
to
specify
you
know
an
aggregate
or
whatever.
That
is
so.
E
I
would
say
that
we
probably
starting
off,
I
think
it's
a
conceptual
type,
but
each
of
the
implementation
may
make
that
more
concrete
such
that
and
I
augmented
the
spec
to
cover
some
of
your
feedback
is
to
say
that
basically,
we
need
a
semantic
way
to
represent
aggregator
type
and
its
parameters,
and
you
could
do
so
by
you
know
for
languages
that
support
classes
and
types
they
may
do
so
with
concrete.
E
You
know:
implementation
of
a
histogram,
aggregator
class,
you
know,
or
if
the
language
doesn't
choose
to
do
that,
then
you
could
just
refer
to
it
as
a
histogram
string
per
se
and
then
you
know,
and
then
the
language
will
do
specifically
things
about
it.
Now
there
is
one
area
of
complication
that
I
think
yeah.
We
have
this
concept
of.
E
I
have
this
concept
of
aggregated
name
which,
like
the
name
like
default,
or
the
name
like
you,
know,
histogram,
where
the
it's
not
it
morphs
right.
So,
if
you
just
say
default,
then
that
aggregator,
if
you,
if
you
were
to
implement
let's,
say
a
default
aggregator,
then
that
aggregator
actually
morphs
depending
on
you
know
what
instrument
kind
you
have
so
there.
I
think
there's
a
bit
of
complication
from
that
perspective
where,
where
that
concept
of
aggregator
name,
that
is
used
generically
from
the
view
api
to
specify
you
know
some
other
concrete
type.
C
Yeah,
so
I
sorry
I
cannot
share
my
screen
and
or
you
cannot
even
see
me
so
I
I
put
something
in
the
chat,
so
so
here's
my
suggestion.
C
First,
you
put
the
aggregation
configuration
as
a
concrete
thing
under
the
view,
because
it's
part
of
the
view
parameter
and
second,
any
details
like
what's
the
default
aggregation
rule
and
if
people
specify
something
how
they're
going
to
interact
like
they
probably
override
part
of
the
default
aggregation
rule,
that's
a
separate
topic
at
h2
and
it
shouldn't
be
a
type.
So
we
put
a
space
there
to
explicitly
tell
people.
This
is
just
a
section
providing
information
that
makes
sense.
C
My
word
is
currently
with
good
aggregator,
as
another
h2
element,
it
seems
to
me,
like
aggregator,
should
be
same
as
meter
provider.
I
should
have
a
class
or
type
in
my
language
that
that
makes
me
worried
and
also
the
wording
we
mentioned
some
aggregator
instances.
I
I
don't
understand
what
is
aggregator
instance.
Unless
you
tell
me
this
is
archive,
make
sense.
C
B
Yeah
the,
for
example,
the
existing
job
implementation
has
both
aggregator
and
aggregator
factory
and
aggregator
factory
is
the
thing
that
lives
at
the
point
in
time
where
you,
you
know,
call
this
thing
an
aggregator
and
then
there's
also
the
configure
that
aggregator
factory,
but
you
know
with
java,
you
just
keep
appending
like
nouns
to
things
it's
pretty
exciting.
I
love
it
but
like.
I
think
this
is
the
point
where,
from
what
I
understand
on
the
spec,
this
is
defining
the
configuration
for
aggregators
for
views.
B
That
was
the
whole
point
of
it
and
if
we're
worried
about
the
name
aggregator
there,
if
there's
any
way,
we
can
clarify
that
this
is
you
know
configuring
aggregation
on
views
and
that's
what
this
is.
I
fully
expect
us
to
eventually
have
an
aggregator
interface
right.
That
was
the
the
point
of
my
comments
was
not
not
to
define
an
aggregator
interface.
Just
let's
not
do
it
right
now,
let's
only
define
views
and
only
expose
that
so
that
we
have
more
freedom
and
implementation
and
then
we'll
get
an
aggregator
interface
later.
E
Okay,
so
we
could
reserve
the
name
aggregator
for
the
moment
to
represent
a,
I
guess,
a
conceptual
type,
knowing
that
going
forward
that
might
turn
into
a
more
concrete
type.
C
A
C
B
A
C
D
I
mean
like
this
question
that
victor
started
with
about
how
histogram
is
an
alias
for
sort
of
whatever
default
histogram
there
is
and
explicit.
Histogram
is
a
way
of
saying
that,
but
you
could
also
have
a
histogram
with
a
config
option,
called
explicit
scale
or
explicit
buckets
or
exponential
scale
or
like
whatever
type
like
to
cite
the
type
based
on
key
values
inside
of
a
general
purpose,
object
and
so
on.
D
Like
that's
all
view
configuration
again
and
then
the
rules
are
more
closely
tied
with
the
data
model
and
the
default
rules
are
more
closely
aligned
with
the
api
semantics,
and
so
I
totally
agree
with
your
summary
and
I
don't
think
we
need
to
say
any
more
about
the
mechanics
of
aggregators.
It's
all
about
view
configuration
that
this
discussion
seems
to
be
stuck
on.
C
Okay,
so
that
covered
my
first
topic-
and
I
I
think
josh
has
a
josh
storage-
has
the
the
exemplar
pr,
and
that
looks
pretty
good
to
me.
Oh
currently,
I
think
joshua
mark
like
has
a
draft
only
because
you're
waiting
for
victor's
pr
right.
B
Yeah,
I
think
victor's
pr
is
in
shape
enough
that
I
can
go
update
it.
I
I
failed
to
do
that
last
week,
so
I
will
do
that
as
soon
as
I'm
able
to
probably
later
today,
maybe
tomorrow,
but
yeah,
now
that
now
that
that
pr
is
mostly
kind
of
agreed
upon,
I
just
need
to
we
need.
We
need
a
hook
to
understand
what
aggregator,
like
there's
a
hook
to
have
aggregators
influence.
The
exemplar
reservoir,
that's
chosen,
and
but
the
plan
was
to
to
either
expose
that
to
users
or
not.
B
B
We
can
also
just
drop
that
as
a
concept
and
just
say
like
we
can
define
the
the
concept
of
what
sampling
needs
to
look
like
without
any
exposed
interfaces
to
users
and
just
a
few
configuration
parameters
and
go
with
that
as
well,
like
none
of
those
interfaces
defined
in
that
vr
need
to
be
exposed
right
now.
So
if
there's
any
contention
there,
my
plan
was
just
to
drop
them
and
only
specify
config.
B
B
B
If
we
get
a
bunch
of
comments
on
the
interfaces
being
problematic,
my
plan
is
to
drop
them
all
and
only
leave
the
configuration
params
and
what
they
mean
and
what
they
entail,
and
the
notion
of
what
sampling
should
look
like
in
general,
but
there'll
be
no
like
no
user
interface
like
code
wise
changes,
they
can
only
have
that
like
sample
with
traces
sample,
everything
or
sorry
allow
sorry
only
sample
from
trace
correlated
measurements
sample
from
anything
or
don't
sample.
As
like
the
three
config
parameters,
that's
the
bare
minimum
vr
maximum
pr
is.
C
Okay,
and
and
with
that
just
quick
summary-
I
I
believe
like
victor's
pr,
should
be
able
to
merge
if
we
fix
them,
like
minor
ratio
like
structure
to
arrow.
For
that
I
I
I
think
we
can
try
to
get
him
merged
by
this
and
dodge
your
pr,
and
my
ipr
will
probably
will
improve
that
and-
and
I
I
think
this
week
is
a
little
bit
tight.
So
probably
we
can
target
next
week
to
get
both
smurfs
and
then
moving
forward.
I
I
still
see
the
matrix
reader
part
or
like
pipeline.
C
We
call
it
many
different
things.
There's
no
such
pr,
so
I'll
would
be
my
next
priority
and
another
thing
I
I
think
that
makes
me
uncomfortable
if
we
were
trying
to
see
the
matrix
initial
experimental
release
for
the
sdk
spec
is
the
measurement
processor
josh.
C
You
mentioned
that
you
would
want
to
remove
that,
and
I
I
think,
like
john
also
mentioned
it
seems
like
if
we
don't
need
that
now,
let's
remove
that
and
just
ship
a
minimum
version
I
just
want
to
get
general
feeling,
like
do
people
feel
measurement
processor,
it's
necessary
for
the
initial
release
or
you're
fine
with
removing
that
and
by
default.
I
assume
people
are
fine.
Just
to
explain
a
little
bit.
There
has
been
a
github
issue
saying
from
dynatrace.
They
want
to
be
able
to
get
the
raw
data
they're
saying
like
in
some
scenario.
C
I
want
to
trigger
based
on
the
raw
measurements,
and
if
you
don't
give
me
a
mechanism,
everything
is
pre-aggregated,
then
I
have
to
do
something
else.
Maybe
I
have
to
double
instrument
which
is
bad
and
measurement
processor
was
introduced
just
to
solve
that
issue.
So
if
we
remove
that
we
can
probably
tell
them
sorry.
The
first
version
won't
cover
this,
but
we
can
add
that
later,
is
that
clear.
B
I
bet
that
everything
I
have
to
say
would
duplicate
what
you
say
and
not
be
as
good.
So.
D
D
Can
you
say
clearly
explicitly
what
you're
saying
to
remove
the
measurement
processor
interface,
which
was
like
got
some
tbd's
around
it
correct
yeah?
I
mean,
I
think
I
support
the
idea
that
we
don't.
I
think
this
is
a
new
discovery
that
I've
under
had
recently,
but
we
want
to
not
pin
down
the
sdk
as
much
as
we
can
so
if
he,
if
removing
that
those
words
from
the
spec
languages,
satisfies
others,
that's
fine
with
me.
I
also
want
to
say
I
haven't
prototyped
this
in
anything,
that's
been
merged.
D
Well,
exemplar
support
is
closely
connected
with
getting
baggage
out
of
the
context
on
this
on
the
call
site,
and
although
we
haven't
ever
done
it,
I
don't.
Of
course
I
don't
think
you
need
to
change
the
api.
The
api
for
the
metrics
already
says
you
have
a
context,
or
at
least
in
the
prototype
for
go.
You
have
a
context
coming
in,
which
is
how
you
get
all
your
baggage
and
the
aggregator
receives.
D
I
said
the
aggregator,
but
I
think
I
mean
the
examplar
observer
or
whatever
it
is,
that
josh
called
it
sees
the
context
and
the
measurement
the
label
set
at
the
moment
the
api
is
called
so
you
do
get
that
thing
that
dynatrace
wants
and
I
I
would
insist
on
that
too.
We
can't
have
exemplars
without
that,
but
I
don't
need
to
say
how
the
sdk
does
it.
B
Yeah,
so
for
my
unders
just
to
add
on
to
that
views
already
exposed
the
ability
for
us
to
attach
labels
from
baggage
and
so
to
the
extent
that
that's
not
enough.
I
think
we
push
on
that
ability,
like
my
my
opinion
right
now,
is
that
views
give
us
the
configuration
we
need
for
80
of
the
cases
where
measurement
processor
would
be
used
and
to
the
extent
they
don't.
We
should
first
look
at
views
and
then
look
at
why
we
need
measurement
processor.
B
There's
a
performance
related
thing
in
java,
where
we
try
to
have
bounded
memory
and
bounded
these
bound
instruments,
so
it
binds
memory
and
make
sure
that
you
don't
have
allocations
in
your
hotpath.
I
don't
want
to
lose
that,
but
it's
not
I'm
not
completely
sold
on
it
like
this
measurement.
Processor
basically
negates
a
a
big
2x
performance
gain
in
java,
but
it's
not
I'm
not.
B
I
don't
need
that,
but
it
is
something
I
don't
want
to
sacrifice
unless
we
have
a
really
good
use
case
for
it
that
it
has
no
other
solution
and
yeah,
I'm
sorry
I
gotta
drop
now
so.
Okay,
thanks.
D
I
I
did
prototype
some
stuff
and
I
I
knew
that
it
was
on.
There
were
several
things
on
the
frontier
at
that
point
in
time,
which
is
about
a
year
and
a
half
ago,
and
it
was
something
like
support
for
getting
context
out
of
our
keys
out
of
the
baggage,
but
but
also
this
idea
that
we
would
want
to
do
exemplars
and
if
you're,
following
the
tracing
side,
I
keep
talking
about
sampling
and
sampling.
D
Stig
it's
been
moving
pretty
pretty
well,
so
I've
I've
been
starting
to
turn
some
of
my
past
studying
of
sampling
onto
tracing,
but
I
also
at
that
time
a
year
and
a
half
ago,
did
prototype
enough
to
get
this
idea
that
you
could
have
probability
sampling
of
metric
events,
and
you
need
the
same
interface.
That
josh
has
been
looking
at
for
the
the
exemplar
interface
and
go
also
has
like
java.
This
bound
instrument
thing,
which
is
for
that
hot
path
performance.
D
I
don't
want
to
lose
it
because
prometheus
has
it
in
all
of
its
sdks.
That
matter
to
us
and
like
josh,
says
it
does
muck
up
that
code
path
where
you're
looking
at
measurement
processor,
because
you
have
this
hot
patch,
where
you've
already
got
your
instrument.
Your
labels
and
you've
got
this
slow
path
where
you
get
your
baggage
labels,
and
you
want
to
look
at
the
exemplars
which
might
want
to
look
at
the
difference
between.
D
We
might
want
to
look
at
the
full
label
set
and
if
you
have
a
hot
path,
where
you're
now
going
through
a
user
interface
called
measurement
processor,
you
have
to
explode
complexity
or
do
simple
things
and
cost
memory.
It
just
creates
a
code
path,
that's
very
complicated
and
I
didn't
get
quite
as
far
as
that.
D
All
especially
not
something
I
could
merge,
but
I
do
remember
like
in
my
pr
notes
to
the
draft
saying
this
is
where
the
probability
sampler
plugs
in
and
where
you
need
to
know
the
number
and
the
context
and
apply
some
math
to
choose
an
example,
and
so
I
see
measurement
processor
as
both
getting
stuff
out
of
baggage,
but
also
implementing
example,
our
reservoirs-
and
I
don't
know
how
to
say
the
minimum
there.
But
I'd
like
to
go.
Do
all
those
things.