►
From YouTube: 2022-08-02 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
B
B
B
The
first
item,
then,
is
a
hotel
sdk
enable
addition
to
the
to
basically
enable
disable
the
sdk
brunei
rounds.
B
A
B
Yeah
totally,
I
think
that
one
of
the
things
is
that
tigrano
mentioned
that
this
should
be.
You
know
some
review
from
all
the
maintainers,
because
this
will
be
affecting
all
of
that.
So
it's
I
could
say
yeah.
It's
both
and
yeah.
Definitely
on
address
comments
here
anyway,
there's
not
anything
else
to
discuss
on
that
front,
because
bruno
is
not
here.
Let's
move
to
the
next
item
and
please.
E
E
E
E
We
need
to
to
to
change
the
the
the
property
into
the
new
value,
and
only
after
that
we
can
add
it
to
the
spec
compliant
compliance
matrix.
I
don't
know
if
you
guys
talked
about
creating
an
optional
column,
so
different
languages
could
opt
in
into
the
property.
B
I
think
the
notion
of
optional
is
already
there.
I
don't
remember
the
details.
I
was
away
for
three
weeks
or
something
like
that
so,
but
I
think
the
notion
of
optionality
is
already
there,
even
if
it's
not
through
a
column.
E
Okay
and
how
is
that
expressed
in
the
column.
D
D
It's
something
that
is,
I
think,
a
useful
tool.
There's
been
discussions
to
try
to
make
it
more
of
an
authoritative
statement,
but
it
is.
It
is
something
that
is
more
of
a
reference
piece
rather
than
the
the
specification
itself
specification
itself
is
the
thing
that
is
the
the
source
of
truth.
D
I
do
want
to
touch
on
a
little
bit.
You
also
said
that
there
was
a
question
of
whether
or
not
it
should
be
an
enum
or
a
boolean.
I
don't
think
that
there's
a
question
rather
than
people
agree.
It
should
be
a
boolean,
but
we
need
to
define
what
a
boolean
is
all
of
the
others.
Don't
booleans
have
not
been
used
before
and
that's
what
tigran's
comment
is
specifically
referring
to,
and
I
think
that's
an
important
one.
D
I
also
think
that
armin
made
a
good
point
that
the
language
of
the
variable
is
important,
that
currently
it's
defined
as
being
is
an
enable
being
enabled
so
by
default.
If
the
default
is
false
and
false
is
somehow
represented
as
zero
again,
you
need
to
define
what
a
boolean
is.
That
would
mean
that
by
default,
it's
not
enabled.
D
So
I
think
that
there's
also
a
question
is,
if
you
wanted
to
define
this
variable
as
hotel,
sdk,
disabled
or
tell
sdk
enabled-
and
I
think
disable
is
making
more
sense,
and
so
I
think
those
are
the
two
points
that
really
come
to
light
in
the
specification
side
that
need
to
be
addressed.
In
my
opinion,.
F
D
Yeah,
that's
a
good
point.
I
didn't
read
that
one.
I
also
was
there's
this
question.
I've
had
in
the
back
of
my
head
as
to
why
we
need
to
include
this
and
why
it
hasn't
been
an
issue
until
now.
I
know
the
java
sdk
has
it
and
it's
in
an
experimental
state,
but
that
was
there
a
reason
we
wanted
to.
E
So
in
java
there's
contain
there
are
containers
that
can
deploy
multiple
applications
and
some
of
them
might
have
open,
telemetry
and
others
not,
and
these
class
loading
issues
would
be
well.
It
will
have
to
to
address
the
class
loading
issues
if
we
had
a
property
that
could
we
could
disable
and
enable
the
the
sdk.
E
So
that's
one
issue,
the
other
is
that
so
in
practice,
when
you
deploy
this
in
live
applications,
you
might
want
to
deploy
these
on
environments
that
don't
have
observability
star
an
observability
stack
on
them,
and
you
just
you,
don't
want
to
repackage
the
the
application
just
because
you
don't
want
to
open
telemetry
on
it,
just
go
to
the
flag
and
disable
it
and
the.
E
The
third
is
that
there's
a
case
for
to
migrate
applications
that
that
had
the
legacy
open,
tracing
into
open
telemetry
and
we
might
want
to
have
the
all
the
classes
in
there,
but
activate
and
deactivate,
like
future,
flagging,
to
see
what
happens
and
that
will
make
it
easier
to
well
debug
and
migrate.
The
applications.
E
No,
this
is
relatively
with
the
the
sdk
itself.
It's
not
agent,
based
okay,.
B
E
So
I
think,
there's
there's
there's
the
expectation
that
the
java
agent
is
used
widely
in
the
java
world,
but
of
at
least
in
quarks.
We
are
not
going
to
use
the
agent
the
agent
itself.
We
are
going
to
instrument
things
ourselves
because
of
the
the
the
way
we
build
and
we
deploy
and
we
have
the
native
mode
and
so
on.
There's
there's
too
many
things
that
we
need
to
change
in
order
to
do
to
use
the
agent.
E
B
Yeah
yeah,
that
makes
sense.
I
think
it's
just
just
for
clarity
purposes.
You
know
like
what
components
and
how
those
components
are
working
so
yeah.
Probably
we
will
need
somebody
from
java
team
that
you
know
they
can
explain
what
this
environment
variable
is
exactly
doing
for
java
for
the
sdk.
So
we
can.
You
know,
oh.
F
F
What
I
think
we
really
need
in
this
pr,
though,
is
a
better
explanation
of
what
problem
is
it
solving,
and
why
is
it
needed,
because
this
feels
like
something
that
application
authors
can
do
easily
themselves
as
well,
if
their
application
is
one
that
needs
it,
you
know
in
every
sec
that
I've
seen
you
end
up
with
a
single
routine
that
governs
your
initialization
of
the
sdk.
If
you
put
a
guard
around
that,
you
don't
initialize
it,
you
get
the
default,
no
ops
that
come
with
the
apis.
B
Well,
either
way,
I
think
that
there's
some
that's
some
initial
feedback,
and
probably
you
want
to
iterate
on
those
comments
that
we
made
it
feels
like.
We
don't
have
enough
people
also.
That
could
comment
on
the
remaining
points
here.
So
probably
we
need
to
continue
iterating
on
this
offline,
daniel
dalam.
A
Yeah
I
mean
I
could
just
say
it
out
loud.
I
I
just
think
it's
interesting
that
in
most
cases
I
I
typically
expect
code
to
supersede
environment
variables.
So
if
there's
a
conflict,
I
almost
always
think
the
code
should
win,
but
it
in
this
case
the
environment
variable,
doesn't
work
if
the
code
is
more
important
than
the
environment
variable,
and
I
I
can
just
see
confusing
situations
where
developers
looking
at
the
code
and
is
like.
Why
is
this
not
working
when
there's
just
an
environment
variable
accidentally
set
somewhere?
A
It's
not
not
a
blocker
or
anything
like
that.
It's
just
something
that
I
thought
of.
A
E
A
Yeah
I
mean
that
that
seems
reasonable.
I
I
guess
I
share
the
same
concerns
as
others
around.
Does
this
even
need
to
be
implemented
yeah,
I
don't
feel
strongly
one
way
or
the
other
about
it.
Honestly,
I
think.
F
If
we're
to
add
a
warning,
then
we
open
new
cans
of
worms.
Like
what
mechanism
do
we
use
to
emit
that
warning?
How
do
we
avoid
stepping
on
your
application,
logs
or
messing
with
their
format,
because
there
are
any
concerns
we
have
was
trying
to
emit
information
out
of
the
sdk
kind
of
exaggerates?
That.
B
Okay,
for
the
sake
of
time,
maybe
we
can
move
on
unless
there's
something
important
that
can
be
still
discussed
on
this
one.
Let's
continue
discussing
that
offline
or
we
can
come
back
after
the
call
yeah
sorry
after
all,
the
points
in
the
gender
are
done.
Sure
thanks
very
much.
Thank
you.
Yeah,
okay,
moving
on
job
partial
success
got
more
approvals.
Is
there
anything
preventing
these
prs
from
be
merged?
We
have
four
approvals
on
each
one.
B
Yeah
I
don't
know
any
of
them.
World
approvers
don't
have
any
feeling.
I
think
it's
it's
fair.
I
think
this
has
been
these
fair
prs.
Having
opened
for
long
enough.
C
Yes,
I
think
we
got
so
I
we
did
the
work
from
from
our
last
discussion,
so
I
think
now
we
have.
We
have
a
good
consensus
on
things.
I
just
just
put
it
here,
so
it's
it's
out
there.
If
and
anyone
really
opposed
to
it,
they
can
they
can
voice
their
opinions
now.
Otherwise
I
think
it.
I
think
it
should
be
ready
to
be
to
go
forward
with
it.
Yes,.
B
Yeah,
that
seems
fair.
We
can
either
do
it
now
or
by
the
end
of
the
day
in
case
somebody
opposes
but
yeah.
C
A
B
That's
just
fine
yeah
either
way
yeah.
I
think
that,
especially
because
of
these
two
pr's
that
have
been
opened
for
long
enough,
as
I
mentioned
before,
so
it's
probably
more
important
to
just
get
some
actual
traction
there,
especially
given
the
actual
approval,
sir
okay.
So
please,
if
anybody
has
any
opinion
against
this,
please
raise
it
today.
Otherwise,
later
today
we
will
be
merging
those
ones.
B
Nice
thanks
so
much
for
that
next,
one
dashboard,
prometheus
name
is
space
and
scope,
attributes.
G
Hey,
let
me
present
quick
cool.
So
last
week
a
question
came
up
about,
what's
remaining
for
the
prometheus
exporter
completeness,
and
so
I
worked
on
this
this
past
week
and
wanted
to
quickly
introduce
it
here.
G
G
So
if
you
have
opinions
on
naming
the
more
the
merrier
right,
the
second
thing
I
wanted
to
share
is
what
we
actually
want
to
do
with
this
short
name:
scope
attribute,
which
is
this
one
here,
and
there
are
sort
of
three
different
levels
of
complexity
that
we
could
take
on
here.
G
And
I
wanted
to
talk
about
the
second
and
third
just
to
sort
of
gauge
whether
people
think
the
added
complexity
is
a
good
idea
or
a
bad
idea.
But
basically
it
would
allow
us
to
actually
round
trip
the
instrumentation
scope,
name
version
and
other
attributes.
If
you're,
using
an
open,
telemetry
collector
to
scrape
these
metrics.
G
Yes,
okay,
great,
I
should
have
asked
the
beginning,
I
suppose
it
would
add
an
info
metric
that
has
all
this
that
contains
the
instrumentation
library
name,
that
contains
the
virgin,
sorry,
the
version
and
any
additional
attributes
that
you
have
on
your
scope
and
then
because
we
have
this
info
metric
in
the
prometheus
receiver
in
the
collector,
we're
actually
able
to
remove
the
prefixes
from
metrics
and
then
add
the
attributes
that
we
find
in
that
in
this
additional
prefix
hotel
scope
info
metric
as
the
instrumentation
scope
itself.
G
C
Joe,
yes,
I
I
yeah,
I
was
looking
at
the
oprs.
So
apart
from
the
suggestions
that
you
made
with
the
scope
how
to
name
it,
I
I
wondered
if,
if
we
considered
also
adding
to
this
the
same,
let's
say
namespace,
where
the
version
and
the
name
is
because
it
seems
that
this
short
name
is
going
to
be.
C
G
So
that
was
actually
the
initial
proposal
and
we
added
scope
attributes
explicitly
in
order
to
support
this
feature.
First
and
foremost,
so
we
did
consider
that.
But
I
suppose
implicit
in
my
assumption
here
is
that,
because
we
went
down
the
route
of
adding
scope
attributes
for
this,
that
we
wanted
this
to
be
a
scope
attribute.
C
H
That's
a
good
point.
I
can
see
both
sides
of
that.
Thank
you,
david
for
the
presentation.
I
have
a
question
about
whether
this
feature
is
something
that
might
be,
I
guess,
widely
applicable
independently
of
prometheus
and
the
question
comes
down
to,
I
think
something
like
in
hotel.
We
have
instrumentation
library
and
we
have
name
and
we've
we've
given.
H
I
believe,
we've
given
the
definitions
for
what
it
means
when
you
mix
multiple
libraries
with
the
same
metric
name
and
yet
a
user
may
have
very
good
intentions
of
sort
of
separating
two
libraries,
I'm
going
to
say,
use
the
same
instrumentation
library
in
one
place,
I'm
going
to
use
it
to
count
beans
and
in
one
place
I'm
going
to
use
it
to
count.
I
don't
know
something
else
and
like
those
now
I'm
saying
they're
different.
The
question
is
whether
I
can
benefit
from
this
namespace.
H
H
Yeah,
I
guess
what
it
seems
to
me
like-
is
that
if
you
didn't
have
a
feature
here
and
you
were
required
to
do
that,
somebody
might
make
a
like
a
fairly
hacky
change
to
the
instrumentation
library
to
allow
you
to
pass
in
a
prefix
and
then
I'm
going
to
say,
here's
my
instrumentation
library
constructor.
I
take
as
my
constructor
argument
prefix
option,
which
lets
me
modify
the
metric
name
of
every
metric
inside
that
library
and
you
can
totally
do
the
same
for
spans.
H
Every
span
in
this
library
is
going
to
have
a
new
name,
because
I
don't
want
them
grouped
together
for
some
reason,
because
I've
done
something
very
different
with
the
library
being
instrumented
and
in
that
case
it-
and
I
think
this
is
also
implied
by
one
of
your
earlier
statements
about
the
prometheus
translation-
is
that
if
the
metrics
data
or
the
trace
data
comes
in
with
a
universal
prefix,
is
it
the
same
as
if
I
had
put
some
like
special
property
into
my
scope?
That
says
everything
here
has
a
prefix.
H
In
other
words,
is
there?
Is
there
like
a
translation?
I
can
write
from
no
prefixed
metrics
with
a
scope,
property
or
scope
field
to
no
scope
field
with
prefixes
applied
to
all
the
metrics
or
all
the
spans
or
whatever,
so
that
we
can
define
this
feature
of
yours
without
reference
to
prometheus.
G
H
C
I
think
one
thing
that
tiger
said
it
was
somewhat
interesting
is
that
if
we
go
with
the
prefix,
I'm
not
sure
if
it's
completely
related
what
josh
was
saying
but
but
so
like.
If
we
go
with
the
with
the
with
the
prefix
like
scope
that,
because
we
have
this
other
issue,
that
is,
that
is
there
for
a
while
about
how
to
flatten
attributes
when
exporting
to
non-dlp.
C
G
G
C
A
C
Might
be
able
to
do
it
if
you
fix
property
empty
so
that
might
make
the
table
generation
work
without
this
dot.
So
if,
if
we
decided.
B
By
the
way
you
were,
your
volume
was
very
low,
so
we
could
barely
hear
you
just
for
yourself.
C
Is
it
better
now
I
don't
know
what's
going
on
with
my
microphone,
yep,
okay,
but
was
it
that
do
you
want
me
to
repeat
it
again
or
is
this
is
okay.
C
No
actually,
no,
no
in
the
emo
file
you
just
instead
of
the
the
there's,
the
id
and
prefix
property.
So
you
still
keep
the
prefix,
but
you
leave
it
empty.
Just
use
an
empty
string.
C
B
H
H
So
there's
one
change
here
that
has,
I
think
it
has
enough
approvals,
but
I
don't
I
don't
doesn't
feel
like.
It
really
has
enough
approvals,
and
I
wanted
to
see
if
everyone
else
agrees.
It's
listed
first
there
and
then
I've
shown
a
couple
of
drafts
for
what's
implied
by
that
change
in
the
goaling
mapping
functions
as
well
as
the
specification
for
the
protocol,
which
is
just
a
comments,
only
change
those
of
you
following
this
discussion
a
month
or
so
ago.
I
think
it's
probably
a
month
a
half
ago.
H
Someone
here
asked
what
we
would
need
to
do
to
get
that
data
structure
marked
stable
in
the
in
the
intervening
time.
We've
done
quite
a
few
things,
so
one
thing
is
that
lightstep
is
put
this
into
production.
The
code,
that's
actually
under
review
here
in
the
I
think
the
fourth
bullet
is-
has
been
reviewed
by
lightstep
engineers.
H
It's
being
well
proposed
as
a
merged
to
the
hotel
go
repository,
and
the
reason
I
want
to
do
that
is
that
I'd
like
to
use
it
from
the
collector
and
I'd
like
to
put
it
somewhere.
Sort
of
official
for
open
source
currently
is
residing
in
the
hotel
launcher
for
go
of
light
steps
repository,
and
I
just
want
to
make
that
available,
so
that
people
can
see
it
if
we're
going
to
need
help
getting
that
reviewed,
because
the
hotel
go
maintainers
and
approvers
are
quite
busy
with
metrics
sdk
work.
H
Lastly,
the
prometheus
team
has
also
asked
for
something
called
zero
tolerance
and
it's
being
discussed
here
on
the
fifth
bullet,
which
is
a
way
that
we
can
avoid
almost
like
I'd,
say,
extremely
small
or
nonsensical
measurements,
which
sounds
like
something
that
you
may
maybe
consider
optional.
But
it
helps
when
we
consider
the
sort
of
long-term
impacts
of
range
on
these
exponential
histograms.
So
please
take
a
look
at
all
of
those
and
that's
everything
I
had
to
say
about
exponential,
histograms
I'll
pause
to
see.
H
H
Okay,
so
that
was
all
just
calling
for
attention
and
I'm
trying
to
get
that
unblocked
a
little
bit
the
last
the
next
bullet.
I
had
more
or
less.
Thank
you
to
david
for
presenting
the
topic
about
prometheus
compatibility.
H
That
was
one
of
the
things
that
came
out
of
my
call
from
last
week's
sig
call
here
to
say
really
what's
left
for
us
for
metrics
1.0
and
I've
been
talking
to
a
bunch
of
you
in
the
last
week.
Just
to
let
you
know
what
I've
learned.
There
are
a
few
areas
in
the
specification
that
we
think
need
to
be
written
down
the
ones
that
I'm
aware
of
that.
Don't
have
issues
I'll
get
filed
this
week.
One
of
them
is
about
certain
aggregator
combinations
that
may
or
may
not
be
considered.
H
Ill-Specified
one
is
about
where
the
range
checks
happen,
whether
they're
in
the
instrument
or
the
aggregator,
and
then
I've
summarized
this.
We
have
sort
of
three
three
sdks
that
are
really.
It
looks
to
me
close
to
or
absolutely
stable,
and
at
that
point
we've
got
enough
sdks.
H
So
at
this
point
I'm
sort
of
saying,
let's
like
continue
looking
at
these
issues
and
get
them
closed
out,
we
should
be
able
to
mark
this
1.0
pretty
soon,
and
I
I
know
that
the
only
remaining
question
that
I
may
get
from
at
least
the
members
of
the
technical
committee
that
I've
discussed
this
with
are
what's
left
for
exemplars,
because
I
know
that
that's
important
to
some
of
you.
I
Hey
hi,
everybody
I'm
quite
new
to
this
project,
but
I
thought
I
might
ask
us
a
question
that
I
ask
also
in
the
github
issue,
but
maybe
it's
easier
to
explain
on
zoom,
and
I
saw
that
the
protocol
has
support
for
the
summary
data
type
and
I've
seen
that
the
api
itself
does
not
support
it,
and
so
first
I
wanted
to
know
what
was
the
motivation
for
for
that,
and
the
second
thing
that
the
entire
my
motivation
for
being
here
and
asking
that
is
that
I
currently
work
on
a
apache,
pulsar
and
apache
bookkeeper
and
we
are
considering
replacing
the
entire
metric
stack
to
something
else,
and
I
was
thinking
about
doing
converting
everything
into
open
telemetry.
I
But
I
I
stumbled
on
an
issue
because
it's
quite
an
old
code-
and
it
has
a
lot
of
summary
usages
and
not
having
a
support
for
summary-
gives
a
pretty
big
blocker
for
me.
So
that's
my
questions.
H
I
can
take
this
question.
Thank
you
stuff.
I
did
respond
quickly
in
the
github
yesterday.
You
know.
We've
got
a
similar
issue
surrounding
what
we
call
the
synchronous
gauge
instrument,
it's
one
that
we
haven't
really
specified
and
it
exists
in
the
protocol.
In
some
sense,
it's
not
quite
the
same
issue
as
the
one
you
presented,
but
it's
one
where
it's
it's
something
that's
causing
a
lot
of
difficulty
for
migration.
H
The
the
reason
for
your
first
question:
why
is
that
open
telemetry
started
out
with
this,
I
guess
you'd
say:
promise
of
separation
between
the
api
and
the
sdk,
so
that
we
were
requiring
ourselves
to
have
a
definition
of
the
meaning
for
each
piece
of
the
api
when
it
came
to
histogram
and
summary
it
looked
like
the
meaning
was
the
same
meaning.
H
But
otherwise
we
let
you
configure
different
aggregations
on
those
instruments
using
this
other
piece
of
the
the
specification
called
views,
and
so
I
put
some
links
sort
of
to
some
of
the
open
issues
right
now
surrounding
where
the
sdk
stands.
As
far
as
exactly
what
you
need
here,
which
is
not
completely
there,
you
know
we
have
a
way
to
configure
views,
but
you
have
to
know
before
you
configure
the
sdk,
the
name
of
the
instrument
that
you
want
to
sort
of
configure.
H
H
The
way
that
you
be
the
way
that
you
implement
the
prometheus
style
summary
that's
in
the
otlp
protocol
can
only
be
defined
by
a
prometheus
library
and
the
openmetrics
specification
says
something
quite
loose
about.
You
know
five
or
ten
minutes
worth
of
time
being
used
to
calculate
the
summaries
and
so
on.
What
I'd
like
to
see
for
users
in
your
position
is
actually
that
we
can
import
directly
that
code
from
prometheus
client,
for
example,
the
code
that
implements
the
aggregator
in
in
go
it's
one
of
bjorn's
libraries.
H
You
know
you
don't
even
need
to
implement
the
to
import,
the
prometheus
client
library,
it's
just
the
aggregate,
the
data
structure
that
they're
using
to
implement
summary
and
then
there
would
be
limitations
on
that,
because
prometheus
only
supports
cumulative
temporality.
H
H
If
you
have
a
temporality
configured
somehow,
and
so
each
sdk
would
then
need
to
provide
you
a
way
to
register
an
alternative
aggregator,
and
we
need
to
solve
some
of
the
other
open
questions
that
I
think
are
going
to
be
post
1.0,
the
one
that
that
I
gave
you
a
link
in
the
github
issue,
2,
which
is
called
api
hints.
H
What
is
what
we've
been
calling
a
mechanism
whereby
you
can
essentially
bypass
the
views
mechanism
and
go
directly
to
saying
what
you
want
as
a
programmer
and
so
that
you
could
say
I'm
going
to
construct
an
instrument
now
it
will
be
called
a
histogram
because
it's
being
used
to
take
measurements,
and
I
want
to
configure
it
with
the
summary
instrument.
We've
done
the
same
here
at
lightstep,
but
not
with
a
summary.
H
We
wanted
the
min
max
sum
count
aggregator,
which
is
a
very
cheap
form
of
histogram,
and
in
that
case
I
was
you
know,
I'm
working
with
an
alternative
sdk,
so
I
just
hard
coded
it,
but
in
the
long
term,
we're
going
to
need
sdks
to
let
you
essentially
register
user
provided
aggregations,
potentially
or
or
that
we
actually
standardize
on
importing
the
prometheus
summary
aggregation
to
allow
that
to
be
used
as
an
option.
I
And
you're
saying
that,
if
suppose,
I'm
able
to
provide
that
specific
aggregator,
which
is
the
summary,
I'm
also
able
to
specify
somehow
somehow
to
translate
it
to
the
summary
data
model
that
will
be
sent
over
in
the
protocol
to
the
collector.
H
I
think
that's
a
I
mean,
that's
a
question
of
the
sdks
organization.
My
understanding
is
that
the
java
sdk
actually
probably
does
implement
the
aggregation
code
path.
You
need
to
export
otlp
with
a
summary
data
point.
I
read
that
somewhere
in
this
discussion.
H
I
know
that
the
go
sdk
that
I'm
using
often
has
a
protocol
library
that,
since
it
includes
that
protocol
the
summary
protocol,
if
I
write
that
protocol
message
and
feed
it
into
the
export
code-
path,
it'll
export
but
the
x,
but
the
there's-
no
aggregation
code
path
in
that
glue
between
the
sdk
and
the
exporter.
So
in
this
case
that
some
work
would
be
needed
on
the
general
purpose
sdk
of
each
language.
H
I
I
think
that
the
thing
that
I'm
not
entirely
sure
here
is,
if
summary
stands
on
itself
in
the
data
model.
Why
not
support
it
all
the
way?
Why
only
in
at
the
api
say
you
know
what
it's
a
bit
like
histogram,
let's
use
that
one
and
that
creates
small
house
developer
experience
for
like
someone
like
me
that
just
want
the
summary
right-
and
I
guess
I'm
not
the
only
one
that
has
legacy
open
source
application
that
wants
to
migrate
into
open,
telemetry
and
needs
to
do
it
and
not
like
reinvent
the
wheel.
Every
time
right.
H
I'm
not
convinced
that
I
I
guess
I
would
say
that
when
this
project
started
there
has
been,
I
would
say,
a
prevailing
wisdom
in
the
monitoring
community,
I'm
referring
to
both
prometheus
and
other
contemporary
systems.
Saying
that
permit
that
the
summary
data
type
is
a
little
bit
discouraged.
We
added
the
data
type
to
the
protocol
so
that
we
can
faithfully
round
trip
between
prometheus
and
otlp.
H
And
have
a
representation
of
that
data,
but
the
fact
that
summary
data
can't
be
aggregated
led
to
leads
to
it
being
discouraged
even
in
the
prometheus
documentation
today.
I
think
that's
part
of
the
reason
why
we
did
what
you're
describing
we
also
have
two
different
expo
two
different
histogram
representations.
H
They
are
different.
We
don't
give
you
different
instruments
for
that
reason
that
they're
the
same
semantics
and
I
think
it's
difficult
to
find
a
meaningful
difference
between
what
it
means
when
you're
summarizing
with
a
summary
instrument
versus
the
histogram
instrument
other
than
that
you're
providing
the
data
type
you
want
in
the
in
the
source
code,
and
I
think
we
should
support
that.
H
I
don't
think
that
I
I
you're
right
that
there's
a
somewhat
of
user
experience
problem.
I
guess,
if
you're,
if
you're,
insisting
on
calling
this
thing
a
summary,
but
I
guess
we
want
to
get
back
to
asking
whether
summary
is
really
a
data
types
that
you
want
to
persist
in
using
now
in
the
monitoring
world
of
today.
I
I
think,
but
let's
just
even
ignore
those
cases,
because
there
are
a
few
only
for
the
migration
and
again
there
are
it's
a
huge
project
migrating
such
a
opal
source
project
that
is
used
by
so
many
people
and
just
imagine
all
the
other
projects
like
apache
age
base.
I
saw
there
are
probably
a
few
more
easing.
The
migration
would
help
over
telemetry
adoption
greatly.
I
So
I
think
that
if
you
already
have
that
in
their
protocol,
I
think
it's
worth
having
it
from
developer
experience
standpoint
having
it
all
the
way,
but
of
course
mentioning
this
is
not
a
recommended
way,
but
it
will
so
it
will
help
the
migrate,
the
migration
of
people
migrating
into
opportunities.
So
much.
H
I
think
that
the
the
counterpoint
there
might
be
that
it
encourages
people
to
migrate
into
a
pattern.
That's
already
been
discouraged
for
technical
reasons
that
many
sort
of
have
been
widely
agreed
to
another
technical
problem
here
is
that
again,
this
is
a
prometheus
data
type
that
we've
literally
just
copied
into
open
telemetry.
C
H
What
I've
seen
in
some
of
those
legacy
systems
that
you're
talking
about
it's
actually
not
instrumentation
done
by
prometheus.
It's
done
by
some
other
library.
Often
it's
using
what
I
what
we
call
here:
delta,
temporality
and
and
I've
seen
that
so
and
the
problem
is
that
and
I'm
familiar
with
kafka,
for
example,
where
you
do
see.
B
H
And-
and
you
can't
use
that
prometheus
data
type
to
express
those
those
metrics,
that's
a
case
where,
from
open
telemetry's
perspective-
and
I
guess
from
the
perspective
of
the
monitoring
systems,
you
were
writing
to
when
the
when
the
instrumentation
was
written
back,
then
it's
like
you're
actually
producing
five
different
metrics
or
seven
different
metrics,
and
that
is
supported
in
open
source.
If,
if
but
we're
going
to
need
sort
of
to
support
custom
aggregations,
if
that's
what
you
want,
I
I
still
think
if
it's
a
mic,
if
it's
a
migration
that
you're
looking
to
do.
H
A
lot
of
control
over
the
upgrade
path
so,
like
I
was
saying
in
my
case,
I
have
upgraded
a
bunch
of
light
steps:
internal
code
to
use
the
open,
telemetry
library
I
had
both
minimax
some
count
aggregators
to
work
around,
as
well
as
synchronous
gauges
to
work
around.
In
both
cases
I
needed
a
hint
to
let
me
control
the
the
behavior.
H
I
was
going
to
get
when
I
construct
the
instrument,
but
it's
like
a
few
pieces
of
code,
because
lightstep
already
has
a
piece
of
code
to
construct
a
summary
and
I'm
just
changing
its
behavior.
By
the
way
we
were
using.
Midmax
sum
count
for
the
summary,
and
it
is
something
where
you
could
decide
to
change
it
into
a
histogram
and
not
break
anything.
You
just
get
more
information
and
I'm
not
saying
our
user
experience
is
great
on
the
product
side,
but
you
could
do
that
and
so
it's
something
we
wanted
to
enable.
H
I'm
afraid
that
if
we
add
a
summary
instrument,
users
are
going
to
use
it
thinking
it's
something
that
will
help
them
monitor
in
the
future
and
and
that's
that's.
The
question
is
whether
we
want
that.
I
would
prefer
to
see
users
switch
to
an
exponential
histogram
and
then
we
can
configure
that
exponential
histogram
to
output
summaries.
If
potentially
using
a
magnet.
You
know
a
specified
algorithm
like.
Is
it
five
minutes
or
ten
minutes?
H
That's
that's
what
we
need
to
settle,
so
we
can
go,
go
calculate
summaries
from
exponential
histograms
pretty
well,
I
don't
think
we
need
a
new
instrument
for
it.
However,.
I
You
think
that
age,
so
you
think
that
at
the
end,
so
you
think
that
at
the
current
state,
it's
possible
for
me
to
have
like
a
summary
class
on
my
own,
that
at
the
end
would
be
might
be
able
to
export.
As
a
summary
in
the
oltp
protocol.
H
I
think
that
I'm
saying
that
that's
the
desired
outcome
that
the
sdks
that
we
provide
as
open
telemetry
kind
of
community
provides
the
default
behaviors
that
we
have,
for
you
know,
limited
limited
set
of
defaults
and
this
behavior
to
do
summaries
until
it's
specified
project
wide,
which
is
you
know,
not
going
to
happen
before
1.0.
H
H
Yeah,
so
my
understanding
was
already
that
java
has
some
support
and
we'd
have
to
look
at
to
the
maintainers
of
that
sdk
to
find
out
more
but
but
yeah.
If
you
could
provide
an
aggregator
class,
I'm
sure
there's
an
aggregator
interface
somewhere
and
there's
got
to
be
some
mechanism
to
tie
it
into
a
view
so
that
how
could
you
configure
it?
That's
a
question
you
know
and
that's
where
we're
missing
a
specification.
H
The
the
name
hints
have
been
given,
but
we
just
haven't
finished
that
work
once
you
have
a
way
to
do.
Hints
then
you're
going
to
provide
your
your
alternate
aggregator
and
just
use
the
hint
and
get
what
you
want.
That's
that's
the
understanding
I
had
and
you
know
I'll
leave
it
open
to
others
to
comment.
I
D
I
don't
I'm
not
a
maintainer
of
java,
but
I
have
looked
a
lot
at
the
code
and
I
thought
that
the
aggregator
interface
was
very
private
and
I
think
that
that's
something
that's
also
left
open
in
the
specification.
We
specifically
reserved
the
word
aggregators
to
expand
the
specification
in
the
future
to
provide
just
this
kind
of
support,
but
I
don't
know
if
it
exists
currently.
A
D
I'm
not
entirely
sure
if
you
couldn't
just
wrap
the
the
histogram
class
itself
and
it
would
produce
the
correct
thing
with
some
sort
of
like
summary
interface.
But
I
I
I
also
feel
a
little
unqualified
to
even
comment
on
this,
because
I'm
not
in
the
java
sig
that
often.
H
F
H
Guess
the
question
I'd
like
to
ask
maintainers
of
any
any
of
the
sigs
metrics
sdks
or
whether
you
think
it
is
either
valuable
or
tremendously
difficult
to
add
support
for,
I
guess
optional
aggregation,
which
means
aggregators
written
in
third-party
libraries
that
can
be
if
they
are
written
to
the
appropriate
interface
and
produce
a
well-specified.
Existing
output
data
type
will
work
and-
and
that's
that's
a
question.
D
Yeah,
that's
a
that's
something.
I've
been
thinking
a
lot
about
and
it's
going
to
be.
I
think
it's
valuable.
I
also
don't
know
it's
going
to
be
hard
to
write
specification
for
it,
because
I
think
the
design
of
this
aggregator
type
or
this
aggregator
interface
that
you
would
produce
like
what
you're
saying
like
having
some
sort
of
functional
methodology
around
it
and
then
producing
some
well
established
data
type,
is,
is
very
different
in
different
languages.
D
So,
far
from
what
I've
already
seen,
I
do
I
it's
gonna
really
depend
on
how
storage
is
handled
of
the
data,
how
the
instruments
themselves
are
calling
this
data
type
like
there's
a
lot,
I
think
from
the
languages
I
have
surveyed
so
far
like
it's.
It's
very
different.
D
H
Yeah
tyler,
I
understand
and
I'm
a
lot
closer
to
this,
your
your
code
than
others
may
realize.
So
I
I'm
thinking
of
how
you
know
hotel
releases
an
sdk
at
the
community
sdk
that
might
be
version
1.0.
H
H
Synchronization
questions,
ownership,
questions
all
that
comes
up,
but
but
but
in
doing
so
in
publishing
the
1.0,
artifact
or
series
of
major
versions
for
the
sdk
you
fixed
that
interface.
At
that
point,
can
I
provide
an
implementation
of
that
fixed
interface
that
follows
all
the
rules
set
by
the
go,
for
example,
sdk
and
provide
you
know
another
alternative
aggregator,
the
re,
the
place
at
which
this
comes
back
to
the
common
code
path
has
to
be,
I
think,
either
some
public
interface
of
the
sdk.
H
That's
like
abstracted
data
type
representation
or
it
can
be
the
otlp
data
type.
Well,
no,
it
has
to
be
the
abstraction,
because
otherwise
other
exporters
won't
support
it.
Right
now
for
myself
and
my
my
sort
of
short-term
objective,
you
know
I
took
the
hotel,
goes
http
grpc,
export
code
path
where
it
has
the
protocol
and,
and
it
has
public
methods
I
can
use
to
to
to
use
that
those
those
exporters,
because
those
exporters
support
the
protocol.
I
can
feed
in
a
summary
and
it
works,
and
so
to
me
that's
a
that.
H
You
know
the
hotel
goes
provided
a
very
reusable
and
very
valuable
component.
I
was
able
to
use
a
you
know,
provide
my
own
aggregator
as
a
result,
and
I
think
it
would
be
valuable
to
hotel
to
allow
this
type
of
experimentation
and
third-party
aggregators
yeah.
D
F
I
H
H
They've
already
heard
this
request
15
times,
and
it
might
be
something
that's
nearly
possible
it
does
it
won't
the
the
problem
we
run
into
is
when
you
have
something
that's
non-standard
or
not
specified
as
a
default
behavior
for
all
the
hotel
sdks,
it
becomes
a
little
hard
to
access
the
feature
and
that's
why
I
think
you
should
take
carlos's
advice
and
go
talk
to
that
group.