►
From YouTube: 2021-06-17 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).
C
A
B
B
C
A
Okay,
let's
start
so
first,
I
want
to
give
people
heads
up.
We
discussed
this
in
the
tuesday
meeting
this
week,
but
previously
we
decided
to
split
the
data
model
and
the
api
sdk
spec
into
separate
meetings,
just
to
be
able
to
focus
on
individual
thing,
because
at
that
time
there
are
too
many
things.
A
But
now
things
are
making
great
progress,
so
we
decided
to
merge
them
back.
Existing
meeting
slots
will
remain
the
same,
but
we'll
report
her
that,
instead
of
focusing
specifically
on
api,
sdk
or
data
model,
will
make
it
generic.
So
third,
like,
for
example,
like
30
minutes
on
the
api
sdk,
then
30
minutes
on
the
data
model,
and
if
we
could
finish
one
part,
then
we
can
reserve
more
time
for
the
other
topic.
A
So
I
want
to
give
people
heads
up
in
this
meeting
we're
we're
only
going
to
focus
on
api
sdk
this
week,
but
starting
from
next
week,
we'll
we'll
also
invite
the
data
model
folks
and
cover
the
topic
so
josh
suraj
from
google,
and
I
will
will
run
both
meetings
I'll
make
the
update
right
after
this
meeting.
So
the
other
folks
subscribing
to
the
calendar
and
the
community
readme
page,
will
get
the
update.
B
Does
this
mean
that
the
data
model
meeting
it
will
be.
A
Discontinued,
like
the
all,
the
existing
meetings
will
still
be
there.
We're
not
we're
not
going
to
remove
any
meetings,
but
we're
going
to
change
the
change
the
agenda,
so
both
meetings
will
cover
api,
sdk
and
data
model,
so
that
gave
us
yeah.
This
helped
us
to
accelerate.
If
we
have
some
topic
on
tuesday,
we
can
follow
up,
and
then
we
can
come
back
on
thursday
and
we
have
something
model
issue
we
talk
on
thursday.
We
can
come
back
on
next
tuesday
get
it.
B
Could
you
please,
then
like
rename,
like
both
of
the
meetings.
B
A
Exactly
thank
you.
This
is
just
hats
off.
I
will
update
all
the
places
like
the
meeting
notes
here,
the
calendar
and
the
community
page
right
after
this,
because
I
don't
want
to
update
before
the
meeting.
Otherwise
it
confused
people
when
you
join
this
meeting
today.
So
just
heads
up
and-
and
I
have
a
couple
topics
here-
if
you
have
more
topics,
please
append
them
later,
so
we'll
talk
about
them
one
by
one.
A
So
I
have
a
couple
prs.
I
want
to
quickly
go
through
them,
so
this
one
is
a
very
small
pr.
I
treat
this
as
a
bug
fix.
So
previously
I
was
trying
to
say
the
unit
is
a
is
a
eight
by
eight
bytes
integers.
What
I
really
mean
is
not
a
single
integer.
You
can
compare
that
as
an
array
of
integers,
but
it
seems
to
be
causing
some
confusion.
So
now
I
try
to
change
the
world.
A
It
should
be
a
very
straightforward
thing,
so
please
help
me
to
reveal
that
currently
I
haven't
received
any
review
comments,
so
the
second
part
is
about
hiddenview.
So
currently
I
have
two
pr's,
because
initially
I
was
thinking
we
should
start
from
the
view
and
take
the
learning
and
put
back
to
the
hint
and
now
there
seems
to
be
a
lot
of
discussion
and
I,
I
think
the
biggest
issue
I've
seen
is
like
from
yuri
and
from
from,
like
several
folks
like
doing
the
prototype.
A
I
I
think
they
they
don't
like
the
name,
hidden
kind
of
view,
and-
and
personally
I
can't
understand
it's
like
the
first
time.
I
remember
I've
seen
hint
and
view
are
coming
from
sql
database.
You
give
the
indexer
hint
and
then
you
define
multiple
views,
so
they
were
basically
saying
all
these
things
are
configuration.
Can
we
just
call
that
configuration
because
they
worried
about
the
user
like
becoming
a
database
and
administrator?
A
Requires
you
to
read
a
very
thick
book
to
understand
all
these
concepts,
but
they
want
to
make
it
simple,
so
the
ask
is:
can
we
make
that
configuration,
and
I,
I
think,
that's
a
reasonable
thing
from
the
user
perspective?
I
want
to
explore
that
and
see
what
are
the
take
from
folks
here.
I
personally
want
to
try
this
and
I
have
some
questions.
So
the
first
question
I
have
is:
if
you
have
one
instrument,
you
might
have
multiple
views.
A
A
Everything
is
configuration,
so
the
user
will
be
confused.
Hey
I'm
I'm
specifying
this
configuration
to
turn
this
into
a
histogram,
and
how
do
I
do
that
by
keeping
the
existing
counter
so
having
view,
I
think
it's
easier
for
people
to
distinguish
that,
but
meanwhile
it
seems
to
be
a
scary
thing
and
people
in
general
don't
like
the
idea.
So
I
wonder
if
we
call
that
configuration,
do
you
see
a
downside
or
it's
a
show
stopper.
A
I
personally
think
it's
not
a
show
stopper
and
the
only
downside
I
can
see
is
we
call
that
configuration
when
people
try
to
search
something
it's
a
very
generic
term,
so
the
documentation
part
will
probably
need
to
better
organize
it.
But
besides
that,
I
I
think
it's
fine
and
I
want
to
take
a
step
unless
someone
here,
you
try
to
stop
me
and
tell
me
this
is
crazy.
We
should
stick
with
you.
B
I'm
not
sure
about
the
view,
but
about
the
hint.
I
might
have
a
suggestion
to
work
this
around
or
maybe
make
this
a
little
bit
simpler,
which
is
like
what,
if,
instead
of
using
the
hint
you
would
be
able
to
like
flat
this
out
and
set
all
of
those
like
additional
configuration
details
on
the
instrument
or
on
the
meter.
B
E
Abstraction
I
I
want
to
double
down
on
that.
I
think,
since
our
instrument
is
called
histogram,
it
should
allow
us
to
specify
buckets
right
when
you
instantiate
it
like
it
it
that
just
feels
like
the
most
natural
place,
to
put
it
and
having
implemented
histogram
now
in
java.
It
is
incredibly
awkward
to
put
it
anywhere
else,
and
we
can.
We
can
talk
about
that,
but
I
I
my
fear
is:
if
we
don't
put
it
right
there,
the
person
who's
instrumenting.
E
So
if
we
force
explicit
buckets
on
this
histogram
instrument
right,
let's
talk
about
like
we've
been
talking
about
other
types
of
histograms,
I
think
that
would
be
a
different
instrument,
but
like
for
this
histogram
instrument
right
now,
it
forces
explicit
buckets.
If
we
don't
allow
the
person
instrumenting
to
decide
on
those
buckets
which
is
the
right
person
for
the
current
histogram,
we
have
no,
you
disagree
josh.
I.
E
I
at
this
point
in
time
I
think
the
best
the
most
likely
person
to
get
it
right
is
the
person
running
the
instrumentation,
not
the
person,
configuring
the
sdk,
if
we
think
about,
if
we
think
about
those
two
users,
just
those
two
users,
not
even
the
ops
person,
the
person
configuring,
the
sdk
is
just
trying
to
get
the
metrics
data
out
right.
The
person
who
wrote
the
instrumentation
is
more
likely
to
understand
what
that
histogram
is
measuring
and
the
distribution
of
it
than
the
person
who's
configuring,
the
sdk
for
export.
E
B
I
I
I
believe
both
can
both
can
be
true
right.
So,
for
example,
if
I
am
doing
some
like
instrumentation
on
my
code
or
my
library,
I
might
have
like
a
better
idea.
What
would
like
be
the
value
of
certain
configurations?
B
For
example,
I
don't
know,
I'm
writing
an
initially
client.
I
want
to
add
this
and
this
and
this,
but
on
the
other
side
I
believe
there
are
values
which
should
be
like
set
or
able
to
override
by
an
operator
who,
for
example,
will
be,
will
know
that
the
I
don't
know
for
this
histogram,
the
maximum
value,
so
the
last
bucket
should
not
be
higher
than
than
this.
B
So
I
believe
both
are
are
valid
scenarios,
though
to
me,
it
still
feels
that
then
we
can
set
these
like
on
the
instrument
side,
which
that
that
should
be
okay,
because
relator,
we
can
basically
like
reconfigure
this
on
the
sdk.
E
E
We
we
want
somebody
to
configure
it
and
guarantee,
there's
a
configuration
for
for
what
those
buckets
are
for
all
histograms,
because
they're
all
different
and
to
the
extent
that
we
want
ops
to
be
able
to
override
instrumenter.
That's
fine,
but
I
don't
think
we
can
rely
on
a
default
instrument
bucket
selection
with
explicit
buckets.
Those
two
things
are
just
incongruous.
E
Okay,
except
today
we
have
explicit
pockets
like,
but
practically
right.
We
don't
have
any
other
kind
of
bucketing
strategy,
and
so,
if
we're
going
to
force
explicit
buckets,
we
need
to
make
sure
like
I,
I
just
don't
think
we
can
realistically
put
a
default
yeah.
So
until
there's
a
future
where
we're
not
using
explicit
buckets
well.
C
E
E
C
It
just
feels
like
you're
letting
a
protocol
roadblock
turn
into
an
api
question
which
doesn't
feel
quite
right
like
like
the
existence
of
dd
sketch
and
circle
hist
it
opened,
which
is
now
open,
histogram.
You
know
and
there's
a
conversation
about
that
which
I
don't
want
to
interrupt
this
one
to
have.
But
you
know
it's
like
it's
ready
to
go
she's,
having
trouble
disagreeing
on
things.
A
So,
okay
concerns
here
number
one
is,
I
I
think
when
we
talk
about
the
hint
bucket
is
just
one
example,
and
we
probably
also
want
the
library
owner
to
tell
people
what's
the
recommended
default
dimensions
instead
of
taking
all
the
attributes.
So
I
have
a
fair
that
if
we
do
something
like
this,
we
require
buckets
as
a
parameter.
Then
what
about
the
suggested
attributes?
Are
we
going
to
have
something
like
suggested
attribute
names,
something
like
this
and
later?
A
A
A
Very
slow
and
later
we'll
add
full
bar,
so
this
is
something
I
want
to
avoid
and
inside
I
I
think
what
we
should
have.
I
totally
agree
it
should
be
part
of
the
instrumentation.
But
what
I
think
is
here:
we
have
a
single
thing
called
hint
or
configuration
or
whatever
name
we
have
and
and
we're
bad
at
naming
things.
A
But
but
here
is
a
single
thing
and
that
thing
can
be
flexible
and
people
can
extend
that
and
also
they're
asked
that
vendors
want
to
extend
that,
for
example,
there
could
be
new
relic
without
some
additional
thing.
They
might
have
a
specific
sketch
or
something
they
can
put
additional
hint.
So
that
gives
people
flexibility
and
and
whether
we
call
that
hidden
her
configuration
doesn't
matter,
but
one
key
here
is
it
it's
the
best
effort
and
the
actual
implementation.
The
isdk
exporter
can
potentially
decide.
B
F
B
With
a
ton
of
arguments,
instead
of
that,
you
would
have
like
a
default
one
which
that
contains
only
like
a
few
options,
like
name
unit
and
whatever
like
description,
and
there
is
another
way
how
you
can
create
instruments,
which
is
basically
a
builder
where
you
can
configure
all
of
these
different
things.
And
it
still
gives
us
the
possibility
to
keep
things
flat.
A
A
I
I
kind
of
prefer
to
have
this
information
associated
with
the
creation
time,
because,
if
you
add
that
later,
the
the
ordering
of
the
execution
is
very
hard
to
decide,
for
example,
if
you
have,
if
you
have
the
a
library
that
is
reinstrument
and
the
library
at
some
point,
it
started
to
run
picking
a
user
request
and
they
said:
okay,
I'm
going
to
add
a
configuration
or
hint.
What
are
you
going
to
do
it's
very
hard
to
define
the
behavior
yeah?
So
what
I'm.
B
B
E
A
Yeah
jonathan
for
your
question,
I
I
think
my
answer
would
be
if,
in
java,
you
want
to
create
histogram
instead
of
filling
in
everything,
use
builder
pattern,
it's
totally
fine
that
you
put
the
hint
or
configuration
in
the
builder
pattern,
so
you
don't
have
to
like
mention
all
the
items
in
a
single
function.
You
can
chain
them
that
that's
your
freedom,
but
that
that
shouldn't
be
part
of
the
the
spec
so
spike
should
give
flexibility
to
the
language
to
have
their
best
way.
E
So
so
I'd
like
to
make
a
proposal,
then
around
hint
and
things.
So
what
I'd
like
to
see
for
the
at
least
for
java
is
the
hint
api
fleshed
out
enough
that
we
can
implement
it
where
default
buckets
can
be
specified
for
histograms
today
and
I'd
also
like
it,
if
it's
possible
for
us
to
throw
an
exception
if
a
default
bucket
does
not
exist
as
a
hint
and
we
don't
support
a
good,
auto
bucketing
strategy
when
you
try
to
make
the
instrument.
Is
that
a
reasonable
thing
to
ask.
E
E
E
G
Experience
like
I,
I
would.
Rather
you
make
a
arbitrary
choice
and
then
on
my
back
end,
I
realized
those
buckets
are
junk
and
I
go,
and
I
say
it
having
having
instrumentation
bubble
up
an
exception
that
it
could
have
handled
by
engineering.
The
problem
away
or
providing
some
kind
of
default
is
a
better
user
experience.
In
my
opinion,
and
from
talking
with
a
lot
of
customers,
they
don't
care
so
much
when
it
causes.
You
know
a
big
problem
for
them
because
they
included
some
instrumentation
library,
that
has
you
know,
exceptions
being
thrown.
E
I
I
hear
you
I
am
so
that's
that's
a
that's
a
actually
discussion
in
itself.
The
existing
java
implementation
throws
exceptions
all
over
the
place,
which
is
I
hear
what
you're
saying
my
concern
here
is
specifically
around
our
version
of
histogram.
I
don't
think
we
can
provide
a
default
bucketing
strategy
that
meets
anyone's
needs
unless
our
bucketing
strategy
is
no
buckets
or
a
bucket
right.
E
A
I
agree
with
josh
and
I
I
think
even
today,
if
you
want
to
do
that,
you
can
do
it.
You
have
the
meter
provider
and
the
meter
provider.
You
can
do
the
configuration
and
say
these
are
the
views
I
want.
If
you
don't
specify
the
wheel,
it's
going
to
take
all
the
instrument
from
from
the
meters
that
are
associated
with
the
provider,
and
in
that
way
you
can
travel
through
in
the
ic.
A
E
I
do
I
do
want
to
be
sensitive
to
what
tyler
was
saying,
though,
because
there's
this
we
we've
taken
the
approach
that
open
telemetry
should
not
get
in
the
user's
way
which,
which
is
to
say
it's
when
a
user
configures
an
sdk,
that
you
would
see
this
behavior
and
say:
hey
here's,
the
specific
instrument.
You
need
to
configure
a
bucket
for
this
right,
but
if
the
user
doesn't
configure
an
sdk,
you
wouldn't
get
an
exception.
This
would
be
deep
in
the
bowels
of
the
sdk.
A
So
I
would
imagine
most,
for
example,
I'll
just
pick.net
like
asp.net
and
those
things
they
will
have
a
good
understanding
of.
What's
the
default
histogram
buckets
and
they
should
provide
that
in
a
hidden
order
configuration
from
the
api
part
and
by
default.
I
expect
my
users
to
be
able
to
use
that,
but
I
still
expect
there's
some
libraries
when
they
instrument
they're,
very
generic,
and
they
don't
have
a
fit
for
all
default
value.
In
this
way
they
decide.
Okay,
we're
going
to
enforce
that
in
our
documentation
by
telling
people
hey.
B
I
would
expect
it
to
like
from
any
library,
but
some
people
like
can
get
angry
about
this.
That
say
why
is
this
there?
Why
am
I
getting
this
exception
if
it
will
not
work
anyways,
I
I
usually
like
it.
Where
would
that
check
be?
It
must
be
on
the
sdk
site,
right
yeah,
it's
the
sdk
configuration
part.
So
I
I.
A
Align
with
the
open,
telemetry
general
error,
handling
philosophy,
we're
saying
for
the
instrumentation
api
like.
If
you
create
a
span,
we
should
never
punish
the
user
like.
If
you
pass
in
something
that
doesn't
make
sense,
we
should
never
throw
exception
to
them,
because
instrumentation
is
scattered
all
over
the
places,
but
the
configuration
part
like
if
you
start
a
trace,
trace
provider,
tracer
provider
or
meter
provider,
and
you
scroll
up
the
configuration.
This
is
the
entry
point
of
your
application,
and
in
this
way
I
I
think
we
haven't
we
haven't
so
far.
B
This
exception,
like
thrown
the
time
when
I
am
like,
I
don't
know
like
creating
an
instrument
or
trying
to
report
a
anything
like
a
data
point
or
then
that
will
be
like
later
processed
or
maybe
exported
or
whatever
we'll
view.
My
basically
my
code,
if
I
am
having,
for
example,
like
a
like
a
couple
of
methods,
one
after
the
other,
and
I
am
trying
to
increment
the
counter,
will
that
exception
be
thrown
at
that
point
or
later.
A
A
D
So
I
just
I
think
it's
worth
calling
out.
I
want
to
call
it
a
concrete
example
that
I
think
kind
of
flies
in
the
face
of
what
josh
is
asking
for
and
what
I
think
all
of
us
are
talking
about.
So,
let's
say,
for
example,
I
am
the
owner
of
some
arbitrary
java,
http
client
library
and
I'm
writing
instrumentation
into
the
library
and
I'm
using
open,
telemetry
instrumentation
in
that
library.
D
As
the
author
of
that
putting
timing
like
creating
timings
around
http
calls,
I
have
no
idea
what
reasonable
numbers
are
going
to
be
for
how
long
these
http
calls
might
take
what
the
durations
are
going
to
be
it
that's
completely
up
to
the
application,
that's
using
them.
I
have
no
information
that
can
help
me
understand
what
those
values
might
be,
except
that
the
lower
bound
will
be
zero
like
other
than
that,
I
know
nothing,
so
I
don't
think
we
can
require
instrumentation
authors
to
provide.
We
require
them
to
provide
histogram
buckets.
E
Yes,
what
I'm
proposing,
though,
let
me
let
me
alter
my
proposal
slightly,
but
when
I
propose
an
exception,
I
don't
propose
just
a
le
exception.
I
propose
a
here's,
how
you
fix
this
exception,
I'm
actually.
I.
I
really
think
we
need
to
push
hard
on
our
error
scenarios
a
bit
in
some
of
these
sdks,
where
our
sections
are
pretty
terrible.
If
the
exception
doesn't
tell
you
how
to
correct
the
exception,
it's
not
a
good
exception
or
if
it
has
to
give
up
because
of
catastrophic
failure.
That's
okay!
E
But
if
it's
like,
you
can't
send
null
here,
it
shouldn't
just
be
no,
but,
like
you
know
illegal
argument
exception
of
like
a
name.
It
should
actually
give
you
a
little
bit
more.
You
know
anyway,
that's
a
random
rant
but
like
it
should
tell
you
how
to
fix
it.
E
So
so
the
idea
here
is,
I
think,
the
experience
to
the
user
of
a
bad
histogram
bucket
is
pretty
bad
and
we
want
to
make
the
user
as
aware
as
possible
for
how
to
fix
it
very
clearly
like
even
give
them
a
line
of
config
to
write
right.
If,
if
that's
possible,
so
maybe
what
we
do
is
we
get
rid
of
the
whole
notion
of
throwing
an
exception?
We
make
a
very
clear
log
statement
that
says:
hey
this
histogram
doesn't
have
a
default
bucket.
I'm
throwing
this
away
or
doing
something
stupid.
Here's
config!
E
You
can
write
to
fix
this
because
it
basically
the
user,
does
need
to
take
action.
Now.
I
have
to
agree
with
you
that,
like
you,
can't
expect
a
great
default
from
an
http
library,
but
an
http
library
can
do
a
better
default
than
we
can
for
any
possible
histogram
right.
At
least
we
have
an
idea
of
network
latencies
in
aggregate,
and
we
know
it's
a
network
latency.
We
know
it's
not
like
a
thermometer
right
that
someone's
making
a
histogram.
E
G
How
does
prometheus
deal
with
this
because
they
have
a
default
and
like
that?
It
seems
to
work
just
fine
for
their
users
like
they
come
in
and
they
look
and
they
say
like.
Oh
okay,
like
this
histogram
is
not
centered
around
the
point
that
I
actually
want
to
be
looking
at
or
the
tail
latency.
I
want
to
be
looking
at
or
anything
like
that
and
then
they
go
in
and
they
fix
it
and
it
seems
like
that
works.
G
Well,
you
know,
and
the
user
experience
that
they
they
go
undergo
is
that
they
set
up
a
histogram
and
the
histogram
works.
It
gives
data
to
the
backend
that
they
start
viewing
the
data
in
the
back
end
and
then
the
operator
comes
in
and
says
like
yeah,
that's
cool,
but
I
need
to
measure
slos
off
of
this
and
they
need
to
be
centered
around
a
different
area.
So
they
start
to
look
at
things
and
tune
them,
and
I
think
that
that's
a
really
good
positive
experience.
G
I
think
you're
right
josh,
that,
like
the
http
author,
could
do
a
better
job
at
writing
defaults.
But
I
don't
know
if
it's
like
a
10x
better.
I
honestly
like.
I
think
that
if
you
took
the
same
defaults
as
prometheus
and
people
started
looking
at
histograms
and
going
like
the
defaults,
just
don't
work
here,
let's
provide
an
override.
I
think
that's
a
perfectly
valid
solution.
A
Okay,
so
I'm
I'm
trying
to
see
if
we
can
converge
on
this.
So
let
me
ask
a
few
questions
number
one.
I
I
want
to
start
from
what
john
was
mentioned,
so
we
cannot
require
all
the
instrumentation
authors
to
put
default
buckets.
I
think
there
are
always
going
to
be
exceptions
where
people
have
no
idea
here.
So
this
cannot
be
a
requirement.
It
can
be
a
best
effort
and
do
we
agree
on
that.
B
This
is,
this
is
only
from
the
perspective
of
the
of
the
people
who
are
doing
the
instrumentation
for
their
own
board
or
own
library
right
for
the
library,
yeah
yeah,
because
I
I.
B
Some
like
way
of
of
of
having
like
default
buckets,
could
be
very
useful.
A
Yeah,
so
I
think
number
one
we're
saying
we
cannot
require
everyone,
it's
very
useful.
We
agree
and
I
I
think
we
should
push
as
hard
as
possible
for
the
instrumentation
to
have
something
default,
so
the
user's
life
will
be
easier,
but
we
cannot
require
everyone
to
to
be
in
that
situation.
So
the
word
is
not
perfect.
The
second
part
is,
we
believe
in
in
majority
of
the
cases
the
library
will
come
with
the
default
buckets.
E
I
believe
this
is
going
to
call
out
to
prometheus.
I
just
looked
up
their
defaults.
They
it's
basically
designed
around
web
rpc
requests
and
meant
to
provide
a
default.
If,
if
you
were
measuring
in
seconds,
it
looks
like
what
a
default
bucketing
strategy
would
be.
C
I
don't
know,
is
it
has
12
buckets
users
aren't
really
very
very
pleased
with
that
kind
of
resolution
and
the
prometheus
project
wants
to
create
a
new
histogram,
just
like
open,
histogram
kind
of
and
there's
some
question
about,
standards
and
donations
to
cncf.
That's
not
in
scope
for
this
conversation
here
now,
but
I
feel,
like
all
the
vendors
at
least
want
to
contribute
technology.
To
avoid
this
problem
by
making
automatic
buckets
open,
histogram
is
one
dd,
sketch
is
another,
it's
just.
It
seems
to
be
out
there.
C
Not
even
prometheus
is
happy
with
its
own
fixed
buckets,
so
I
I
don't
feel
like.
We
should
promote
it
much,
but
I
won't
argue
against
in
a
you
know,
explicit
way
to
say
these
are
buckets.
I
want
because
there
are
examples
of
like
where
you
have
a
range
of
your
number
inputs
too.
Like
I
want
to
say,
the
number
should
never
be
greater
than
100
or
less
than
100.
So
in
those
cases
it
helps
me
if
I
can
explicitly
give
you
buckets,
but
I'm
not
sure
it's
the
common
case.
B
Also,
I
I
guess
we
want
to
like
the
the
histograms
we
are
talking
about.
Those
should
be
hdr
histograms.
C
Right,
hdr
histograms
are
one
another
one
of
them
and
it's
all
really
a
question
of
find
agreement
on
the
protocols
used
to
represent
them.
I
I
have
at
one
point
made
an
issue
in
the
spec
repo
saying
any
histogram
will
do
if,
especially
if
it
has
automatic
bucketing-
and
I
would
like
to
like-
I
would
like
so
that
the
sdks
can
just
choose
whichever
sd,
whichever
technology
is
most
ready
for
them
most
reliable.
So
in
java
it
may
be
hdr
and
go.
C
E
So
I
I
want
to
change
change
my
stance
because
I
think
the
prometheus
thing
kind
of
convinced
me
of
we
should,
if,
if
we
decide
to
make
default
buckets,
we
should
specify
them
and
we
should
specify
them
kind
of.
Similarly,
I
think
of
let's
just
say
that
it's
going
to
be
web
requests
right
like
we're
going
to
specify
web
requests,
we
could
even
have
it
match
prometheus.
Exactly
if
we
wanted
to.
E
It
does
mean
that
we'll
have
to
figure
out
what
our
default
unit
is
across
the
board
for
these
things,
because
the
prometheus
default
buckets
are
fractional
and
I
don't
know
if
we're
recording
fractional
values
if
we're
recording,
longs
or
doubles
or
whatever,
like
again
that
that
that
I'd
have
to
investigate.
But
I
I'm
I'm
convinced
that,
like
yes,
we
don't
want
to
break
users,
it's
probably
true
users,
don't
want
to
care
at
all,
and
that's
we'll
have
to
come
up
with
something
better
and
that's
a
long,
long
long
term.
E
A
The
noise,
no
it's
very
good
discussion,
so
so
josh
you!
Actually
you
brought
up
a
thing.
I
started
to
think.
If
we
want
to
do
something
about
this,
do
you
think
semantic
convention
would
be
a
good
place?
For
example,
we
can
say:
http
should
follow
this
and
we
expect
all
the
http
instrumentation
to
also
specify
the
default
histo
histogram
is.
I
think
that
might
be
a
good
ideation.
B
Be
a
fan
of
them.
Okay.
Can
I
just
throw
in
like
a
goal
or
suggestion
I
believe
from
the
from
the
user
perspective?
It
would
be
very,
very
useful
if,
if
they
don't
do
anything
and
not
configure
anything
like
histogram
wise,
they
will
get
like
the
same
behavior
bucketing
wise
for
all
of
their
applications,
where
they
had
to
open
telemetry
so
that
they
will
be
able
to
basically
like
aggregate
these.
B
These
histograms,
I
mean
the
same
metrics
across
services
and
by
aggregation
I
only
mean,
like
just
add
them
together,
because
they
are
using
the
same
bucketing,
and
in
that
case
you
can
do
it.
If
you
are
using
like
different
bucketing,
then
you
will
not
be
able
to
do
that.
G
I
do
think
there's
an
interesting
opportunity
here,
though
kind
of
describing,
as
you
said,
like
the
instrumentation
author,
could
potentially
have
more
information
as
to
what
the
histogram
bucket
should
be,
and
I
think
that
maybe
some
of
the
discussion
has
been
around
the
either
or
if
the
sdk
should
provide
the
default.
The
instrumentation
should
provide
the
default
or,
if
it
shouldn't,
but
there
is
also
this
opportunity
that,
like
maybe
the
instrumentation
on
there's
a
priority
chain
there
that
could
happen
and
maybe
the
instrumentation
library
itself
could
provide
defaults.
G
And
if
that
isn't
satisfied,
then
the
sdk
could
provide
defaults.
But
it
also
might
add
more
complication,
that's
necessary.
You
know
the
user
may
be
even
more
confused
as
to
like
where
that
number
is
coming
from
just
a
thought.
E
That
lines
up
with
prometheus
they
their
instrument
for
histogram,
allows
you
to
specify
buckets,
so
you
can
optionally
go
in
and
configure
it.
So
I
think,
like
we're,
seeing
a
lot
of
like
I
don't
care.
If
the
configuration
for
buckets
is
a
hint
api
or
a
well-defined
sdk
thing,
that's
not
measurement
processor,
because
measurement
processor
is
way
too
big
and
we'll
talk
about
that
in
a
bit.
I
hope,
but
yeah,
I'm
hoping
it's
a
very
clearly.
You
know
laser
focused.
This
instrument
has
this
bucket
right.
Someone
needs
to
be
able
to
configure
it
somewhere.
E
E
C
I
have
another
way
of
making
that
a
requirement
josh
it's
to
say
something
like.
I
would
like
in
the
future
to
be
able
to
take
a
prometheus
library's
interface,
swap
in
an
open,
telemetry
library,
underneath
the
hood
and
support
it
completely.
Using
just
api
calls.
So
in
order
to
do
that,
the
prometheus
instrument
registration
includes
the
option
to
set
explicit
buckets.
Therefore,
I
need
a
way
to
do
that
in
my
open,
telemetry
api,
so
sort
of
like
compatibility
requirement,
which
would
have
happened
in
open
tracing
with
any
of
the
existing
open
tracing
libraries.
C
A
Thanks,
okay,
before
I
move
on,
I
I
think
I
still
have
one
question
about
the
perception
on
view
versus
like
hint
versus
configuration
and
again
it's
naming
so
so
it'll
be
hard,
and-
and
I
explain
so-
I'm
worried
about
configuration
number
one.
It's
it's
hard
for
people
to
search.
If
everything
is
configuration,
we
tell
them.
You
can
specify
some
configuration
in
the
api
and
then
there's
some
other
configuration
in
ick.
That
makes
me
worried.
A
The
second
part
is
in
the
ic
head
part.
I
think
there
is
a
valid
scenario
where
people
can
take
one
instrument
and
they
want
to
report
that
in
different
ways.
They
want
to
say.
I
won't
treat
this
instrument
as
a
counter
and
report
that
to
permissive,
and
I
want
to
treat
this
as
a
histogram
and
report
to
my
otlp.
A
In
this
way.
I
think
calling
that
view
we
can
tell
people,
you
have
two
views
and
they
are
applied
to
the
same
instrument,
but
calling
that
configuration.
I
think
it's
very
hard
like
I
have
to
explain.
You
have
two
configurations
and
they're
separate
and
whatever
you
do,
they're
independent
of
each
other
and
each
of
them
is
sent
into
a
different
thing.
So
that
makes
me
worried
about
calling
everything
configuration,
but
on
the
other
side,
I'm
I'm
also
seeing
by
calling
view
and
hint
reminded
people.
This
is
a
scary
like
sequel,
specific
thing.
A
So
so
I'm
stuck
here
and
I
want
to
know
the
feedback.
So
we
have,
we
have
three.
I
have
three
approaches:
either
we
we
don't
do
it.
We
give
up
on
the
view
and
hint
which
I
I
think
is
going
to
be
a
showstopper.
We
cannot
so
first.
I
want
to
confirm
this
is
not
something
that
we
want
to
do
so
I
want
to
give.
A
So
here
goes
the
question:
try
to
make
it
very
simple:
if
we
give
hint
and
view
to
people
who
are
not
heavily
involved
in
this
discussion,
they
would
be
scared
and
they
would,
by
default,
pay
configuration.
So
I
would
expect
most
of
the
users
when
they
see
this.
They
would
also
prefer
configuration,
but
it
seems
here
like,
as
we
think
more
about
this.
We
start
to
see
configuration
it's
going
to
cause
some
problem
and
we
we
kind
of
prefer
viewing
him
the
name
that
matter,
but
we
try
to
separate
the
concept.
A
E
E
We
need
to
make
users
aware
that
this
could
happen,
and
it
then
there's
the
op.
So
so
the
question
there
would
be:
is
it
good
that
we
have
ignorable
configuration
or
not?
Is
that
something
that
is
bad
for
users?
I
think
that's.
That
would
be,
I
think,
the
primary
discussion
in
the
hin
api
yeah.
I
don't
want
to
walk
into
that
yet
because
I
think
we'll
hash
that
out
on
the
vr.
E
The
second
thing
would
be
around
view
giving
users
a
term
for
something
that
is
more
limited
than
just
general
configuration,
I
think,
is
a
good
thing,
especially
if
it
has
at
least
a
little
bit
of
precedence
or
a
little
bit
of
good.
I
don't
know
naming
like
association,
not
100
positive
view.
Does
it
is
what
open
sense
is
used,
but
I
I
personally
think
we
should
give
it
a
name
and
give
it
a
very
streamlined
api,
because
that
will
help
more
than
just
calling
it
config.
A
I
I
agree
with
you
josh,
so
this
is
so
far
what
I
I
would
prefer
and
also
regarding
the
hint
I
I
think
here
I
try
to
explain
hidden,
is
something
that
people
can
ignore.
Well,
configuration
is
hard
and
it's
like
everything
can
be
called
configuration,
and
I,
I
think
so
far.
I've
got
questions
from
noah
from
from
yuri
and
from
from
other
folks,
and
given
that
yuri
has
been
in
the
telemetry
space
for
many
years
and
noah
has
been
owning
the
diagnostic
akai
figure.
A
A
So
I
want
to
get
more
feedback,
so
this
is
something
I
personally
I
I
prefer
to
have
hinton
view,
but
I'm
guiding
a
lot
of
people
who
have
been
working
in
this
space.
For
many
years
more
than
me,
they're
telling
me
configuration
and
I'm
struggling,
I
want
to
get
more
feedback
instead
of
making
my
random
decision
here.
B
By
the
way,
I
I
am
not
sure
like
combining
them
is
is
a
good
idea
either,
because
there
will
be
things
that
you
only
configure
on
the
sdk
site,
for
example,
if
you
want
to,
for
example,
filter
out
some
of
the
instruments
by
name
yeah
that
will
not
exist
on
instrumentation
time
or
yeah.
B
I
I
I
would
keep
them
separately
and
to
me
it's
like
the
view
is
kind
of
the
configuration.
The
hint
is
basically
just
data
that
belongs
to
the
instrument.
A
Your
hint
and
view
are
exactly
the
same
concepts
in
sql
server
right,
you
define,
you
have
a
table,
you
have
multiple
views
and
you
can
provide
the
indexer
hint
and
hint
can
be
ignored
in
the
query
optimizer.
So
I
guess
probably,
when
people
introduced
those
concepts
in
open
senses,
they
were
probably
coming
from
the
sql
background.
A
So
anyone
has
has
different
meaning,
like
you
think
we
should
combine
that,
if
not
then
probably
we're
missing
like
yuri
and
and
noah
here,
so
I'll
I'll
communicate
back.
E
A
Yeah,
but
it
doesn't
have
the
semantic
or
it's
not
clear,
that
it's
just
the
best
effort
and-
and
I
think
he
can
ignore-
that-
that's
true-
that's
true-
the
default
means,
if
I
give
you
the
histogram.
I
explain
here.
If
I
give
you
the
histogram
buckets
like
this
and
the
bacon
is
saying
no,
I
cannot
support
that
many
I'm
going
to
do
something
about
it.
A
A
But
the
noah
has
a
point
he's
saying:
if
there's
a
instrument
name
where
the
backhand
doesn't
support,
the
backhand
might
also
alter
the
name.
So
it
seems
everything
can
be
changed
later.
So
why?
Why
would
you
want
to
stress
that
something
cannot
be
changed?
Just
call
everything
configuration
and
he
starts
he's,
starting
from
the
user
perspective
he's
saying,
if
everything
had
configuration,
it
might
be
easier
for
the
user
mental
model,
and
I
also
agree
with
him.
F
A
So
I'm
struggling
between
these
two
approaches:
either
I
keep
existing
prs
and
I
still
skin
hand
view
and
probably
can
change
the
name,
but
still
keep
the
concept
separate.
You
know
polish,
the
prs
move
forward
or
my
body
is
at
certain
moment
we
hit
him,
we
hit
a
wall
and
we
decide
okay,
we
need
to
combine
the
concepts,
and
this
is
where
I'm
I'm,
I'm
stuck.
The
pr
has
been
stuck
there
for
a
while.
E
So
I'm
still
a
fan
of
keeping
vue
as
a
separate
streamlined
thing
that
you
would
configure
if
we
just
call
hint
configuration
and
we
still
have
views
in
the
sdk.
I
think
that's
fine.
If
we
take
this
approach
of,
we
make
it
clear
to
users
that
configuration
can
get
overwritten
like.
I
think
the
purpose
behind
the
hint
idea
is
it's
ignore,
like
we
want
to
make
sure
the
user
understands
fully
that
we
could
ignore
their
configuration.
E
A
A
Yeah,
I
I
would
probably
make
it
stronger.
Please
try
to
separate
the
concept.
I
wouldn't
call
view
a
con.
I
wouldn't
call
hint
a
configuration.
I
think
joshua
mentioned
you're
fine.
If
people
call
hints
a
configuration.
I
think
I
wouldn't
be
fine,
because
if
we
call
that
configuration
it
would
be
very
confusing
if
people
want
to
configure
the
ick.
They
call
that
view.
A
A
F
So
riley
may
make
a
just
a
I
guess.
A
thought
is
that
the
hint
always
troubled
me
a
little
bit
because,
as
as
we
already
said,
it's
not
necessarily
you
know
would
be
a
guaranteed
to
be
honored.
So
I
I
just
thought
this
out
there.
I
think
that
the
library
developer
should
provide
not
in
a
hint
or
we'll
have
to
find
a
way
to
do.
It
provide
a
concrete
configuration
that
they
would
prefer
and
then
the
sdk
developer
could
choose
to
override
or
replace
that
configuration
with
another
concrete
configuration
that
that
will
actually
be
effective.
F
So
to
tyler's
point:
it's
really
not
com
combining
these
things,
but
really
a
priority
of
choosing.
Do
I
want
to
use
the
you
know
the
libraries
concrete
configuration
or
do
I
want
to
use
an
override
my
you
know,
sdks
concrete
configuration,
or
do
I
want
to
use
the
operators
concrete
configuration.
So
from
that
perspective
I
see
that's
all
as
being
a
configuration,
but
choosing
which
set
of
configuration
you
want
to
use
instead
of
combining
a
hint
into
you
know
a
view
config
or
whatever
anyway,.
F
A
Thoughts.
Okay,
so
here
goes
the
challenge.
I
I
think
I
called
out
earlier.
This
is
not
a
simple
configuration
override
or
peg,
which
configuration,
because
you
can
have
multiple
views
on
the
same
instrument
in
this
way.
If
you
come
like
you
have
two
wheels,
you
call
both
configuration.
I
think
it's
a
little
bit
confusing.
F
A
Okay,
so
it
seems
like
I,
I
should
go
forward
with
the
two
pr's
and
and
still
try
to
push
for
two
separate
concepts
and
and
if
the
pr
are
still
blocked
I'll,
try
to
resolve
the
minor
comments
like
some
of
the
wording
issues
those
things,
but
I
think
there's
some
fundamental
issues.
So
if
we
cannot
agree
on
this
I'll
I'll
need
to
bring
this
back
to
the
tc
and
the
spec
op
meeting
to
see
if
we
can
resolve
that
in
the
worst
case
is
we'll
do
a
vault,
but
probably
we
won't
be
in
that
situation.
A
Okay,
so
so
sorry,
this
one
is
running
very
long
time.
So
it's
update
on
the
prototype.
I
know
like
josh
and
victor
they
have
the
prototype
and
I
I
remember
anthony
mentioned
he
probably
would
do
some
prototype
for
gold.
I
haven't
heard
back
from
him
yet
so,
if
you
guys
want
to
update,
I
think
josh,
I
I
went
through
your
note,
and
this
is
one
thing:
I'm
not
clear
but
I'll,
let
you
go.
E
Yeah,
so
I
got
all
the
synchronous
instruments
implemented
with
exemplars,
with
histograms,
with
aggregations
with
the
measurement
processor
through
to
the
shared
state.
Now
we
still
have
an
issue
with
collection,
but
the
effectively
measurement
is
described
as
having
a
value
and
a
set
of
attributes.
E
What
I
attached
to
it
was
context
and
what's
missing
from
it,
is
the
actual
record
time.
I
think
we
might
have
a
bug
with
the
data
model
if
you
actually
export
exemplars
and
you
do
exemplar
sampling,
where
you
put
like
trace
id,
the
exemplars
are
meant
to
have
the
exact
record
time
timestamp
on
them.
E
That's
not
called
out,
and
also
it's
not
necessarily
clear
in
the
api
or
sdk
who
makes
the
determination
of
start
stop
times
for
recording
like
when
that's
happening.
This
is
probably
part
and
parcel
with
us
defining
how
we
do
export,
how
we
do
the
shared
state,
how
we
have
multiple
exports,
but
effectively.
No
one
is
declared
to
have
kept
track
of
start
and
stop
times.
So
I
put
that
inside
of
the
shared
storage.
E
We
can
talk
about
how
it's
implemented
in
java,
but
effectively
a
measurement
processor
doesn't
actually
consume
measurements.
What
it
does
is,
it
sets
up
a
pipeline
from
instrument
directly
to
storage
and
that
storage
is
responsible
for
owning
start
and
stop
collect
times
and
whenever
it
gets
called
to
do
a
flip
of
the
next
collection
interval,
it
will
assign
a
stop
time,
but
we
we
don't
actually
call
out
like
that's
that
any
measurement
of
time
is
taken
in
the
api,
but
in
the
data
model
we
require
an
exact
time
stamp
on
exemplars.
E
My
proposal
here
and
I
can
I
can
open
up
a
pr-
is
to
change
the
exemplar
definition
to
be
a
little
looser.
So
we
can
basically
use
collection
time
on
exemplars,
so
we
don't
have
to
hit
a
clock
every
freaking,
you
know
millisecond
across
a
bajillion
threads
if
we're
going
to
be
sampling
exemplars,
but
that's
the
the
the
more
important
question
is
who
determines
collection
time?
When
does
that
happen?
How
does
that
get
flipped
over
was
just
a
big
open
question
that
I
just
kind
of
stuck
with
how
java
does
it
today.
C
In
my
prototype
there
was
a
controller
concept
that
did
did
that
determination
if
there
was
a
push
or
a
pull
that
was
slightly
different
and
if
there
were
both,
it
had
to
do.
Combination
of
them.
But
your
question
about
clocks,
for
example,
ours.
I
would.
I
would
challenge
that,
like
you,
can
make
a
sampling
decision
before
you
check
the
clock.
E
C
Right,
I
could
see
leaving
some
flexibility
there.
You
know
if,
if
your
probability,
sampling
and
there's
an
otep
that
I
have
open
about
it
like
it
would
make
sense
to
keep
the
exact
time
stamp,
because
you
can
then
plot
a
time
series
from
the
data
you
can
take
all
the
exemplars
sum
them
up.
Their
counts.
Their
sampling
counts
and
then
make
a
time
series,
but
you
need
real
time
stamps.
C
It
should
it
shouldn't
well
not
in
the
way
I'm
thinking
of
it.
If
you
want
to
do
temporal
alignment
of
sampled
exemplars
you'd
want
to
be
able
to
to
realign
your
collection
window
by
by
moving
exemplars
into
an
adjacent
window
based
on
their
actual
time,
but
this
would
this
implies
that
you're
doing
probabilistic
sampling
so
we're
a
little
bit
off
track.
E
Yeah,
I
guess,
with
there's
a
whole
there's
a
whole
can
of
worms
to
open
with
exemplars.
I
have
a
prototype.
That's
out
there,
that
you
can
take
a
look
at
it's
real
dumb,
I
should
say
simplistic,
but
it
basically,
just
if
there's
two
options
you
have
no
sampling
or
if
a
trace
is
sampled
sample,
all
measurements.
E
From
that
same
context,
right.
The
more
important
thing,
though,
is
this
time
stamp
selection
right.
I
think
I
think
we
actually
want
to
to
to
figure
out
how
we
define
when
and
where
time
stamp
selection
happens
and
the
whole.
You
know
if
I
have
a
pool
based
model
for
metrics
or
a
push
based
model
for
metrics.
When
am
I,
when
am
I
flipping
my
collection
intervals
on
synchronous
instruments?
E
When
am
I,
when
am
I
actually
going
out
with
my
asynchronous
instruments
and
getting
a
value
and
what
does
the
shared
state
actually
mean
right
in
java,
because
you
have
to
do
a
delta
there
and
and
aggregation
anytime?
Someone
calls
give
me
the
current
metrics.
We
actually
do
a
new
timestamp
and
flip
all
the
metrics,
and
you
can
never
get
that
set
of
metric
collection.
Again
in
shared
state,
so
it
basically
allows
one
person
to
export
right
and
that's
just
how
the
implementation
is
today,
what
I'm
seeing
with
the
sdk.
E
I
think
we
need
to
flush
that
out
to
make
it
more
explicit,
more
clear
what
it
means.
Who
does
the
the
collection?
How
often
it
happens?
You
know
that
sort
of
thing
of
the
metrics
into
these,
like
shared
state,
buckets
for
them
the
exporters
to
go
out.
I
that
that
was
that
needs
to
get
looked
at.
The
other
thing
I
noticed
was
implementing
a
measurement
processor
was
really
really
really
big,
so
I
think
we
should
fragment
that
api
up
a
little
bit.
E
I
think
it's
a
great
api,
it's
exactly
the
right
emergency
escape
hatch
to
have,
but
to
the
extent
we
can
make
little
components.
I
think
the
that'll
be
good,
so
those
are
kind
of
the
two
two
major
things
that
I'm
calling
out
here
and
then
there's
a
bunch
of
other
random
notes
and
things
that
I
can
raise
issues
for.
I'm
probably
gonna
open
up
some
pr's
against
the
api
by
the
way,
so
I'll
do
that.
Instead
of
this
meeting.