►
From YouTube: 2021-03-16 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
B
A
B
A
C
C
C
C
Yeah,
I
mean
it's
kind
of
a
full
look
at
what
problems
they
think
people
want
to
be
able
to
solve
and
then
how
they
want
like
metrics.
They
want
to
track
on
how
well
open
telemetry
is
solving
these
problems
and
kind
of
some
ways
to
get
feedback,
surface
feedback
and
generally
improve
things.
This
guy
who
wrote
this,
I
think,
is
matt
mccleary
from
microsoft.
C
In
the
conversation
with
the
spec
sig,
I
think
one
of
the
call
to
action
anyways
was
trying
to
actually
get
people
to
try
open,
telemetry
and
and
do
some
user
research.
I
know
teddy
young
from
lightstep
has
done
a
little
bit
of
this
before
and
he's
he's
used
various
subjects
for
research.
C
I
think
he
was
saying
that
you
get
like
a
lot
of
like
younger
developers.
You
don't
always
get
like
the
target
audience
and
he's
tried
it
on
people
at
light
steps.
So
people
who
don't
work
on
this
project
but
are
in
the
space,
and
he
found
that
to
be
a
little
bit
better,
a
little
bit
more
of
the
right
target
audience.
So
he
was
asking
he
was
asking
and
generally
just
floating
the
idea
of
like
what.
C
A
Cool,
I
informally
have
heard
some
feedback
from
friends
that
getting
started
with
open.
Telemetry
can
be
rough,
so
hopefully,
hopefully
something
good
comes
of
this.
C
Yeah,
I
think
I
think
getting
started
is
a
known
problem
in
in
a
lot
of
ways
actually
like
getting
things
actually
set
up
being
an
sdk
configured
is
a
problem.
That's
that's
the
first
problem
and
like
if
you
manage
to
get
past
that
problem,
there's
a
handful
of
secondary
problems
that
you're
going
to
run
into.
C
One
of
them,
I
don't
think
I
should
jump
in
line
all
right,
maybe
I'll
jump
in
line,
so
one
of
those
problems
ends
up
being
this,
like
named
tracer
problem.
I
don't
know
if
anybody
here
has
run
into
this
problem
like.
C
Every
other
apm
product
that
I
have
used
you
just
there
is
a
tracer
and
you
use
it
in
open
telemetry.
C
You
need
to
get
a
named
tracer
and
basically
it
it
corresponds
to
the
thing
that
you're
creating
spans.
For
so
is
it
the
application
as
a
whole?
Is
it?
Is
it
your
application?
Is
it
some
component
that
you're
instrumenting
and
typically
that's
what
the
name
of
the
tracer
is
is?
Is
the
name
of
the
component
that
you're
that
you're
instrumenting,
but
for
your
own
application?
You
want
to
name
it
after
your
your
application,
so
this
well
sometimes
makes
sense
for
for
instrumentation
authors.
C
C
Yeah,
so
this
discussion
was
about
basically,
can
you
pass
a
null
to
get
tracer?
Is
there
some
way
to
get
like
a
default
tracer?
C
Could
you
just
pass
an
empty
string
to
signify
that,
and
this
ended
up
taking
a
long
time
to
actually
discuss,
and
I
don't
feel
like
there
was
a
really
good
resolution.
I
think,
though,.
C
The
one
of
the
I
don't
know
one
comment
that
one
of
the
later
comments
was
like:
why
not
just
allow
md
empty
or
null,
which
ends
up
being
sent
to
a
back
end
as
an
empty
string,
and
then
the
back
end
understands
the
empty
string
case
and
provides
some
provides
whatever
you
want
for
that.
C
But
yeah
that
does
go
perhaps
in
in
line
with.
Maybe
these
next
document
documents
that
I
wanted
to
at
least
discuss-
and
I
think
several
meetings
ago
mentioned
that
there
are
some
improvements
for
for
tracing,
even
the
weave
1.0
and
those
fall
into
a
few
areas.
One
one
such
area
is
convenience
apis.
C
So
right
now
we
have
withstand
and
in
span
which
I
think
are
becoming
progressively
more
controversial
in
my
mind
as
we're
heading
towards
a
heading
towards
possibly
ga,
because
we're
kind
of
committed
to
them
and
we're
starting
to
talk
about
these
convenience
methods,
and
I
think,
there's
like
with
those
methods,
in
particular
there's
kind
of
some
open
questions
about
how
they
should
interact
with
with
the
current
context
and
once
we
ga
with
them
we're
kind
of
stuck
with
them.
I
guess
so.
C
If
we,
if
we
don't
know
how
they're
going
to
interact
with
context
or
if
the,
if
we
end
up
deciding
on
convenience
methods
at
the
spec
level,
with
a
slightly
different
behavior
with
the
same
name
that
we
end
up
end
up
in
a
slightly
challenging
situation.
C
I
guess
we
can
come
back
and
talk
about
our
specific
situation
with
these
a
little
bit
later,
but
the
tldr
is
that
there
is
this
hotel
convenience,
api
kind
of
group-
I
guess-
and
both
of
this
and
the
other
one
I'll
mention-
is
hotel,
instrumentation
design,
they
didn't
want
to
add
new
meetings
to
hotel.
C
And
basically
there
are
these
required
otep
sections,
so
those
are
kind
of
the
deliverables.
I
think
these
groups
are
going
to
be
responsible
for
and
basically
that's
what
that's,
what
we're
looking
to
get
more
guidance
for
for
for
hotel
so
for
convenience
api.
There
is
this
api
architecture,
suggestions.
C
A
package
that
contains
these
methods,
what
the
method
signature
should
be
and
then
for
languages
that
support
it
like
java,
for
example,
you
might
want
some
annotations
other
such
things.
C
C
Basically,
looking
for
some
guidance
around
different
types
of
instrumentation
and
I
think
ultimately
like
what
how
you
should
tackle
some
of
these
problems,
what
things
you
should
create
spans
for
maybe
what
things
you
should
create
events
for
kind
of,
maybe
the
a
move
beyond
just
just
the
semantic
conventions
for
certain
types
of
instrumentation
and
generally
kind
of
guidance
for.
C
Ecosystem
management,
I
think
this
becomes
an
issue
as
we
get
more
and
more
third-party
instrumentation
anyways
and,
I
guess
even
first
party
and
then
the
stability
requirements
so.
C
I
don't
know
I
I've
said
a
lot,
so
I
just
want
to
check
in
any
questions
comments
on
this.
A
I
mean,
I
think,
it's
all
good
stuff.
I
wonder
what
the
convenience
api
will
look
like
and
if
that's
sort
of
we
designed
the
api,
that's
fiddly
and
hard
to
work
with,
so
we
need
to
go
back
and
redesign
it,
and
I
wonder
what
will
sort
of
what
will
become
of
the
two
are
people?
Are
you
know?
C
Yeah,
I
think
you
know
the
api
that
we
have
is
is
known
to
be
like
very
low
level
and
it's
kind
of
targeted
towards
it's
targeted
towards
us,
like
the
developers
of
open,
telemetry
and
instrumentation
authors,
it's
like
definitely
probably
not
targeted
towards
more
of
like
an
end
user.
Somebody
who
I
just
want
to
add
an
attribute
to
to
the
current
span,
or
something
like
that.
So,
like
you
know
all
of
the
pieces
are
there
for
us
to
do
this.
We
get
the
current
span.
C
We
we
can
add
an
attribute,
but
maybe
there's
like
a
few
stuff
to
that,
and
there
actually
might
be
three
in
the
real
world.
But
if
we
could
simplify
that
down
to
just
one
api
call,
that's
pretty
high
level
comes
from
another.
C
C
I
think
the
drawbacks
is
that
sometimes
they
can
be
a
little
bit
less
performant.
You
have
to
actually
do
a
little
bit
more.
Then
then
you
might,
if
you
use
the
low-level
api
or
you
might
be
able
to
like
you,
might
be
able
to
structure
your
code
in
any
way
in
slightly
more
intelligent
ways
when
you
use
the
low
low
level
api
to
shave
off
an
object,
allocation
or
accessing
something
multiple
times,
etc
and
kind
of.
C
Yeah
the
I
I
had
another
thought
there
that
I
am
not
remembering,
but
at
any
rate
yeah
that's
kind
of
the
goal
of
these
convenience
methods,
and
it's
not
so
much
that
the
api
that
we
have
is
not
good
enough.
It's
just
that.
We
know
that
the
api
that
we
have
is
very
very
low
level
and.
C
But
yeah
so
just
to
highlight
there
are
a
couple
of
new
slack
channels
where,
where
these
discussions
are
going
going
on.
B
With
the
user
research
bit
you
mentioned,
do
you
know
if
ted
or
I
guess
whoever's
conducting
these
surveys
are
sort
of
like
usertesting.com
but
for
developer
type
things
like
do
they
have
a
goal
there?
Having
is
it
just
like
get
a
trace
in
your
backyard
in?
Is
it
or
it's
in
in
your
case?
Is
it
like
get
a
trace
in
light
step,
or
is
it
like
get
a?
You
know,
log
to
the
open,
telemetry
collector
logging
exporter
like?
Is
there
a
common
goal
with
these,
or
is
it
just
sort
of
like?
B
Oh,
do
you
have
a
do?
You
have
a
personal
app,
you
have.
Why
don't
you
install
tracing
and
let
me
know
your
thoughts
like,
have
you
had
any
feedback
there,
because
for
what
it's
worth?
This
is
a
problem
that
exists
at
my
company
too,
so
yeah,
because
if
you
have
a
angle,
you
you're
like
telling
users
to
work
toward
it
would
be
good
to
know.
I
can
try
to
talk
to.
B
I
don't
know
someone
more
important
to
me
and
see
if
I
can
get
some
resources
from
you
and
do
the
like.
Hey
you
just
started
three
weeks
ago.
Can
I
borrow
you
for
an
hour,
I
think,
but
yeah
it
would
be
good
to
know
if
there's
any,
if
we,
if
there's
any
like
yeah
specific
angle,
you're
trying
to
test
or
people
are
trying
to
test.
C
Yeah,
I
think
that's
a
good
question.
I
know
ted
did
a
round
of
user
feedback
a
little
while
ago
and
I
feel
like
there
was
a
document
that
was
like
try
to
do
these
things
and
I
feel
like
that
is
suspiciously
missing
from
from
this
proposal.
It's
like
how
yeah
like
what
what
should
we
have
people
try
to
do,
and
I
think
we'll
probably
have
more
success
likely
have
more
success.
If
there
is
some
sort
of
plan
to
present
to
your
co-workers
and.
C
B
C
No,
no,
I
I
think,
that's
a
good
insight
and
maybe
something
worth
like
asking
a
question
on
this
doc
or
on
the
issue
about
we'll
comment
on
the
issue
of
five.
C
C
I
guess
it
is
one
of
these
things
where
the
collector
does
have
a
pretty
big
influence
across
the
project,
so
maybe
some
justification
for
for
wanting
a
little
bit
wider
audience
and
buy-in.
But.
E
C
Yeah,
I
guess
collector
contrib
is
further
out
to
the
fringe.
So
I
think
your
observation
is
is
very
valid.
C
And
then
I
think
I
kind
of
left
the
meeting
during
this.
The
stuff
always
like
tends
to
go
long,
but
it
was
kind
of
a
question.
I
think
this
is
really
targeted
towards
the
the
spec
repo,
but
it
probably
applies
to
all
the
repos
and
I
think,
there's
just
a
question
as
to
if
there's
an
sla
on
reviews,
I
think
we
are
pretty
decent
in
in
the
ruby
repo,
although
I
will
admit
some
reviews,
I've
done
I've
taken
longer
than
I
have
wished.
C
I
think
we
all,
I
think,
we've
all
been
through
that
experience
one
way
or
another.
So
just
trying
to
be
courteous,
I
think,
is-
is
a
good
idea
at
the
spec
sig.
Some
stuff
does
sit
notoriously
long
with
like
no
feedback
and
it's
hard
to
get
people
to
own
that
stuff
a
little
bit
more.
C
I
do
feel
like
it's
a
little
bit
worse
over
there
than
it
is
in
in
our
repo,
but
I
think
I
think
there
is
no
no
no
sla
on
this,
and
I
think
one
of
the
reasons
why
stuff
is
so
slow
at
the
spec
level
is
because
it
is
pretty
committing
and
they
do
want
to
get
feedback
from
like
it's
like
they
want
to
hear
from
java
and
ruby.
C
You
know
and
python
before
before
merging
something
just
because
they
want
to
make
sure
it's
going
to
work
across
a
wide
array
of
languages,
oftentimes
and
not
just
oh.
This
is
good,
for
this
is
good
for
java.
It's
got
to
be
good
for
everybody
kind
of
mentality,
so
I
think
no
easy
solution
to
that
one.
But
that
was
a
discussion
that
was
there.
C
C
And
what
should
we
look
at
first
over
here?
I
guess
issues
prs.
E
Milestones,
I
think
robert
wanted
to
dominate
this
meeting.
C
C
C
Cool
yeah,
so
as
a
brief
summary
there,
there
were
a
couple
pr's
last
week
that
I
looked
through
the
jager
propagator
ot
trace
propagator,
and
I
got
me
looking
at
baggage
and
I
realized
that
baggage
hadn't
been
touched.
A
long
time
was
kind
of
part
of
this
otep
66
project
a
long
time
ago,
and
it
did
some
cleanup.
So
I
was
trying
to
clean
it
up
and
bring
it
at
least
functionally
up
to
date,
and
I
think
one
of
the
controversial
things
that
I
did
was
change.
C
The
apis
from
like
set
entry,
get
entry
remove
entry,
and
this
is
because
for
each
thing
in
baggage,
you
need
to
store
a
value
and
possibly
metadata
open.
Telemetry
does
not
support
metadata,
but
w3c
baggage
does
so
you
kind
of
need
a
place
to
stick
that
stuff
and
make
sure
that
if
you
did
receive
metadata
from
some
other
app
that
supported
it,
that
you
least
propagate
it,
but
we
don't
really
expose
apis
for
it.
So.
C
It
looks
like,
as
I
suspected
this
was
a
little
more
controversial.
We
do
want
to
stick
with
these
things
as
set
value
get
value.
I
started,
I
started
doing
that
and
I
started
just
like
returning
the
value
off
the
entry
and
I
got
a
long
ways.
C
I
got
all
the
way
to
inject
and
then
I
was
like
how
do
I
get
the
metadata
and
that's
when
I
decided
to
just
change
the
api,
but
I
don't
know,
would
you
be
happy
with
a
get
metadata
method
that
is
api,
private,
that
the
injector
uses
and
it
just
kind
of
like
for
each
key?
D
E
Yeah,
I
kind
of
feel
like
it's
it's
a
corner
case.
It
hasn't
been
specified
because
nobody
wanted
to
dive
into
what
metadata
actually
meant
so,
but
they
wanted
to
allow
you
to
set
it.
So
you
can
set
it,
you
can
propagate
it,
but
you
can't
get
it.
I
feel
like
this
is
something
that's
going
to
be
addressed
at
some
point
in
the
future.
Once
there's
been
some
use
of
metadata
in
the
wild,
I
wouldn't
want
to
commit
to
a
an
api
for
this
right
now.
E
E
That's
really
the
only
propagator
implementation
that
needs
to
deal
with
metadata,
and
you
know
whether
that's
with
this
api
private
get
metadata
or
whether
you
actually
want
something
more
performant.
C
Yeah,
so
really,
I
just
need
to
be
able
to
iterate
all
the
things
to.
C
C
E
It
just
means
you
can
do
a
hash
look
up
each
time,
instead
of
just
taking
what
the
iterator
is
giving
you.
E
E
The
reason
this
is
useful
is
that
if
somebody
had
a
propagator
for
whatever
reason,
actually
no,
we
just
want
to
hide
it.
I
mean
either,
approach
is
fine.
Either
approach
is
fine.
I
just
feel
like
it's
a
private
api
between
the
propagator
and
the
the
manager
and,
however,
that's
done.
We
should
just
be
clear
that
this
isn't
part
of
the
public
api
and
we're
not
committing
to
you
know
we're
not
committing
to
api
stability
guarantees
for
this
particular
thing.
C
That
makes
sense
I'll
come
up
with
something,
and
I
will
the
next
thing
will
be
slightly
better
and
if
it's
not
good
enough,
just
let
me
know-
and
I
will
continue
to
to
work
on
it,
but
I
kind
of.
E
Yeah
yeah.
This
is
also
going
to
intersect
with
my
api.
Sorry,
my
refactor
of
the
propagators
that,
like
I
need
to
finish
now
that
people
have
thrown
a
couple
more
propagators
into
the
mix
that
I
need
to
update
but
yeah
I
they're
going
to
interact
with
one
another.
C
Yeah,
I
saw
that
apologies.
I
feel
like
we'll
we'll
figure
that
one
out
as
well,
but
I
do
think
this
is
important,
because
I
think
what
we
have
today
is
slightly
broken
and
probably
like
not
api
complete,
I
guess
for
4ga
for
baggage.
E
C
E
D
That's
exciting
yeah,
so
I
started
working
on
the
instrumentation
for
active
record
and
I
think
I'm
taking
a
reasonable
approach.
Andrew
left,
some
good
comments
there
and
I'm
not
sure
what
the
right
way
for
so
maybe
we'll
just
start
with,
like
a
quick
overview
of
how
I'm
approaching
it.
So
I
looked
at
a
few
different
underlying
classes
that
act
record.
Active
record
has
there's
a
persistence
class
that,
through
many
means
of
interaction,
becomes
available
on
any
active
record
model
in
a
rails
application.
D
So
this
is
the
the
class
that
gives
you
your
class
methods
like
model.create,
create
with
a
bang
and
all
the
things
that
go
with
it
your
inserts,
but
it
also
gives
you
the
instance
method
of
like
model.save
model.update
model
delete,
destroy,
and
all
that
goes
with
that.
D
I
think
that's
the
class
to
be
patching,
so
persistence
rv
there.
I
don't
have
it's
not
comprehensive.
I
don't
have
every
single
public
method
patched
so
far.
I
just
want
to
start
with
a
base
and
see
what
it
looked
like.
D
There's
another
class
that
sits
above
it
as
I've
recently
learned
that
in
active
record,
when
you
do
any
sort
of
persistence
method,
it
gets
wrapped
in
a
transaction
implicitly.
D
So
there
is
also
this
transaction
class
where
you
have
kind
of
like
a
like.
If
you
instrument
both
you
get
like
model.save
wrapped
it
up
model.save,
so
you
get
like
kind
of
this
like
duplicate
effect.
So
originally
I
thought
transaction
was
the
one
I
wanted
to
patch
because
it
was
at
a
higher
level,
so
it
would
encompass
things
like
your
commit.
D
But
for
me
I
think
the
reason
why
I
kind
of
came
to
that
conclusion
that
I
wanted
to
do
transaction
was
like.
I
was
doing
a
simple
test
where
I
was
like
in
a
console
doing
like
user.new.save
and
the
commit
wasn't
part
of
your
trace,
because
the
commit
happens
after
the
save
outside
of
the
context
of
saying,
like
user.save,
but
in
the
context
of
say,
like
a
web
request.
D
Those
things
become
right
beside
each
other,
whereas
if
you
instrument
at
the
transaction
level,
you
would
always
have
the
commit
and-
and
when
I
say
the
commit,
I
mean
from
the
my
c,
my
sql
instrumentation.
I
was
using
alongside
of
it,
to
see
how
the
two
kind
of
looked
together,
you
wouldn't
have
the
the
commit
in
the
same
request.
D
If
you
use
the
persistence
patching,
but
if
you
use
the
transaction,
you
would
get
the
commit
caught
in
there
as
well
as
all
of
your
callbacks,
but
when
you're
actually
doing
it
against,
like
a
rails,
controller,
you're
saying
like
create,
and
if
you
actually
just
jump
to
the
description
of
the
pr.
This
might
make
what
I'm
saying
a
little
bit
easy
to
or
easier
to
see.
I
just
included
a
simple
strange
screenshot,
so
this
is
literally
a
controller
action
that
says
user.new.save.
D
I
think
that's
what
I
used
for
this
one
here
or
does
it
create?
No.
This
was
just
this
wasn't
created,
so
basically
it's
doing
user
create.
Now
I
have
transaction
parentheses
here
I
just
like
renamed
this
fan
name
so
it'd
be
obvious
to
distinguish
which
one's,
which
I
think
it's
a
little
bit
too
noisy.
D
So
all
this
is
to
say
is,
I
think,
the
first
pass
of
this
and
I
do
think,
there's
going
to
be
a
lot
of
room
for
improvement
as
it
gets
used,
which
is
probably
going
to
draw
some
feedback
as
people
use
it,
because
people
are
going
to
expect
something.
That's
like
100
fraud
ready
is
to
just
patch
the
persistence
level
here,
because
this
is
going
to
give
us.
I
think,
like,
as
a
rails
developer,
what
you
would
expect
to
see.
D
I
think
it's
worth
taking
a
second
to
talk
about
the
active
support
notifications,
because
shopify's
internal
existing
instrumentation.
What
we
did
is
we
used
active
support
notifications.
We
talked
about
some
of
the
the
shortcomings
there.
There's
a
topic
called
sql.active
and
it
does
have
the
nice
property
that
it
is
database
agnostic.
So
if
you
didn't
have
like
right
now,
there's
no
open
telemetry
instrumentation
for
postgres,
for
example.
D
If
we
did
the
sql.activerecord
instrumentation,
you
would
effectively
get
the
same
spans
generated
by
that
instrumentation.
The
postgres
like
right
now,
if
we
did
the
sql.record
instrumentation
and
had
my
sequel,
you'd
have
two
spans
that
are
very
tightly
overlapping.
They're,
essentially
like
the
would
be
covering
the
same
thing.
I
think
the
active
support
one
would
have
a
little
bit
more
information
that
it
knew
that
it
was
like
model.save
or
something
like
that.
D
But
from
my
perspective,
if
you're
instrumenting,
my
sequel
and
you
do
that
active
support
notification,
you're
really
you're
not
really
making
your
your
tracing
richer,
you're,
not
it's
not
more
comprehensive.
Like
I
don't.
I
don't
see
a
lot
of
value
of
two
tight
overlapping
spans
like
that,
because
you're
not
getting
more
visibility
into
the
timing
you're
just
seeing
okay,
this
is
how
long
the
actual
sequel
took.
D
D
So
if
you
have
a
bunch
of
like
crappy
slow
callbacks,
you
got
a
bunch
of
after
commit
hooks
all
of
a
sudden.
Your
save
is
very,
very
it's
taking
a
lot
of
time,
but
you
can
see
the
difference
now
between
the
actual
execution
of
the
database
versus
okay.
Something
else
is
happening
here.
It's
not
just
writing
to
the
database.
That's
slow
here!
Maybe
I
have
too
much
going
on
as
an
after
hook
or
a
form
up
or
something
like
that.
D
The
callbacks,
I
think,
from
what
I
played
around
with
it,
looks
like
instrumenting.
Those
would
be
an
active
support,
not
an
active
record,
so
that
would
be,
I
think,
a
separate
pr
to
this
one,
a
separate
set
of
instrumentation.
If
we
go
that
route,
I
do
think
there
is
value
there,
but
it
you
have
to
be
careful.
D
C
C
Have
thoughts?
Oh
go
ahead.
I
just
quickly
say
to
the
point
of
like
overlapping
active
record
and
my
sql
instrumentation
like.
I
think
that
that
I
generally
agree
that
you
don't
get
additional
value.
C
And
then,
in
terms
of
that
trace
being
noisy,
I
agree
and
it
sounds
like
it's
noisy
because
of
both
the
transaction
and
both
patching
the
transaction
class,
as
well
as
the
persistence
class
module.
A
A
Because
I
don't
know
about
more
meaningful,
but
I
appreciate
your
confidence
in
me.
I,
like
the
pr
overall,
I
think
it's
a
pretty
good,
certainly
a
good
like
first
step
and
a
good
like
it's
better
than
what
we
have
now,
which
is
nothing
so
you
know
for
that
alone.
I
like
it.
I
I
actually
had
active
support
notifications
up
on
my
screen
and
was
thinking
about
it
while
walking
the
dog
again
earlier.
A
I've
been
staring
at
it
for
a
while.
I
still
think
we
should
probably
try
to
make
them
safer
and
alleviate
some
of
the
problems
that
shopify
experienced.
Just
because
there's
so
much
data,
that's
available.
It
can
be
overwhelming
and
it's
up
to
us
probably
to
make
sure
that
the
correct
things
are
subscribed
to
and
give
the
right
knobs
to
people
to
tweak
if
they
need
it,
but
like
we,
we
miss
so
much
by
by
patching
it
all
over.
A
We
also
really
start
to
tightly
couple
ourselves
to
rails
internal
implementations
too,
and
that
can
be
particularly
difficult,
especially
when
you
start
getting
down
to
the
lower
levels
like.
I
know
we're
not
patching
aural
or
anything
like
that,
which
would
be
frightening,
but
the
lower
you
go
with
rails,
the
more
likely
you
are
that
even
a
minor
point
release
will
mess
up
your
instrumentation,
whereas
at
least
with
notifications
less
likely
that
they're
going
to
change
that.
You
know
they'd
publish
that
as
a
documented
thing.
A
I
think
that
there's
some
improvements
we
could
explore
making
derails
for
that,
but
also,
if
we're
going
to
patch
things,
we
could
patch
the
method
that
is
delivering
notifications
to
subscribers
and
just
catch
exceptions.
And
you
know
there
is
a
limited
patch.
I
think
we
could
make
there
to
make
things
safer
and
then
at
least
allow
that
as
an
option.
A
So
I
don't
know
that
I
had
if
that
was
more
meaningful
commentary,
but
I
do
think
we
we
get
a
lot
from
active
support
notifications,
the
the
thing
specifically
with
databases.
That's
nice,
is
we
get
for
free,
we
get
postgres,
we
get,
we
get
any
other
esoteric,
instrumentation
or
databases
that
people
have
db2
sqlite.
I
once
ran
rails
with,
like
a
google
cloud,
datastore
adapter,
which
was
fun.
So
there
are
all
sorts
of
interesting
things
you
would
get
that
we
wouldn't
necessarily
get.
If
we
have
to
patch.
A
D
I
think
no,
I
think,
that's,
I
think,
that's
a
good
point
and
I
don't
think
like
a
prudent
move
would
be
for
us
to
completely
shut
the
door
on
using
active
support
notifications.
I
feel
like
the
reality
is
I'm
like
just
kicking
the
can
a
bit
oh
yeah,
I'm
dealing
with
it.
D
I
do
feel
that
patching
at
the
persistence
level
is
probably
the
right
move
for
us
in
that,
like
yeah,
just
to
dress,
like
the
point
of
we
want
to
be
cautious
about
patching
lower
level
apis
for
rails
because
they
can
change,
I
haven't
been
working
on
rails
forever,
but
it's
been
five
years
now,
at
least,
and
these
these
methods
that
were
patching
here
don't
see
a
lot
of
churn
because,
like
you
know,
I
I
wouldn't
expect
save
to
go
anywhere.
D
For
example
like
so
these
kind
of
methods,
they're
heavily
used,
they're
public
they're,
not
this
isn't
a
private
api.
This
is
the
one
that
gets
included
on
all
your
models,
so
I
feel
a
little
bit
more
confidence
in
the
fact
that
we
won't
see
a
lot
a
lot
of
turn
here.
If
we
want
to
be
a
little
bit
more
proactive
and
really
cautious,
like
with
the
instrumentation,
we
could
put
an
upper
bound
on
the
version.
So
it's
saying
it's
compatible.
D
We
know
it's
compatible
here
and
here
and
outside
of
that,
like
we'll,
have
to
cautiously
increase
the
support,
as
shopify
releases
replaces
releases
new
versions,
but,
like
I,
I
like
this
approach
just
in
that,
I
think
it
provides
like
a
richer
trace,
like
you
can
see
more
and
I,
what
I
would
really
be
happy
to
see
is
after
this
gets
settled,
is
adding
things
like
callbacks
being
able
to
trace
callbacks
time
spent
in
callbacks,
because,
like
I,
hate
callbacks
and
it's
nice
being
able
to
point
to
them
and
show
people
that
it's
really
slowing
down
their
requests.
D
D
How
much
time
is
being
spent
there
right,
and
I
think
that
we
could
really
step
up
kind
of
the
quality
of
instrumentation
against
rails
that
exist,
like
I
haven't
seen
any
other
tools
do
this
well
or
at
all.
So
I
think
we
could
really
kind
of
bring
something
new
and
I
think
that
could
help
for
the
adoption
of
open
telemetry
in
general,
which
is
probably
something
that
benefits
all
of
us.
D
So
unless,
like
there's
some
contention
and
like
I'll
move
this
out
of
draft,
but
I'm
going
to
be
moving
forward
with
the
persistence
methods
and
the
persistence
class
methods,
so
the
class
methods
are
just
like
the
create
and
all
that
stuff
in
regards
to
transactions.
D
There
is
one
method
that
I'd
like
to
continue
patching
and
it's
the
dot
transaction.
So
it's
like
the
actual.
If
someone
declares
like
you
know,
active
record-based,
transaction
or
model.transaction,
I
think
it's
good
that
we
should
continue
to
trace
that.
I
think
it's
good
to
surface
where
the
transaction
is
starting
and
ending
in
a
trace.
D
D
I
think
it
might,
but
I
don't
know
if
anybody
has
an
idea
on
attributes
of
like
hey
you're
looking
at
trace
and
I
it
saved
like
there
was
an
error.
What
was
the
resulting
model
like
which
one
of
these
failed
like?
I
think
that
could
help
an
investigation,
but
I
don't
know
if
anyone
has
any
opinions
on
that,
and
I
would
like
to
hear
that
as
well.
C
C
Might,
I
don't
know
like
this
looks
super
stable
but,
as
you
start
grabbing
in
to
get
other
other
data
to
attach
to
it
that
might
look
progressively
worse,
you
don't
really
know
until
it
happens,
but
I
would
I
feel,
like
I
feel
like
I
would
probably
have
to
look
over
the
database
attributes,
but
I
think
these
fans
are
definitely
if
they
are
not
like
sql
or
database
fans
they're
very
closely
related,
and
they
might
be
in
some
sort
of
purgatory
between
orm
and
database
adapters
fans,
and
we
might,
we
might
just
have
to
sort
that
out.
C
A
I
think
I
think
this
is
honestly
great
to
to
to
move
forward
with.
I
wanted
to
make
sure
you
didn't
think
I
was
saying
we
should
not
do
it
in
favor
of
something
else.
I
think
this
is
absolutely
fantastic,
and
I
also
agree
that,
like
this
what's
here
is
definitely
not
going
away
anytime
soon,
like
not
getting
rid
of
save
things
like
that,
so
I
think
that's
great.
As
for
other
things
about
it,
the
only
real
thing
I
thought
was,
it
might
be
nice
to
somehow
exclude
traces
via
configuration.
A
At
least
I
know
some
of
the
internal
apps
I
run
would
generate
hundreds
of
spans
this
way
because
they
are
not
well
optimized.
To
put
it
nicely,
that
might
be
the
only
thing
worth
thinking
about
harder,
but
even
without
that,
I
think
it's
excellent
to
move
forward
with
yeah.
D
I
want
to
surface
definitely
is
configuration
options,
so
you
can
decide
if
you
what
you
including
sorry,
go
ahead.
Francis.
F
Yeah
I
just
wanted
to
I
mean
this-
may
be
something
that's
kind
of
prior
art
somewhere.
I
I
think
I
agree.
This
is
absolutely
a
great
start.
We
want
to
be
doing
this,
as
I
just
said
like
you
can
generate
a
lot
of
spans
and
those
fans
tend
to
be
of
varying
degrees
of
quality.
I've
actually
worked
in
a
and
even
talking
about
those
callbacks
of
transactions.
I've
actually
worked
with.
F
F
F
Rails
instrumentation
installed
and
turned
on
and
pointed
at
a
store
right.
How
can
I
say?
Oh
these
classes,
or
this
kind
of
controller
method
or
whatever
you
know,
trace
at
this
level
of
fidelity
versus
right
other
things,
and
I
don't
know
if
that's
that
might
already
be
in
the
spec.
That
might
be
something
related
to
the
sort
of
the
usability
work.
But
I
think
that
that
request
is
going
to
come
up
soon-ish.
D
Yeah,
I've
definitely
like
been
thinking
about
that.
I
don't
have
any
real
value.
To
add
to
that
is
that
we
are
going
to
have
to
figure
out
like
a
verbose
mode
at
some
point
or
otherwise
it's
going
to
just
be
like
a
wall
of
config
options
for
people
to
set
up
when
they
get
started,
which
sucks
too,
I
think
we've
been
pretty
mindful
of
setting
reasonable
defaults
like
we
have.
The
good
fortune
of
like
for
me
is
like
I
can
test
this
against
like
a
shopify
controller
action.
D
Shopify
is
a
pretty
big
application,
so
it's
pretty
noisy.
So
I
can
see
what
some
of
the
worst
case
scenarios
probably
look
like,
but
also
I
can
test
it
again,
simple
one.
So
I
can
try
to
like
get
some
of
that
balance,
but
yeah.
I
totally
agree.
We're
gonna
have
to
figure
something
out,
and
I
don't
know
what
that
looks
like.
D
Yet
I
think
matt
has
like
the
the
semantics
specs
up.
This
is
something
that
I
thought
about
but
didn't
dwell
on
because,
like
I
don't
know,
crappy
but
like
this
doesn't
fit
really
anywhere
into
the
spec,
because
I
don't
think
this
replaces
my
sequel
instrumentation
at
all.
Like
the
the
instrumentation
gem,
I
don't
think
I
think
it's
a
separate
concern,
but
I
don't
think
there's
a
semantic
spec
for
aurams
right.
C
That's
kind
of
where
I
was
saying
I
feel
like
this
is
in
some
another
region
between
between
whether
or
not
it
should
be
treated
exclusively
as
an
orm
or
more
as
a
of
a
database
concern.
This
might
be
a
question
for
the
instrumentation
working
group
channel
the
hotel
dash
instrumentation
channel,
but
ultimately,
thinking
back
to
what
people
things
that
I
think
people
have
found
useful
and
have
asked
for
in
the
past
on
this
sort
of
stuff.
C
I
feel
like
people
really
want
to
know
what
database
instance
core.
This
query
corresponds
to
so.
C
Information
to
identify
the
instance,
I
think
other
things
that
are
useful
are
just
knowing
you
know,
database
name
table
name.
I
believe
activerecord
has
a
pretty
easy
way
to
get
to
access
the
the
template
for
the
query
that
is
being
executed.
So
it's
already
kind
of
a.
C
E
Yeah
yeah
there
you
go,
I
think,
there's
two
modes,
maybe
that
you
can
run
in
so
sometimes
you
have
the
template
string
and
sometimes
you
only
have
the
fully
formed
statement.
I.
E
A
Github
we
have
our
our
instrumentation
has
to
manually
scrub
sql
strings,
to
make
sure
we
don't
leak
data,
but
I
know
that
rails
with
postgres
out
of
the
box
tends
to
use
typecast
fines
all
the
time.
So
I
think
it.
I
think
it
somewhat
varies
depending
on
your
adapter.
D
The
level
that,
like
at
the
persistence
level,
if
we're
patching
there,
we
don't
readily
have
available
those
things.
We'd
have
to
go
a
level
lower
and,
as
we
go
lower
we're
getting
more
into
private
apis
and
so
like
I
don't
know
if
this
is
my
place
to
decide
but
like
I
would
see
these
as
distinct
things
like
I.
D
If
you
want
to
get
that
information
like
your
your
db
statement,
which
database
instance
or
the
connection
url
or
any
of
that
stuff,
I
think
that
should
be
coming
from
your
mysql
instrumentation
or
potentially
your
postgres
or
if,
in
addition
to
this,
as
like,
we
instrument
active
support
and
we
eventually
do
the
active
support
notifications.
D
You
can
choose
whether
you
want
to
instrument
closer
to
the
database
with
like
sql
dot,
active
record
topic
and
still
use
this
higher
level
one.
I
think
that
they're,
not
one
is
not
a
replacement
for
the
other.
I
think
the
two
work
potentially
really
well
in
conjunction
but
like
maybe
someone
doesn't
care
about
low
level
database,
so
maybe
someone
does
and
like
they
don't
use
the
higher
level.
I
think
that's
kind
of
like
an
application
order
decision.
D
I
know
from
for
best
perspective
that
I
have
and
like
what
I
would
like
to
push
forward
at
shopify.
Is
you
get
both
your
your
instrumenting
persistence,
but
you
also
have
your
mysql
instrument
and
you
can
see
the
the
nitty
gritty
of
my
sequel,
but
then
you
can
also
see
the
high
level
timing
of
your
saves
and
creates.
E
Yeah
there's
in
general,
you
want
to
have
your
client
spans
as
close
to
the
wire
as
possible,
so
that
you're
you're,
measuring
that
your
communication
and
service
latency,
as
opposed
to
any
additional
work
that
you're
doing
in
the
persistence
layer
there
can
in
based
on
my
experience.
It
can
often
be
a
fair
amount
of
work
done
in
that
persistence,
layer
and
potentially
a
lot
of
allocations.
E
D
Yeah
like
in
the
case
of
when
I
was
just
working
on
this
in
my
little
test
environment,
I
said
like
an
after
commit
hook
of
like
two
seconds,
and
so
I
could
see
like
you
could
see
how
it
affected
the
timing.
So
without
this,
like
a
persistence
layer,
your
might
you
got
your
my
sequel
commits
that
are
super
fast,
but
your
quest
is
taking
super
long
as
I
started
to
fill
out
instrumentation,
it
started
to
become
a
lot
more
obvious
where
this
was
happening
and
like
that
was.
D
The
kind
of
the
scenario
I
was
looking
to
support
is
like
my
database
is
fast,
but
why
is
my
save
so
slow
right
and
it's
not
always
obvious,
and
I'm
trying
to
make
that
sort
of
thing
just
painfully
obvious
to
whoever
is
reading
the
trace.
D
I
don't,
I
know
we're
already
going
over,
but
I'll
just
kind
of
bring
it
up
and
we
want
to
discuss
it.
Maybe
someone
can
look
at
it
after
for
querying
it's
a
little
bit
awkward.
D
Just
there
is
a
model
or
a
class
just
called
querying.rb,
and
it
supports
all
the
querying
methods.
You
would
expect
an
active
record
from
fine
to
find
by
to
42
with
the
bang,
but
basically
there's
one
method
in
there
that
you
do
have
access
to
the
the
sql
you
do
have
access
to
the
binds
and
you
do
have
access
to
what
model
is
actually
initiating
this
query.
D
I
don't
know
what
to
call
it,
so
I
just
called
it
like
the
class
model
dot
find
by
sql,
but
that
kind
of
encompasses
a
lot
of
different
things.
It's
kind
of
hoping
it's
a
magical
world
that,
after
I
started
doing
it,
everything's
kind
of
naive
it'd
be
cool
if
you
could
actually
get
the
chain
of
like
queries,
you
know
when
someone
has
like
40
wares.
D
D
Like
the
the
choke
point
I
found
for
instrumenting,
the
one
that
seems
to
be
reasonable
is
there's
a
querying.rb
class,
an
active
record
and
a
method
find
by
sql
the
their
active
support.
Instrumentation
that
sits
in
that
one
is
instantiating
active
records.
So
that's
like
at
the
level
of
taking
your
row
and
turning
it
into
an
object.
D
Your
activerecord
object.
So
I
don't.
I
don't
know
that
one's
a
little
bit
closer
to
the
database
than
the
persistence
patching
that
I've
been
doing.
D
D
So
if
it's
like
a
user
model
and
you
would
have
access
to
the
user
instance
and
all
of
its
attributes,
I
don't
know
if
this
makes
sense,
but
it's
just
like
thinking
of
eventually,
people
will
probably
want
to
have
some
attributes
associated
with
these
spans,
but
because
you
know
we
can't
guarantee
that
the
model
necessarily
has
a
column
id.
You
know,
even
though
that
is
pretty
standard,
like
people
do
different
things
and
the
configuration
for
that
could
look
as
simple
as
sending
in
a
callable.
That
accepts
your
instance
and
you
could
potentially
configure
it.
D
I
don't
know
based
off
of
maybe
the
norms
of
how
your
application
is
set
up
for
shopify.
That's
a
little
bit
trickier
because
our
config
is
set
in
one
place
and
applied
to
all
the
applications,
but
for
an
individual
application
owner.
That
might
be
handy
if
they
have
like
a
convention,
like
maybe
they're,
using
uuids
instead
of
ids,
and
they
call
them
uid
or
something
I
don't
know,
and
so
people
could
set
what
attributes
on
the
spam
that
they
desire
based
off
of
maybe
conventions
of
their
application.
D
A
I
would
I
mean,
as
long
as
it
was
something
that
was
opt-in
and
not
opt-out.
I
would
personally
think
that's
potentially
useful,
but
if
it
was
opt-out
I
would
scream
and
tear
my
hair
out
and
say:
oh
my
god.
I
can't
use
this
because
how
do
I
know
they're
not
going
to
pull
out
something
that
I
can't
have
pulled
out.
You
know
but
yeah.
That
could
be
interesting
too.
That's.
D
One
of
the
things
I
think
we'll
kick
the
can
on
and
wait
for
someone
to
ask
for
before
we
add
it.
It
should
be
easy
enough
to
add.
I
don't
assume
anybody
wants
it
until
somebody
actually
asks
for
it.
I
don't
think
we
want
it
just
yet,
but
for
like
shopify's
use
cases
I'll
wait
till
someone
asks
and
actually
has
a
proven
need
for
it
before
we
start
adding
stuff.
B
Because
we're
way
over
so
I
don't
want
to
keep
trying
this
out
when
you
were
looking
into
the
implementation
of
activerecord.
I
know
you
mentioned
earlier
that
this
is
sort
of
a
it
could
be
an
improvement
on
existing
implementations.
Are
there
any
vendors
that
have
opened?
You
know
open
source,
I
guess
they're,
all
github
that
are
doing
this
approach.
Instead
of
you
know,
using
notifications.
D
Sorry
I
did
some
looking
and
I
didn't
see
anyone
taking
this
approach.
I
think
this
approach
is
like
I
think,
if
I
put
this
in
front
of
like
the
rails,
core
team,
they'd,
probably
like
yell
at
me
or
something
so
I'm
just
not
going
to
put
it
in
front
of
them
and
then
we
can
ask
for
for
goodness
later.
D
But
to
answer
your
question,
I
haven't
seen
anyone
taking
this
approach,
but
to
me
just
because
the
api
seems
so
stable,
like
it's
hard
for
me
to
say
like
this
is
a
horrible
idea,
like
you
know
the
active
support
approach.
I
understand
why
everyone
has
taken
it.
Is
it's
just
really
convenient
if
you
don't
want
to
instrument
like
every
database
adapter
like
that's
awesome,
you
get
all
the
same
information.
It's
generalized,
it's
like
there's
an
easy
hook
for
it.
D
B
Levels
I
I
just
worry:
it's
like
you're
walking
into
the
temple
of
doom
and
there's
like
the
skeletons
with
like
the
arrow
and
you're
just
yeah.
Anyway.
We
don't
want
this.
So,
okay,
I
don't
I
don't
have
like
I
yeah,
I
I
don't
have
intelligent
things
to
say
other
than
I'm.
You
know
neurotic
and
nervous
about
anything
that
new
relic
didn't
do
eight
years
ago,
which
is
which
was
matt.
So
I
don't
know
you
know
anyway
cool.
B
This
is
awesome,
though,
and
I
owe
you
a
review
on
it
at
the
very
least.
So
I'm
sorry
I've
not
been
able
to
allocate
any
time
this
week.
D
Yeah,
I
still
have
to
clean
it
up
and
move
it
out
of
draft
right
now.
I
just
wanted
to
make
sure
that
people
had
a
chance
to
look
at
it
before
we
started
talking
about
it,
so
they
could
muster
up
some
opinions
before
we
started
talking
but
yeah.
I
appreciate
the
the
worries.
I
worry
about
everything
too.
D
A
lot
of
my
testing,
as
I
was
iterating
on
this,
was
actually
just
against,
like
our
massive
core
monolith,
which
like
makes
a
laptop
melt
when
you
turn
it
on
anyways
so
like
it,
helps
enforce
my
confidence
in
it
also
because
open
telemetry
we're
not
using
it
on
our
core
monolith
yet,
and
I
was
doing
it
in
development
quite
successfully.
So,
like
everything
just
worked,
and
as
I
was
patching
it,
I
was
getting
comprehensible
traces
and
not
errors.
A
A
I
think
people
take
the
active
support
notifications
route
for
a
very
good
reason,
and
we
should
still
look
into
it
but
like
this
is
going
to
get
us
a
lot
of
useful
telemet
like
this
is
very
useful
as
it
is,
and
I
don't
think
it's
the
if
we
were
instrumenting
something
else
like
this
like
something
brand
new
like
active
storage.
I'd
be
like
we
shouldn't
touch
that
that's
not
settled.
You
know,
but
like.
D
C
Yeah,
it's
a
few
comments
on
this
approach
versus
active
support
notifications.
I
did
pull
up
the
notification
and
it
has.
It
took
me
a
minute
to
find
this,
but
that's
my
problem.
It
brought
back
some
memories
of
using
active
support
notifications
and
it
is
not.
C
It
is
not
the
best
approach,
it's
not
the
most
complete
approach.
I
remember
like
you
get
this
connection
object
and
you
actually
have
to
it's
like
a
ruby
object
and
you
have
to
like
reach
into
the
connection
to
get
a
lot
of
the
information
that
you
want
to
like
enrich
a
span
like
some
of
the
stuff
is
really
nice
like
having
the
sequel
and
the
binds
and
and
other
things,
but
I
feel,
like
you
still
had
to
like
monkey
patch
some
methods
on
activerecord
to
get
the
stuff
that
you
wanted
so
like.
C
C
One
of
the
reasons
I
did
pull
this
off.
I
just
wanted
to
see
like
what
what
attributes
are
readily
available
from
the
notifications,
and
then
I
think
that's
just
our
big
question
right
now
is
is
an
orl
like
a
database
fan
and
what
should
be
on
it,
and
should
we
expect
that
the
underlying
database
adapter
is
instrumented
and
it
will
collect
most
of
that
data,
or
do
we
expect
that
it's
uninstrumented
and
we
want
to
collect
more
of
this
from
the
orm
level.
C
But
I
think
it's
a
question
we're
not
going
to
answer
right
now,
but
I
think
it's
one
to
kind
of
talk
about.
Maybe
an
hotel,
instrumentation
and
just
keep
in
mind
as
we
work
through
this.
D
Yeah,
I
agree,
I
think,
even
in
the
future
like,
I
would
not
be
surprised
to
see
us
end
up
instrumenting
the
active
record
or
active
support
notifications
and
leave
it
to
be
the
application
owner's
choice
like
do
they
have
my
sequel,
instrumentation
or
they
just
use
active
support
because,
like
I
think
one
is
somewhat
a
substitute
for
the
other
and,
like
I
don't
see
anything
potentially
wrong
with
that
other
than
like
the
flakiness
and
painfulness
of
active
support.
But,
like
andrew
said
like
that,
isn't
something
we
should
avoid
fixing.
C
Cool
we
are
far
over
and
and
I
need
to
go
so
this
has
been
good.
I
will
try
to
get
some
eyes
on
this
and
around
see
everybody
on
slack
and
next
week.