►
From YouTube: 2022-07-01 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
Okay,
I
think
this
one
jack
already
changed
it
to
global,
open
telemetry,
but
jack.
Did
that
make
sense,
or
did
you
still
want
to
chat
about
sort
of
the
option
of
limiting
global
open,
telemetry
usage.
A
Honestly,
I
I
kind
of
want
to
defer
to
the
instrumentation
experts,
so
you
know
what
types
of
so
I
know
that
the
pattern
has
been
to
pull
in
global,
open
telemetry
a
lot.
You
know
I
noticed
one
of
the
drawbacks
of
that
is
like
when
I
was
implementing.
This
is,
if
you
need
to
reset
it
for
test
purposes,
you
need
to
have
some
sort
of
mechanism
so
that
you
can
re-retrieve
whatever
global
open.
Telemetry
is
configured
at
the
time.
D
Yeah,
I
wonder
so.
I
know
there
have
been
several
requests
at
least
or
a
way
to
query
the
global
to
see
whether
it's
been
set
without
having
to
ask
for
it
right.
I
don't
know.
Did
we
get
that
in
there?
I
don't
remember
what
the
what
the
stated
status
that
was,
but
it
feels
like
this
is
a
case
where
it
might
be
very
useful,
and
I
think
it
might
come
like
be
relevant
for
the
reset
case
as
well.
D
Potentially
that
instrumentation
like
this
libraries,
but
for
agent
instrumentation,
I
don't
care
about
like
that's,
that's
a
whole
other
world.
That's
got
to
use
global,
no
big
deal
library
instrumentation,
though
that
doesn't
have
life
cycle
or
constructor
or
build,
or
anything
that
lets
you
really
customize
it.
D
I
wonder
if
it
would
be
worthwhile
having
kind
of
a
lazy,
a
lazy
pattern
or
it
wouldn't
get
initialized
until
it
was
actually
first
accessed
the
reason
I
say
that
and
maybe
like
we
have
some
sort
of
construct,
that's
built
into
like
some
common
library,
library,
instrumentation
library
or
whatever.
That
thing
is
like
instrumentation
api,
maybe
I'm
not
sure
where
it
belongs,
but
they
would
facilitate
this.
I
just
I'm
trying
to
head
off.
At
the
past,
all
of
the
people
running
into
global
initialization
order.
A
So
I
think
you
can
do
that
with
a
with
a
couple
of
ways,
so
in
this
code
that
lazy
initialization
that
that's
how
it
currently
stands.
A
So
you,
you
inject
this
this
metric
reporter
into
your
when
you're
configuring,
your
kafka,
consumer,
your
kafka
producer
and
the
first
time
that
it
sees
metrics
that
are
sent
to
it
via,
like
the
kafka
client
library
it
will,
it
will
grab
the
meter
from
global,
open
telemetry
if
it's
not
set.
So
I
changed
that
this
morning,
right
down
there
on
73.,
so.
D
Of
have
the
potential
issue
where
now
that
call
to
global
up
until
which
we
get
metered
may
actually
initialize
the
global
without
like
if
it's
the
first
time,
it's
actually
been
done.
If
the.
If
the
user
doesn't
really
understand
how
to
do
the
life
cycle
and
doesn't
initialize
their
global
like
right
away
before
they
spin
up
anything
else,
this
is
going
to
stop
on
it
and
it's
going
to
make
their
open
function,
not
work
right.
A
A
The
original
thing
that
I
did
because
of
that
was
I
had
a
static
setter.
You
know
where
you
have
a
static
method
to
set
your
open
telemetry
instance,
but
you
know,
I
think,
the
I
think
the
feedback
that
trask
gave
is
is
good
feedback,
which
is
that
kind
of
like
creates
a
bunch
of
little
global,
open,
telemetry
type
instances
where
that
state
is
being
managed.
D
Yeah-
and
this
is
where
I'm
I'm
starting
to
lean
towards
people
asking
for
a
way
to
find
out
if,
if
it's
been
config,
if
global
has
been
set,
because
then
in
this
instrumentation,
if
the
global
hasn't
been
set,
you
can
just
you,
can
basically
skip
out
and
not
do
anything
right
and
and
skip
all
of
the
metric
stuff.
If
there's
no
global
registered.
A
D
Because
because
in
this
case,
like
you
wouldn't
want
this
call
on
line
75,
I
don't
think
in
most
normal
cases
like
it
would
be
very
surprising
as
a
user.
If
I
pulled
this
in
and
suddenly
it
was,
it
was
initializing,
open,
telemetry
for
me
and
maybe
pulling
in
random
stuff
off
my
class
path
and
spin.
It
like
it
feels
like
a
negative
user
experience
unless
they
very
carefully
read
the
documentation
which
no
one
ever
will
I
mean
that's.
D
We
I
mean
that
happens
to
us
all
the
time
right,
so
the
more
that
we
can
kind
of
normal
everyday
user
proof
this
stuff,
so
that
they
don't
shoot
themselves
in
the
foot
and
make
it
hard
to
understand
what
went
wrong
because
the
error
they're
going
to
get
when
they
try
to
set
it
then
later,
is
oh
inside
here's.
The
stack
trace
where
it
got
set
before,
and
it's
going
to
be
in
some
this
library
that
they
pulled
in
which
they
didn't
realize
was
going
to
do
that.
D
C
Is
there
any
worry
about
if
this
stuff,
like
this
kafka,
metrics
or
jdbc,
is
initialized
too
early
is
called
too
early
before
they
have,
or
is
that
just
trading
one
problem
for
another
and
better
to
because
if
it's
too
early,
then
they
haven't
really
had
a
chance
to
configure
it.
A
Well,
this
doesn't
get
auto
configured
anywhere.
You
have
to
explicitly
include
this
on
your
your
consumer
producer
configuration.
So
it's
not
like
it's
there's,
no
sort
of
like
detection
on
the
class
path,
and
it's
not.
D
Like
wiring,
this
up
with
spring
and
part
of
your
spring
initialization
does
create
create
an
open
telemetry
instance
and
set
the
global
you're
going
to
have
to
explicitly
make
sure
in
your
spring
world
that
that
happens
before
your
kafka.
Consumer
gets
wired
up
right
and
you're
going
to
have
to
know
that.
That
is
something
you
have
to
do,
that.
D
That
ordering
is
very
important
and
it's
and
it
I
can
tell
you
just
having
gone
back
into
the
world
of
spring
in
the
past
few
months,
like
it's
super
tricky
to
make
sure
you
get
all
the
initialization
in
the
right
order.
If
you
have
these
kind
of
hidden
dependencies
that
are
not
really
obvious
yeah
that
can't
be
expressed
in
the
dag
yeah
exactly
exactly.
A
A
And
you
in
this,
if
you
set
it
to
true,
it
will
like
initialize
if
it
hasn't
been
initialized.
If
you
set
it
to
false
and
there's
no
open
telemetry,
it
can
either
return
a
no
op
or
return
a
or
null
one
of
the
two,
and
in
that
case
all
the
instrumentation
like
this.
Can
it
can
log
in
this
situation,
so
it
can
give
you,
like
the
user,
a
very
clear
warning
that
there
was
some
sort
of
initialization
order
issue
and
they
have
you
know
they
have
no
open
telemetry
instance
yeah.
D
D
That
would
do
that
internally
and
return
a
no
op
until
it's
been
set
and
then
return
the
real
thing
and
then
the
pattern
would
have
to
be
in
these
cases
where
you
need
global.
You
always
access
the
global
through
this
thing
and
then
it
will,
when
it's
ready,
it'll,
be
ready
and
it'll
work.
B
Need
a
boolean,
like
my
recommendation,
would
probably
be
like
having
another
method,
maybe
called
get
or
not
for
now,
and
we
can
deprecate
get
like
now
that
bogdan's
gone,
we
don't
need
that
auto
configure
stuff
anymore.
That's
the
only
reason
we
have
that
there
in
the
first
place,
but
we
just
I
guess
we
can't
duplicate
that
for
agent
users
though,
but
we
would
want
to
move
away
from
the
auto
configured
version
in
the
next
major
release.
I
think,
because
it's
only
causing
these
problems
and
none
of
us
wanted
it
in
the
first
place.
D
Mean
I
think
there
are.
There
is
a
use
case
for
that
full
spi
world,
where
you
just
want
to
call
get
whenever
you
call
it
and
then
there
it
is
it's
ready
to
go.
It's
not
the
world
I
live
in,
but
I
think
there
is.
D
There
clearly
is
a
use
case
for
somebody
to
have
that
be
be
there,
but
but
I
agree
having
a
different
method
that
we
want,
especially
in
our
own
instrumentation,
lean
towards
using
a
different
method,
and
in
that
case,
for
example,
like
this
code
here,
we
would
call
global,
open,
telemetry,
dot,
get
or
null,
and
we
wouldn't
even
initialize
the
meter.
D
B
A
C
That
feels
like
some
debug
level
logging
within
the
sdk
itself,
that
says
hey
you
asked
for
you
know
get.
I
was
thinking
like
get
if
I
like
returning
the
no
op
in
the
other
kit,
like
just
so
that
instrumentation
just
says,
give
me
that
thing,
and
that
works
just
fine
with
the
java
agent.
Also
because
we
have
a
we,
we
do
have
a
open
limit,
a
global,
open
telemetry
that
we
would
pass
back
to
the
user.
D
C
I
I
would
say
just
let's
take
the
simple
route
and
bail
out
instead
of
trying
to
recover
somehow.
D
Later
on,
yeah,
because
I
know,
like
the,
I
think,
the
go:
the
go
global
returns,
you
like
a
a
promise
or
not
a
promise,
but
like
a
a
shim
that
will
then
when
the
global
gets
set,
will
actually
start
working,
and
so
it
gives
you
meters
that
are
backed
by
this
kind
of
shimmy
thing
that
will
late
bind
whenever
someone
actually
initializes
the
global
yeah.
A
So,
okay,
if
if
we
have
this
method
that
returns
null
or
I
think
that's
what
we're
saying-
no
op,
so
I
I
guess,
I'm
a
bit
confused
on
why
why
you
don't
want
a
log
statement
that
would
allow
you
to
detect
that
you
haven't
set
up
global,
open
telemetry
in
time.
A
D
B
D
A
I
think
it
could
become
an
issue
like
the
performance
because
think
about
that.
If,
if
every
time
you
want
to
be
able
to
like
account
for
open
telemetry
not
being
set
up,
it's
not
just
getting
the
meter
that
could
like
leak
into
getting
instruments
as
well,
yeah,
and
so
like
you
could.
C
A
B
B
C
And
that's
already
the
case
for
all
the
ones
where
you
do
inject
the
open
telemetry
instance
already.
So
presumably
this
wouldn't
wouldn't
be
the
only
instrumentation
that
somebody's
using.
So
they
already
need
to
deal
with
that
ordering
for
injecting
the
open
telemetry
instance
to
the
other
library,
instrumentations
yeah.
C
D
I
mean
just
for
the
sake
of
argument
like
what,
if
what,
if
we
and
I
don't
know
how,
how
much
of
a
breaking
change
this
would
be.
But
what,
if
we
thought
about
returning
a
lazy
meter
that
would,
whenever
you
ask
well,
I
guess
you'd
have
to
do
at
the
instrument
level
you
have
to
go
like
every
single
thing.
That's
returned
would
need
to
be
have
a
lazy
like
a
lazy
backing
thing
that
would
initialize
it
for
real.
If
it
was
there,
it
would
be
a
real
pain.
C
And
if
they're
not
registering
open,
telemetry
like
if
they're,
I
see
the
main
problem
being
that
people
won't
do
it
at
all,
not
that
they'll.
Do
it
too
late
register
it
and
call
the
the
register
as
default
as
global.
D
B
B
B
A
A
If
so,
this
is
so,
I'm
not
sure
what
types
of
objects
can
be
put
in
there.
It's
a
map
of
string
object,
but
if
you
go
to
the
other
class
open
telemetry,
the
main
implementation,
open,
telemetry
kafka,
whatever
that
one
there's
a
an
init
method
in
here
that
I
think
gets
called
with
the
configuration
so
it's
down
at
the
bottom.
It
doesn't
do
anything
right
now.
A
Okay
yeah,
so
you
could
and
it
could
put
itself
in
there
too,
as
the
reporter
interface.
So
it
could.
D
B
C
A
D
B
And
just
to
flesh
out
the
idea
a
bit
more
like
even
the
class
as
long
as
the
constructor
is
public,
I
don't
think
the
class
would
have
to
be
public,
and
so
we,
like
literally
the
only
public
thing,
would
be
this
method
probably
and
they
could
put
in
the
package.
Private
class
name
and
open
dumpy
object
as
long
as
the
constructor
is
public,
I'm
pretty
sure,
like
the
reflection
would
be
able
to
construct.
B
D
A
D
Everybody
in
the
world
uses
mutable
maps
except
people
who
don't,
but
I
mean
this
is
the
big
thing
like
you
you're,
like
oh,
it's
java
11,
I
have
map.of
and
then
you
do
that
and
then
every
the
world
breaks,
because
everyone
assumes
that
you're
match
immutable
right
yeah.
So
anybody
can
just
return
a
map
that.
A
D
A
Well
or
you
could
just
not
accept
the
base
one
and
only
return
the
map,
and
you
could
count
on
the
user
to
merge
it
with
theirs.
However,
they
see
fit.
D
B
A
B
D
B
C
Yeah,
it
would
be
worth
asking
that
person
who
is
asking
about
how
to
query
the
global
open
telemetry.
What
their
use
case
is
because
maybe
that's
what
they
want.
D
C
A
D
B
D
D
C
D
D
C
Because
he
pointed
out
the
the
the
problems
with
the
typewriter
yeah
yeah
yeah.
C
He
he
said
this
morning
that
he
had
some
thoughts,
maybe
with
some
wild
card
upper
bound
or
something
that
it
might
anyway.
He
said
he
was
gonna.
Think
about
it,
some
more
so
I
guess
there's
kind
enough
not
much.
A
So
let
me,
let's
just:
can
we
play
this
out
for
a
second?
So
if
we,
if
we
break
this
out
and
we
have
a
new
module
that
has
this
config
properties
in
it
and
it
has
that
interface
and
then
the
config
properties
that
lives
in
auto,
configure
spi
drops
all
of
its
methods
and
extends
that
interface.
B
Like
I
think,
every
method
in
auto
configuration
customizer
takes
it
so
yeah,
basically
duplicate
that
class
and
deprecate
the
current
one.
I
think
that's
the
practical
one,
rather
than
trying
to
add
a
bunch
of
methods,
probably
with
different
names
because
of
the
type
ratio.
So
we
would
probably
just
end
up
with
customizer
two
or
something.
D
B
B
B
And
like
it's
sort
of
it's
sort
of
our
philosophy,
I
think
like,
if
we
think
library
instrumentation
is
supposed
to
have
envar
configuration,
then
we'd
want
to
provide
a
good
experience
for
that
for
instrumentation
authors.
If
we
don't
think
it's
required,
then,
even
if
an
instrumentation
author
wanted
it,
they
could
do
it
themselves.
We
don't
have
to
provide
any
api,
so
that
and
sort
of
yeah
I
mean
for
programmatic.
Of
course
you
have
support
either
way.
D
D
D
There
could
we
can,
we
think
about
this
module
having
a
slightly
bigger
purpose
than
just
containing
one
class
like
is
there?
Are
there
other
other
other
facilities
or
classes
or
things
that
we
could
think
about
putting
in
there?
That
would
be
in
the
same
class
of
useful,
open,
telemetry
utilities
that
aren't
necessarily
all
configuration.
D
But
that's
all
internal
stuff,
that's
right!.
C
B
B
B
We
wanted
so,
I
think
the
micrometer
shim
wanted
to
use
it
and
for
now
it
doesn't
because
we
don't
really
have
a
cache
but
or
maybe
so,
I
think,
a
piece
of
the
concurrent
unbounded
one
for
now,
but
hopefully
it
would
be
a
bounded
one
with,
and
maybe
even
the
metrics
sdk
if
it
had
a
higher
performance
thing
instead
of
us
doing
that,
if
with
the
bounce,
I
don't
know
if
it
would
help
there,
but
there
are
some
places
that
could
use
a
cache
and
sdk.
I
think.
B
A
Would
you
those
in
internal
packages
within
this
or
keep
them
as
public.
D
B
C
B
B
B
If
we
use
it
in
both
places,
even
as
an
implementation
detail,
I
mean
the
idea
wasn't
duplicated.
Currently
it
is
it's
okay
to
duplicate,
in
that
case,
duplicate
and
configures.
In
that
bigger
video,
I
guess.
C
One
option
we
had
thrown
out
was
instrumentation
config,
renaming
sort
of
repurposing
the
one
in
the
agent
sort
of
having
two
different
like
instead
of
having
them
overlap
and
store
the
same
things
having
the
config
and
auto
configure
is
meant
for
auto
configuration
of
the
sdk.
B
A
D
Yeah,
I
don't
know
just
brainstorming
really
at
this
point
it
may
it
weirds
me
out
a
little
bit
to
create
a
one
class
module
to
share
that
class
with
with
like
it
feels
like.
I
think
this
is
what
you're
saying
on
august,
maybe
we're
over
designing
and
maybe
that
we
don't
need
to
have
a
shared
system.
I
don't
know
it
feels
weird
single
class
module
always
feels
like
you're
working
around
some
other
problem.
C
Well,
I
actually
think
this
helps
with
at
least
my
my
thinking
on
it
that
of
kind
of
hunting.
Basically,
until
we
know
what
this
is,
because
this
might
allow
us
to
do
some,
we
might
want
to
do
some
change
and
better
to
just
do
that
change
once
and
so
then,
the
question
is
just
from
the
instrumentation
api
perspective
since
we're
trying
to
stabilize
that
soon.
C
You
know
what
we
would
do
sort
of
there
without
trying
to
make
any
changes
in
the
sdk
auto
configure
and
knowing
that
yeah.
Oh
no,
oh,
I
guess,
oh
well,
that
goes
back
to
the
programmatic
configuration
thing
for.
B
C
Because
internal
say
like
I
don't
want
to,
I
don't
really
want
to
make
it
internal
if
we're
using
it
like
people
are
just.
I
don't
want
people
to
get
in
the
habit
of
using
internal
stuff.
Those
feels.
C
B
C
B
C
And
then
we
could
move
the
config
potentially
to
the
java
agent
extension
so
that,
because
we
do
need
config
there
and
we
do
need
config
from.
C
C
The
you
unlocked
the
key
to
unlock
whatever
this
problem
was.
B
D
Does
he
ever
show
up
to
the
special
topics
meeting
anymore?
D
C
Yeah,
so
I
can
write
this
up
basically
in
the
instrumentation
repo.
Now,
because
it
sounds
like
the
the
proposal
is
not
to
do
anything
in
the
core
repo,
so
I'll
write
up
an
issue
or
piggyback
on
an
existing
one
in
the
instrumentation
repo
and
then
yeah.
I
think
if
we
sort
of
I'll
go
through,
maybe
make
maybe
I'll
make
a
list
of
all
the
current
library
instrumentation
property,
based
that
we
support,
so
that
we
can
have
a
good
view
of
what
we're
going
to
take
away.
D
C
D
Yeah,
that's
super
difficult,
I'm
more
thinking
about
if
you
just
have
a
crud
api
making
it
item
potent
if
the
client
loses
the
network
connection
and
make
re
re
re-requests
the
same
thing
in
a
retry
loop
that
if
it
did
succeed
on
the
server
making
sure
that
it
doesn't
fail,
second
time
etc.
A
D
A
If,
if
you,
if
you
have
a
relational
database,
that
both
of
those
are
in
front
of
and
you
have
transactions-
and
you
have-
and
you
know,
the
client
provides
the
identifier
for
the
record
well,
there's.
A
B
D
B
B
And
I
think
job
in
like
so
one
my
reading
of
that
spec
is
that
the
main
point
of
all
that
was
just
to
allow
the
collector
to
propagate
target
from
its
prometheus
receiver
to
promute
this
exporter,
and
I
suspect
the
sdk
explorer
languages
added
on
for
complete
mistake
without
thinking
too
much.
That's
my
random
understanding
and,
like
I
do
understand
that
conceptual
resource
is
supposed
to
sort
of
map
to
target,
so
you
would
have
the
same
cardinality.
B
In
reality,
resource
has
service
instance
id,
which
is
a
uuid,
that's
generated
on
server,
startup
and
there's
a
pid
which
can
change
every
time
it
restarts,
even
though
the
scrape
config
makes
sure
that
that
job
would
generally
be
the
same
thing
as
target
as
far
as
premiums
is
concerned,
but
the
resource
would
not
be
unique
for
that
thing
across
restarts.
So
that's.
B
A
B
A
Yeah
and
just
to
kind
of
close
the
loop
on
this,
so
the
this
issue
arose
because
a
user
was
there,
you
know
they
basically
came
with
a
complaint.
Why
aren't
my
resource
attributes
being
propagated
on
any
of
my
prometheus
data?
And
you
know,
I
think
I
think
my
takeaway
after
reading
the
spec
a
lot
was
that
the
context
about
like
what
we
call
resource
and
open
telemetry
of
identifying
the
machine
that
you're
scraping?
That
is
the
job
of
the
collector.
A
The
thing
that's
doing
the
scraping
to
know
that
it's
supposed
to
know
the
identifying
characteristics
about
the
machine
that
it's
scraping
ahead
of
time,
and
so
in
this
user's
case
you
know
like
when
they
define
their
scrape
config.
You
know
they.
They
know
where
they're
scraping
and
so
it's
up
to
them
to
to
use
their
their
prior
knowledge
to
to
figure
out
how
to
properly
identify
it
and
so
yeah
that.
B
Was
kind
of
my
takeaway,
because
I
don't
I
mean
I
haven't
just
permit
this
in
a
while,
like
I
don't
know,
if
anything
other
than
job,
in
instance,
even
do
anything
if
we
populate
target
with
them
like,
I
thought
the
only
point
of
the
target
thing
was
so
prometheus.
Can
then,
like
in
its
native
data
format,
have
the
job
in
instance,
because
otherwise
like
to
actually
use
them?
I
think
they
would
have
to
be
labels.
B
A
D
A
B
A
B
A
B
Prometheus
or
collector
that
scrapes
from
other
collectors,
if
you
don't
keep
that
target
info
and
export
somehow,
then
that
you
have
no
way
to
differentiate
them,
but
yeah
as
far
as
a
user
needing
to
be
able
to
filter
the
metrics
on
resource,
probably,
actually
those
need
to
be
mapped
to
labels,
not
target.
That's
my
understanding
could
be
wrong
with
it.
I
think
that's
true.
A
Yeah,
it's
a
bit
weird.
This
whole
thing,
because
you
know
some
of
the
spec
is
set
up
for
this
scenario,
where
you
have
a
collector
that
has
a
prometheus
receiver,
which
is
scraping
a
open,
telemetry
sdk,
and
you
want
to
for
some
reason,
like
you
know,
instead
of
using
otlp
as
the
transport,
which
is,
you
know,
really
tightly
aligned
with
the
sdk
and
the
api
and
the
whole
data
model.
Like
you,
you,
you
kind
of
do
a
lossy
translation
to
the
prometheus
format
and.
B
That's
probably
for
people
that
want
to
experiment
with
an
open,
telemetry
backend
like
they
already
have
a
prometheus,
and
so
now
they
want
to
export
to
both
their
own
prometheus
and
to
uralic
or
something
without
modifying
their
apps.
Yet
maybe
they
would
in
the
future,
but
they're
already
exporting
on
prometheus,
but
they
want
to
try
out
some
non-prometheus
back-end.
So
that's
when
they
use
this
collector.
A
A
B
A
A
Yeah,
so
I
think
I
think
what
the
spec
needs
to
do
then,
is
to
your
point.
They
just
need
to
this
whole
section
might
actually
be
wrong,
because
it's
trying
to
accommodate
this
use
case
that
you
know
I
don't
think
necessarily
should
be
promoted,
which
is
we
just
described.
So
I
won't
repeat
it,
but
I
think
yeah
to
your
point.
The
better
situation
would
be
if
the
prometheus
exporter
had
a
opt-in
list,
a
way
to
configure
an
opt-in
list
of
resource
attributes
to
include
as
metric
level
attributes.
A
Out,
but
I
think
my
conclusion
was
that
the
user's
question
didn't
really
have
you
know
it's
not
something
that
this
pr
will
even
resolve.
The
user's
question
is
resolved
by
the
fact
that
the
collector
should
know
the
context
of
the
thing
that
it's
scraping,
and
so
you
know,
resource
attributes
aren't
really
something
that
we're
responsible
for
exposing.
A
Using
the
open-source
collector
to
scrape
from
like
and
premix
this
receiver,
I'm
not
sure
they're,
definitely
using
our
prometheus
exporter,
I'm
not
sure
yeah
like
and
and
that's
that's
another
part
of
the
problem,
because,
if
they're
not
using
the
the
prometheus
receiver
for
the
collector,
it
won't
be,
it
won't
help
them
anyways.
This
is
a
very
like
collector
oriented
solution.
B
B
A
Okay,
yeah
I'll,
do
that
and
I
don't
know
I
suppose
I'll
leave
the
pr
open
for
now
and
maybe
tag
it
as
block
by
spec
or
something
like
that.
But
I'm
in
no
hurry
to
merge
it
or
anything.
B
B
A
A
These
chemistries
well,
I
will
say
that
at
a
prior
job
we
use
prometheus
with
kubernetes
and
we
use
prometheus
to
scrape
the
kubernetes
apis
and
there
was
effectively
new
time
series
for
each
resource
in
in
kubernetes,
which,
like
include
things
that
are
semi-long-lived
like
like
pods
and
then
things
that
are
really
short
like
jobs
and
so,
like
you
know,
there
was
lots
of.
A
We
had
things
that
were
spinning
off
jobs
like
reading
from
a
message,
queue
and
spinning
off
a
job
in
response
to
that,
and
so
there
was
lots
and
lots
and
lots
of
of
time
series
being
spun
up
as
a
result
of
that
and
and
prometheus
dealt
with
it.
Fine.
I
forgot
what
our
ttl
was
but-
and
I
don't
know
the
order
of
magnitude
of
the
number
of
series
that
we've
created.
B
D
A
A
D
A
That
that's
an
idea.
That's
been
tossed
around
with
this
hint
api.
The
idea
that,
like
you
know
when
a
piece
of
instrumentation,
creates
an
instrument,
it
can
say
hey.
I
want
to
have
like
a
histogram,
and
I
think
that,
like
these,
this
set
of
attributes
are
the
most
important
attributes
so
record
these
by
default.
A
But
you
know
at
instrumentation
time
it
records
a
much
larger
set
or
a
larger
set
than
than
the
ones
that
it
thinks
most
users
will
be
interested
in
and
if
a
user
wanted
to
opt
into
that
larger
set,
they
could
do
so
at
sdk
configuration
time
with
views,
so
the
data
would
be
there,
but
not
for
everybody,
because
it's
not
the
normal
use
case.
C
There
was
some
reason
why,
this
morning,
why
that
approach
wasn't
going
to
work
and
that
we
needed
the
hints
api
for
this
well.
A
What
I
was
describing
is
kind
of
the
hint
api
like
it's
like
a
version
of
the
hint
api,
so
the
the
hint
that
here
is
like
when
you
create
the
instrument.
You
say
that
this
set
of
attributes
is
going
to
be
useful
to
most
users.
I
didn't
call
it
that,
but
that's
that's
kind
of
what
it
is.
B
A
Well,
yeah
sure,
like
I,
I
think
I
think
that
semantic
inventions
would
define
the
default
set
of
attributes,
but,
like
maybe
there's
situations
where
there's
additional
attributes
present
on
spans
that
you
know
for
cardinality
reasons,
aren't
included
on
metrics
by
default,
but
you
can
opt
into
them.
B
Yeah,
so
I
don't,
I
wouldn't
expect
to
need
the
in-state
guy.
If
that
can
be
in
semantic
conventions
like
maybe
for
non-semantic
convention
metrics,
you
would
need
that,
but
like
any
http
server
metrics,
for
example,
we
know
the
conventions
that
aren't
high
cardinalities,
so
that
should
just
be
the
default
view
for
them.
A
A
B
D
B
C
B
B
A
Yeah,
that's
kind
of
that's
kind
of
where
I'm
coming
from
so,
and
I
think,
like
you
know
the
the
section
of
the
instrumenter
api
that,
like
you
know,
provides
the
kind
of
you
know.
Encodes
the
semantic
conventions
like
the
http
attribute
getters,
something
like
that,
which
is
the
instrumenters
encoding
of
the
semantic
conventions,
could
also
provide
a
mechanism
that
says
like
when
you
get.
C
C
So
jack
mentioned
that
in
to
this
week's
spec
call
that,
though,
that
riley
had
brought
up
potentially
re
trying
to
re-uh
get
the
metrics
sig
going
again
to
for
a
couple
of
issues
that
still
needed
to
be
addressed,
one
of
which
was
the
hints.
A
Yeah
three
come
to
mind:
exponential
histograms
and
hints
are
all
work
that
was
punted
and
and
prometheus
exporter.
That
too
that's
kind
of
poor
areas.
B
C
B
Like
metrics
hearing
about
the
metric
sig
like
it's
a
bit
disappointing,
because
I
don't
think
that
any
of
these
metrics
features
are
actually
the
highest
priority
for
users,
it's
having
stable,
instrumentation
and
so
you're,
not
supposed
to
restart
the
metric
sig
until
making
some
progress
on
this
thing,
that's
way
more
important.
So
this
is
but.
C
It's
clearly
not
way
more
important,
because
I
I
told
you
did
I
tell
you
about
the
the
maintainer
meet
the
poll
that
they
did
at
kubecon
of
users
and
list
of
priorities
sounds
a
bit
yeah,
but.
A
A
C
C
D
C
From
the
microsoft
side,
it's
very
important
and
you
can
tell
that
by
the
people
who've
been
driving,
all
the
like,
the
messaging
spec
and
dennis
and
ludmilla
on
the
http
spec.
Oh.
B
B
A
C
Well,
there's
an
issue
that
sort
of
describes
what's
outstanding
but
as
and
dennis
was
sort
of
driving
that,
but
ludmilla
has
been,
or
at
lenovo
has
been
pushing
on
some
of
those
which
then
keep
opening
up
new
cans
of
worms,
plus
the
fact
that
it's
only
like
one
person,
one
person
at
the
pc
is
a
christian,
is
sort
of
engaging
in
that
discussion,
and
so.
A
Yeah,
I
think
that's
really.
What
it
takes
for
stuff
to
move
forward
is
like
some
sort
of
tc
sponsorship,
so.
C
B
I
did
give
my
advice
right
that
we
java
just
needs
to
set
our
deadline
and
we're
going
to
release
our
stable
instrumentation
in
september
or
something,
and
if
that
means,
even
if
the
semantic
events
are
ready.
Who
cares
because
we've
been
waiting
way
too
long?
That's
still
my
recommended
strategy.
This
camp
just
gone
forever.
C
Yeah,
so
as
far
as
how
long
jack
yeah,
your
guess
is
as
good
as
mine,
which
is
probably
as
good
as
milla's,
because
it's
just
not
up
to
us.
A
C
I'm
sure
ludmil
yeah,
I
I
told
lamilla,
I
felt
bad
about
like
not
engaging
in
that
because
I'm
sure
another
voice
would
just
so
that
it's
not
just
her
and
christian,
like
having
more
voices,
would
probably
be
appreciated.
A
Yeah,
I
I
can
go,
do
that
you
know
they
just
got
so
far
down
in
the
weeds
and
there's
so
much
contacts
to
be
aware
of
at
their
level
of
the
conversation.
But
I
suppose
I
can
at
least
give
my
like
opinion
at
like,
like
a
higher
level
of
abstraction,
and
so
you
know
let
them
continue
that
lower
level
conversation.
C
D
C
It
can
help
there's
some
of
the
tc
members
are
more
apt
to.
C
Something
that
you
know
has
some
community.
A
Support
I
I
guess
I
have
noticed
that
a
bit
like
sometimes
I'd
like
I
I
stamp
stuff
early
and
then
like.
If
it's
been
stale
for
a
while
and
then
like
you
know,
what
do
you
know
a
couple,
other
people
stamp
it
pretty
soon
afterwards,
maybe
it's
the
type
of
thing
where
you
stamp
it,
and
then
it
jumps
to
the
top
of
their
notifications.
They
become
aware
of
it
again.
A
C
Yeah
but
then,
but
I
think
the
there's
less
controversial
things
and
then
there's.
I
think
these
http
changes
are,
I
mean
any
change
to
the
http.
Semantic
convention
is
obviously
going
to
be
controversial,
which
makes
it
challenging
and
I
think,
there's
various
levels
of
obstacles
and
then
I
think
on
something
as
critical
as
that.
There's
probably
still
the
final
boss
level,
which.
C
All
right
well
have
a
good
long
weekend.
Jack
and
honorag
enjoy
your
summer
weekend,
whether
it's
short
or
long
see
you
later.
C
Yeah,
that's
right.
I
keep
forgetting
you're
like
at
the
latitude
of
like
los
angeles
right,
not.