►
From YouTube: 2022-02-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
A
B
A
A
I
live
in
crescal,
new
jersey,
it's
a
suburb
of
new
jersey.
It's
not
too
far
from
where
I
was
my
wife's
family
is
nearby
and
we're
having
a
baby
soon,
so
she
wants
to
be
near
her
family.
A
Thank
you.
My
neighbors
are
from
tel
aviv.
Actually,
so
maybe
you
know
it's
a
small
city,
maybe
you
know.
A
I
don't
know
I
just
I
met
them.
I
forget
everybody's
name.
As
soon
as
I
met
him,
it
was
like
ella
and
I
forget
the
husband's
name.
They
were.
B
A
He's
I
think
he
works
in
finance,
I
don't
know
I
didn't
pry
too
much
finance,
maybe
I'll
ask
him
seems
they
were
very.
They
were
very
nice.
A
C
Yeah,
how
are
you
doing
what's
up
with
you
yeah?
Nothing
special
everything
is
normal
cool.
D
Yeah
we
we
have
a
look.
It's
not
the
side,
kick
instrumentation
itself
we're
having
an
issue
with
right.
Now
is
there's
another
like
gem
that
exists
in
our
company
that
they,
they
log
some
of
the
job
information
to
like
just
her
log
store
and
so
we're
appending
the
trace
id
and
the
log
payload.
So,
if
someone's
looking
at
the
logs,
they
can
jump
from
the
log
directly
to
the
trace.
D
But
what
we
think
is
happening
is
it's
pulling
the
wrong
trace
context
into
the
log,
because
we
we
don't,
we
don't
want,
run
one
long,
continuous
trace
from
our
jobs.
So
we
think
that
it's
like
grabbing
some
other
random
trace
id
that
it's
logging,
but
the
job
is
getting
emitted
or
the
span
for
that
job
is
getting
emitted
with
a
different
trace
altogether.
So
that's
kind
of
what
we're
came
up
this
morning.
D
Well,
I
we
we've
been
using
it
for
a
while,
like
the
way
it's
set
up
with
the
defaults,
and
we
were
using
it
previously
as
one
long
continuous
trace.
What
how
do
you
have
it
configured
like
what,
because
I
don't
think
anyone's
here
yet
so,
if
we
want,
we
can
just
quickly
jump
into
this.
D
B
Is
not
connected
to
a
sidekick
on
the
consumer
side
and
on
the
client
side
it's
like.
If
you
do
a
sidekick
operation,
then
the
radius
is
not
correctly
aligned
with
the
sidekick.
It's
a
sibling
instead
of
a
child,
and
then
I
wanted
to
suppress,
spend
like
because
it's
not
interesting
to
us-
and
I
can
do
it
currently.
D
Have
you
looked
at
the
patches,
I'll
link,
the
folder.
B
D
Yeah,
so
what
I
noticed
with
redis
and
sidekick
is
that
there's
a
lot
of
like
background
polling
that
happens
a
lot
of
stuff
that
happens
outside
of
the
actual
job
worker
process
that
it's
interacting
with
sidekick.
It's
kind
of
like
background
noise,
so
those
patches
a
few
of
them
are
meant
to
silence
that,
like
the
the
heartbeat,
if
you
were
to
like
turn
that
on,
it
would
be
really
really
really
noisy.
But
you
would
have
a
bit
of
context
around
these
retis
fans
and
then
it
depends.
D
B
I
haven't
figured
it
out
yet,
but
if,
if
I
get
stuck,
can
I
write
you
in
slack
to
get
help
sure.
D
Yeah
one
of
the
one
of
the
things
you
can
do
that
I
suggest
is
maybe,
if
you're
like,
if
you're
really
committed
to
going
down
this
rabbit
hole
just
like
if
you're
running
it
locally,
modify
your
redis
instrumentation
to
include
the
full
call
stack
on
the
span
like
put
put
collar
and
just
like
jam
that
into
an
attribute
running
locally.
I
wouldn't
encourage
you
to
do
that
in
production,
but
in
your
local
environment.
That's
how
I
found
a
lot
of
them
ultimately
for
the
redis
instrumentation
you'll.
D
Look
that
there's
an
option
to
disallow
root,
redis
spans.
So
basically,
if
you
have
a
trace
that
the
red
like
span
like
the
root
of
the
trace
is
redis,
which
means
you'll
you'll
end
up
with
one
span
traces
of
redis,
you
can
turn
that
off.
B
B
We
have
tons
of
those
single
spend
readys.
D
Yeah
you
you,
I
spent
probably
a
week
chasing
down
a
lot
of
them
and
the
one
those
patches
I
linked.
That's
where
I
found
it.
I
found
a
bunch
of
them,
but
even
then,
because
so
many
of
the
applications
that
we
administer
they
use
different
like
enhancements
to
sidekick
like
sidekick
scheduler
and
this,
and
that
I
wasn't
going
to
instrument
like
15
different
gems.
So
we
just
set
it
so
redis.
You
can
shut
off
the
root
spans
and
it
cleans
up
your
your
span
volume
on
redis
a
lot.
D
F
F
I
think
we
have
been
talking
at
length
about
this
instrumentation
library,
name,
slash,
scope,
name,
slash
other
things.
It
sounds
like
people
are
kind
of
coalescing
around
tigran's
solution.
Here,
there's
quite
a
few
green
checks
on
it.
I
was
reading
through
it
at
a
bit
during
the
specs
egg.
I
didn't
make
it
all
the
way
through
to
be
able
to
tell
you
everything,
that's
happening
here,
but
it
sounds
like
there
are.
There
might
be
some
implications
around
the
api
that
need
to
be
just
investigated.
I
guess
so.
E
A
I
don't
think
like,
I
think
we
can
implement
it
in
the
in
the
sdk.
Fine.
I
guess
I'm
curious,
like
seems
like
any
consumers.
It'll
break
stuff
pre
immediately,
so
is
it
gonna
be
like
a
major
version
bump
or
minor?
Like
I
don't
know,
okay,
I
guess
I'll
read
it.
Maybe
I'm
not
familiar
enough
with
what
constitutes
major
verse,
minor
first
patch
pump.
F
A
A
I
don't
know,
maybe
I
get
maybe
yeah
I
don't
know
I
don't.
I
guess
I'll
have
to
read
all
the
comments
and
stuff.
D
I
think
I
think
I
might
have
caught
this
or
maybe
I'm
missing
spot,
but
I
think
there's
like
kind
of
a
bit
of
a
loophole
where
it's
like
some
of
the
behavior
around
that
the
instrumentation
library
name
was
left
pretty
open-ended
and
it's
like
well,
it's
not
guaranteed
anywhere
so
like
it's,
not
actually
a
resource
attribute,
and
if
you
look
at
like
in
the
like
open
coverage,
ruby,
sdk
or
like
just
like
the
trace
sdk,
it
doesn't
get
passed
around
like
pretty
much
anywhere
other
than
saying
it
must
be
provided
on
like
tracer
tracer
creation
right
but
other
than
that.
D
Like
your
span
processors,
your
exporters
don't
have
access
to
that.
Informa
information.
It's
not
emitted
as
a
resource
attribute.
It's
admitted
it's
its
own.
Like
kind
of
thing,
I
don't
know
that's
kind
of
what
I've
gleaned
into
it
is
they're,
hoping
probably
to
like
sneak
this
breaking
change
in,
but
it's
like.
Maybe
it's
not
actually
breaking.
If
you
squint
hard
enough.
A
D
Yeah,
I
don't
think
anything.
We've
done
has
any
hard
dependencies
on
it.
It's
like
the
way
we've
been
consuming
like
the
existing,
not
attribute
or
whatever
you
want
to
call
it.
It's
just
like
it
allows
anybody
who's,
reading
a
trace
to
quickly
identify.
Where
did
the
span
come
from
right
like
what
was
the
responsible
for
generating
this
fan?
Was
it
my
application
or
was
it
instrumentation?
It
was
instrumentation.
A
Literally,
like
them
the
look
up
and
go
like
and
go
like.
I
want,
you
know,
maybe
they'll
alias
the
I
don't
know
go
super
well.
I
guess
you
can
use
like
alias
methods
or
whatever.
But
that's
all
that's
all
I
mean
it's
like.
I
just
don't
want
there
to
be.
Like
a
you
know,
sort
of
no
reference
yeah
anyway.
G
F
Yeah,
I
think
it
makes
sense
for
for
us
to
kind
of
read
through
this
understand
what
the
implications
are
and
just
make
sure
that
we
don't
need
to
like
break
our
api
at
a
bare
minimum
and
then
see
what
implications
there
could
be
for
for
other
things.
Downstream
of
this,
that
may
or
may
not
be
loopholed
like
tigran's
comments
here,
makes
me
think
that
things
might
be
okay
and
that,
like
they're,
keeping
the
hotel
library,
dot,
star
attributes
for
backwards
compatibility
reasons,
but
they're
deprecated
and
will
be
removed
according
to
normal
guarantees.
F
Yeah,
I
think,
reading
through
this,
and
maybe
writing
up
an
issue
of
how
we
want
to
address.
It
is
probably
a
reasonable
next
step.
F
I
guess
there's
this
experimental
metric
service
configuration
in
the
protos.
Apparently
it's
experimental,
it's
alleged
to
be
experimental
and
alleged
that
nobody's
using
it
and
it
it's
breaking
some
things
and
making
it
hard
to
like
work
work
around
some
things
in
the
proto
repo,
so
tgrin
was
just.
F
F
Johannes
has
a
pr
for
relaxing
the
specs
that
you
can
add
links
after
spam
creation
time,
like
I
think
I
brought
this
up.
You
know
last
week
or
the
week
before,
and
it
was
uncontroversial,
but.
F
Bogdan
thinks
that
we
are
opening
a
pandora's
box
just
in
terms
of
how
this
will
affect
sampling
more
or
less
like
that.
You
will
end
up
potentially
with
a
lot
of
like
broken
traces,
if
you're
not
forced
to
add
these
links
at
the
beginning,
but
it
seems
kind
of
like
a
catch-22
it
seems
like
you
know.
The
reason
that
this
needs
to
be
relaxed
is
in
order
to
accommodate
the
use
case
where
you
don't
know
up
front
what
the
links
are
going
to
be.
F
So
I
think
the
action
item
here
was
to
have
the
messaging
sig,
and
I
think,
johannes
volunteered
to
maybe
next
week,
give
just
like
a
10-minute
presentation
of
like
what
the
actual
use
cases
are.
F
I
believe
that
they
exist
and
that
there's
probably
no
way
around
being
needing
to
add
links
after
spam
creation
time,
but
I
think
I
don't
know,
I
think
maybe
others
need
to
be
convinced
a
little
bit,
that
it
is
a
good
idea.
D
A
E
A
F
Yeah,
so
if
I
were
you,
I
would
expect
to
hear
about
this
next
week.
Again,
probably
for
me,
re
retelling,
what
johannes
is
going
to
or
summarizing
what
johannes
says.
F
Moved
on
onto
metrics,
there
was
a
little
bit
of
a
talk
about
marking
the
sdk
spec
as
mixed
stable.
F
I
don't
understand
when
you
use
multiple
terms
to
specify
like
the
maturity
of
a
spec,
but
apparently
it
means
something-
and
I
feel
like
this
next
topic
really
is
kind
of
the
key
item
here
and
dovetails
in
with
the
lack
of
understanding
that
at
least
I
have
in
terms
of
kind
of
some
of
these
spec
statuses.
F
But
ultimately
it
seems
like
there
are.
F
F
F
I
don't
know,
I
think
the
words
unusable
or
something
in
those
along
those
lines
were
being
thrown
around
and
at
a
bare
minimum,
like
a
torture
to
use
so
trying
to
find
some
way
to
to
reconcile.
This,
I
think,
is
what
people
people
are
after
and
I
don't
know
I've
kind
of
just
watching
this
stuff.
F
I
know
metrics
has
been
moving
slowly,
but
I
feel
like
there
was
kind
of
like
a
push
with
some
like
milestones
and
deadlines
kind
of
this
summer,
and
I
you
get
the
impression
that
there
was
a
lot
of
deadline
driven
development
here,
and
this
is
why
we're
getting
some
of
these
like
weird
labelings,
of
like
the
spec
maturity,
is
to
kind
of
be
like
you
know
what
we
can
kind
of
loosely
say
we
get
to
sing
if
we
invent
new
terminology,
I
might
just
be
making
this
up,
but
like
that's,
that's
kind
of
an
impression
that
I
was
getting,
but
I
think
ultimately
like
one
of
the
the
big
things.
F
Is
this
multi-callback
registration
and
go
definitely
says
they
need
this?
The
java
sigs
says
that
they
need
it
and
they
have
a
prototype
and
javascript
says
that
they
would
really
like
it
and
are
working
on
a
prototype.
So
I
think
that
was
one
one
of
the
takeaways
from
this
is
that
those
three
languages
were
going
to
has
some
implementations
of
multi-callback
registration
just
to
make
sure
that
it's
a
good
idea
and
then
see
what
they
can
do
about
the
api
issues
around
supporting
that.
F
So
nobody
is
saying
that
there's
going
to
be
any
changes
to
anything,
that's
already
been
declared
stable,
but
I
think
the
the
door
might
be
open.
I
guess
if
people
agree
that
you
know
what
nobody's
actually
using
this
stuff
and
lice
would
be
made
so
much
better.
If
we
could
tweak
things
a
little
bit,
there
might
be
a
call
for.
F
For
I
don't
know,
maybe
maybe
a
new
version,
maybe
something
around
adjusting
that
api
in
some
sensible
way.
F
But
I
feel
like
this
is
stuff
that
we're
probably
like
on
the
verge
of
getting
to
and
maybe
stuff
that,
hopefully,
these
issues
are
resolved
by
the
time
our
implementation
gets
far
enough
along.
I
think
a
lot
of
them
have
to
do
with.
F
I
think
there
are
a
lot
of
corner
cases
that
start
showing
up
when
you
start
implementing
views.
That
was
what
it
sounded
like.
F
F
D
Yeah,
like
each
meter,
can
only
have
a
single
instrument
of
that
name.
So
if
you
have
like
your
tracer
or
your
meter
provider,
and
then
you
have
your
meter
and
then
you
have
two
counters.
If
you
you,
basically
just
go
by
name
like
what
is
your
counter
name,
if
you
have
a
counter
and
b
counter,
that's
fine!
But
if
you
have
two
eight
counters,
like
that's
an
error
and
it
just
it's
expected
that
you're.
D
Maybe
not,
but
you
can
also
can't
retrieve
instruments
through
a
meter
which
I
found
weird.
F
D
F
F
This
pr
is
something
to
kind
of
like
smooth
over
a
lot
of
these
corner
cases
and
also
like
improve
some
of
the
apis
for
for
idiomatic
reasons
as
well,
but
this
might
be
something
interesting
to
look
at
since
since
we're
starting
to
work
on
metrics
and
just
kind
of
diving
in,
and
I
guess
just
be
aware
of
the
issues
that
the
stuff
is
trying
to
address
so
that,
as
as
we're
as
we're
progressing
along
that
we're
not
painting
ourselves
into
a
corner
at
a
bare
minimum
and
then
maybe
it'll
be
like
kind
of
like
an.
F
I
understand
the
argument
here,
because
I
know
going
through
these
specs
sometimes
start
scratching
your
head.
Asking
yourself.
Is
this
a
good
idea?
I
know
this
is
what
is
written
here,
but
yeah.
E
F
So
yeah,
then
we
got
into
like
this
long
white
shirt
about
what
is
the
meaning
of
a
wild
card
for
the
views.
It's
a
on
the
surface,
it's
kind
of
like
a
simple
question
or
a
simple
statement.
It's
like
you
know
the
name
of
the
instrument
with
wild
card
support
and.
F
F
But
the
thing
that
was
complicating
that
is
folks
kept
bringing
up
like
what
about
configuration
from
a
file.
F
There's
like,
I
guess,
there's
a
big
desire
to
be
able
to
make
views
configurable
by
a
file,
and
I
think,
there's
always
kind
of
talk
about
just
like
making
like
everything
in
hotel
configurable
by
a
file
and
that's
where
things
start
to
break
down
a
little
bit
more.
F
So
those
those
were
a
lot
of
the
complications
that
were
talked
about
and
the
people
who
were
at
least
like
anti-regex?
They
were
saying
it
should
be
kind
of
like
shell,
globbing
and
really
the
only
two
things
that
you
should
be
able
to
are.
The
only
things
you
should
be
concerned
about
are
like
star
and
question
mark.
F
Treated
star
as
if
you
just
parsed
it
out
and
then
used
star
or
question
mark
as
the
wild
card
that
would
possibly
solve
all
use
cases.
F
But
ultimately
the
conclusion
is
that
languages
can
support
a
wild
card
and
explain
what
wild
card
is.
So
it's
kind
of
like
up
to
the
language
implementation.
F
F
So,
given
that
it's
like
you
can
kind
of
define
it,
so
you
can
have
patterns.
Regular
expressions,
predicates
and
riley
will
will
kind
of
clarify
this
in
the
spec.
I
guess.
F
D
Setting
so
I
said
like
last
week,
you
suggested
I
go
over
some
of
the
metric
stuff.
I
I'm
happy
to
do
that.
I
just
want
to
if
it
ends
up
running
longer
I
wanted
to
before
we
did
that
see
if
we
could
quickly
take
a
look
at
ariel's
pr
for
the
rail
tie.
I
left
a
comment
and
I
think
it's
just
something
that
could
probably
get
hammered
out.
D
As
a
quick
group
discussion,
I
have
like
a
a
slight
inclination
to
one's
direction,
but,
like
I'm
not
really
like
caught
up
on
it,
so
if
you
scroll
up
to
the
bottom,
I
just
kind
of
highlighted
like
a
few
different
use
cases,
but
the
the
two
ways
I
kind
of
see
it
going
and
I'm
just
trying
to.
D
Like
summarize
what
I
wrote
there
is
that
it
could
be
as
its
own
standalone
gem
and
then
the
discussion
becomes
whether
or
not
like
what
includes
this
gem,
if
it's
being
included
by
say,
like
the
rails,
instrumentation
rails,
instrumentation
package,
does
it
include
this
rail
tie?
Gem
does
instrumentation
all
include
it.
I
proceed
to
say
that
like
if
it
is
its
own
standalone
thing,
I
don't
know
if
it
really
makes
sense
to
be
directly
a
part
of
instrumentation
all
because
it
feels
like
this
isn't
necessarily
instrumentation.
D
This
is
like
a
configuration
or
an
auto
configuration
hook.
The
other
way
I
could
see
this
going
is
like
this
is
literally
just
part
of
the
rails.
Instrumentation
and
one
of
the
features
of
the
rails
instrumentation
package
is
that
it
will
configure
the
sdk
for
you,
which,
the
more
I
think
about
it,
the
more
I
think
it
makes
sense.
D
The
question
then
becomes
like:
is
this
surprising
or
unexpected
behavior
for
someone
like,
if
someone's
previously
using
this
or,
if
someone's
using
instrumentation,
all
in
their
rails,
app
and
all
of
a
sudden
it
like
configures
itself
or
it
configures
itself
twice,
because
if
they
were
doing
it
themselves
before
now,
it's
doing
automatically
for
them
like?
Are
these
things
that
we
should
be
concerned
with?
And
then
I
kind
of
like
talk
about
a
few
of
the
different
use.
Cases
is
like
or
like
imagined,
personas
of
users.
D
As
someone
who's
like,
I
want
to
get
up
and
running
quickly.
I
don't
want
to
think
about
anything
like
I
just
I'm
going
to
grab
instrumentation
all
the
rails,
app
everything
just
works.
I've
done
like
nothing,
but
I've
had.
I
realized
I've
had
to
add
an
exporter
or
something
like
that
to
it,
because
there's
no
auto
pull
and
exporter
code
or
I'm
a
rails
app.
I
pull
on
the
rails
instrumentation
because
I
just
want
to
start
with
that
as
a
baseline.
D
Again,
I
have
to
add
the
exporter,
but
I
don't
have
to
do
anything
else.
I've
just
added
this
gem
and
the
exporter,
and
I
have
like
open
telemetry
configured
and
then
there's
someone
who
wants
to
do
something
a
little
bit
more
focused,
more
opinionated
kind
of
like
I'd,
say
like
more
of
the
persona
like
we
have
a
shopify
is
like.
D
I
want
to
curate
the
configuration
everything
else:
I'm
not
going
to
pull
in
instrumentation
rails,
I'm
going
to
pull
an
active
record
and
action
pack
and
all
that
stuff
and
I'm
just
doing
it
hand
by
hand
or
so
to
speak.
Like
I'm
curating
everything
I
don't
want
that
auto
configuration
behavior.
D
I
think
it
makes
sense
to
actually
put
this
into
instrumentation
rail.
So
that's
what
I'm
leaning
towards.
But
again
I
feel
like.
I
have
a
lot
of
bias
around
this
stuff,
like
I've
spent
some
time
in
here
so
much
time
working
on
this
stuff.
Now
that
I'm
not
sure
what
like
someone
new
to
this
would
expect
and
what
would
be
the
best
experience
to
provide
them.
D
I
I
feel
like
it
might
be
to
be
putting
the
rail
tie
as
part
of
the
instrumentation
rails
package.
It's
not
a
sub
gem,
it's
just
instrumentation
rails,
ropes
and
all
its
other
sub
instrumentation
packages,
and
it
compares
the
xdk
from
you.
So
then
the
question
I'm
like
throwing
at
the
group
is
like.
Does
that
make
sense?
Is
this
what
you
guys
would
expect?
D
G
Still,
finding
a
solution
for
how
to
do
that
as
well,
and
I've
seen
how
you
know,
for
example,
the
new
relic
agent,
does
it
where
it
essentially
has
a
it
feels
block
if
you're
using
rails,
we'll
define
this
and
load.
This
rail
tie
otherwise
run
the
configuration
code
as
normal
right.
I
think
what
I'm,
what
I'm,
trying
to
what
I
as
an
end
user,
would
want
to
see
is.
G
Having
an
out-of-the-box
experience
without
having
to
meddle
with
things
as
much,
I
don't
know
that
that
answers
your
question
about
whether
or
not
the
rails,
instruc
instrumentation
should
be
the
thing
that
brings
in
the
rail
time.
G
I
went
in
the
direction
of
pulling
it
out
separately
because
I
wasn't
sure
that
it
made
sense
to
pull
it
in,
since
I
think
the
direction
that
we
wanted
to
head
with
the
rails
instrumentation
was
to
not
treat
it
as
an
all-in-one
package.
So
like
a
sub
all
in
one
package,
if
that
thinking
has
changed,
then
maybe
it
makes
sense
to
roll
it
in
there
and
obviously,
as
long
as
it
doesn't
conflict
but
yeah.
G
D
A
D
D
Maybe
this
is
just
like
its
own
gem
that
is
like
not
rails,
auto
configure
it's
just
like
the
auto
configure
gem
for
the
sdk,
and
then
I
don't
know
if
that
becomes
like
this
mishmash
of
like
it
supports
all
these
different
types
of
frameworks
and
it
becomes
kind
of
like
a
grab
bag,
best
effort
thing
which
feels
a
little
bit
weird,
but
that's
interesting.
I
just
don't
know
how
far
we
would
want
to
go
with
this
stuff
and
where,
like,
would
it
live
in
contrib?
A
I
mean
right
now
it
is
like
a
rail
tie
is
for
rails
like
that's
in
the
name.
I
don't
think
it's
so
like
you
know,
we
could
just
name
that
I
think,
if
we're
clear
about
the
package
naming
or
whatever
I
don't
know,
my
only
thing
is
like.
A
I
think
it's
not
as
big
an
issue
of
if
we,
if
we
do
include
it
in
rails,
because
well
because,
basically,
what
you
can
always
do
in
the
gem
file
is
just
like
you
can
tell
users
they're
at
the
end
of
the
day
user.
If
the
the
use
case
of
like
the
user
who's
like
copying
and
pasting
everything
you
know
or
just
like
wants
to
get
started
like
grabs.
The
one
liner
start
thing
from
our
docs
puts
it
into
his
gem
file.
A
You
can
have
a
require
statement
in
your
gem
file
that
could
bring
in
like
say
you
could
say
like
instrumentation,
all
gem
instrumentation,
all
or
gem
rails,
wherever
we
decide
to
do
it
and
then
comma
require,
and
you
can
point
to
the
rail
ties
path
and
that
could
be
like.
So
it
wouldn't
be
the
end
of
the
world
if
it
lives
in
the
rails
thing,
but
people
don't
not
everyone
wants
it.
A
You
just
wouldn't
have
that
require
block.
Here's
the
example
from
dd
trace
rb.
You
can
see
it's
like.
A
It's
not
and
it
makes
it
a
little
less
contentious
to
like
you
know,
because
then
people
can
always
just
be
like
cool.
I
want
whatever
wherever
it
lives
like.
I
want
this
package,
but
I
don't
want
to
turn
all
everything
on
automatically
like.
Then
they
just
like
won't
have
that
required
statement.
I
don't
know
the
real
thing.
D
D
I
like
that
that
require
approach,
because
then
it
becomes
part
of
the
rails
gem
and
then
you
can
optionally
allow
someone
to
just
make
a
call
to
that
require
thing
right
and
then
it
can
pull
in
the
rail
tie
and
then
it
does
magic
for
people
and
it
becomes
optional
and
it
just
to
be
documented.
And
so
it's
like
yeah.
A
D
D
Yeah
we'd
have
to
like
quickly
make
sure
it
actually
works
the
way
we
believe
it
works,
but
I
think
that
sounds
right
and
it
sounds
good
because
I
think
ariel
was
saying
is
that
like
instrumentation
rails
wasn't
gonna
like
include
anything
itself,
it
was
just
gonna
like
group
sub
things,
but
I
think
this
this.
D
I
guess
the
other
part
is.
It
depends
on
the
sdk,
whereas
instrumentation
is
not
supposed
to
that's
another
consideration.
I
don't
I'd
like
to
punt
this
a
little
bit
till
when
he's
back.
I
think
it's
hard
to
decide
this
and
I
think
that
he's
working
on
it.
I
would
like
him
to
be
involved
in
the
conversation.
I
don't
I
don't
know
it's
it's
really.
It's
a
bit
of
an
awkward
thing
that
lives
between
things
right.
It
looks
between
the
sdk
and
does
it
require.
E
A
It
almost
feels
resource
detector-ish,
but
not
a
resource
like
something
detector
anyway,
yeah
yeah.
Let's
I'm
I'm
comfortable
punting
a
little
too,
because
I
have
to
review
it
anyway,
and
this
feels,
like
you
know,
it's
not
blocking
a
review
which
you
know
this
can
end
up
living
with
ver.
You
know
we
can
still
review
and
iterate
on
the
package
and
then
move
it
at
the
end
of
the
day
somewhere.
So
that's
fine
with
me,
and
I
want
to
give
you
time
for
the
metric
stuff,
cool.
F
I
was
just
going
to
ask
one
thing,
like
my
gut
feeling
says
that
it
would
be
nice
if
it
was
part
of
of
instrumentation
rails
and
yeah,
like
eric
pointed
out
that
you
can
require
a
file
and
that
would
kind
of
kick
off
the
auto
instrumentation,
I'm
wondering
if
it
would
work
as
like
an
option
to
the
rails.
Instrumentation,
like
I
think,
there's
like
some
there's,
always
some
timing
and
load
issues
when
you're
doing
this
stuff
and
I'm
not
sure
if
you're
going
to
be
too
late
at
that
point
in
time.
F
But
that
might
be
like
a
second
option
and
it
it
could
be
one
of
these
things
that
is
kind
of
like
enabled
by
default.
If
you
kind
of
want
the
new
relic
experience
where
it
just
works,
and
then
there's
always
the
option
of
like
auto
instrument
false
or
something
that
you
could
pass
in
to
yeah
use
rails,.
D
F
I
think
would
be
an
environment
variable
but
also,
like
you
know,
an
encode
configuration
for
the
rails,
instrumentation.
A
A
I
should
probably
just
see
what
the
standard
for
options
are
for
python
and
node
like
what
are
they
giving
customers
or
users
and,
like
you
know
that
might
guide
us
to
like
what
we
really
want
to
expose
and,
like
I
don't
know
that,
can
or
maybe
protect
us
a
little
and
like
we
don't
want
to
give
people
too
much
flexibility
anyway,
we're
this
was
the
one
meeting
we
were
supposed
to
not
go
over
or
to
give
rob
a
chance
to
talk
about
metrics.
D
Yeah
I'll
try
to
not
get
very
far
got
15
minutes
and
like
eric
and
myself
have
a
heart
stop.
So
if
you
want
to
relinquish
control
of
the
share
screen,
I
can
point
at
stuff.
E
D
D
It's
asking
for
permission,
I
gave
you
permission
the
other
day
for
the
sake
of
brevity,
can
matt
take
back
control
and
share
this,
because
I
don't
want
to
make
you
guys
wait.
While
I
try
to
configure
this.
D
So
I
think,
like
the
the
first
spot
to
jump
of
interest,
is
open.
Telemetry
dash,
metrics
dash
api
rb.
D
So
this
is
going
to
look
really
familiar
to
what
we're
doing
with
the
tracer,
so
we're
using
the
openclimatry
package,
we're
providing
a
setter
for
a
meter
provider
and
we're
doing
all
that
lovely
fun
stuff
of
having
internal
proxy
meter
providers.
So
we
do
the
same
thing.
With
the
tracer
meter
provider,
we
have
a
proxy
tracer
provider.
D
What
this
allows
is
that,
if
someone
is
consuming
just
the
api,
they
can
safely
instantiate
a
meter
provider
as
well
as
a
meter,
and
when
the
sdk
is
configured
it
will
upgrade
and
it'll
provide
delegates
for
all
of
these
things.
So
this
looks
this
should
look
very
familiar
to
what
exists
in
the
tracing
package.
D
D
Moving
down
a
little
bit
to,
let's
see
like
it,
I
don't
know
if
you
guys
want
to
like
look
at
this
directly,
but
if
you're
scrolling
down
you're
looking,
you
can
actually
see
the
implementation
of
these
proxy
instruments.
It
has
again
similar
upgrade
with
add,
and
it's
just
using
the
delegate.
D
D
More
of
the
same.
I
I'm
skimming
over
this
because
I
don't
think
it's
particularly
interesting.
It's
more
of
just
like
this
is
how
it's
set
up,
but
I
think
where
it
looks
a
little
bit
more
interest
is,
if
you
go
to
the
actual
meter
rb,
you
can
talk
a
little
bit
about
that,
so
not
the
proxy
meter,
but
just
the
meter.rb
file.
D
So
looking
at
that
there
you
can
see.
This
is
more
following
the
actual
spec
here.
So
these
are
the
type
of
instruments
that
are
implemented.
This
is
the
no
op
implementation,
there's
a
fun
name,
regular
expression
that
I
hope
is
totally
accurate.
The
test
seemed
to
suggest
it
is,
and
some
random
regular
expression
website
helped
me,
but
it's
meant
to
do
the
augmented
backer
now
form
or
whatever
it's
called.
D
So
if
you
scroll
down
a
little
bit
further
here,
all
those
create
instruments
are
just
passing.
Those
like
no
ops
and
then
below.
France's
comment
is
talking
about
all
the
rules
that
need
to
be
in
place.
So
this
is
quite
a
bit
different
than
a
lot
of
the
tracer
stuff
where
it
seems
to
be
a
lot
more
forgiving.
If
you
make
a
mistake
here,
it
raises
quite
heavily
on
any
sort
of
like
you
forgot
a
name.
You
have
an
empty
name.
D
It
doesn't
find
the
format
if
you're,
not
utf-8
mv3,
if
you're
missing
a
description
or
the
size
exceeds
it,
so
a
lot
of
aggressive
validation.
Again,
this
is
like,
I
don't
think
like
nitty
gritty
interesting,
but
it
is
showing
like
the
structure
of
what
the
interface
looks
like
and
the
rules
for
creating
it.
F
F
F
I
don't
know,
there's
a
whole
can
of
worms
around
like
what
to
do
when
you
encounter
like
an
exception.
I
guess
as
a
piece
of
monitoring
software
and
I
think
in
tracing
it
was
just
like
just
never
raise
and
try
to
like
you
know,
provide
a
sensible
default
if
the
data
is
is
terrible
and
if
not
just
like
log
or
throw
it
to
like
an
error
handler
and
it
seems
like
I
don't
know,
I
don't
know
anyone
is
like
happy
with
that
experience.
F
I
think
it
was
kind
of
like
a.
I
don't
know.
I
would
say
it
is
controversial
at
best
that
people
feel
like
this.
Is
that
we're
doing
the
right
thing,
at
least
in
terms
of
tracing,
but
this
stuff
it
seems
like
you
totally,
can
raise,
but.
F
I
don't
know
my
opinion,
is
that,
like
there
should
just
be
like
no
different
behavior
between
when
you
use
the
api
and
when
you
use
the
sdk,
so
as
long
as
the
api
is
checking
the
stuff
and
raising,
then
I
think
the
user
will
not
be
surprised
either
way.
Is
that
kind
of
the
approach
that
we're
taking?
I
guess
for
now.
D
Yeah,
like
I,
I
honestly
I
find
like
the
difference
between
the
two
a
little
bit
surprising
but
yeah.
That
is
like
kind
of
the
approach
we're
taking
right
now.
I
hope
that
pieces
of
application
code
aren't
conditionally
creating
instruments
because,
like
this,
can
very
quickly
turn
into
a
runtime
error,
which
seems
to
go
against
kind
of
like
the
general
principles
here.
D
So
I
am
not
really
excited
about
this
approach
as
like
someone
who's
like
administering
this
stuff,
like
you
you're
mentioning
that,
like
the
way
like
the
trace
api
was
set
up,
was
like
everything,
just
kind
of
gets
shoot
into
an
error
handler
which
isn't
necessarily
great,
but
it
does
make
deploying
this
stuff
to
a
wide
fleet
of
code
feel
a
lot
safer
and
it
like
takes
away
a
lot
of
like
operational
stress,
whereas
this
is
gonna
introduce
a
bunch
in
my
like.
D
F
So
least,
initially
you,
you
are
somewhat
happy
with
the
way
we're
doing
things
for
tracing,
even
though
it
might
not
be
like
ideal
in
all
situations
like
it,
it's
generally
working
for
you,
you
feel
comfortable,
like
deploying
apps
with
that,
whereas,
like
this
approach
might
be,
there
might
be
a
little
bit
of
sketch
with
this
stuff.
D
That's
feels
weird
to
me,
whereas
with
the
trace
deployment
you
stuff
might
be
broken
like
yeah,
it
might
be
broken
and
that's
not
ideal.
But
what
usually
happens-
and
I
know
that
the
spec
actually
encourages
people
or
like
implementations,
to
not
do
this,
but
like
users,
get
flooded
with
open,
telemetry
error
logs
and
they
come
and
tell
us,
and
then
we
work
with
them
and
we
fix
it.
So
we're
able
to
identify
a
problem
and
resolve
it
in
a
non
cataclysmic
way,
which
I
think
has
been
really
really
easy
for
me.
D
It's
like
people
come
in
and
they
say:
hey,
I'm
noticing
this
error
or
something
wrong
say
no,
like
there's
an
issue
with
the
instrumentation.
Your
application
is
fine,
like
it's
okay,
but
we
will
correct
this
and
it
it
at
least.
For
me,
it
feels
confidence
boosting
for
people
who
are
adopting
it
because
they,
I
can
even
point
them
like
this-
has
to
be
designed
in
such
a
way
that
it
won't
introduce
runtime
errors
and
then
suddenly
people
aren't
like
is
tracing
breaking
all
my
stuff,
they're
like
oh,
okay.
D
This
is
just
something
that's
not
configured
right,
whereas
with
this
again
like
I'm
repeating
myself,
but
it's
like
someone
doesn't
know
the
api
and
they
they
start
trying
to
create
the
same
meter
over
and
over
again
and
like.
It
only
happens
on
this
one
code
path
for
some
reason
like
that.
That
becomes
scary
right.
F
Yeah,
it
seems
like
duplicate
instruments
are
probably
like
the
biggest
risk,
and
it
seems
like
somehow
they're
probably
going
to
happen
and
if
they
crash
an
app
when
it
does
happen,
that
is
not
great
and
if
you
have
to
like
always
wrap
your
instrument
creation
in
a
in
a
rescue.
That
is
also
like
not
like
an
awesome
api.
So,
yes,.
D
That
that's
how
I
feel
about
it,
I
think
like
if,
let's
say
flash
forward,
this
is
like
implemented
and
I'm
trying
to
deploy
this
at
shopify,
and
I
do
my
first
pilot
app
and
they
run
into
this.
The
first
thing
I'm
going
to
do
is
I'm
going
to
introduce
like
a
meter,
creator
helper
or
something
like
that
in
our
internal
gem.
That
says,
like
here's
a
safe
way
to
create
it,
you
either
get
a
meter
back
or
you
don't.
We
won't
blow
up
your
app
right.
D
F
Yeah,
it's
also
unreasonable,
yeah,
sorry
to
derail
this
conversation,
but
I
thought
it
was
it's
interesting
and
good
to
know
about
just
so
that,
if,
if
conversat,
if
conversations
come
up
about
this,
I
at
least
have
have
an
opinion
and
can
kind
of
bring
back.
This
experience.
I
guess
too,
to
these
other
groups
and
just
kind
of
mention
that
it
is
a
little
weird
that
things
are
a
little
bit
different
between
tracing
and
metrics
world
when
it
comes
to
error
handling
and
that
yeah
at
a
glance.
D
Yeah
right
so
like
the
way,
the
way
that,
like
it
kind
of,
threw
me
off
in
my
like
my
expectations,
and
it
is
possible
that,
like
there
has
been
some
misinterpretation
of
the
spec
right,
so
I
won't
say
that,
like
my
understanding
is
immaculate
but
like
create
counter,
I
would
expect
like
more
intuitively,
create
counter,
for
example,
it
would
just
be
like
counter
right,
so
you
have
your
meter
and
you
say,
give
me
a
counter
named
a
and
if
it
doesn't
exist,
it's
going
to
create
you
one
right
it
either
like
creates
or
retrieves
one
similar
to
how
we
are.
D
We
behave
with
meters
and
tracers.
I
don't
know
why
that
that
behavior
changed
for
instruments,
but
let's
say
you
have
like
a
counter
a
and
counter
a
and
they
have
different
units
like.
Should
that
be
an
error?
Should
those
be
separate
counters?
Can
you
have
the
same
counter
with
different
units
like
like?
I
I
don't
know
what
like
that
would
make
sense,
but
it
just
it
seems
like
a
more
consistent
experience,
even
right
like
if
you
try
to
retrieve
the
same
meter
multiple
times
you
just
it
doesn't
keep
making
new
ones.
D
It
gives
you
the
one
you
already
created,
so
this
like
explicit,
create
instrument
behavior.
I
find
really
out
of
place
with
everything
we've
seen
so
far
in
terms
of
like
tracing
and
even
meter
providers
meter
like
it's
just
like.
Why
did
it
change
here
and
maybe
I'm
missing
something
like
I'm
by
no
means
an
expert
in
the
metric
space,
but
it's
like.
A
I
wonder
if
I
wonder
if
they're
just
reporting,
whatever
the
prometheus
approaches
or
something
and
it's
like
that's,
I
can
understand
the
context
there
a
little
better
than
them
being
like.
Let's
just
create
a
different
approach.
Maybe
this
is
what
prometheus's
sdks
do
and
so
they're
like.
Well,
that's
the
most
popular
format.
So
I
don't
know
it
seems.
F
F
Yeah,
I
do
feel
like
prometheus
what
limited
experience
I
have
with
it
seems
like
you
register
all
your
instruments
like
up
front
so
like,
whereas,
like
statsd,
you
kind
of
just
like
fire,
these
metrics
off
from
anywhere
like
on
the
fly
and
then
kind
of
two
different
two
different
ideas
behind
it.
D
Yeah
we
have
to,
we
have
another
meeting
that
we
have
to
jump
to.
I
would
like
to
pick
this
up
next
week
and
continue
on.
I
think
it
gets
quite
a
bit
more
interesting
than
this
once
we
get
into
the
sdk
stuff,
and
hopefully
I
can
do
a
good
job
of
explaining
it.
Hopefully,
I've
made
a
bit
of
progress,
so
I
can
actually
like
point
at
stuff
a
bit
more.
D
E
Cool
thanks
for
doing
this,
walk
through
see
you
all
next
week,
all
right
take
care.
Everyone
bye,
guys.