►
From YouTube: 2022-08-16 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
D
I
wish
that
there
was
a
way,
and
maybe
there
is,
but
I
wish
that
I
knew
it
to
put
the
link
to
the
spec
sig
notes
in
our
google
doc,
but
have
the
link
be
open?
The
spec
save
notes
in
view
only
because
I
don't
want
to
edit
I'm
not
interested
in
adding
because
I'm
looking
at
it
afterwards,
but
I
didn't
see
anything
on
the
url
change
when
I
switched
to
viewing
it's
just
slash
edit
still.
C
I
am
not
a
vampire
I've
not
been
bitten,
I'm
not
turning
into
something
evil,
but
I
did
get
hit
with
an
escrima
stick
in
the
face
during
the
large
class
last
week
and
my
eyes
are
colorful.
So.
D
D
C
C
All
right
so,
a
little
while
ago
there
was
a
spec
sig
or
there
there
was
a
spec
issue
to
remove
direction
as
an
attribute
from
a
number
of
metrics.
There
were
some
situations
where
it
was
like
not
a
good
fit
so
like
on
on
network.
You
would
have
like
sent
and
received
on
like
disk
operations,
you
would
have
read
or
written
and
they
weren't
making
sense
for
everything.
C
So
so
there
was
kind
of
an
effort
underway
to
treat
those
as
separate
metrics,
basically
just
move
the
direction
into
the
name,
making
a
different
metric,
and
then
everything
was
working
out.
C
C
I
think
we
were
still
trying
to
kind
of
survey
the
state
of
the
world
kind
of
outside
of
hotel
to
see
what
makes
the
most
sense
and,
if
there's
a
good
precedent
out
there,
but
I
think
the
tldrs
there
are
probably
some
situations
where
direction
still
makes
sense
as
being
an
attribute
on
a
metric.
I
think
there's
going
to
be
some
situations
where
it
doesn't
make
sense,
we're
just
going
to
do
a
little
bit
more
work
to
figure
out
exactly
where.
Where
and
why.
C
E
C
C
So
just
trying
to
make
this
a
more
official
or
an
officially
official
sig
under
the
hotel
umbrella.
I
don't
think
there's
any
problems
with
that,
which
is
an
ask
at
the
meeting.
C
There
is
an
issue
about
adding
a
process.threads
or
similar
metric
and
a
name
for
it.
I
think
we
talked
about
this
a
little
bit
last
week.
C
C
I
think
the
other
thing
is
that
people
are
probably
conflating
a
little
bit
like
the
vm
of
your
language,
whether
or
not
you
have
access
to
a
thread
count
or
whether
you
have
kind
of
some
sort
of
managed
threads,
green
threads,
fibers
other
things,
and
I
kind
of
suspect
that
in
the
end,
I'm
probably
making
a
leap
here,
but
I
think
at
the
end
you
can
probably
have
something
like
a
a
process.threads
which
is
the
operating
system's
view
of
the
threads
being
used
by
a
process
that
would
be
totally
fine
and
then
some
sort
of
like
vm
dot.
C
My
concurrency
mechanism,
maybe
with
your
language
in
there
as
well,
because
those
tend
to
vary
between
vms
and
then
I
think
everyone
would
be
happy.
But
the
discussion
is
ongoing.
C
This
has
been
hotel,
sdk
enabled,
I
don't
think
anybody
is
challenging
whether
or
not
this
should
be
an
environment
variable,
but
I
think
there
has
been
just
an
incredible
bike
shedding
about
how
to
represent
a
true
or
false
value
here
and
yep
yeah.
It's
just
been.
I
don't
know.
C
Anyone
who
has
been
to
these
white
sheds,
you
just
have
to
laugh,
I
guess
as
as
he's
happened,
but
I
think
I
don't
know
this
was
talked
about
for
a
really
long
time
and
there's
just
a
lot
of
concerns
about.
Should
it
be
the
word
true
explicitly
true
what
about
zero
and
one
or
should
you
look
at
it?
The
other
way
like?
Should
it
be
exclusively
false
and
anything?
That's
not
false
is
you
know
not
falsy
and
therefore
true,
I
think,
towards
the
end.
C
E
C
C
C
This
has
been
brought
up
a
couple
times
it's
here
to
support
the
equivalent
of
prometheus
namespace
for
hotel
metrics,
and
this
is
something
in
prometheus,
so
that
metrics
created
by
separate
libraries,
don't
conflict,
and
I
have
to
say
the
more
I
think
about
this,
the
more
I'm
starting
to
get
kind
of
confused,
because
I
know
we
have
the
notion
of
meter
provider
in
hotel,
which
I
think
is
supposed
to
be
the
same
thing,
but
I
suspect
that
the
meter
provider
name
might
not
always
be
short
enough.
It
might
not.
C
It
might
not
fit
into
the
namespace
space
super
well,
and
that
might
be
the
reason
why
they're
trying
to
introduce
this
again.
I
don't
see
anybody
like
objecting
to
adding
short
name
in
general.
It's
the
name
of
short
name.
C
C
D
Yeah
I'll
have
to
go
read
that
one
because
scope
scope,
scope,
having
replaced
instrumentation
library.
Now
you
have
scope
right,
scope,
metrics,
go
trace
or
skip
span
and
a
scope's
name
comes
in
as
scope,
name
scope.name.
D
When
when
you,
when
you
interpret
at
least
when
we
interpret
these
things
much
like
instrumentation
library
name,
would
be
called
library.name
in
the
in
the
attributes.
On
that
span
it
seems
like
if
there
is
a
attribute
called
short
name
on
scope,
it
would
be
scope.shortname
much
like
the
name
on
a
scope
is
scope.name.
E
D
What
I'll
read
it
and
see
if
see
if
I
can
write
that
down
or
if
or
if
I'm
wrong.
C
Yeah,
how
are
all
these
things
working
out
underneath.
A
D
If
I'm
remembering
things
right,
it's
as
as
a
receiver
of
hotel,
when
I
get
things
at
the
instrumentation
library
or
or
scope
level,
there's
an
attribute
in
there
called
name-
and
I
know
because
of
semantic
inventions.
I
call
it
library.name
or
now
scope.name
because
it
got
renamed
so
scope.shortname
makes
sense
to
me,
but
it
maybe
doesn't
go
on
the
wire.
It
goes.
It's
part
of
the
semantic
conventions
when
bringing
this
thing
in
it's
a
scope,
level
thing.
E
C
Cool,
it
sounds
sounds
reasonable.
Unlike
all
right,
we
are
starting
to
run
a
little
bit
long,
but
I
think
yeah.
The
last
thing
that
was
on
the
list
was
the
profiling
working
group
is
finishing
up
their.
C
I
assume,
is
the
initial
proposal,
because
the
bike
sheds
most
likely
haven't,
started
yet
around
the
profiling
signal
and
it's
kind
of
built
as
it
as
an
event
type.
I
think
events
are
built
on
top
of
logs
there's
a
document
at
least,
and
it's
a
document,
and
then
this
sig
meets
at
8am
pacific
on
thursdays.
C
I
think
they
were
going
to
have
a
more
throw
through
discussion
of
the
document
and
proposal
there,
but
it
sounds
like
sounds
like
at
least
the
group
has
agreed
on
something
that
they
are
happy
with
for
profiling.
So
that
is
like
the
exciting
news
and
that's
what
I
have
for
the
specs.
E
So,
do
you
think
that
also
hi
everyone
do
you
think
that,
like
are
we
converging
on
the
log
data
model
actually
just
being
a
generic
event
data
model,
because
I
believe
the
client
telemetry
working
group,
at
least
at
one
point,
was
also
going
to
build
their
client-side
stuff
on
top
of
logs
for
want
of
an
event
signal.
It
sounds
like
maybe
that's
the
case
here
as
well,
for
profiling
is
that
kind
of
the
direction
this
is
going
overall?
Do
you
think
I'm
curious?
C
It
seems
like
logs
are
the
low-level
primitive
that
events
are
being
built
on
top
of.
I
don't
know
if
that
is
intended
or
not,
but
it
seems
like
that
is.
A
With
with
profiling,
some
context
that
might
be
relevant
is
splunk
has
a
profiling
feature
that
they
shipped
via
hotel,
which
they've
done
by
shoehorning
it
into
the
logs.
A
So
it
wouldn't
surprise
me
if
they're
like
well,
here's
our
prior
art,
you
know
that's
why
we're
looking
at
logs
for
this,
but
I
haven't
attended
a
tried
to
encourage
people
for
like
seem
to
attempt
to
know
more
than
about
profiling.
E
It
would
make
sense
logs
as
a
signal
are
very,
very
flexible.
It's
essentially,
you
know,
attributes
and
resource
and
then
a
body
which
a
body
can
be
literally
anything
you
want,
including
another
structured
object.
So
it's
sort
of,
I
guess
it
kind
of
makes
sense.
D
The
structured
object,
part
is,
I
I
don't
know
the
details
of
the
log
signal,
but
are:
are
there
formats
on
the
wire
proto
like
in
otlp,
the
wire
protocol?
Did
we
say,
like
this
body,
can
take
the
form
of
something
that
is
itself
parsable,
because
that's
a
we
have
customers
who
are
interested
in
doing
like
json
unpacking
in
their
traces,
so
like
a
span
could
have
a
field.
That's
a
whole
bunch
of
json
and
they're
like
I'd
like
all
those
to
magically
become
attributes
and.
D
C
E
I
mean
if
it
weren't
there
and
there's
also
some
like
trace
id
bits
in
there
that
are
also
kind
of
specific
but
yeah
if
it
was
just
like
resource
and
instrumentation
library
and
then
the
body
being
in
any
field
yeah,
you
could
like
re-implement
anything
else
on
top
of
that
body
field
right.
But
it's
interesting.
D
D
A
Anyway,
who's
the
who's,
the
person
supposed
to
say
what
time
sam
yeah
he's
got
some
stuff
going
on.
I
think
cheetos
would
like
me
to
say
third
time.
I
think
on
this
stuff.
A
E
C
Yeah
getting
out
with
something
potentially
useful,
is
there
anything
useful?
Should
we.
A
Oh
yeah,
to
be
clear,
I
don't
have
like.
I
had
one
thing
just
to
juanita's
opinion
before
I
do
it,
but
I
don't
have
burning
questions
or
anything
okay.
So,
if
there's
valuable,
if
people
are
valuable
stuff,
you
know
for
sure
talk.
Go
too
specific.
E
I
was
just
gonna
mention
before
we
get
into
the
structured
one.
I
will
have
something
more
interesting.
Next
week
I've
been
in
touch
with
somebody
who
asked
not
to
actually
be
named
in
their
connection
directly
to
open
telemetry.
But
let's
say
a
large
company
uses.
Ruby
had
some
really
interesting
feedback
and
I've
been
kind
of
talking
to
him
about
it
and
sort
of
trying
to
figure
it
out.
E
So
I
think
I'm
going
to
try
to
present
something
more
structured
next
week
about
some
real
world
sort
of
open,
telemetry
pain
points
with
ruby
and
specifically
like
where
they
were
not
able
to
necessarily
use
our
stuff
and
they
wanted
to
and
like
what
we
might
be
able
to
do
in
the
future.
So
I
I
am
working
on
that
and
I
wanted
to
mention
that
I
hope
to
present
that
next
week,
cool.
C
Cool
yeah,
real
user
stories,
I
think,
are
we
super
helpful.
A
Cool
I
put
this
on
the
agenda
so
following
up
from
last
week,
which
we're
reverting,
you
know,
we
don't
need
to
go
over
this
thing
kind
of
beat
into
the
ground,
but
one
thing
we're
doing
is
encouraging
people
to
add
their
own
instrumentation,
so
we're
going
to
write
a
doc
sort
of
being
like
hey.
Here's
like
what
good
instrumentation
looks
like
do
you.
I
guess
my
question
is
like.
Are
there
things
I
ought
to
put
in
there
like,
because
I
totally
zoned
out
the
past
couple
weeks?
A
A
It
feels
like
these.
Should
you
know
this
should
be
not
specific
to
a
language.
There's
there's
some
language
specifics
to
writing.
Good
instrumentation,
like
you
know,
don't
use,
classy
values
depend
or
whatever,
but
it
feels
like
largely
it's
like
pretty
holistic
and
so
yeah.
I
don't
know
what
do
you
all
think.
A
D
Maybe
some
in
the
vein
of
the
thread
that
was
in
the
cncf
slack,
with
having
an
example
rails
app
that
example
rails
app,
the
open,
telemetry
initializer
could
maybe
also
include
a
custom
library.
That
is
a
custom
instrumentation
example.
A
Something
we've
told
you
to
do
that's
a
good
idea
but
yeah,
I
guess
and
then
okay,
that's
a
good,
that's
a
good
approach.
Actually
I
think
that
is
helpful
and
I
will
attempt
to
do
that.
D
To
your
question
about:
where
would
we
if
we
were
to
document
it?
Where
would
we
document
it?
I
don't
know
that
in
poking
around
other
languages,
docs
I've
ever
seen
like
a
good
here's,
how
you
write
your
like
here's,
how
you
write
auto
instrumentation,
it's
it's
very
like
here's,
how
you
turn
on
the
existing
auto
instrumentation
by
bringing
in
libraries
and
fiddling
configs
and
here's
how
you
make
manual
spans
right.
I
don't
know
that
I've
come
across
so.
A
Right
or
a
package
that
provides
another
inspiration,
yeah
yeah
yeah
concurred.
I
agree:
yeah,
okay,
cool
yeah,
so
maybe
I
was
just
thinking
about
it
like.
D
A
Seems
yeah?
No,
I
mean
somebody
should
write
that,
rather
than
shoehorning
in
config
options
to
sneak
your
auto
instrumentation
in
yeah
god,
man
is
here
to
chew.
Bubble
gum
kick
ass
anyway,
the
most
watching
a
lot
of
rowdy
piper
over
weekend
cool,
that's
helpful
and
no
further
question.
C
Right
yeah,
I
think
there
there
is
some
ruby,
specific
software
on
how
to
use
like
instrumentation
base
and
if
you
wanted
to.
A
And
yeah
yeah,
I
wasn't
sure
how
much
to
get
into
like
one.
I
haven't
written
anything
so
like
I
thought
that
was
for
10
minutes.
Basically
I
did
the
revert
and
then
I
realized
there
are
two
parts
to
this.
Yeah
like
I
wasn't
sure
how
much
to
get
into
like
cool.
Like
publish
the
gem
to
ruby
gems,
you
know
et
cetera,
but
I
can
include
that's
all
pretty
trivial
or
I
could
just
link
to
the
rubygems.comwork.
C
Yeah,
I
don't
know
that
you
need
to
walk
somebody
through
actually
publishing
to
rubygems,
but
I
think
understanding
how
to
use
instrumentation
base
in
your
package
is
kind
of
one
of
the
key.
The
key
things.
Okay,.
D
And
I
think
the
use
case
for
which
the
the
hooks
came
in
it's
probably
a
good
use
case
of
like
okay,
so
you
don't
like
the
the
standard
rack,
auto
instrumentation
that
comes
with
open
telemetry
can
trip
here's
how
you
don't
bring
that
into
your
bro,
don't
bring
that
one
in
your
project?
Here's
how
you
write
your
own.
A
A
I'm
going
to
reach
out
to
helios
and
see
what
they
what
they
pay
for
contracts
just
to
write
their
thing
for
him.
Oh
my
three
times
like
cool
two
birds
with
one
stone,
yeah,
that's
a
good
that
is
a
good
call.
Yeah
I'll,
probably
do
something
with
rack
or
something.
That's
like
a
slight
mod
on
like
hey.
You
want
to
do
some
funky
thing
that
we
don't
want
to
expose.
Then
this
client
instrumentation,
like
here's,
how
you
might
spread
your.
C
A
I
mean
I'll
put
the
in
there,
our
I'll,
submit
it
to
contrib,
so
it
gets
the
reviews
and
stuff
we
want.
Like
you
know,
we
can
have
our
own
discussion,
it's
about
like
whoever
poor,
austin
or
whoever
maintains
or
fill
up
on
the
community.
The
I
o
repo
it
doesn't
have
to
like
you
know,
get
read
in,
we
can
sort
of
like
agree
on.
We
can
do
all
the
hard
reviewing
on
contrib
and
then
I
cannot
stream
it
or
something.
D
There's
there's
some
in
in
to
agree
with
that.
There's
some
other,
maybe
additional
byproducts
of
having
the
example
in
contrib,
because
the
example
can
then
act
as
a
little
integration.
Testy
sandbox
spin
things
up
for
when
you're,
making
changes
to
instrumentation
you've
got
a
little
sample
app
in
there
ready
to
run
a
critical
in
my
eye
that
it
could
be
a
part
of
ci
like
this
stuff
integrates
in
the
example,
but
that's
like,
let's
not
make
ci
more
complicated
than
it
is
already.
A
And
let's
have
that
sample
app
run
on
the
latest
version
of
jruby
and
then
sorry
drop
a
ruby
move
on
never
fail.
D
C
A
Probably
well
we
there's
some
things
we
probably
have
to
merge
that
have
been
like
approved
and
yes,
I
mean
the
basic
one
is
like
all
these
things
that
I'm
adding
into
revert
like
you
should
probably
merge
them
and
then
release
the
http
instrumentations
that
are
impacted
along
with
all.
But
I'm
not
sure
I
don't
know
what
the
I
don't
know
offhand.
I
would
have
to
look
at
what's
closed
and,
if
anything's
been
merged,
that's
like
a
version
pump.
A
You
would
think
I'd
be
on
top
of
this,
but
not
I
can
look
into
it
and
I'll
make
a
list
of
stuff
that
needs
to
get
bumped
and
and
then
maybe,
if
there
are
I'll
get
bump,
those
things
check
it
with
ariel
make
sure
he
agrees,
and
then
we
can
bump
instrumentation
at
all.
I
can
just
put
on
my
to-do
for
this
week.
E
I'm
wondering
if
we're
not
actually
creating
github
releases
for
the
individual
gems,
when
we
release
them
right,
we're
just
pushing
them
to
ruby
gems,
because
I
know
github
can
actually
show
you
like
you
know.
You
know,
commits
since
last
release
or
whatever
I'm
wondering
if
we
added
that
into
our
release
process.
If
maybe,
then
it
would
make
this
task
a
little
bit
easier,
we'd
be
able
to
see
commits
to
maine
since
last
release
of
instrumentation
all
right.
C
A
Feature
but
well.
A
Probably
not,
there
hasn't
been
too
much.
We
have
a
bunch
of
stuff
approved
but
not
merged.
A
E
I
will
bring
it
up
to
them
next
week,
then
I
will
ask
them
what
they
think
I
mean,
given
that
there
are
releases
cut
for
via
github
actions.
I
mean
it
feels
like.
Maybe
we
do
somehow,
but
you
know
I
will
ask
them,
would
they
yeah.
A
A
C
All
right,
so
it
sounds
like
the
action
item
is
to
figure
out
what
we
want
to
integrate
for
our
next
release
and
then
release
it.
But
we're
probably
not
we're
not
sitting
on
something
that.
A
A
C
Is
there
anything
here
that
is
in
need
of
some
reviews
that
would
help
out
this
process.
A
Though
so
I
think
both
rake
and
ra
race
car
is,
I
think,
needs
another
approver,
an
approver
to
approve
it
as
well
as
rake.
I
think
they
both
are.
I've
approved
both
of
them,
but
I
approve
pretty
fast
on
this.
As
you
may
be
aware,.
A
B
Graphql
stuff,
can
you
guys
hear
me.
C
B
Cool
the
graphical
stuff
is
kind
of
in,
like
a
hang
tight
holding
pattern
right
now,
so
the
authors
are
from
people
internal
shopify,
just
like
a
little
more
context.
One
of
them
is
like
a
lead
on
like
an
api
team.
B
This
is
something
they
want
and
they've
been
patiently
waiting
we're
looking
at
approaching.
This
is
like
entirely
different
than
the
pr
so
like,
instead
of
handling
it
at
the
instrumentation
level,
I'll
just
like
quickly
recap.
Basically,
there's
a
lot
of
verbose
fields
that
are
off
by
defaults
with
graphical
instrumentation.
B
Turning
them
on
generates
large
traces,
which
is
not
a
good
default
behavior,
because
it
could
just
be
noise,
so
I
said
hey
like
maybe
we
could
do
this
per
request,
74,
so
they've
taken
a
couple
approaches.
This
being
the
second
attempt-
and
I
said,
hey
what
about
this
scenario-
and
maybe
we
should
use
propagation
rob
that
left
that
comment
there
said
hey
like
not
all
graphql
uses
http-
and
I
didn't
know
that-
which
is
a
very
good,
fair
point,
but
more
to
just
like
a
general
approach,
and
I
kind
of
left.
B
This
comment
for
a
couple
of
johnny's
pr's:
is
that
like
it
might
make
more
sense
to,
or
I
feel
that
it
makes
more
sense
to
handle
some
of
these
concerns
with
a
sampler
with
like
a
custom
sapler
configured
to
handle
it.
B
Yeah,
that's
exactly
it
so
yeah
we
we
are
taking
it
like
a
step
further
than
that,
so
one
of
our
applications
has
a
sampler
that
does
like
one
percent
of
the
traces
at
a
higher
verbosity,
where
it
prunes
a
lot
of
internal
spans
like
almost
the
bulk
of
them.
We
want
to
amend
that
we're
going
to
take
the
approach
where,
with
this
graphical
instrumentation,
we
could
say
turn
it
on
and
that
pruning
will
prune
all
those
internal
instruments
with
those
internal
spans
there.
B
But
if
someone
tells
the
verbosity
to
get
forced
it'll,
override
those
pruning
rules
and
say
like
keep
everything,
absolutely
everything
and
so
it'll
basically
be
like
the
debug
flag
right
that
people
are
used
to
it's
like
turn.
The
noise
on
and
off,
but
it'll,
be
on
a
per
request
basis
and
instead
of
having
the
instrumentation
handle
that
that
concern
it'll
be
a
sampling
level
thing.
B
The
benefit
is
that
if
we
run
into
cases
where
we
want
to
do
the
same
thing
with
like
say,
http
requests
similar
to
what
like
johnny's
configuring
in
his
prs.
We
don't
have
to
go
and
update
all
of
the
instrumentation
libraries.
You
just
add
a
rule
that
follows
the
semantic
conventions
around
http
spans
and
say
hey
if
it
looks
like
this
to
this
client
or
this
endpoint,
and
we
don't
care
what
http
library
we're
using
we're
going
to
apply
the
same
rule
set
to
you.
So
we
haven't
done
this
yet.
But
it's
it's
work.
B
That's
in
flight
right
now
and
we'll
have
to
profile
it
a
bit
because
it
could
be
computationally,
expensive,
good,
being
keyword.
We
have
to
see
what
the
actual
impact
looks
like,
but
from
our
current
vantage
point
this
seems
like
the
more
sustainable
approach,
the
more
organized
approach,
no.
D
Parallel
to
this,
honeycomb
is
trying
to
work
with
the
collector
folks
to
get
some
sort
of
sampling,
rules-based
sampling
added
to
collectors
so
that
you
can
generate
all
you
want
run
through
collectors
and
collectors.
Do
the
computational
intensive
stuff,
if
you're,
okay,
with
sending
it
all
over
the
wire,
but
don't
want
to
store
it
in
your
data
back
end.
B
Yeah,
the
I
think,
one
of
the
trade-offs
and
one
of
the
reasons
we're
actually
doing
this
at
the
application
level.
Right
now
is
we
have
this
like
one
little
trick
where,
when
you
generate
a
non-recording
span,
it'll
inherit
the
parent's
band
id
and
basically
the
way
that
works
is
like
all
the
non-recording
spans
will
have.
Essentially
the
same
parents
fan
id
of
whatever
is
the
nearest
recording
span.
B
So
you
preserve
the
structure
of
the
trace
without
having
to
rebuild
the
trace,
whereas
if
we
were
to
do
it
at
the
collector,
it
isn't
obvious
how
we
could
get
that
same
efficiency
right
yep.
So
we
don't
want
to
rebuild
traces
in
the
collector,
at
least
not
yet.
B
So
yeah
that's
one
of
the
reasons
why
for
us
right
now,
it
seems
so
appealing
to
do
it
at
the
application
level
and
I
think
that's
like
a
an
important
concern
because
it's
like
we
run
our
infrastructure
right.
So
it's
like
as
long
as
this
isn't
hurting
the
performance
of
the
application
greatly
like
we're
going
to
pay
for
it
somewhere
right
and
if
it's
cheaper,
to
pay
for
it
in
the
application,
then
it
makes
sense.
B
D
Are
there
I
was
looking
at
labels
as
a
way
to
sort
of
communicate
states
of
things.
D
I
don't
know
that
there
exists
one,
and
I
don't
I
wouldn't
want
to
open
the
bike,
shed
paint
discussion
about
what
labels
ought
to
be
there,
but
planting
the
seed
for
maybe
a
future
discussion
about.
Are
there
way?
Are
there
things
that
we
can
communicate
about
the
state
of
issues
and
prs
through
labels
that
don't
make
us
hate
ourselves
later.
B
I
I
don't
have
really
strong
opinions
there.
I
think
that,
like
airing
to
the
side
of
sharing
more
easily
like
with
a
state
of
something,
is
good
so
yeah,
I'm
not
against
that.
D
C
I
was
going
to
quickly
ask:
is
this
non-recording
span
behavior?
Is
this
the
default
behavior
pin
in
the
ruby
sdk,
or
is
this
a
shopify
add-on.
B
B
So
it's
not
perfect,
the
other
implication
being
we
have
that
helper
utility
for
untraced
spans-
and
I
think
it
just
like
entirely-
doesn't
work
with
this
because
it's
like,
oh,
I
just
inherit
the
parents,
bad
or
whatever
I'm
gonna
still
create
myself
like.
I
don't
care
right,
so
there
is
some
some
implications
there,
but
yes,
it
is
an
internal
thing.
It's
not
too
heavyweight.
B
I
don't
know
if
it
makes
sense
to
upstream
it,
but
right
now
it
just
lives
like
in
our
little
hello
world,
so
it's
only
actually
being
used
on
two
applications
but
they're,
two
larger
high
voltage
volume
applications.
So
it's
fairly
battle
tested
at
this
point.
B
Yeah
I'll
talk
to
francis
and
see
if
we're
thinks
we're
clear
to
share
that.
D
Well,
it's
a
it's
another
step
farther
away.
There's
the
like!
Okay,
you
don't
like
the
auto
instrumentation
here
you
could
write.
You
could
don't
turn
it
on
to
write
your
own
and
now
we're
into
like.
You
don't
want
to
trace
everything,
but
you
don't
you're,
like
you
can
sub
in
a
new
hacked
tracer
provider.
A
B
D
B
A
C
C
Patch
things,
but
like
the
poor
gophers,
like
they're,
they're
kind
of
out
of
luck
if
they
want
this
behavior
or
have
to
kind
of
maintain
their
own
fork.
So
I
don't
know
I'm
just
talking
that
in
the
back
of
my
mind,
because
I
think
it
is
useful
to
be
able
to
have
like
a
sampled
but
a
sampler
approach
to
being
able
to
drop,
noisy
or
useless
fans
yeah.
I
agree.
I
think.
B
The
the
more
I
spent
time
with
open
telemetry,
I
think
initially
like
I
was.
I
definitely
had
that
kind
of
inclination
just
be
like
I'll,
just
change
all
the
instrumentations
to
fit
the
needs,
but
more
and
more
I'm
seeing
like
it
feels
like
it
makes
a
lot
more
sense
to
lean
into
the
samplers.
B
But
again
some
cases
require
some
special
patches
and
yeah.
It's
not
necessarily.
I
don't
know
if
the
right
word
is
like
fair
to
tell
other
people
that
yeah,
like
don't
do
this
instrumentation
change,
you
go.
You
make
yourself
a
sampler,
because
this
is
my
full-time
job.
It's
not
necessarily
they're
sort
of
spending
time
to
get
familiar
with.
It
isn't
necessarily
a
reasonable
expectation
unless
you
provide
really
great
documentation
and
starting
points
for
them.
D
Well,
I'm
intrigued
to
see
it
if
it's
something
that
can
be
shared,
because
maybe
that's
another
thing.
We
start.
D
B
B
It
seems
a
lot
more
reasonable
than
what's
in
the
spec
right
now,
because
it
without
it,
it
really
really
puts
sampling
at
a
disadvantage
because
it
just
means
you
have
like
weird
broken
traces
if
you're
doing
internal
trace
like
if
you
want
to
sample
any
span
within
a
trace
out.
B
Right
exactly
so
again,
that's
like
for
me
it
just
I
don't
know
it
seems
weird
like
I,
I
think
at
the
end
of
the
day,
like
a
trace
like
at
its
minimum
needs
to
have
all
the
service
boundaries
like
the
ins
and
outs,
your
your
all,
your
https
fans
need
to
be
there.
So
if
you
drop
some
higher
level
span,
that's
really
noisy,
but
you
still
want
to
see
the
client
calls.
B
E
I'll
talk
to
you
all
later
all
right
see
you
next
week.