►
From YouTube: 2021-08-18 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
B
A
C
Yeah
there's
a
new
node
stock.
C
Oh,
probably
not
there,
no,
if
you
go
to
the
calendar,
invite
but
I'll
just
post
it
into
the
chat.
A
C
Yeah
I've
been
playing
around
with
that.
I
don't
have
a
thing
to
show
right
now.
It's
been
taking
me
a
bit
of
time
to
to
get
familiar
with
the
current
state
of
the
go
metric
stuff
and
all
of
that,
but
but
I
have
a
pretty
good.
I
have
a
pretty
good
idea
of
how
I
want
to
do
it
at
this
point,
but
there's
a
bit
of
trickiness
just
due
to
the
fact
of
there's
a
lot.
A
lot
of
things
are
private
and
go
that
I
would
want
to
access.
C
And
then,
basically
on
every
pass
just
have
like
a
map
of
like
basically
having
like
adding
to
our
semantic
conventions
like
a
key
map
of
like
if
you're
in
http
span,
like
here's
all
the
here's,
all
the
attribute
keys
that
represent
the
http
conventions.
C
I
pretty
sure
that's
how
the
the
go
meter
api
works,
because
you.
E
C
You
bind
the
keys
and
then
in
the
do
your
business
so.
C
In
my
prototype,
the
idea
is,
you
have
like
this
combo
object
right.
That's
basically
a
span
that
when
you
call
and
has
like
a
pre-configured
set
of
metrics
right,
that
it
emits
and
you're
defining
what
metrics
it
should
emit
by
when
you,
when
you
initialize
it,
you
say
like.
I
want
a
metered
span
that
measures
http
or
sql
or
whatever,
and
so
by
setting
it
that
configuration.
It
knows
what
key
set,
what
kind
of
metrics
instruments
it
wants
to
create,
and
then
it
knows
the
key
sets
for
like
each
metric
instrument.
C
D
E
C
Prototype
yeah,
that's
the
part
where
I'm
like
how's
this.
It's
supposed
to
work
like
like.
I
understand
the
basic
idea,
I
think
is
like
yeah,
you
create
a
meter
and
you
have
the
ability
to
then
bind
attributes
to
that
meter,
because
every
run
of
these
things
you're
going
to
want
to
have
different.
C
That
meter
is
going
to
emit
a
different
set
of
values
right
in
a
sense,
it's
like
a
slightly
different
meter
right
because
the
the
label
set
is
like
changing
slightly
and
since
the
values
in
the
label
set
are
changing
and
I
believe
that's
how
how
the
go
api
works
is
meters
have
like
a
bind
and
an
unbind
function
that
lets
you.
C
You
bind
and
unbind
them.
So,
every
time
when
you
call
span
end,
it
takes
all
the
it
binds
all
the
appropriate
attributes
to
each
meter
and
then
triggers
the
the
meter
to
do
its
thing.
So
you
have
like
a
meter
object.
That
knows
it's
like
an
http
status
counter
or
whatever
it's
supposed
to
be,
and
so
it
knows
what
things
it's
it
gets.
It
knows
how
to
grab
the
stuff.
It
wants
off
of
an
attribute
map.
Basically
and
then
trigger
whatever
kind
of
metrics
instrument
is
supposed
to
be.
C
I
don't
know
if
there's
like
a
more
efficient
way
to
do
that,
I
don't
like
having
to
copy
the
stuff
over
all
the
time.
It
would
be
nice
to
have
something
that
just
shared
the
data
structures,
but.
D
C
Yeah
yeah,
that's
yeah,
I
mean
that's,
you
can
kind
of
do
it
either
way,
but
it
you
you're
kind
of
like
passing
in
this
like
whole
blob
of
attributes
to
a
span,
and
I
think
the
way
you're
doing
it
is
you.
You
have
a
a
typed
interface
for
passing
the
the
attributes
to
the
the
span.
Essentially
you're,
like
here's,
my
http
request,
an
http
response
and
then
like
a
thing
under
the
hood,
is
like
pulling
all
that.
C
Off
which
which
makes
sense.
But
then
you
have
this
typed
typed
interface,
and
I
was
trying
to
look
at
a
way
to.
C
To
have
that
just
be
configuration
essentially
and
keep
the
existing
interfaces,
which
the
advantage
is
then
the
end
user
doesn't
necessarily
need
to
know
that
they're
using
one
of
these
things
right,
it
just
works
like
a
regular
span.
The
disadvantage,
obviously,
is
you
know
it's
possible
to.
I
think.
Maybe
all
these
have
the
possibility
of
like
you
can
get
all
the
way
to
ending
ending
the
instrumentation
object
without
having
passed
it
all
the
attributes
that
it
needed,
and
I
don't
have
like
a
good
solution
for
that.
C
D
C
Yeah,
but
it
seems
like
that
might
not
always
be
the
case
I
mean.
Maybe
it
is,
but
it
I
know
like
it
seems
like
there's,
there's
often
things
that
aren't
going
to
be
present
right,
like
the
status
quo
or
something
status
code.
The
route
slug
is
the
thing
you
would
want,
but
often
the
framework
knows
about
that.
Not
the
underlying
http
object
like
this,
and
for
that.
D
B
C
C
Depending
on
like
how
things
are
are
structured
in
the
the
code
that's
dealing
with
it,
so
it
seems
to
me
like
that's,
like
maybe
a
sort
of
inevitable
problem
that
yeah
I
mean
you
can
you
could,
I
think
maybe
you
could
solve
with
testing
if
you're
you
know,
by
having,
like
data
level,
testing
of
being
able
to
say
like
cool.
C
D
D
D
C
C
Like
I'm
saying
I
expect
these
semantic
conventions
are
going
to
be
here
and
then,
as
we
like,
add
metrics
conventions
for
those
same
semantics,
just
by
telling
it
it's
supposed
to
have
that,
then
it
will
be
like
okay
cool.
So
that
means
for
each
one
of
these
configuration
options.
You
gave
me
I'm
going
to
create
the
appropriate
suite
of
metrics
objects
and
then
they're
going
to
trigger
at
the
various
times
when
they
they
expect
to
trigger.
C
Though
I
was
thinking
they
would
all
be
able
to
trigger
at
the
end,
though,
so
that's
a
little
squiggle,
I'm
gonna
have
to
figure
out,
but
but
then
you
would
have
like
just
basically
something
that
looks
like
a
span
object.
That
also
is
just
kind
of
producing
metrics
in
the
background
and
producing
errors.
C
If
it's
missing,
if
it's
missing
attributes
that
it
knows
it's
supposed
to
need,
so
it
seemed
well
seemed
like
a
straightforward
way
of
doing
it
and
then,
at
the
same
time,
looking
at
and
go
there,
there
already
are
a
bunch
of
semantic
convention
helpers
around
things
like
http
objects,
where
you
can
like
what
you
guys
are
doing
just
like.
C
If
you
have
an
http
request
object,
you
can
basically
just
be
like
two
attribute
on
that
thing,
and
it
will
just
copy
all
the
stuff
onto
a
span
without
you
having
to
know
about
that,
which
is
why
I
was
not
creating
like
the
intermediary
object
that
you
were.
C
C
Another
meeting
on
thursday
at
8
a.m,
pacific
for
the
messaging
conventions,
and
so
my
guess
is
like
those
are
they're
scheduling
these
separate
meetings
so
that
they
have
like
specific
meetings
for
the
smes
to
go
to
like
the
subject
matter,
experts
for
those
domains
and
then
there's
a
proposal
to
have
this
meeting,
be
like
the
more
generic
instrumentation
meeting
and
some
people
did
pop
up
in
those
threads
saying
like
hey.
I
want
to
talk
about
this
stuff,
but
I'm
in
asia,
pacific
time
and
we're
kind
of
saying
like
well.
C
You
can
come
to
this
meeting,
but
I
wanted
to
double
check
with
you
in
particular
and,
like
the
other
people
come
to
this
afternoon.
Meeting
is
like
is
converting
this
to
like,
like
officially
converting
this
to
just
be
like
an
instrumentation
meeting
for
some
time
period.
C
Okay,
or
is
that
like
taking
away
valuable
time
to
like
talk
about
other
other
spec
stuff?
In
other
words
like?
Should
we
be
camping
on
this
meeting
or
do
you
want
like
to
advocate
for
like
actually
no,
we
should
have
a
separate
meeting
and
then
leave
this
meeting
for
more
generic
spec
work,
so
I
wasn't
sure
how
much
you
cared.
So
I
wanted
to
check
with
you
before
that
happens.
C
E
C
C
C
D
C
Okay,
okay,
so
we
could
do
you
want
to
just
like
have
that
one
after
this
one
or
something
like
that?
C
Maybe
yes,
that's
the
way
to
do
it.
Yeah
that
works.
Okay,
okay,
yeah
sounds
good,
and
as
for
whether
the
instrumentation
meeting
needs
to
be
like
an
hour
or
a
half
hour,
maybe
it
could
be
an
hour
for
starters,
all
right
cool
and
I
posted
a
link.
C
C
E
Sure
hi,
I'm
robert.
I
work
at
shopify
on
the
observability
team,
so
I'm
one
of
the
maintainers
for
open,
climatry,
ruby.
Most
of
my
time
is
composed
of
instrumenting
ruby
applications.
So
I'm
just
interested
to
see
what
gets
discussed
here
and
what
comes
out
of
here,
because
I
think
it's
going
to
be
very,
very
applicable
to
both
like
most
of
the
open
telemetry
ruby
group
like
rsig.
Most
of
our
time
is
about
instrumentation
stuff
that
we
discussed.
So
I
just
think
it'd
be
relevant
to
be
have
someone
present
here.
C
B
Just
trying
to
learn
more
about
what
instrumentation
means,
I
feel
like
a
better
elevator
pitch
might
be
needed.
I've
definitely
seen
this
pattern.
I've
I've
implemented
around
it.
I
have
some
ideas.
I
heard
you
trying
to
explain
some
mechanics
of
the
go
sdk
and
I
can
definitely
help
you
there.
B
It
sounded
like
if
I
was
to
invent
an
elevator
pitch
based
on
what
I
know
from
listening.
It's
something
about
wanting
to
create
a
way
to
share
state
between
sdk
components
in
ways
that,
like
don't
let
the
user
see
what
you're
sharing
but
we'd
like
to
be
able
to
get
data
from
the
beginning
of
a
span
into
some
metrics
context,
and
we
don't
really
have
a
machinery
to
do
that,
and
it's
more
it's
as
much
about
sort
of
programming
paradigm
as
it
is
about
sdk
machinery.
It
sounds
like.
C
Yeah
yeah,
okay,
so
elevator
pitch,
and
what
the
instrumentation
working
group
is
is
working
on
the
I
would
say,
there's
like
two
goals
that
are
kind
of
related.
The
one
big
goal
is
to
be
able
to
declare
the
tracing
semantic
conventions
for
starters
as
stable
and
our
tracing
instrumentation
is
stable.
C
This
is
kind
of
a
hold
up
for
adoption
in
some
corners
of
the
internet
because
they
see
that
the
data
we're
sending
is
not
stable
and
thus
like.
In
theory,
we
could
be
making
improvements
quote
unquote
in
our
instrumentation
that
thus
change
the
data
and
thus
break
all
your
dashboards,
because
we
changed
the
data
we
were
sending
and
so
that's
bad
and
we
wanted
to
come
up
with
a
solving
that
has
two
parts
one
is
like.
C
C
Are
there
further
attributes
that
we
need
to
have?
Is
there
information
on
like
span
structure
that
needs
to
be
resolved,
for
example
in
http
spans
right
when
you
have
like
spans
stacked?
On
top
of
spans,
how
do
you
deal
with
that?
Like
there's
just
some
nuance
in
there?
That
kind
of
has
to
get
dealt
with
configuration
options
is
a
kind
of
under
research
aspect
here,
right
like,
for
example,
in
database
spans
like
how
do
you
configure
whether
or
not
you're
sending
say
the
the
whole
sql
statement
stuff
like
that?
C
Like
some
of
this,
we
end
up
just
kind
of
doing
in
sampling,
but
you
know
people
want
to
be
able
to
suppress
like
noisy
health.
E
C
B
B
Which
which
attributes
which
aggregators
you
know
which
metrics
do
you
want
to
choose,
which
you
want
to
drop
and
in
this
in
the
span
world
I'd
like
to
call
it
view
configuration
it
may
not
catch,
but.
C
C
It
it
in
the
past
it
has
turned
into
a
nightmare.
It's
not
a
nightmare
in
open
telemetry
too
much
yet
because
we
just
don't
really
provide
configuration
in
general,
but
talking
to
people
from
other
cigs
like
javascript
and
python
like
they
are
starting
to
feel
this.
Where
people
are
coming
in
and
like
on
various
pieces
of
instrumentation
asking
for
like
widgets
and
hooks
and
various
things
right,
because
they
can't,
they
can't
write
that
instrumentation
like
we
wrote
that
somebody
else
wrote
that
instrumentation,
but
they
want
to
muck
with
it
somehow
and.
B
C
So
yeah
so
there's
a
pile
of
stuff
around
like
like
stabilizing
semantic
conventions
and
dealing
with
some
of
these
other
issues
around
providing
users
with
instrumentation.
Just
like
this
configuration
stuff,
then
there's.
If
we
are
going
to
stabilize
this
instrumentation,
we
may
still
want
to
change
it
in
the
future
so
like.
C
How
do
we
actually
do
that
tigran
wrote
this
schema
versioning
proposal
for
open
telemetry
so
that
you
have
schema
versions
and
so
there's
a
way
to
identify
like
if
we're
going
to
change
the
conventions
in
the
future,
then
you
can
provide
a
mapping
between
schema
versions.
So
if
an
end
user
is
like
I'm
using
schema
version
1.14
and
you
start
sending
it
1.16
data
it
could
somewhere
in
that
pipeline,
convert
it
to
114
data
so
that
their
dashboards
don't
break.
C
We've
had
and
otep's
been
accepted
for
schema
versioning,
but
I
don't
think
we've
actually
like
gone
in
there
and
like
tried
to
do
any
of
that
in
practice
and
actually
like
doing
some
of
that
in
practice
and
like
figuring
out
how
real
it
is,
is,
I
think,
a
key
element
to
being
able
to
like
sign
off
on
these
conventions
are
stable
and
here's
like
the
long-term
support,
guarantees
we're
giving
you
about
the
data
that's
coming
out
of
open
telemetry
and
like
practically
speaking,
like
here's,
how
you
you
lock
your
data
in
place.
C
If,
like
you,
really
care,
these
seem
like
just
things
we
have
to
like
think
through
or
people
are
going
to
kill
us
at
some
point
when
we
change
the
data,
because
that's
just
this
is
like
not
it's
going
to
be
unpleasant
experience
for
people.
C
So
that's
that's
like
one
big
pile
of
stuff,
and
I
think,
like
the
monday
meeting,
I
haven't
been
to
any
of
the
meetings
with
microsoft
or
aws
yet
on
this.
But
the
we're
gonna
have
some
meetings
talking
about
that
stuff,
combined
with
talking
about
meeting
with
subject
matter,
experts
to
just
go
over
each
individual
set
of
semantic
conventions
so
having
some
sequel
experts
come
in
and
having
a
look
at
like
our
sequel
conventions
and
being
like
is
this?
C
Is
this
good?
Is
this
good
enough?
What
are
we?
What
are
we
missing
here
likewise
for
like
messaging
cues,
like
kafka
and
stuff,
like
that
having
kafka
experts
come
in
and
look
at
all
that
stuff?
C
So
if
we
can
get
those
two
things
solved
like
the
nuts
and
bolts
of
like
you
know,
actually
like
the
part
on
the
open,
telemetry
side,
where
we
haven't
fully
defined
things
like
like
schema
versioning
and
all
of
that
and
configuration
getting
that
like
actually
thought
through,
so
we
feel
confident,
we
know
what
it
is
and
then
getting
the
individual
blocks
of
conventions
reviewed
by
experts
and
then
signed
off
on.
So
we
can
say
this
is
like
the
first
stable
version.
C
That's
all
the
work
we
need
to
do
in
order
to
say,
like
our
data
is
stable.
So
that's
like
one
big
thrust
of
work
that
I
think
most
of
people
in
the
group
are
going
to
be
working
on,
which
is
why
we
have
multiple
meetings,
because
it's
a
lot
of
work.
C
C
There's
this
mess
that
kind
of
occurs,
which
is
well
one.
Your
writing
now,
just
like
stacks
of
instrumentation
code,
where
you've
got
all
of
your
your
span
stuff
and
then
right,
underneath
it
you're
you're
having
to
generate
a
bunch
of
metrics
objects,
and
then
you
have
the
metrics
conventions
for
http
and
you
have
to
generate
all
of
those
things
correctly,
and
so
that's
like
an
even
bigger
pile
of
stuff.
You
have
to
to
keep
straight
if
you're
gonna
implement
this
correctly.
C
E
B
Me
because
I've
seen
it
go
badly.
I've
seen
it
go
well,
and
I
do
think
that
we've
maybe
failed
to
capture
our
concept
in
open
summary
that
might
fall
out
of
this
and
it's
something
that
doesn't
belong
in
the
user's
hands.
It's
not
something
that
we
add
a
feature
and
the
user
gets
more,
it's
something
where
we
add
a
spec
that
the
sdk
component
gets
more
somehow.
I
think.
C
B
B
That
applies
to
the
stuff
I'm
doing
and
like
at
the
moment,
when
I'm
building
the
it
that
first
time
I
I
paid
the
cost
of
my
instrumentation,
the
biggest
part
of
instrumentation
cost
is
just
building
the
attribute
set,
and
now
I'm
going
to
pass
it
to
my
span,
but
it's
in
effect
for
every
one
of
my
metrics
operations
in
some
ways,
but
I
said
in
some
ways
and
it's
just
a
little
complicated
at
that
point.
You've
got
to
talk
about
scope
and
context
and
all
those
things.
C
So
I
I
put
a
link
to
onorag's
proposal
into
the
chat.
I'm
gonna
slack
it
to
you
josh.
Since
I
see
you're
on
the
phone
yeah,
I
I've
I've
seen
the
chat,
yeah
actually
yeah,
so
so
this
is
one
one
proposal,
but
just
just
to
back
up
a
second
to
explain
like
the
problem.
We're
trying
to
solve
is
like
it's
one
yeah
like
trying
to
just
remember
all
the
metrics
you're
supposed
to
emit.
C
If
it's
an
http
span
like
this
just
turns
into
like
a
lot
of
junk
for
people
to
manage,
but
it's
like
pretty
mechanical
right,
like
we've
already
predefined.
All
of
this
stuff
so
like.
Why
are
we
making
instrumentation
authors
have
to
like?
Look
it
all
up
in
the
spec
and
like
get
it
right
like
there
should
be
some
way
to
package
all
this
stuff
up
better,
so
that
it's
easier
to
just
get
right.
C
And
then
you
get
into
the
fact
that,
like
you,
the
straw
that
broke
the
camel's
back
for
me
was
like
request,
duration,
where
it's
now
like
you,
have
a
span
recording
the
duration
and
you
want
to
like
produce
a
metric
for
that
duration,
which
okay,
fine,
you
know
you're
sending
the
stuff
to
do
different
places.
So
you
want
a
metric
for
two,
but
we're
kind
of
like
forcing.
A
C
C
Turned
off
like
if
the
system's
turned
off
then
like
they
still
have
all
this
overhead
from
like
having
all
these
timers
and
like
like
that's
just
like
that.
Just
gets
into
crazy
space
and
if
you
think.
C
E
B
The
most
efficient
interface
for
entering
that
single
event
might
be
just
literally
to
enter
a
single
telemetry
event
from
which
you
could
define
any
number
or
derive
any
number
of
metric
events
corresponding
to
each
of
the
columns
in
this
multivariate
event.
So
potentially-
and
this
is
I-
I
don't
want
to
try
and
slow
us
down
in
any
ways
but
like
potentially
the
answer
to
your
question,
is
you
instrument
your
http
request?
B
One
time
and
you
know
it
creates
one
event
which
is
both
a
span
and
a
bunch
of
metric
events
and
a
single
attribute
set
all
at
once,
but
that
doesn't
necessarily
make
the
problem
easier.
You
still
have
like
this.
The
attribute
event
starts
during
the
beginning
of
the
span
and
then
you
might
add
attributes
as
you
go
and
then
by
the
end,
you've
got
your
status
code
and
dynamic
you're.
C
C
B
Yeah
lightstep
has
one
that
I
was
mostly
involved
with
trading
like
five
years
ago,
where
there
there
is
a
user
level
api,
and
I
call
it
scope,
which
is
again
why
I
and
I
created
that
resource
scope
proposal
a
year
and
a
half
ago,
basically
lifting
the
idea
out,
which
is
like,
in
my
context
somehow,
as
I
start
a
span,
I'm
also
going
to
put
in
a
scope
which
is
like
attributes
related
to
this.
B
This
context,
not
not
the
child
context,
but
this
context
whatever
that
means,
and
then
you
could,
you
could
probe
the
current
context
for
its
scope
variables
and
I
I
mean
to
say
it's
not
a
user
level
api,
because
I
really
don't
want
to
see
users
beginning
to
use
open,
telemetry
sdks
just
so
that
they
can
pass
scope
variables
around
in
their
context,
because
users
shouldn't
be
depending
on
instrumentation
state
to
to
guide
their
programs,
or
else
they
become
part
of
the
program.
It's
not
instrumentation
anymore,.
C
B
C
Yeah,
I
really
want
to
avoid
adding
new
concepts
that
the
user
has
to
care
about.
If
you
look
at
honorogs,
it's
like
super
simple,
dumb
right.
It's
like
really
easy
interface,
that's
just
like
start
and
end,
and
you
know
pass
me
all
of
pass
me:
some
objects
that
I'll
pull
the
attributes
off
of
and
I'm
looking
at
one.
That's
maybe
like
a
little
more
just
like
the
span
interface
and
it's
doing
that
stuff
under
the
hood.
C
But
I
I
have
a
lot
of
faith
that
we
don't
have
to
give
the
end
user
like
new
concepts
that
they
have
to
juggle
it's
about,
like
simplifying
things
and
just
to
clarify.
Why
I
think
it's
so
important
is
right.
Now
we're
talking
about
simplifying
life
for
us
and
like
all
of
our
contrib
instrumentation
but
long
term.
We
want
people
to
go
native
right,
like
we
want
people
to
natively
instrument,
the
libraries
and,
if,
like
that's
like
a
crazy
amount
of
work,
where
it's
like
really
easy
to
do
it
wrong.
C
Then
one
that's
gonna
backfire
and
two
we're
gonna
end
up
with
like
people
showing
up
and
being
like
cool,
like
I
instrumented
some
important
library
with
open
telemetry.
But
then
they
like
didn't
really
like
conform
to
the
conventions,
the
way
they
want
we
wanted
them
to
or
like.
I
think
we
it's
really
important
for
us
to
to
make
this
like
very
straightforward
for
library,
authors
or
it's
just.
D
E
B
So
but
you
are
really
establishing
a
connection
between
the
semantic
conventions
for
hdp
and
the
api
for
programming
and
http
instrumentation
module.
It
sounds
like
so
that
you
for
an
sql
database
you'd
have
a
different
potentially
where
the
the
phases
of
instrumentation,
instead
of
being
like
request,
start
request.
Stop
it's
more.
Like
you
know,
statement
statement
compile
in
like
statement
executor.
I
don't
know,
I
don't
know
it
might
be.
C
C
Divided
up
is
just
helper
functions
that
can
take
various
common
objects
and
like
to
attribute
them,
see
a
trask
since
the
go
since
the
go
implementation
already
has
all
that
stuff
in
the
semantic
convention
package,
then
it's
more
about
just
having
like
a
a
kind
of
like
it'd,
be
the
equivalent
of
a
tracer,
but
instead
of
saying
new
tracer,
it's
like
a
new
metered
tracer.
C
The
point
is
like
all
of
the
details
about
like
what
attributes
go
where
what
are
you
supposed
to
name
this
thing
like
some
of
those
those
kinds
of
things,
those
are
the
places
where
we
don't
want
to
have
to
make
the
end
user
think,
because
it's
all
should
be
mechanical
if
we've
defined
the
conventions
already
like
all
they
can
do,
is
exactly
follow
the
conventions
or
get
it
wrong
and
so
like.
Why
not
give
them
code?
C
That
does
that
for
them,
because
you
know
that's
what
computers
are
for,
but
robert
you
I'm
interested
because
you,
you
said
you've
been
writing
a
lot
of
instrumentation.
Does
this?
How
does
this
stuff
all
sound
to
you?
Is
this
speaking
your
language.
E
A
bit
yeah
we
we
did
like
our
group,
discuss
underwrite's
hotep
there
and
we
we
looked
through
it
and,
like
I
think,
one
of
the
big
like
concerns
that
came
out
of
it
is
like
when
you
look
at
ruby
and
compared
to
java
they're,
very
different
languages.
E
So
a
lot
of
the
idioms
that
are
used
there
would
sit
out
really
awkwardly
if
we
were
to
try
to
implement
them
in
in
ruby,
and
it's
not
that
we
couldn't
do
it.
It's.
I
think
the
the
reaction
is
that
nobody
really
wants
to
do
it
because
it
just
it
doesn't
seem
idiomatic
and
I
think,
for
a
language
like
ruby,
2
or
ruby
as
well.
E
You,
you
really
have
to
be
mindful
of
just
allocating
a
lot
of
objects
and
like
there's,
there
just
seems
a
lot
of
extra
layers
like
if
you
look
at
our
instrumentation
now-
and
I
don't
know
if
I'm
actually
encouraging
you
to
a
lot
of.
It-
is
just
like
a
monkey
patch
right
that
says
in
span
and
you
give
it
a
name
right.
It's
they're,
very,
very
thin,
layers
of
instrumentation.
So
when
I
I
looked
at
this,
I
was
like
whoa
we're.
Adding
like
this
would
be
adding
a
lot
of
stuff
to
something.
E
That's
very
simple
right
now,
but
there
are
cases
where
we
do
need
to
do
something
a
little
bit
better
like
when
we're
think
talking
about
instrumenting
the
100
million
http
libraries
that
exist
in
ruby,
for
whatever
reason,
there's
an
obvious
pattern
that
comes
out
and
we
are
looking
at
extracting
it
so
that
an
instrumentation
author
can
just
kind
of
plug
in
a
uri
object
right
and
then
it'll
generate
the
span
with
the
right
information.
So
I
think
that.
E
And
it's
it's
something:
that's
gonna
be
worked
on.
Probably
in
I
don't
know
next
couple
weeks,
but
again
it's
it's.
Like
my
my
concern.
The
takeaway
is
like
this
shouldn't
feel
language
specific
and
right
now
it
does
and
and
that's
something
that
I
wouldn't
like
to
see,
but
the
intentions
and
the
motivations
behind
it
like
absolutely
I
can
align
with,
because
I
think
of
right
now
the
story
for
first
party
instrumentation,
which
we
started
doing
internally
at
shopify.
E
It's
really
easy
because
I'm
doing
it
right,
I
think
I
know
what
I'm
doing
so.
You
add
it.
You
add
it
to
the
gym
and
then
any
of
the
the
dependent
anyone
that
pulls
that
dependency
is
just
they're
on
their
way.
They're
good,
it's
great,
but
you
think
of
like
the
ruby
ecosystem
and
all
the
gems
out
there
and
someone's
just
gonna
ad
hoc
start,
adding
spans
where
they
think
it's
interesting
and
that
could
go
to
hell
really
quick
right.
So
yeah
I
don't
know
it's.
I
think
it's!
E
I
don't
have
like
a
really
concise
thing
and
that's
what
kind
of
coming
here
is
to
just
start
thinking
about
it
more
and
thinking
about,
what's
what's
being
proposed
and
what
the
focuses
are
here,
but
I
do
agree
that
it
should
be
really
simple.
I
agree
that
we
should
make
it
hard
to
do
the
wrong
thing.
I
think
whenever
you
want
to
provide
a
developer,
an
interface
like
that's
that's,
the
kind
of
the
motivator
is
like
make
it
easy
to
do.
E
The
right
thing
make
it
really
painful
to
do
the
wrong
thing,
and
if
you
think,
if
what
you
think
is
the
wrong
thing,
it
might
be
the
right
thing
in
some
case,
so
just
provide
an
escape
hatch
right
like
something
I
actually
want
to
talk
about.
Eventually,
one
of
these
meetings
is
the
whole
configuration
story
for
instrumentation
right,
like
where
we've
already
started.
Getting
to
the
point
where,
like
okay,
we
need
to
start
normalizing
configuration
options
across
like
all
of
our
database,
instrumentation
all
our
http
instrumentation,
but
that's
not
enough
right.
E
Now
I'm
responsible
for
deploying
instrumentation
to
the
fleet
at
shopify,
and
I
have
a
wrapper
gem
that
just
configures
everything
and
it's
very
opinionated,
but
once
in
a
while,
someone
will
come
up
and
say
well,
your
opinion
was
wrong.
For
this
reason
I
say:
okay,
fine,
what's
their
escape
patch,
so
I'd
like
to
see
like
something
formal
come
out
and
say
you
can
always
override
with
an
environment
variable
now
that
satisfies
my
use
case
really
well,
but
is
there
things
I'm
not
considering
from
other
organizations?
E
Other
organizations
might
say
well
no,
but
like
that's
something
that
I
like
to
discuss
and
have
that
conversation
on,
because
I
think
that
there's
a
lot
of
value
there,
but
I'm
coming
with,
I
think,
a
really
focused
opinion
of
like
I
work
at
a
company,
I'm
rolling
out
instrumentation
to
a
bunch
of
application
owners
that
don't
really
get
a
huge
say
in
it
sometimes
and
I'm
trying
to
like
lay
out
this
opinion.
So
how
do
I
make
my
life
easier?
So
their
life
is
easy
right.
C
That's
a
great
background
to
have-
and
I
know
I
I
agree
like
we
part
of
why
I
want
to
start
working
on
this
and
go
and
unfortunately
they're
in
europe,
so
they
can't
make
it
to
this
meeting,
but
I
have
two
developers,
diego
from
who
work
at
like
steph,
diego
from
the
python
sig
and
bart
from
the
javascript
sig.
C
We're
gonna
start
working
on
this
as
well
to
help
try
to
write
some
prototypes
in
those
languages
around
this
to
yeah
see
if
we
could
hopefully
like
if
we
try
it
a
couple
different
ways
in
in
a
couple
of
different
languages,
you
know:
can
we
figure
out?
What's
what
are
the
commonalities?
C
There
is
there
a
way
to
to
do
this?
That
feels
you
know
like
yeah,
like
what
is
the
subject,
the
subset
of
stuff,
where
we
could
converge
and
like
put
into
the
spec
and
say
like
this
is
the
way
to
do
it
and
like
where
actually
are
the
languages
different
enough
that
you
know
we
want
to
leave
room
for
idiomatic
language
structures.
C
You
know
so
that
it
doesn't
feel
like.
You
know,
java
code
or
go
code
being
like
foisted
on
languages
that
don't
have
those
paradigms.
E
Like
one
of
the
things
that's
already
kind
of
come
out
of
the
the
work
we've
been
doing,
I
think
it
came
up
from
one
of
our
our
guys
from
lightstep
matt
and
we
have.
We
have
an
instrumentation
registry.
So
anytime
someone
develops
third-party
instrumentation.
They
can
include
a
package
and
it'll
register
it,
and
then,
when
the
sdk
fires
off
it,
fires
off
a
an
install
hook
and
you
can
kind
of
pass
in
your
configuration
options
there.
E
There
is,
like
an
environment
overload
to
disable
it
so,
but
that
like
when,
when
I
look
at
the
proposal
like
that,
doesn't
how
does
that
fit
right
like
do
we
rip
out
everything
we
did
and
like
that
would
feel
kind
of
working
backwards?
So
I
wanna.
B
E
E
Because
I
know
that,
like
there's
certain
languages
that
are
just
more
prevalent
right,
I
know
ruby
is
popular
but
like
compared
to
java
java
has
like
a
lot
of
people
that
are
working
on
it,
and
so
it
I
think
there
is
like
a
little
bit
of
a
a
risk
to
like
ruby,
falling
kind
of
to
the
side
there.
And
we
don't
want
that
to
happen,
because
obviously
it's
pretty
important
to
a
few
companies
right.
C
Well,
I
feel
like
open
telemetry
we've
always
done
our
best
work
when
we've
prototyped
things
in
multiple
languages
before
putting
it
into
the
spec
like
like
it
is
every
time
we
haven't
done
that
I
feel
like
it's
bitten
us
somehow,
so
so
yeah
I
I
just
think.
That's
just
the
best
way
to
do
it
is
to
like
come
up
with
some
prototypes
and
several
languages
that
ensures
there's
now
like
a
group
of
people
working
on
it
who,
like
have
like
hand
experience
unlike
the
problem,
and
it's
not
just
an
abstract
problem.
C
So
so
that's
great,
I'm
glad
you're
here
and
and
yeah,
even
though
it'll
probably
be
async
feedback,
we'll
have
some
javascript
and
some
some
python
so
and
then,
like
the
next
step.
Yeah
like
we've,
been
talking
about
http,
but
we
also
now
want
to
apply
this
to
like
another
domain
like
sql,
or
something
like
that
and
see
like
what.
C
E
One
of
the
ones
that
has
come
up
for
us
a
couple
times
is
just
how
the
ruby
ecosystem
runs
like
the
job
frameworks
like
there's.
No
semantic
convention
right
there
for
that
right
now,
but
because
it's
typically
backed
by
something
like
redis
we've
been
just
kind
of
piggybacking
on
the
the
messaging
semantic
convention.
So
like.
D
D
E
Because
there's
certain
things-
and
that's
like
the
tricky
part,
I
think-
is
there-
there
are
certain
things
that
are
just
going
to
be
specific
and
like
to
a
certain
ecosystem
like
I'd
like
to
hear
more
about
any
conventions
around.
What
does
it
look
like
when
you
instrument
an
orm
right
rails
comes
to
mind?
E
Obviously
it's
very
relevant
to
what
I
do
so
you
know
I
have
active
record
instrumentation,
one
of
the
first
pieces
of
feedback
I
got
is
like
oh
this
isn't
the
database
fan
like
they
were
expecting
it
to
be
instrumenting
the
database,
but
we
already
instrument
the
database.
So
what
does
it
look
like
when
you
instrument
an
or
app
right?
E
C
John,
I
think,
there's
something
I've
heard
you
maybe
bring
up
around
like
multi-layered
instrumentation.
I
don't
know
if
you've
seen
it
at
the
like
framework
level,
but
but
it
does
get
trickier
once
multiple
layers
start
trying
to
get
involved
in
this
stuff
right
yeah
I
mean
just
yesterday.
A
Jason,
plum,
I
don't
know
some
of
you
may
have
interacted
with
him
and
I
were
working
on
converting
the
jetty,
eight
instrumentation
and
the
instrumentation
repo
from
the
old
from
an
old
api
to
the
new
instrumentation
api
that
honorard
has
built
out,
and
it
turns
out
that
that
particular
instrumentation,
because
jetty
is
a
very
commonly
used.
App
server
for
many
things,
interacts
with
a
whole
bunch
of
other
instrumentation
like
the
core
server
instrumentation
and
a
bunch
of
other
things
and
trying
to
disentangle.
That
was
very
tricky.
A
And
actually
we
found
that
the
test
coverage
is
actually
only
so-so.
So
we
got
all
the
tests
passing
and
yet
the
instrumentation
wasn't
working
correctly
at
all.
So
because
of
these
interactions
between
the
various
layers,
like
the
app
server
itself
versus
the
server
and
api
versus
other
pieces
of
the
stack,
all
of
which
are
important
and
add
relevant
information
to
the
kind
of
to
the
span.
E
Yeah,
that's
that's
a
really
good
point.
That's
something
that
I've
discussed
internally
with
the
guy
who's
been
kind
of
teaching
me
all
this
stuff.
I
don't
know
if
anyone's
interacted
with
him
yet
but
francis
monsanti,
but
one
thing
we've
talked
about
is
like
there's
the
code,
the
application
developers
right
so
like
they.
They
they
can
instrument
their
own
code.
E
They
can
add
their
trace
points,
but
if
we
add
instrumentation
to
active
record
or
any
part
of
rails,
do
they
want
to
filter
that
like
because
there's
the
different
layers
right,
there's
the
code,
they
write,
there's
their
framework
code,
there's
potentially
infrastructure
code
and
then
there's
different
verticals
like
we
trace
our
collection
pipeline
because
we
are
maintaining
it.
So
we
actually
trace
our
export
pipeline
from
the
application
through
load
balancers
to
our
collectors
right.
So
they
don't
want
to
see
that.
So
how
do
we
segment
that
information?
And
then
it
becomes?
E
Let's
talk
about
like
different
layers
and
different
personas
of
who
sees
what
and
how
do
you
actually
set
the
different
layers
there,
and
how
do
you
group
it
together
so
that,
like
people
aren't
just
getting
flooded
with
noise,
like
we
have
a
team,
that's
tracing
their
their
job
worker
loop
right.
E
They
want
to
see
the
idle
loop,
but
a
team.
That's
just
like
running
a
simple
rails,
app
and
they're
running
a
job
broker.
In
the
background.
They
don't
want
to
see
that,
but
the
the
flood
of
span
volume
that
they
get
would
be
absurd
right,
but
there
are
teams
you
care
about.
So
how
do
you
kind
of
filter
that
out
anyways
I'm,
let's
open
it
up.
C
But
that
I
think
that
gets
into
the
configuration
question
which
I
I
just
see
as
like
this
is
a
thing
that
we,
I
just
think
we're
not
quite
there
yet,
which
is
why
it
hasn't
fully
come
up
with
a
lot
of
user
feedback,
but
I
just
know
we're
gonna
hit,
which
is
around
yeah
at
minimum.
I
mean
something
I
think
you've
talked
about.
John
is
like
just.
How
do
you
enable
or
disable
instrumentation
like?
How
do
you
turn
it
on
or
off?
C
That's
I
mean
as
similar
as
possible
as
grape
is
like
kind
of
okay,
but
like
the
configuration
format
needs
to
ideally
needs
to
be
like
the
same
right
like
you
just
have,
like
you
know,
an
open,
telemetry
comp
file
that
has
like
the
same
semantics,
regardless
of
where
you're
running
it
otherwise
it'll
be
crazy,
making
for
people
and
probably
crazy
making
for
us
if
that
stuff
starts
to
really
fracture.
So
so
we
need
to.
C
A
They
are,
they
are
already
doing
this.
I
get.
I
get
issues
in
open,
telemetry
java,
all
the
time
or
it's
like
hey,
can
you
we
need
to
add
this
little
thing
here
and
like.
Why
do
you
buy
this
thing?
Well,
when
you
support
this
use
case,
I'm
like
all
right,
let's
go
to
the
spec
yeah,
let's
introduce
the
spec.
We
need
to
do
this
everywhere,
but
yeah
it's
already
happening.
Yeah.
The
ship
has
sailed
ted.
C
It's
not
shocking
me
at
all,
and
so
I
feel
like
in
general,
open
telemetry
has
been
a
little
underwater
just
trying
to
like
ship,
stable,
1.0s
and
like
get
metrics
and
stuff
out
the
door,
but
like
I
feel
like
really
happy
to
see
people
starting
to
really
focus
on
this
stuff,
because
it's
it's
going
to
quickly
be
it's
like
the
next
crisis
brewing
and
it's
like
already
brewing,
and
it's
going
to
like
the
volume
is,
I
think
I
predict,
is
going
to
turn
up
really
high
once
metrics
gets
out
there
because,
unlike
tracing
metrics,
is
like
a
really
popular
thing
and
so
we're
gonna,
I
predict
see
like
a
huge
influx
in
in
users.
C
After
that
happens,
so
yeah,
I
think
we're
out
of
time
yeah
I
gotta
run
it's
great
talking
to
you
all
rob
say
hi
in
the
the
hotel,
instrumentation
channel.
It's
pretty
low
volume
right
now,
but
that's
probably
where
we'll
want
to
continue
these
conversations
they
sing
and
yeah.
I
totally
would
love
to
see
the
prototype
that
you're
working
on
over
in
ruby.