►
From YouTube: 2022-07-26 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
Oh,
what's
the
weather
out
there
and
where
are
you
you're
in
wrigleyville
or
where
are
you.
A
Technically
boys,
town
but
wrigleyville
is
like
two
blocks
over,
maybe
they're,
very
close
together,
the
weather's
great.
Actually,
it's
like
71
in
sunny
and
yeah.
It's
really
nice.
Actually,
it's
pretty
rare
that
we
actually
get
whether
that's
nice.
A
Enjoy,
like
the
you
know,
four
weeks
of
nice
summer
that
we
actually
get
throughout
the
year.
B
Yeah
right
somewhere,
I
was
thinking
to
go
into
schools
in
like
boston,
but
you
know
in
like
high
school
and
I
had
a
teacher
and
they
were
like
well
like
if
you
want
to
visit
like
boston
as
a
college
town
like
just
remember
that,
like
it's
mostly
covered
in
snow,
so
like
don't
visit
in
the
summer
or
you'll,
be
surprised
like
that.
That's
right!
What
are
you?
A
B
A
B
I
was
thinking
that
my
my
wife's
boss
is
the
owner
of
the
bets.
Actually,
so
she
works
for
the
finance
group
that
opens
the
bets.
So
she
like
one
of
her
coworkers
like
their
office,
is
like
city
field.
It's
like
sometimes
I'll
call
it
like.
Oh
yeah.
Sorry,
research
is
bad.
I'm
in
like
a
box
in
city
field,.
B
Well,
that's
actually
unironically,
that's
how
we
met
it
used
to
be
like
back
in
the
day
you
couldn't
give
away.
You
literally
couldn't
give
away
mets
tickets.
They
were
so
bad
and
they
had
like
a
box,
and
so
she
used
to
just
be
like
yeah.
If
anyone
wants
to
come
like
we
have
30
seats,
I'm
like
yeah
I'll,
come
free
food
and
then,
like
that's,
that's
how
we
met.
Actually,
it
was
me
being
like
shake
shack.
Unlimited,
shake
shack
burgers.
This
is
awesome,
like
I
guess
I'll
talk
to
you
while
I'm
here.
B
A
D
B
Let's
see
if
he
isn't
no,
nothing
in
the
slack.
I
see.
If
he's
online
he's
not
logged
in
like
his
on
it
doesn't
appear
to
be
on,
but
not
many
people
have
the
cncf
slack
open.
A
B
B
C
D
C
Oh,
there
was
a
turnout
yesterday
last
week,
new
folks,
whose
misha
was
there.
D
C
This
hundred-year-old
chihuahua
abomination
with
two
teeth:
all
right,
so
they
go.
There
goes
to
show
like
either
what
is
I'm
not
acclimated
still
to
like
jet
lag,
but
I
swear
to
god.
I
thought
adorable
doggo
was
like
a
startup,
so
there
you
go.
That's.
B
B
I
I'm
fine
to
get
started.
I
didn't
attend
the
maintainers,
the
spec
sig.
So
oh
and
I
forgot
to
include
that.
B
B
A
B
Great
here
we
are,
it's
7
26
8
a.m,
pacific
time,
so
the
first
thing
was
looks
like
otlp
partial
success,
and
what
did
they
change
with
that?
Because
that
was
murderously.
B
I
haven't
been
following
this.
This
is
definitely
something
we
probably
need
to
make
an.
I
think
we
made
an
issue
last
week,
but
probably
something
we
have
to
implement
at
some
point.
A
I
agree,
we'll
probably
have
to
do
it
once
it's
merged,
but
that's
all
right.
B
So
yeah,
okay,
yeah,
it's
a
quick
thing,
so
moving
along,
looks
like
they
wanted
to
they
trimmed
down
some
of
the
http
spam
semantic
conventions.
B
B
B
Oh
gosh,
so
now,
okay,
so
I
don't
know
we
can
do
like
a.
We
could
do
a
survey
of
our
own
instrumentation
and
see
if
there's
stuff
that
we're
now
in
violation
of,
but
I
don't
yeah-
these
are
sort
of
like
not
particularly
popular.
I
don't
really
see
an
http
server
name
in
our
stuff.
B
So
and
they're
making
some
of
this
optional.
Okay,
I
don't
know
it
sounds
like
I
think
this
piggy
backs
off,
maybe
what
robert
and
I
were
discussing
a
little
bit
last
week
with
like
making
1.0
some
instrumentation,
where
it's
like
you
want
to
be
able
to
depend
on
certain
attributes
coming
from
your
clients
and
servers
and
stuff.
So
I
think
this
is
good
and
then
it
sort
of
scopes.
You
know
it
gives
you
a
for
a
clearer
set
of
what
those
should
be.
B
Oh,
it
looks
like
they
want
to
start
to
push
for
ga.
On
the
metrics
specification.
That's
cool,
they're
kicking
the
can
on
exponential
bucket
histograms.
B
I
you
know,
I
don't
have
to
anything
intelligent
to
say
about
metrics
work.
Has
anyone
else
have
seen
this
or
thoughts
on
it.
D
A
B
I
wish
you
way
more
than
luck,
cool
yeah,
I
think,
sounds
good.
It's
nice
to
see
them
chugging
along.
I
vaguely
recall
this
being
something
they
wanted
to
ga
in
like
2021,
so
I
don't
know
or
like
earlier
this
year,
yeah
so
nice
him
getting
to
it
all
right.
I
don't
know.
That's
and
so
concludes
eric's
recap
of
the
the
spec
stick.
B
Now
we
have
the
the
stuff
that
actually
impacts
us
some
issues.
Pr's.
I
see
a
couple
things
on
here.
B
C
What
I
was
saying
to
myself
before
I
unmuted
the
mic
was:
I
need
to
unmute
my
mic
first,
but
my
hands
were
up
so
there's
been,
you
know,
we've
had
a
lot
of
discussion
around
sampling
and
disabling
traces
and
adding
hooks
or
instrumentations
and
whatnot,
and
I
kind
of
maybe
those
two
things
are
separate,
but
I
kind
of
wanted
to
revisit
like
this,
the
the
guidance
that
we
want
to
provide
people,
for
you
know
suppressing
traces.
C
I
guess
right
the
untraced
functionality,
because,
right
now
you
know
we're
you
know
we
see
some
some
pr
recently
got
open
for
nhtp
to
essentially
say
like
these
are
there's
some
attribute
that
I
want
to
be
able,
like
untraced,
hosts,
for
example,
right
as
being
something
that
we
don't
want
to.
We
want
to
suppress
the
traces
for
those
right.
The
suggestion
you
had
made
robert
was
you
know,
perhaps
adding
a
custom
sampler,
so
something
I
wanted
to
bring
up
was.
C
C
You
know
we
don't
have
the
notion
of
like
a
client,
sdk
and
I've
complained
about
this
before,
but
we
don't
have
the
same
model
of
a
processor
pipeline
in
the
in
the
client
sdk,
which
I
think
we
should,
and
so
I
don't
know
if
this
has
been
brought
up
before
or
discussed
or
or
pushed
on,
to
try
to
make
a
change
to
the
client
spec
for
the
sdk
to
say
these
things
should
have
a
symmetric
architecture.
D
Yeah,
I
think
it's
it's
tricky.
I'm
I'm
actually
very
conflicted
on
this
pr,
because,
on
the
one
hand,
we've
done
this
exact
thing
in
other
instrumentation
libraries
like
rap,
so
like
there's
kind
of
the
kind
of
hypocritical
aspect
of
it
it's
like
well,
we
did
it
when
we
needed
it
and
now
they
need
it
and
we're
going
to
push
back
on
it.
D
It
feels
doesn't
feel
good,
but
at
the
same
time
since,
because
I
think
I
originally
added
some
or
all
the
entrees
stuff
to
rack
I've
learned
more
since
then-
and
I
have
been
coming
around
to
it
so
like
when
I
was
attending
the
instrumentation
sigs
more
regularly.
D
That
was
kind
of
the
common
answer
to
like
people
talking
about
like
how
do
we
kind
of
omit
specific
spans
from
certain
pieces
of
instrumentation?
It's
like
well,
that's
what
the
sampler
is
for
right,
like
the
idea
that
you
can
do
this,
but,
like
you
stated
with
like
some
attributes,
aren't
present
until
after
the
thing
happens.
But
even
then
I
don't
see
a
lot
of
instrumentation
that
we
have
like
that,
because
if
you
need
some
information
after
the
request
is
complete.
D
C
You
can
correct
me
it's
wrong,
I
don't
know
so,
let's
say
so
sorry,
you're
saying
that
the
span
is
started
after
because,
when
we're
using
the
nspam
block
and
we're
wrapping
an
http
call,
the
response
occurs,
and
then
we
grab
the
response,
attributes
and
say
put
the
http
status
on
it.
But
if
I
wanted
my
sampling
decision
to
say
I
want
to
drop
anything,
that's
400
range
or
I
want
to
include
everything.
That's
500
range.
C
Always
you
can't
do
that,
because,
if
you're
using
the
in-span
helper,
so
that's
one
example
of
what
that
would
be
like
and
also
like.
If
you
were
doing
something
where
you
were
doing
some
sort
of
like
like,
for
example,
in
trilogy
right,
we
have
like
a
logical
database
name
that
gets
resolved
like
we
have
like
a
logical
cluster
name
that
gets
resolved
to
an
actual
database
host,
and
that
happens
later
on.
C
We
wouldn't
be
able
to
say,
like
I
want
to
filter
on
all
these
specific
database
hosts
only
like
a
specific
cluster
that
I'm
interested
in
or
if
you
wanted
to
use
like,
or
the
http
route
attribute.
C
Also
the
case
right.
The
the
action
pack
his
result
was
using
recognized
route
to
generating
the
route
after
the
span
has
been
created,
so
those
are
at
least
those
are
at
least
three
cases
I
can
think
of
that
today
would
be
useful
for
me
to
be
able
to
filter
those
out.
The
only
way
I
can
do
that
is
now
through
a
collector's
side,
spam,
processor
or
filter
processor.
D
Yeah,
the
ins
like
the
structure
of
the
instrumentation
would
have
to
change
just
to
to
support
that
to
begin
with
so
like
I
don't
know
if
we
want
to
rope
that
into
this
like
pr,
because
this
vr
is
like
the
upfront
position
right
and
so
like
the
upfront
decision
can
be
handled
by
the
sampler.
So
like
kind
of
outline
it
in
my
comment
there,
but
it's
like
one
of
the
benefits
here
is
like
this
no
longer
becomes
an
instrumentation
change
and
it
applies
to
all
your
http.
C
Libraries
right
you
well
you'd
have
to
want
to
do
something.
That's
a
map
right,
so
you
might
want
to
say,
like
I
don't
want
to
trace
like
these
attributes,
don't
necessarily
correspond
to
everything
right,
so
you
might
want
to
say
like
for
net
http,
here's
the
untraced
host
or
for
all
instrumentation
scopes.
C
C
That
gives
us
a
closer
experience
to
what
the
pipeline
would
and
then,
if
we
start
looking
at
our
current
instrumentations
and
move
away
from
using
the
inspan
helper
and
constructing
the
spans
at
the
very
end,
then
we
increase
the
likelihood
that
we'll
have
all
of
the
necessary
attributes
amended
to
the
span
when
the
span
is
started.
B
B
B
Yeah,
I
tend
to
agree
that
you
know
I
think
and
matt's
brought
this
up
historic
previously
number
times
sort
of
what
robert's
saying
which
is
like
it
just
starts
to
spiral.
When
you
have
these
like
instrumentation
cut,
you
know
like
I
almost
would.
Rather
all
the
complexity
live
in
a
sampler
and
the
sampler
is
just
you
know
is
bro
is
able
to
you
know
at
least
it's
isolated
to
the
one
class.
B
But
yeah,
I
think
the
sampler.
I
think
it's
like
we're
getting
to
a
point
where
the
current
design
of
the
sampler
and
the
processing
pipeline
or
whatever
is
sort
of
like
a
little
bit
behind
the
actual
use
cases.
People
are
using
and
the
work
hasn't
been
done
by
the
broader
upstream
community.
Maybe
that's
partially
our
fault
as
well,
because
we
haven't
pushed
you
know
that
that
is
hard.
It's
hard
to
to
champion
those
things
to
improve
some
of
these.
B
You
know
these
areas
where
you
can
make
sampling
or
filtering
decisions,
and
so
you
know
people
are,
but
people
still
need
to
write,
instrumentation
and
get
this
stuff
done
so
they're
fun
you
know
like,
and
so
in
some
languages
it
feels
like
they're,
finding
ways
to
to
shove
it
into
a
config
option
and
others.
B
B
I
don't
think
I
guess
I
should
review
this
more
like
closely.
I
haven't
looked
at
this
pr
until
just
now
I
don't
have.
I
don't
have
a
strong
decision
on
whether
or
not
to
take
the
pr
it
feels
it
just
feels
like
a
we're
continuing
to
hit
this
thing
right.
People
are
coming
up
with
like
creative
and
useful
conflict
options,
but
they
technically
like
don't
really
shouldn't,
really
live
on,
like
a
random
instrumentation
libraries,
random
configuration.
C
C
C
I
think
also
like
it's
like
we.
If
we
can
minimize
the
amount
of
code
we're
back
to
minimizing
the
amount
of
code
that
people
have
to
write,
because
if
everybody
has
to
re-register
like,
if
everybody
has
to
write
these
customizations
to
all
the
instrumentations
all
the
time,
and
especially
if
it's
got
to
be
like
executable
things,
we
want
to
move,
we
don't
want.
We
want
to
move
away
from
that
right.
We
want
to
have
that
experience,
be
streamlined.
B
D
Yeah
yeah,
like
the
whiteboard,
is
still
just
not
super
clear.
I
think,
unfortunately,
like
johnny's
been
contributing
and
using
open.
Telemetry
sounds
like
the
get-go
right,
and
I
think
that
should
carry
some
weight
in
itself,
because
this
isn't
like
a
new
user.
D
Someone
who's
been
kind
of
working
with
it
for
a
while
and
kind
of
is
using
it
very
I'm
assuming
pragmatically
right
like
so
for
them,
they're
like
they
don't
want
to
deal
with
nesting
samplers
right,
like
that's
one
of
the
comments
that
are
the
second
last
paragraph,
like
they
have
their
one
out
of
1000,
request
sampler,
and
so
they
have
to
put
the
two
together,
and
you
know
it
uses
like
the
word
like
the
language
clutch,
and
it's
like
for
that,
like
I'm
inferring
that
it's
just
like
it's
not
super
obvious,
or
maybe
even
clear
how
you
do
that
like
it
is
definitely
a
supported
use
case
right.
D
That's
how
you
have
like
parody-based
samplers
so
like
he
could
have
his
one
and
one
thousand
parent-based
sampler,
and
then
he
would
nest
this
custom
sampler
within
it.
That
says.
Okay,
if
you
do
decide
that
this
is
one
of
the
1000
winners,
we're
still
gonna
filter
out.
This
end
point
because
maybe
he's
got
like
an
error,
reporting
tool
or
something
like
that.
D
That's
constantly
just
like
hanging
updates
out
to
an
external
service,
and
it's
just
like
probably
eating
too
into
his
like
telemetry
costs
right
because
it's
just
no,
it
isn't
he's
not
it's
not
actionable
feedback
right
like
this
is
a
kind
of
inferring,
but
I'm
also
like
sharing
some
of
the
insights
I've
picked
up
while
like
internally
people
are
like.
I
don't
want
to
know
about
this.
This
perpetual
update
that
we're
picking
out
it's
just
noise,
fair,
like
totally
fair
we'd
like
to
filter
that
out.
D
So
for
me,
it's
like
if
I
was
approaching
this
and
tackling
this
right
now,
I'm
like
well,
we've
got
a
fleet
of
services.
We
have
way
too
many
http
libraries.
D
I
don't
want
to
amend
all
of
them
and
configure
all
of
them,
but
I
do
have
the
means
of
tacking
in
a
sampling
rule
right
like
we
can
start
making
a
part
of
our
default
package
to
roll
out
replacing
the
default
sampler
with
the
custom
sampler
and
like
yeah,
you
have
to
write
a
class
and
then
somewhere
in
your
configuration,
you
have
to
say
tracer
provider,
dot,
sampler
equal
that
thing,
but
it
becomes
like
a
one-time
thing
and
then
you're
kind
of
done.
So
it's
probably
like.
D
I
don't
know
what
the
word
I
want
to
use
for
this,
but
it's
just
like
a
different
kind
of
perspectives
on
how
to
approach
these
and
like
the
cost
associated
with
them,
because
he
mentions
like
boilerplate
like
I
don't
want
to
have
to
add
all
the
spoiler
plate.
And
it's
like
that's
fine.
I
guess
it's
like
for
me
my
perspective.
I
don't
see
it
as
boilerplate.
D
B
D
C
C
That's
my
oh!
That's
the
only
course
of
action
that
I
have
right
now
for
me
if,
if
we
can
somehow
make
it
possible
for
them
to-
and
this
is
going
to
be
like
an
upstream
thing
right-
I
don't
know
if
this
is
an
old
tap
process
or
if
this
is
open
up
something
an
issue
for
discussion
in
the
spec.
But
it's
like
to
change
sdk
to
like
support.
C
You
know,
client-side
processor
pipelines.
I
don't
think
that's
unreasonable.
D
B
C
B
Yeah,
I
don't.
I
don't
hate
that
I
think
it's
not
a
bad,
it's
a
creative
use.
I
can
trip
to
be
honest,
like
I
don't
know
if
there's
prior
art
for
it
like
I'd,
be
curious,
if
it
wouldn't
surprise
me
if
other
languages
were
doing
it,
but
I
think
it's
like
a
perfectly
valid
thing
to
do
like
just
the
same
way.
There's
resource
detectors
and
contrib
like
why
can't
there
be
a
sampler,
I
guess
but
yeah
I
don't
know
it's.
B
I
don't
know
if
they,
I
don't
know
if
the
ergonomics
of
that
are
easy,
I'd
be
curious.
If
that
I
guess
he
did
propose
that
right.
That
was
the
thing
he
suggested
that.
B
Robertson
yeah,
like
I
think
it's
you
know,
I
would
prefer
that
over
yeah
going
around
because
it's
really
not
even
with
some
of
the
stuff
like
with
hosts
it's
not
even
that
it's
not
even
http.
It's
just
all
client
libraries
in
some
way
because,
like
you
know,.
C
B
So
yeah,
I
would
prefer
robert
suggestion
of
like
providing
kind
of
our
own
skeletony
sampler
thing
like
configurable
sampler
than
yeah
attempting
to
go
around
to
all
the
to
do.
Whack-A-Mole
with
all
the
instrumentations.
B
B
B
I
should
probably
write
some
stuff
down.
We
need
more
volunteers
on
this
project.
B
B
Thank
you
sampler.
Is
that
a
good
summary
meaning
toward
a
configurable
standpoint
that.
C
Missed
the
whole,
so
so
the
second
part
of
that
was
the
hooks
discussion.
Like
I
missed
the
whole
hooks
discussion.
I
know
it
was
like
we're
we're
talking
about
potentially
removing
rolling
back
the
hooks
on
some
of
the
client
libraries
for
the
request
and
response
hooks.
Is
that
still
something
that
people
are
like
wanting
to
do.
B
The
things
we
definitely
are
doing
are
not
accepting
a
pr
for
the
rack
hooks,
that's
a
firm
now.
I
think
we
closed
the
pr
for
it
and
the
contributors
said.
Okay,
that's
not
what
I
was
hoping
for,
but
no
worries
and
yeah.
There
was
some
discussion
on
reverting
client
books,
but
I
don't
believe
we
reached
consensus.
A
Okay,
I
think
I
think
our
discussion
around
that
landed,
mostly
on
hooks,
are
complicated
and
open
up
lots
of
doors
for
people
to
point
fingers
at
us.
When
we
didn't
really,
you
know
it's.
The
instrument
station's
always
going
to
carry
our
name
even
if
it's
a
hook,
that's
misbehaving
in
some
distro
or
something
and
yeah
just
felt
like
an
escape
hatch
that
could
be
problematic
in
the
future,
but
like
okay,
yeah.
A
No,
as
you
say,
I
think,
like
the
providing
like
the
sort
of
rules-based
sampler
that
we
were
talking
about
is
an
interesting
strategy,
because
there
clearly
is.
People
clearly
need
to
do
things
that
our
instrumentation
doesn't
provide
an
option
for,
and
they
sometimes
need
to
do
strange
things
and
that's:
okay.
It's
yeah!
I
like
the
idea
of
giving
them
sort
of
a
workable
extendable
example
that
they
can
use
like
do
it
themselves
or
something.
C
So
I
don't
you
know
personally,
I
don't
have
anything
against
the
the
hook,
processors
for
the
or
the
hook
lambdas
for
the
things
that
don't
have
an
execution
api,
and
I
don't
think
that
you
know
people
saying
like
I
don't
know.
That's
necessarily
the
case
that
people
are
gonna
attribute
this
problem
to
us
and
if
they
do,
then
we
will
say
no
like
it's
yeah.
It's
it's!
You
know
it's
not
us.
C
I
don't
know
how
how
pervasive
or
bad
that's
going
to
be,
and
the
only
reason
why
I
say
the
hook
ones
for
so
hook,
ones
for
things
that
aren't
faraday
and
aren't
rack
because
you
can
hook.
You
can
write
your
own
middleware
for
those
you
know,
but
for
net
http.
That
library
is
like
not
so
fun
to
work
with
and
it
doesn't
provide
those
capabilities.
C
B
It
does,
I
think,
it's
valid,
which
is
I
mean,
I
one
hand,
I
think
it's
a
bit
of
a
counter
factual
to
say,
like
this
will
result
in
people
misattributing
stuff
to
us
because
well
like
that
reality.
D
B
C
B
It
seems
reasonable
that
I
could,
but
that
it's
not
like,
we
can
point
to
an
issues
board
and
be
like
look.
37
of
these
issues
are
people,
so
I
think
that's
hard
and
we
have
to
trust
to
some
extent
like
people's
experience
to
say,
here's.
You
know
I've
seen
this
sort
of
thing
occur
in
the
past,
with
my
lived
experience
and
I'm
applying
that
lived
experience
to
this,
and
so
I
think
that's
reasonable,
but
yeah,
it
feels
it's
hard
to
just.
B
You
know
that
can
be
hard
to
explain
to
people,
especially
like
an
outside
community.
Just
saying:
hey,
just
trust
us.
B
This
is
bad,
so
I
think
that's
a
little
tough,
on
the
other
hand,
like
I
do
think
francis
had
a
good
way
of
summarizing
it,
which
is
like
it's
not
necessarily
our
responsibility
to
provide,
like
all
things,
to
all
people
like
infinite
configurability
or
whatever,
which
is
sort
of
like
what
hooks
like
that's
outside,
not
to
say
that
people
can't
provide
that,
but
that
isn't
necessarily
something
that
the
instrumentation
that
the
maintainers
maintain
whatever
is
in
scope
for
us
to
do.
B
B
You
know
like
install
separate
instrumentation
that
does
that
and-
and
you
know
own,
that
instrumentation
feels
like
not
the
most
friendly,
like
a
pretty
high
bar
to
ask
someone
to
do
who's
like
I
think
it's
totally
fine
for
to
say
some
up
and
coming
vendor
like
cool
like
well.
Maybe
you
should
own
your
own
instrumentation,
then
yeah.
A
I
mean
that
I
think
that's
true,
but
on
the
other
hand
like
in
ruby,
it
is
exceedingly
easy
to
monkey
patch
our
instrumentation
and
make
it
behave
the
way
you
want
not
that
I
mean
I
know,
there's
a
you
know:
people
are
always
mixed
on
whether
or
not
that's
a
good
idea,
but
it's
yeah.
You
know,
I
think
you
could
accomplish
the
same
thing
without
necessarily
publishing
all
of
your
own
gems
and
maintaining
them
yeah
yeah.
A
I
don't
know,
I
think,
a
lot
of
where
I
come
down
on.
It
is
just
the
more
places
we
give
people
to
run
arbitrary
code
in
the
context
of
a
of
a
request
or
of
a.
I
guess.
A
transaction
within
our
system
makes
it
more
complicated
for
us
to
maintain
down
the
line.
It's
a
very
poorly
worded
way
of
saying
that
I
guess
but
yeah
I
don't
know.
C
B
I
think
that's
right,
I
don't,
I
was
leaning,
you
know
originally
leaning
toward
allowing
hooks
just
because
I
you
know,
I
think,
there's
some.
You
know
you,
you
don't
have.
I
think
right
now
that
there's
a
real
user
there's
a
real
there's,
a
real
gap,
which
is
that
users
don't
have
access
to
most
client.
Spans
really
is,
and
it
can
be
weird
and
those
are
the
spans
that
often
are
the
noisiest
or
the
weirdest.
You
know
leak
the
most
pii
or
you
have
them
the
weirdest.
B
You
know
you're
hitting
the
stripe
end
point
and
you
want
to
treat
some
obscure
thing
in
an
obscure
way
like,
and
so
it's
just
you
know,
you
know
it's
kind
of
getting
and
so
right
now
there's
just
no
way
to
touch
those
spans,
and
so,
like
I
mean.
B
And
so
that's
really
why
the
only
thing
I'm
supportive
of
for
this
is
because
like
well.
If
people
are
really
getting
killed
on
those
spans,
then
I
want
to
be
able
to
give
them
a
way
to
solve
their
problems.
But
I
don't
know
I'm
fine,
like
someone
who's
right
now
marked
down
to
maintain
this
thing
for
the
rest
of
my
life.
B
I
have
no
problem
reducing
the
scope
of
what
I
what
I
have
to
maintain,
and
I
think
it
you
know,
and
I've
seen
and
you
know
for
what
it's
worth
in
my
lived
experience
when
I
was
a
data
dog
not
that
I've
been
there
in
a
year
or
so
we
there
was
a
hook
we
exposed
on
after
request
hook.
That's
similar
to
this,
and
the
real
issue
we
saw
is
that
users
would
blow
up
their
spam
names
and
make
them
almost
like
dynamic
and
then
at
the
end
of
the
month.
B
I'm
not
sure
if
anyone
in
the
world
has
ever
had
an
issue
with
their
data
dog
bill,
they
would
come
back
and
be
like
hey.
I
owe
you
a
million
dollars
because
I
accidentally
put
a
uuid
on
my
spam
name,
because
you
exposed
this
hook
and
now
I
blame
you
and
I'd
have
to
sit
there
and
be
like
okay,
my
bad,
but
you
do
still
owe
me
a
million
dollars
like
we
did
to
store
and
retain
those
fans.
So
not
a
million
dollars,
but
you
know
so
like
there
is
a
high
support.
A
Yeah,
there's
a
there's,
a
fine
line
to
walk
between
preventing
people
from
shooting
themselves
in
the
foot
and
also
then
treating
them
like
they're,
dumb
and
can't
do
anything
and
it's
kind
of
hard
to
strike
the
balance
sometimes
but
okay
yeah,
I
guess
like
from
my
perspective.
I
don't
feel
super
strongly
like
I've.
I've
said
some
opinions
here,
they're
around
it,
but
like
ultimately,
I'm
gonna
go
along
with
what
everyone
else
thinks
on
it.
D
That's
been
kind
of
forming
in
my
head
like
since,
like
this
kind
of
conversation
came
up,
and
just
even
over
the
last
few
minutes
when
listening
to
don't
talk,
is
that,
like
I
like
the
idea
of
us
moving
towards
a
direction
where,
as
they
form
more
more
concretely,
like
semantic
conventions,
exist
on
all
the
instrumentation,
the
officially
maintained
ones
by
us
look
very
very
close
to
these
formally
defined
ones,
but
somewhere
along
the
way.
D
We've
made
it
so
incredibly
trivial
to
say
instrument
and
http
library
that
if
a
vendor
comes
along
and
wants
to
augment
their
observability
experience,
they
can
just
have
their
own
vendor
version
of
the
same
instrumentation,
but
because,
like
we've,
created
such
lovely,
like
even
the
registry
and
the
base
and
the
instrumentation
generator,
like
the,
I
guess
like
being
familiar
with
it.
D
I'm
skewed
and
biased,
but
like
the
level
of
effort
to
just
like
get
up
and
running
and
have
your
own
kind
of
flavored,
http
instrumentation
isn't
actually
that
high
right
now,
if
you're
familiar
with
it,
it
would
be
nice
if
we
get
to
the
point
where
it's
like
trivial
to
like
run
a
command
and
it'll
scaffold,
the
gem
that
has
all
the
same
hooks
like
we
do
have
a
command
for
that.
But
it's
not
necessarily
obvious.
So
it's
like
then
again,
it's
like
well.
D
This
semantically
defined
http
instrumentation
that
is
offered
by
the
open,
telemetry
community.
It
doesn't
satisfy
my
use
case
so
I'll
run
this
one
command
and
I'll
vendor
it,
and
I'm
this
very
successful,
observability
vendor
and
I
can
add
the
twist
that
I
need
and
it
will
still
just
work
with
everybody
else's
instrumentation,
and
I
can
just
tack
it
on.
B
Rails
generators:
that's
what
I
think
the
answer
is
the
greatest,
the
greatest
invention
of
all
time:
yeah,
okay,
cool-
so
I
don't
know,
I
think
we're
leaning
toward
reverting.
B
No
one's
wants
to
die
on
the
hill
of
owning
hooks.
There
might
be
some
blow
back
or
people
not
happy,
but
we've
never
released
this.
So
we.
C
Should
yeah
we
should
talk
to?
We
should
reach
out
to
the
author
and
send
them
a
link
to
this
video
on
this
discussion,
perhaps
and
summarize
what
it
is
that
we
want
to
try
to
help
them
do,
because
we
shouldn't.
B
C
C
C
And
talking
about
the
race
car
instrumentation,
so
this
one
I
didn't
have
a
lot
of
time
to
look
at,
but
when
I
first
looked
at
it
I
was.
I
thought
it
was
interesting.
Let's
look
at
it
together.
B
C
So
the
one
thing
that
stands
out
to
me
is
the
fact
that
this
does
not
use
the
existing
hooks
that
are
available
in
race
car.
So,
let's
look
at
like
how
it
works
right
now.
I
think
it's
a
consumer
or
something
I
don't
know
a
runner
so
see
here.
It's
overriding
the
constructor
and
then
mixing
in
you
know
per
object.
Instance,
it's
it's
mixing
in
these
modules
that
are
on
the
side,
as
opposed
to
using
the
existing
notifications.
C
So
there's
like
two
a
couple
of
portions
of
those.
So
there's
like
the
notifications
hooks
as
well
as
the
there
are
some
other
classes
that
aren't
instrumented,
and
I
asked
this
question
and
I
think
what
chris
was
saying
was
that
he
doesn't
see
what's
actually
getting
executed
because
of
the
fact
that
it's
not
the
the
notification
hooks,
aren't
at
the
right
and
aren't
in
the
right
scope.
C
So
there's
this
instrumenter
right
and
this
only
works
if
it's
using
active
support
notifications.
So
that's
one
problem
is
the
sense
that
we
wouldn't
be
able
to
hook
in
instrumentation
to
it.
But
this
there's
this
back
end
instrument.
C
So
I
guess
part
of
me
was
wondering
like:
should
this
be
done
using
the
existing
race
car
instrumentations
and
using
our
active
support
notifications
worker
thing,
but
then
as
a
but
then
we
would
have
to
also
have
like
a
transform
payload
hook
so
that
we
can
get
it
massaged
into
the
appropriate
semantic
conventions
for
each
one
of
the
instrumentation
events.
C
But
things
aren't
instrumented
in
the
scope
that
chris
would
like.
I
think
that's
what
his
response
was.
I
didn't
dig
too
much
into
that
which
was.
C
It
was
quite
ugly,
he
said
or-
or
I
think
the
other
option
I
gave
him
was
why
not
decorate
process
or
process
batch.
For
example,
you
know,
but
he
was
talking
about
like
with
paws,
not
propagating
the
exceptions,
so
he
wouldn't
see,
like
the
exceptions
getting
recorded
in
this
block
right,
because
that
exception
gets
recorded
there
and
then
there's
an
additional
error
handler
that
occurs
so
it's
like.
A
C
C
B
We
actually
have
some
users
internally,
who
were
like
hey
where's.
My
race
car
span,
really
oh
good
question
but
yeah.
So
this
is
much
deeper
than
I
went
on
the
instrumentation.
I
generally,
you
know
I
am
down
to
use
asn.
I
think
it's
better
to
build
on
top
of
asm.
If
we
can.
C
It
would
it
would
it
would,
it
would
mean
requiring
asm
if
people
and
if
people
didn't
use
it,
that
would
be
troublesome.
D
A
C
B
C
B
C
B
My
cynical
opinion
is
we
maintain
this
instrumentation
datadog
had
very
relatively
low
uses.
No
just
never
didn't
get
complaints
about
it.
So
I'm
down
to
just
copy
pasta
that
whatever
that
approach
was
and
then
if
people
want
to
approve
it,
they
can
do
that.
But
you
know
like,
for
example,
ivo.
This
person
works.
B
I'm
not
just
quite
sure
why
he's
contributing
to
the
race
car
gym,
and
I
think
the
owners
of
this
gym
were
users
of
the
dd
trace
rb
package
themselves,
not
the
public
information
but
whatever
so
so,
yeah,
I'm
down
to
not
use
like
if,
if
we
think
using
asn
and
like
adding
our
error
handler
is
like
uncharted
territory
and
we
don't
have
a
ton
of
confidence
in
how
to
like
robustly
test
it.
B
C
B
That's
asm.
If
I
remember
correctly,
okay,
I
would
bet
dallas
donuts.
They
they
do
what
we
do
similar,
which
is
there's
this
base.
You
know
sort
of
like
a
skeleton,
asn,
okay,
you
know
instrumentation
and
then
you
sort
of
provide
your
own.
C
So
there
so
there's
a
subscription
for
the
race
car
event,
which
is
the
process
batch
and
so
on
and
so
forth.
I
see
process
batch
consume
batch
and
message
the
main
main
loop.
They
call
it.
I
guess
for
consumer
all
good,
don't
forget
to
tell
her
about
my
tickets
and
if
I
could
get
a
plane
ride
and
hotel
that'd
be
doop
doop.
B
Sorry,
I
don't,
I
missed
the
last
part.
Okay.
Well,
oh,
I
was
about
to
say,
like
you
have
a
link
yeah,
and
so,
if
we
hit
up
events,
you
can
see
all
the
they
don't
even
subscribe
to
batch.
Oh
no
process
patch-
and
you
know
it
gives
you
some
helpers
to
spare
options.
Okay,
I
mean.
B
Yeah,
I
guess
we
need
to
figure
out.
The
error
thing
sounds
like
it
might
just
not
be
handled
properly
right
now
in
the
current
apache
dude.
You
know
like
I
don't
think
the
same
way
that
just
because
other
sigs
are
doing
stuff
with
their
instrumentation
and
open
telemetry.
We
shouldn't
just
do
stuff,
because
some
instrumentation
from
four
years
ago
and
datadog
is
doing
it.
That's
not
a
justification,
but
it's
a
path
of
least
resistance.
Often
okay,
I
don't
have.
I
guess
I
think
we
need
to
investigate
the.
B
It
sounds
like
the
blocker
here.
That
is
the
error
stuff
like.
That
is
a
reason,
a
pretty
strong
reason
not
to
rely
on
active
support.
Note
this
approach.
If
you
can't
capture
errors,
it
makes
the
instrumentation
close
to
you.
You
know
close
to
useless,
usually
that's
the
stuff
people
want
to
trace.
So
I
think.
B
C
B
I
will
volunteer
to
investigate
this.
I
think
I
need
to
I
assign
myself
the
review.
I
need
to
prove
out
the
stuff
we're
talking
about
here
and
figure
out.
I
think
the
approacher
laying
out
makes
sense
to
me
if
we
can
do
that,
which
is
like
just
hook
into
that
on
error
hook,
if
possible
and
then
rely
on
asn.
I
think
that
reduces
the
scope
of
our
instrumentation,
because
it's
like.
C
B
Yeah
that
seems
like
in
any
pattern
and
yeah.
I
don't
know
in
general,
like
if
people
like,
in
my
view,
with
a
lot
of
like
if
gems
are
including
instrumentations,
like
that's,
probably
going
to
be
something
that
we
can
more
concretely
more
confidently
build
on
top
of
than
like
the
dolly
approach
of
like,
let's,
let's,
let's
monkey
path,
random
methods
and
hope
they
don't
break.
When
the
the
author
has
a
weekend,
binge
do
a
major
upgrade
or
whatever
like
so
I
don't
know.
Okay,
I
mean
good
discussion.