►
From YouTube: 2022-03-08 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
C
C
Oh
cool
yeah,
I
think
I
think
it's
a
any
implementation
is
a
good.
You
know,
I
think,
there's
a
I
actually,
I'm
not
sure
what
the
right
way
to
do
it
is,
but
I
think
it's
a
good
feature.
If,
if
it's,
I
think
it's
a
good
thing
to
do.
B
C
B
Right
but
we
need
an
implementation
library
for
the
sampling
decision
and
it's
currently
not
in
the
spec
and
there's
a
lot
of
discussions
about
adding
it.
So
I
commented
there
and
I'm
waiting.
C
C
Yeah
yeah,
you
would
need
to
otherwise
you're
guessing
based
on
the
presence.
Maybe
the
presence
of
some
attributes,
it's
bad,
okay,
yeah
I
mean,
I
think
not
so
this
could
be
a
discussion
for
like
a
regular
thing,
but
I
think
if
you
know
an
approach
in
the
instrumentation
is
fine
and
if
we
improve
it
later,
that's
better.
But
you
know
anything
incrementally
good
is
good.
C
Yeah
anyway.
Sorry,
hello,
everybody
else.
C
All
right,
I
think,
rob
or
robert
or
someone
did
an
admirable
job
of
filling
in
as
well.
They
tried,
but
you
know
you
were
missed.
E
I'm
sure
yeah,
I'm
sure
whatever
happened.
It
was
at
least
as
good
as
whatever
is
going
to
happen
today,
so
yeah
a
couple
new
faces.
It
looks
like
sam
was
around
last
week
and
possibly
one
of
your
co-workers
eric.
C
Yeah
yeah
sam's
a
staff
engineer
here
and
we'll
be
getting
involved
in
ruby.
You'll,
probably
see
him
in
some
other
cigs
as
well,
go
or
js
so
but
yeah,
a
valued
member
of
the
team
and
laughs
at
my
jokes.
E
So
yeah,
I
don't
know
that
I've
seen
kirk
around
and
I
don't
think
that
I
see
him
on
last
week's
attendee.
If
this
is
your
first
time
welcome,
if
you've
been
here
more
than
once,
welcome
back
can.
D
Okay,
all
right
cool
that
wasn't
sure
yeah
yeah,
I
my
first
time
here.
I've
I've
been
doing
ruby
for
sin
over
two
decades
so
and
I'm
a
principal
engineer,
developer
relations
with
new
relic
and
looking
to
both
contribute
some
to
to
the
ruby
hotel
implementation
and
I've
been
working
on
a
complete
crystal
language
hotel
package
and
have
sort
of
used.
You
guys
work
as
inspiration.
D
You
know
see
how
you
guys
handled
some
things
before
I
go
and
handle
it.
So
you
know
killing
two
birds
with
one
stone
here.
F
I
joined
last
week
and
matt
you
weren't
around,
but
I'm
dave
from
scout
apm
we're
trying
to
get
involved
in
the
open,
telemetry
community
and
we've
been
doing
apm
specifically
for
ruby
for
about
seven
years
now,
so
looking
to
contribute
where
we
can.
E
E
On
that
note,
I
could
probably
go
ahead
and
get
started
with
the
meeting.
I
usually
just
kind
of
recap:
the
spec
sig,
which
is
kind
of
the
it's
kind
of
the
overall
group
that
is.
E
E
E
What
it
means
for
semantic
conventions
and
instrumentation
to
be
stable,
and
this
this
bullet
point
list
kind
of
summarizes
more
or
less
what
what
the
specification
changes
are,
but
basically.
E
When
I
glance
over
this,
it
looks
like
additive
changes
are
always
allowed.
It
seems
that
if
you
want
to
change
a
change
attribute,
then
you
need
to
provide
a
schema
that
kind
of
describes
the
changes.
E
E
So
I
think
that's
where
things
become
a
little
bit
more
interesting
is
I
assume
this
means
as
soon
as
something
is
declared
stable,
like
you
should
expect
not
to
change
things
for
the
next
year,
but
after
that,
as
long
as
you've
described
the
change
by
a
schema,
you're
fine,
I
think.
E
So
if
you're
interested
in
this
go
ahead
and
take
a
look,
I
think
most
vendors
probably
have
some
level
of
interest
in
how
this
will
actually
play
out
in
the
real
world.
But
the
the
whole
idea
behind
all
this
is
to
have
a
way
for
instrumentation
to
be
able
to
change
over
time
without
breaking
back
ends.
E
So
if
like
customers
have
like
alerts
on
like
a
certain
that
are
based
on
a
certain
attribute
understand,
if
the
attribute
name
has
changed,
the
alert
won't
break
as
long
as
you
understand
the
the
schema
and
are
able
to
kind
of
convert,
upgrade
or
downgrade
things
as
as
necessary.
C
E
E
E
But
people
said
this
looks
really
similar
to
the
instrumentation
library
and
there
are
several
proposals
to
kind
of
just
make
this
a
little
bit
more
generic,
so
that,
like
a
logger
name,
would
fit
there.
So,
ultimately,
we
ended
up
with
this
being
named
instrumentation
scope,
but
there
are
some
problems.
A
rename
in
the
protos
was
fine
for
protobufs.
E
There
is
otlp,
there's
a
json
format
for
otlp.
It
is
considered
unstable,
but
people
are
are
using
it
like
it's
the
only
way
to
get
spans
of
the
browser
currently,
so
a
rename
like
that
is
a
breaking
change
to
the
json
format.
So
this
was
trying
to
basically
add
in
some
backwards
compatibility
between
the
old
change
and
the
new
change
for
the
purposes
of
json.
E
It
looks
pretty
possibly
complicated,
but
that
is
but
that's
the
goal
behind
this,
so
anybody
ingesting
otlp
should
probably
take
a
look
and
just
make
sure
this
is
going
to
work
with.
This
is
going
to
work
or
something
that
you
can
deal
with
on
ingest.
E
So
then
we
got
into
the
metrics
portion
of
of
meeting
and
it
seems
like
the
biggest
problem
right
now.
Is
this
preferred
aggregation
and
preferred
aggregation,
temporality
notion
and
basically
for
metrics
there
are.
E
There
are
kind
of
like
different
paradigms.
I
guess
for
how
how
you
export
metrics
and
there's
kind
of
the
prometheus
world
where
everything
is
like
a
cumulative,
so
the
so
sdks
just
kind
of
keep
cumulative
values
and
they
send
up
those
whole
values
with
every
export
and
the
back
end
figures
out
the
difference
between
kind
of
the
previous
values
and
the
newly
received
values,
and
that's
how
that
works.
E
E
There
can
be
like
a
default
temporality
for
each
instrument,
but
users
could
configure
for
each
kind
of
instrument,
type
instrument
kind,
how
they
wanted
those
to
be
handled
as
cumulatives
or
deltas,
and
it
seems
like
this
works
out
pretty
well
for
many
of
the
instruments,
but
maybe
not
all
of
them,
I
think,
is
where
this
keeps
running
into
difficulties,
but
the
the
end
result
is.
The
discussion
was
like.
E
There
are
vendors
who
need
to
be
able
to
export
in
both
of
those
formats
and
kind
of
foregoing.
This
right
now
would
put
them
in
a
bad
bad
place,
and
so
I
think
ultimately,
there
needs
to
be
some
kind
of
decision
and.
E
E
E
Other
things
that
were
mentioned
is
that
there
is
going
to
be
a
kukan
in
spain
and
there
will
be
a
open,
telemetry
track.
I
guess
and
yeah
there'll
be
a
maintainers
track
and
some
hotel
talks.
So
if
you
are
are
going
if
you
want
to
speak.
If
anything
is
interesting
about
that,
take
a
look,
and
then
this
last
thing
was
actually
a.
E
It
was
a
late
ad,
but
probably
somewhat
relevant.
E
This
is
kind
of
a
new
process.
It's
meant
to
be
it's
being
introduced
kind
of
at
the
spec
level,
but
there
are
a
number
of
new
kind
of
like,
or
there
are
a
number
of
working
groups.
I
guess
that
have
spun
up
around
like
other
topics,
topics
or
kind,
of
course,
like
core
areas
mainly
do
with
instrumentation
like
the
messaging
spec
sig
is,
is
an
example
and
then
there's
the
semantic
convention
sig.
E
So
this
policy
or
this
proposal,
I
guess,
is
a
way
to
try
to
facilitate
movement
of
stuff
at
the
spec
level
and.
E
In
general,
the
idea
is
that
new
proposals
that
people
are
working
on
to
spec
should
have
a
sponsor
assigned
to
them,
and
the
sponsor
will
be
from
the
for
the
tc
from
the
hotel
technical
committee
and
they
will
kind
of
be
the
person
who
will
help
the
spec
author
shepherd
this
thing
through
the
whole
spec
process.
E
So
if
things,
if
things
get
stuck
in
a
variety
of
ways,
though,
the
sponsor
will
be
something
they
can
lean
on
to
help
move
things
through,
but
and
it
will
also
kind
of
help-
I
I
guess
the
other
thing
that
will
happen
is
because
sometimes
like
it
can
be
hard
to
get
feedback
on
what
you're
working
on.
Sometimes
people
just
like
keep
moving
forward,
and
then
somebody
does
actually
come
back
and
look
at
it
like
hey.
Actually,
everything
is
wrong.
E
Let's
go
back
to
the
beginning
and
try
this
again,
maybe
not
quite
like
that.
But
the
idea
is
to
not
have
that
happen
and
to
kind
of
streamline
the
process
so
that
you
know
if
things
are
off
track,
identify
that
early,
so
that
you
know
there's
a
huge
time
investment
going
down
these
paths
that
will
end
up
being
abandoned.
E
So
this
is
just
a
apr
proposing.
This
change
is
seemed
reasonable
and
like
a
good
way
to
to
move
us
through.
E
So
that
really
was
the
specs
egg
questions
comments,
concerns.
A
It's
a
little
not
concerning,
but
it's
that
interesting
to
see
some
of
the
potential
churn
coming
up
in
the
metric
stuff,
like
around
the
preferred
aggregation,
temporality
and
like
having
the
proposal
to
have
it
be
per
instrument,
makes
it
kind
of
interesting
like
having
been
trying
to
like
rock
through
the
spec
as
it
is
now.
Seeing.
Changes
like
that
coming
in
would
be
could
be
a
little
bit
frustrating
if
I
was
further
along
right,
like
that's
pretty
significant,
I
would
say
a
pretty
significant
change.
A
I
not
disputing
the
value
or
anything
like
that,
but
I'm
getting
more
and
more
of
sense
that
the
stable
and
feature
freeze
labels
were
rushed.
I
don't
know
if
that's
the
sense
you've.
Well,
I
don't
want
to
make
matt
agree
with
me,
but
I
from
the
things
you've
been
bringing
back
from
the
spec
sig
it.
It
kind
of
feels
like
that,
because
I
do
know
that
there
is
a
bit
of
pressure
to
like
push
along
the
metric
stuff,
so
it
yeah.
E
E
I
think
they
have
been
trying
to
be
very
creative,
with
the
way
that
they
have
been
handling
sections,
I
guess
of
of
the
metric
spec
as
being
stable
or
mixed
or
other
things
in
a
way
to
try
to
shore
things
up
as
soon
as
possible,
but
yeah.
I
think
it
would
be
accurate
to
say
that
maybe
some
things
have
been
have
been
perceived
as
stable
before
they
probably
are
as
stable
as
you
would
like
them
to
be,
and
the
one
could
identify
that
as
being
slightly
rushed.
E
I
think
if
you
would
have
waited
a
little
bit
longer
on
some
of
these
things,
for
some
of
these
concerns
to
arise
and
be
addressed,
then
you
wouldn't
so
much
be
in
these
situations,
but
just
to
kind
of
clarify.
I
think
I
think
the
goal
on
this
preferred
temporality
is
like
per
instrument
kind,
not
not
per
instrument,
so
I
think
like
that,
would
be
like
up
down
counter.
A
I
guess
I
should
read
the
pr,
but
I
wonder
if
it's
like
meant
to
be
as
a
like
an
override,
because
part
of
that
prefer
aggregation,
temporality
is
supposed
to
be.
There's
like
you
can
explicitly
set
it
there's
a
default
and
then
an
exporter
itself
should
be
able
to
supply
what
its
preferred
temporality
is.
So
now
again,
I
should
just
read
that
pr:
how
does
the
per
instrument
kind
interplay
with
those
four
different
things
or
those
three
different
things?
It
starts
to
feel
a
little
muddled.
E
E
It
does
seem,
like
things
are
a
little
bit
gridlocked
where
there
hasn't
been
enough
feedback
to
kind
of
get
consensus,
so
they
were
just
wanting
to
drop
this
out
of
the
initial
iteration
altogether.
But
now
there's
people
who
are
like
we
kind
of
need
this
initial
iteration.
A
Right
right
because,
like
any
any
observability
vendor
that
has
a
back
end,
that
depends
on
some
format
like
could
absolutely
be
kind
of
knocked
out
of
the
running
if
this
gets
delayed
and
their
their
preferred
choice
doesn't
get
picked
as
a
defaults
or
something
like
that
right.
So
I
could
see
that
being
quite
problematic
for
a
lot
of
people
and
I'm
sure
a
lot
of
vendors
are
doing
things
very
very
differently
on
their
back
ends
right
so
yeah.
E
Yeah
and
since
you
are
spearheading
a
lot
of
this
development
for
the
ruby
sig,
I
think
you,
you
would
be
a
good
person
to
look
at
this
and
actually
have
some
opinions
on
it.
So.
F
Aside
from
the
from
the
spec
sig,
is
there
typically
a
language
that
ends
up
being
first
to
implement
within
the
open,
telemetry
languages.
E
So
yes,
it
over
the
history
of
open
telemetry,
the
languages
that
have
kind
of
been
the
front
runners
on
certain
things
have
have
kind
of
changed,
but
metrics
has
gone
through
a
couple
of
iterations
and
it
seems
like
the
the
go
project
has
always
been
like
the
one
where
most
things
have
been
kind
of.
E
I
don't
know
prototyped
out
so,
but
on
the
most
recent
iteration
of
the
metrics
spec,
I
think
go
java
and
python
we're
kind
of
initially
prototyping
things.
So
all
three
of
them
are
maybe
a
little
bit
further
along
javascript
is
somewhere,
probably
in
between
where
ruby
and
those
other
projects
are.
E
But
having
said
that,
like,
I
think,
meaning
before
last,
we
were
kind
of
talking
asking
amongst
ourselves
like
what
other
projects
are
wants
to
kind
of
look
at,
for
you
know,
inspiration
in
this
area,
and
I
don't
know
I
was
trying
to
ask
around
and
nobody
was
saying
that
their
implementation
was
in
great
shape.
I
felt
like
at
least
from
like
the
go
community,
even
though
they
have
done
a
lot
of
the
prototyping.
I
think
they
have
enough
there
to
realize
that
they
want
to
make
some
changes
to.
E
There
so
I
guess,
I
guess
that's
kind
of
the
state
of
things
things
are
are
influx
and
nobody
feels
like
they
have
like
the
perfect
implementation
to
look
to
sure.
D
As
someone
who's
been
kind
of
playing
catch
up
and
doing
a
completely
new
implementation,
I've
found
that
I
mean
I've
used
the
ruby
implementation
where
there's
stuff
to
to
look
at
for
inspiration.
D
But
I've
found
that,
as
far
as
like
documentation
and
and
information,
you
can
go,
read
and
and
understand,
reasoning
and
that
sort
of
thing
it
seems
like
the
java
implementations
are
usually
if
the
java
implementation
is
usually
pretty
solid
around
that
and
I've
gotten
for
the
information
that
that
I
haven't.
You
know
leaned
on
your
guys's
work
for
a
lot
of
what
I
have
used
to
inspire.
My
own
work
on
the
crystal
implementation
has
come
from
java.
Just
you
know,
for
a
data
point.
D
E
Is
this
is
your
crystal
implementation?
Is
it
public
somewhere
yeah.
D
Yeah,
it
is
it's
on
github
yeah
and
why
haynes
is?
Is
my
github
handle
and
yeah?
It's
definitely
a
work
in
progress.
Traces
are
nominally
working,
I'm
sure
there's
all
sorts
of
bugs
with
it,
but
it's
nominally
working,
I
started
working
on
metrics
and
then
yeah
ran
into
you
know,
wait
what
what's
actually
happening
here.
You
know
some
of
the
stuff
you've
just
been
talking
about,
and
so
I
backed
off
of
metrics
and
I'm
looking
at
at
trying
to
get
logs
implemented
because.
D
It's
not
nearly
as
complicated
and,
and
so
you
know,
that's
what
I'm
looking
at
right
now
is
to
get
logging
implemented
and
start
getting
a
few
guinea
pigs
to
actually
start
testing
this
stuff
and
help
me
figure
out
all
the
places
where
I
did
things
wrong.
E
Cool
yeah
yeah,
I
feel
like
there
should
be
some
some
good
avenues
for
for
collaboration
with
some
of
the
people
who
have
done
the
complimentary
work
in
ruby.
So.
D
Yeah
yeah,
I
mean
you,
know
syntactically
crystal
and
ruby
are
so
similar
that
a
lot
of
the
design
decisions
and
things
like
that
yeah.
While
I
haven't
necessarily
done
the
same
thing,
you
know
I
was
able
to
look
at
what
you
guys
did
and
understand
what
you
did
and
why
you
did
it
and
you
know
helped
me,
make
decisions.
E
Yeah-
and
I
guess
once
you
feel
things
are
far
along
enough,
where
you
would
like
more
people
to
know
about
this,
I
think
we
can
start
talking
with
the
the
larger
community
to
just
kind
of
get
the
crystal
project
listed
yeah
in
the
various
places.
So
if
you
are,
if
you
are
ever
ready
for
that,
obviously.
D
That
that
is
definitely
the
goal.
I
need
to
basically
right
now
it's
public,
but
you
know
it's
it's
just
sort
of
it's
quietly
public
and
you
know
there's
before
I
draw
any
real
attention
to
it.
There's
a
bunch
of
things
to
clean
up.
You
know
a
ton
of
things
to
clean
up,
but
you
know
that's
that's
where
it's
at
right
now.
E
Cool
yeah
definitely
reach
out
to
me
or
or
or
anybody
else
when
you
feel
like
things
are
getting
getting
to
the
point
where
you
would
like
this
to
be
be
listed
and
used,
and.
D
Meanwhile,
on
on
the
ruby
side
of
things,
if,
if
there
are
specific
like
bite-sized
issues
that
need
some
attention.
D
E
Cool
yeah,
so
why
don't
we
move
on
to
things
relevant
to
the
the
ruby
project
and
see.
E
C
Hello,
the
first
one
I'll.
Let
amir
discuss
his
issue
first
one.
I
just
wanted
to
note
that
it
does
look
like
a
bug
in
postgres
instrumentation.
I've
scheduled
it
to
investigate
the
bug.
Essentially,
you
can
invoke
some
active
record
methods
that
call
our
postgres
instrumentation
with
arguments
they're
not
expecting
like
in
different
types,
and
so
what
happens?
Is
you
try
to
it?
Eventually,
we
set
as
a
span
of
tribute
a
non-primitive
value
as,
like
you
know
some
some
rails
class,
instead
of
it
being
like
a.
C
We
expect
it
to
be
a
strength
so
anyway,
I
don't.
I
all
I'm
saying
is
that
I
think
it
is
a
bug
which
shouldn't
probably
impact
most
people
unless
they're
doing
some
unholy
things
with
unholy's,
not
a
great
descriptive
term,
but
I
use
it
unless
they're
doing
unusual.
C
You
know
use
of
active
record
which
this
user's
doing,
but
the
fix
seems
pretty
straightforward.
I
just
haven't
had
time
to
get
to
it,
but
if
anyone
wants
to
pick
it
up,
I
think
it's
a
relatively
straightforward
I've
outlined
sort
of
like
what
the
solution
might
be.
Otherwise
I'll
get
to
it.
Probably
the
end
of
the
week.
B
Yeah,
I've
seen
some
weird
active
record
traces.
It's
recursively
instrumenting
itself
and
we
end
up
with
like
a
huge
tree
of
operations
for
a
single
call,
and
I
try
to
solve
it
in
node.
We
usually
solve
it
by
adding
a
instrumentation
config
to
to
be
able
to
suppress
certain
things
when
they're
not
interesting,
but
then
eric
suggested
to
do
it
with
a
custom
sampler,
which
I
really
like,
because
it
means
we
can
write
generic
code
that
will
always
work
no
matter
what
instrumentation
and
what
logic
we
need.
B
B
C
I
didn't
do
too
much
yeah.
My
only
comment
here
is,
I
think,
I'm
in
favor
of
you
had
proposed
the
initial
solution,
which
you
have
working
and
note
already
like
in
their
jskin
contrib,
which
is
like
you
attach
a
context
key
to
track
sort
of
like
whether
essentially
it's
a
middleware
span
of
active
record
seems
like
francis,
had
waited
and
said
it
seems
like
a
reasonable
approach,
which
kind
of
deferred
to
him.
I
think
it's
fine,
it's!
C
I
don't
think
we
really
use
context
in
that
way
too
often,
so
I'm
very
anxious
about
bloating.
You
know
sort
of
like
touching
context
in
ways
that,
like
aren't
very
clearly
defined,
but
it
seems
to
not
be
a
violation
of
the
specification
in
any
way
and
I'm
open
to
it.
If
it
helps
users
reduce
noisy
instrumentation,
I've.
C
Seems
I
I'd
be
open
to
it.
If
there's
a
pr,
I
don't
think
it's
a
blocker
to
me,
but
I'm
not
the
end-all,
be
you
know,
I'm
just
giving
my
opinion
and
I'd
say
like
let's
be
one
you
have
to
cut
context
is
immutable,
so
we'd
be
adding
to
context.
We
there's
some
performance
tradeoffs
there,
because
we're
making
a
copy,
but
also,
I
don't
know
I
have.
C
I
haven't,
thought
about
failure
modes
for
like
if
we're
constantly,
if
we
start
adding
lots
of
keys
to
context
whether
that
is
creates
issues
in
ways
I
haven't
thought
about,
but
it's
something
I
haven't
thought
through
clearly,
so
my
natural
reaction
is
to
be
scared
of
it.
If
that
makes
sense
anyway,
this
is
awesome
and
yeah.
Let
me
know
if
you
need
a
review
on
anything.
B
But
I
think,
regardless
of
the
verbosity
like
active
record,
it
has
a
create
function
which,
if
it's
in
been
invoked
with
a
an
array,
then
it's
recursively
calling
create
on
each
element
of
the
array,
and
then
you
end
up
with
a
create
and
a
child
of
it,
which
is
also
create
and
then
a
child
of
it,
which
is
a
new
I
think
or
safe.
It's
very
confusing.
C
Right,
regardless
of
whether
we
choose
to
add
this
context
to
track
middleware,
we
can
just
create
some
logic
and
active
record
which
says
if
this
is
an
array
or
only
trace
it.
If
the
arguments
in
array,
don't
you
know
or
something
like
that,
like
only
trace
the
individual
calls
or
only
trace
the
array
invocation,
I
would
think
we
need
to
do
the
latter,
which
is
we
don't
like
in
my
mind.
C
B
A
The
confusion
you're
seeing
is
like
it's.
The
way
active
records
seems
to
be
structured
itself,
because
I
remember
when
I
was
setting
this
up,
I
kind
of
ran
through
it.
Is
that,
like
the
same
model
like
or
like,
if
say,
you
have
an
instance
of
a
new
model
and
you
call
save
on
it
that
same
save
method
is
what
create
calls
underlying.
A
So
if
you
want
to
instrument
like
user.save
and
also
user.create
create's
going
to
call
save,
so
you
will
get
a
stand
for
that
save,
and
then
you
get
that
nesting
which,
like
you
said
it
looks
a
little
bit
awkward.
I
know
it's
awkward
and
I
kind
of
when
I
originally
did
this.
A
It
was
intended
to
be
very
much
experimental
because
previously,
like
other
instrumentation,
would
use
like
active
support
notifications,
which
would
wrap
quite
closely
to
the
database
call
right,
but
because
we
have
like
my
sql
spans
and
postgres
spans,
there
wasn't
a
lot
of
value
because
they're
so
closely
overlapping,
like
what?
What
information
is
this
actually
providing
you?
What
insight
is
it
giving
you
over
existing
spans,
the
problem
with
where
it
sits
right
now
in
its
current
state
is
I
have
not?
A
What's
actually
really
interesting,
here
is,
if
you
start
tracing
or
generating
spans
for
your
validations
or
any
callbacks
or
hooks
those
weird
little
like
create,
create
save
save
spans.
They
actually
start
filling
out
with
additional
detail
and
say
you
have
like
a
slow,
validator
or
a
slow
call
back
like
a
before
and
after
hook
it
starts
to
fill
out
that
timing.
So
you
don't
get
this
this
awkward
kind
of
like
redundant
nesting.
A
You
get
kind
of
this
filled
out
tree
of
like
oh
wow.
This
is
all
the
work,
my
rm's
doing,
that's
what
I
hoped
would
be
the
direction
of
this,
but
now
I'm
concerned
like
seeing
people
are
taking
it
on
and
they're,
not
getting
a
lot
of
value
and
they're,
seeing
that
it's
quite
noisy,
and
it's
I'm
wondering
like.
A
A
I
see
this
as
like
something
that
should
be
not
noisy
but
a
little
bit
more
verbose,
because
I
I
want
to
know
if
I'm
tracing
active
record.
It's
because
I
want
to
know
what
active
record
is
doing
and
I
want
to
know
the
implication
or
the
impact
that
all
the
junk
I've
tacked
onto
my
model
is
costing
me.
I'm
not
looking
for
just
a
really
like
one
createspan
one
save
span,
because
it
doesn't
doesn't
tell
me
anything
like
ultimately,
you're
still
just
going
to
see
a
big
gap
and
then
database
stuff.
B
Think
about
that
I
totally
agree.
I
think
that
different
users
have
different
needs
and
some
users
are.
They
want
to
just
get
an
overview
of
what's
happening
in
the
application
and
what
what's
the
duration
of
like
the
main
components
and-
and
I
I
don't
know
how
other
vendors
are
charging
for
tracing
data,
but
I
think
it's
very
common
to
charge
bell
span
and
then,
if
you
create
like,
I
don't
know,
you
do
a
single
operation
and
it
creates
a
30
spans.
B
Then
it
could
be
problematic
for
users
that
don't
need
it,
but
they
still
pay
for
it,
and
then
they
look
at
their
trace
and
it's
like
huge
traces
with
so
many
lines
and
so
many
mess
that
it's
how
to
to
find
what
you're
looking
for.
So
there
is
a
trade-off
and
I
think,
there's
no
way
one
solution
that
will
everybody
will
be
happy
with.
B
A
I
definitely
think
a
custom
sampler
that
you
can
really
tailor
to
your
application
makes
a
lot
of
sense.
We
do
like
internally
at
our
organization
we
do
have
a
custom
sampler,
one
of
the
things
you'll
you'll
run
into.
If
you
start
playing
with
this-
and
I
don't
know
if
the
spec
is
supporting
this
better
now,
I
believe
previously,
it
didn't
is,
if
you
start
plucking
spans
out
of
your
trace,
like
on
the
fly,
you're
gonna
break
your
trace.
A
So,
like
let's
say
you
have,
I
don't
know
a
couple
active
record
spans
for
like
saves
at
the
same
hierarchy,
and
then
you
have
a
bunch
of
nested,
like
my
sql
spans
that'd
be
in
there.
If
you
make
them
non-recording
expands,
I
believe,
with
how
the
api
is.
Currently,
their
parent
will
just
be
missing.
A
A
So
if
you
do
take
that
approach,
you're
going
to
have
to
do
something
odd,
like
make
your
non-recording
spans,
use
their
parent
as
their
span
id
and
you
might
have
to
hypothetically
patch
that
method
on
the
internal
span
create
to
do
that.
A
So
well,
you
I
might
have
to
look
at
it
because
I,
unless
it's
changed,
that
that
was
and
is
I
think,
of
still
a
problem.
So
I
think
at
the
time
when
we
looked
at
doing
our
custom
sampler,
the
the
spec
didn't
really
have
that
behavior
defined
in
the
way
that
work
well,
but
maybe
that's
changed
or
maybe
on
a
date.
If
you
do
look
into
this,
if
we're
wrong
and
we
need
to
update
it,
that
would
be
great
yeah.
I.
E
Yeah,
so
I
have,
I
don't
know
one
or
two
comments
just
on
this
whole
discussion
yeah,
I
think
the
the
custom
sampler
definitely
sounds
like
like
a
good
route
aside
from
maybe
not
having
instrumentation
library,
but
it
seems
like
people
are
other
people
have
this
need.
E
I
don't
know
like
whenever,
whenever
I'm
looking
at
these
kind
of
situations,
and
one
of
the
approaches
is
to
like
add
a
bunch
of
like
configuration
flags
to
instrumentation
to
kind
of
kind
of,
I
don't
know,
try
to
format
your
trace
in
the
instrumentation
code,
like
that
stuff
gets
pretty
ugly,
pretty
fast,
so
being
able
to
kind
of
like
just
let
the
instrumentation
record
the
facts
and
then
let
something
else
kind
of
like
format,
those
as
as
you
would
like
to
see
them
like,
if,
if
there
are
any
paths
that
make
that,
like
a
tenable
approach,
I
always
think
that
is
like
a
slightly
better
one,
and
I
think
I
think
hotel
has
this
problem
right
now
in
like
a
couple
of
areas,
and
I
don't
think
that
there
is
like
a
super
clean
solution.
E
An
http
call
can
be
actually
fairly
complex
and
it
can
be
a
lot
of
things
happening
under
the
hood
and
whether
that
should
be
like
individual
spans,
whether
you
should
try
to
collapse
them
all
into
a
single
span.
Somehow
or
whether
you
know
some
of
these
things
are
better
formatted
as
events
on
a
span.
E
So
I
definitely
see
some
parallels
with
that,
and
one
thing
that
I've
at
least
thrown
out
there
in
the
http
is
that
we
have
spam
processors,
but
these
actually
seem
very
poorly
designed
for
things
that
you
might
want
to
do
with
them
like.
I
feel
like
that
would
be
like
a
good
way
to
like
roll
up
a
bunch
of
like
nested
active
records
fans.
E
If
you
wanted
to
like
your
active
record,
instrumentation
could
create
all
these
nuts
and
create
spans,
but
your
processor
could
just
be
like
could
just
see
is
the
parent
to
create,
if
so,
just
like
make
it
an
event
or
just
like
you
know,
ignore
it
other
things,
but
I
don't
know,
I
feel,
like
all
these
things
are
easier
said
than
done.
B
I
think
ignoring
stuff
in
the
process
all
can
be
dangerous
because
this
context
can
be
injected
into
propagation
headers
or
it
can
be
used
in
a
in
ways
that
that
are
propagated
downstream
before
the
processor
and
regarding
the
instrumentation
air
config
versus
sampler.
So
I
totally
agree,
but
I
think
like
for,
for
a
regular
user
that
needs
this
functionality.
Plugging
in
a
custom
sampler
might
be
more
complex
to
achieve
than
just
turning
on
a
configuration
option.
B
So
there
is
a
trade-off
to
this,
but
I
personally
prefer
the
sampler
option,
but
it
might
be
because
I
don't
care
the
writing
one,
but
I
think
regular
users
might
yeah
not.
C
As
well,
I
I
don't
want
to
keep
talking
in
circles.
I
think
everything's
been
summarized.
I
think
your
explanation
is
correct,
which
is
samplers
ideally
where
this
lives,
but
it
might
be
hard
for
an
end
user
to
actually
take
that
approach
and
if
you
feel
like
this
is
like
my
personal
opinion
is
again
like
if
you
feel
like
this
is
an
issue
that
is
impacting
your
end
users.
Experience
to
the
point
that
they're,
like
you,
know,
you're,
ripping
me
off.
C
I'm
you're
charging
me
too
much
money
for
this
useless
information
or
whatever
like,
and
the
reasonable
solution
is,
like,
let's
add,
just
a
little
kind
of
hacky
config
option
to
active
record.
I'm
like
ok.
I
recognize
that,
like
it's,
not
maybe
the
perfect
thing,
but
like
I'm,
okay
with
that,
if
it
helps
you
know
like
if
there's
a
real
need
there,
but
you
know
it
sounds
like
you're,
not
at
that
point.
So
I
don't
want
to
push
anything,
but
you
know
that's.
All
I
was
wanted
to
highlight
is
like
no.
C
E
All
right,
yeah
yeah-
this
was
an
interesting
conversation,
but
you
probably
covered
most
of
the
points
and
there's
a
great
discussion
here.
E
So
yeah,
I
think,
before
we
got
into
all
this
I
know
I
know.
Kirk
was
mentioning
that
that
he's
here
interested
in
work-
and
I
think
this
is
probably
always
true
for
for
many
people.
So
I
think
most
things
do
go
into
our
backlog
and
there
are
help
wanted
things.
There
are
some
of
our
impact,
the
good
first
issue,
but
maybe
we
don't
have
a
lot
of
those
these
days,
but
I
think
for
yeah.
E
E
And
there
is
an
hotel,
ruby
channel
there
so
like,
if
you're,
just
kind
of
like
curious
about
something
or
want
to
get.
You
know
an
opinion
on
something
good
to
work
on,
or
the
approach
you're
taking
and
working
on
something
that's
a
good
place
to
kind
of
reach
out
and
yeah
most
people
that
regularly
attend
this
meeting
are
over.
There.
E
Cool
yeah.
I
just
wanted
to
mention
that
before
we
run
out
of
time
at
the
end.
But
having
said
that,
oh
we
have
five
minutes
left.
C
Can
do
you
mind
popping
open
the
pr's
I
can
see
normally,
I
would
ask
robert
to
talk
about
metrics,
but
it's
three
minutes,
so
I
don't
want
to
like
yeah
next.
C
I
have
to
review,
I
think
most
of
the
stuff
is
approved
or
good
to
go.
I
have
to
review
the
thing
from
tristan.
I
don't
know
if
that's
been
looks
like
one
of
those
is
still
open
or
people
are
already
looking
at
it.
I
guess
I
don't
know,
I
think
arielle
should
be
back
next
week,
hopefully,
but
I'm
sure
I
think
the
rail
tie
and
the
trace
metrics
reporter.
We
should
remember
not
to
forget
about
so.
C
Er,
oh
I
did
it
one
thing
I
put
an
open
issue
on
the
contrib
repo
it's
on
my
plate
to
do
in
upcoming
sprint.
I
don't
know
to
just
spike
out
moving
instrumentation
over
to
contrib.
I
think
I'm
just
gonna
pair
with
ariel
robert,
had
suggested
an
approach
which
I
think
makes
sense,
which
is
just
like,
essentially
fork
the
entire
repo
over
to
get
trip
and
then
rip
out
the
parts
we
don't
need
and
see
what
works
and
what
doesn't
so.
I've
added
an
issue.
C
I
haven't
actually
done
anything
for
this,
but
it
is
not
lost
on
me
that
it
needs
to
be
done.
So
that's
the
only
other
comment
I
have.
C
F
Most
languages
breaking
out
instrumentation
into
their
own
repos,
so.
C
Sorry,
matt
tlds.
F
What's
the
involvement
look
like
from
framework
authors
or
library
authors
at
this
point,
it
seems
like
a
lot
of
the
instrumentation
is
still
obviously
in
open,
telemetry
land
rather
than
the
actual
authors
themselves.
Have
we
seen
any
movement
or
adoption
in
anything
in
particular,.
A
No,
I
I
haven't,
I
don't
know
if
anyone
else
has
I've
started
like
trying
to
have
that
dialogue
with
the
different
maintainers
like
dolly's
a
popular
memcache
jam.
So
I
like
to
talk
to
you,
author,
a
bit
kind
of
just
putting
forward
requirements.
Some
intentions
perception
there
was
good,
but
it's
more
like
still
want
to
keep
it
generic
and
not
like
favor
one
specific
observability
library
right
or
you
know
like
to
them.
Just
open
telemetry
is
very
important
to
them.
A
Open
telemetry
is
another
thing
right,
so
that's
been
a
bit
tricky
for
for
us
to
shop
by
any
first
party
gems,
you
don't,
I
don't
think
I've
gotten
any
of
the
published,
like
the
public
ones
like
we're,
starting
to
make
it
internally
into
our
private
gems.
Hopefully,
where
appropriate,
we'll
start
stuffing
it
into
like
public
gems
and
we're
hoping
we
can
use
that
to
sway
it
a
bit.
I
I
haven't
really
taken
the
chance
to
kind
of
bombard
our
rails
maintainers.
A
Yet
with
it
I
know
the
answer
will
probably
just
be
just
use
active
support,
notifications
right,
that's
what
it's
there
for,
but
again
like
it's
tricky,
because
we
know
that
we
need
to
get
a
bunch
of
people
to
adopt
it
before
everybody
else
adopts
it
like
as
a
first
party
kind
of
or
yeah
as
a
first
party
tool
for
instrumenting.
But
somebody
has
to
make
that
first
step
and
I'm
hoping
that
we
can
leverage
some
of
our
like
chopped
my
own
stuff.
First,
because
we
know
we're
adopting
it
right.
A
C
E
Cool,
so
we
are
at
time
any
last
minute
concerns.
E
Right
well,
yeah.
It
was
good
seeing
everybody,
I
guess
we
can.
We
can
continue
to
talk
on
slack
and
see
everyone
next
week.