►
From YouTube: 2021-11-09 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).
B
B
Okay,
let's
start
thank
everybody
for
joining.
We
have
a
few
items
and
a
reminder
that
we
will
be
using
the
last
20
minutes
of
the
call
to
discuss
metrics.
Okay,
the
first
item
I
put
that
one
there.
This
is
just
for
your
information.
Metrics
api
will
be
market
stable.
B
Probably
after
this
call
it
has
enough
reviews,
but
this
is
an
important
change
or
an
important
situation
that
everybody
needs
to
be
aware
of
that.
Once
this
is
merged,
I
will
prepare
the
the
monthly
release
just
for
your
information.
A
Macd
probability,
sampling
hi,
I'm
going
to
take
my
two
items
out
of
order
here
so
that
the
two
sampling
ones
line
up
first
note
is
the
technical
committee
received
some
feedback
a
month
or
so
ago,
saying
we're
really
hard
to
reach
and
maybe
not
a
very
transparent
group
to
the
community.
A
One
of
our
action
items
was
to
create
a
list
of
interests
so
that,
if
you
are
looking
for
someone
to
respond
on
a
particular
issue,
particularly
ones
that
cross
repositories
or
touch
the
specification
that
you
know
how
to
find
that
person,
I
have
created
that
list
and
merged
it,
and
I
put
a
link
in
the
notes
here.
This
is
an
open
invitation
to
anyone
who
has
an
interest
that
wants
to
advertise
it.
A
I've
listed
that
it
is
encouraged
for
technical
committee
members
and
invitation
for
everyone
else,
but
if
you
have
a
strong
interest
and
you're,
not
a
maintainer
approver.
Actually
I
would
like
you
to
list
your
interests
as
well,
so
that's
there
I'm
going
to
follow
up
today
with
another
pr
to
link
it
more
more
visibly
from
the
readme
and
the
community
repository.
A
So
please
feel
free
to
add
yourself,
okay,
my
second
topic,
which
is
out
of
order.
Last
week
I
gave
a
little
bit
more
depth
and
several
weeks
ago
I
gave
a
pitch
on
this
as
well.
The
probability
sampling
work
is
a
fairly
complex
specification
that
we
have
drafted.
It's
been
a
group
project
for
a
couple
of
months
now
to
really
pin
this
down.
I
would
say
it's
ready
and
very
close
to
being
perfectly
worded,
although
I'm
sure
you'll
all
be
able
to
read
it
find
problems.
A
It
is
it's
passed,
a
lot
of
reviews
and
I
think
we're
ready
to
get
the
enough
approvals
from
the
community
to
actually
merge
this,
and
if
you
will
please
take
a
look
at
that
and
consider
reviewing
and
proving
that
would
be
appreciated.
We
do
have
some
prototypes
and
can
demonstrate
this
is
working.
The
latest
round
of
updates
includes
a
test
specification
talks
about
chi,
squared
and
stuff,
like
that,
so
get
ready
for
some
statistics.
A
That
was
all
I
had
on
that
topic.
I
really
want
to
encourage
people
who
have
an
interest
in
this
to
help
get
it
merged.
Thank
you
now.
Carlos
has
another
topic
about
sampling.
B
Yeah
exactly
this
is
later
related.
Actually
I
couldn't.
I
don't
remember
what
was
the
reason
for
this,
but
basically,
at
this
moment,
sampler
description
is
meant
to
be
immutable
and
yuri
was
asking:
do
we
really
need
that?
So
I
don't
know
it
doesn't
seem
important
enough
to
remain
immutable
at
this
point,
but
if
anybody
remembers
why
that
I'm,
I
will
be
digging
after
this
call.
What's
what's
the
state
there.
A
Thank
you.
I
admit
I
was
confused
by
this
at
first.
I
have
to
go
look
at
the
issue
myself,
but
anyone
else
feel
free
to
comment.
B
A
This
is
this
would
be
a
good
topic
to
talk
about
in
the
sampling
site.
We
continue
to
have
that
every
thursday
at
nine
eight
o'clock,
pacific
time
and
yeah.
If,
if
you
have
an
interest
in
conveying
what
sampling
is
taking
place
using
a
description,
we
should
probably
talk
about
how
to
specify
that
formally
so
that
we
can
actually
convey
sample
descriptions
as
a
resource
value.
B
C
Okay,
cool
so
update,
as
carlos
mentioned
we're
getting
apis
back
to
stable.
So
thanks
everyone-
and
I
suggest
that
we
merge
the
pr
today.
Second,
one,
let's
go
to
the
issue
trigger,
so
it's
very
simple:
we
don't
have
any
new
matrix
issue
in
the
past
week,
so
all
the
existing
issues
have
have
been
triaged.
C
The
third
one
is
we
look
at
the
active
prs.
I
think
there
are
six
of
them.
This
one
should
be
a
very
simple
pr.
Just
add
some
additional
clarification
text
doesn't
change
anything.
So
my
suggestion
is
to
have
more
review
and
try
to
merge
that
as
soon
as
possible,
this
one
has
a
some
dos,
so
josh
sturridge
blocked
the
pr-
and
I
I
think
he
explained
the
reason
so
my
suggestion
is
for
cgio
to
abandon
this
pr.
C
C
This
one
is
a
little
bit
subjective,
so
I
want
people
to
review.
I
think
the
idea
is
in
some
languages
if
you
have
an
enum
the
value,
none
have
special
meaning
it's
kind
of
reserved,
while
job
has
a
very
explicit
meaning,
but
it
seems
the
overall
effort
like
in
the
attributes
and
the
other
stuff,
like
there's
some
additional
thinking.
So
given
this
is
very
subjective,
I
would
suggest
I
would
be
careful
and
get
more
reviewers.
A
Riley,
I
know
we've
labored
this
last
issue
that
you
had
up
there
about
meter,
name
and
instrument
name
uniqueness,
but
I
don't
think
we've
fully
resolved.
It
would
now
be
a
good
time
to
to
discuss
that
or
to
recap
that
for
the
group
yeah.
A
Yeah
yeah
and
I
don't
actually
want
to
put
you
on
the
spot,
I
feel
like
josh
s
might
have
an
opinion
he
wants
to
share
right
now
sure
it's.
The
last
comment.
D
I
knew
there
was
something
coming
yeah,
so
so
I
think
this
pr
is
really
short
up
well
and
what
we
do
when
we
export
spans
is.
We
require
this
hotel.library
parameter
right
and
we
say
that
like
this
should
be
consistent
to
do
cross,
telemetry
collaboration
and
that
sort
of
thing
I
think
so
so
the
only
the
only
problem
I
have
with
this
pr
is,
I
think,
by
default.
We
should
export
a
label
for
the
the
library,
I'm
not
100
positive
on
version
because
of
cardinality,
but
I
actually
think
it'd
be
fine.
D
If
we
make
that
the
default
as
well,
the
only
really
oh
hold
on
sorry
spam
call.
The
only
really
weird
thing
is:
we
might
not
be
able
to
put
a
dot
in
the
label.
I
forget
what
the
allowable
parameters
are
for
for
me
yeah,
so
we
might
have
to
call
it.
D
You
know
hotel
underscore,
but
like
I,
what
I,
what
I
want
to
see
out
of
this
pr
is
that
we
align
the
the
notion
of
systems
that
don't
support
instrumentation
library
by
default,
getting
instrumentation
library,
attributes
or
labels
the
same
way
we
do
for
trace.
That's
that's!
That's
what
I'd
like
to
propose
so
this
pr
effectively,
instead
of
instead
of
having
it
by
default,
there's
a
set
of
environment
variables
that
you
use
to
configure
which
ones
go
to
prometheus.
D
I
think
that
that
environment
variable
thing
is
okay,
we
have
a
whole
bunch
of
concerns
over
the
number
of
environment
variables,
we're
adding
in
general,
and
I
think,
there's
a
general
configuration
thing
that
we
need
to
resolve
relatively
quickly.
We've
had
that
discussion
a
thousand
times
the
only
thing
that
I
that
I
have
on
this
pr
is
I
I
actually
think
this
should
be
the
default.
This
should
be
the
default
for
every
metric
exporter
that
we
recommend
is
basically
if
your
metric
system
doesn't
support
the
library.
D
C
I
I
have
some
question:
I
like
the
general
direction,
but
I
think
the
the
details
could
be
very
messy.
For
example,
if
the
user
already
made
something
that
will
conflict
with
this
name
or
think
about.
If
we
have
two
different
libraries
and
we
have
never
specced
out,
if
the
library
name
should
be
case
sensitive
insensitive,
how
do
we
handle
some
special
characters
like
if
they're
trading
zero?
What
do
we
do
so?
D
So
that
all
of
those
concerns
exist
for
tracing
today
as
well,
so
all
I'm
suggesting
is
we
align
with
what
tracing
did
for
now,
and
I
I
think
that
most
of
that
kind
of
issue
we
can.
We
can
actually
squash
down
over
time,
but
but
if
we
want
to
spec
that
all
out
initially
that's
fine
too,
I
all
I'm
suggesting
here
is
we
should
align
exactly
with
what
tracing
did
like
metrics
as
much
as
possible
should
not
diverge
from
like
the
spirit
or
like
actual
specification
of
tracy.
C
The
reason
I
mentioned
this
is
recently
I'm
working
on
the
premises,
exporter
improvement
for
opentelemetry.net,
and
I
noticed
so
many
so
many
corner
cases
that
if
we
we
don't
make
it
very
clear,
it
will
cause
side
effects
to
the
backend
system.
For
example,
premises
allows
you
to
have
a
label
value
equal
to
an
empty
string,
but
what
does
it
mean
like
an
empty
string
means
you
don't
have
that
dimension?
C
C
D
D
So,
like
the
data
model,
spec
there's
a
there's,
a
draft
I
threw
together
for
that.
We
have
the
working
code
of
the
collector,
but
that's
mostly
going
from
prometheus
to
otlp
to
prometheus.
We,
we
are
somewhat
lacking
in
otlp2
prometheus,
like
the
full
set
of
otlp
right.
So
I
do
think
that
that
needs
to
get
specked
out.
D
So,
if
we're
not
comfortable
like
in
my
opinion,
if,
if
this
doesn't
line
up
with
trace,
I
want
to
do
some
prototyping
investigation
to
prove
what
this
looks
like
in
practice
and
that's
why
I
suggested
to
harold-
and
his
question
was
basically
like:
does
this
have
to
get
done
before
metrics
is
launched,
so
oh
prometheus
to
open
census,
dotopity
prometheus
nice,
nice
thanks
anthony
anyway.
D
A
A
I
agree
with
your
philosophy
josh,
that
in
general
the
the
trace
and
metrics
should
be
very
close,
and
we've
already
specified
this,
and
we,
I
think
we
already
have
a
name
specified
for
instrumentation
library
name.
Semantic
convention
should
be
the
same.
I
agree
with
all
that,
but
I
actually
don't
think
that
prometheus
wants
this
to
happen.
I
think
that
what
riley
referred
to
is
go.
A
The
confusion
that
will
be
created
is
going
to
be
tremendous
because,
if
you're
trying
to
migrate
from
an
existing
usage
of
prometheus
to
turn
on
your
hotel
libraries
and
continue
using
prometheus,
this
new
label
or
attribute
is
going
to
interfere
and
you're
going
to
want
to
remove
it
and
it's
going
to
create
trouble.
So
I
mean
open
question
here:
is
there
some
other
way
that
we
could
put
this
information
into
an
open
metric
stream?
A
A
Well,
it's
a
library!
Sorry!
I!
What
I
just
said
is
totally
false,
but
I
want
it
to
be
true,
which
is
to
say
that
it's
a
we've
added
we've
added
per
instrumentation
library,
schema,
url
properties
and
and
if
there
was
some
way
for
us
to
put
that
information
into
an
open
metric
stream,
that
would
be
more
appropriate
is
what
I'm
looking
for.
D
Yeah,
I
think
one
of
the
most
interesting
things
on
the
pr
was
a
question
of
whether
the
library
name
belongs
as
a
metric,
prefix
name,
so
that
we
can
actually
differentiate
metrics
the
way
open,
telemetry
does
inside
of
prometheus.
That
was
probably
the
most
compelling
proposal
of
a
interesting
thing
for
prometheus
that
I
really
thought
through
a
bunch,
and
I
kind
of
think
we
don't
want
to
do
that
for
various
reasons,
but
that
I
think
it's
worth
noodling
on
as
a
group,
probably
with
the
prometheus
working
group.
D
So
I
agree
that
this
discussion
should
probably
happen
over
there.
We
should
is
wired
on
the
call
I
didn't
check,
because
we
should
make
sure
he
comes
and
we
can
have
a
discussion
there.
A
I
agree
with
all
that.
I
I
still
feel
that
our
goal,
when
we
specified
instrumentation
library,
was
to
allow
that
the
two
metrics
actually
mean
the
same
thing:
they're
just
there's
a
way
of
keeping
them
distinct
and
by
that
logic,
leaving
off
this
attribute
ought
to
be
okay,
except
it
breaks
single
writer
rule.
A
We
need
to
have
an
aggregation
happen
before
it's
okay,
if
there
are
more
than
one
producers
of
the
metric,
that's
in
question
and
it's
impossible
to
say
only
add
that
attribute
when
there's
a
conflict,
because
it
will
be
too
late
by
that
point.
So
I
don't
see
a
good
solution,
unfortunately,
but
I
think
we
should
get
prometheus
involved.
C
So
may
I
ask
which
language
is
currently
doing
this
prototype?
I
can't
volunteer
on.net,
I'm
I'm
happy
to
do
whatever
that
accepted
like
can
help
to
speed
up
the
premises.
Exporter
spec!
C
D
There's
a
java
implementation
that
we
can.
We
can
take
a
look
at
that.
It's
pretty
easy
to
modify
as
well.
So
if
we
need
to
do
some
prototyping
there,
that's
also
a
good
one.
A
Because
I
want
to
say
I
want
to
say
something
like:
there
is
a
correct
solution
here.
The
data
model
says
what
should
happen
if
you
register
the
same
instrument
in
multiple
libraries
and
then
you're
going
to
erase
the
library
attribute,
you
must
aggregate
apply
the
default
aggregation
rules
so
inside
of
the
sdk.
A
If
we
knew
that
the
instrument
had
been
registered
twice,
then
we
can
arrange
for
them
to
have
the
same
aggregator
and
we
would
erase
that
attribute
effectively
that
attribute
at
the
sdk
at
creation
time
and
then
we'd
push
it
through
otlp
and
it
would
get
there
to
prometheus
correctly
and
the
correct
thing
would
have
been
done,
meaning
you
sum
the
two
counters.
If
they
happen
in
different
libraries,
but
then
what
would
the
collector
do?
A
How
would
the
collector
apply
that
same
transformation
and
it
it
gets
into
this
very
slippery
slope
where
we
have
to
talk
about
late
arriving
data
and
when,
when
you're
pushing
data
into
prometheus,
there
are
some
ambiguities
that
are
created
and
I've
I
mean,
I
think,
we've
as
a
group.
We've
avoided
talking
about
how
to
do
temporal,
re-aggregation
and
spatial
re-aggregation
inside
of
the
collector,
because
it
requires
a
stateful
processor
and
it
becomes
very
tricky.
So
the
problem
is,
it
gets
really
hard
to
do
with
the
collector.
E
To
be
clear,
the
collector's
transit
of
data
through
open
senses
from
the
prometheus
receiver
is
a
temporary
thing.
Hopefully
we
have
an
implementation
that
goes
directly
to
otlp.
We
need
to
get
some
more
experience
in
utilizing
it
before
we
actually
make
a
migration
to
and
rip
out
the
open
sense
as
part
of
that
path.
But
that
is
not
a
long-term
part
of
our
plans.
A
Think
what
we're
seeing
here?
Basically,
if
we
don't
address
this
issue
you,
it
will
be
very
clearly
possible
for
one
sdk
to
have
two
instruments
with
the
same
name
that
pass
through
prometheus
and
break
a
single
writer
rule
and
then
and
then
you
have
completely
incorrect
data
and
that's
why
harold
put
this
pr
together.
So
I
think
we
should
josh's
proposal
is
probably
the
best
one,
but
it
does
create
a
lot
of
trouble.
I
don't
think
it's
a
good
answer.
Sorry
to
interrupt
anthony.
E
You
just
say
I
I
think
I
might
be
more
concerned
with
the
collector
receiving
otlp
and
needing
to
export
that
to
prometheus,
and
how
does
it
deal
with
creating
or
aggregating?
As
you
said,
you
know,
we've
tried
to
avoid
having
reaggregation
inside
of
the
collector
and
keeping
memory
inside
of
the
collector,
and
if
this
is
going
to
lead
to
that
happening,
that
would
be
a
concern
that
I
have.
I.
A
Mean
I
think
it's
a
really
big
opportunity
for
the
project.
The
collector
ought
to
be
able
to
do
the
same
thing.
Prometheus
does,
which
is
these
recording
rules
which
are
there
to
eliminate
cardinality
and
to
do
stateful
transformations
before
you
output
metrics?
But
it
is
a
big
project
to
undertake,
especially
when
you
have
more
elements
in
your
data
model
than
prometheus.
A
So
if
I
am
pushing
data
to
prometheus
and
I
have
to
erase
an
instrumentation
library
label,
because
multiple
instruments
are
producing
the
same
metric
from
the
same
process,
then
I
have
to
keep
state
and
then
I
have
to
say
what
what
happens
if,
for
some
reason
that
processes
metrics
were
delayed?
Well,
we
can
kind
of
say
that
should
never
happen.
But
there's
not
like
there's
no.
Where,
where
the
data
model,
we
can
say
that
shouldn't
happen.
A
Like
some
more
metrics
came
in
from
the
same
application,
maybe
they
had
to
split
their
payload
into
two
parts.
Now
you
have
metrics
being
split
across
payloads
and
they're
arriving
in
the
collector,
and
you
have
to
statefully
remove
that
it's
really
hard,
because
now
what
happens?
If
some
more
data
arrives?
A
minute
later
or
two
minutes
later
or
five
minutes
later,
when
do
you
cut
that
off
and
how
do
you
really
work?
The
updates
to
happens
to
your
stateful
aggregation
over
time
during
that
acceptance
window
so.
D
So
can
I
can
I
call
out
if
we
were
to,
if
we're,
if
we're
to
short
this
discussion,
for
what
we
need
to
bring
to
prometheus
working
group.
I
just
just
from
a
high
level
we're
talking
about
otlp
into
prometheus
or
openmetrics
format.
Out
of
scope
is
prometheus
back
into
otlp.
We
are
not
planning
to
round
trip
instrumentation
library
into
prometheus
and
back
out.
That
is
just
off
the
table,
not
something
we
ever
care
about.
D
Okay,
because
nobody
has
mentioned
it,
and
I
just
want
to
make
sure
that
we
only
the
only
specification
we
really
need
here
is
otlp
to
permeate
where
we
round
out
more
of
the
open
telemetry
protocol
into
prometheus,
and
the
focused
discussion
should
be
what
and
how
does
instrumentation
library
get
encoded.
And
specifically,
if
you
look
at
riley's
concerns
where
we
can
have
meter
a
and
meter
b-
and
I
think
unit
is
less
important
than
description-
I
don't
remember,
does
prometheus
have
unit
or
is
it
in
the
description?
I
forget.
C
D
Yeah,
I
I
I
absolutely
agree
with
that
and
that
so
so
I
think
the
issue
is
the
same
for
any
of
the
metric
description,
attributes
of
like
unit
or
even
just
metric
type.
What,
if
you
have
a
metric
type
conflict,
I
think
we
agree
that
that's
kind
of
a
bug
if
two
meters
have
the
same
metric
name
with
a
different
type,
but
that's
allowed
by
our
data
model.
So
we
need
to
actually
spec
out
how
to
account
for
it.
So
it
sounds
like
we
go
to
prometheus
with
hey.
D
We
want
to
take
otlp
the
protocol
migrate
it
to
the
prometheus
data
model.
Let's
just
look
at
instrumentation
library
and
how
that
maps
and
just
focus
on
that
discussion
and
get
resolution,
and
then
we
can
expand
it
over
time
with
more
and
more
pieces
of
a
prometheus,
sorry
otlp
to
prometheus
spec
cool
josh.
D
I
know
you're
overloaded.
Is
this
something
like
I?
I
actually
can't
attend
the
prometheus
working
group
tomorrow?
Is
this
something
that
you
have
time
to
to
to
own?
Or
is
this
something
that
we
can
do
like
like?
What's
the
timeline
priority
of
this?
Is
this
something
we
could
tackle
next
week
in
a
discussion
with
the
prometheus
working
group,
or
is
this
something
that's
far
more
urgent?
We
need
to
start
hashing
it
out
now.
A
I
think
we
should
propose
your
original
suggestion,
which
is
we
just
add
this
attribute
and
see
what
they
say.
I
can
go
to
the
prometheus
working
group
tomorrow
and
do
that.
D
C
D
Yeah
that
shouldn't
be
too
hard
to
do.
I'm
there
there's
pr.
If,
if
anyone
from
the
java
sig
is
here
and
interested,
please
please
sign
up.