►
From YouTube: 2022-11-08 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
C
E
D
B
D
F
Okay,
hello,
sorry
for
being
late.
We
are
two
minutes
past
starting
time.
I
suggest
we
wait
one
more
minute
in
case
more
people
to
show
up
it's
12th
of
us
so
yeah.
Hopefully
we
get
more
people
and
just
one
for
your
information
yeah
we're
trying
to
do
the
release
for
November
the
monthly
release
and
we
need
actual
approvals
and
previews.
So
just
take
a
look
at
that
one:
okay
and
yeah.
Let's
start
in
half
minute,
we
have
a
few
items.
There
yeah
feel
free
to
have
more
important
items.
F
G
So
should
I
just
go
with
with
this
topic:
yeah,
please
yeah
sure,
so,
just
a
little
bit
context
about
myself.
So
I
am
in
Cisco
in
in
epsegon,
which
is
a
startup
that
bought
about
a
year
ago,
so
I'm,
the
architect
of
our
group,
and
we
we
also
have
Usher
here,
which
is
the
team
leader
working
on
open,
Telemetry
yeah
and
a
few
months
ago,
I
added
this
old
tab
for
collecting
payloads
in
traces.
G
This
topic
is
something
that
you
think
that
should
be
included
in
in
open,
Telemetry
and,
of
course,
there's
a
lot
of
of
technical
issues
that
are
related
to
that,
and
there
is
a
proposal
in
this
Otep
about
it.
It's
it's,
it's
not
complete,
but
how
and
an
API
could
look
like
and
how
and
and
how
this
kind
of
data
should
be
integrated
inside
in
inside
spans.
F
B
I
I
think
my
main
question.
Ron
is
so
we
don't,
since
we
have
made
attributes
on
traces,
we've
extended,
otlp
to
support
maps
and
other
kinds
of
like
nested
values,
maps
and
arrays.
Things
like
that
and
we're
actively
discussing
backwards,
compatible
way
of
exposing
that
for
span
attributes
they're
already
available
for
for
logs,
for
example,
and
so
I
think.
My
main
question
is
like
assuming
we
get
those
kinds
of
nested
attributes
exposed.
G
G
I
could
say
that
adding
different
attributes
will
help
us
to
to
do
more
sophisticated
processing
to
this
to
this
data
and
also
to
support
even
different
kind
of
attributes
in
the
future
that
will
meet
different
types
of
payloads
and-
and
this
could
be
like
another
reason
for
why
it
could
have
separating
that,
but
definitely
it
it
is.
It
is
an
option
that
that
I
think
could
work
as
well,
but
even
even
if,
if
we
will
support
this,
this
kind
of
mapping
attributes
I
think
we
still
figure
out.
G
B
Yeah
I
mean
I.
Think
you,
unless
there's
like
a
strong
reason,
I
can
tell
you
you're
going
to
get
a
lot
of
pushback
for
further
defining
Fields
like
an
email
field,
and
things
like
that
that
I
see
in
here
you're
going
to
get
a
lot
of
pushback
to
say
these
should
just
be
semantic
conventions
that
that
work
with
attributes,
and
we
try
to
extend
the
kind
of
attribute
values
that
we
can.
B
For
each
library
to
to
record
things
like
HTTP
requests
and
stuff
like
that,
so
rather
than
the
end
user
having
to
like
map
you're
good,
whatever
HTTP
object,
they
have
to
the
correct
values
like
we
could
potentially
provide
them.
You
know
a
function
that
does
that
for
them.
So
sorry
go
ahead.
Tristan.
D
E
B
So
that
might
be
a
case
for
adding
payload
attributes
that
are
just
attributes
with
another
name
potentially
or
something
like
that.
So
I
just
want
to
throw
that
out
there
that
the
the
way,
just
in
general,
the
way
we
we
work
is
we
wanted
to
find
a
kind
of
generic
data
structure,
and
then
we
want
to
use
semantic
conventions
for
defining
the
kind
of
the
structure
of
the
values
in
there,
rather
than
defining
a
bunch
of
like
structs
and
Fields
for
each
each
data
type.
We
want
to
collect
just
like
in
general.
B
B
That's
that's
the
approach
that
in
general
we
like
to
take
towards
these
things,
so
you'll
probably
get
a
lot
of
pushback
from
the
TC
to
take
that
approach,
but
I
totally
am
sympathetic
to
the
idea
that
there
may
be
ways
that
payload
attributes
kind
of
conflict
with
the
rules
we
want
to
have
for
regular
attributes
like
like
size
limits
that
Tristan
mentioned
and
other
things
like
that.
So.
B
K
Bob
wants
to
try
some,
maybe
start
by
giving
some
her
story
like
what?
What
problem
are
you
trying
to
solve?
What
scenario?
Are
you
there,
for
example,
if
we're
trying
to
collect
HD
about
it
and
that
HP
body
is
a
video
two
gigabytes?
What
are
you
going
to
do
and
if
it's
an
image,
then
you
want
to
translate
to
a
specific
size,
then
what
are
you
going
to
do
with
the
smaller,
like
partial
image
file?
K
G
Yeah
so
I
think
that
some
of
that
is
is
in
the
Otep.
But
the
I
think
the
most
broad
use
case
for
that
is
to
is
to
debug
applications
by
being
able
to
find
specific
data
fields
that
go
between
services
and
also
to
just
see
the
the
context
as
broad
as
possible
and
and
I
think
that
being
able
to
to
collect
the
relevant
data
from
from
all
the
possible
payload.
That
the
collect
is
also
a
challenge.
G
But
there
are
multiple
things
that
could
be
done
like
automatically
shortening
specific
long
strings
or
arrays
inside
inside
the
mapping
or
by
giving
like
configuration.
That
will
be
Advanced
enough
to
to
allow
the
user
to
to
configure
that
specific
data
inside
the
payload
that
is
relevant
or
what
not.
And
what
isn't
relevant.
E
G
K
I
can't
imagine
how
people
might
find
it
useful
and
I've
also
also
seen
on
the
other
side.
There's
some
systems
started
by
providing
HTTP
about
it,
but
eventually
they'll
get
huge
amount
of
payload,
and
then
people
even
put
some
something
huge
like
a
downfire
or
something
some
like
binary
format,
and
how
would
the
existing
systems
evolve
to
support
that
I?
Try
to
imagine
the
world
supporting
basically
about
it,
how
the
years
and
depth
can
work
and
how
do
people
realize
that
he
may
be
Cortana
or
something,
and
this
is
about
the
entire
ecosystem.
G
G
E
L
The
thing
that
kind
of
strikes
me
about
the
explanation
there
of
the
the
purpose
is
we're
trying
to
add
attributes
that
can
help
debug
issues
as
they
happen,
and
that's
the
case
for
all
of
the
attributes
that
we're
adding
so
I
don't
see
the
payload
attributes.
As
being
you
know,
super
specific
in
in
any
way
and
I
I.
Think
Riley's
point
you
know
about
what
do
you
have
what
happens
when
you've
got
very
large
payloads
binary,
payloads
things
that
are
not
decomposable
easily
into
individual
attribute
values?
How
do
you
do
that
I?
Think?
G
L
Sure
so,
let's,
let's
say
we're
we're
building
a
system
that
uses
Adam
publishing.
You
know
a
typical
restful,
API
type
system
and
we
want
to
have
some
of
the
attributes
from
a
payload
of
a
published
article
attached
to
the
span
responsible.
For
you
know,
that's
that's
covering
the
receipt
of
that
post
request
to
publish
an
article
I
think
we
should
have
semantic
conventions
for
detailing
which
elements
of
an
atom
article
publishing
request.
We
should
have
on
a
span
and
what
those
fields
mean
when
they
appear
so
that
receiving
systems
know.
L
You
know:
okay,
I
see
Adam
dot,
author
I
know
that
that's
going
to
be
a
name
and
it's
going
to
be
a
string,
and
it
has
these
particular
meanings
as
opposed
to
an
potentially
arbitrary
bag
of
undefined
attributes.
That
may
be
defined
by
the
author,
but
may
not
have
consistent
meaning
for
receiving
systems.
G
Yeah
so
I
I
think
that
it
it
could
of
course
help
in
in
many
scenarios
on
on
their.
On
the
other
hand,
I
think
that
the
user
still
needs
to
know
where
these
attributes
come
from.
So
does
it
came
from
the
incoming
HTTP
message
or
some
which
doesn't
attribute
that
the
user
added
to
the
span
manually,
for
example,
so
and
and
also
I,
think
that's.
G
It
could
be
very
good
and
and
help
the
users
not
send
too
much
data,
but
on
their,
on
the
other
hand,
it
it
requires
many
con,
a
lot
of
configurations
that
could
be
too
big
of
a
burden.
So
if
the
payload
is
not
too
big,
why
not
just
send
it
all,
and
then
you
you
will
be
able
to
use
it
as
a
user
whenever
you
need
us
yeah
so
and
I
think
that
we
we
can
support
both
by
the
way,
but.
B
Yeah,
but
most
of
what
you
just
said,
the
run
just
sounds
like
Reinventing
attributes,
so
we
already
have
like
you
know.
We,
we
Define,
we
use
semantic
conventions
to
Define
like
standard
attributes
and
if
users
want
to
add
additional
attributes,
that's
totally
fine,
like
it's
easy
to
differentiate
between
them.
B
I
think
the
to
me,
the
the
like
two
real
questions
here
are
the
I
think
both
related
to
well
one
like
how
to
properly
structure
this
like
Anthony's
definition
of
having
like
a
payload,
DOT
type,
and
then
you
know
a
couple
different
attributes
for
the
kind
of
content
you
might
expect
to
find
in
there
like
serialized,
Json
or
something
like
that
would
be
a
good
like
place
to
start.
Potentially,
the
other
main
issue
is
just
the
size
issue.
We
don't
so
far.
B
We
have
tried
really
hard
to
avoid
instrumentation
level
configuration
we
don't.
We
want
open,
Telemetry
out
of
the
box
to
ship
with
instrumentation.
That's
that's
ready
to
go
into
production
and
if
it's
a
little
bit
noisy,
for
example,
you
have
say
health
check,
endpoints
that
are
noisy
to
use
things
like
automated
sampling
or
to
allow
the
users
to
just
add
some
configuration
into
their
collector.
B
The
next
hop
down
the
line
to
be
able
to
filter
that
stuff
out.
I
do
have
some
concern
with
adding
payload
data.
I
do
think
it's
useful
to
be
clear,
but
if
a
side
effect
of
this
is
suddenly
the
out
of
the
box,
instrumentation
becomes
like
very,
very
heavy
in
terms
of
the
amount
of
data
we're
sending
on
The.
Wire
I
wouldn't
want
to
solve
that
problem.
B
By
telling
that
end
users
they
need
to
go
in
and
do
a
bunch
of
instrumentation
level
configuration
so
I
don't
quite
know
what
the
solution
there
is,
if
there's
just
a
flag
in
the
hike,
a
span
processor
or
something
that
just
dumps
all
of
this
stuff
on
the
floor
by
default,
or
you
know
a
simple
way
for
the
end
user
to
to
deal
with
it.
But.
I
M
Josh
might
have
something
the
paths
I've
seen
this
handled
by
creating
a
verbose
like
flag.
You
know,
I
mean
many
logging
packages
have
this
already.
So
if
you
say
something
like
I
want
one
in
a
thousand
of
my
spans
to
include
the
payload,
the
and
and
that's
a
whole
feature
set
being
requested
right
there,
which
is
kind
of
a
lot
to
ask
for
a
verbose
fit
for
my
span
events
or
something
like
that.
But
it's
not
a
question.
M
What
what
I
remember
coming
up
more
in
this
type
of
scenario
in
the
past
has
been
pii
concerns
like
when
you
talk
about
specifying
most
of
the
attributes,
we've
already
given
cinematic
conventions
for
they're,
not
pii,
and
as
soon
as
you
talk
about
payload.
It's
like
this
giant
question
about
what
you're
leaking
and
it
typically
it's
been
payloads,
have
been
far
more
locked
down
than
standard
attributes
and
that's
what
I
would
worry
about.
G
Yeah,
that's
to
clarify
about
I,
think
it
relates
to
to
postponential
I.
Think
are
super
good.
The
I
think
that
this
feature
shouldn't
be
enabled
by
default.
So
when
the
user
uses
opportunity
like
today,
it
will
work
the
same
and
you
will
need
to
specifically
configure
it
going
to
be
probably
experimental
from
for
some
time
that
he
wants
to
collect
that
and
we'll
have
some
default
limits
for
everything
doesn't
die,
but
yeah.
These
points
are
still
relevant.
Yeah.
B
That's
that's
actively
being
discussed,
it's
a
little
crazy.
We
waited
this
long
to
have
it,
but
but
just
to
let
you
know
like
in
terms
of
like
where,
in
the
queue
something
like
this
might
might
land
it
might
take
a
little
bit
for
us
to
implement
this,
because
it
might
be
easier
to
do
something.
That's
going
to
be
entirely
optional,
which
I
agree.
This
should
be
means.
B
This
by
just
defining
the
semantic
conventions
for
these
attributes
and
saying
this
field
is
a
verbose
field.
You
know
you
should
drop
it
most
of
the
time,
but
I
don't
know.
I
I
think
there's
some
details
there,
but
just
to
warn
you
Ron,
it's
it's
gonna,
be
I
think
it
might
be
a
little
slow
going
to
to
get
this
through
yeah,
but
have
faith.
F
Yeah
by
the
way,
at
the
end
of
the
agenda,
there's
an
item
regarding
the
configuration
group.
So
maybe
we
can
talk
about
that.
Okay,
okay,
for
the
sake
of
time,
I
suggest
we
move
on,
hopefully
around
you
got
some
initial
feedback
and
we
can
iterate
in
the
old
tab.
Let's
yeah,
let's
keep
that
feedback
for
now.
Thank
you
so
much!
F
Okay,
thank
you
sweet!
They
are
here.
Thank
you.
Next
one
are
two
items:
I
put
there
myself,
but
they
were
actually
from
Jack
what
they
they
have
been
waiting
for
feedback.
They
are
the
first
one
is
just
you
know,
having
a
metric
for
for
time
after
GC
and
the
second
one
is
for
tracking
the
entire
QC
process
using
a
histogram
for
one
of
them.
We
already
have
enough
reviews.
Just
please
review
that.
F
J
So
yeah
I
I
originally
posted
this.
If,
if
anybody
is
interested
and
has
some
Cycles
to
review,
it
would
be
appreciated,
the
javasick
is
already
kind
of
gotten
Behind
these
conceptually
and
we're
waiting
the
garbage
collection.
Semantic
inventions
are
the
last
piece
last
major
piece
of
jvm
runtime
semantic
inventions
that
are
unaddressed.
So
if
we
can
get
these
in,
then
we
as
a
Java
Sig,
have
a
pretty
good
story
around
runtime
metrics.
J
So
we
already
have
PRS
representing
these
implementations
and
we're
just
kind
of
blocked
on
merging
those
until
the
these
are
merged
into
the
spec,
because
we
don't
want
to
cause
churn
for
our
users.
We
don't
want
to
release
code
that
has
instrumentation
one
way
and
then
you
know
get
feedback
from
this.
This
spec
and
then
have
to
change
that
instrumentation
and
break
their
their
dashboards.
So
feedback
would
be
appreciated.
J
K
J
K
It's
very
helpful
for
them
to
understand
the
peak
load
and
the
general
CPU
use,
and
so
that
seems
to
be
a
demand
for
any
type
of
utilization
to
also
show
histogram,
depending
on
the
scenario
so
monolith.
If
it's
a
general
problem,
we
want
to
say
hey
all
the
like
percentage-based
thing
can
be
also
viewed
as
histogram
or
want
to
do
that,
specifically
for
each
individual
metric.
J
E
M
This
is
an
area
where
we
begin
wanting
a
synchronous
gauge
again
and
I.
Many
of
you
know
that
we've
been
sort
of
waiting
to
get
out
like
a
first
1.0
type
of
metric
stability
before
we
go
talking
about
synchronous
gauges,
but
anytime,
you've
got
like
a
synchronous
observation
like
that.
It
makes
sense
to
make
a
histogram
out
of
it
as
well,
but
there's
a
few
cans
of
worms.
There
I'd
like
to
postpone
until
we've
got
more
sdks
at
stable.
J
The
one
thing
that
I
that
might
be
worth
discussing
while
we
have
some
folks
here
is
I-
think
if
there's
any
reason
not
to
record
this
as
a
histogram,
it
would
be
related
to
you
know
how
much
data
has
to
be
exported
out
of
the
application
in
a
histogram
versus
a
couple
of
counters.
So
with
garbage
collection
time.
The
main
things
that
you
want
to
analyze
is
how
many
discrete
garbage
collection
events
took
place
and
then
how
much
time
was
spent
in
garbage
collection.
J
So
you
know
you
can
track
both
of
those
as
encounters
and
then,
but
if
you
track
it
instead
as
a
histogram,
you
get
the
account
and
the
sum,
but
you
also
get
the
max
and
then
the
distribution.
So
you
get
some
you.
You
unlock
some
analysis
possibilities
that
aren't
available
if
you
were
just
to
track
the
count
and
the
sum
of
time,
and
so
a
question
that
was
going
on
in
my
head
is
like
okay:
when
is
it
appropriate
to
capture
more
data
and
send
more
data
out
of
the
application
like?
J
K
K
That's
the
raw
that
the
best
like
verbal
State
you
can
guide,
or
do
you
want
that
to
be
only
something
like
a
counter
or
something
in
the
middle
like
this
program,
so
you
can
see
the
extreme
and
we
somehow
talk
to
the
download
runtime
team
and
figured
the
raw
logging
part.
Probably
it's
just
two
more
of
us,
so
they
suggest
leave
some
lower
level
troubleshooting
thing
to
specific
tools.
Instead
of
trying
to
cover
that
in
the
generic
like
Telemetry
system,.
J
Yeah,
that's
a
that's
a
good
case
and
like
maybe
so,
for
the
low
level
garbage
collection
events.
You
know,
I
think
what
we
have
to
think
about
is
what
are
the
same
defaults
and
then
what
should
you
be
able
to
flip
on
in
in
in
situations
where
it's
relevant
so
from
a
default
perspective?
It
probably
doesn't
make
sense
to
emit
those
low-level
garbage
collection.
Events
I
think
we
can
all
probably
agree
on
that,
but
maybe
you
can
flip
them
on
if
it's
appropriate
for
your
use
case,
yeah.
E
A
J
I
thought
a
histogram
was
a
good
compromise
here
for
how
to
track
these.
These
garbage
collection
events,
because
you
know
with
views
we
have
the
ability
to
take
a
more
heavy
weight.
You
know
histogram,
which
has
all
the
buckets
and
downgrade
it
to
a
single
bucket
histogram,
which
is
which
is
much
less
data
over
the
network.
So
that's
kind
of
why
I
felt
comfortable
with
leaving
a
histogram
as
the
default
for
this,
except.
D
M
M
Is
that
there's
there's
some
connection
between
gauges
and
histograms
that
we
have
totally
not
able
to
make
until
we've
talked
about
how
to
make
a
synchronous
gauge
but
and
I
want
to
hold
that
off
for
a
second
but
I
do
want
to
respond
to
Jack's
comment
in
the
lightstop
SDK
that
I
developed,
partly
to
get
livestep
internal
code
base
moved
forward,
but
also
prototyping
I've
added
with
a
min
max
some
count
aggregator.
This
was
discussed
many
times
during
the
early
prototypes
for
open
Telemetry.
M
It
is
a
histogram
that
just
records
me
maximum
count,
and
it
stands
in
for
that
situation
that
you
described
Jack
where
you've
got
a
like.
A
count
of
events
like
garbage
collection,
duration
and
I
can
either
have
two
counters
or
I
can
have
one
histogram,
I
think
semantically.
We
should
probably
go
after
one
histogram,
because
it
keeps
those
counters
coherent
and
consistent
and
describes
to
you
what
you're
seeing
like.
M
It
suggests
to
me
that
again,
I
want
us
to
finish
something
rather
than
just
prolong
our
very
long
Hotel
metrics
project,
but
having
another
alternative
for
histogram,
which
is
exactly
what
you
said.
The
zero
histogram
I
call
that
Min
maximum
count
and
then
we're
back
to
the
question
of
how
much
verbosity
do
you
want?
How
do
you
configure
it?
How
do
you
know-
and
it's
almost
the
same
as
that
question
about
payload
earlier
today,
like
yeah,
you
can
get
really
expensive
instrumentation.
If
you
want,
how
do
you?
M
J
Now,
thanks
for
the
feedback,
take
a
look
at
those
pcrs
I
would
I
would
appreciate
a
thumbs
up.
It
doesn't
seem
like
there's
any
good
reason
not
to
record
it
as
a
histogram.
For
now
we
have
the
tools
to
be
able
to
reduce
the
the
data
being
emitted
out
of
an
SDK
today,
and
you
know
I
hope
with
time.
Maybe
it
can
get
even
easier.
You
know
with
a
file
based
configuration,
it
should
be
even
easier
to
configure
the
views
for
the
specific
instruments
to
control
your
data.
Egress.
M
J
It's
definitely
it's
definitely
available
in
Java,
because
you
know
you
can
configure
a
histogram,
an
explicit
bucket
histogram
with
its
buckets.
So
if
you
just
specify
none
of
those
buckets,
then
you
have
you
have
that.
Well,
it's
a
one
bucket
histogram,
not
a
zero
bucket,
but
it's
effectively
the
same
thing.
M
F
D
D
The
idea
is,
you
can
wrap
a
function
and
then
everything
under
it
will
not
create
a
span,
even
though
it
might
start
spans
technically
and
there's
a
couple
ways
of
doing
this.
They
all
have
their
pros
and
cons.
Javascript
has
an
implementation.
Ruby
has
one.
Basically,
it
creates
a
recorded
span.
That's
not
sampled!
D
So
if
the
parent,
if
you're
using
a
parent
base
to
get
rid
of
it,
they
won't
record
it,
but
not
you're,
not
always
using
parent-based
sampler,
so
that
doesn't
work
in
all
cases,
so
I'm
trying
to
collect
information
on
this,
because
I
gotta
asked
once
again
about
this
functionality
from
a
user
and
hoping
to
get
it
worked
out
in
in
the
spec
so
that
it's
available
everywhere.
So
if.
D
H
I
guess
I'll
break
the
Silence
by
just
saying
I
strongly
support
this
I
think
it's
probably
been
solved
in
just
about
every
language
because
of
a
lack
of
specification
in
a
different
way,
every
single
time,
probably
I.
Think
probably
at
this
point
it
might
be
hard
to
specify
just
because
there
are
so
many
different
implementations.
H
Javascript
did
not
use
a
sampler
for
just
the
reason
you
mentioned
that
if
somebody
has
a
custom,
sampler
or
something
like
that
and
doesn't
implement
this
functionality,
you
can
end
up
with
like
infinite
Loops,
where
we
trace
the
exports
for
trade
for
otlp
exports
and
stuff,
like
that.
So
that's
obviously
not
good
yeah
I'm
strongly
in
support
of
specifying
this
I
think
it
should
even
be
I.
I
would
make
an
argument
for
it
to
be
added
to
the
API
and
JavaScript.
H
M
M
D
M
I
recall
in
the
old
days
back
in
the
Google
using
C
plus
plus
code
base,
we
had
something
called
a
blank
Trace
span
and
it
was
just
essentially
saying:
I
I
need
to
make
sure
there's
no
Trace
context
here,
because
I
don't
want
to
be
instrumented
and
the
other.
The
other
devices
I
recall,
would
be
like,
like
thread
local
storage.
To
say:
I
must
not
be
traced
because
you're
writing
an
exporter
for
a
tracing
library,
for
example.
Sorry
Ted
I,
don't
have
many
good
answers.
H
We
added
a
flag
in
the
local
context.
The
trace,
Flags
I,
would
be
a
little
bit
like
you
know.
Trace
Flags
come
in
from
an
external
call.
Something
like
a
health
check
would
obviously
not
include
that,
so
you
would
need
some
mechanism
to
add
it,
and
then
you
know
it's
kind
of
a.
It
seems
like
adding
a
local
concern
to
a
data
model
which
was
explicitly
made
to
be
a
remote
I.
Don't
know
I
I
think
Trace
Flags
is.
Is
there
there
could
be
an
argument
made
for
a
trace
flag.
H
M
B
B
H
H
You
don't
have
such
a
problem
with
metrics,
because
everything
is
aggregated
and
rolled
up.
That
said,
you
probably
don't
care
about
the
response
times
of
your
health
check,
endpoint,
so
I
think
in
some
cases
you
want
to
disable
tracing
and
in
some
cases
you
want
to
disable
all
Telemetry,
but
but
the
conversation
explodes
so
in
JavaScript
we
kicked
that
can
down
the
road
by
saying
we'll
wait
for
the
specification
and
it
only
disables
tracing.
E
M
On
that
note,
we
have
this
open.
Otep
number
207
by
Christian,
noymore
I,
believe,
is
that
right,
yes,
proposing
something
called
context:
scope,
attributes
context,
scoped
attributes-
and
this
is
as
close
as
I've,
seen
to
any
discussion
involving
local
Telemetry
configuration
properties
that
do
not
cross
the
wire,
and
so
the
whole
point
of
that.
M
That
Otep,
which
has
been
debated
quite
a
bit
but
kind
of
stalled
out,
is,
is
that
I
want
to
make
changes
to
the
ways
the
attributes
that
are
propagated
locally,
without
making
changes
to
the
attributes
that
are
propagated
across
the
wire,
which
is
really
close
to
what
you're
asking
for
here.
In
other
words,
I'd
like
to
make
a
local
change
to
my
ability
to
start
traces,
which
is
not
very
different
than
making
a
local
change
to
my
attributes.
M
H
B
H
Guess
I,
don't
know
how
important
I
think
that's
what
that's
what
Trace
state
is
for.
If
there's
missing
spans
in
the
middle
of
a
trace
is
what
you're
saying
yeah
I
I
mean
most
vendors
I
think
have
solved
that
using
Trace
State
at
this
point,
I
don't
know
if
any
of
the
open
source
Solutions
do
that,
though,.
H
B
State
it's
Trace
state
is
like
on
the
wire.
You
would
know
that,
but
it
seems
like
communicating
that
information
to
the
back
end.
For
example,
if
you
have
something
that's
trying
to
do,
Trace
graph
analysis-
and
you
know
I,
don't
know
I,
guess
it's
not
as
big
of
a
deal
if
it's
something
that's
always
on
or
off,
as
opposed
to
like
spans
it
or
sampled
out
some
of
the
time,
but
yeah.
A
D
D
There
be,
there
would
be
missing
spans,
but
there
wouldn't
they
wouldn't
be
parent
potential
parents
of
anything,
because
you
simply
wrapped
and
then
you
continued
on
with
like,
because
you'd
have
to
be
able
to
retrace.
You
essentially
say
now
start
tracing
again.
If
you
had
functionality
like
that,
yeah.
B
I'm,
just
thinking
more
about
the
distributed
use
case.
Maybe
it's
a
it's
a
non
non-biggy,
but
if
we're
saying
like,
we
want
to
locally
disable
data
collection,
but
you're
talking
about
a
trace
that
continues
on
it
seems
like
like
a
simple
answer
would
be:
it
would
be
Trace,
State
and
you're.
Just
saying,
like
I,
don't
care
from
this
point
onwards,
I!
Don't
care
about
this
Trace
like
just
turn
it
off.
M
B
M
Talking
about
two
problems
right
now,
there's
one
about
like
I,
have
a
trace
and
my
child
was
sampled
and
how
do
I
know
that
my
child
was
sampled
I'm
missing
my
child
and
then
we're
talking
about
you
know.
There's
there's
can
there's
sampling,
that's
not
root
based,
and
you
know
like
in
my
intermediate
node
is
missing,
like
a
proxy
got
sampled
out
and
I
have
no
way
of
knowing
that
my
my
parent,
Trace
ID
is
not
not
present
so
I'm
linking
to
my
grandparent
or
something
like
that.
There
have
been
proposals
to
count.
M
The
number
of
missing
ancestors
I've
seen
that,
but
this
does
not
seem
like
the
same
issue
that
that
started.
This
conversation
about
untraced
local
Behavior,
like
I,
think
you
want
to
clear
the
trace
ID
when
you're
in
your
this
special
circumstance
where
you
can't
trace
anything
which
means
you're,
not
weaving,
a
sort
of
like
half
Trace
situation,
great.
M
K
A
vulnerative
folks
see
the
similar
issue
is
what
I
saw
in
open
climate
Donuts.
There
are
two
cases:
one
is
in
some
exporter,
you're
doing
the
RPC
operation,
extending
data
from
HTTP
client
or
receiving
data,
as
if
it
is
sort
of
Prometheus-
and
you
don't
want
those
interactions
to
be
automatically
captured
by
some
instrumentation
Library.
The
second
scenario
is
in
some
operation.
You
know
this
is
a
high
level
operation
you're
trying
to
upload
one
gigabytes
of
file.
K
F
N
Yeah,
everyone
I,
don't
have
a
lot
to
say
there
other
than
just
wanting
to
call
out
that
this
working
group
is
kicked
off
officially
I
think
it's
been
unofficially
a
working
group
with
a
few
of
us
that
I've
met
a
couple
of
times
and
yeah.
If
folks
are
interested
in
participating,
feel
free
to
join
the
working
group.