►
From YouTube: 2022-04-26 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
A
C
B
Record
the
trace
flags
and
also
for
links.
We
have
the
trace
flags
from
the
propagation
context,
but
are
currently
not
written
into
the
otlp
portals,
there's
no
field
to
store
them,
and
I
want
to
suggest
adding
this
field.
I
know
that
it
can
be
very
useful
for
links
if
you
know
that
they
are
not
sampled,
then
you
can
save
some
query
to
the
database
to
look
for
them
when
they're
not
supposed
to
be
there.
C
B
If
we
just
add
them,
then
all
the
exporters
will
not
fill
this
value
and
it
will
look
like
a
zero,
which
means
they're,
not
sampled,
and
we
will
not
be
able
to
differentiate
between
and
not
sampled
and
the
value
is
just
stay
absent.
So
I
want
to
suggest
adding
it
as
an
optional
feel
to
the
bottom
off.
A
Yeah,
I
think
it
does
make
sense.
I
already
had
a
look
at
the
proposal.
I
think
yeah
that
it
makes
it
does
make
sense
to
have
this
information
in
the
protocol.
A
I
posted
some
comments
there
about
the
need
to
do
the
exercise
of
ensuring
that
whatever
is
introduced,
we
don't
break
the
interoperability
of
the
nodes,
receivers
and
exporters
so
yeah.
If
that
is
done,
then
I
think
I'm
personally
fine
with
the
addition.
Obviously
others
will
need
to
have
a
look
at
that
as
well.
I
don't
know.
E
This
also
makes
us
future
proof
to
additions
future
additions
to
the
trace
flags
that
the
w3c
may
add.
So
I
think,
that's
also
a
good
reason.
A
Yeah,
does
anyone
remember,
I
think
we
we
recently
added
another
field.
I
was.
It
was
somewhere
in
the
metric
stroke.
I'm
not
not.
I
don't
remember
what
exactly
it
was,
but
I
think
we
used
the
optional
the
ability
to
have
optional
fields
in
product
yeah.
F
F
Yeah
so
we
added
the
ability
to
have
optional
and
that
works
if
you're
able
to
use
a
recent
version
of
proto
everyone
using
gogo
proto
is
kind
of
screwed,
and
so
we
went
back
and
forth
on
a
bunch
of
different
ways
to
handle
the
gogo
proto
situation.
So
I
have
a
fork
of
gogo
proto
that
allows
optional
for
proto2.
F
I
don't
recommend
using
it
because
I
wrote
it,
but
I
I
think
the
way
that
bogdan
wanted
to
go
forward
was
we
write
a
custom
type
in
gogo
proto
that
allows
optional
and
that
we
take
the
crazy
collector
hackery
on
around
protos
anyway,
and
we
do
even
more
crazy
hackery
for
go.
Go
proto,
optional,.
A
F
Okay,
so
we
have
a
set
of
patches
for
for
pro.
So
here's
here's
a
question
the
set
of
patches,
though
last
time
I
tried,
I
couldn't
update
proto
to
add
optional
and
the
patch
at
the
same
time.
In
the
same
pr,
so
I
like
literally,
can't
submit
the
pr
to
add
optional.
A
A
G
A
A
As
for
the
specific
inclusion
of
the
flags,
I
mean
yeah.
That
requires
its
own
discussion.
The
issue
is
there:
if
you
guys
have
any
thoughts
about
it
now
we
can
discuss
it
now
as
well.
J
Making
the
field
optional
seems
like
a
burden
to
me.
We've
recently
had
a
discussion
about
versioning,
and
this
would
be
another
case
where
you
know,
there's
a
field
that
we've
been
fine
without
so
it's
backwards
compatible
in
some
definition.
We
don't
need
to
have
that
field.
Therefore,
you
should
go
to
add
it,
but
if
you
need
to
know
that
it's
there,
you
could
go
as
far
as
making
it
optional
or
you
could
declare
that
it's
never
like
it's
not
breaking.
So
it's
not.
A
So
the
problem
there
george,
is
that
the
zero
value
for
this
field
is
wrong.
Essentially
right.
So
if
you
have
an
old
exporter
which
doesn't
set
it
to
anything,
and
you
have
a
receiver
which
operates
with
a
new
version
of
the
protocol,
the
the
receiver
will
see
the
zero
value,
essentially,
which
is
wrong
because
there
is
zero
value
means
it's
not
sampled,
which
is
not
the
default
expectation
right.
A
J
It,
but
if
they
were
using
data,
that's
being
sent
today,
they
would
have
still
have
no
way
of
knowing
whether
that
data
was
out
of
compliance.
In
other
words,
so
they
still
have
to
accept
data.
That's
being
written
today,
so
they're
going
to
have
to
face
the
problem
of
not
knowing
unless
they
have
a
version,
but
but
having
optional
one
won't
help
them,
because
they're
going
to
have
to
accept
data,
that's
being
written
right
now.
A
J
A
Situations
there
is,
there
is
if
the
data
is
coming
from
new
versions
of
the
exporters.
You
expect
the
exporter
to
correctly
set
the
same
plug.
It's
either
sampled
or
not
sampled.
A
So
the
receiver
has
to
look
at
that
and
say
and
make
a
comparison
with
with
zero
value,
essentially
of
sample
slack
right
if
the
data
is
coming
from
the
old
ones.
That's
the
third
case
old
exporters.
Its
value
is
not
set
by
the
exporter,
because
exporter
has
no
idea
that
such
a
field
exists
at
all.
The
receiver
needs
to
know
about
this
third
case
because
to
the
receiver,
it
means
that
the
data
was
actually
sampled,
which
is
equivalent
to
having
a
value
of
non-zero
in
the
field,
but
the
receiver
will
see
a
zero
value.
K
A
To
having
the
optional
field
you're
saying,
let's
see
sure,
but
but
we
know
the
proto
level,
we
can
do
it
at
the
data
level,
yeah
yeah
exactly
and
that
has
been
discussed.
We
discussed
it
with
the
with
the
was
that
with
the
histograms
as
well.
There
was
precisely
what
we
discussed
and
then
settled
on
the
optional.
This
is
exactly
what
what
we
went
through
already.
F
A
F
A
Like
so
imagine
a
case,
you
have
a
source
which
emits
traces
and
logs
and
the
independent
decision
is
made
to
drop
the
particular
trace.
So
the
trace
is
dropped
right,
but
the
logs
are
not
dropped.
You
receive
a
log
which
references,
a
trace
which
is
not
going
to
to
ever
exist
right.
You
you're
not
going
to
see
it.
A
You
want
to
know
it
so
that
let's
say
you
have
a
feature
in
your
ui
where
you,
you
see
a
log
record
and
it
links
you
to
that
to
the
corresponding
trace,
so
that
you
can
disable
that
feature,
because
it's
not
going
to
go
anywhere.
It's
not
going
to
find
that
trace.
The
trace
id
is
present
in
the
log
record,
but
that
trace
id
is
not
valid
from
the
perspective
of
the
back
end,
because
the
back
end
is
never
going
to
see
that
trace
at
all.
F
A
Precisely
you're
going
to
see
that
the
date
that
plug
is
zero,
it
means
that
the
trace
does
not
exist
so
that
the
the
hyperlink
is
impossible.
So
you
show
it,
but
the
trace
doesn't
exist
that
you
just
don't
show
hyperlink
whatever
you
want
to
do
in
your
back
end
right.
It's
it's
a
hint
to
the
back
end
that
this
trace
id
it.
Doesn't
you
you're
not
going
to
find
it?
Don't
try.
F
J
Related
point
from
last
week's
sampling
sig,
so
the
logs
group
would
like
to
be
able
to
sample
logs
and
they
came
to
that
meeting
yesterday
last
week,
saying
so:
there's
no
trace
state
in
the
log
record,
which
means
that
we
can't
take
the
probability
sampling
information
that
we
designed
for
for
spans
and
apply
them
to
any
logs.
J
So
that
there's
a
request
to
add
the
one
missing
field
which
is
trace
state
to
the
logs,
but
the
logs
have
trace
flags
for
some
reason,
whereas
we're
looking
at
right
now,
the
issue
is
spans,
don't
have
trace
flags,
but
they
do
have
trace
state.
I
I
think
we
do
need
all
four
fields
which
is
trace
id
span,
id
trace,
state
and
trace
flags
everywhere,
and
I
kind
of
wish
we
hadn't
broken
them
apart
into
four
separate
fields,
because
it
seems
like
we're
having
a
debate
over
adding
four
separate
fields
to
every
every
signal.
J
So
we
need
the
flags
and
the
trace
state
and
the
trace
id
and
the
spin
id.
I
think
everyone
agrees
to
that,
but
I
don't
think
we
need
to
make
them
optional.
A
Okay,
baldwin
you're,
saying
something.
L
Yeah
I
was
running,
I
joined
the
discussion
late,
but
I
heard
the
problem
with
the
trace
flags
of
needed
to
be
optional.
Was
that
one
of
the
topic
correct?
Yes,
so
on
the
trace
flags,
my
argument
against
having
it
optional
is
by
default.
If
it.
If
it
comes
from
an
old
exporter
which
doesn't
know
about
this,
it
comes
as
zero,
which
means
not
sampled.
So
you
you
come
with
a
safe
decision.
L
A
L
From
things
like
you,
you,
you
don't
show
the
link
that
you
mentioned,
for
example,.
L
And
then
I
mean
I
mean
missing.
That
field
will
do
the
same
thing.
If
somebody,
if
somebody
uses
a
new
protocol,
but
it
literally
doesn't
set
that
field,
it
misses
the
same
functionality
correct.
So
how
do
what?
What
is
your
argument
against
somebody
not
setting
that
field
versus
somebody
intentionally
versus
somebody,
not
upgrading
intentionally.
A
So,
if
you,
if
you
so
after
this
field,
is
added
any
exporter
which
upgrades
its
protocol
version
should,
at
the
same
time
begin
populating
the
field
to
a
non-zero
value
right.
That
is
the
expectation.
Otherwise
it's
just
emitting.
L
A
A
L
Whenever
you
do
the
the
the
the
way,
how
I
would
do
it
if
I
were
the
product
owner
of
that,
I
would
just
simply
say:
okay,
I'm
I'm
treating
missing
as
zero,
which
means
I'm
not
putting
link
because
I'm
not
sure
if
the
thing
is,
if
it
is
sample
or
not,
and
if
it's
one
I
may
consider
to
add
the
link-
and
I
will
add
a
link
and
that's
it
and
I'll
explain
to
the
customer,
because
there
is
no
way
you
go
retractive
to
fix
all
the
history
there.
L
A
So
let's
say
you
had
this
feature
to
link
from
a
spam
to
to
a
linked
spam
right.
I
guess
this
is
where,
where
it
matters-
and
previously
you
would
always
just
show
the
link,
because
you
had
no
idea
whether
the
linkedin
file
is
sampled
or
not.
Sampled,
now.
C
A
F
C
F
Suppress
optimistically
after
the
fact,
it's
like
it's
a
fine
decision.
I'm
I'm
suggesting
like
the
notion
that
you
should
be
writing
whether
or
not
a
trace
was
sampled
in
a
log
is
interesting
to
me
in
that
it
it
completely
negates
a
tail
sampling
use
case
and
that's
okay,
which
I
think
means
it
either
needs
another
use
case
where
it's
required
right,
or
this
is
just
like
an
optional
thing.
F
That
is
like
somewhat
useful
for
some
people
where
you're
only
doing
head
sampling,
but
I
don't
think
it's
a
generally
useful
thing
and-
and
I
have
bug
reports
from
users
to
to
tell
you
how
I
think
it's
not
a
generally
useful
thing
if
you
want
so
that
said,
is
it
already
marked
as
required
in
the
protocol,
because
if
it
is
and
that
protocol
is
released,
the
decisions
done,
we
should
never
make
something
that
was
required
optional.
F
L
And
also
josh,
there
is
no
such
thing
as
required
in
proto2.
L
F
L
F
Yeah
so
you'll
get
zero
and
zero
means
this
wasn't
sampled,
which
actually
has
an
action,
whereas
one
means
this
may
have
been
sampled,
and
you
know
that.
That's
like
it's
weird,
because
in
this
case
I
kind
of
wish
the
flag
was
inverted
personally,
because
that
would
be
more
sense.
The
default
value
being
may
have
been
sampled,
and
you
have
to
actually
say
this
absolutely
was
not
sampled.
L
Okay,
the
value
cannot
be
changed
right
now.
So
what?
What
are
we
doing
in
terms
of
your
optional
different
one?
Last
idea
about
that
is,
if
you
do
the
switch
that
you
propose,
so
you
show
the
links
right
now
and
then
suddenly
we
have
this
flag
and
you
implement
this
new
switch
new
new
thing
that
allow
allow
the
backend
to
show
the
links
only
for
the
ones
that
have
a
one
for
that
flag.
A
You
will
have
the
link,
because
all
data
will
not
have
this
field
as
being
present
and
when
the
field
is
not
present,
you
do
want
to
enable
the
link,
because
that's
the
safe
path
right
I
mean
it
depends
if
it's
safe
or
not,
because
if,
if
it's
by
saying
it's
more
safe
right,
you
you
still,
I
guess,
allow
the
present
data
to
be
found
and
for
for
the.
D
A
L
Yeah,
so
my
two
cents
here,
I
don't
think
it.
It's
worth
spending
the
the
this
time.
Arguing
about
that.
I
think
it's
a
minor
thing.
It
may
be
good,
but
I
think
the
the
counter-argument
of
having
to
deal
with
this
special
being
optional
versus
all
the
others
not
being
optional.
I
think
it
complicates
the
logic
and
things
and
brings
frustration
to
to
some
of
the
developers,
so
I
would
prefer
to
keep
it
consistent.
A
L
In
the
back
end,
in
the
back
end,
no,
I
don't
think
you
can
retracting
my.
A
C
Yeah
thanks:
this
is
something
that
I
brought
up
in
the
log
sig
last
week
and
before
talking
about
it,
and
it
was
recommended
that
I
bring
it
up
here
too,
so
just
running
it
past
the
broader
audience.
The
basic
idea
is
that
the
background,
currently
the
log
data
model
says
that
company
specific
attributes
should
have
sort
of
a
fully
qualified,
like
java
style
prefix
to
them.
C
So,
and
there
are
some
examples
of
this,
the
one
that
came
up
that
we
noticed
was
the
google
cloud
ones
would
be
like
com.google.log
name
and
we're
wondering
if
it
would
be
reasonable
or
anyone
to
object
to
carving
out
or
sort
of
just
clarifying
an
exception
for
cloud
providers
to
use
like
an
abbreviated
prefix.
So
instead
of
com.google
use
like
gcp
or
aws,
so
it
would
bring
a
little
bit
more
consistency
with
other
places.
In
the
specification
where
there's,
I
think,
trace
uses
that
kind
of
approach.
C
We
found
a
couple
examples
of
like
aws
dot.
You
know
this
or
gcp
dot
this
other
areas.
So
I
link
to
the
issue
in
the
agenda
here
and
that
has
a
couple
links
to
other
areas
that
we've
seen
it
so
just
wondering
if
there's
any
objections
to
it
or
anything
that
I
should
pay
attention
to
and
if
not,
I'm
gonna
raise
pr
trying
to
make
the
change
and
just
clarifying
this
a
little
bit.
C
Yeah
yeah:
well,
the
idea
is
like
to
map
it.
Would
it
would
map?
Basically,
so
I
don't
think
that
we
would
be
expanding
them
from
a
technical
sense,
but
it
would
be
like
the
translated
equivalent.
K
C
I
I
I
found
using
the
company
name
as
a
prefix
cause
trouble
if
the
company
lives
for
more
than
10
years,
because
there's
like
a
question
their
organizational
change.
So
I
I
probably
would
suggest
that
we,
we
don't
follow
the
company
name.
We
use
some
a
common
name
that
makes
sense
and
not
heavily
affected
by
by
companies
like
thinking
like
like
merged
or
something
I've
seen
a
problem
in
java,
a
lot
of
historical
names
and
for
the
new
generation
of
developers.
They
have
no
idea
what
those
names
are
unless
they
dig
into
the
history.
K
K
The
important
thing
is
is
that
it
uses
dns
as
a
name
spacing
mechanism
to
avoid
conflicts.
So
if
you
own
a
domain,
it
doesn't
matter
what
your
company
name.
Is
you
own
that
and
you
can
use
that
as
a
namespace
and
have
confidence
that
you
will
not
conflict
with
other
people's
non-specified
attributes.
A
Do
you
think
that
that
was?
That
was
the
logic,
but
I
guess
in
this
particular
case
we're
actually
saying
that
we
shouldn't
be
doing
that.
So
it's
not
the
argument
in
favor
of
using
the
company
name,
it's
argument
in
favor
of
not
doing
that
for
a
very
common
case,
where
you're
actually
using
the
cloud
provider
right,
you're
referencing
to
something
that
is
specific
to
a
cloud
provider.
A
So
I
guess
the
question
here
is:
are
we
allow
it
to
deviate
from
the
specification
as
it
is
written
right
now
where
it
says
you
have
to
use
the
company
name
and
instead
of
doing
that,
use
the
the
abbreviated
cloud
provider
name
like
gcpd
or
aws,
and
we
already
do
that
in
some
other
semantic
conventions.
So
it's
not
something
completely
new,
but
the
spec.
The
specification
doesn't
really
explicitly
allow
that.
So
this
is
the
question
of
doing
that,
like
maybe
we
just
just
make
an
exception
to
that.
A
Maybe
we
delete
that
completely
the
company
name
riley.
If
we
want
to
do
that,
but
I
would
suggest
that
we
discuss
that
separately
in
this
particular
case,
it's
easier
to
make
the
case
for
the
particular
exception
for
cloud
providers.
I
guess
the
question
here
is
that
we
said
that
open
climatry
is
vendor
neutral.
A
In
a
sense,
we're
saying
you
know
what
the
the
cloud
providers
are
important
in
this
case.
It's
very
often
that
you
want
to
reference
to
some
attribute
that
is
provider
specific,
so
it
does
make
sense
to
use
shorter,
attribute
names
in
this
case,
as
evidenced
by
already
existing
semantic
conventions.
So
do
we
accept
that
it's
okay
to
deviate
from
this
neutrality,
slightly
in
favor
of
having
more
usable
easier
to
read,
attribute
names
for
a
very
common
use
cases
for
cloud
provider,
immediate
attributes?
This
is
the
question
we.
M
C
The
last
section
in
there-
so
I
guess
maybe
the
idea
for
this
is
just
to
kind
of
clear
up.
You
know
like
the
conflict
between
you
know
this
section
exists,
or
is
this
just
expected
to
override
you
know
where
the
current
examples
are
already
listed?
We
can
just
update
those
and
point
to
this
as
the
justification.
I
I
Just
like
we
like.
We
explain
the
the
idea
behind
that
like
why
you
want
namespace,
because
you
want
to
avoid
conflict.
If
you
just
pick
a
common
name,
it's
very
easy
for
you
to
have
those
conflict
with
other
vendors,
so
you
should
name
space
stuff,
but
how,
with
namespace
that
I
I
think
we
have
to
determine
the
strategy
based
on
the
scenario.
For
example,
if
I
have
android
specific
thing,
do
I
name
that
as
com.google
android,
because
google
is
literally
driving
android,
but
maybe
no,
because
android
is
open
source,
it's
driven
by
the
android
community.
I
K
I
Maybe
that
that's
what
I
learned
by
comparing
java
and
dotnet,
so
in
java,
the
the
class
are
namespaced
after
the
company
hierarchy
like
the
the
package
name,
but
in
downlight
the
package
name
are
kind
of
like
freestyle.
Sometimes
you
see
system
does
something.
Sometimes
you
see
like
microsoft
or
something-
and
I
haven't
seen
big
problem
in
donetsk
donations
seems
like
it's
as
successful
as
java.
M
Yeah,
I
agree
with
riley
on
this.
I
think
that,
eventually
anyone
can
put
anything
as
the
attribute
and
it's
like
a
common
sense-
how
to
provide
the
namespace
that
is
unique
enough
for
a
given
area
for
for
attributes
and
and
this
calm,
that
something
requirement
is
a
little
odd
for,
for
many
cases,.
C
A
I
think
it's
fine
to
rename
the
specific
ones
that
we
have,
which
use
com.google
to
start
using
gcp
dot.
Whatever
I
don't
see
any
objections
at
the
moment
anyway,
you
can
open
the
pr
if
anybody
objects,
they
can
do
that
on
the
pr.
As
for
the
generic
suggestion
that
riley
has
to
get
rid
of
the
company
name
completely,
that
can
be
another
separate
pr.
We
can
discuss
that
there
behind
that.
I
Yeah
and
I'm
gonna
do
a
concrete
example
like
for
microsoft:
it's
not
just
either.
So
if
we
put
everything
com.microsoft
as
error,
this
is
essentially
wrong
because
there
are
windows
and
all
this
other
stuff,
but
I
do
think
like
putting
either
as
a
prefix
for
other
stuff
makes
more
sense
than
com.microsoft,
either
or
even
com.edu.
I
K
I
I
think
the
the
thing
is
semantic
convention
will
eventually
evolve
just
like
natural
language
if
they
expect
something
like
fixed
and
everyone.
Following
a
strict
rule,
I
think
eventually
it
will
be
very
hard
to
use,
and
if
we
don't
look
for
a
change,
then
people
will
go
and
implement
the
next
version,
which
is
simpler.
A
This
is
also
about
the
case
centering
when,
when
you,
when
there
is
no
semantic
convention
at
auto
telemetry
for
the
thing
that
you
want
to
record,
but
you
still
want
to
be
careful
to
avoid
the
conflicts
right,
so
this
is
an
easy
way
to
achieve
that-
maybe
not
the
best
way,
but
this
was
why
it
was
written.
This
way
you
don't
have
a
good
way
to
maybe
proposing
this
to
open
telemetry.
It's
too
specific.
A
C
M
And
now
this
question
comes
from
the
point
of
open,
telemetry
collector
reviewer.
M
So,
for
example,
we
have
metrics
such
as
I
don't
know,
mysql.bufferpool.pages,
which
is
namespaced,
but
then
it
has
attributes
like
buffer
pull
page
pages
or
comment
or
handler
and
those
are
not
namespaced
and
I'm
wondering
if
that's,
okay
or
not
and
and
depending
on
the
answer
we
either
maybe
need
to
update
the
specification
and
say-
and
I'm
just
hypothetically
saying,
I'm
not
saying
that
this
is
good
or
bad,
that
if
metric
name
is
namespace,
then
record
level
attributes
maybe
don't
need
to
be
namespace,
because
this
is
already
not
needed,
since
the
metric
name
is
namespace
or
the
other
way.
M
A
Historically,
this
comes
from
the
fact
that
the
metrics
initially
had
labels
of
attributes
and
that
this
definition
didn't
apply
to
metrics
at
all.
Then
we
said
the
metrics
labels
are
actually
attributes
and
suddenly
the
restrictions
we
have
on
the
attributes
now
apply
to
the
metrics
as
well.
So
this
is
the
I
guess,
historical
context
and
you're
absolutely
right
for
things
like
like
cpu
system,
cpu
or
process
cpu
metrics.
A
We
we
don't
have
any
prefixes
for
the
namespaces
for
the
attribute
names
like
we
call
it
state.
It
can
be
idle
system
stuff
like
that,
so
there's
no
prefix
at
all.
I
don't
know
what's
the
answer.
I
just
wanted
to
give
some
historical
context
on
this.
F
I
want
to
add
one
more
piece
of
context
too.
When
we
talk
about
instrumentation
and
we
talk
about
attributes,
we
also
a
lot
of
the
instrumentation
pulls
attributes
from
traces,
so
like
the
latency
metric,
for
example,
is
going
to
use
the
same
set
of
attributes
as
the
trace,
and
so,
if
you
have
a
namespace
decision
on
attributes
around
metrics,
I
don't
think
we
should
make
it
independently
of
attribute
decisions
for
other
signals,
because
I
think
it's
correlated
that
said,
does
any.
K
M
Yeah,
I
think
so.
I
think
we
can
continue
the
discussion
there
and
yeah.
I'm
curious
like
well
with
the
outcome
because
well
either
we
need
to
follow
the
the
requirements
we
put
in
the
specification
in
the
receivers
or
we
need
to
update
the
specification
so.
N
Sorry
before
we
move
on,
I
have
a
small
question
for
your
survey.
Just
from
just
to
get
the
wall
rolling.
Would
it
be
bad
to
support
both
cases
like
both
namespace
attributes,
for
some
cases
and
simple
names
for
others,
or
is
that
just
recipe
for
chaos.
F
I,
as
long
as
you
don't
get
it
as
long
as
it's
a
dead,
simple
rule
and
it
doesn't
confuse
anyone.
I
just
feel
like
that
would
be
confusing
like
as
a
user
right.
When
do
I
expect
one
versus
the
other
as
an
instrumentation
author,
when
do
I
use
one
versus
the
other?
When
do
I
simplify?
I
think
the
proposal
here
is
to
use
the
simple
attributes.
Is
that
right
is
that
our
preference,
when
the
metric
is
namespaced.
M
So
I
opened
the
issue,
but
I
my
preference
will
be
to
be
consistent
and
I
would
prefer
to
have
this
long
names
with
namespace
for
all
signals,
because
it's
it's
a
harder
problem
for
locks
and
tracing
and
but
well.
I
think
that
eventually
it's
all
about
making
a
decision.
A
M
A
N
Look
fine,
I
don't
know,
but
that's
correct,
that's
exactly
what
I
was
thinking
that
some
of
them
is
like.
You
know.
What
do
you
use
them
like,
for
example,
in
the
java,
some
of
the
java
ones,
you
have
an
attribute
called
put
name.
So
what
did
you
use
before
just
extra
extra
characters
for
for
free,
let's
say.
F
Yeah,
so
if
we
have
a
rule
around
shrinking,
though
it
should
be
obvious
like
how
you
would
shrink
between
a
span
and
a
metric
if
the
metric
name
is
attributed
or
or
namespaced,
maybe
we
have
the
same
thing
with
span
names
having
a
namespace
to
them
and
shrinking
like
like
again
this.
This
probably
all
deserves
some
discussion
in
the
bug,
with
maybe
a
few
proposals.
F
I
just
want
to
call
out
that
at
a
minimum,
given
there
are
limitations
to
attribute
length
in
various
systems,
we
should
probably
also
have
those
documented
somewhere
for
our
own
understanding
in
the
spec
and
maybe
not
let
the
attribute
name
go
beyond
that
length
as
a
thing
that
we
call
out.
That
would
be
my
only
concern
with
adding
name
spacing
would
be
systems
breaking,
but
yeah.
A
A
It
yeah,
but
when
I
look
at
the
metrics
that
we
have
now
like
system
cpu
time,
which
has
the
cpu
number
as
a
as
a
notch,
what
do
you
rename
it
to
what
cpu
number?
What
does
it
become?
I
don't
I
don't
see
any
good
name
for
that
other
than
like.
What's
the
prefix,
for
that,
do
you
use
system.cpu.number,
as
the
attribute
name
looks
very
superfluous
to
me
I
don't
know,
but
again,
I
think
we
need
a
proposal
which
which
says
these
are
the
changes.
A
A
A
There
was
a
pr
which
earlier
proposed
to
add
this
as
one
of
the
I
guess,
built-in
fields
of
the
scope,
and
instead
of
that,
we
will
just
record
this
as
one
of
the
possible
attributes
of
the
scope,
and
another
use
case
is
where,
where
you
can
record
some
data
in
the
form
of
typically
it's
log
records,
but
the
the
data
belongs
to
different
different
verticals
different
business
domains.
Probably
so
things
like
profiling.
A
Information
belongs
to
two
different
place,
then
than
the
let's
say,
application
logs
right,
or
maybe
it's
client-side
events
that
you
want
that
they
have
their
own
business
domain.
So
different
sigs
want
to
use
log
records
for
this
purpose
to
record
the
information
that
they
have
in
there
in
their
area.
A
The
optional
version
today,
in
addition
to
that,
will
allow
specifying
any
number
of
optional
number
of
any
number
of
attributes
right,
maybe
zero,
and
then
those
attributes
will
be
recorded
with
all
the
immediate
telemetry
that
goes
through
that
tracer
meter
or
or
the
log
meter.
This
is
the
proposal
I
linked
to
the
old
tab.
There
please
have
a
look.
I
tried
to
show
some
examples
use
cases
as
well.
H
I'm
glad
to
see
this
getting
added,
I
I
did
make
a
request
for
prototypes,
I'm
not
sure
if
there
are
any
prototypes
available,
but
I
suggestions
in
the.
H
You
mean
yeah,
I
think
we,
I
don't
think
it's
an
official
rule
yet
something
that
for
the
tc
to
consider,
but
I
think
we're
trying
to
move
to
a
pattern
of
like
having
at
least
one
or
two
prototypes
available.
H
A
Yeah
at
the
minimum,
I
would
say,
even
if
it's
not
prototypes,
then
at
least
there
is
a
clear
confirmation
from
the
language
maintainers
that
this
is
doable
right
right.
That
is
would
be,
I
guess,
that's
the
minimum.
You
would
expect
to
happen
here
because
it's
it's
a
change
in
the
api
yeah
exactly.
D
F
One
one
thought
here:
tigran
like
a
good
way
to
test
this
out,
would
be
a
collector
processor
that
filters
for
instrumentation
library
and
just
appends
attributes,
because
one
thing
I'm
thinking
about
is:
should
you
be
able
to
do
this
both
at
instrumentation
time,
which
is
when
you
get
a
meter?
Should
you
also
be
able
to
do
it
at
runtime
or
operation?
You
know
deployment
time
yeah,
which
would
be
like
in
the
collector
yeah
yeah.
It's
it's
trivially.
A
Doable
in
the
collector,
I
don't
see
any
problem
there
like.
If
it's
a
fielding
or
tlp,
you
can
have
a
processor
which
filters
based
on
the
value
does
all
sorts
of
routing
loading
based
on
it.
It's
it's
doable.
I
mean
we
can
check
with
the
other
maintainers,
but
I
think
yeah.
I
can
vouch
that
it's
doable.
H
A
H
Change
to
the
our
produce
as
well.
Yes,.
A
A
Okay,
maybe
let's
move
to
the
next
one,
because
we
don't
have
a
lot
of
time
remaining
client
sessions,
resources,
martin.
O
Yes,
hello
so
in
in
the
client,
instrumentation
sake,
we're
discussing
the
concept
of
sessions
and
we're
trying
to
figure
out
where
exactly
to
put
the
session
data,
and
we
believe
that
it
belongs
on
the
resource,
because
it's
it's
data,
that's
shared
across
all
all
telemetry
emitted
from
from
the
instrumentation
traces
logs
and
metrics,
and
the
the
the
challenge
with
with
sessions,
though,
is
that
they
can
change
during
the
during
the
lifetime
of
the
application.
O
So
we're
you
know
we.
We
are
aware
that
there
is
a
currently
restriction
on
resources
being
immutable.
O
We
created
an
issue
to
this
to
to
to
discuss
this
topic
and
the
proposal
we're
thinking
of
right
now
is
adding
a
concept
of
a
resource
provider
which
would
be
all
the
different
places
that
generate
you
know,
signals
or
telemetry
would
get
the
resources
from
this
provider
instead
of
having
you
know
a
reference
to
the
actual
instance
of
the
resource,
and
that
way
that
would
allow
for
something
like
a
like
a
session
session
manager,
a
concept
to
to
update
or
add
additional
information
to
the
resources.
O
And
then,
when
new
signals
are
created,
they
could
get
it
from
this
provider,
so
I
we,
the
reason
I'm
bringing
it
up
is.
Is
I
know
that
this
is
a
topic
potentially
that
has
implications,
and
we
would
like
to
get
feedback
on
what
those,
what
what
the
side
effects
would
be.
A
O
K
O
O
It
would
ask
the
resource
provider
to
to
get
the
resources
that
are
up
to
date
at
that
point
in
time
and
then
associate
those
resources
with
the
new
span.
L
So
so,
and
they
are
resolved
at
the
beginning,
slash
in
in
the
initial
in
the
initial
stages
of
the
applications,
and
then
they
are
considered,
and
there
are
backgrounds
that
make
some
some
planning
on
on
the
fact
that
restores
are
kind
of
immutable.
K
L
K
H
If
you
anthony,
if
you
look
at
most
implementations
it,
it
is
the
case
usually
that
when
you're
creating
starting
a
span,
the
tracer
either
has
you
know
a
set
of
resources
appended
to
it,
or
it
has
access
to
a
tracer
provider
that
has
like
a
set
of
resources
appended
to
it
in
most
implementations,
this
is
like
a
simple
change
that
tracer
provider
now
has
a
resource
provider,
and
rather
than
so,
rather
than
just
like
a
a
static
link
to
an
immutable
set
of
resources,
it's
asking
the
provider
to
give
it
a
pointer
to
an
immutable
set
of
resources.
H
Been
looking
at
building
some
prototypes
for
it
and
it
does
look
from
an
implementation
standpoint,
pretty
simple
in
most
languages.
H
I
do
think
that
what
bogdan's
bringing
up
is,
I
think,
like
you
know,
if,
over
time,
the
resources
might
be
changing
in
some
way,
that's
valid,
but
nevertheless,
what
kind
of
dependencies
have
back
ends
put
on
put
on
resources
as
a
group
not
changing
in
order
to
identify
an
instance
and
do
we
need
to
actually
clarify
a
better
way
more
reliable
way
for
people
to
to
identify
like
a
service
instance.
L
True,
I
mean
we
can.
We
can
do
that,
but
the
problem
that
I
feel
we
we
started
from
resources
as
being
the
identification
of
the
source
of
telemetry
and
I
don't
think
a
session
is
a
source
of
telemetry.
I
think
I
think
a
session
is
a
logical
umbrella
on
top
of
some
over
a
period
of
time,
essentially.
L
A
A
H
Yeah
part
part
of
the
reason
why
well
one
thing
we're
trying
to
avoid
is
just
stapling
this
thing
as
attributes
onto
everything,
because
that
that
that
is
doable,
but
it's
very
inefficient
and
just
doesn't
doesn't
seem
like
a
good
model
from
the
perspective
of
of
clients.
One
thing
to
remember
is
we're
looking
at
at
clients,
in
particular
when
we're
developing
these,
and
so
that
overhead
is
actually
significant
when
you're
talking
about
about
clients.
So.
L
That's
I
doubt
that
ted
I
mean,
I
doubt
the
reason
why
I
doubt
this
is
because,
first
of
all,
I
think
we
can
extend
the
current
apis
to
accept
a
set
of
attributes,
and
you
do
this
in
one
call
if
you
want.
If
that's
your
overhead,
if
the
overhead
is
on
the
wire,
that's
not
true,
because
if
you
are
using
any
any
minimal
encoding
like
gzip
or
anything,
then
then
the
overhead
is
out.
So
so
I'm
a
bit
struggling
here
determining
where
the
problem
is,
but.
H
I
mean
I
would,
I
would
defer
it
back
to
the
the
the
rum
experts,
the
client
experts
who've,
been
part
of
the
sig
they're
they're
concerned
about
it,
but
I
also
think
from
a
modeling
standpoint.
J
There's
a
question
about
whether
this
data
belongs
to
a
scope
or
whether
it
belongs
to
the
whole
process
right-
and
I
think
the
intuition
people
came
in
here-
is
that
this
data,
the
session
and
data,
belongs
to
the
whole
process.
So
if
we
put
session
data
on
the
resource,
it
makes
it
all
of
a
sudden
look
like
these
sessions
are
independent
processes.
J
I
don't
have
a
conceptual
problem
with
calling
a
session
a
process,
but
perhaps
we're
losing
the
information
that
would
allow
you
to
say
that
these
sessions
all
happened
on
the
same
thing,
which
we
want
to
call
a
process
right.
There
have
been
issues
filed
over
time
in
open
temperature.
You
can
go
look
them
up.
J
We
can
find
them
saying
we'd
like
to
see
the
difference
between
a
descriptive
attribute
in
the
resource
versus
an
identifying
attribute
in
the
resource,
and
I
would
like
to
hold
out
that
potential
solution
here,
because
when
you
look
at
the
way
a
prometheus
system
works,
half
of
your
resources
are
not
known
inside
the
process.
You
publish
your
identifying
attributes
and
then
they
get
joined
together
with
the
other,
descriptive
properties
outside
of
the
process.
And
if
we
had
a
descriptive
versus
identifying
attribute
distinction
here,
then
I
think
we
need
to
solve
this
problem.
J
L
I
have
a
question,
even
if
we
have
this,
do
you
think
these
sessions
should
be
represented
as
resource
that,
like
independent
of
the
fact
that
you
we
we
have
because
I
feel
like
I
feel
like
it's
not.
We
started
with
the
resources
as
identifying
the
source
of
telemetry
and,
and
we
have
the
new
notion
of
scope
which
identifies
a
logical
scope
into
the
into
the
the
program
which
may
be
much
better
fit.
In
my
opinion,.
H
Scopes
might
be
better
in
this
this
particular
case.
I
I
agree
with
that.
We
we
haven't
had
scope,
so
when
we
were
looking
at
this
resources
did
fit
just
fine
for
our
use
case,
I
I
will
mention
that
there
is
when
we
designed
immutable
resources.
H
We
were
thinking
about
servers
and
one
thing
that
has
come
up
we're
just
talking
about
sessions
right
now,
but
in
clients.
It
is
the
case
that
I
think
clients
may
end
up
with
things
that
are
valuable
resources.
H
Things
like
time,
zone
and
stuff
like
that
and
clients
have
this
habit
of
especially
mobile
clients
and
desktop
clients
of
being
not
refreshed,
all
the
time
like
a
web
browser,
but
actually
being
put
to
sleep
and
then
reawakening
at
some
point
in
time
later,
where
some
of
the
resources
they
may
want
to
admit,
may
actually
have
have
changed
because,
for
example,
the
clients
in
a
new
place
now
and
we
we
haven't
fully
developed
any
of
those
resources
yet
because
we
haven't
really
dug
into
mobile
clients
in
great
detail.
H
But
but
that
is
a
thing
this
group
has
pointed
out
that
regardless
of
of
sessions,
this
might
be.
This
might
be
an
issue
for
clients
awakening
at
a
later
point
in
time
and
having
some
of
their
resources
needing
to
change
at
that
point,
without
restarting
the
entire
process.
H
So
that's
I
hope
that
makes
sense,
but
that's
that's
just
something
we're
we're
seeing.
So
it
might
be
the
case
that
we
still
want
to
do
something
like
this
resource
provider
thing,
but
also,
maybe
do
it
in
the
future
and
for
now
just
move
sessions
onto
scopes
because
it's
like
the
better,
more
correct
place
for
them
to
go.
But
I
did
want
to
point
out
that
it's
like
a
broader
issue
that
the
the
client
working
groups
are
identifying.
H
And
it's
one,
you
know
we
haven't
addressed
because
servers
don't
do
this
right.
Servers
just
exist
as
an
instance
and
stay
in
one
spot
until
you
know
they're
obliterated
and
a
new
instance
starts
somewhere
else.
Clients
go
to
sleep
and
reawaken
and
have
a
long
lifespan
where
they
may
be
moving
all
over
the
place,
and
that
may
just
end
up
affecting
something
about
how
they
emit
resources
or
how
you
may
want
to
identify
it
as
like
one
process
versus
another
process,
potentially.
A
L
Bye,
thank
you,
but
this
is
by
the
way.
This
is
a
plus
one
for
degrasso
for
sure.