►
From YouTube: 2021-11-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).
A
We're
and
eve
and
amir
you
all
work
together.
I
take
it
because
the
same
person
is
in
the
background
with
both
your
okay.
A
I
was
in,
I
was
in
tel
aviv
a
few
years
ago
for
one
of
the
microsoft
conferences
or
something
it
was
good.
Yeah,
it's
nice,
it's
first
time
you
do
like
it
yeah
yeah.
I
mean
you
know
everyone's
like
when
you
don't
make
aaliyah.
I
think
I
don't
know
because
yeah,
it's
yeah
yeah,
it's
a
beautiful.
You
know
beautiful
city,
it's
fun
everyone's
nice
to
me,
but
yeah
cool.
I
appreciate
the
the
aws
contribution
stuff.
It's
good
good,
stuff.
A
Good
good
how's
is
it
freezing
cold
in
chicago,
yet.
D
D
So
luckily
nothing
is
stuck
on
the
ground
yet
so
we
haven't
had
to
actually
deal
with
that.
It
should
be
kind
of
like
oh
look,
it's
snowing
and
then
melting
immediately,
which
is
how
I,
like
it
yeah.
It.
D
D
I
think
I
think
lake
erie
partially
freezes
over.
I
think
that
is
small
enough
to
actually
get
some
get
some
solid
ice
coverage,
but
yeah
lake
michigan
is
just
too
big
for
that
no
big
deal.
A
D
A
I
put
a
bitter
coating
on
sweet
pills
cool,
so
I
think
most
people
are
here.
Yeah
most
folks
are.
G
Cool
yeah,
I
think
most
people
are
here.
This
is
the
usual
starting
time.
It
looks
like
we
have
a
couple
of
new
faces,
or
at
least
new
to
me
faces.
I
think
I
think
we've
seen
apr
from
from
yanev
and
then
amir.
I
know
I've
seen
around
a
little
bit
welcome
if
this
is
your
first
ruby,
seg.
B
Intro,
I
guess
maybe
yeah
yeah,
so
we
are
both
working
at
the
spectre.
It's
a
small
start-up,
doing
a
tracing
around
open,
telemetry
and
we're
located
in
tel
aviv
in
israel
and
there
we
were
mainly
working
on
a
node
until
now,
but
now
we're
extending
our
support
to
ruby
as
well,
and
we
started
integrating
the
ruby
into
our
systems
and
overall,
it
works
really
good
and
everyone
are
really
friendly.
G
Awesome
thanks
yeah,
I'm
matt.
I
work
for
lightstop.
I've
been
involved
in
open,
telemetry
ruby
since
since
the
early
days,
although
I
don't
know,
I
have
less
and
less
time
to
work
on
it
as
as
time
goes
on,
but
but
I
try.
D
I
guess
I'll
go
next,
then
my
name
is
andrew.
I
used
to
work
at
github
with
aielle
was
pretty
heavily
involved
in
open,
telemetry
rubric
there.
Now
I'm
working
at
a
startup,
that's
doing
heavy
industrial
automation,
stuff
and
I'm
very
much
not
as
involved
anymore,
but
I
still
like
coming
to
the
meetings
to
chat
and
have
face
time
with
people
and
yeah.
Let's
see
who
should
go
next
tim,
you
want
to
go
next
sure
yeah
work
at
shopify
with
rob
eric
yeah.
A
I
work
with
rob
and
tim
francis
at
shopify
nice
to
meet
you.
I
K
Yes,
sorry,
I
was,
I
needed
another
layer,
it's
cold
here.
Hi,
I'm
rob!
I
don't
steal
goats,
it's
just
my
name's
sake
and
I
guess
we're
doing
introductions.
I
work
at
honeycomb
doing
tracing
because
that's
what
honeycomb
does.
K
Were
there
other
questions,
favorite
hobbies
foods
yeah,
it's.
K
J
G
Cool
well
welcome.
It's
always
exciting
to
see
new
faces,
especially
when
there's
interest
in
an
open,
telemetry,
ruby,
so
yeah
we'll
go
ahead
and
kick
off
the
meeting.
Typically,
I
don't
know
the
spec
sig
happens
before
this,
and
I
recap
quickly
what
has
happened
there.
Then
we
kind
of
move
into
talking
about
issues
a
little
more
relevant
to
our
repo,
so
so
we'll
do
that.
I
think
we'll
make
sure
to
discuss
anything
with
with
your
pr
yanov.
At
some
point.
G
The
the
specs
was
not
very
long,
so
let
me
just
get
into
it
like
the
biggest
thing
was
a
huge
bike
shed
around
the
logger
name
and
the
log
data
model.
The
conversation
started
with
the
desire
to
add
a
new
field
for
logger
name
to
the
model
and
the
bike
shutting
was
around.
Why
not
just
use
instrumentation
library
name,
and
I
don't
know
the
conversation
went
in
in
many
directions,
but
I
think
I
think
ultimately
somebody
suggested
that
maybe
it's
just
the
name.
G
So
I
think
people
generally
like
that
idea
and
so
much
so
that
I
think
there
is
at
least
talk
of
seeing
how
hard
it
would
be
to
actually
rename
this
to
instrumentation
scope
without
breaking
things.
So.
G
I
don't
know
if
we
use
like
it's
definitely
something
in
otlp
that
would
have
to
be
addressed.
I
think
it
would
be
fine
for
the
protobuf
representation
like
a
rename
would
not
kill
us
there.
If
we're
not
using
keyword,
args
anywhere,
then
we'd
probably
be
fine
there
as
well,
but
yeah.
I
think
that
decision
has
not
been
made,
but
if,
if
we
know
for
a
fact
that
this
is
exposed
somehow
in
in
hotel
ruby
in
a
way
that
would
be
breaking,
then
we
can.
We
speak
up
that
this
would
be
impossible
for
us.
G
J
So
it's
mostly
a
problem
for
exporters
that
are
reading
the
span
data.
I
suppose
spam
processes
as
well
would
have
to
deal
with
this.
G
If
that's,
if
that's
the
worst
thing,
probably
alias
the
method
and
move
forward,
I
don't
know
I
I
think
I
think
the
jury
is
out
on
whether
or
not
it
will
be
officially
renamed,
but
I
think
people
did
like
it
and
they
at
least
wanted
heavy
documentation
that
this
is
how
instrumentation
library
should
be
thought
of,
as
as
kind
of
the
scope.
K
Because
because
instrumentation
libraries
often
will
like,
if
I
know
that
a
particular
instrumentation
has
particular
field
names,
not
field
names,
attributes
on
it,
there's
like
a
schema
that
comes
along
with
each
instrumentation
library
version.
K
J
As
far
as
I
recall,
instrumentation
like
there
was
a
extensive
debate
about
instrumentation
library
versus
instrumented
library
and
the
reason
instrumentation
library
existed
was
to
enable
some
ability
to
kind
of
squash
instrumentation
like
squash,
noisy
instrumentation,
and
that's
why
it
was
instrumentation
library
rather
than
the
instrumental
library
like
a
whole
lot
of
people,
including
us,
looked
at
this
and
said:
don't
you
really
want
to
know
what
the
instrumented
library
is?
J
Doesn't
that
make
a
lot
more
sense,
but
the
whole
justification
for
it
was
that
you
it
allowed
you
to
squash,
noisy
instrumentation,
or
if
you
had
a
bad
version
of
the
instrumentation
library
you
could,
you
know,
configure
a
processor
or
something
to
stifle
that
I
don't
think
any
of
the
surrounding
infrastructure
was
ever
defined
for
it,
which
is
problematic.
G
Yeah
so
in
light
of
those
comments,
I
think
that's
one
of
the
reasons
why
actually
people
were
advocating
for
this
being
the
the
logger
name,
because,
ultimately,
it's
like
you
kind
of
want
to
do
some
of
those
similar
things
where
you
want
to
be
able
to.
You
know.
G
Kind
of
squelch
some
messages,
I
guess
from
some
loggers
or
from
some
areas
of
the
application,
and
also,
I
think,
the
other
kind
of
nice
side
effect.
I
guess
of
introducing
this-
is
that
you
have
some
logical
grouping
for
for
these
messages,
whether
there's
fans
for
your
tracing
or
you
know,
log
messages
that
you
can
kind
of
group
them
by
the
part
of
the
application
that
they're
kind
of
coming
from,
but
yeah.
G
I
guess
if,
if-
and
I
think
maybe
this
is
why
this
bike
shed
went
on
for
so
long-
is
that
I
guess
in
the
case
of
a
logger
you're
kind
of
talking
about,
if
you're,
using
that
as
the
instrumentation
library
name
or
you
know
whatever.
We
want
to
call
that
if
it
is
the
same
thing,
you're
kind
of
talking
about
this
component,
the
logger
and
no
longer
the
part
of
the
application,
the
code
in
the
application
that
is
generating
kind
of
the
message,
yeah.
K
G
G
We
are
really
reliving
this.
This
conversation
from
the
the
spec
sig,
so.
G
But
yeah,
no,
I
I
think
I
think
it's
good
that
we're
capturing
the
essence
of
that
argument.
So
there
is
this
issue
and
I
think
it
is
it
seems
like
it.
You
know
it
is
still
up
to
debate.
So
if
anybody
has
opinions
as
to
how
to
best
handle
this
feel
free
to
comment
there
or
if,
if
this
interests
you
in
general
just
follow
the
discussion
there.
G
If
not,
I
will
mention
this
20
minutes
of
time
box
metrics.
We
definitely
did
not
get
20
minutes,
because
that
conversation
on
loggername
took
took
a
really
long
time
but
yeah.
I
think
there
was
just
a
call
to
check
out
some
of
these
currently
open
prs,
but
I
think
the
biggest
discussion
was
around
prometheus
exporter.
G
Yeah,
there
are
basically
basically
establishing
some
conventions
for
metrics
that
you
can
use
to
drive
like
an
uptime
for
a
thing
it
looks
like
they
are.
G
A
I
guess
it's
just
like
broadly
confusing
to
me.
It
feels
like
there's
a
little
bit
of
like
I
don't
know.
The
word
like
two-facedness
with
like
oh
open
telemetry
is
very
strictly
scoped
to
like
transport,
it's
like
data
and
it's
like
transport
and
we,
our
scope,
doesn't
involve
anything
you
know
like
once.
It
hits
the
back
end
like
that's
outside
the
purview
and
and
there's
like
this.
A
All
this,
like
you
know,
they
changed
the
mission
statement
and
there's
like
all
this
like
back
and
forth,
but
then
it's
like
these
things
are
very
like
I
I
don't
know
like
then.
This
feels
like
something
like
very
clearly
related
to
like
alerting
you
know,
graphing
and
alerting,
which
is
outside
the
purview
of
open
telemetry.
So
it's
like
how
is
this
stuff
getting
in
the
spec
but
then
like?
A
If
someone
wants
to
come
along
and
say
like,
let's
define
how
to
you
know
what
a
storage
format
should
look
like
people
will
then
throw
their
hands
up
and
be
like
no.
That
falls
outside
the
like.
Sorry,
that's
not
open
telemetry
and
it
feels
like
it's
because
it's
convenient
to
say
it's
not
open
tom
tree
and
when
it's
not
like,
I
don't
know,
I'm
not
gonna
like
you
know.
What
am
I
gonna
do
like
come
in
here
and
like
yell
at
people
like,
but
it's
this
just
feels
like
like.
Why
is
this
in
the
spec?
A
K
Sorry,
sorry,
I
could
see
how
mentioning
these
as
use
cases,
for
it
is
useful
to
describe
uptime
in
this
way
so
that,
as
an
example,
alerting
and
graphing
can
be
done
this
way,
but
like
the
alerting
and
graphing
isn't
part
of
the
spec.
It's
the
we're
going
to
take
articulate
uptime
in
this
way
to
support
these
use
cases.
A
That's
for
me
to
say
that
it
would
be.
I
don't
think
open
telemetry
should
be
restricted
to
just
the
trend
like
it's
like.
Let's
not
pretend
that
this
isn't
like.
If
we're
going
to
like
it's
like.
Oh
it's,
it's
possible
that
this
is
how
it
could
maybe
be
used
hypothetically,
which
is
how
we're
using
it
and
like.
I
would
just
rather
say,
like
yeah,
open
plymouth.
A
You
can
define
specification
for
this
stuff
and
like
if
people
want
to
put
forth
specification
like
don't
let
other
people
come
out
of
the
woodwork
and
say
like
no,
that's
not
the
right
way
to
do.
Storage
format,
like
I
don't
know
but
yeah.
I
understand
your
point.
You're
saying
like
this,
provides
the
background
knowledge
for
why
you
have
to
make
these
metric
names
and
stuff
and
that's
fair,
but
it's
a
little
bit
like
we're,
we're
putting
we're
intentionally
being
disingenuous
to
say
that,
like
oh,
this
doesn't
cover.
K
Well,
I
think
I
think,
scoped
to
semantic
conventions.
It's
like
these
are
the
semantics
of
talking
about
up.
I
haven't
read
this
thing,
so
I
have
no
opinion
about
the
actual
bones
of
this
proposal,
but
like
for
the
semantic
invention
of
talking
about
uptime,
for
a
thing
to
come
in
this
form.
Is
the
transport
serves
these
use
cases
which
could
be?
K
A
A
K
A
Yeah
sorry
I'll
stop
wasting
people's
time.
G
I
I
think,
that's
a
fair,
fair
critique.
I
do
think
that
in
general
there
there
will
be
a
set
of
semantic
conventions
that
come
out
for
for
various
metrics,
and
maybe
maybe
it's
not
a
completely
terrible
situation
to
have
some
at
least
standards
and
conventions,
so
that.
G
Yeah
I
mean,
as
as
people
create
systems
that
emit
these
things,
that
they're
not
that's,
not
completely
the
wild
west,
I
guess,
and
that
back
ends
have
have
some
things
that
they
can
look
at,
and
developers
have
some
sort
of
guidance
for
when
they
make
these
things.
But.
E
G
Yeah,
I
think
so.
That
concludes
the
specs
egg
and
if
there's
not
anything
else,
I
know
that
yeah.
G
Janos
pr
for
aws,
sdk,
instrumentation
and
arielle
was
the
first
to
jump
on
this
last
week
and
kind
of
encouraged
me
in
a
few
others
to
take
a
look
at
it
and
yeah.
G
We
have
all
taken
a
look
it.
It's
it's
an
excellent
work.
I
think
we
pointed
out
a
few
small
details,
but
I
believe
most
of
these
have
been
fixed.
So
I'm
not
sure
I'm
not
sure
if
there's
anything
any
open
questions
we
should
go
over
or
if
anybody
else
wanted
to
take
a
look
at
this
but
yeah.
Let
me
open
the
floor
for
discussion
on
this
pr.
L
A
Yeah,
we
can
talk
about
a
little,
I
approved
it,
I
think,
or
if
I
haven't,
I
can
approve
it.
The
only
thing
I
was
waiting
on
is
yeah.
It's
like
some
we're
doing.
Some
method,
chaining
and
matt
pointed
out
like
some
of
these
might
return
nil.
Some
some
are
just
out
and,
and
so
like.
A
If
there's
a
chance,
they
could
return
nil
or
something
unexpected.
Then
we
should
use
a
safe
operator
on
it.
So
I
don't
know
offhand
whether,
like
how
the
gem
is
written,
whatever
this
like
seahorse
gem,
which
is
a
weird
name
yeah
I
see,
which
is
that.
I
A
A
Oh
yeah,
that's
a
good
question,
so
I
think
it
gets
used
in
two
places.
Is
it
gets
used
in
the
span
name,
which
is
a
and
then
as
a
span
attribute?
So
I
think
it's
okay
if
it
returns
nil
and
we
just
don't
set
the
attribute
but
for
the
span
name,
if
we're
using
interpolation,
you
know
of
like
the
return
value,
I
think
the
span
name
is
like
service
name,
which
would
be
like
dynamodb
and
then
like
operation,
which
is
like
delete
thing.
So
we
should
probably
yeah.
K
A
L
I
think
I
got
it,
I
loved
it
yeah
and
please
review
it.
A
Okay,
other
yeah,
other
than
that,
I
thought
it
was
good
work.
It's
good
to
approve.
You
know
I
think
incrementally
like
this
is
fine.
People
will
come
along
later
and
be
like.
Oh
for
sns,
we
want
to
include
these
attributes
for
sns
bands
and,
like
that's,
fine
people
can
make
those
incremental.
A
You
know,
updates
to
the
the
code
if
they
think
that
whatever
athena
aws
service
has
some
useful
attributes,
but
for
now,
like
the
only
other
required
one
was
that
d
when
it's
dynamodb
it
gets
tagged
as
db
system
and
besides
that,
there's
nothing
else
required
for
the
spec,
so
yeah.
Let's,
let's
get
the
tires
and
load
the
fires
and
yeah.
I
think.
L
L
A
I
think
that's
a
so
it's
good
to
add
it.
I
know
there's
support
for
that
in
node.
I
think
it
would
be
nice
to
see
like,
I
think,
there's
some
open
questions
around.
A
What
is
the
right
like
and
it
would
be
nice
to
have
actually
like
the
aws
folks
like
define
specification
here.
I'm
not
sure
if
there
is
specification,
but
they're
very
involved
in
optometry,
like
I
think
one
is
like.
A
What's
the
behavior
in
the
event
that
we
hit
10
message
attribute,
headers
or
whatever
it
is
like
there's
some
basically
sns
itself
has
limitations,
because
you
can
only
have
so
many
headers
so
like
what's
the
behavior
there,
I
would
like
to
see
that,
like
defined
by
nws
themselves,
instead
of
it
being
sort
of
like
it's
just
sort
of
like
become
the
law
of
the
land
based
on
these,
whatever
data
dogs
instrumentation
was
like
four
years
ago
and
then
the
other
one
is
like:
what's
the
right
way
to
handle
links
like,
should
it
be
propagated
as
a
child
span
or
propagated
as
like
a
span
link,
I
think
right
now
we
have
a
number
of
cases
where
we
let
people
define
an
option
to
say
here's
how
I
want
to
do
my
propagation
I
want
to.
A
I
want
to
propagate
as
a
link.
I
want
to
prop
where
I
want
to
do
just
parent
child
and
let
the
users
choose
like.
I
think
that's
the
right
way
to
do
it.
Is
you
just
expose
those
options
but
again
like
it
would
be
nice
if
we
especially
because
aws
is
like
so
involved
like
it
would
be
nice
if
they
de
said
like
this
is
the
way
we'd
prefer.
You
know
this
is
the
right
way
to
represent
these
services
and
then
also
batching
operations.
I
think
is
another
one
that
isn't
particularly
well
covered.
A
Is
you
can
do,
and
that
leads
to
some
complications.
So
you
know,
like
I
don't
know.
I
all
I'm
saying
is.
I
think
the
sns
sqs
propagation
is
like
non-trivial.
The
implementation
is
doable,
but
with
some
like
weird
edge
cases
that
are
non-trivial
and
people
have
defined
answers
for
sort
of
like
ad
hoc,
and
I'm
totally
fine
with,
like.
I
don't
know
if
that's
a
blocker
but
like
at
a
certain
point,
especially
if
you,
if
aspecto,
is
like
going
around
and
doing
this
and
like
node
and
ruby,
it's
like
at
some
point.
A
It
would
be
nice
if
all
the
smart
folks
from
aws
said,
like
hey,
here's
the
right,
here's
the
way
we'd
prefer
to
do
this,
because
one
day
you
know
this
is
the
way
it
might
get
officially
instrumented
anyway.
That's
my
two
cents,
sorry
for
talking
so
much.
I
had
a
second
coffee.
So
I'm
talking
about.
B
A
Okay,
perf:
that's
I'm
glad
I'm
not
they're
smarter
people.
Let
me
think
about
this
yeah
just
link
to
it
in
the
pr,
so
I
can
review
but
yeah.
Otherwise,
it's
awesome.
I
think
it's
a
super
when
I
was
at
datadog.
This
was
a
very
high
value
feature
that
customers
asked
for
until
we
gave
it
to
him
so
yeah.
I
think
it's
important
to
do.
I
I
was
going
to
add
diana
and
I
were
having
an
interesting
conversation
as
part
of
context
propagation
itself,
because
I'm
not
sure
what
the
plan
was
for.
I
mean
where
you
were
talking
about,
like
with
the
messaging
seg,
how
they
wanted
to
transport
the
context
or
transmit
the
context
between
messages,
because
I
know
that
there
was
a
constraint
where
there's
only
10
key
value
pairs
for
the
headers
fields
for
sqs
in
particular,
and
I
brought
up
the
strange
edge
case
use
case
where
it's
like
you
know.
We
support
multiple.
I
Header
fields
for
some
reason
it
would
stink
if,
like
the
instrumentation,
was
trying
to
propagate
contacts
and
ate
all
those
slots,
and
we
were
unable
to
do
that.
So
I
was
wondering
what
other
instrumentation
I
didn't
look
into
it,
yet
how
other
instrumentations
were
handling
it.
I
know
in
the
case
for
like
in
systems
where
we
don't
have
a
headers
field
like
active
job.
We
serialize
everything
in
the
payload
itself
and
deserialize
it
on
the
on
the
other
side,
but
that
would
require
like
coordination
between
multiple
sdks.
I
B
There
was
no
discussion
about
this
issue.
Actually
there
are
a
few
other
issues
which
are
a
problem,
at
least
for
sqs
like
the
the
payload
side,
because
we're
also
adding
more
bytes
to
the
message
in
the
instrumentation
and
we
can
cross
the
256k
limit
and
cause
the
message
to
be
rejected
because
of
the
instrumentation
and
and
another
issue
is
that
when
we
receive
the
message
in
sqs,
we
have
to
declare
which
message
attributes
we
want
to
get
back
so
without
dynamic,
it's
a
bit
of
a
problem
to
do
that.
B
So
there
are
issues
around
sqs,
I'm
not
sure.
If
we'll
be
able
to
solve
all
of
them.
I
think
we'll
just
to
have
to
do
a
best
effort,
so
I
guess
say,
and
if
we'll
publish
the
pr
soon
and
we
can
discuss
those
things
there
as
comments
and
try
to
see
what's
the
best
thing,
we
can
do
all
this
yeah,
but
thanks
for
bringing
it
up.
G
Yeah
I
I
echo
that
as
well
just
for
clarification
like
what
existing
sqs
instrumentation
is
there
in
in
open
telemetry
already
is:
is
there?
Is
there
one
for
node
and
are
there
any
others
like,
maybe
like
a
python
or
or
something
else.
B
I
wrote
the
one
full
node
and
I
didn't
handle
any
of
those
issues
there
and
it's
been
working
for
like
a
year
and
a
half
and
I
got
no
complaints
yet.
So
I
guess
it's
mostly
theoretical
problems
that
we're
talking
about
and
not
real
issues
that
battles
people.
B
A
C
G
Cool
yeah.
That
was
a
good
discussion
and
I
guess
good
stuff
to
keep
in
mind
when,
when
the
pr
does
does
both
come
through.
G
Cool
yeah,
so
I
think
we'll
all
be
watching
for
changes
to
come
in
and
if
anybody
else
wanted
to
look
this
over
and
give
it
a
review
you're
more
than
welcome
to
is
there
anything
else.
That
is
on
anybody's
mind
that
we
should
discuss.
B
I
have
a
general
question
regarding
the
release
time
like
if
someone
opens
a
pr,
if
there's
an
estimation
or
like
about
how
much
time
it
takes
to
review
it
and
then
to
publish
it
to
the
registry,
because
we
used
to
contribute
to
node
in
the
past
and
it
could
take
like
a
month
or
two
until
pr
is
reviewed,
and
then
the
release
cycle
would
be
like
once
a
month,
sometimes
even
more
so
until
the
pr
is
like
from
the
time
the
pr
is
sent
until
it's
published,
it
could
take
a
few
months.
B
It's
no
longer
this
way,
but
we
had
so
yeah.
J
Yeah,
so
we
have
not
been
consistent
here.
It
has
been
a
little
bit
slow
at
times
because
there's
a
smaller
pool
of
people
kind
of
reviewing
prs
here.
J
Our
release
process
has
been
a
little
bit
ad
hoc
and
if
you
need
a
release
like
if
we've
merged
something
and
we
haven't
released,
it
feel
free
to
harass
one
of
the
maintainers
and
we
will
cut
a
new
release
yeah
just
in
general,
if
you're,
not
getting
attention
feel
free
to
harass
me
or
don't
don't
really
want
to
throw
robert
under
the
bus,
but
I
will
harass
me
or
robert
on
the
cncf
slack
and
we
will
we'll
get
eric
to
review
it.
J
I
think
that's
how
delegation
works,
but
anyway,
yeah
we'll
try
to
get
this
moving
as
quick
as
we
can.
It's
just
we're,
not
always
on
top
of
things
here.
J
Amazing.
Thank
you
very
much
and
generally
like
a
smaller
pr,
is
going
to
be
easier
to
push
through
than
a
larger
one.
The
the
larger
ones,
particularly
if
you're,
adding
instrumentation
for
something
that
nobody's
familiar
with
that
can
take
a
really
long
time
to
get
through,
because
nobody
has
a
clue
how
the
gem
that
you're
instrumenting
works
and
we
have
to
go
off
and
learn
that
so
there's
there's
more
of
a
learning
curve
to
the
review
cycle.
E
Yeah,
like
hot
fixes,
like
little
fixes,
are
usually
like
it
can
be
as
simple
as
like
merge
the
fix
and
we
can
deploy
it
right
after
the
the
really
slow
ones
are
like
functionality
added
to
the
sdk
or
the
api
which
shouldn't
really
be
happening
anymore.
But,
like
anything,
that's
cross-cutting
across
multiple
gems.
E
It
probably
requires
a
big
bang
release
and
that
takes
a
bit
of
time
going
through
ci
and
like
everything,
kind
of
gets
coupled
so
that
you
have
to
release
pretty
much
everything
all
at
once
and
those
ones
are
slow
because
it's
just
a
matter
of
getting
everything
to
pass
because
everything's
pointing
at
each
other,
which
is
just
the
situation
we're
in
and
then
like
waiting
for
ci,
because
sometimes
that'll
take
like
an
hour
right
because,
like
the
windows,
runner
takes
like
40
minutes
to
be
available
or
something
like
that.
E
And
at
that
point
you
get
distracted
right
and
you
will
work
on
something
else.
So
it
those
ones
can
be
kind
of
painful.
The
ones
that
we're
not
familiar
with,
also
painful
but
like
little
fixes,
are
always
going
to
be
really
quick
and
again,
just
to
echo
what
france
said
like
if
there's
something
that's
been
merged
and
hasn't
been
released
and
you're
waiting
on
it.
It's
not
like
you
won't.
E
I
will,
I
personally
won't
be
upset
or
offended
or
annoyed
if
you're
just
like
hey,
can
you
release
this,
and
you
just
remind
me,
even
if
you
have
to
remind
me
more
than
once,
which
hopefully
doesn't
happen
like
just
go
ahead
and
do
it
because,
at
the
end
of
the
day
like
we
want
this
repo
to
be
useful
for
the
people
who
are
using
it
and
contributing
to
it
so
like
applying
pressure
to
us,
is
expected
and
welcomed.
I
L
J
Yeah
we
wrote
the
gcp
one
because
we're
running
in
gcp
at
shopify,
and
you
know
that's
the
one
that
we
we
needed
to
have
parity
with
the
trace.
Instrumentation
that
we
were
replacing.
We
like
new
resource
detectors
are
very
welcome.
F
J
There
is
some
discussion,
I
think,
rob
maybe
opened
an
issue
a
while
back
about
possibly
restructuring
resource
detectors
so
that
we
don't
just
have
a
single
resource
detectors,
gem
that
has
all
the
resource
detectors,
but
instead
have
them
broken
out
into
separate
gems.
I
can't
remember,
if
did
you
create
actually.
E
I
could
make
an
issue
I
might,
I
might
just
like
carve
out
some
time
and
just
just
go
ahead
and
do
it,
but
right
now
we
like,
if
you
added
a
resource
detector.
Anyone
who
pulls
in
this
like
auto
instrument
or
auto
resource
detection,
would
pull
in
like
aws
and
gcp,
which,
like
people
probably
don't
want
to
do.
I
don't
think
we
want
to
pull
in
things.
We
don't
need.
J
Yeah,
the
particular
the
particular
concern
is
that
if
you
have
this
auto
resource
detector,
that
has
all
of
them
in
there,
so
you
know
microsoft
and
like
azure
aws,
you
know
oracle
cloud
gcp,
all
this
stuff
in
there
then
running
through
all
of
them
at
startup,
you're
gonna
basically
be
waiting
for
timeouts
for
all
the
things
that
don't
that
that
you're
not
running
in
right.
J
J
I'm
not
sure
there
is
some
built-in
resource
detection
in
the
sdk
itself.
I
can't
remember
exactly
what
we
have
in
there.
G
Yeah
I
was
just
pulling
up
the
the
js
contrib
repo,
just
for
kind
of
like
checking
out
structure,
but
each
one
of
these
are
different
npm
package.
So
probably
we
may
want
to
adopt
something
similar.
A
I
L
J
L
No,
I
you
covered
all
my
questions.
Thank
you.
I
E
What
like
exploding
the
universe?
What
does
that
mean
like
this
just
span
volume.
E
I
Yeah
yeah
yeah,
because
I'm
getting
that
plus,
I
have
my
sql
spans,
I'm
already
running
and
it's
kind
of
like.
I
don't
need
really
both,
but
I
do
kind
of
want
some,
because
I
want
some
concept
of
like
hey
look.
This
destroys
getting
called
and
all
these
after
hooks
are
occurring
and
there's
all
these
other
dependent
destroys
that
are
occurring
as
a
result
of
that,
and
I
want
to
see
that
all
grouped
together,
because
right
now
they're
not
that's
kind
of
what
we're
experimenting
in
right
now.
I
So
folks
are
doing
manual
instrumentation
for
specific
ar
classes
to
see
their
sql
statements,
grouped
together
by
a
scope
of
something
that's
happening,
and
you
know
how
right
now
you
know
we're
able
to.
We
can
have
the
choice
of
say
just
mixing
in
the
individual
middleware
for
a
specific
faraday
instance
for
specific
middleware
is
this.
I
don't
know.
If
maybe
we
want
to
consider
making
it
possible
for
active
record
to
be
segmented,
her
child
class
and
or
for
some
class
in
the
class
hierarchy.
I
Yeah
yeah
and
in
some
cases
like
we
have
like
this
sprawl
of
like
separate
classes
that
are
subclasses
derived
classes
of
application
record
and
they
correspond
to
one
subset
of
a
shard
of
a
database
or
a
whole
database
cluster
altogether.
I
E
E
It
is
going
after
the
base
because,
like
the
assumption
was
that,
like
I
want
all
my
models,
instrumented
like
I
want
active
record
instrument
and
not
like
a
subset.
I
G
Would
this
break
if
you
could
provide
an
array
of
models
to
mix
it
into
and
if
and
the
default
is
a
single
element
with
active
record
base?
But
if
you
want
to,
if
you
wanted
to
override
that,
or
would
this
just
be
terrible.
E
It's
terrible,
I
think
it's
just.
It
becomes
a
very
specific
use
case
right
like
that's.
That's
how
I'm
thinking
about
right
now
is
it's
a
very
specific
use
case,
whereas,
like
we've
been
trying
to
take
the
approach
of
like?
What's
the
general
use
case
you
want
to
solve
for
like
how
do
we
align
allow
like
deviating
from
that
and
what
what
makes
sense
like
if
you
want
to
instrument
like
15
of
your
30
models
you
should
be
allowed
to,
but
is
that
something
that
should
be
done
like
surface
directly
through
the
configuration
of
the
instrumentation?
I
I
E
K
It
seems
like
a
step
away
from
auto
instrumentation,
but
if
there
are
a
way
to
configure
the
active
record
instrumentation
to
be
instead
of
feeding
it,
the
configuration
say,
don't
auto,
like
it's
a
don't
auto
wire
to
base,
but
then
in
any
classes
that
you
want
instrumented,
you
could
decorate
it
with
a
mix
in
and
it's
not
quite
it's
auto
and
that
you're
not
manually
instrumenting
what's
going
on
in
there.
But
you
are
saying,
like
includes,
or
whatever
into
the
into.
F
E
E
If
it's
it's
a
matter
of
just
like
you
pull
in
this
gem,
you
set
it
to
not
run
the
auto
instrumentation
and
you
pull
out
what
you
need
and
apply
it
where
you
want,
because
this
is
this
stuff
like
like
this
thing
is
like
not,
it
doesn't
feel
like
auto
instrumentation
anymore.
It's
selective,
instrumentation
right
and
I
think
maybe.
J
Yeah,
can
you
do
that
in
a
way?
That's
convenient,
so
there's
just
like
a
one
one
liner
that
you
need
to
add
to
each
of
the
classes
as
opposed
to
you
know
right
now:
you're
prepending,
what
seven
patches
so
it'd
be
nice
if
it
was
just
like
a
one-liner,
and
so
you
pull
this
in
you
disable
it
with
an
environment
variable
or
whatever,
and
then
you
explicitly.
I
J
I
E
Yeah,
I
think
that
sounds
like
kind
of
reasonable.
It's
like
you,
have
auto
instrumentation,
but
you
can
still
pull
out
the
manual
components
of
it
and
use
it
right
like
you,
can
manually,
apply
it
and
there's
like
a
reasonable
way
to
do
it
because,
like
there
is
like
all
those
patches,
but
I
also
just
wonder
at
the
same
time,
it's
like
you
could
provide
a
mix
in,
but
from
the
sounds
of
it,
some
of
it's
noisy
to
your
app
owners
like
it
could
be
that
you
only
care
about
like
persistence,
methods
right
and.
E
Allow
like
I,
I
guess
like
because
there's
how
many
permutations
of
like
these
different
pieces
do
people
want
and
at
what
point
does
it
just
make
sense
for,
like
you
create
this,
like
whatever
750
method,
patch
class,
that
you
include
into
your
models
like
you
know,
I
mean
that
you
get
like
at
this
point
already
doing
a
manual
so
pull
out
what
you
need
and
then
make
it
reusable
across
your
code.
I
just
don't
know
if
it
makes
sense
for
that
to
live
in
the
auto
instrumentation.
J
I
guess
for
auto
instrumentation:
if
you
keep
these
individual
patches,
then
people
can
choose,
to.
You
know,
apply
them
individually
to
their
classes,
assuming
they
apply
cleanly,
but
having
one
that
just
gathers
them
all
and
applies
it
as
a
one-liner
would
also
be
helpful,
like
it
could
be.
K
J
Other,
like
any
other
permutations,
I
think,
are
up
to
users
like
if
they.
If
they
want
to
get
everything
except
the
persistence
class
methods,
then
you
know
they
can
they
can
do
it
the
hard
way
or
you
know,
they've
got
a
template
to
follow,
but
we
should
make
the
the
easiest
thing
easy
right
and
then
everything
else
should
just
be
possible
by
wiring
things
up
in
different
ways
or
having
different
helpers.
I
So
if
we,
if
we
summarized,
we
would
say
we
want
to
be
able
to
say,
have
auto
instrumentation
for
everything,
have
auto
instrumentation
available
but
disabled
and
have
everything
every
capability
of
auto
instrumentation
isolated
to
a
single
class
that
it
gets
mixed
into
or
choose
your
own
adventure.
I
There
was
only
one
more
thing
I
wanted
to
bring
up
I'll,
bring
it
up,
probably
in
the
in
the
chat,
but
it
was
mostly
around
like.
I
wonder
if
there's
something
we
can
do
to
add
like
a
to
deal
with
this,
a
specific
issue
that
came
up
about
sinatra,
auto
instrumentation
from
the
outside
and
not
having
to
write
code
like
I'm
still
trying
to
wrap
my
head
around
what
the
heck
the
person
was
trying
to
do,
but.
I
A
F
A
E
I
E
Yeah,
I
know
that
I
think
that's
super.
That
approach
sounds
pretty
reasonable.
Active
record
instrumentation
is
very
near
and
dear
to
my
heart,
because
I
spend
way
too
much
time
on
it.
So
I
like
very
much
care
about
the
evolution
of
this,
because
I
still
hate
active
support
notifications
and
I
still
think
this
is
the
better
worst
version
of
this
and
I
still
think
there's
like
a
ton
of
like
interesting
work
to
be
done
in
instrumenting
or
on
orms
in
general.
E
I
I
Just
in
a
different
shape,
right
all
right,
thanks
again,
y'all
have
a
great
day
take
care
of
yourselves.