►
From YouTube: 2021-03-23 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).
B
Hi,
this
is
my
first
one,
so
I'm
kind
of
just
lurking.
A
Hey
welcome
rob,
is
it
pronounced,
rob.
A
A
That
is
like
ariel
valentine
yeah,
ariel,
very,
very
cool
man
rob
kids
stealing
from
a
goat.
I
love
it.
That's
like
the
best
intro
baby.
C
A
A
B
Go
run
perlman,
he
managed
to
nail
the
the
grumpiness
better.
I
think.
A
Hey
I'm
with
you,
hopefully.
A
Yeah,
I
hope
that
I
hope
folks
that
watch
these
videos
afterwards,
like
appreciate
the
banter
that
I
bring
the
group
so
just
to
give
you
a
little
heads
up.
This
is
your
first
one.
A
The
these
are
run
by
the
core
maintainers
and
that's
going
to
be
francis
robert,
oh
friend,
not
this
francis,
but
another
francis
francis
robert
matt
and
eric
right,
usually
the
ones
that
run
this
meeting,
but
the
rest
of
us
are
contributors.
So
we're
just
kind
of
hanging
out
and
enjoying
rob.
Tell
us
a
little
bit
about
yourself.
While
we
wait.
B
I'm
I
work
at
honeycomb.
I'd
been
doing
ruby
things
for
about
two
decades,
maybe
15
years
15
years.
A
Hey,
how
that
that's
pretty
awesome,
hey
matt,
just
doing
little
intros
here
this
rob
kid.
He
introduced
himself
from
honeycomb
and
francis,
although
it
does
not
work
for
honeycomb
really
likes
honeycombs.
It
seems
I
do
appreciate
that
background.
D
Yeah
awesome
to
see
you
here,
rob
I'm
matt.
I
work
for
lightstep.
I've
been
involved
in
some
way
in
open,
telemetry
ruby,
since
pretty
early
on
the
summer
started.
Anyways
yeah,
I
don't
know,
there's
too
much
else
to
say
I
I
often
try
to
run
these
meetings.
I
usually
do
a
pretty
terrible
job,
but
nobody
has
has
booted
me
from
this
just
yet.
E
C
F
F
G
Audio,
I
can
jump
in
the
meantime
yeah,
I'm
francis,
I
I'm
the
other
francis
I
work
for
shopify.
I
lead
our
distributed
tracing
efforts,
I'm
one
of
the
founding
members
of
open,
telemetry
ruby.
So
I've
been
working
on
this
for
a
little
while
yeah.
A
F
I'm
another
francis:
it's
super
we're
never
going
to
get
over
having
two
francis
in
the
saint
paul.
It's
super
weird
yeah,
I'm
an
independent
software
consultant
sort
of
just
like,
I
think,
is
pretty
interesting
and
I've
been
contributing
from
the
margins
for
a
little
while
now.
H
Yeah
we'll
see
if
it
works,
can
you
guys
hear
me
yep
wow,
that's
amazing,
hi,
I'm
rob.
I
work
at
shopify
work
with
francis.
I
don't
know
if
he's
introduced
himself,
I'm
assuming
yes
open
telemetry,
for
you
know
getting
close
to
a
year
now
about
a
year,
maybe
less
probably
less
than
what
else
to
say.
I
mainly
contribute
instrumentation
and
yeah
nice
to
meet.
You.
D
Cool,
so
let's
go
ahead
and
get
started
with
the
meeting
I'll
go
ahead
and
share
a
screen.
D
So
yeah
we
usually
start
off
these
meetings.
I'll
kind
of
just
recap:
the
specs
egg,
hopefully
in
less
time
than
the
specs
egg,
actually
takes
it's
the
meeting
that
occurs
before
this
one.
This
one
actually
went
short
for,
like
the
first
time
ever
or
first
time
in
a
real
long
time.
So
hopefully
the
the
recap
will
be
fairly
short.
D
D
D
D
Yeah,
I
I
retract
everything
about
z
pages
they
they
were
mentioned,
but
for
some
reason
I
did
not
see
it
in
the.
D
D
At
least
the
metrics
folder
makes
sense
to
some
somewhat
be
here
somehow,
but
I
see
the
argument
now
that
it's
not
quite
clear
like
what
what
these
things
are,
what
their
status
is
and
if
they're
even
being
worked
on.
So
I
think
that
was
the.
D
That
was
the
discussion.
It
looks
like
the
the
action
plan
is
to
try
to
get
rid
of
this
experimental
folder.
First,
I
guess
by
by
adding
a
status
the
thing
that's
there
and
then
based
on
that
status.
Try
it
try
to
clean
things
up,
and
then
I
guess
that
folder
will
end
up
being
empty
and
then
removed.
D
D
The
consensus
was
this
would
be
nice,
but
I
think
the
prevailing
opinion
was
it
would
take
some
time
to
would
take
some
time
to
kind
of
spec
those
defaults
out
and
agree
on
them.
So
if
somebody
wanted
to
do
the
work,
they
were
more
than
willing
to
kind
of
adopt
the
outcome.
G
D
We
have
shopify
has
a
maximum
back
off
time.
G
D
Yeah,
no,
that
it's
it's
a
good
joke.
I
was
taking
it
too
literally,
though
yeah
these
things
end
up,
yeah
getting
complex
pretty
quickly.
So
anyhow,
that's
that's
this.
So
the
last
thing
was:
it
appears
that
there's
some
ambiguity
in
spec,
but
I
think
we
we
at
least
cleared
this
up
at
the
spec
sig
meeting
and
the
title
doesn't
capture
everything
here.
D
Basically,
if
you,
if
in
your
current
contacts,
you
have
valid
baggage
and
you
are
extracting
attempting
to
extract
baggage
from
some
other
context,
it
seems
that
if
you
pair
up
the
facts
that
if
your
new
extract
either
failed
to
extract
baggage
or
extract
like
an
empty
baggage,
it
would
overwrite
the
existing
baggage,
and
I
think
that
this
is
an
undesirable
behavior.
D
So
yeah
this
this
was
the
takeaway.
If,
if
an
extraction
fails,
it
needs
to
not
touch
what
is
in
the
existing
context,
so
tyler
was
going
to
open
a
pr
just
to
kind
of
correct,
correct
the
spec
language
there.
D
I'm
not
sure
if
this
is
where
we
should
start.
If
we
should
start
with
our
issues
or
milestones,
any
suggestions.
G
D
Although
it
may
not
seem
like
it,
I
did
try
to
do
a
couple
things
during
the
past
week
to
figure
out
some
of
this
work
and
move
a
little
bit
forward.
One
of
them
was
getting
some
clarity
on
the
way
b3
should
be
configured
for
that
propagator's
pr.
G
Yeah,
I
saw
that
so
it
looks
like
we
always
extract
single
as
a
preference
and
then
fall
back
to
multi.
D
Yes,
yep
and
yeah.
I
think
that
that
should
make
things
straightforward
way
more
straightforward
than
having
these
like
three
flavors
of
of
b3,
and
you
know
having
almost
every
like
permutation
covered,
because
it
really
didn't
make
sense
yeah.
So
I'm
starting
on
that
refactor
at
the
moment,
so
cool
so.
C
I'm
implementing
the
feedback
from
the
zipkin
for
the
zipping
pr.
I
broke
a
bunch
of
tests
by
by
just
yellow
merging
things,
so
I'm
just
cleaning
up
the
tests
but
yeah.
That's
my
my
only
contribution.
D
Cool-
and
I
did
ask
I
did
ask
in
the
hotel
instrumentation
channel
just
if
any
other
sigs
were
instrumenting,
orms
and
like,
where
do
they
fall
in
the
realm
of
semantic
conventions,
and
java
has
instrumentation
for
hibernate
and
it
is
not
treated
as
as
they
did
as
the
spans
are
not
treated
as
database
fans
from
the
semantic
conventions.
I
think
the
assumption
is
that
the
underlying
database
adapter
will
be
instrumented
so.
D
D
Possibly
some
justification
for
doing
it
this
way,
but
it
seems
like
there's
been
at
least
some
feedback
from
from
rob
yeah.
I
guess
maybe
I
should
start
talking
about
this
one,
but.
B
H
I
guess
for
this
one:
it's
mostly
just:
there
was
like
some
discussion
on
it,
but
I
think
the
last
like
meeting
we
talked
over.
It
seems
like
everyone's
comfortable
with
this
approach
I
think
now
what's
left
is
like.
If
anyone
wants
to
actually
review
it,
I
do
still
have
to
make
it
part
of
the
rails
gem.
So
I
did
it
as
like
a
separate
one
and
I
think
I'll
probably
have
all
of
the
rails
sub-gems
as
their
own
instrumentation
packages.
H
I
think
that
makes
sense.
So
if
people
are
using
individual
ones,
we
can
still
have
instrumentation
for
that
rails
is
the
aggregator
I
think
rails
like
originally
that
gem.
I
just
wanted
to
do
everything
in
there,
but,
as
I
started
working
on
it,
it
makes
sense
to
split
up
that
way.
So
I
just
need
to
make
this
part
of
the
rails
stuff.
Then
the
question
kind
of
around
that
one
would
be.
We
have
the
instrumentation
all
packaged,
should
it
be
rails
and
then
have
active
record
on
its
own
like.
H
D
Yeah,
I
think
this
is
actually
worthy
of
a
quick
discussion
to
figure
out
like
should
this
all
bundle
under
the
rails,
or
does
it
make
sense
to
have
these
as
as
independent
gems?
I
guess
before
we
combine
them,
I
can
see
pros
and
cons
to
like
each
approach
like
as
far
as
active
record
goes.
D
Some
use
cases
where
people
will
pull
in
like
active
record
with
sinatra
and
really
not
use
rails,
but
as
long
as
as
long
as
our
rails
bundle
would
be
okay
with
this,
if
it
would
just
like
install
the
components
for
which
for
which
you
have
those
rails
rails,
gems,
you
know,
including
your
application.
D
I
could
see
that
being
fine.
I
don't
know
I'm.
E
E
That
way
is
I'm
pretty
sure
the
rails
instrumentation
today
does
a
little
bit
of
magic
with
the
rack
instrumentation
to
get
that
working
correctly,
and
so
I
would
like,
if
I
wanted
to
opt
out
and
we
didn't
have
everything
under
rails
and
I
installed
all
the
other
gems
manually.
I
would
then
also
have
to
duplicate
that
rack
magic
as
well,
which
is
just
a
little
annoying
but
not
horrible.
E
To
me,
it
feels
pretty
good
to
say,
like
I
want
to
instrument
rails,
and
I
do
not
want
active
record
or
I
do
not
want
active
job
or
like
some
other
piece
that
we
eventually
add
just
to
default
them
to
on,
and
let
me
say,
actually
turn
these
off,
if
I
think
they're
too
noisy
for
some
reason.
That's
my
two
cents,
though
I
I
think
like
both
approaches,
are
actually
valid
and
would
work
just
fine,
so
you
know,
whichever
way
I
think
everyone
else
wants
to
find
with
me.
H
Okay,
so
like,
I
think
that,
because
I
think
there's
gonna
be
some
that
I
don't
know,
I
don't
know
how
much
they
make
sense
their
own
like
for
rails.
When
I
started
with
like
the
requests
instrumentation
for,
like
the
controllers
to
me,
I've
never
heard
of
anyone
using
those
in
isolation.
It
seemed
weird
to
have
it
on
its
own,
but
I
have
heard
people
using
active
record
on
its
own,
so
that
made
sense.
I've
seen
projects
use
active
support
on
its
own
without
rails.
H
So
I
definitely
know
there's
a
use
case
there
to
the
point
of
being
able
to
disable
it
there's
actually
some.
I
don't
even
know
if
it's
documented,
but
there
is
some
magic
in
the
base
instrumentation
class,
where
there's
a
naming
convention
and
you
can
disable
any
instrumentation
class
with
the
right
environment
variable
or
if
you
pass
in
a
config
option
with
the
class
name
of
the
instrumentation,
you
just
say
enable
false.
H
So
even
if
it's
included
under
rails
or
not
or
if
it's
included
under
all,
it's
a
config
option
that
matches
to
that
name.
So
yeah,
there's,
there's
always
a
route
for
that.
So
I
think
I'll
make
active
record
as
a
dependency
of
the
rails
instrumentation
and
by
virtue
of
or
the
way
everything's
set
up,
it'll
just
install
it.
It
doesn't
need
any
magic
hook
there
to
actually
install
it
so
and
then
for
the
next
thing
that
happens
towards
rails.
E
F
And
my
two
sense
on
that
is
just
from
a
gem
perspective,
which
is
which
is
maybe
a
little
different
from
the
actual
conflict
perspective.
But
from
a
gem
perspective,
we
should
like
our
instrumentation
gems
should
mirror
the
structure
of
rails
gems
and
its
own
dependencies
right
rails
is
dependent
on
whatever
12
other
gems
are
rails.
Instrumentation
should
be
dependent
on
exactly
12
other
that
instrument
the
exact
same
components
in
the
end.
H
Yeah
that
yeah
sorry
that's
a
better
way
of
articulating
it.
That's
the
that's
the
intention,
I'd
like
to
do
there
so
right
now.
That's
not
true
I'll
have
to
correct
that.
I'll,
be
honest.
It's
not
going
to
be
super
high
priority
right
now
to
extract
the
dispatch
stuff,
but
that
is
the
direction.
I
think
this
should
move.
C
Cool
yeah,
the
only
addition
here
I
can
add,
is
people
definitely
use
activerecord
outside
of
rails.
So
it's
good
to
have
some
path
toward
allowing
people
to
just
use
active
record,
but
I
think
wrapping
everything
under
rails
addresses
ninety
seven
point:
nine,
ninety
nine
percent
of
the
cases,
so
that
should
be
like
the
happy
path
in
terms
of
just
like
the
config
block,
cool.
H
Cool
then,
I
think
that,
oh,
that's,
like
really
left
on
this
pr
I'll
I'll
make
those
changes
to
make
it
a
dependency
of
the
rails
gem
as
well.
So
if
anyone
wants
to
come
through
and
review
it,
it's
not
too
complicated.
It's
just
a
lot
of
supers
wrapped
in
a
spam,
but
if
anybody
wants
to
pull
it
into
a
demo
project,
they
have
locally
to
take
a
look
and
say:
actually
you
know
what
this
isn't:
okay
or
something's
wrong
here.
E
I
have
to
test
some
things
on
one
of
my
internal
rails
apps
today,
so
I
will
pull
it
in
and
test
it
and
give
you
some.
D
D
If
move
on,
is
there
something
else
worth
talking
about.
G
I
think
we
should
probably
close
the
instrument-
google
api's
core,
because
robert's
actually
doing
that
in
the
upstream
repo.
So.
H
Yeah,
so
I
have
a
pull
request
now.
I
actually
had
two
I
closed
one
by
accident,
but
I
do
have
a
pr
against
that
to
actually
instrument
it.
As
for
sport,
instrumentation
we've
we
discussed
this
a
few
weeks
ago,
but
I'm
doing
a
second
one
on
an
internal
gem
inside
shopify
and
the
more
I'm
working
with
it.
I
really
actually
like
us
using
the
instrumentation
based
class.
I
find
it
makes
it
really
simple.
H
A
change
was
merged
in
this
week.
That
makes
the
default
so
before
your
base
class
would
give
you
a
nail
for
the
tracer.
If
the
instrumentation
install
hook
wasn't
called
so
you've
changed
that
now,
so
you
get
a
no-op
tracer.
So
for
anybody
who's
doing
first
part
instrumentation.
They
don't
have
to
do
a
bunch
of
conditional
checks
to
see
if
the
instrumentation
is
actually
installed.
H
You
can
just
comfortably
reference
the
instrumentation
instance
tracer,
and
if
it's
not
installed
it'll
just
know
off,
and
if
it's
there
it'll
just
work
and
I'm
finding
it
really
really
simple
to
actually
add
first-party
instrumentation
using
our
base
instrumentation
class,
which
is
really
great.
H
D
Cool,
so
so
this
is
going
in
as
as
first
party
and
and
everything
seems
seems
to
be
working
out
well,
using
our
just
subclassing
instrumentation
base
there.
So
great,
I
guess,
should
I
go
ahead
and
make
a
comment
to
this
effect
and
close
this.
H
Yeah
yeah
go
ahead
and
close
it
in
the
art,
the
the
slack.
I
just
dropped
the
link
to
the
pr.
If
anybody
curious
of
what
it
actually
looks
like.
D
All
right,
so
I
know
we
have
propagators
which
you're
working
on
francis
and
then
baggage
they're,
both
kind
of
like
they're.
Both
they
both
overlap
in
some
way
is
there
a
preferred
way,
preferred
yeah,
preferred
strategy
to
try
to
integrate.
G
These,
I
don't
know
whoever
gets
theirs
in
first
wins.
I
guess
right.
The
other
person
has
to
do
the
the
merge.
That's
fine!
I
think
if
we
can
get
your
baggage
refactor
in
that's
probably
closer
to
done
than
my
propagator
refactor,
we
also
have
the
x-ray
propagator
implementation.
G
I
owe
a
another
review
on
that.
I
guess
I'm
a
weak
overdue
on
that,
so
that's
likely
to
go
in
pretty
soon
as
well,
and
that's
using
the
old
like
separate
extractor
injector
thing
so
once
that
goes
in
I'll
also
need
to
update
my
pr
to
take
that
into
account.
G
D
All
right,
that
makes
sense.
I
think
I've
addressed
the
outstanding
feedback
here.
So
if
there
is
more
feedback,
please
get
it
in.
G
D
Yeah,
I
was
going
to
say
that
it
looks
like
this
needs
some
some
eyes.
E
Yes,
very
much
so
eyes
and
testing
if
anyone
else
has
postgresql,
I
can't
it's
actually
kind
of
hard
for
me
to
test
it
internally
here,
because
we
only
have
one
thing
that
uses
postgres.
That's
it,
but
one
of
the
things
I
wanted
to
ask
about.
I
noticed,
while
I
was
instrumenting
it
that
rails
will
aggressively,
prepare
and
execute
statements
when
you're
using
postgres,
because
it
can-
which
is
great
and
without
a
cache
of
prepared
statements
it
made
the
instrumentation
really
felt
very
useless.
E
E
The
lru
cache
that
I
picked
seems
pretty
widely
used.
I
also
think
it's
entirely
possible
to
do
without
it
we're
not
using
enough
of
it
to
where
we
couldn't
reimplement
a
little
bit
ourselves
in
just
plain
old
ruby.
So
I
wanted
to
get
a
little
bit
of
direction
from
people
here
and
see
what
we
thought,
because
if
you
think
we
should
avoid
that
dependency,
then
I
can
do
that.
H
My
gut
reaction
is
not
having
the
dependency
is
probably
better.
Just
because
of
I
can't
I
just
appreciate
like
having
dealt
with
a
lot
of
dependencies
and
maintaining
them
and
all
the
nightmares
that
come
with
that,
especially
like
for
the
context
of
shopify,
where
a
lot
of
these
teams
don't
necessarily
have
a
lot
of
say
in
it.
We
just
say
you
have
tracing
on
your
application
and
then
they
get
a
bunch
of
dependencies
with
it.
H
So
less
is
more
in
that
case,
but
that
being
said,
we're
not
using
postgres
at
shopify.
So
like
there,
there
is,
or
not
to
my
knowledge.
Maybe
they
are.
I
have
no
idea.
I
haven't
seen
it,
but
personally
for
like
side,
projects
and
stuff
like
that.
H
I
do
use
it
and
I
can
try
to
spin
up
some
sort
of
thing
on,
like
my
personal
machine,
to
try
to
test
this
to
see
what
it
looks
like
with
and
without
it,
because,
like
you
said
it
without
it,
it
didn't
feel
right
so
or
it
didn't
look
right.
So
I'd
have
to
try
to
take
a
look
and
see
if
I
can
maybe
set
aside
some
time
on
the
weekend,
for
that.
You
know
because
I'll
have
to
like
actually
get
postgres
going
somewhere.
A
I
was
excited
andrew.
Actually,
we
didn't
talk
about
this
yet
so
that
would.
A
Cool
that
you
worked
on
this
the
what
about
prior
art
for
is
there
anything
already
done
for
auto
instrumentation
for
java,
oh
c-sharp,
I
don't.
E
Know
that's
a
good
question.
I
copied
a
little
bit
of
this
actually
from
a
stalled
datadog,
auto
instrumentation
pr
for
ruby.
I
haven't
looked
much
for
any
other
language.
I
didn't
go
looking
for
other
languages,
primarily
because
they're
not
going
to
be
we're.
You
know
we're
wrapping
a
specific
to
ruby
gem.
You
know
I'm
not
hooking
into
anything
in
postgres
to
do
the
instrumentation,
so
I
felt
like
other
languages.
A
Or
if
they're
running
into
this
problem
at
all
right,
yeah
they're,
generating
prepared
statements,
I
would
assume
that
hibernate
would
do
that
and
I'm
curious
what
rob
and
eric's
experience
has
been
working
with
instrumenting
at
their
company
respective
companies.
C
E
It's
not,
I
mean
the
the
the
lru
caches
that
most
people
use
in
ruby
nowadays
work
on
the
fact
that
since
3b19,
key
insertion
is
ordered,
so
you
can
very
very
easily
implement
it,
and
so
I
did
it
just
because
I
have
a
tendency
to
breed
new
bugs
whenever
I
re-implement
things
and
I
didn't
want
to.
But
it's
I
think
this
is
trivial
enough-
that
I
can
just
drop
the
dependency
and
do
it
ourselves,
possibly
even
as
a
something
in
open,
telemetry
core
that
we
can
reuse
elsewhere.
C
Yeah,
I
don't
have
strong
one
or
not
a
maintainer,
so
there's
some
maintenance
burden
that
comes
with
adding
dependency
and
and
the
fun.
And
so
you
know
it's
not
really
my
call
but
yeah
vendoring.
I
don't
know,
I
think
one
we'll
probably
have
to
do
it
with
metrics
anyway,
with
some
stuff
right.
We're
gonna
have
some
gems
that
do
statsd
or
prometheus,
or
I
don't
know
and
yeah,
but
you
know
it
sounds
sounds
like
I'm
sorry
not
to
keep
rambling.
C
The
only
other
thing
I
would
say
is
like
should
you
know,
maybe,
let's
think
about
whether
this
is
something
that
is
how
to
add
it
to
the
span
like
whether
it
should
actually
get
added
to
the
span
if
it
should
get
added
as
a
span
event
or
as
a
tribute
or
you
know,
I
don't
know,
maybe
that's
also
worth
figuring
out
before
you
go
down
the
rabbit
hole
of
doing
all
this
work,
to
add
it,
but
sounds
useful
and
for
sure,
more
and
more.
B
About
all,
I
could
add,
would
be
the
origin
of
my
question
on
the
active
record.
Pr
was
that
our
instrumentation
for
figuring
out
what
the
database
is
doing
is
the
active
support
notification
subscription
to
sql
active
record
events.
B
The
most
recent
trip
in
there
is
that,
if
you're
not
using
prepared
statements,
you
don't
get
very
easily
obfuscated
sql.
You
have
to
do
all
sorts
of
shenanigans,
no
actually.
B
E
B
E
No
problem,
I
think
francis
actually
mentioned
we
should
reach
out
to
new
relic
and
see
if
they'd
be
willing
to
donate
their
obfuscation
code
to
our
project,
so
that
we
can.
That
would
be.
That
would
be
dope.
G
C
A
C
Save
michael's
in
the
cncf
slack
he's
you
know,
he's
been
a
bunch
of
meetings.
B
So
I'd
also
say
that
this
instrumentation
might
be
for
rails
users.
Duplicative
of
active
support
notification
subscriptions
to
the
sequel,
so
I
don't
like,
if
you
were
to
do
one
or
the
other,
I
don't
know
which
one
would
get
you
a
bigger
bang
for
the
buck.
E
Yeah,
that
was
my
thought
was
that
it
was
valuable
to
have
because
our
overall
direction
on
active
support
notifications
within
the
project
isn't
completely
settled
and
just
could
get
us
something
else
that
people
will
have.
You
know
value
for
outside
of
rails
too.
My
for
what
it's
worth
my
first
attempt
at
instrumenting,
some
of
our
apps
with
with
database
calls,
was,
was
looking
at
the
notifications
as
well.
It
definitely
is
very,
very
easy,
so
it's
easy,
but.
B
Then
we
got
to
maintain
a
whole
like
data
mapper
of
what
does
an
active
support
event,
look
like
versus
the
semantic
schema
for
open
telemetry,
or
at
least
that's
my
understanding
of
it
as
a
as
a
I'm
new
here,
but
so
otherwise.
B
So,
okay,
so
feedback
is
this
looks
awesome
and
I'll.
I
do
use
postgres
not
at
honeycomb,
but
in
my
personal
life,
so
I'll
see
what
I
could
do
about
taking
it
for
a
test
drive
cool.
E
Yeah,
any
additional
testing
would
be
super
appreciated.
One
of
the
other
things
about
it
was
that
I
have
it
logging
a
lot
of
statements
that
maybe
people
think
are
useless.
So
you
know
maybe
not.
E
B
And
well
that,
or
or
as
you
brought
up
on
it
on
the
other
issue,
ability
to
filter
out
like
I
don't
care
about
statements
like
this.
Yes,
yeah.
G
D
G
I
have
two
things
that
I
want
to
briefly
chat
about
that
are
not
pr
related
yeah.
I
don't
know
if
this
is
a
good
time
for
that
one
is
so.
We
have
a
a
dependency
on
protobuf,
obviously
for
the
otlp
exporter,
and
our
current
experience
with
this
at
shopify
is
not
great.
G
The
protobuf
gem
from
google
is
notoriously
flaky,
especially
around
releases
of
new
versions
of
ruby,
so
the
latest
version
of
this
has
had
a
had
a
significant
rewrite
and
has
introduced
a
bunch
of
bugs
it's
just
been
super
flaky
we've
had
a
lot
of
memory
leaks
related
to
this,
and
it's
just
not
a
super
good
feeling.
We
have
people
asking
us,
you
know:
can
we
come
up
with
an
alternative
implementation
of
this?
G
Whether
that's
you
know
generating
some
c
code
and
binding
or
whatever
anything
that
gets
us
away
from
having
a
dependency
on
the
the
google
protobuf
gem?
So
grpc
is
the
other
notoriously
flaky
thing
for
ruby,
specifically
so
yeah
like
we've,
been
avoiding
writing
grpc
instrument,
auto
instrumentation
we've.
You
know
we
we've
had
this
grpc
example
thing
sitting
out
there
like
this
is
pr.
G
If
you
scroll
down
a
bit,
there's
this
pr,
that's
been
sitting
open
for
almost
a
year
now
those
two
things
grpc
and
protobuf
are
just
generally
unpleasant
in
ruby.
I
don't
know
what
to
do
about
them.
I
don't
know
if
anybody
has
any
ideas,
particularly
about
the
protobuf
thing.
We
have
a
bunch
of
people
internally,
who
are
you
know,
backing
out
gem
version
bumps
because
of
flakiness
in
the
315
version
of
of
protobuf,
so
yeah.
Let
me
let
me
start
with
that
one
then
I
have
another
topic.
E
E
I
guess
I'm
struggling
to
to
see
like
what
what
would
be
annoying
for
us
if
we
had
grpc
instrumentation
like
I.
I
definitely
agree
that
the
protobuf
gems
like
edmond,
was
working
with
it
two
days
ago
and
it's
very
annoying
actually,
but
as
far
as
like
instrumenting
grpc
calls,
I
don't
think
you
actually
have
to
deal
with
the
protobufs
themselves
directly
or
any
of
that.
You
basically
just
have
to
patch
a
method
like
we
do
with
active
records.
G
Or
something
you're
just
taking
a
dependency
on
this
thing
and
I
think
there's
two
things
one
maybe
grpc
is
not
widely
used
in
the
ruby
community.
G
G
And
then
fixes
to
protobuf
in
order
to
support
the
new
version
of
ruby,
invariably
a
flaky,
and
it
just
becomes
a
month-long
or
month-long
affair.
So
if
we.
E
Have
we
thought
about
having
a
contrib
repo
for
for
hotel
ruby,
where
we
could
stick
something
like
this?
That
maybe
is
more
annoying
to
deal
with
and
shouldn't
be
part
of
the
core
distribution,
especially
because
I
think,
as
you
said,
it's
not
super
widely
used
within
ruby.
E
G
And
there's
not
like
thrift
is
not
really
much
better
for
ruby
as
anyone
who's
like
taking
a
look
at
the
jaeger
exporter
is
aware.
So
what
are
you
left
with
exporting
jason?
I
don't
know
it's
not
exactly
efficient.
D
C
C
D
I
was
just
gonna
say
yeah.
This
sounds
like
a
sticky
situation
for
protobuf
and
for
the
otop
exporter
in
particular,
like
one
possible
avenue
out
is,
is
json,
but
even
that
is
it's
not
ready
today,
just
because
the
the
otp
json
protocol
has
not
been
marked
as
stable,
yet,
which
is,
I
think
it
needs
to
be
marked
as
stable.
Soon
it's
actually
a
problem
for
javascript
in
the
browser,
and
there
are.
There
are
ways
to
make
json
exporting
over
json
as
efficient
as
possible.
D
B
What,
as
a
possibly
naive
question,
is
just
running
an
open,
telemetry,
collector
receiving
otlp
json
and
then
doing
the
re-export
as
grpc
once
it
when
it
leaves
expensive
like
once
it
crosses
an
expensive
border.
You
can
do
the
conversion
with
a
collector.
Yes,
you
have
to
run
a
collector
and
so
it's
more
infrastructure
to
run,
but.
G
D
D
It
seems
like,
ideally,
we
want
protobuf
for
for
a
number
of
reasons
we
just
want
it
to
work
and
be
stable.
Is.
G
D
I
easy
I
don't
know
see
this
is
I
mean
this
is
a
library
that
is
under
google's
purview
to
some
degree.
I
don't
know
if
it
is
something
we
can
reach
out
to
daniel
about
and
just
kind
of
like
at
least
mention
the
things
that
we're
observing
and
see.
If
it
is
anything
that
that
they're
aware
of
that,
they
are
interested
in
solving
that
they
can
prioritize
solving
that
they
can
do
some
help
on
whatever
see,
if
there's
any
way
to
kind
of
like
fix
the
problem
at
the
source.
D
I
guess
because
it
seems
like
all
the
alternatives
means
somebody
probably
here
doing
some
weird
work
to
work
around
it
and
that
maybe
should
be
like
a
plan
b.
I
guess,
if
plan
a
doesn't
work,
but
but
my
guess
is
that
this
is
probably
not
an
not
an
easy
problem
any
way
you
look
at
it,
otherwise
it
probably
would
have
been
solved
already,
but
maybe
it
is.
I
don't
know.
G
D
But
yeah
I
wish
daniel
were
around
so
we
could
talk
to
him,
but
does
does
it
make
sense
to
at
least
kind
of
like
reach
out
and
see
see
what
the
situation
is
and
see
like
what.
G
Yeah,
I
think
so
we
should
try
to
try
to
leverage
that
yeah.
We
do
that,
so
the
the
other
topic
was
something
I
brought
up
last
week
briefly
as
more
kind
of
a
vague
architectural
thought.
G
We
we
kind
of
had
a
little
bit
of
duplication
between
named
traces
and
our
you
know,
configuration
sorry
our
yeah,
I
guess
configuration
the
the
instrumentation
based
class
like
this
there's
some
overlap
conceptually
between
the
two
and
I
wondered
if
anybody
had
given
any
thought
to
like
how
are
other
languages
solving
this,
for
example,
the
configuration
and
are
they
providing
any
kind
of
configuration
based
class?
G
So
the
the
main
thing
is
that
one
of
the
original
purposes
for
introducing
name
traces
was
having
the
ability
to
configure
a
tracer
to,
for
example,
if
you
had
something
that
was
broken
to
be
able
to
disable
it.
If
you
had
some
instrumentation
that
was
excessively
verbose
to
be
able
to
disable
it,
and
I
don't
think
that
capability
has
been
fully
realized
with
named
tracers.
G
But
we've
implemented
something
like
that
with
our
configuration
based
class
and
the
ability
to
or
our
instrumentation
based
class
and
our
ability
to
just
say
enabled
false.
G
G
The
way
we've
set
it
up.
So
we
we
end
up
with
this
like
full
name:
space,
open,
telemetry,
colon,
colon,
instrumentation,
colon
colon
rake
colon
colon,
something
right,
so
your
configuration
tends
to
look
pretty
verbose
if
you're
actually
like.
If
you
have
a
whole
lot
of
instrumentation
and
you
need
to
configure
it
all,
it's
going
to
end
up
being
pretty
verbose
rather
than
using
names
that
people
may
be
familiar
with
like
rake
and
rack
and
rails
and
active
record
so
yeah
it.
These
are
just
kind
of
vague
feelings.
G
D
E
How
do
you
open
the
proposals?
The
instrumentation
based
class
allows
you
to
set
the
name.
Does
it
not?
I
mean
we
could
also
just
set
our
name
to
a
short
name
internally.
I
think
I
would
agree
it
is
verbose.
I
noticed
that
the
other
day
I
was
like.
Oh
that's,
that's
a
lot.
It
doesn't
really
fit
in
light
steps.
Nice
little
sidebar
for
a
trace
detail.
E
I
also
say
about
the
name:
tracer
thing
I
was
just
going
to
say,
as
it
makes
a
lot
of
sense
for
instrumentation
libraries,
but
just
as
a
as
an
end
user
tracing
something
internally,
it's
sort
of
like.
Why
do
I
have
to
provide
this
at
all?
Why
do
I
have
to
give
it
a
name
and
all
of
my
internal
convenience
classes
basically
make
it
it
wraps.
E
The
argument
says
it's
optional
and
if
you
don't
give
it
to
me,
I
set
it
to
whatever
you
set
the
service
name
to
so
just
as
a
user,
it's
sort
of
like.
I
don't
think
I
need
it
very.
Much
definitely
makes
sense
for
instrumentation
libraries,
though
so
that's
just
my
two
cents.
I
don't
have
any
better
thoughts
of
it
than
that.
G
Yeah,
it
was
a.
It
was
a
controversial
topic
when
it
was
originally
introduced.
So
your
sentiment
is
not
uncommon.
H
I
see
like
there's
like
the
two
sides
that
like
having
a
default
tracer
that
just
like,
like
andrew
said,
like
matches.
The
name
of
your
service
is
really
handy
and
for
a
lot
of
use
cases,
that's
what
makes
sense,
but
there
are
maybe
some
more
complex
ones
where
you
having
the
name.
Tracer
is
nice
too,
like
bigger
rails
applications,
often
or
will
in
some
cases
introduce
component
boundaries
or
engines
and
being
able
to
having
some
teams
working
on,
say,
like
an
engine?
H
E
That
seems
like
you,
stopping
the
heavy
use
case.
I
think
that
I
think
a
default
in
our
library
of
of
saying
you
know
if
you
don't
give
us
a
name
we'll
we'll
just
pick.
The
service
name
would
be
nice
and
ergonomic
for
people.
I
really
like
the
idea
of
things
that
are
highly
configurable.
If
you
need
it,
but
otherwise
present
a
simple
interface.
H
G
Think,
that's
probably
something
to
bring
up
at.
I
think
there's
like
a
special
sig
or
breakout
group
or
whatever
we
we're
calling
it
these
days
for
a
defining
a
convenience
api
for,
like
80
use
cases
on
top
of
the
open,
tracing
or
open
telemetry.
Sorry,
api,
open,
telemetry
tracing
api,
so
that's
probably
a
topic
that
should
be
brought
up
there.
I
know.
G
Okay,
yeah
yeah,
like
matt,
had
a
pr
a
while
back,
which
we
didn't
end
up
merging
for
introducing
a
default
tracer.
The
problem
is
right.
Now
the
the
spec
says
that
if
you,
I
think
the
spec
has
specific
requirements
around
what
the
name
should
be.
If
you
don't
provide
it
and
then,
of
course,
it
also
has
a
default
for
the
service
name
of
just
unknown
service,
colon
process,
name
or
just
uncop,
sorry
unknown
service
so
like.
D
I
did
have
an
opinion
on
on
the
first
thing,
the
first
part
of
your
comment
about
about
name,
tracers,
originally
kind
of
being
introduced
to
be
able
to
kind
of
disable
an
instrumentation
and
kind
of
the
mechanism
by
which
you
would
disable
an
instrumentation
is
supposed
to
be
returning
a
no-op
tracer
and
how
that
kind
of
overlaps
with
the
instrumentation
based
class,
where
you
can
actually
enable
or
disable
instrumentation
there,
and
I
guess
I
have
two
two
thoughts
there.
D
I
know
when
when
they
were
talking
about
name
tracers,
I
was
actually
a
big
advocate
for
like
why
not
just
disable
the
instrumentation
begin
with,
and
I
still
think
there's
a
lot
of
merit
to
that
to
that
approach.
And
but
the
larger
thing
is
that
the
name
tracer's
work,
kind
of
stops
short
of
ever
realizing
the
the
ability
to
kind
of
enable
and
disable
instrumentation,
and
I
think
one
of,
like
the
big
reasons,
is
actually
technical
in
that.
D
If
you
end
up
returning
the
no
op
tracer,
I
think
your
trace
ends
up
breaking
rather
than
just
yeah,
rather
than
I
I
believe-
and
I
would
have
to
think
through
this
and
make
sure
that
this
is
still
the
case.
But
the
way
the
no
op
tracer
works
with
the
current
span.
D
You
end
up
with
like
a
no
op
span
in
a
context
and
then,
as
you
start
your
next
ban,
it
doesn't
link
up
with
its
true
parent,
and
this
kind
of
shortcoming
had
not
been
resolved
and
that's
one
of
the
big
reasons
why
that
work
stalled,
and
I
think
it
was
meant
to
be
solved
at
some
point
but
has
probably
been
on
the
back
burner
for
for
folks.
D
But
I
think,
as
it
stands
today
there
there
might
not
be
a
way
to
actually
disable
anything
through
through
a
named
tracer,
whereas
technically
you
can
do
it
with
instrumentation
base.
But
I
think
it
does
deserve
some
thought.
Some
forward
looking
thought
to
make
sure
that
these
things
are
going
to
line
up
in
the
future.
B
I
mean
about
now.
Yes,
you
couldn't
understand
my
handwriting.
I
have
a
new
person
question.
I
think,
to
figure
out,
if
I
understood
the
issue
that
you
described,
is
it
that
name
tracer?
The
idea
behind
implementing
that
feature
is
both
was
both
as
a
feature
flag,
flipper
somehow
to
say
from
this
point
on.
I
don't
want
spans
or
traces
and
to
give
named
context
like
robert
had
described
to
this
portion
of
my
system.
B
It
has
a
different
name
than
the
some
other
portion
or
the
parent
portion
of
the
system,
and
that,
while
the
I
can
name
a
portion
of
my
system
and
get
sort
of
labeled
events
spans
coming
out
of
that
with
name
tracers
today,
you
don't
get
the
feature
flag
flipping
through
the
name
tracer
you
get
it
through
the
parent
instrumentation
class
and
enabling
or
disabling
instrumentations
there.
G
Yeah,
that's
right,
yeah,
so
so
we
never
really
realized
that
capability
with
name
traces
and
it
sounds
like
that
hasn't
really
been
resolved.
At
the
spec
level
we
had
or
matt
had
had
started
building
out
our
configuration
mechanism
before
name
traces
were
really
brought
in
as
a
thing
but
yeah.
We
we
never
like
those
two
things,
never
really
linked
up.
Our
configuration
mechanism
and
our
instrumentation
based
class
is
specific
to
the
ruby
implementation
of
open
telemetry.
G
That
was
suggested
as
the
way
or
as
one
of
the
rationales
for
name
traces
yeah,
but
no
mechanism
was
defined
for
actually
doing
that.
Okay,
so
configuration
of
these
things,
configuration
of
the
instrumentation
is
really
left
up
to
the
sdk
implementation.
It's
not
specified.
B
D
Nice
yeah,
so
on
that
token,
or
on
yeah
on
that
point,
I'm
not
sure
I
I
think
we
can
talk
about
this
stuff
further,
but
I
don't
know
I
do
think
there
is
a
still
a
slight
difference
between
like
not
installing
an
instrumentation
altogether
and
in
installing
it,
but
returning
a
no-op
tracer.
Instead,
it's
subtle,
but
I
don't
know
like
I've,
seen
situations
where
just
the
there
could
be
some
nasty
bugs
or
bugs
that
show
up.
D
You
know
in
kind
of
certain
setups
that
just
installing
instrumentation
could
cause,
and
this
would
be
like
a
way
out
or
something
like
that.
Again,
it's
not
like
a
common
use
case
and
we
hope
to
not
regularly
produce
such
bugs.
But
that's
that's
one
thing
to
keep
in
mind.
D
I
think
I
think
that's
how
it
goes
and
by
like
by
not
in
song
and
instrumentation
you're,
actually
doing
nothing
whereas
like
by
the
song
instrumentation,
but
using
a
no-op
traits
there.
There
is
some
level
of
overhead
there.
It's
it
should
be
low,
but
it's
not
nothing
so.
D
So
there
might
be
some
merits
to
having
this.
I
feel
like
the
worst
thing
that
will
happen
is
in
the
future,
when
there
is
configuration
for
name
tracers,
to
turn
this
off,
that
you
will
have
two
ways
to
do
something
and
they
are
slightly
different.
So
I
don't
know
that
that
is
the
end
of
the
world,
but
I
don't
know
I
I
guess
those
are
my
thoughts.
I
will
leave
them
there,
I'm
not
like
saying
we
need
to
keep
both
both
methods,
but.
G
Yeah
but,
as
I
said
it's
more
a
feeling,
rather
than
a
you
know
something
hard
and
fast
that
I
can
point
to
and
say
you
know,
there's
duplication
here
that
we
should
take
care
of.
G
D
Yeah,
I
think,
calling
like
you
know,
active
record,
open,
telemetry,
active
record
or
something
rather
than
everything
else
that
we
have
in
the
namespace.
C
We
might
want
to
the
only
thing
I
had
not
the
only
thing
I
had
on
stuff
all
the
time,
we're
three
minutes
over
there.
So
I'm
just
I'm
sorry
we
might
get
have
issues
if
they
start
to
put
constraints
around.
What's
considered
a
breaking
change,
you
know
there's
like
docs
going
around
being
like.
Oh,
if
this
attribute
value
changes,
that's
a
breaking
change,
so
we
might
just
it's.
D
Yeah,
this
is
all
kind
of
stuff-
that's
happening
with
the
instrumentation
working
group,
which
is
really
just
a
slack
channel
as
far
as
I
know,
but
but
yeah
they're,
trying
to
kind
of
lock
in
and
determine
what
it
means
for
instrumentation
to
be
stable.
C
D
All
right,
great
yeah,
I
I
think
we
talked
about
a
lot.
We
have
some
some
work
to
do
on
some
pr's,
but
otherwise
see
you
around.
On
slack
and
next
week,.