►
From YouTube: 2022-07-19 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
A
D
All
right,
so
I
don't
know
if
I
should
give
you
give
an
introduction
to
the
others,
but
yeah,
so
the
I'll
just
go
to
the
current
stats.
So
there's
two
pr's
open
there
is
the
spec
there's
the
spec
vr
open
in
the
proto,
so
the
spec
we
there
were
some
discussions,
but
it
seems
not
that
there's
some
agreement
there's
some
approvals
already
on
it,
but
the
proto
we
it
was
closed
so
the
last
week
or
so
before.
D
We,
it
was
called
because
there's
still
not
mission
agreement
and
it
was
two
long
discussions.
It
was
hard
to
follow
and
so
on,
yeah.
So
so
we
closed
it
in
and
and
had
an
idea
to
reopen
with
the
different
approach,
switching
the
semantics
to
reject
it.
D
A
That
we're
close,
I
guess
to
coming
to
an
agreement,
but
I
guess
yeah
josh,
if
you're
here,
maybe
you
can
tell
why
did
you
feel
the
need
to
maybe
reset
this?
I
guess.
B
Yeah
I
felt
first
of
all,
I
had
contributed
a
lot
of
discussion
early
on
in
that
pr.
That
was
extraneous
at
that
point,
so
I
felt
like
resetting
the
pr
discussion
in
the
protocol.
B
Repository
would
just
help
because
it
appeared
that
there
had
there
had
become
some
confusion,
and
you
know
basically
I'm
just
very
supportive
of
this
pr
or
this
approach
in
general,
and
I
just
found
that
the
semantics
of
optional
in
protocol
3
and
protobuffer
syntax
version
3
and
the
semantics
of
you
know
optional
fields
that
aren't
really
marked
optional,
because
they're
messages
and
the
the.
B
What
do
you
do
when
you
get
a
zero
value
with
or
without
an
empty
message
is,
was
a
question
that
kept
coming
up
and
I
felt
either
we
would
have
to
use
an
optional
or
we
would
have
to
agree
to
some
sort
of
interpretation
rules.
When
you
see
a
zero,
it
might
be
meaningful
or
might
not
be
because
of
the
protocol
rules.
So
I
felt
like
at
the
end,
if
we
can't
have
optional
or
we
don't
want
optional,
then
we
should
count
the
number
of
dropped
things,
not
the
number
of
accepted
things.
B
So
that
zero
can
be
optional,
if
you
don't
put
in
a
value,
it
becomes
zero
and
you
have
to
assume
everything
was
accepted.
But
if
you
do
use
a
value,
you
can
enter
the
entire
count.
If
you
want
to
drop
everything,
it's
meaningful
so
that
you
don't
need
the
zero
value
if
you're
counting
rejected
or
dropped
things,
but
you
you
need
an
optional
zero
value.
If
you're
counting
accepted
things,
that's
that's
what
this
is
about.
I
I
basically
want
to
make
sure
we
get
something
done
and
I'll
accept
any
kind
of
compromise.
E
D
It
is
like
that,
yes,
the
the
the
top
level
messages
message.
Properties
is,
if
you,
if
you
1.10,
you
can
just
leave
it
on
set
and
it
it
will
be
null
and
everything
will
be
okay.
D
I
think
the
only
problem
have
arise
when
when,
for
example,
the
server
decides
to
for
some
reason,
initialize
the
the
the
field,
the
message
and
then
just
leave
it
at
that-
or
maybe
it
initialize
that
and
sets
a
message
as
that's
a
sets,
the
error
message
but
doesn't
set
the
value,
then
you
don't
know
if
it
intended
to
be
like
I
didn't
accept
anything
or
I
just
forgot
to
set
it.
So
I
think
that
was
the
point.
There
was
a
concern.
A
That's
not
that's.
That's!
That's!
The
implementations
shouldn't
forget
to
do
things
right
this.
The
specification
says:
that's
that's
what
they
are
supposed
to
do.
It's
not
an
excuse
for
the
server
to
forget
to
do
that
right.
It's
just
that.
The
server
made
a
mistake
right.
D
I
feel
it
is
it's
clear
that
if
it's,
if
you
want
to
signalize
a
partial
success,
then
you
need
to
initialize
this
view
and
you
must
set
the
value,
the
the
accepted
field,
and
if
they
don't
do
it,
then-
and
I
guess
this
like
this-
it's
already
out
of
our
hands
right-
they
can
still
do
weird
things,
but
but
I
also,
I
also
think
that
the
reverting
or
reversing
it
to
what
to
what
josh
said
also
makes
sense.
So
I'm
also
fine
with
both
approaches.
A
A
B
That
that's
that
understanding,
though
so
so
what
happens
when
a
server
decides
to
set
this
field
and
did
actually
drop
zero,
so
the
value
dropped
or
accepted
whatever
the
value
of
that
field
is
zero,
whatever
whatever
it
means,
but
the
the
error
message
string
is
empty
because
they
didn't
fill
that
in.
Maybe
they
didn't
feel
like
filling
in
an
error
message
now.
You've
got
a
message
that,
from
the
protocol
buffer
compiler's
point
of
view
is
exactly
zero.
It
doesn't
need
to
be
serialized.
B
It
is
an
optional
message
that
has
a
default
value
and
until
you
write
the
optional
keyword
in
the
protocol
file,
those
are
equivalent
to
the
protocol
buffer
compiler.
So
some
proxy
somewhere
could
say
I'm
serializing
a
message
in
my
response:
it's
empty.
I
don't
need
to
serialize
it,
and
now
the
recipient
sees
the
response
with
no
no
partial
success,
because
the
zero
and
the
empty
string
caused
it
to
look
like
an
unset
message.
B
So
I
I
had
been
talking
about
this
withdrawal
before
you
know
in
this
private
discussion
I
said
well,
what
we're
just
going
to
end
up
with
is
a
rule
that
says.
If
the
error
message
is
non-empty,
then
the
zero
is
meaningful.
If
the
error
message
is
not
is
empty,
the
zero
is
quite
questionable
and
I
don't
know
what
it
means.
I
think
that's
where
we
ended
up
and
so
forgetting
to
set
a
message,
is
almost
equivalent
to
forgetting
to
set
a
non-empty
string
in
your
error
message,
and
I
guess
it.
B
You
know
again
I'll
accept
anything
here.
We
really
got
to
get
something
for
our
customers,
so.
A
B
D
Yeah,
the
problem
with
the
with
requiring
the
message
to
be
required
is,
is
that
we
don't
define
what
you
should
put
there
or
any
guidance,
and
I
I
feel
a
bit
odd
that
we
require
that
this
must
have
to
put
it.
But
we
don't
say
what
you
should
put
there,
not
sure
if
this
is
also
common
in
other
places,
but
yeah
yeah
yeah.
That's
a
good
point
with
the
compilers
and
doing
strange
behavior.
It
is
actually
the
default
message
if,
if
it's
empty,
so
I.
B
Know
that
there's
trouble
accepting
the
actual
keyword
and
that
there's
a
subscript
that
keeps
it
the
optional
keyword
out
of
the
collector,
for
example,
but
my
understanding
was,
if
you
actually
use
the
optional
keyword
on
a
message
in
protocol,
you
know
syntax
three:
it
it
just
forces
you
to
have
that
pointer
and
it
forces
the
people
who
are
with
proxies
to
preserve
that
point
or
even
when
it's
empty,
so
that
using
optional
on
the
message,
the
partial
success
message
might
not
cost
us
anything
and
might
give
us
what
we're
asking
for.
B
A
So
you're
saying
put
the
optional
on
the
message
field
on
the,
which
is
the
outer
the
outer
message
not.
B
D
B
That's
not
actually
my
understanding,
I
mean
like
I,
but
I
don't
actually
know
what
the
gogo
compiler
that
I
believe
people
are
still
using
would
would
do
like
that.
It
has
an
annotation
saying,
don't
make
a
pointer
out
of
this
and
that's
usually
something
you
can
do,
whether
it's
optional
or
not,
and
I
think
one
of
the
reasons
that
we
had
said
the
the
take
those
optional
keywords
out
of
the
protocol
is
that
we're
still
using
gogo
and
it
doesn't
understand
it
so
we're
turning
them
into
one
of
fields
and
anyways.
B
The
outcome
where
we
just
say
your
error
message
should
be
non-empty,
or
else
someone
might
miscount
your
dropped
fans.
Metrics
logs
is
okay
with
me
again.
A
D
Yeah,
so
what
I?
What
I
thought
about
this
is
that
if
we
refer
to
to
to
to
reject
it
so
like
what
I
thought
is
if,
if
a
sender
receives
a
partial
success
and
the
project
is
zero,
for
example,
it's
probably
like
every
situation
or
something
that
shouldn't
happen
right,
and
in
that
case
they
can
just
treat
it
as
as
it
was
a
success.
They
did.
D
They
just
ignore
it,
basically,
because
if,
if
we
revert
it
to
rejected,
then
it
should
there
should,
if
the,
if
the
parts
of
success
is
there,
there
should
be
something
that
is
not
zero
right.
So
that's
the
way
I
see
it,
and
I
could
rewrite
this
back
to
say
something
like
this
and
I
guess
then
we
would
solve
it.
It
would
be
solved.
B
Yeah,
I
think
I
support
that
idea
that
the
you
could
use
a
client
error,
for
example,
to
signal
the
case
where
you're
accepting
everything
with
an
error.
It's
just
it's
hard
to
define
that
situation,
accepting
everything,
but
there
is
an
error.
B
It's
kind
of
weird
it
doesn't
need,
it
doesn't
require
an
rpc
level
error
or
an
http
status
code
error.
I'm
not
really
sure
yeah.
D
Yeah,
like
both
case,
the
the
way
I
see
like
both
cases,
has
have
this
weird
situation
like
the.
If
we
revert
we
have
this,
that
we
could
get
zero
as
well
and
and
say:
okay,
like
you,
can
treat,
it
is
a
success
because
this
shouldn't
happen,
but
the
same
way
with
the
with
the
accepted.
D
We
cannot
say
like
no,
if
you
receive
zero,
but
there's
this
other
case
that
that
josh
just
said
it,
which
is
also
more
complicated
but
yeah,
and
we
can
also
market
the
the
number
field
as
optional,
with
with
the
option
in
prototype,
and
then
we
don't
have
the
zero
problem
anymore,
but.
A
E
If
something
is
optional,
its
existence
is
important,
so
I
don't
think
a
proxy
can
drop
it.
If
it's
not
optional,
then
the
zero
is
just
the
default
value.
D
Yeah,
so
if
if
if,
if,
if
you
mark
it
as
as
optional
then,
and
if
they
don't
set
it,
then
it's
not
zero.
It's
this
undefined
state
right
and
and
then
the
the
the
centers
can
also
check
if
this
was
ever
set
or
if
it
has
zero.
So
if
yeah
can
I.
F
Ask
it
can
I
ask
a
use
case
question
here
so,
like
yeah,
the
the
field
that
we're
arguing?
What's
the
the
there's
there's
one
use
case
that
I'm
aware
of
for
this,
which
is
a
partial
projection,
leads
to
us,
not
retrying
right,
that's
the
most
important
bit
of
this
whole
pr.
So
let's
make
sure
that
stays
like
no
matter.
F
So
I
think
that's
where
there's
some
contention
here
over
filling
this
thing
out
versus
not,
but
what's
the
use
case
of
returning,
the
number
of
messages
is
this
about
like
observability
like
we
want
to
put
push
a
metric
of
how
many
things
are
rejected,
should
that
metric
just
be
delivered
by
the
server
and
not
by
the
client,
like
I'm
trying
to
understand
why?
Why,
like,
should
we
be
fighting
to
add
this
field
now
or
can
we
add
it
later
is?
A
Yeah
to
me
it's
observability
right.
I
would
want
to
kind
of
get
a
sense
of
how
many
were
rejected,
like
how
serious
it
is
in
a
sense
right,
if
I'm,
if
I'm
troubleshooting,
something
it
probably
matters,
whether
one
point
out
of
a
million
is
rejected
or
or
I
guess
the
vast
majority
of
those
are
rejected,
but
there's
probably
some
qualitative
difference
in
the
quantity
here.
E
I
think
what
josh
is
is
getting
at,
though,
is:
why
do
you
collect
that
metric
on
the
client
or
the
agent
rather
than
just?
If
the
server
has
to
return
that
number
back
to
the
agent
anyways,
then
the
server
knows
how
many
were
dropped
and
it
can
just
you
know,
show
a
metric
on
the
server
side
generate
a
metric
on
the
server
side
to
say
this
many
were
dropped.
B
E
B
B
The
of
the
server
and
makes
the
chances
that
a
client
is
misconfigured
and
has
no
sort
of
immediate
way
to
discover
that
themselves
more
likely.
I
think
that
the
error
message
field
is
like
most
of
the
value
here
and
I-
and
I
think
now
I
can
see-
we've
we've.
The
fault
here
is
that
we've
tried
to
put
two
things
into
one
piece
of
work.
B
I
think
joao
just
wanted
the
error
details
and
I
think
I
just
wanted
the
counts,
and
that's
because
I'm
trying
to
get
to
a
place
where
I
can
count
how
many
metrics
are
succeeding,
and
I
know
that,
even
though
I
can
directly
file
that
on
on
the
server
side,
clients
go
to
look
at
their
logs
and
and
so
having
a
counter
that
I
can
print
in
the
log
myself
or
a
summary
of
myself
is
something
I'd
still
like
to
have.
D
Yes,
yeah,
I
I
agree
with
with
the
other
case.
Yeah.
The
their
messages
are
indeed
helpful,
because,
because
we
can,
we
can
put
some
structure
like
josh
said
like
we
can.
Service
can
come
up
with
a
different
structure
and,
and
ultimately
we
should
have
our
own
proper
structure,
but
later
on
right.
So,
but
and
and
and
this
is
just
helpful
like
if
I'm
trying
something
trying
a
vendor
trying
something
it
doesn't
work,
and
I
don't
know
how
to
use
things
yet
then
just
having
the
log
there.
It
really
helps.
D
We
think
in
for
the
examples,
there's
a
lot
of
examples
that
that
everyone
came
up
in
the
prs
like,
for
example,
reaching
a
quota
like
the
server
accepted
part
of
parts
of
the
data
points,
for
example,
but
reject
the
rest
or
you
don't
have
enough
rights
to
to
do
this,
but
half
away
and
so
on
or
or
or
you
change
counter
to
a
gauge
and
and
metrics
are
rejected,
and
so
on.
So
there's
a
lot
of
use
case
there.
D
A
D
Yeah,
I
can
create
one,
so
if
the,
if
you
want
to
just
try
to
reject
the
the
the
other
way
around
the
having
rejected
I,
I
will
open
the
pr
and
and
tag
you
so
we
can
continue
the.
D
D
A
Move
to
the
next
item,
josh,
so
that
you
have
the
next
one.
F
Yes,
I
think
this
one
there's
a
there's,
an
issue
that
had
a
whole
ton
of
discussion
on
it,
that
I
want
to
ask
the
fundamental
question
here
to
see
if
we
agree
on
that
before
we
move
forward
with
the
issue
which
is
specifically,
should
we
provide
a
new
location
for
metric
definitions?
That's
not
like
overall
open
telemetry
semantic
conventions.
It
has
like
a
different
kind
of
bar,
so
this
would
be
like
you
know,
in
the
in
the
collector.
F
There's
a
receiver,
for
I
don't
know
kafka
or
you
know
different
database
metrics
like
mysql
in
java
right
there's
a
receiver
for
a
particular
library
that
might
be
java,
specific,
okay
and
there's
a
set
of
metrics
that
that
thing
defines
do
we
want
to
have
so
it's
almost
two
questions.
Do
we
want
to
have
a
standard
metric
definition,
file
format?
The
collector
has
these
these
metric,
xml
or
yaml
files
that
I
really
like
that.
I
think
we
should
standardize
on
and
have
tooling
around
to
generate
documentation.
F
I
think
it'd
be
valuable
and
we
should
add
that
to
our
spec,
but
the
second
thing
it
would
be,
should
we
have
like
just
say:
open
cylinders
we'll
have
more
than
one
kind
of
metric
semantic
convention.
F
So
if
I'm
the
java
sig-
and
I
want
to
make
a
couple
metric
libraries
that
provide
metrics
for-
I
don't
know,
pick
java
framework
spring
or
something
right,
I
can
make
a
spring
yaml
file
that
defines
what
the
metrics
are
that
will
generate
docs,
and
then
I
can
also
have
a
a
schema
file
for
that
set
of
metrics,
where
I
define
compatibility
right.
That
is
not
at
the
semantic
convention
level
that
requires
the
level
of
semantic
inventions.
So
like
do
we
want
to
provide
that
for
cigs,
yes
or
no,
that's
it
it's
more.
F
G
I
can't
share
my
feeling,
I
I
think
number
one.
We
should
number
two.
Maybe
after
the
split
library,
specific
semantics
shouldn't
go
to
a
central
place
by
nature
they're
distributed,
and
we
should
allow
people
to
invent
their
own
semantic
convention
following
a
certain
format
and
maybe
the
automatic
tool
that
generates
the
docs
can
be
published
as
a
as
a
tool
that
anyone
can
use
to
integrate
into
their
repository.
G
G
B
E
Sam
also
mentioned-
and
I
agree
that
this
may
be
worth
applying
to
tracing
as
well.
There
are
library,
specific
attributes
requested,
at
least
in
javascript,
I
assume
in
other
languages.
It
happens
all
the
time
someone
says
I
have
this
library,
it's
not
covered
by
the
overall
semantic
conventions,
but
I
want
to
track
this
attribute
and
we
at
this
point
have
no
idea
how
to
handle
that
kind
of
thing.
F
I
want
to
add
that
it
should
also
apply
to
logs
now
that
we
have
a
logging
api
and
specification
around
events
coming.
We
should
make
sure
that
we're
consistent
across
all
the
signals
yeah
I
like
that,
though,.
A
So
I'm
all
for
decentralizing,
where
we
can.
I
think
it's
it's
a
good
idea
generally.
A
The
only
thing
that
I'm
not
sure
about
is
whether
we
will
be
able
to
enhance
the
schemas
in
a
way
that
allows
the
independently
created
metrics
to
properly
to
properly
have
their
own
their
own
schemas,
in
a
way
that
it
is
essentially
it's
the
notion
of
derived
schemas
right.
There
is
the
centralized
portion
which
lives
in
the
specification,
and
there
is
the
the
add-on,
the
additional
portion
that
comes
from
the
the
specific
library
or
specific
application.
A
I
think,
then
we
we
need
that
unless
we,
unless
that
that
exists,
and
that's
that
that
concept
of
derived
schema
exists,
it's
going
to
be
nearly
impossible
to
make
the
schemas
work
in
that
case.
So
I
I
would
want
to
put
a
bit
more
thought
into
this
aspect.
At
least
I
agree
with
the
with
the
other
comments.
I
I
think
you
you're
right
with
everything
you
said
before.
F
Okay,
so
it
sounds
like
there's,
there's
consensus
so
far
that
this
is
the
direction
we
want
to
go.
So
I
think,
given
that
we
can
start
just
thinking
about
next
steps
and
how
to
do
it,
because,
like
tigran
you're
outlining
like
there's
a
set
of
problems
we
have
to
tackle,
I
think
there's
two
more
that
dan
and
someone
else
raised
in
the
issue.
I
just
want
to
make
sure
we're
aligned
that
okay,
this
is
the
direction
we're
gonna
go.
F
We're
gonna,
try
this
we're
going
to
make
this
split
and
if
we're
all
agreed
now
we
start
tackling
those
problems.
But
first
I
want
to
make
sure
everyone
agreed,
because
it
wasn't
clear
to
me
in
the
issue
and
all
the
threads.
If
people
were
against
the
direction
or
against
specific,
like
you
know,
implementations
of
components,
but
if
we're
all
aligned
on
the
direction,
we
can
start
picking
off
pieces
and
tackling
them.
So
that's
good!
That's
all
I
wanted.
C
A
A
Repository
which
removes
an
experimental
concept
called
trace,
config,
which
I
think
never
was
used
as
far
as
I'm,
I
know,
got
the
the
approvals
I'm
about
to
to
hit
the
merge
button.
This
is
the
last
chance
to
object
I'll
wait,
I
guess
another
day
and
if
I
don't
hear
from
anyone,
I'm
going
to
merge
it.
A
Okay,
next
one
is
the
split
transformation
for
the
schemas.
This
is
a
new
type
of
transformation,
so
this
was
triggered
by
the
by
the
change
that
happened
with
one
of
the
system
metrics
where
we
removed
the
direction
attribute,
and
there
is
another
similar
one
that
is
pending
right
now
that
splits
one
of
the
other
existing
metrics
into
a
few,
and
this
is
necessary
before
we
make
the
next
release
before
we
create
the
schema
for
the
next
release.
So
please
take
a
look.
It's
pull
request,
2653-653.
A
We
need
we
either
need
to
measure
this
or
or
or
we
revert,
the
the
the
change
that
split
the
magic
right.
So
I
need
reviews
there.
Let's
take
a
look.
C
I
believe
we
have
two
outstanding
items
that
we
need
to
resolve
before
we
can
declare
a
tlp
1.0
based
on
the
spec
issue,
I'd
like
to
make
sure
we
have
eyes
on
them
and
try
to
come
to
a
resolution.
I
think
particularly
the
suggestion
for
adding
short
keys
to
the
json
encoding
is
something
I
don't
know
that
we've
discussed
at
this
reading
and
it
is
a
very
significant
change
that
I
think
we
need
a
resolution
to
sooner
than
later.
A
So
I
guess
we
have
a
big
time.
Maybe
let's
discuss
that
the
short
keys
as
well.
Given
the
comments
I
saw
there,
there
seemed
to
be
two
possible
ways
to
have
efficient
data
efficient.
I
guess
exporting
from
the
from
javascript
applications.
One
is
to
use
the
the
newly
proposed
compression
api,
which
is
not
available
everywhere,
but
it's
still
available
in
some
of
the
browsers
chromium
based
in
particular,
and
the
other
approach
is
to
use
the
binary
protobufs
and
it
seems
like
there
is.
A
There
are
libraries
which
are
quite
efficient
even
better
than
the
the
building
json.
Apparently,
the
claims
are
given
that
those
two
things
and
given
that
what
I
was
proposing
was
primarily
driven
by
the
by
the
concerns
by
the
performance
concerns,
because
we
needed
to
do
gzip,
which
was
slow,
etc,
etc.
A
C
E
C
A
E
C
I
I
think
that
would
leave
us
then,
with
the
issue
about
enums.
I
know
there
was
some
questions
from
bogdan.
Do
you
need
for
him
to
return
before
we
can
get
resolution
to
that
or
have
we
got
a
resolution?
It's
kind
of
hard
to
follow
the
outstanding
pr
on
that.
A
F
Can
can
we
summarize
that
with
like,
because
we've
had
discussions
on
it
already,
I
believe
in
various
locations.
Can
someone
try
to
collate
the
discussion
and
where
it
stands
and
like
the
major
points,
because
that
would
really
help
us
in
this
discussion,
like
let's
focus
on
the
major
question,
as
opposed
to
like
fiddly
bits
of
that
I
was
looking
at
the
revisited
noon.
F
Values
and
like
it
looks
like
this
will
break
significantly
code
apis
to
do
but
shouldn't
break
the
binary
protocol,
and
I
just
want
to
make
sure
that
we,
we
know
what
trade-offs
we're
making
and
that
they're
all
elucidated,
and
it's
not
clear
in
that
document.
What
the
what
we
need
to
be
discussing
to
make
progress.
A
So
for
the
num
names
and
values
right.
First
of
all,
this
is
not
a
required
change.
It
doesn't.
I
guess
it's
not
a
feature.
It's
not
a
new
capability,
it
doesn't
really
add
any
value
beyond
simply
making
things.
Look
more
consistent
in
the
protobuf
definition
right
functionally
nothing
changes
there.
A
For,
because
of
that,
I
I
guess
I
I
I'm
not.
I
guess,
there's
no
strong.
I
guess
need
to
to
make
this
happen
right.
So
I
don't
know
if
the
consistency
argument
here
is,
is
I
guess,
a
strong
enough
argument
to
to
break
even
the
the
compiled
right
for
further
languages
which
depend
on
that?
So
really
it's
just
kind
of
more
like
a
cosmetic
cosmetic
change
in
the
protobar
file
itself
and
well
and
in
the
code
that
uses
that
the
compiled
symbols
and
not
not
not
a
protocol
or
functionality
argument
at
all
right.
A
F
A
F
Yeah,
I
know
that
normally
these
discussions
happen.
The
prometheus
working
group,
but
I
saw
gotham-
was
on
so
I
wanted
to
specifically
ask
this,
because
we
we've
been
having
discussions
on
high
resolution
histograms
and
prometheus
and
I'm
trying
to
get
a
better
understanding
of
what
compatibility
looks
like
for
exponential
histograms
in
prometheus.
F
So
today
in
open
telemetry
we
have
open
or
we
have
exponential,
histogram
implementations.
So
what
I'm
wondering
is
I
want
to
throw
out
the
straw
man.
Does
it
make
sense
for
us
to
try
to
implement
an
sdk
with
our
exponential
histogram
that
exposes
it
as
a
prometheus,
explicit
histogram,
to
try
to
get
an
understanding
of
what
breakage
is
my
fear
here
is,
I
don't
think
we
can
provide
a
backwards,
compatible
solution
that
works
and
I'll
give
you
the
use
case,
I'm
worried
about
so
our
exponential
histograms.
Are
we
don't
define
a
bounds
for
range?
F
We
define
a
initial
like
resolution
level
and
as
we
get
more
data,
we
change
the
bounds
dynamically
and
from
what
you
were
suggesting
in
the
issue.
Every
time
we
do
that
we
break
the
time
series
in
prometheus.
F
So
my
fear
here
is
when
we
get
a
latency
spike,
which
is
the
most
important
bit
of
of
handling
an
exponential
histogram.
Why
we
want
it
is
to
see
what
the
latency
spikes
look
like
more
realistically,
we
would
every
single
time
we
have
that
break
the
time
series
and
I
think
we
can
put
out
a
demo
that
would
show
this
and
try
to
figure
out
what
it
looks
like
in
practice.
It's
possible,
given
the
resolutions
we've
chosen
that
this
isn't
that
big
of
a
concern,
but
it
like
to
me
as
a
user.
F
They
should
settle
over
time,
but
my
fear
is
like
you:
have
an
application
that's
running
successfully
and
you
have
that
you
know
a
lot
of
times
in
our
applications.
We
see
like
a
gaussian
distribution
right
and
then,
when
there's
a
problem,
you
hit
that
other
programmatic
flow.
That
has
the
latency
spike.
That's
when
you
rescale,
but
that's
also
the
interesting
bit
that
you
care
about
so
after
that
spike.
The
application
will
then
have
the
same
bounds
and
everything
will
be
okay,
but
you'll
miss
the
first
spike.
Every
time.
H
Yes,
that
is
that
is
correct,
but
the
hope
is
that
the
rescaling
happens
so
infrequently
that
it
like.
Yes,
you
miss
the
first
spike,
but
after
the
bound
settle
in
place,
things
should
be
fine
and
it.
The
other
reason
we
kind
of
picked
boundaries
is
for
the
prometheus
case,
where,
if
you
use
the
prometheus
sdk-
and
you
pick
a
resolution,
I
think
it
stays
consistent
over
time.
H
Like
you
kind
of
pick
the
scale
at
the
beginning
then
rescaling
dynamically,
and
if
you
do
that
for
the
prometheus
use
case,
you
can
still
scrape
it
with
the
prometheus
and
that
works,
which
is
why
we
want
to
keep
the
bounds,
but
for
the
open,
telemetry
use
case
if
it
kind
of
resets
every
few
hours
or
if
it
rescales
every
few
hours.
That
would
be
not
very
useful.
I
agree.
F
F
So
we
need
to
figure
out
how
to
make
this
kind
of
work
with
prometheus
effectively.
I.
G
Have
a
question
josh,
so
so
in
some
cases
maybe
the
instrumentation
library
could
be
buggy
or
maybe
the
time
timer
is
not
accurate.
G
We
we
could
get
a
very
small
number
that
is
not
zero
and
when
we
also
like
shrink
the
precision
to
cover
cover
more
dynamic
range,
would
that
have
a
temporality
associated
so
which
means
maybe
in
the
like
in
five
minutes.
We
have
this
very
inaccurate,
but
very
large
dynamic
range
buckets,
but
after
five
minutes
when
the
outliners
are
gone,
we're
back
to
normal,
or
we
consider
this
as
a
poison
like
once.
You
have
something
that
is
super
large
or
very
small,
but
not
zero,
then
you're
doomed.
F
Yeah
we
we
currently
it's
the
taint
model,
so
basically
over
the
course
of
the
application
you
expand
range,
but
we
never
shrink
back
down.
C
B
You
know
spikes
sort
of
tainting
the
the
data,
so
I
know
that
that's
a
tough
one
to
sort
of
map
into
cumulative
temporality
for
this
particular,
because
you
know
the
the
exactly
the
problem
you're
describing,
I
believe,
the
the
prometheus
document,
which
is
still
in
a
I
think,
a
word
document
somewhere
that
that
bjorn
circulated
talks
about
essentially
a
reset
interval
that
makes
the
prometheus
data
type
a
lot
like
a
delta
temporality,
but
but
instead
of
being
like
on
a
one
window,
sort
of
reset
interval,
it's
more
like
a
one
hour
or
you
know
like
so
the
idea
would
be.
B
I
think
the
idea
was
you
can
reset
this
thing
every
every
now
and
then,
and
that
and
that's
kind
of,
like
development
work
for
prometheus.
As
I
understood
it,.
G
Yeah,
so
my
my
gut
feeling
is
whatever
temporality
and
sliding
window
we
use
to
calculate
the
histogram.
We
need
some
way
to
avoid
the
developer,
making
a
random
mistake
and
all
of
a
sudden
that
histogram
got
ruined
forever,
and
in
that
case
they
have
to
invent
a
different
name.
F
Okay,
so
that
I
I
agree
with
all
of
that,
but
coming
back
to
the
original,
like
discussion
of
how
we
integrate
with
prometheus,
I
guess
I
should
ask
a
second
question
of
gotham.
Are
we
planning
to
allow
bucket
ranges
to
change
for
exponential
histograms
in
new
prometheus,
so
not
backwards
compatible
prometheus,
but
like
new
prometheus?
Is
that
going
to
be
a
thing
that
we're
allowed
to
do
for
prometheus.
H
I
think
so,
but
I
will
get
back
to
you
on
the
issue
about
that,
but
I
think
that
even
prometheus
implements
rescaling
the
histogram
okay.
This
is
awesome.
B
This
is
also
my
understanding,
I
that
but
the
difference
here-
and
there
is
a
real
question
that
I
think
we
deserve
to
answer
as
a
group
which
is
that
the
prometheus
plan,
because
of
its
cumulative
nature
and
its
sort
of
desire
to
not
reset
most
of
time
is,
is
going
with
a
sparse
encoding,
so
that
there
are
span
runs
that
have
dense
regions
and
then
gaps
and
dense
regions
and
gaps,
and
this
is
one
way
that
you
can
have
support
for
high
resolution,
with
lots
of
zeros
in
the
middle.
B
What
we
don't
have
right
now
is
the
kind
of
specification
for
like
the
way
we've
written
for
what
you
know,
how
to
encode
the
data.
So
it's
going
to
become
a
problem
where
we
don't
know
how
to
to
output
prometheus
data,
even
though
we
have
exponential
histogram
data
that
has
all
the
same
boundaries.
It's
just
that
we
don't
know
exactly
what
to
do
to
create
this
sparse
representation.
B
So
I
guess
we
need
some
sort
of
like
algorithm
to
generate
one,
because
you
know
it's
gonna
have
to
decide
when
to
put
a
gap.
How
big
does
a
gap
have
to
be
to
make
it
a
gap
and
so
on?
I
I
know
that
we
do.
We
can
easily
get
gaps.
You
know
if
I,
if
I
say
I
have
100
buckets
in
my
histogram
and
I
put
in
two
values:
they're
going
to
end
up
at
the
far
ends
of
the
array.
B
That's
just
the
way
it
works,
so
I'll
have
I'll
have
a
bunch
of
zeros
more
or
less
so
these
questions
should
be
answered
and
it
would
look
like,
I
think,
essentially,
a
translation
between
dense
and
sparse
representations.
B
I
also
want
to
step
back
just
a
little
bit.
The
original
issue
that
gotham
filed
was
about
our
inclusivity
on
the
boundaries
and
that's
the
issue
that
I,
the
proposal
that
I
had
come
up
with
was
to
change
that
to
accommodate
their
desires,
and
I
think
we
should
continue
going
in
that
direction,
like
the
boundary
condition
whether
it
falls
right
or
left
up
or
down.
B
I
think
there
are
technical
arguments
in
favor
of
one
way
or
another,
but
like
it's
also,
it's
there's
so
much
history
there
that
the
technical
arguments
just
don't
matter
there
was
there
were
three
options
that
I
looked
at
in
that
pr.
In
that
issue,
and
and
one
of
those
options
I
really
don't
like
and
it
is,
it
just
makes
it
a
little
harder.
So
I'm
rejecting
that
third
option,
because
I
think
it's
unnecessary
complexity
but
and
if
prometheus
ends
up
off
by
one
relative
to
us.
B
I
think
we'll
have
made
a
good
decision,
but
I
think
there's
also
time
for
prometheus
to
consider
an
off
by
one
change.
Possibly
that
would
be
better
for
all
of
us,
having,
I
think
at
least
shown
the
technical
reason.
B
Why
I
like
the
off
by
one
where
it
is
for
us
today
so
anyway
the
the
pr
that
I
sent,
which
I
still
want
to
get
everyone
to
agree
to,
is
just
to
change
the
boundary
conditions
we
write
in
that
exactness
is
optional,
so
you
actually
don't
need
to
take
it,
but
take
this
advice
at
all.
B
You
know
if
you,
if
you
ignore
this
change,
it's
still
correct
in
my
opinion,
because
we
never
said
you
had
to
be
exact
and
that
the
exact
answer
on
the
boundaries
was
always
a
little
uncertain
for
us
in
the
in
the
present
spec.
So
all
we're
doing
is
saying
you.
You
have
the
option
to
be
exact
and
we
should
follow
prometheus
when
we
are
exact,
that's
it
basically,
and
as
far
as
the
cost
and
the
complexity
of
the
code,
it's
slightly
more
complex.
The
cost
is,
I
think,
negligible.
F
B
F
No,
my
my
question
is
more
fundamental.
It
is,
should
we
be
declaring
exponential
histograms
as
backwards
compatible
with
explicit
bucket
histograms
in
hotel.
I
like
prometheus,
says
that
they
want
to
do
that,
but
when
we
were
looking
at
that
specific
comment
on
this,
I
I
feel
like
the
way
we've
designed
our
exponential
histogram
buckets.
We
should
never
recommend
them
with
explicit
bucket,
given
how
this
breakage
would
work
in
practice
right.
So
we
could
like
demo
this
and
show
this
off,
but
that
was
the
question
I
was
going.
F
After
of
it
looks
like
we
should
never
ever
recommend
users
use
exponential
histograms
in
hotel
with
explicit
buckets
in
prometheus,
so
that
backwards
compatibility
thing
that
prometheus
wants
to
do.
We
would
not
recommend,
whereas.
B
My
understanding
was
that
the
backwards
compatibility
desire
was
of
the
query,
so
that
old
queries
would
work,
whether
you
had
new
data
or
old
data,
however,
that
that
only
works
when
the
query
was
for
the
power
of
two.
Otherwise
there's
just
no
exact
representation
in
you
know
decimal
floating
point.
That
said
that
you
know
for
powers
of
two
other
than
the
the
even
ones,
but
I
think
that
doesn't.
H
Matter,
I
think
what
josh
is
suggesting
is:
if
somebody
declares
exponential
histogram
in
hotel,
sdk
and
an
older
prometheus
is
scraping
it
we
don't
expose
fixed
bucket
histograms
like
prometheus.
We
basically
maybe
just
drop
that
exponential
histogram
in
the
prometheus
v2
representation.
B
B
And
I
think
josh
is
looking
for
a
quick
answer
to
the
question
which
is:
if
we
have,
if
we
are
getting
to
the
place
where
sdk's
hotel
sdks
are
configured
with
exponential,
histogram
and
and
we're
expecting
somewhere
along
the
pipeline
someone's
going
to
say
how
do
I
get
prometheus
remote
write
out
or
how
do
I?
How
do
I
export
prometheus
openmetrics
and
neither
will
have
a
good
answer.
H
We,
like
small
update,
we
are
the
first
pr
for
remote
right
for
exponential.
Histograms
is
mods.
We
are
testing
it
out
and
like,
but
what
I'll
do
is
I'll?
Try
to
document
as
much
as
possible
in
a
markdown
file
in
the
prometheus
repo,
the
state
of
current
histograms
and
remote
right
and
everything
so
that
the
community
can
collaborate.
H
B
Josh
when
I
was
prototyping
the
exponential
histogram
I
in
the
collector,
I
did
at
one
point
write
a
converter
that
would
take
your
exponential
histogram
data
and
and
convert
it
back
into
explicit
data,
but
not
on
every
boundary
that
was
present
in
the
data
using
a
configured
set
of
boundaries,
and
we
could
find
a,
I
think,
a
reasonable
fallback
which
would
would
fall
back
onto
the
decimal
log,
linear
style
of
the
default
boundaries
and
prometheus.
So
the
default
boundaries
of
communication
are
0.005.01.025.
F
Written
down
at
one
point,
yeah,
that
seems
like
the
way
we
have
to
do
backwards.
Compatibility
with
old
prometheus
here,
as
opposed
to
trying
to
expose
buckets,
as
is
that
that's
kind
of
one
of
the
things
I
want
to
tease
into
the
other.
The
other
nuanced
discussion
here
was
just
making
sure
with
prometheus.
You
know
we're
doing
this
dynamic,
ranging
where
we
expand
our
range.
As
we
see
data,
and
I
just
want
to
make
sure
that's
going
to
be
supported
because
to
us,
that's
critical
for
instrumentation
users
do
not
want
to
specify
range.
F
That's
that's!
That's
the
fundam
to
me.
That
was
one
of
the
fundamental
requirements
that
led
to
our
current
design
and
it
if
we
start
having
to
require
range
that
breaks
a
whole
bunch
of
assumptions
we
made
in
our
design
of
exponential.
So
I
just
want
to
make
sure
prometheus
will
support
that
as
a
back
end,
because
that's
that's
critical
user
value
for
us.
B
B
So
for
the
pr
that
of
mine,
that's
waiting
to
change
the
boundaries,
I
think
we
can
wait
a
little
longer.
I
don't
consider
it
breaking
it's,
not
it's
not
great,
but
it's
not
really
breaking
from
my
perspective.
It
wouldn't
shift
the
boundaries
and
the
graph
that
my
users
are
seeing,
for
example.
So
that's
fine.
You
know
like
I
don't
care
about
boundaries
much,
but
we
should
we
shouldn't
wait
too
long.
B
I
think
there
was
a
question
two
months
ago,
one
month
ago,
jack
raised
which
was
like:
when
can
we
mark
this
out
of
experimental-
and
I
just
do
want
to
follow
up
because
we
have
it
working?
It's
it's
in
production,
the
the
algorithm
that
I
that
I
prototyped
is
now
fully
reviewed
by
light
stuff
engineers
and
we
have
released
it
in
an
sdk
that
we
are
in
control
of
that's
a
separate
matter,
but
and
and
there's
now
a
pr
pending
in
hotel
go
to
accept
the
the
data
structure.
B
I
I
you
know
if
that
can
go
forward,
then
the
next
step
for
me
would
be
to
start
adding
collector
support.
I
would
like
to
get
the
statsd
receiver
to
use
this
exponential
histogram,
but
we
should
be
able
to
market
stable
soon.
That's
what
I'm
after.
H
H
So
currently
for
otel,
the
zero
bucket
is
considered,
basically
anything
that's
exactly
zero
or
is
super
close
to
zero.
According
to
whatever
library
libraries
precision
is,
but
in
prometheus
we
kind
of
encode
exactly
what
the
zero
threshold
is
and
we
use
it
in
multiple
ways.
But
one
of
the
main
ways
is
to
kind
of
limit
the
number
of
buckets
in
the
histogram
by
expanding
the
zero
threshold,
and
this
is
something
we've
kind
of
taken
from
dd
sketch,
which
expands
the
I
think,
the
lowest
bucket
in
case.
B
Thank
you.
I
originally
did
express
some
concerns,
but
I
I've
come
around
on
this.
There
was
a
good
discussion
in
one
of
the
prometheus
working
groups
on
on
why
this
maybe
is
not
a
instrumentation
level
issue,
but
a
data
level
issue,
and
anyway
I
do
support
it.
B
That
I
mean
that's
a
good
question.
I
my
my
philosophical
objection
here
was
that
I
think
if
you
have
a
zero,
you
should
just
be
a
zero
like,
like
the
application,
should
round
zeroes
down
like,
and
that
was
my
original
objection.
That
was
the
way
I
understood
it.
This
is
just
an
instrumentation
issue,
but
when
bjorn
explained
it
and
pointed
at
the
dd
sketch
paper
talking
about
how,
if
you
are
constrained,
for
you
know,
precision
and
your
dynamic
range
is
spreading.
B
One
thing
you
can
do
is
is
lose
precision
on
the
bottom
end
by
by
calling
it
zero.
So,
but
but
your
question
about
whether
we
would
want
to
change
our
algorithm,
I
don't
know
how
to
change
the
code.
I've
got
or
what
I
would
do
to
change
the
code.
I've
got
to
do
this
and
I
haven't
thought
about
it,
because
in
my
approach
you
can
always
change
scale
to
to
get
to
back
into
the
sort
of
optimal
the
ideal
condition
so
I'll.
B
This
will
take
some
thought
and
I
I
think,
as
an
optional
feature.
I
think
that
the
reason
that
they're
sending
this
is
they
want
to
be
able
to
pass
through
open,
telemetry
back
to
prometheus
and
get
the
data
that
they
started
with.
I
don't
really
understand
that
the
the
that
this
is
a
high
value
field,
it's
more
of
a
they're
asking
for
this
kind
of
thing.
F
G
I
I
feel
yes
in
some
environment.
If
your
timer
is
not
accurate,
you,
you
might
get
a
very
small
number
and
maybe
unfortunately
it's
not
an
ieee
float
zero,
and
in
this
way
you
might
want
to
set
a
threshold
by
saying
anything
smaller
than
this
very
small
number
will
always
be
considered
as
zero,
and
I
think
it's
platform
and
system
dependent
so
having
this
is
more
like
an
additive
change
to
existing
thing.
B
Right
so
then
you
could,
you
could
reject
values
that
are
too
small
or
you
would
round
them
down.
I
think
yeah
yeah,
but
you
wouldn't
otherwise
change
the
structure.
I
think
that's
the
original
assumption
I
had
when
I
read
the
request
and
the
reason
why
this
needs
to
be
part
of
the
data
is
that
if
you
have
a
suite,
you
know
a
job
full
of
your
application
and
somehow
you've
reconfigured
that
so
you're.
B
Changing
your
zero
threshold
right
now
and
half
of
them
have
one
and
half
of
them
have
the
other
that
you
would
end
up
with
the
right
data.
If
you
follow
the
rules
for
merging
these
data
points,
because
I
had
asked
the
question
like:
why
isn't
this?
F
Yeah,
I
also
want
to
call
out
that
when
it
comes
to
instrumentation
and
metrics,
specifically
histograms,
we
have
the
advanced
users
who
know
what
the
hell
they're
doing
for
instrumentation
and
making
metrics
that
we
should
make
them
they
might
care
about
their
zero
threshold.
But
then
we
have
the
everyday
user
that
just
wants
to
see
a
histogram
and
doesn't
give
a
crap
about
any
of
the
parameters
and
just
wants
to
say
make
it
work,
and
we
are
kind
of
like
from
what
my
understanding
of
our
api
of
histogram
we're
trying
to
optimize
for
that
person.
F
And
so
I
don't.
I
don't
want
us
to
like
start
putting
more
and
more
of
these
required
things
on
the
instrumentation
that,
like
we
don't
behave
well,
unless
someone
fills
it
out
right.
If
that
were
the
case,
I'd
say.
I
think
I
think
we
failed
here
with
that
threshold
if,
if
the
user
always
has
to
care.
B
Another
point,
I
guess,
is
that
you
can
use
an
integer,
valued
value
and
and
choose
your
units
to
make
this
problem
go
away.
So
if
you're
measuring
time
in
microseconds-
and
you
use
an
integer
measurement,
there's
no
zero
value,
that's
below
one!
That's
that's
easy,
easy
thing
to
do,
and-
and
so
maybe
that's
another
reason
why
I'm
not
not
so
excited
about
this
field,
but
but
I
don't
want
to
stand
in
the
way
of
it
either.