►
From YouTube: 2021-11-04 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
A
D
A
A
A
The
question
here
is
we:
we
allow
that
in
the
api
you
have
different
meters
and
under
different
meter.
You
can
have
different
instruments,
but
they
can
use
the
same
name.
So
this
is
a
concrete
example.
You
have
two
libraries
and
they
happen
to
have
the
same
instrument,
but
in
the
isdk
based
on
the
the
rule
like.
If
you
don't
have
a
view,
we
give
you
a
default
view
and
if
there's
name
conflict
we'll
do
something
about
it,
so
we
will
end
up
with
taking
only
one
of
it
and
dropping
the
others.
A
The
ask
here
is
basically:
can
you
make
the
meter
name
as
a
prefix
for
the
instrument
or
introduce
something?
So
I
can
get
both
by
default,
and
I
explained
my
thinking
it
seems
there
are
folks
who
don't
like
this
approach.
So
I
feel
maybe
this
is
more
like.
What's
the
right
balance
and
I
can
see
even
their
strong
statement
saying
it
seems
like
a.
It
seems
like
a
bug.
C
C
I
think
that
is
yeah.
So
if
you
just
use
the
the
net
api,
then
you
might
end
up
with
two
meters
that,
for
example,
you
have
two
different
libraries
that
both
have
a
request
count.
I
don't
know
like
two
different
database
libraries
that
you
pull
in
and
they
both
have
a
request
count.
And
if
you,
if
you
do
this,
then
you
might
end
up
with
two
different
instruments
from
two
different
libraries
that
have
the
same
instrument
name
and
then
in
the
net
implementation.
What
happens?
C
I
think
this
is
more
of
a
clarification
question
here
is
what
should
happen
is
is
like
the
understanding
wrong
that
these
things
should
not
interfere,
or
I
don't
know
in
either
case
it's
probably
something
that
will
come
up
in
at
some
point
like,
for
example,
given
you
have
to
you
have
two
database
libraries
and
you
pull
in
both
database
libraries
and
you
want
requests
count
for
each
of
these,
but
in
the
back
end
or
in
the
in
the
open,
telemetry
collector
or
wherever
you
send
your
metrics,
you
just
end
up
with
half
of
them,
because
the
other
one
is
just
dropped
and
yeah.
C
I
think
this
is
more
of
a
clarification
thing.
We
have
to
put
clarification
somewhere
either
in
the
in
this
case.net
sdk
or
api
usage
part,
or
we
put
it
in
the
api
spec
in
some
some
way
or
it's
it's
just.
I
think
it's
just
I
see.
A
Yes,
so
so
to
explain
that
a
little
bit,
I
think
in
the
sdk
spec,
we
explained
the
the
rule
here
and
based
on
the
rule.
If
you
have
two
instruments
that
have
the
same
name
but
under
different
meter-
and
you
don't
have
any
view,
so
you
will
have
a
default
configuration
applied
and
then
we
go
through
the
louder.
You
can
see.
Oh
there's
a
name
conflict
then
we'll
just
take
the
first
one
and
drop
the
the
others
if
they
have
the
same
name.
A
A
E
Sorry
go
ahead.
Can
we
take
a
step
back
because
I
think
you're
already
a
little
too
deep
here
if
we
take
a
step
back
on
the
issue?
Here's
an
interesting
problem
all
right.
So,
let's
talk
about,
say
our
prometheus
exporter
and
let's
talk
about.
I
have
a
database
metric
with
name
a
and
in
in
meter
a
right
like
that
that
right
there
you
have
instrument,
xyz
and
meter
a
and
you
have
instrument
xyz
and
meter
b.
Now,
according
to
our
data
model
and
our
specification,
those
two
instruments
can
be
different.
E
One
can
be
a
counter.
One
can
be
a
gauge
and
in
our
protocol,
they're
actually
isolated,
because
the
meter
is
part
of
the
protocol
and
you
have
a
completely
separate
subset
where
you'll
actually
have
a
different
metric
stream,
with
a
gauge
for
x
y
z
for
meter,
a
and
you'll
have
a
different
metric
stream
for
meter
b
with
a
counter
which
is
xyz
right
if,
if
the
first
one's
a
gauge
and
segments
of
counter,
but
then
when
I
go
to
prometheus,
that
instrument
basically
is
going
to
that
meter.
C
E
C
But
in
the
in
the
net
sdk,
currently
what
is
happening
is
there
is
a
map
and
it
puts
like
the
first
time.
Whatever
instrument
name
comes
in
it
will
put
that
instrument
name
in
the
map
and
just
the
instrument
name
without
the
meter
name.
C
So
on
consecutive
calls
to
that
or
if
you
have
different
instruments
with
the
same
name,
it
will
drop
them
and
they
won't
ever
reach
the
exporters
because
they
addressed
before
so
so
I
think
that
that's
that's
the
clarification
that
we're
looking
for,
because
it's
it's
probably
true
it
it
that's,
but
I
I
mean
I
guess
I
wonder
is
that
like
is
that
if
you,
if
we
have
this
case
here,
we
have
two
meters
with
different
names
but
the
same
instrument
name.
D
D
So
I
don't
expect
to
have
a
case
where
there's
mixed
type
across
meters
to
me,
the
the
reason
that
different
libraries
are
generating
the
same
metric
is
that
they're
actually
trying
to
say
the
same
thing
using
the
same
metric
name
so
that
if
only
one
library
is
present,
you
can
just
get
the
metric
name.
But
as
soon
as
there
are
more
than
one
library
providing
a
metric,
then
I
think
we
either
should
talk
about
re-aggregating
or
keeping
them
separate
streams.
D
A
Josh,
so
so
here
here's
my
reply
to
the
initial
issue,
so
I
I
think
in
this
case,
if
there
are
different
things
and
they
want
to
report,
http
request
count.
I
guess
they
probably
even
have
different
semantic-
the
dimensions,
how
they
name
things
they
might
not
align
with
the
semantic
convention.
So
if
they
happen
to
have
a
collision
on
the
name.
I
think
this
is
a
bug
the
application
owner
should
realize
and
they
should
do
something
explicit
about
it.
B
Semantic
convention
must
be
always
like
in
sync,
with
like
every
other
libraries
that
they
are
using,
no
because,
because,
like
library
instrumenters,
they
can,
they
can
like
apply
or
they
can
have
instruments.
Yeah.
A
B
Are
named
like
outside
of
the
auto
semantic
conventions
for.
B
The
instrument
name
is
not
in
the
semantic
conventions
and
let's
say
that
the
user
of
this
library
they
also
have,
I
don't
know
like
a
company
wide
or
department
by
naming
convention,
which
is
not
the
same
as
the
auto
naming
convention
or
like
outside
of
it.
Those
two
things
can
conflict.
A
Yeah
yeah
they
can't
and
and
third
party
they
they
don't
have
to
follow
the
open
time.
Transcendental
convention,
although
it's
a
recommended
thing
and
and
my
take
about
this-
is
very
similar
to
the
the
class
names
like.
If
someone
should
give
you
a
java
class
that
has
the
same
name,
space
same
class
name,
and
you
want
to
use
that
and
you
don't
want
to
have
conflict.
What
do
you?
Do
you
probably
decide?
Okay,
that's
a
bad
behavior.
They
should
follow
some
convention
or
that's
a
bad
library.
I
should
stay
away
from
that.
E
Actually,
what
we
do
is
we
shade,
which
is
what
I
would
say,
views
do,
but
any
anyway,
that's
a
different
story
like
that.
We
we
hit
that
all
the
freaking
time,
unfortunately
like,
like
especially
in
open
telemetry,
because
you
have
a
bajillion
instances
of
grpc,
because
you
have
the
open,
telemetry
grpc.
You
have
like
someone
else's
grpc
you
need
to
like
hide
that
stuff.
I
think
this
is
just
going
to
be
a
problem
that
we
run
into.
A
E
Where,
where
is
it
used
practically
or
like
the
by
default?
Okay.
B
If,
if
I
don't,
if
I
don't
specify
a
view,
then
the
name
of
the
meter
will
be
added
to
the
tags
right
or
labels.
Sorry,
so.
E
In
open
telemetry,
it's
a
first
class
concept,
it's
called
instrumentation
library
and
all
of
your
metrics
are
bundled
by
instrumentation
library.
B
Then,
where
it
be
used,
do
you
mean
when
it's
exported
to
like
prometheus,
for
example,
yes
or
or
any
other
or
otlp
or
whatever
back
end.
E
We
we
haven't
specified
that
yet
they
were
still
working
on
it,
but
there's
a
there's,
a
convention
from
tracing
where
it
becomes
an
attribute
called
hotel.library
and
hotel
dot
library
version
you
get
both
of
those
exported.
G
A
Yeah
so
in
promises,
this
is
an
ongoing
pr
trying
to
address
the
power.
B
And
whoever
is
using
otrb
like
as
a
back
end,
what
is
the
like?
What
is
the
recommended
way
of
using
this
like
concatenating
it
into
the
name,
because,
like
the
beckham
might
not
have
this
concept
of
a
meter
name,
it
might
not
be
the
first
class
citizen.
So
what
is
the
recommendation?
What
should
they
do
with
that
like
attach
it
as
a
label
or
like
concatenate
it
as
a
name
of
the
instrument
or
the
metric?
In
that
case,.
A
C
Let's
say
an
attribute
like
we
require
them
to
use
a
semantic
convention
to
have
a
unique
meter
name
and
that
meter
name,
oh
sorry,
instrument
name
and
that
instrument
name
alone
should
be
enough
to
determine
that
like
this
is
this?
Is
this
instrument
from
this
library
without
having
to
fall
back
to
the
meter
name
itself?
C
E
Well,
no,
no,
no
you're,
you're
asking,
I
think
you're
you're
teasing,
that's
something
that
we
haven't
really
discussed
in
depth,
but
like
so
in
it.
Let's
I'm
thinking
in
terms
of
like
back
end,
usages
and
say
prometheus
right.
We
can
talk
about
otlp
all
day
and
I
think
in
otlp.
This
isn't
an
issue
because
these
are
distinct,
but
it
doesn't
matter
until
you
talk
end
to
end
and
what
this
looks
like
in
a
query
into
a
user.
E
That
said,
when
we
look
at
actual
real
life
issues
across
libraries,
like
the
one
that
you're
raising
here
of
you
know,
I
have
meter
a
and
a
meter
b
and
they
disagree
on
the
definition
of
the
metric.
E
So
to
in
my
mind
you
know
we
have
two
possible
ways
we
can
go
here.
We
could
go
the
route
that
I
think
you
might
be
suggesting,
which
is
the
meter
name,
is
part
of
the
identity
of
the
metric,
and
we
attach
the
meter
name
to
the
instrument
name.
When
we
export
to
prometheus
the
other
route
we
can
go,
which
is
the
route
I
think
we've
been
going
previously
and
I'm
more
on
board
with
this,
because
I
think
it
leads
to
better
user
friction.
Is
we
make
sure
instrument?
Names
are
consistent
in
our
community.
E
So
if
you
call
something
http,
client
duration,
it
has
the
same
meaning
everywhere
and
then
meter
becomes
a
label
that
you
can
use
to
do
filtering.
I
think
that's
like
open.
Telemetry
is
currently
moving
on
on
the
left
hand
side,
but
we
might
not
have
all
the
tools
to
do
that.
Well
yet-
and
I
think
you're
you're
finding
some
of
the
rough
edges
in
the
current
spec,
but
but
I
think,
like
both
are
viable
options.
Just
to
look.
A
Yeah,
I
I
would
expect
when
people
see
the
http
server
duration
and
they
look
at
the
back
end.
They
see
exactly
the
same
instead
of
something
like
google
underscore
http
duration
and
then
dynatrix
underscore
something,
and
that
seems
to
defeat
the
purpose
I
and
I
I
think
in
most
other
cases,
imagine
if
you're
using
python,
you
wouldn't
use
three
http
server,
libraries
at
the
same
time,
normal
case,
although
you
can,
and
if
you
happen-
to
use
like
two
libraries
that
have
the
same
http,
client
duration.
A
Imagine
like
you,
use
some
http
client
for
a
secure
connection
and
use
them
http
client
for
non-secure
connection.
Then
the
question
is:
do
you
even
think
it's
safe
to
merge
those
things?
I
I
guess?
No,
you
have
to
be
explicit
and
the
application
owner
has
the
best
knowledge
if
it
makes
that
by
default.
I
think
it
might
be
like
50
people
will
be
happy
because
that's
what
is
they
expect?
The
other
50
people
would
be
crazy
on
us.
So
it
doesn't
seem
to
me
that
there's
a
perfect
answer.
A
And
if
there's
no
perfect
answer
and
there's
not
even
the
8
like
20
problem,
then
I
think
the
default
behavior
is.
We
complain
to
the
application
developer
and
let
them
solve
that
problem,
and
with
that
I
I
think
that
wouldn't
shut
down
the
door.
If
later
we
learned
something
we
change
our
mind,
we
think
we
should
do
something
by
default.
We
can
still
do
that.
C
If
I
now
have
two
instruments
with
the
same
name,
the
first
one
will
be
capped.
The
second
one
will
be
dropped
and
if
I
want
to
export
them
both,
then
I
would
have
to
change
one
of
them
beforehand
as
an
application
developer
or
as
an
application
owner
to
make
sure
that,
because
I
know
which
which
ones
I
want
and
where
and
then
it's
my
responsibility
to
either
combine
these
two
metric
streams
in
order
to
separate
them
later
on,
as
with
a
label
or
rename
one
of
them.
E
So
I
I
want
to
call
out,
I
think
you
actually
have
a
bug
in
dot
net
as
well
like
I,
I
believe
dot
net
should
have
a
distinct
metric
x
y
z
from
meter
a
and
a
different
metric
xyz
from
meter
b,
and
it
should
be
reporting
them
independently
in
otlp.
And
then,
when
you
export
prometheus,
you
get
one
metric
xyz,
where
there's
a
label
of
meter,
a
with
all
those
streams
attached
and
another
label,
with
b
with
those
streams
attached,
so
that
actually
sounds
kind
of
like
a
bug
in
net.
D
D
D
Well,
I
think
that
that's
what's
intended.
My
my
position
here
is
that,
like
the
name
of
the
instrument
is
semantically
identifying
and
if
you
use
the
same
name,
it
must
mean
the
same
thing.
There
should
never
be
a
type
conflict
and
as
long
as
there's
not
a
type
conflict,
I
actually
don't
see
a
problem
and
I
don't
think
you
need
to
put
your
library
name
in
as
an
attribute
always
for
that
reason.
D
D
D
A
G
C
But
but
you're
now
talking
about
different
types
right,
so
then
you
would
also
export
one
of
them
as
a
prometheus
count
and
one
of
them
as
a
prometheus
gauge.
Or
are
we
talking
about
something
where
the
types
also
match
up?
So
we
have
two
almost
identical
prometheus
streams
where
actually
all
of
the
parameters
match,
like
all
of
the
the
type
matches,
the
name
matches
and
the
labels
match,
but
they
are
just
like
two
separate
things
or
are
we
talking
about
where,
like
they're?
D
H
One
one
thing
to
note
is
when
you
use
at
least
on
the
java
side,
if
you
have
a
gauge
versus
a
counter,
it
will
add
total
to
the
end
if
total
does
not
exist
in
the
name.
So
that's
one
thing
to
like
to
think
about
is
that
even
if
they
were
named
exactly
the
same,
the
resulting
metric
would
not
be
the
same
in
prometheus.
D
G
Right
now,
I
think
if
somebody
interferes
with
with
prometheus
library,
there
is
a
registry,
I
think
it's
called
metric
registry
or
something
informative,
and
if
you
have
different
registries,
you
will
get
two
different
metrics
and
you
keep
the
same
problem.
If
you
are
using
the
same
registry,
you
are
accumulating
that
and
I
think
we
should
try
to
map
more
closer
to
what's
religious
instead
of
trying
to
solve
their
issue.
E
E
E
No
no,
but
you
could
we
could
encode
this
like
that,
so
that
you
kind
of
see
them
all
together
in
in
it
it
it's
the
closest
equivalent
that
prometheus
has
to
what
we've
done,
but
it's
not
the
same
it
I
think
it's.
I
think
that
would
I'm
just
throwing
it
out
there
as
an
idea.
We
should
probably
never
ever
consider
again.
It's
like
one
of
those
hey
here's
a
terrible
idea.
Please
please,
let's
not
do
it,
but
I'm
just
throwing
that
out
there
if
people
are
looking
for
for
this
mapping.
D
A
F
Write
the
summary
here,
like
the
sdk,
is
not
expected
to
disregard
an
instrument
if
it
is
duplicated
and
the
exporter,
if
they
choose,
they
can
decide.
What
to
do
in
in
case
of
4p
should
not
be
an
issue
and
for
prometheus
we
can
decide
what
to
do
like
prefix
or
do
something
else.
A
A
A
A
Doesn't
seem
to
be
a
big
change
at
all,
so
please
take
a
look
and
approve
and
merge
it
next
topic.
I
I
guess
it's
the
right
time.
We
move
the
api
stack
to
stable,
I
think,
based
on
the
feedback.
So
far
I
haven't
seen
any
any
issue
or
question
related
to
the
api
I've
seen
there
are.
There
are
some
like
interests
in
talking
about
the
the
the
timer
instrument,
api
or
the
bung
instruments,
but
all
of
them
are
like
feature
that
we
we
can
add
later
after
the
stable
release.
A
So
based
on
that,
I
think
the
api
can
be
stable
this
month,
any
objection
or
we
should
wait
for
other
signal.
I
I
think
we've
spent
a
lot
of
time
on
the
api.
It
has
been
feature-free
since
end
of
august.
I
believe
yeah,
it's
been
a
while
yeah
and
I
haven't
seen
any
single
question
about
the
api.
It
seems
to
be
well
understood.
A
Okay,
the
last
thing
is
just
asking
for
help,
so
the
current
feature
metrics,
we
have,
we
have
java
and
doughnut
so
meanwhile
like
if
golan
and
python
are
making
progress.
Please
keep
this
updated.