►
From YouTube: 2022-09-28 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
Yeah
yeah,
it
might
be
near
time
we'll
see,
but
maybe
in
the
near
future,
we'll
want
to
wind
these
meetings
down.
A
A
Foreign,
let's
see
actually
I
raised
something
last
meeting,
but
I
didn't
really
get
a
good
answer
to
it.
You
might
know
the
answer,
but
basically.
A
A
Right
so
an
example
would
be
I,
have
a
gauge
named
Foo
underscore
total
versus
I
have
a
counter
named
Foo
and
it
turns
out.
If
you
get
a
metric
point
named
Foo
total,
you
don't
actually
know
which
one
it
belongs
to
I
I
was
wondering
if
that
came
up
at
all
in
open,
metrics
discussions.
I
think
we're
doing
the
least
bad
thing,
which
is
just
to
associate
all
the
points
with
the
counter
version.
A
Okay
right,
if
this
was
something
that
came
up
or
if
there's
a
recommended
way
to
handle
it.
B
It
did
come
up
so
following
the
the
naming
scheme
or
the
naming
guidance
of
of
Prometheus,
you
would
not
ever
have
arrived
at
a
Gorge
which
is
called
food,
total
and
I'm
just
playing
back
the
discussion.
We
we
had
back
then,
and
it
was
basically
seen
as
as
an
acceptable
risk,
slash
impact.
B
You
have
the
same
thing
with
underscore
created,
which
has
even
a
little
bit
more
of
of
a
likelihood
of
of
biting,
at
least
in
my
experience.
Of
course,.
A
B
Can
conceivably
be
arrived
at
just
by
by
using
this
as
the
implicit
name
of
a
timestamp?
B
B
But
if
you
don't
have
that
Header
information
anymore,
assuming
it's
it's
a
counter
is,
is
the
right
thing
to
do.
In
my
opinion,.
A
A
B
A
A
The
the
other
case
that
we've
found
is
that,
if
you're
using
Prometheus
and
someone
didn't
add
a
suffix,
because
we
don't
know
if
it's
open,
metrics
or
Prometheus,
sometimes
we
can
misassociate
metrics
there
as
well.
So,
for
example,
if
I
have
the
counter
named
just
Foo
in
Prometheus
without
total
and
then
a
different
counter
named
something
with
total,
then
those
two
will
sort
of
collide.
A
If
that
makes
sense,
because
we
assume
that
we
should
trim
the
total
suffix
off
of
metric
points
like
open
metrics
does
I
assume
that
recommendation
there
is
similar,
which
is
do
what's
right.
If
people
follow
conventions.
B
That's
slightly
less
more
likely,
even
when
you
follow
Prometheus
conventions,
that
kind
of
case
but
yeah.
What
you're
saying
is
correct
just
to
make
sure
do
you
never
have
information
about
about
what
the
underlying
thing
was,
because
at
what
point
are
we
talking?
B
Do
you
get
this
pushed
to
you
or
do?
Are
you
scraping
something
and
then
put
it
into
Prometheus
remote
right
yourself
at
what
part
of
the
stick
are
we
talking
because
normally
I
think
we're
talking
about
you're,
scraping
the
thing
and
then
forwarding
it
to
right?
Okay,
so
at
that
point
you
have
the
Header
information
of
whatever
the
metrics
endpoint
is.
A
B
Okay
I
mean,
but
but
this
is
something
which
maybe
we
we
can
look
at
on
Prometheus
side.
If
there's
a
reasonable
way
to
to
expose
this
towards
the
append
interface,
where
this
scrape
is
coming
from.
We
actually
had
this
discussion
within
within
the
working
group
back
and
forth,
because
I
like
being
explicit
and
I
would
have
much
preferred
to
put
it
into
into
the
actual
body,
and
then
we
actually
payload
the
information
about
what
version.
B
The
thing
is,
because
precisely
this
kind
of
thing,
but
then
we
would
have
had
it
in
two
places,
because
we
can't
really
get
rid
of
the
header
and
if
they
diverge,
everyone
is
unhappy
right.
A
Yeah
okay
sounds
like
maybe
we
can
open
an
issue
on
the
Prometheus
repo
and
follow
follow
up
from
there.
Thank.
B
A
A
A
And
then
the
second
topic:
well,
the
really
the
first
topic
for
today.
But
the
second
topic
I
wanted
to
discuss.
Overall
was
the
current
plan
for
handling
instrumentation
scope
and
funny
story.
I've
thought,
since
about
2017
that
Prometheus
disallowed
the
same
metric
in
a
scrape
to
have
a
different
set
of
label
keys,
because
at
one
point
that
was
prohibited.
B
C
B
B
Sorry
so
it's
totally
fine
first
per
definition:
the
label
set-
and
that
includes
the
metric
name-
is
what
makes
up
the
identity
of
of
the
time
series.
So,
if
any
of
those
changes-
and
it
doesn't
matter,
it's
the
label
name
or
the
label
value
and
the
metric
name
is
just
a
special
label
value
under
this
lens.
Simply
the
identity
of
the
thing
changes
and
the
old
thing
goes
away,
and
the
new
thing
pops
into
existence.
A
Great
so
I
Linked
In
the
notes,
the
at
this
point,
ancient
changes
for
it,
but
at
one
point
it
was
disallowed
to
have
different
sets
of
label
keys,
at
least
in
the
go
client
and
so
for
years.
I've
thought
this
was
a
rule
and
wrote
entire
proposals
to
try
and
work
around,
never
letting
this
happen
in
open,
Telemetry
and
wasted.
Unfortunately,
a
lot
of
Josh's
time
and
others.
C
A
It
it
was
outlawed
for
the
whole
go
client,
so
at
one
point
and
it
was
rolled
back
but
I
missed
the
memo,
and
so
I
had
I
was
working
under
the
assumption
that
we
had
to
do
that,
but
long
story
short.
A
The
result
of
this
is
now
a
proposal
that
I
think
will
move
forward,
which
is
to
add
instrumentation
name
and
instrumentation
scope
version
as
labels
on
Prometheus
metrics.
This
deviates
somewhat
from
how
Prometheus
normally
handles
scope
or
name
spacing
metrics.
A
B
No
strong
opinions,
just
for
completeness
sake,
I
was
talking
about
the
exposition
and
how
Prometheus
sees
the
time
series,
and
you
were
talking
about
how
specifically
the
gold,
client,
Library
endless
things
yeah.
That's.
A
Did
you
happen
to
catch
the?
What
what
the
current
plan
is
or
should
I
talk
about
that
again.
B
B
A
This
is
regarding
not
following
the
convention
of
adding
namespace
as
a
prefix
and
instead
adding
something
like
namespace
as
a
metric
label.
C
I
would
actually
prefer
to
have
us
think
of
it
as
a
disambiguation
device.
There's
two
cases,
there's
one
where
the
the
this
concept
of
open
Telemetry
scope
exists
and
all
it
has
is
a
name
and
aversion
and
those
are
meant
to
disambiguate
when
there
are
conflicts
which
we
don't
truly
expect
to
be
common
by
the
previous
discussion,
I
think,
but
when
they
do,
we
understand
that
incorrectness
will
result
from
multiple
libraries
or
pieces
of
code
overwriting
the
same
metrics
and
instead
of
a
sort
of
Convention
of
prefixing.
All
the
metric
names
we
are
proposing.
C
David
is
proposing
this
additional
pair
of
attribute
labels
that
would
be
able
to
disambiguate
any
collisions
as
well
as
offer
you
a
chance
to
join
with
any
other
scope
attribute
variables.
So
there's
a
case
when
you
only
have
name
inversion
that
the
that
all
it
does
is
help
you
disambiguate
and
I
I've
proposed
that
we
offer
an
option
for
most
users.
Don't
need
this
to
just
like,
take
the
risk
of
collisions
and
not
have
those
extra
labels,
because
they're
not
really
adding
very
much
if
you
don't
have
collisions.
C
But
when
you
have
these
so-called
scope,
attributes
which
are
attributes
scoped
to
a
unit
of
code,
those
will
disappear
unless
we
have
this
mechanism
that
David's
proposing,
which
would
add
additional
attributes
on
this
scope,
metric
main
the
scope
metric
that
you
could
then
join.
If
you
have
the
name
inversion,
labels.
B
So
the
collision
avoidance
is
meant
to
avoid
collisions
as
I
start
joining
more
and
more
data
sources
or
metric
sources
and
shove
them
through
the
pipeline
together
to
to
this
to
disinvigorate,
where
they're
coming
from,
like
from
different
targets
or
sources
depending
on.
If
you
are
talking
push
or
pull,
is
that
correct.
A
C
We
don't
expect
between
programs
that
would
be
addressed
by
some
other
disambiguation
or
or
job
and
instance.
It's
a
case
of
let's
say
you
have
a
library
of
code
that
is
reused
by
multiple
in
multiple
places,
in
your
big
application.
So
I've
got
like
helper
library
that
has
instrumentation
and
three
people
are
using
helper
Library.
They
might
have
different
versions
of
helper
Library.
I,
don't
think
that's
most
like
some
languages.
C
B
Okay,
that's
an
interesting
point
for
for
so
for.
B
The
intents
and
purposes
Prometheus
scrapes,
this
is
something
which
doesn't
happen,
but
that's,
maybe
not
an
assumption
which
you,
which
you
can
make
in
the
fully
generic
case.
B
So
what
what
normally
is
done
is
like,
as
you
cannot
do
this
you
just
disinfigate
through
through
the
metric
names
or
if
you,
if
you
have
any
subsystems,
you
can
also
just
toss
another
label
onto
the
thing,
but
this
is
something
which
is
done
at
code
writing
time,
because
the
person
who's
who's
doing
the
thing.
B
Gets
a
collision
otherwise,
as
far
as
I
understand
what
you're
saying
is:
I,
have
a
library
or
I
have
the
library
three
times
or
ten
times,
so
it
doesn't
matter,
I
call
it
in
different
places
and
they
all
join
the
total
metrics
into
a
thing
which
is
then
being
scraped,
and
at
that
point,
when
it
is
being
exposed,
I
have
those
collisions
which
cannot
happen
under
a.
A
There's
also
because
we've
tried
to
Define
conventions
for
things
like
metric
names,
multiple
different
HTTP
libraries
are
also
expected
to
produce
the
same
metrics
we've
sort
of
specked
out
exactly
how
we
hope
that
those
should
all
look.
So
it
may
even
be
the
case
that
different
libraries
produce
the
same
metric
names
and
attributes.
B
Maybe
a
little
bit
of
a
known
answer
we
over
have.
We
always
try
to
avoid
this.
That's
part
of
the
reason
why
open
metrics
deliberately
doesn't
have
a
namespace
concept.
I
personally,
I
wanted
to
have
a
namespace
concept,
because
that
would
that
would
allow
you
to
do
completely
bypass
this,
because
you
could
say
my
name:
space
is
full
library
and
my
other
name
space
is
Bar
library.
B
That
does
not
guard
me
against
using
three
different
versions
of
the
same
library,
but
at
some
point,
if
you're
building
a
dedicated
foot
gun
with
a
foot
shaped
nozzle
and
have
a
big,
a
big
sign
put
foot
here
at
some
point,
it's
going
to
break
down
like
and
and
even
if
people
are
not
using
the
libraries
and
they
just
print
F
from
their
code.
At
some
point
they
they
can
break
it.
So
you
you
can't
make
it
fully
resilient.
B
All
that
being
said,
we
didn't
see
the
need
to
to
overload
things
with
with
the
namespace
I
have
a
pretty
hard
cut
in
three
minutes,
which
is
why
I'm
trying
to
speed
run
through
through
a
few
years
of
deliberation.
B
B
If
you
want,
because
we'll
definitely
continue
discussing
this-
and
the
third
option
we
considered
was
to
have
double
underscore
as
a
basically
compatible
and
no
need
for
any
changes
thing,
because
that
allows
you,
if
you
really
want
to
have
this
namespace
just
say:
Foo
underscore
underscore
HTTP
latency
seconds,
but
that
does
not
help
you.
If
you
want
to
group
all
HTTP
underscore
ADB
latency
seconds.
B
Of
course,
all
of
a
sudden,
you
have
different
metric
names
and
you
would
need
magic,
which
is
aware
of
this
behavior
and
cuts
it
off
for
for
blah
blah
blah
blah.
So
that's
like
the
the
whole
discussion
space
we
went
through
on
on
the
topic
of
namespaces.
A
Okay,
I
know
you
have
to
leave
we,
so
the
current
proposal
is
similar
to
the
underscore
underscore
namespace
label
except
we've,
called
it
open,
Telemetry
or
otel
scope
name.
A
Do
you
think
that
that's
I
believe
it
is
compliant
with
the
open
metric
spec?
Do
you
think
a
wise
decision,
given
our
state.
B
I
would
always
try
and
come
up
with
names
which
are
not
specific
to
any
implementation
or
any
any
wire
protocol,
because,
ideally,
in
30
years,
what
we
are
currently
working
on
some
remnant
is
still
being
used
somewhere
at
least
that's
how?
How
I
think
about
those
things
so
I
would
prefer
not
to
encode
the
name
of
the
of
the
actual
spec
in
within
the
thing
Beyond.
This
absolutely
I
mean
there
is
an
argument
to
be
made
to
to
to
have
a
well-defined
name
scope
would
work.
B
Namespace
would
work
the
advantage
of
of
at
least
within
the
Prometheus
ecosystem
of
of
pulling
one
of
the
underscore
underscore
label
names
out
of
our
magic
hat.
Is
those
are
explicitly
reserved?
So
we
know
there
is
no
Collision,
because
when
you
say
scope
or
when
you
say
namespace
that
can
Clash,
someone
certainly
has
this
somewhere
already.
B
No
worries
I'll.
B
We
can
also
try
and
schedule
something
off
so
in
14
days,
I'll
be
traveling
for
a
month
in
the
U.S
and
I'll
be
back
to
back
with
meetings
and
also
for
the
next
one
I
think
cubecon
clashes.
B
We
can
also
try
and
find
a
different
time,
or
we
can
try
and
do
this
offline
or
in
particular,
for
the
dots.
If
you
can
try
and
join
the
Primitive
staff
Summit.
Maybe
we
can
can
continue
over
there,
because
those
would
mean
changes
to
to
basically
Prometheus
itself.
B
It's
always
the
last
Thursday
or
the
fourth
Thursday
of
the
month,
so
the
next
one
is
here.
The
next
one
is
during
cubecon,
so
it's
probably
not
going
to
happen.
Okay,
I'll
talk
to
Gotham
and
let's
see
if
we
can
just
set
something
up
to
to
continue
this
okay,
okay,
cool.