►
From YouTube: 2021-12-07 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).
A
B
A
Okay,
I
think
we
can
start.
I
have
the
first
few
items
in
the
agenda,
so
the
first
one
is
about
the
agent
management,
so
the
the
agent
management
work
group
was
started
with
the
to
come
up
with
a
remote
management
solution
for
open
plan
sheet,
collector,
possibly
other
standalone
agents.
A
Among
the
capabilities
that
we
are
considering
is
the
ability
to
remotely
configure
the
agents
to
push
the
configuration
from
some
some
central
management
server
to
the
agent
so
and
immediately
I
guess
after
we
started
this
work,
we
got
a
request
to
consider
extending
the
this
this
to
to
open
telemetry
sdks,
to
essentially
push
the
configuration
of
the
sdks
in
a
similar
way
from
some
central
location
to
the
sdks.
A
A
A
A
A
The
idea
was
to
revive
the
the
original
meaning
of
the
intent
behind
the
instrumentation
library,
which
was
proposed
initially
as
the
component
as
a
concept,
so
I
was
exploring
whether
it's
even
possible
technically
right,
whether
that
would
be
a
breaking
change.
If
we
tried
to
do
that,
it
seems
like
it
is
a
breaking
change.
At
least
the
the
javascript
investigation
shows
that
we
we
can't.
C
C
I
also
wanted
to
quickly
mention,
at
least
in
my
understanding,
instrumentation
library
and
component
are
not
the
same
thing
component
is
the
is
the
component
that's
being
instrumented
like
mysql
and
the
instrumentation
library?
Is
the
library
that's
doing
the
instrument
thing
so
like
auto
instrumentation,
my
sequel,
or
something
like
that?
C
In
some
cases
those
could
be
the
same
where
a
library
has
instrumented
itself
for
like
native
instrumentation
and
stuff
like
that.
But
there
are
two
different
concepts
and
I
believe
they
should
be
represented
by
two
different
fields.
If
we
want
to
have
them
both.
A
C
A
So
I
guess
anyway,
going
back
to
the
to
the
idea
of
exploring
the
renaming
right,
it
seems
like
renaming,
is
not
really
possible
to
do
it's
too
late.
It's
now
part
of
the
our
our
guarantees,
which
then
I
don't
know
to
to
me.
A
The
consequence
of
that
is
actually
that
we
cannot
extend
the
meaning,
in
my
opinion,
of
the
instrumentation
library
of
the
concept
of
it.
It
would
be
too
much
of
a
stretch
to
me
to
we
try
to
somehow,
even
even
if
we
ignored
what
you
said
daniel
and
try
to
say
that,
oh
no,
you
know
what
the
component
is
actually
what
we
intended
to
record
in
the
instrumentation
library
name.
I
think
that
would
be
too
much
of
a
stretch,
given
that
the
name
it's
it's
very
precise,
the
instrumentation
library
is
a
specific
name.
A
It
has
a
specific
meaning.
It
has
a
definition
now
and
trying
to
say
that
the
intent
was
different,
we're
going
to
record
something
else
in
that
field.
Instead,
I
think
that's.
I
think
that
would
be
wrong.
That's
that's
my
opinion.
I
think
we
should
keep
the
meaning
as
it
is,
which
again
that
has
a
consequence
right.
It
means
that
the
whole
notion
of
let's
bring
that
back.
Let's
bring
back
the
original
meaning,
then
maybe
rename
it
and
then
use
it
for
the
logger
name.
A
C
So
if
we
want
it,
just
for
the
logger
name,
then
having
the
logger
name
as
a
top
level
component
might
make
sense.
If
we
want
it
for
the
other
signals
as
well.
It
may
make
sense
to
introduce
some
new
field
like
instrumentation
target,
or
something
like
that,
or
you
know,
maybe
even
bring
component
back
and
have
them
both
live
side
by
side,
because
they
do
have
separate
meanings
and
then,
in
some
cases
for
native
instrumentation
they
would
either
have
the
same
value
or
you
would
omit
one
of
them
or
whatever
makes
sense.
A
Okay,
so
I
guess
I
what
I'm
going
to
do
is
probably
closed
the
issue
which
says
which
asks
for
renaming
and
then
I
will
probably
open
another
issue
which
which
tries
to
discuss
what
we're
just
trying
to
discuss
whether
the
reason
to
have
an
alternate
concept
additional
or
no,
and
and
where
do
we
want
to
go
from
that?
But
I
think
kind
of
that.
The
renaming
at
this
point
seems
to
be
a
dead
end.
To
me.
A
A
This
was
discussed
in
the
login
sig
and
we
found
the
needs
to
record
the
observed
timestamp
as
opposed
to
the
generated
timestamp
the
time
when
the
event
was
generated
in
the
log
records.
The
the
detailed
description
is
there.
I
linked
it
in
the
agenda.
Please
have
a
look
at
the
proposal
and
see
what
you
think
about
it.
The
logging
sig
has
discussed
it
and
is
in
favor
of
adding
it.
We
have
approvals,
but
I'd
like
to
maybe
have
a
broader
discussion
and
more
feedback
from
others
as
well
before
we
move
forward
with
that.
D
Perfect,
thank
you
so
much
tigran
yeah
by
the
way
in
the
latest.
We
are
the
observed
time
stamp.
I
see
that,
as
you
mentioned,
that
there
are
enough
reviews
from
the
log
seek,
so
you
want
reviews,
because
you
want
to
merge
this
or
you
think
that,
like
members
from
other
signals,
should
review
this
anyway,
I'd
like
to
have
more
broader
acceptance.
D
Okay
moving
forward,
then
martin
request
for
comments
on
this
draftspr2192.
D
E
D
E
Okay,
sorry,
okay,
so
I
we
had
discussion
about
this
at
the
last
couple
of
meetings
and
I
opened
a
pr
as
a
result,
and
I
actually
need
some
guidance
here,
because
I'm
realizing
that
there
are
two
things:
two
things
that
I
that
I
don't
know
how
to
handle
exactly
in
the
pr.
E
Essentially
I'm
trying
to
I'm
trying
to
introduce
a
new
new
field
geometry
source
name
that
would
define
the
name
of
the
source
of
the
telemetry
independent
of
the
type.
So
we
in
the
client
side,
client
side
sake.
We
we.
What
we
want
to
do
is
send
send
this
all
started
by
by
the
need
to
identify
the
type
of
telemetry,
in
our
case
the
client-side
telemetry.
So
in
a
different
pr,
I
proposed
adding
a
new
set
of
attributes
prefixed
with
app.
E
So,
instead
of
service
dot
name,
you
would
have
app.name
and
corresponding
attributes,
and
there
was,
I
think,
what
we
realized,
that
service
name
right
now
is
required,
and
it's
used
to
identify
its
intended
aside
from
describing
a
service
like
a
backend
service
is
intended
to
describe
just
a
generic
source
of
telemetry.
So
the
purpose
of
this
pr
was
to
introduce
an
independent
set
of
fields
or
field,
and
so
our
one
thing
that
I
have
a
question
about
is
the
backwards
compatibility
with
service
dot
name.
E
It
appears
that,
since
it's
required,
this
would
be
a
breaking
change,
and
I
guess
what
I
would
like
to
know
is:
should
should
the
service
name
be
always
required
or
only
for
back-end
applications
as
a
backwards
compatibility?
A
A
A
Maybe
it
should
be
in
everything
that
sdks
they
meet
so
so
possibly,
but
then,
if
that's
true
like,
if
we
have
client-side
applications,
then
we
should
call
them
services
as
well
right
for
this
requirement
to
make
sense.
So
I
guess
the
question
is
there
right?
Do
we?
Are
we
actually
happy
to
say
that
the
service
is
something
that
also
includes
client-side
applications?
A
F
F
I
think
the
collector
can
get
around
it,
because
it's
probably
worded
in
a
way
that
it's
just
for
sdks
but
the
the
decision,
the
the
client
side,
instrumentation
team,
I
think,
was
not
as
active
when
we
made
that
original
decision
on
service
name
and
there's
a
big
big,
big
negative
to
calling
it
service
name
in
that
we're
gonna
constantly
have
people
come
in
and
say
why
the
hell
is
this
a
service?
F
I
don't
get
it
right,
so
the
thing
that
we're
looking
at
trying
to
figure
out
how
to
do
now
is:
can
we
change
what
we
have
today
in
a
non-breaking
way
such
that
the
client-side
instrumentation
can
use
something
called
application
and
and
back-end
you
know,
instrumentation
can
use
something
code,
service
and
everybody's
happy.
F
So
the
problem,
though,
is
that
we
specified
service
name
is
required
right.
That's
that's
how
it's
specified,
but
the
idea
of
trying
to
stick
with
service
name
and
forcing
client-side
to
use
that
I
think
there's
agreement
at
least
there's
a
big
big
big
negative
in
the
client-side
instrumentation
around
this,
causing
massive
confusion
in
hotel.
So
we'd
like
to
try
to
avoid
that,
if
possible.
In
any
proposal,
we
have
so
just
to
just
to
put
some
clarity
on
the
the
discussion
here.
F
That's
that's
kind
of
the
discussion
we're
having
is
like
how
do
it
it's
similar
to
your
instrumentation
library,
effort
of
you
know.
We
don't
want
to
rename
the
thing
we
kind
of
want
to
add
a
new
thing
that
works
with
the
old
thing
right.
So
what
does
what
does
that
look
like,
and
how
do
we
change
the
spec.
A
A
I
I
I'm
not
I'm
not
quite
sure
about
that,
because
the
collector
definitely
missed
telemetry,
which
does
not
include
service
them
today,
and
it's
been
like
that
for
a
very
long
time
now.
Does
that
mean
that
all
all
of
that
that
the
collector
emits
is
un
receivable
by
by
those
backhands?
Is
that
really.
G
G
B
I
mean
what
we
could
do
is
propose
some
kind
of
way
of
having
back-end
back-end
specific
translations
from
this
or
this
or
some
default
and
lessen
the
requirement.
But
I
don't
know
how
that
will
relate
to
the
change
of
the
api
across
the
wire,
but
one
of
the
saving
graces
of
where
we
are
with
protobuf
right
now.
Our
protobuf
definition
is
all
fields
are
optional.
Like
protobuf3,
there
is
no
required
field.
G
G
I
think
we
can
certainly
choose
something
different
and
we
could
probably
say
one
of
service
name
or
application
name
is
required.
I
don't
know
what
the
impact
to
consumers
will
be.
If
we
do
that,
though,.
F
That
is
absolutely
required,
like
a
new
name
thing,
and
so
martin
has
a
the
proposal
actually
has
a
namespace
and
a
name
pair,
but
it
could
just
be
a
single
thing,
but
there's
a
new
thing
that
that
represents
both
an
application
and
service,
and
then
you
would
also
have
a
duplicated
service
that
name
and
application
that
name
so
the
the
problem
is:
is
this
backwards
compatible
or
not
with
our
previous
spec
right?
Because,
yes,
in
the
future,
there
will
be
a
guaranteed
name.
F
You
can
use
for
all
jager
zipkin
exporters
right,
but
do
sdks
need
to
kind
of
backfill
service.name
from
application.name
for
correct
behavior
to
keep
backwards.
Compatibility.
That's
like
the
open
question
here
is
like
how
do
we
handle
that
scenario,
but
in
terms
of
what
the
proposal
is
it's
to
have
a
new
name,
that's
unique
and
then
have
service
dot,
name
and
application,
sorry,
service,
dot,
star
and
application,
dot,
star
exposed
and
open
for
whatever
services
need
and
whatever
front-end
applications
need
right.
That's
that's
the
proposal
on
the
table.
F
It's
just
the
the
detail
here
is:
how
do
we
take
a
service.name
requirement
and
make
a
backwards
compatible,
spec
change
so
that
folks
don't
break
during
transition.
E
E
Great
there
is,
there
is
other,
like
related
topic
to
my
other
bullet
point,
which
is,
we
need
a
way
to
identify
the
type
of
telemetry,
and
originally
we
thought
that
the
presence
of
the
app
attributes
would
would
indicate
that.
It's
that
it's
a
you
know
that
it's
a
client-side
telemetry,
but
the
problem
now
is
like,
if
you
make,
if
you,
if
you
use
a
different
name,
and
the
only
attribute
that
is
required
is
the
name
then
potentially
would
happen
that
there
are
no
app
attributes
at
all.
E
So
so
you
so,
I
guess
my
my
additional
question
or
proposal
would
be
to
introduce
another
field.
That's
like
an
enum
of
type.
F
So
if
you
read
the
semantic
inventions
around
resources
right
now
for
a
particular
resource,
there
are
required
attributes,
there's
only
one
required
attribute
for
all
resources,
which
is
service.name,
but
if
you're
running
kubernetes
with
the
symantec
conventions,
we
actually
say
like,
if
you're
going
to
provide
a
resource
around
like
a
kubernetes
pod.
Here
are
the
things
you
need
to
provide
and
I
think
it'd
be
totally
acceptable
for
for
you
to
say
if
you're
providing
telemetry
from
client-side
here
are.
The
here
are
the
things
you
have
to
provide.
F
I
don't
think
we
need
a
type
there,
because
you
should
be
able
to
leverage
that
same
like
app.name
in
the
sense
of
basically,
one
thing
to
think
about
here
is
resource.
Attributes
are
actually
expensive
because
we
send
them
with
with
with
telemetry
we
at
least
we
should
think
about
not
sending
them
not
sending
a
maximal
set.
F
We
should
think
about
sending
a
minimal
set,
that's
identifying
in
our
spec,
and
then
users
can
expand
as
they
need,
because
we
need
to
make
room
for
them,
and
if
we
have
this
giant
bundle
of
tons
and
tons
of
crap,
then
unless
users
really
want
all
of
that,
it
makes
it
hard
for
them,
especially
if
we
specify
these,
as
must
anyway,
back
to
the
original
thing.
I
think
you
should
be
able
to
specify
a
app.
F
thing
for
like
if
this
comes
from
a
browser
or
app.you
know
whatever.
If
this
comes
from
a
mobile
phone
right
and
etc
for
other
devices,
and
you
should
be
able
to
rely
on
that
because
the
way
those
resource
semantic
inventions
are
defined
are,
if
you're
running
on
this,
here's
the
semantic
conventions
that
we
provide
for
consistent
resource
identity
across
the
system.
We
still
have
a
bit
to
dive
into
whether
or
not
these
are
additive
right.
F
F
Now,
yeah
yeah
yeah
there's
a
difference
between
required
and
convention
right
like
I,
I
honestly
think
that
if
you
mark
this
as
optional,
but
every
single
piece
of
telemetry,
our
group
provides,
has
it
by
default
and
the
tools
don't
work.
If
it's
not
there,
it's
effectively
required
and
everyone
will
treat
it
that
way,
but
we,
but
it
also
gives
us
room
to
kind
of
fix
things
and
spec
later.
If
we
decide,
we
want
to
migrate
in
non-breaking
ways
right.
So
that's
one
reason
that
we
use
optional.
E
F
So
so
the
identifying
thing
where
you
want
to
know
it's
from
client
side.
I
guess
if
we
step
into
that
use
case,
what
what's
the
specific
use
case
there
that
you're
trying
where
you
would
need
to
identify.
This
came
from
a
client
versus
this
came
from
a
server
yeah
and
and
in
that
use
case,
what
are
your
identifying
attributes
you
can
use
distinguish
between
the
two.
H
Yeah
is,
does
the
client
say
you
have
specific,
you
know
reasons
why
they
think
that
the
like
a
a
client
telemetry
source,
you
know
its
instrumentation
needs
to
be
differentiated
from
services,
or
is
that
just
kind
of
looking
into
the
future
and
projecting
like?
Are
those
use
cases
there
where
you
need
to
differentiate
between
the
two.
E
We
think,
or,
like
the
shape
of
the
data,
is
going
to
be
very
different
too,
like
so
like,
for
example
like
we,
we
think
that,
like
the
the
most
of
the
sick,
a
lot
of
the
signals
coming
from
client
side
are
gonna,
be
events
and
like
we're
gonna
have
to
like
distinguish
between
logs
and
events
for
client
side,
so
like
on
the
back
end.
The
processing
of
those
that
type
of
telemetry
is
going
to
have
to
know
where
to
send
it.
F
Okay,
so
what
I
would
say
to
make
progress
here
is,
I
don't
think
we're
going
to
make
a
decision
because
we're
introducing
people
to
the
topic-
everyone,
please
read
the
pr
for
martin.
It
might
make
sense
for
you
to
list
some
requirements
around
that,
like
the
the
bit
around
logs
as
events
is,
is
pretty
interesting.
If
we
could
write
and
I'm
gonna
use.
F
Business
speak
like
a
requirement
stock
of
like
here
are
the
requirements
that
we
have
for
what
we
need
from
a
client
side
right
and
then
that
can
help
people
evaluate,
because
I
I
do
think
this
generic
id
can
work
out.
We
can
do
it
in
a
backwards
compatible
way,
but
if
you
also
need
a
way
to
identify
absolutely
this
was
client-side.
So
I
interpret
my
logs
differently.
F
E
Okay,
yeah
in
that,
in
the
apr
that
I
opened
for
the
source
name,
I
I
did
list
the
requirements
that
I
that
I
think
are.
F
In
play
here
great,
so
then
it
sounds
like
people
need
to
read
it
and
we
need
to
give
them
time
to
think
through
it.
I
don't
think
like
like
effectively.
I
think
more
discussion
today
won't
be
more
productive
than
it's
already
been.
So
maybe
we
come
back
and
reevaluate
in
a
discussion
in
a
week
and
we'll
see
what
comments
we
get
on
the
thing
I'll
take
some
time
myself
to
help
maybe
craft
a
proposal
around
the
backwards
compatibility
issue
and
send
it
to
you
for
you
to
think
over.
F
D
Perfect,
thank
you.
We
have
by
the
way
time
box
of
20
minutes
by
the
end
of
the
call
to
discuss
metrics.
So,
let's
move
fast.
Oh
there's
only
one
more
point:
johannes,
are
you
around?
Yes,.
I
I'm
around
will
take
much
less
than
10
minutes.
I
just
wanted
to
give
a
quick
update
about
the
fro.
The
message
messaging
semantic
conventions
work
on
messaging
work
group.
Last
week
we
put
up
an
early
draft
out
tab
just
here
to
capture
the
agreements
that
we
made
so
far,
which
are
around
context
propagation,
so
that
odep,
it's
not
really
for
like
a
real,
you
edited
review.
Yet
it's
not
ready
for
real
view.
It's
just
for
people
who
want
to
see
what
we
already.
I
What's
the
state
of
the
current
work
and
we're
right,
you
can
look
in
the
result,
tab
and
we
will
update
that
as
we
go.
Currently,
we
have
some
first
bits
there
regarding
context
propagation.
We
have
quite
some.
We
have
an
agreement
there
and
we
are
now
discussing
the
span
structure,
attributes
and
then
the
last
part
left
will
be
here,
the
individual,
like
systems
where
we
want
to
give
conventions.
For
so
we
will
update
this
tab
as
we
go
and
yeah.
Whoever
is
interested
in
like
offline
collaboration
or
wants
to
see
where
we
at
that
is.
I
This
old
tip
is
the
point
the
point
to
look
for.
D
Yes,
I
already
see
some
comments
there,
so
yeah,
it's
good
discussion
is
going
already.
Thank
you.
Okay.
If
there's
nothing
else
to
comment,
we
can
jump
into
metrics.
Yours.
F
All
right
we've
had
a
no
screen
sharing
day
so
far,
so
I'm
going
to
continue
the
tradition
we
have.
We
have
we're
trying
to
get
the
metric
sdk
mark
stable.
So
there's
I
have
a
link
here
in
the
docs
to
the
project
that
you
can
see
all
the
different
things,
but
I
did
a
quick
roll
up
summary
here.
So
we
have
two
to
do's
that
are
in
progress
with
no
one
actively
working
on
kind
of
one
is
the
clarify
some
aggregation
bug
that
just
came
in.
F
F
If
for
histograms,
it's
hey
go
record
this
value
in
a
metric
for
async
callbacks,
it's
hey,
here's
the
current
value
of
the
whole
sump
and
I'm
going
to
call
those
like
total
or
cumulative
values
right
then,
we
also
have
a
counter
instrument,
which
is
hey,
add
this
to
the
value
that
you've
stored.
F
Okay,
that
is
a
delta
recording
or
a
partial,
recording,
okay,
and
so
some
aggregation
for
partial
recordings.
Like
sums
all
those
things
together
and
gives
you
some
at
the
end,
that's
that's
what
it's
designed
to
do
and
the
bug
is
asking.
Does
it
make
sense
to
sum
async
instruments
where
they
give
you
an
entire
value?
F
And
the
answer
here
is
incredibly
nuanced
to
some
extent.
So,
partly
the
answer
is
no.
You
shouldn't
sum
together
to
absolute
values,
but
the
other
answer
is
yes.
You
should
because,
if
I
define
a
view
where
I
get
rid
of
a
label,
what
some
tells
me
to
do
is
if
I
have
two
measurements
across
two
labels
and
I'm
getting
rid
of
the
label.
I
sum
those
two
things
together
right
and
so
that's
what
some
aggregation
means
for
async
instruments.
The
question
to
the
group
is:
I
just
gave
that
description.
F
Should
we
put
that
in
the
spec?
Does
that
need
to
be
in
the
spec
or
is
it
implicit?
I
I'm
kind
of
asking
other
implementers
of
the
spec
how
confusing
this
is
for
clarity
in
the
java
prototype,
not
the
current
implementation,
I
actually
had
a
difference
between
a
delta
measurement
and
a
cumulative
measurement.
I
called
them
out
explicitly
to
avoid
confusing
myself
over
how
to
use
this,
and,
in
the
end
it
turned
out.
I
used
them
pretty
much
the
same
way,
no
matter
what
the
code
didn't
change,
so
I
got
rid
of
that
distinction.
H
A
quick
question
josh
so
if
let's
say
you're
going
down
the
path
where
you
know
you
actually
did
want
to
sum
together
these
these
async
observations
and
you
didn't
have
a
view
that
did
spatial
reaggregation
would
would
the
would
it
be?
If
is
there
any
actual
sum
taking
place,
or
are
you
just
kind
of
you
know,
because
you're
observing
a
cumulative
sum
already
you're
just
admitting
that
basically,
I'm
trying
to
ask
is
this
question
only
relevant
if
you
have
views
in
place
or
not.
F
F
We
had
talked
about
it
being
an
error.
Cjo
put
a
related
issue
here.
I
think
that
maybe
I
believe
we
had
talked
about
this
before
that's
kind
of
considered
an
error
with
use.
Dropping
some
attribute.
J
F
J
F
Yeah
well,
we'll
have
to
actually
define
those
terms,
because
I
try
to
avoid
that
in
my
description,
just
because
I
tend
to
use
too
much
metric
jargon
so
apology
anyway,
we
should
actually
define
those
terms
and
put
it
in
anyone
have
time
to
take
this
bug
and
add
those
that
guidance.
F
Riley
added
supplementary
guidelines
found
the
issue
posted
by
cjo.
Okay,
if
that's
the
case,
we
can
close
this
bug
josh,
since
you
commented
that
would
you
want
to
take
this
bug?
Do
you
have
time
the
the
new
bug
sure
I
will
add
that
cool?
Thank
you
cool,
so
that
was
that
was
issue
number
one.
That's
a
to
do.
The
second
one
is
around
periodic
metric
reader
clarification.
We
had
talked
about
this
before
there's
a
action
item
that
effectively
during
the
metrics.
F
So
the
confusing
thing
here
was
whether
or
not
the
collect
method
is
exposed
on
periodic
metric
reader
for
subclasses
or
external
people
to
call
or
if
periodic
metric
readers
should
not
allow
anyone
but
its
timer
right
to
to
collect
metrics.
That's
that's
the
current
issue
and
basically
we
talked
about
just
having.
We
specifically
allowed
this
to
be
flexible
and
someone
wanted
to
write
a
example
code
here.
That's
what
that's
what
we
discussed.
F
F
It
okay,
oh
great
thanks
aaron,
I
didn't
realize
it
was
assigned
to
you
you're,
the
reporter
and
the
assignee
wow,
okay,
great,
so
that
one
that
one's
taken
care
of
all
right.
So
then,
if
we
go
into
in
progress,
we
have
two
pr's
that
are
open.
One
is
around
limiting
view
renaming,
so
I
want
to
call
this
out,
especially
since
cjo
is
on
the
call
this.
F
This
is
a
basically
we
are
concerned
around
the
current
spec
being
a
little
too
flexible
and
we
wanted
to
limit
one
area
where
we
know
things
fall
apart.
So
if
you
specify
a
view
name
and
you
have
some
sort
of
an
instrument
selector
that
you
know
selects
many
many
many
many
possible
instruments
or
metric
names,
it
can
cause
errors
because
you
can
only
have
one
view
name
for
one
instrument.
F
If
that
makes
sense,
you
can
have
multiple
views
per
instrument,
but
you
can
only
have
one
of
the
same
name,
and
so,
if
you
use
a
name
rule,
you
can
get
into
a
problem
where
you
basically
suppress
a
bajillion
metrics
by
accident.
F
So
we
wanted
to
actually
outlaw
that
the
spec
that's
what
this
pr
is
about,
there's
a
bunch
of
feedback
from
cjo.
That
was
great,
so
I
tried
to
respond
to
it,
but
effectively.
The
the
wording
of
this
limitation
is
now
limited
to
only
where
people
pre-register
selection
criteria.
F
So
please
take
a
look
I'd
like
to
try
to
get
that
that
through
this,
because
this
is
a
spec
change
it,
it
makes
a
must
requirement
that
or
that
we
could
alleviate
later,
if
we
need
but
right
now,
if
we
don't
get
this
through,
basically
we
have.
We
have
it
open
in
the
spec,
so
everyone
needs
to
allow
it
as
opposed
to.
If
we
disable
it,
we
can
fix
it
later.
Okay,
the
other
thing
in
here
outside
of
limiting
views,
was
exemplar
clarifications.
F
There's
some
good
discussion
on
that
as
well.
There
are,
there
should
be
no
semantic
changes
to
exemplars
here,
but
this
is
there.
There
were
a
whole
bunch
of
various
concerns
and
bugs
that
I
try
to
address
in
the
same
pr,
so
I'll
just
call
out
two
one
was:
when
do
you
reset
exemplar
state,
and
so
I
just
wanna
comment
that
the
intention
in
the
spec
is
that
exemplars
should
be
sampled
from
the
time
period
that
the
metric
data
point
is
reported
against.
F
So
there's
a
there's,
an
exemplar
reservoir,
that's
specified
with
a
you,
know,
sample
a
measurement
and
a
collect
method
right.
The
state
of
that
thing
needs
to
be
reset
based
on
the
cumulative
or
delta
time
window
that
you're
using
for
your
exemplars,
because
your
exemplar
should
be
against
the
entire
cumulative
window
or
against
the
entire
delta
window.
That's
kind
of
the
idea
behind
exemplars.
F
I
don't
think
I
did
a
great
job
in
the
spec
and
I
think
you
all
called
it
out.
Please
take
a
look
at
this
clarification
and
and
make
suggestions
for
how
to
clear
make
that
easier
to
read
and
easier
to
understand
that
that's
part.
One
part
two
was
there's
a
question
around
the
motivation
behind
exemplars
and
what
they
do.
Why
they're
different
than
traces
and
what
kind
of
correlations
they
enable
that
aren't
otherwise
possible?
F
So
that
is
also
added
in
there
and
yeah
thanks
to
everyone
who
reviewed
that
so
far,
but
we
could
use
some
more
eyes.
F
The
last
is
a
bug
that
I
don't
think
anyone
has
submitted
a
pr
for-
and
I
think
is
somewhat
worth
discussing
here-
and
this
is
around
removing
baggage
interactions
from
the
view,
api
and
metrics
okay,
so
con
the
the
the
discussion
on
the
bug
was
just
to
mark
this
aspect
of
the
spec
unstable,
which
is
okay,
but
I
also
think
we
should
discuss
so.
The
the
the
issue
was
raised
by
anurag
and
here's
here's,
the
tldr.
F
We
are
building
instrumentation
libraries
for
our
instrumentation,
an
instrumentation
library
is
a
higher
level
library
that
is
meant
to
give
both
traces
and
metrics.
That
library
should
be
able
to
decide
the
interaction
of
baggage
and
they're
trying
to
extract
attributes
once
for
both
traces
and
metrics.
F
In
the
current
tracing
spec,
there
is
no
direct
like
implicit
interaction
between
generating
a
trace
and
baggage
that
is
always
manual
by
the
user.
In
the
metric
spec.
We
change.
We
we
did,
we
added
in
views
the
ability
to
automatically
pull
baggage
attributes
out
in
a
view
and
declare
that,
as
part
of
the
configuration.
F
And
we
prototyped
that
and
got
it
working.
So
a
metric
view
can
say
here
are
baggage
attributes
that
if
you
find
you
should
pull
and
attach
it
to
the
metric,
the
interaction
with
tracing
is
completely
unknown
and
the
interaction
with
this
instrumentation
library
design
that
currently
exists
in
java
is
very
poor
in
the
sense
of
the
instrumentation
library
will
pull
out
baggage
attributes
the
view
library
will
also
pull
in
baggage
attributes.
You
get
a
conflict,
that's
just
implicitly
ignored,
and
so
it
kind
of
works.
But
it's
really
weird
right.
F
So
the
question
here
is:
what
do
we
want
to
do
about
baggage,
and
I
want
to
expand
to
say
what
should
we
do
for
the
release
of
the
metrics
sdk
initially
do
like
do?
We
want
to
include
any
kind
of
baggage
interaction.
B
I
I
want
to
step
in
as
I'm
trying
to
kind
of
follow
up
behind
josh
in
implementing
the
go
side
of
this,
and
that
was
one
of
the
things
that
I
quickly
found
at
pointed
out
is
if
we
have
this
ability
for
the
views
to
take
information
from
the
context
of
the
the
synchronous
thing,
which
is
where
the
baggage
ends
up
living,
then
we
also
have
to
we
first
off
have
to
propagate
that
context.
B
All
the
way
through
to
the
views
and
beyond,
like
how
it's
originally
aggregated,
all
the
way
into
the
views,
but
then
also
it
has
this
weird
interaction
of.
B
Why
is
this
an
option
that
we
have
in
the
metrics
portion
when
this
is
realistically
something
that
needs
to
be
in
an
instrumentation
library
like
your
http
instrumentation
library
can
give
you
an
option
to
pull
the
baggage
out
where
it
actually
has
context
about?
Where
that
that
baggage
is
coming
from
and
how
that
might
be
handled.
B
So
my
recommendation
is
honestly:
we
shouldn't
be
pulling
it
out
at
the
in
the
higher
order
library.
It
should
be
at
the
one
step
below
like
if
your
http
library
is
instrumented
with
hotel
code,
they
should
be
manipulating
the
context
and
then
the
baggage
there.
F
I
see
your
definition
of
higher
order
and
mine
are
inverted.
So
to
me,
the
metrics
sdk
is
the
lowest
possible
library
that
you
can
leverage
right
and
then
the
tracing
would
be
like
the
lowest
possible
trace
in
library
and
instrumentation
libraries
built
above
it.
So
the
idea
here
is,
we
make
baggage
interactions
explicit
and
then
the
the
higher
level
library
can
can
deal
with
it.
F
So
we
just
remove
like
what
I
don't
want
to
do
is
have
baggage
be
experimental
in
the
sdk
that
we
launch,
because
it
means
that
all
of
our
apis
around
views
have
to
be
able
to
handle
that
in
the
future
or
release
in
a
stable
way
that
can
handle
it
where,
if
we
don't
plan
to
do
it,
that's
kind
of
a
big
tax
right.
I
know
that
the
baggage
thing
is
working
in
java.
F
I
I
don't
know
if
dot
net
implemented,
that
bit
or
not,
but
the
lack
of
baggage
interaction
trace.
I
don't
think
was
a.
We
don't
want
to
have
interaction,
the
trace
api.
It
was,
we
don't
know
what
to
do
yet
right.
B
I
think
at
some
point
the
baggage
interaction
at
the
instrumentation
library,
at
the
like
hotel,
http
library,
has
enough
context
from
the
request
to
pull,
can
have
enough
context
from
the
request
to
pull
out
the
user-specific
options
and
put
them
into
metadata
that
we
propagate
normally
through
traces
right,
and
I
think
the
same
thing
can
exist
within
metrics.
We
don't
necessarily
need
to
have
that
added
at
the
next
layer,
either
up
or
down.
However,
you
want
to
describe
it.
F
Yeah,
I
guess
my
argument
here
would
be
then
that
I
I
think
we
need
to
specify
what
that
configuration
looks
like
around
leveraging
baggage,
like
so
one
of
the
ideas
behind
views.
So
for
those
of
you
familiar
with
prometheus
because
it's
the
biggest
metric
system
prometheus
has
this
thing
called
rewrite
rules
that
are
used
heavily,
and
that
is
how
do
I
control
what
metrics
are
ingested
right
and
it's
it's
the
most
significant
important
thing
you
need
to
add
beyond
just
having
a
client
library
for
push-based
metrics,
it's
the
opposite!
F
Recording
rules,
sorry
rewrite
rules,
recording
rules.
I
was
telling
rewrite
rules
because
they
rewrite
whatever
recording
rules
so
push-based
metrics.
Our
solution
to
that
is
views
right
because
we're
the
source
of
the
truth
and
the
way
we
limit
what
goes
over.
The
network
is
actually
like
right
in
what
we
push
and
in
the
collector,
then
there's
like
filters
and
things
that
we
can
do.
But
views
are
the
first
line
defense
around
not
generating
too
much
telemetry
and
not
sending
too
many
network
things
that
we
can
handle
in
prometheus.
F
You
know
there's
those
like
header
things
where
you
can
say
like
limit
the
number
of
metrics
and
all
that
stuff.
When
you
make
a
call,
that's
your
config,
that's
that's
their
version
of
use.
This
is
so
we
need
configuration
to
be
able
to
handle
this,
and
my
concern
right
now
is
how
consistent
will
baggage
be
with
selecting
like
what
spans
I
emit,
which
what
metrics
I
emit.
What
attributes
those
metrics
have
like
I
wanna.
F
So
it
sounds
like
we
should
probably
just
remove
completely
from
the
spec
any
talk
to
baggage,
but
I
do
want
to
make
sure
that
we
figure
this
out
and
then
it's
consistent.
I
think
the
configuration
for
what's
exported
in
traces
what's
exported
to
metrics
in
addition
to
how
to
pull
in
baggage,
needs
to
be
consistent
across
all
of
these
things.
F
B
So
would
it
be
fair,
like
there
is
already
well
there
sort
of
is
already
a
baggage
api
right,
and
would
it
be
fair
to
say
that
it
it's
not
necessarily
consistent
across
the
instrumentation
instrumentation
libraries,
so
the
the
ones
that
I
talk
about,
but
would
it
be
better
to
put
a
recommendation
for
instrumentation
libraries
on
this
is
how
you'd
handle
it,
because
that's
that's
where
I,
I
believe,
the
the
this
abstraction
needs
to
lie.
B
Like
that's
my
opinion,
at
least,
and
then
that's
kind
of
covering
our
basis
of
like
when
you
receive
a
request.
You
pull
out
this
baggage
and
you,
if
you
are
tracing
you,
attach
it
to
traces.
If
you
are
creating
metrics,
you
attach
it
to
your
metrics
and
that's
how
you
manipulate
that.
Assuming
that
you
have
synchronous,
metrics
right.
F
Yeah,
I
think
I
think
that
makes
sense
I
actually
kind
of
want
to
get
these
instrumentation
libraries
specified.
I
think
it'd
be
important
for
folks
doing
that
instrumentation
to
get
a
group
together,
because,
if
we're
pushing
these
details
in
higher
level
apis,
I
still
think
it
matters
like
again
consistency
for
users.
How
do
I
control
what
telemetry
is
ingested
consistently
across
everything
right
and
how
much
of
it
belongs
in
the
collector?
F
How
much
of
it
belongs
in
these
libraries
good
question
when
it
comes
to
attributes,
there's
significant
reasons
you
need
to
control
it
on
the
client
level
right.
We
have
some
cardinality
limits
in
java
that
we're
just
tweaking
around
with
to
to
make
sure
that
we
don't
explode.
Memory
usage
right,
it's
it's
it's!
These
are
deciding
to
choose
baggage
in
metrics
may
be
different
than
in
traces
and.
F
F
Well,
no,
I
think
that
was
the
consensus
before
was
to
mark
it
unstable.
What
I'm
proposing
is,
let's
just
remove
it
from
the
spec
instead
of
marking
it
unstable.
So
we
don't
have
this
weird
restriction.
Anyone
anyone
have
time
to
go,
make
that
pr
and
want
to
drive
that
through
aaron.
If
you
feel
strongly,
would
you
mind
doing
that.
B
I
can
I'm
still
trying
to
wrap
my
head
around
the
whole
of
this
because
there's
another
proposal.
I
also
want
to
get
out
on
the
table
before
we
try
and
solidify
this
around
views.
Specifically,
I
can
talk
with
you
offline
since
you've
been
driving
the
views.
It
looks
like.
F
F
There
there
may
be
a
way,
hopefully
yeah,
okay,
cool
last
thing
for
metrics,
then
is
that
was
remove
baggage
and
views
which
I
wanted
to
make
sure.
I
wanted
to
be
more
aggressive
on
that
one.
So
thank
you
for
having
that
chat
last
thing.
There's
a
proposal
to
mark
the
metrics
sdk
is
stable
instead
of
feature
freeze,
which
it
is
right
now.
If
you
look
at
every
single
pr
we've
discussed,
it
is
add,
clarity
or
remove
feature,
given
we're
still
removing
features
we
want
to.
F
We,
I
don't
think
we
want
to
mark
anything
stable
until
the
at
least
the
end
of
this
month
and
so
likely
in
january,
and
if
anybody
has
huge
reservations
about
that
or
whatever.
Let
me
know
what
I
want
to
avoid,
though,
is
there
are
folks
releasing
stable
apis
against
metrics
with
unstable
sdks.
F
If
we
are
running
into
issues
with
that,
because
our
api
is
marked
stable
by
the
way,
if
we're
running
into
issues
with
that
in
cigs
and
you're
unable
to
continue
to
make
progress
with
metrics,
we
should
have
some
discussions.
But
hopefully
this
doesn't
change
anything
around
the
metric
timeline
that
wasn't
already
there
and
we
are
still
not
trying
we're
not
allowing
features
to
be
added
to
the
sdk
in
the
spec,
which
does
mean
exponential
histograms
are
ground
to
a
halt
outside
of
prototypes
just
as
an
fyi.