►
From YouTube: 2021-11-18 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
C
A
Yeah,
so
my
my
take
is,
if
currently
it's
not
clear-
maybe
it's
fine
from
the
spec
perspective,
but
from
implementation.
I
would
suggest
that
you
make
it
final
for
now
and
later,
if
you
change
that,
allow
people
to
override
it's
an
additional
feature.
B
Yeah
yeah,
that's
what
I
figured.
Can
you
think
of
anything
that
somebody
would
do
if
they
overrided
this,
because,
like
there's
other
things
in
the
spec,
like
we
specify
a
meter
provider
in
the
sdk?
Probably
not
thinking
anybody's
going
to
going
to
subclass
it,
but
this
one.
If
we
think
people
are
going
to
subclass,
I'm
just
curious
what
what
they
would
add
to
it.
Besides,
what
they
get
from
the
periodic
metric
reader
and
from
the
the
one
that
the
pull-based
exporters
use.
A
A
D
That's
so
I
just
want
to
call
out
we
we
did
that
in
the
open
census
library
in
java,
for
the
prototype
for
the
opencensus
bridge,
but
we
actually
have
a
separate
thing
called
a
metric
producer
that
has
a
collect
method
and
symmetric
producer
has
one
single
method
on
it
called
collect
which
grabs
metrics
and
it
does
a
collection
cycle,
and
we
we
have
a
metric
reader
factory
that
takes
in
a
producer.
D
That's
given
the
collect
method,
because
we're
trying
to
hide
the
implementation,
the
collect
method
from
people
and
actually
inheritance
is
not
always
the
safest
way
to
have
binary
compatibility
in
java.
So
like
it
it.
It
was
a
limitation
that
we
had
to
work
around
the
spec,
so
I
think
like
if
we
might
want
to
maybe
clarify
that
a
little
bit
or
some
way,
however,
that
open
census
use
case,
I
fully
expect
we
need
to
provide
a
hook
on
the
sdk
to
provide
these
external
metric
systems
to
have
this
work
correctly.
D
The
way
we
do
it
right
now
in
the
java
prototype
is
not
scalable
across
multiple
readers
and
it's
it's
a
little
bit
awkward
because
you
have
to
hijack
every
single
reader
that
is
ever
registered
to
allow
it
to
also
collect
metrics
from
opencensus.
So
I
understand
what
you're
saying
but
like
in
practice.
I
think
there's
another
thing
that
that
needs
to
exist
that
does
that
metric
producer
component.
D
I
I
think
the
the
collect
method
itself
is
generally
something
that,
like
the
sdk
needs
to
give
to
a
reader
effectively
and
if
it's
like
a
finalized
implementation
or
if
it's
a
separate
interface
whatever,
but
I
think
we
should
definitely
call
out
that
collect
method
should
be
implemented
by
the
sdk
and
that
users
will
not
over
write
it
like.
I
think
we
actually
need
to
specify
that
just
so
we
have
freedom
to
change.
It.
E
But
josh
along
the
lines
of
the
question
so
is,
is
the
intent
for
for
clients,
users
to
be
able
to
implement
their
own
metric
reader
factory.
E
B
And
so
it's
sorry
I
it's
not.
I
don't
understand
why
why
you
need
a
specific
reader
for
prometheus.
C
B
Yeah
so,
like
my
read
of
the
spec,
is
that
you
can
instantiate
this
metric
reader,
which
poll
based
exporters
are
supposed
to
use.
Why?
Wouldn't
that
one
work
with
prometheus.
D
We
so
in
in
java,
prometheus
is
an
extension
of
metric
reader,
the
prometheus
exporter.
It's
not
a
metric
exporter.
It's
actually
a
prometheus
metric
reader
effectively.
C
C
If
that's
the
case,
then
we
are
expanding
greatly,
the
the
amount
of
stuff
that
the
user
can
have
contact
with
like
the
api.
C
E
In
java,
that's
the
case,
so
the
the
packages
are
structured
in
a
way
and
the
classes
are
marked
as
final
or
or
not
final,
such
that
the
ones
that
are
intended
to
be
extended
or
implemented
have
the
appropriate
keywords
in
place
and
the
ones
that
are
are
not
meant
to
be
extended
or
implemented
are
not
accessible.
C
Okay,
yeah,
but.
E
C
Is
if
the
specifications
says
somewhere,
these
must
be
implementable
or
over,
or
we
should
make
it
possible
for
the
user
to
override
this,
and
so
we
omit
that
note
in
the
specification
are
we
implicitly
saying
it
can
be
overwritten
by
the
user?
I'm
I'm
asking
because
it
if,
if
we
are
implicitly
saying
you
can
override
the
user,
can
override
or
can
implement
this
if
they
want,
if
we
don't
say
the
the
contrary,
then
we
are
greatly
expanding
the
stuff
that
the
user
can
have
contact
with.
D
I
I
understand
what
you're
saying,
to
the
extent
that
we
define
interfaces
in
our
specification.
For
the
most
part,
those
are
user
overrideable.
D
D
They
were
intended
to
be
user
overrideable
in
the
sense
of
you
know,
metric
reader
is
a
solution
for
pull
based.
Metric
exporter
is
a
solution
for
push
based
and
those
who
want
to
unify
metric
exporter
for
pull
and
push
are
able
to
do
so.
That's
like
the
intention
of
the
spec.
So
if
we
need
to
make
that
explicitly
clear,
we
should
do
so
you're
concerned
around
like
if
we
open
up
the
door
for
users
to
extend
to
anything,
we've
specified.
D
Does
that
make
the
specs
super
hard
to
implement,
because
we
have
all
these
things
that
users
can
extend.
I
I
think,
if
you
go
look
through
the
spec
I'd
like
to
understand
like
specific
instances
that
you're
worried
about,
because
if
that's
the
case,
we
might
want
to
go.
Look
at
those
interfaces.
To
begin
with,
I'm
not
aware
of
any
interface.
We've
specified
that
if
we
allow
users
to
implement
their
own
version
of
it
would
be
a
problem
specifically
like
the
interfaces
we,
the
the
api
which
we
want
to
allow
multiple
sdk
implementations.
D
C
So
my
question
goes
goes
that
way,
so
I
I
want
to
know
if
we
need
to
pretty
much
assume
that
that
everything
that
is
defined
in
the
metrics
sdk
is
also
an
interface
that
we
also
need
to
make
safe
or
not
so
so
pretty
much.
That
is
my
question.
Do
we
should
we
assume
that
everything
that
is
in
the
in
the
sdk
document
of
the
metrics
specification
is
also
an
api
or
not.
A
Maybe
there
there's
one
one
thing
I
I'd
like
to
clarify.
I
I
think
the
spike
we
called
out
some
something
their
their
interfaces,
and
I,
I
think
we're
only
seeing
the
interfaces
are
the
extension
point
and
the
fact
that
if
the
interface
also
has
some
implementation,
like
the
clock
in
this
case,
we
should
call
it
that
this
one
is
not
supposed
to
be
like,
like
implemented
by
the
user,
and
so
what
you
mentioned.
It
seems
like
you're
talking
about
something
that
is
not
interface
as
well.
Right.
C
Also
interfaces
because
if,
if
there
is
something
that
is
an
interface
and
the
user
can
implement,
then
the
user
can
create
something
from
it
by
subclassing
and
that
thing
that
is
created
must
be
made
safe
as
well.
So.
D
C
There
is
a
requirement
to
speak
about
very
handy
right
that
stuff
and
an
error
that
happens
when
running
token
delimiter
code
should
not
must
not
crash
the
application.
So
what
we're
trying
to
do
is
to
make
safe
the
code
that
the
user
has
contact
with,
for
example,
the
user
may
have
may
can
create
a
trace
right
or
create
a
tracer
provider
by
invoking
a
mirror
provider.
C
C
Is
it's
important
to
know
what
is
something
that
the
user
is
expected
to
have
contact
with,
in
the
sense
that
they
can
import
it
or
use
it
in
their
own
code
right,
so
that
we
know
that
that
thing
must
be
made
safe
because
the
user
will
have
contact
with
it.
C
So
what
what
I'm
trying
to
understand
now
is
if
the
objects
that
are
defined
in
the
sdk
specification
for
metrics
are
something
that
are
also
that
are
stuff,
that
we
should
assume
them
to
also
be
interfaces,
something
that
the
user
can
by
can
import
or
use
directly
or
not,
because,
depending
on
that,
we
need
to
know
if
we
must
make
that
safe
or
not.
C
Just
imagine
that
we
pretty
much
wrap
the
methods
that
the
tracer
provider
has
in
a
try
right
so
that
it
catches
any
exception
that
happens
running
that,
if
an
exception
happens,
we
follow
some
procedure
to
handle
that
and
make
it
safe
right.
C
Right,
yeah:
well
it
that
is
an
implementation
detail.
We
could
make
that
happen
in
the
api
and
then
use
use
the
api
object
as
a
proxy
for
the
sdk
object.
That
is
underlying
so
that
different
exception
is
raised
by
the
sdk
object.
Then
it's
caught
by
the
api
proxy,
but
that
that
is
more
an
implementation
detail
on
how
the
the
the
safety
mechanism
will
work.
C
What
is
more
important
is
for
us
to
know
what
is
expect
is
expected
to
be
accessible
by
the
user
and
and
what
is
not
so
that
we
we
can
know
okay,
this
needs
to
be
made
safely.
It's
not
may
say.
A
So
diago,
if
I
could
suggest,
maybe
we
should
take
this
offline,
and
would
you
follow
an
issue
to
describe
the
general
problem
and
then
provide
a
very
concrete
example
saying
you're
facing
this
difficulty?
You
have
option
a
and
b
and
with
the
spike
written
in
the
current
way.
You
don't
know
how
to
resolve
that.
That
would
be
helpful.
A
I
I
think
the
periodic
one
will
give
you
the
the
by
default
behavior,
that
it
has
some
like
periodic
tasks,
but
there
are
specific
case
where
the
user
might
want
to
call
flash
explicitly
and
this
clock
allows
the
provider
to
to
implement
the
force
flash.
So
imagine
if
you
have
a
periodic
reader
you're
saying
I
want
to
push
the
metrics
every
one
hour,
but
then
the
application
is
running
for
one
hour
and
30
minutes
and
they
decided
to
exit.
A
D
So
riley
this
is
a.
This
is
a
different
thing,
so
flush
is
public.
Close
is
public.
This
is
like,
if
I'm
a
periodic
metric
reader,
and
I
have
a
thread
that
wakes
up
and
calls
collect
and
collect,
is
publicly
exposed
on
metric
reader.
That
means
some
other
person
can
call
my
collect
on
periodic
metric
reader,
yeah
and.
D
And
those
delta
metrics
get
collected
by
whoever
the
hell,
that
is,
they
do
whatever
they
want,
because
it's
a
public
method
and
the
underlying
exporter
doesn't
see
them.
I
think
that's!
That's
specifically
what
this
is.
So
this
is
like
a
periodic
metric
reader
reading
and
collecting
and
talking
to
an
exporter,
and
then
I
have
some
external,
like
malicious
agent,
possibly
calling
collect
on
my
periodic
exporter
and
they're
grabbing
those
metrics,
those
delta
metrics
and
putting
them
somewhere
else.
But
then
my
exporter
never
sees
those
metrics.
This
is
kind
of
a
weird
audi
again.
D
A
D
B
D
B
Ahead,
aaron
you're,
the
one
that's
looking
into
it.
Well,
maybe
we
can
just
check
here.
B
B
B
B
A
A
B
Josh,
I
think
I
think
that
would
mess
up
what
you
described
for
the
prometheus
reader
right.
D
If
somebody
external
to
prometheus
called
collect
yeah,
we
do
have
a
problem.
The
only
benefit
is
prometheus
is
just
a
cumulative
reader.
So
if
we
had
something
like
prometheus,
that
was
a
delta
reader.
That
would
be
interesting.
A
Yeah
and
I
can
share
in
the
donated
implementation
when
people
call
the
collect,
we
actually
have
an
understanding
during
the
configuration
time.
B
Yeah,
I
think
I
see
what
you
mean.
That's
just
not
at
all
what
I
got
when
I
was
reading
the
spec
and
I
I
could
see
how
you
could
implement
that,
though
that
does
make
sense.
So,
basically,
when
you
create
the
metric
reader,
you
would
have
to
give
it
sort
of
the
thing
to
send
metrics
to
regardless
if
it's
push
or
pull
right,
yeah.
A
Yeah,
yeah
and-
and
here
I
I
think,
different
language-
they
have
a
different
way
of
how
to
model
this,
especially
the
tricky
part,
is
on
the
premises
exporter.
I
think
the
javascript
decided
to
model
that
not
as
an
exporter
inside
the
user
reader
model.
So
this
is
where
we
give
the
flexibility
and
it
seems
in
python.
You
were
simply
looking
for
something
that
you
can
just
translate
the
english
into
the
code,
and
it's
not
there,
because
if
we
put
it
there,
it
would
make
the
java
implementation
invalid
right
right.
A
B
Yeah
that
could
work,
I
think,
possibly
also
my
confusion.
Just
came
from
the
name
reader,
so
I
was
sort
of
assuming
it
was
like
a
thing
that
you
can
read,
call
like
a
read
method
and
get
sort
of.
B
A
A
You're
basically
triggering
clocks
and
you
will
trigger
the
the
callback
functions
and
they
won't
change
the
result.
If
you
call
a
clock,
then
you
call
another
collect.
The
result
will
be
different.
Comparing
to
you
call
a
single
clock,
because
the
the
fact
that
you're
observing
something
is
changing
the
state,
especially
for
the
delta
situation,.
B
Yeah,
no,
I
think
I
think
what
you're
saying
makes
sense.
I
just
didn't
interpret
it
that
way,
so
I
think
maybe
the
examples
you're
proposing
would
would
fix
this
yeah.
A
A
B
Yeah,
so
that
makes
sense,
I
think
one
other
question
that
that
raises
is
if
the
collection
will
call
sort
of
whatever
you
pass
into
it,
what
what
happens
with
shutdown,
because
it
won't
call
shutdown
on
the
exporter.
You
give
it,
for
instance,
right
because
that's
the
the
meter
provider's
responsibility.
B
A
B
Okay,
all
right,
let
me
read
through
the
spec
again,
because
I
sort
of
understood
it
as
that
was
an
error,
but
that
makes
sense
as
well.
A
Yeah,
so
I'm
pretty
sure
like,
like
shut
down
force.
Flash
those
functions
can
be
called
concurrently
as
many
times
as
you
want,
but
there
the
the
only
requirement
is
once
shut
down
is
finished.
Any
subsequent
call
to
force
flash
and
shutdown
would
be
no
up.
If
you
can
and-
and
it
is
not
a
must,
it
is
a
shoot
because
in
some
highly
concurrent
situations
it's
very
hard
to
define
a
strict
behavior.
D
D
And
if
I
call
flush,
is
there
like
a
sdk,
wide
flush
method?
If
I
remember
right
and
that
calls
collect
on
readers.
A
C
D
Right
right
right,
I
know,
I
know
that's
to
match
tracing,
because
tracing
has
a
flush
method.
We
wanted
to
match
the
java
force
flush
for
both
of
those.
I
I
I'm
wondering,
because
we
still
have
some
time
here.
D
It
just
it,
it
feels
weird
for
me
to
have
flush,
call,
collect,
call
flush,
but
maybe
that's
not
important
enough.
D
Like
I
know,
java
deviates
here
and
that's
fine,
I'm
just
curious
if,
if
that's
part
of
the
confusion
here,
because
the
meaning
of
collect
you
know
it,
has
this
active,
give
me
metrics
right
now
thing
as
opposed
to
this
notion
of
like
flush,
which
is
hey,
go
grab,
metrics
and
export
them
right.
D
I
don't
know
anyway,
I
think
if
we,
if,
if
we
shore
this
up
and
whatever
whatever
we
do
to
kind
of
clear
up,
the
description
could
help
a
lot.
But
this
is
an
area
in
the
spec
that
trips
a
lot
of
people
up,
and
you
know
riley
you-
and
I
talked
a
lot
about
this
initially
too-
to
do
the
java
implementation.
So
I
do
think
it's
worth
cleaning
up
this
language
at
a
minimum.
A
So
maybe
we
can,
we
can
quickly
talk
about
what's
the
potential
outcome.
So
maybe
one
thing
is
we
added
some
clarification
here
just
to
describe
a
flow
or
maybe
another
outcome
is
we
just
unify
on
the
same
term,
which
I
I
think
will
be
hard
because
flash
it
seems
you
already
got
something
you
just
have
to
flash
it.
Well.
Clock
has
additional
meaning,
like
I
wouldn't
expect
flash
to
have
a
side
effect,
but
but
we
already
have
that
in
the
provider
like
meteor
provider
force,
flash
for
delta
has
side
effect.
D
I
I
mean
flush
has
side
effects
for
traces
too.
The
side
effect
is
your
cube's
flushed
right.
So
it's
like
all
my
pending
measurements
are
flushed.
That's
that
I
think
that's
a
reasonable
side
effect
and
the
implication
would
be
that
you
have
to
collect
metrics.
The
weird
the
bit
that
I
agree
with
totally
is
the
fact
that
flush
would
call
async
instruments,
because
that
doesn't
that
doesn't
feel
like
a
flush
but
for
sync
instruments:
the
fact
that
it
takes
all
the
pending
measurements
and
flushes
them
out.
I
think
that
makes
sense
but
yeah.
D
I
don't
have
strong
feelings
on
naming
and
I'm
terrible
at
naming
as
everyone
who's
worked
with
me
knows.
I
just
think
this
is
an
area
that
people
get
confused
over,
so
we
should.
We
should
spend
some
time
either
documenting
or
whatever.
That's
that's.
That's
my
main
concern.
So
maybe
aaron.
If
you
raise
this,
if
you
have
suggestions,
that'd
be
ideal,
but
whatever
happens
here,
I'm
happy
with.
I
just
think
we're
probably
gonna.
G
D
A
It
seems
to
be
more
than
what
I
can
handle
so
so
maybe
if
some
of
you
can
volunteer,
you
can
handle
some
some
issue
here
in
the
pr.
Please.
A
H
B
Yeah
this
is
the
last
one
I
opened.
Let
me
take
a
read.
A
D
A
B
Right,
I
think
I
think
the
confusion
here
is,
if
you
don't
pass
a
name,
it
only
works,
because
the
default
behavior
is
that
the
view
name
comes
from
the
instrument
right
right,
whereas
somebody
might
expect
like
one
of
two
things,
for
instance
like
if
I
target
all
all
of
like
a
specific
counter,
like
I
don't
know,
say
a
request
count
or
something
like
that-
that
it
will
add
all
of
them
together
into
a
single
metric
like
somebody
might
expect
that
or
they
might
expect.
B
A
A
B
A
B
Sorry,
I
I
guess
maybe
I'm
just
not
I'm
not
reading
the
spec
as
like
normatively
as
I
should,
maybe
because
I
I
sort
of
skip
that
conflict
part
and
I
figured
the
conflict
was
more
like
you
do
something.
That's
like
you,
try
to
set
a
counter
for
a
down
counter
or
like
a
monotonic,
something
or
something.
A
I
I
see
so
so,
maybe
so
maybe
you
can
read
it
again
and
you
see
like
if
there's
a
potential
to
make
some
like
improvement.
You
comment
in
the
issue
and
you
ping
me
on
the
issue
I'll
I'll
see.
Maybe
we
can
add
some
example
here
just
to
help
people
to
understand
it
better.
A
I
I
think,
there's
another
issue.
We
should
talk
about
the
example
should
that
be
enabled
by
default
or
not
so
so
far.
It
seems
many
folks
are
saying
a
lot
of
metrics
backhand
do
not
support
example
and
the
popular
one
which
support
exemplar
is
permitted
and
that's
an
off
by
default
feature.
So
you
have
to
use
some
specific
flag
to
ask
for
it
and
it
requires
you
to
switch
from
the
permissive
text
format
protocol
to
the
open,
metrics
protocol.
Something
like
that.
A
D
D
D
You're
right
that
for
the
back
end
to
support
exemplars,
you
have
to
turn
it
on
with
this
experiment
that
they're
working
on
and
it's
still
kind
of
coming
into
play,
but
I
think,
in
terms
of
the
long-term
interest
of
open
telemetry
around
correlated
telemetry,
this
is
a
feature
we
should
push
on
in
terms
of
overhead
it.
There
is
no
overhead
in
the
general
path,
for
example
our
sampling,
unless
you're
tracing
right
or
there
should
be
very,
very,
very
minimal
overhead.
D
So
I
definitely
think
that
basically
there's
two
things
I
think
should
be
true:
one
is
exemplar.
Sampling
should
be
tied
to
tracing
effectively
those
those
that's
something
that
is
new
and
open
telemetry.
That's
not
necessarily
true.
In
other
example,
our
samplers,
where
it's
just
for
all
measurements.
So
the
default
is
not
sample
all
the
time
the
default
is
sample
with
trace
and
that's
different
than
default
on,
and
it's
different
than
default
off.
So
I
think
that
that,
as
a
default,
I
just
want
to
call
that
out
that
that's
what
it
is.
D
E
Hey
josh,
what
happens
if
you
have
exemplars
being
emitted,
be
via
a
prometheus
exporter
and
someone
hasn't
turned
on
exemplar
support
and
prometheus.
D
It
should
be
ignored,
it
should
be
covered,
yeah
yeah.
We
actually,
I
don't
know
if
you
saw
the
request
to
java
to
like
how
do
I
get
my
exemplars
working
from.
B
D
Yeah
so
yeah
it!
So
if
you,
if
you
have
the
mod
it
should
be
ignored.
We
found
a
bug,
though,
where
you
can't
report
exemplars
in
prometheus
against
sums
or
gauges,
which
makes
sense
to
some
extent,
even
though
the
prometheus
client
library
allows
it.
So
that's
it.
We
might
have
to
run
through
some
some
interesting
times
initially,
but
if
you're
only
exposing
exemplars
against
the
histogram
metric
families,
you
should
be
totally
fine.
A
Gosh,
I
have
a
question
regarding
performance,
so
I
I
agree
with
the
overall
direction
like
in
the
future.
I
I
think
matrix
traces
correlation
by
default.
It
seems
like
the
industry
trend
and
we
we
should.
We
should
do
it.
My
question
is
more
about
implementation.
Detail
so
think
about
the
matrix
system
is
already
running
in
open
telemetry
and
the
tracing
feature
is
not
enabled
and
it
can
enable
at
runtime
right.
So
after
running
for
five
minutes,
all
of
a
sudden,
someone
decided,
okay,
I'm
going
to
turn
on
something
and
enable
the
trace
provider.
D
Yeah
so
effectively
what
what
the
proposal
on
exemplar
sampling
is.
Is
you
you
allocate
the
memory
overhead
for
exemplars,
but
you
don't
take
the
runtime
collection
cost
until
you
actually
see
sample
traces
in
terms
of
dynamic
configuration.
That's
actually
a
really
good
question,
because
that's
not
a
concern
for
java,
since
they
don't
allow
it.
D
So
basically
you
always
have
exemplar,
so
you
never
have
exemplars.
So
if
we
anyway,
what
I,
what
I'd
suggest
in
in
that
case
again
with
histograms,
if
you
look
at
the
cost
of
calculating
histograms
in
terms
of
memory
footprint
and
everything,
adding
in
exemplars,
is
not
a
significant
ask,
because
it's
very
similar
to
bucket
strategies-
and
I
I'd
say
that
like
again
to
me
at
a
minimum-
that's
what
we
should
have
out
of
the
box,
especially
around
latency,
because
latency
and
tracing
are
highly
correlated.
D
I
think
that
is,
that
is
the
killer
right.
I
also
think
we
should
do
exemplar
sampling
by
default
everywhere,
but
I
I
don't
I'm
not
going
to
hang
on
that
horse.
That's
that's
fine!
If
people
don't
feel
that
way,
when
we
looked
at
the
implementation
of
exemplars
in
java,
it's
not
it's
not
a
lot
of
overhead,
especially
especially
when
you
tie
it
to
trace
sampling.
D
It's
if
you
turn
it
off.
If
you
turn
off
the,
if
you
use
the
filter
to
control
it,
it
was
zero
overhead
and
if
you
add
in
the
with
trace
sampler-
and
we
do
worst
case
scenario
of
100
tracing.
D
It
was,
it
was
like
10,
nanoseconds
or
something
it
wasn't
like.
It
wasn't
a
huge
lift.
So
I
think
what
I'd
like
to
see
examples
of
where
it
is
super
expensive
and
I
think,
in
a
lot
of
those
cases,
people
should
be
probably
doing
more
fine-grained
control
of
traces
and
exemplars
in
in
that
case,
but
yeah.
If
folks
want
to
turn
it
off.
D
Basically,
here's
here's
my
assumption
right
folks
who
only
care
about
metrics,
won't
have
exemplars
out
of
the
box
it
just.
They
won't
show
up
folks
who
care
about
tracing
and
metrics
will
get
really
nice
histogram
support
with
exemplars
out
of
the
box,
and
I
think
that
is
a
killer
feature
we
need
to
preserve
and
then,
if
you
are
an
advanced
tracing
user
and
the
exemplars
are
actually
a
performance
liability,
it's
easy
to
flip
them
all
off.
D
So
that
that's.
Why
that's
why
the
the
spec
was
designed
around
this
as
a
proposal
if
we
really
are
uncomfortable
with
that?
That's
fine,
but
I
think
I
don't
want
to
overreact,
and
I
know
for
a
fact
that
we
have
prometheus
users
asking
for
exemplars
from
us.
Examples
are
hard
to
do
outside
of
open
telemetry.
A
I
see
it
anyway,
so
quick
question.
I
I
I
think
so
far
the
major
concern
around
this
is
number
one
you
spend
for
the
collection
cost
and
most
of
the
back
end
today
doesn't
even
support
that.
So
you
you
burn.
The
cpu
cycle
then
drop
the
data
on
the
floor.
I
think
josh
explained
that
well,
so
it's
not
a
significant
cost
and
it's
more
like
forward-looking.
E
D
E
D
A
A
Anything
can
be
turned
on
at
runtime,
so
you
can
have
a
metric
system
running
for
five
minutes
without
tracing
and
all
of
a
sudden
tracing
got
enabled,
and
I
have
some
idea
how
to
make
that
efficient.
I
think
the
current
challenge
cjo
is
facing
is
in
order
to
do
that
he's
doing
the
check
for
every
single
measurement
like
when
people
report
the
measurement
it's
going
to
check
hey.
Do
I
have
a
do.
I
have
a
trace
id
spam
id
in
the
contacts
and
that
is
very
slow.
A
Although
the
operation
itself
is
fast,
but
thinking
about
for
metrics.
On
my
laptop
like
four
years
old,
I
can,
I
can
run
10
million
measurements
per
second
today
with
open
telemetry.net
and
by
adding
that
check.
Maybe
I'm
I'm
giving
up.
3
million
per
second
cost.
That's
a
lot.
So
what
I'm
thinking
is.
Maybe
we
can
have
some
some
global
flag
and
we
can
check
the
periodically
so
by
default
it
is
off
and
when
the
tracing
system
is
on,
we
turn
that
flag
to
and
that's
a
single
global
static
thing.
A
The
metric
system
kind
of
oh
someone
enabled
that
so
I'm
going
to
change
the
behavior.
That
should
be
much
faster
than
checking
the
the
contacts.
Although
there
might
be
some
in
accuracy,
don't
expect
you
turn
on
the
feature
and
all
of
a
sudden
immediately
you
got
the
correlation,
maybe
after
a
few
milliseconds
and
that's
probably
okay,.
D
Yeah,
in
fact,
in
addition,
preserving
exemplars
is
best
effort
if
you're
under
memory
pressure
and
you
need
to
drop
data
or
memory,
dropping
exemplars
is
totally
fine.
That
is,
that
is
absolutely
loud.
These
are
best
effort,
they're
really
nice
for
users
who
need
to
diagnose
like
a
sample,
99th
percentile
problem.
But
if
you
need
to
drop
them,
you
should
be
willing
to
drop
them
in
your
sdk.
So
in
that
same
vein,
if
it
takes
you
a
while
to
propagate
the
change,
that
should
be
totally
fine
too.
A
A
Okay,
so
I'll
I'll
do
a
prototype
and
respond
to
this
issue,
and
hopefully
we
can.
We
can
close
on
that
based
on
the
feedback,
but
if
anyone
else,
if
you
work
on
different
language,
you
see
the
concern
whether
it's
like.
Why
do
I
spend
the
cost
if
I
got
nothing
by
default
or
you
think
it's
just
hard
to
implement?
Please
please
comment
here.
D
I'm
also
happy
to
help
with
implementations
and
mine
is
slightly
based
on
the
prometheus
client
library.
So
I
also
highly
recommend
looking
at
that
for
your
language.
If
you
haven't.
H
A
For
the
prs,
I
think
the
ask
is
very
simple.
So
currently
we
focus
on
the
pr's
that
are
that
have
the
metrics
tag,
but
not
have
the
semantic
conventions
tag.
There
might
be
a
caveat
like
if
someone
open
api,
that's
trying
to
address
both
the
ick
and
semantic
combination,
but
I
I
try
to
look
like
a
wrong
for
the
history.
That's
not
the
case.
So
so.
Please
use
this
link
and
and
how
to
review
the
pull
request
and
you
think
it
like,
especially
for
for
two
jobs,
because
you
have
the
merge
permission.
A
If
you
think
that
it
is
ready,
it
got
enough
discussion
and
there
is
a
consensus.
We
should
move
that
fast
as
fast
as
possible
and
and
for
the
pr
we
can.
We
can
take
offline
if
we
still
have
few
minutes.
We
can
finish
the
meeting
earlier
and
please
look
at
the
pr
one.
Last
thing
I
want
to
ask
I'll
be
gone
for
the
entire
december
and
based
on
our
original
plan,
we're
saying
we
want
to
get
the
metrics
down
by
a
novice
like
this
month
so
by
november.
A
The
third
is,
we
should
be
able
to
get
the
metrics
sdk
stable.
I
figured
there's
still
a
lot
of
things
we
need
to
do,
especially
there.
There
are
more
feedback
work
guiding,
so
I'm
not
sure
if
we're
able
to
hit
that,
but
I'll
I'll
try
to
push
for
it.
So
what
I'm
going
to
do
is
I'll
send
the
pr
to
propose
and
market
sdk
spec
high
stable,
and
I
I
expect
there
will
be
some
some
more
issues
coming
I'll.
A
F
I
need
to
remind
myself
what
stable
means
exactly,
but
looking
at
the
prs
that
are
in
front
of
us,
I
felt
like
the
first.
Two
of
them
were
fairly
easy
to
get
merged,
but
the
third
one
seem
to
have
disagreement
and
lingering
unresolved
comments.
How
can
you
comment
on
what
you
think
we
should
do.
A
Okay,
so
my
suggestion
is
we
at
least
we
hyper
focus
on
getting
the
sdk
spike
stable
for
the
premises,
exporter
and
other
exporter.
We
try
our
best
if
like
if
the
ist
and
the
premises
can
get
too
stable
at
the
same
time
awesome,
but
the
minimum
bar
is.
We
try
to
prioritize
to
get
the
sdk
part
stable
the
premises.
One
can
stay
as
a
feature
freeze
or
even
experimental.
If
you
think
we
need
more
time.
D
Okay,
let's
let
let's
go
even
more
aggressive,
the
the
even
the
discussions
we
had
today.
D
We
entertained
changing
the
sdk
a
little
bit,
but
we
ended
up
just
saying
that
we
needed
to
resolve
the
specification
to
make
it
more
clear
if
we
actually
think
we're
going
to
be
changing
the
sdk
itself
in
any
of
the
issues
that
we've
seen
so
far.
I'd
be
curious,
but
I
want
to
hear
more
implementation
things
because
I
don't
see
that
necessarily
happening,
I
think,
maybe
in
if
we
can
in
december.
D
A
And
also
think
about,
even
if
the
permissive
spike
and
the
exporter
is
a
beta
version
or
like
a
feature
freeze
like
not
stable
version,
I
still
imagine
that
people
can
use
it
and
even
if
there's
changes
it
shouldn't
require
them
to
change
a
lot
of
code.
It's
probably
like
zero
line
of
code
change.
Just
take
the
latest
version.
Recompile
you're
done.
A
Well,
compared
to
the
sdk,
if
the
isdk
would
expect
another
big
change,
we
would
ask
many
languages
to
redo
their
work,
like
I
think,
that's
not
the
case.
So
far,
the
like
there
hasn't
been
so
many
issues,
but
all
the
issues
being
reported.
They
asked
for
additional
clarification
and
it's
it's
something
we
sort
of
decided
before
we
gave
the
freedom
now
we're
saying
people.
People
need
more
clarity,
so
we're
trying
to
be
helpful
by
providing
examples.
That's
all
we
do.
We
don't
try
to
say
okay,
but
there's
something
wrong
in
the
ick.