►
From YouTube: 2022-03-01 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
A
A
Good,
I
didn't
hear
anything
that
you
just.
I
couldn't
discern
what
you
said
before.
B
B
I
think
so
I
think
it
just
means
like
okay,
okay,
all
right,
okay,
so
it
goes
how's
it
going.
I
don't
know
how
are
you
how's?
Okay,.
A
Everything's
good,
I
had,
I
had
a
lentil
fiasco,
but
that
was
on
sunday,
but
the
big
news
is
that
our
family
has
moved
our
covetile
to
relax.
So
we
had
some
people
over
for
dinner
last
night.
B
B
Yeah,
you
cook,
they
didn't
turn
out
well
or
what
could
it
possibly
be?
Well.
A
I'm
a
big
fan
of
the
instant
pot
and
I
decided
to
make
some
lentils
and
because
my
life
is
boring
most
days
I
eat
like
a
salad
with
like
quinoa
or
lentils
in
it
for
lunch.
Okay-
and
I
was
like
all
right-
the
lentils
was
a
new
modification
and
I
looked
up
a
recipe
for
cooking
lentils
in
the
instant
pot,
and
I
did
that
because
this
is
all
supposed
to
be
like
you,
don't
have
to
think
very
hard
about
it.
A
B
A
Could
be
too
much
pressure
too
much
time.
People
in
the
vegan
channel
on
the
slack
are
going
off
telling
me
how
to
fix
my
problems,
so
that's
great,
but
right
now
I
just
have
to
eat
this.
Like
lentil
yeah.
A
It's
not
so
bad
because
I
made
it
with
boolean
like
vegetable.
I
don't
know
how
to
say
that
word:
bouillon
yeah.
B
B
C
C
B
Well,
sorry,
the
cigs
have
been
moving
around
some
of
the
meeting
stuff
meeting
links
and
retooling
there,
and
it's
been
a
little
confusing
for
some
people,
myself
included.
D
In
the
meeting
notes
are,
are
the
oh:
are
the
notes
in
the
calendar
invite.
B
They
are,
I
can
provide
a
link
there
with
me,
usually
away
from
matt
from
lightstep.
He
usually
runs
the
meeting.
B
So
I'm
kind
of
waiting
for
him
ariel
says
he's
unable
to
join.
B
There
we
go
ariel,
I
think
he
found
his
way
in
and
there
is
the
gym.
Oh
sam
already
shared
the
agenda.
B
Welcome
back
ariel
we're
just
seeing
if
matt's
gonna
join.
If
not,
I
guess
we
can
get
started.
B
Cool,
well,
I
don't
know
he
hasn't
replied.
So
I
would
say:
let's
let's
get
started,
I'm
sure
matt
can
you
know
catch
up
async
or
you
know
he
can.
We
can
read
the
meeting
notes
all
right.
I
guess
I
can.
I
can
drive
today
totally
fine.
B
Let
me
just
share
my
screen.
Sorry.
B
Can
I
ignore
that?
Can
everyone
see
my
screen
cool
all
right,
welcome
everyone?
We
can
do
quick
introductions
if
you
want,
but
it's
if
you
just
see
the
attendees
list,
that
also
works.
B
B
Yeah
or
I
guess
it's,
this
specification
sig,
so
we
can
review
that
real
quickly
if
people
would
like,
if
not,
we
can
move
on
to
pressing
pressing
issues
and
concerns.
Anyone
want
me
to
do
like
a
five
minute
summary
of
what
happened
in
the
spec
sig
all
right.
I
take
your
silence
as
a
yes
all
right.
B
It
appears.
Let's
see
if
any
of
these
have
any
discussion.
People
care
about.
Please
speak
up.
Otherwise
I'll
run
through
them
looks
like
a
json
serialization
format
to
file
was,
has
been
going
back
and
forth
for
a
while.
Last
I
looked
at
this,
it
was
pretty
close
to
getting
merged.
B
It's
basically
just
defining.
You
know
what
the
json
should
look
like.
If
you
want
to
write
to
disk,
which
is
pretty
reasonable,
it
seems
pretty
much
like
what
the
otlp
export
of
json
over
http
looks
like
cool
that'd,
be
cool,
looks
like
they're,
getting
close
to
declaring
stability
on
the
log
data
mile
data
model,
which
will
be
nice.
That
one
is
the
metrics
data
model
is
stable.
Tracing
has
been
stable
for
some
time,
and
so
this
is
the
remaining
one.
So
it'll
be
nice.
B
I
have
no,
you
know
I'm
doing
this
live,
so
I
don't
actually
know
how
okay
it
looks
like
it's
just
a
draft,
so
I'm
sure
this
will
take.
You
know
the
usual
forever.
There
was
a
metrics
time
box
youtube
treat,
oh
and
then
also
there
was
a
okay.
So
one
of
the
follow-ups,
I
guess
from
the
renaming
thing
we
talked
about
of
instrumentation
library,
instrumentation
scope-
is
that
well,
I'm
not
sure
exactly
what
the
discussion
was,
but
they're
saying
they
need
to
treat
more
than
just
the
otop.
Why
are
data
as
stable?
B
I
think
some
cigs
were
complaining
that
doing
this
renaming
is
difficult.
You
know
it's
more
than
just
like
aliasing,
some
things
they
might
be
using
like
generated
code
more
than
us.
We're
kind
of
like
hand
writing
in
a
lot
of
these
like
names
like
a
tribute
instrumentation
library,
and
so
that
was
probably
or
more
problem.
So
this
change,
which
is,
I
guess
technically
not
a
breaking
change-
has
breaking
implications
for
some
languages
like
go.
I
remember
sam
has
more
familiarity
with
this,
so
they
talked
about
it.
B
I
don't
know
what
the
resolution
of
was,
but
anyway
and
time
box
discussion
on
metrics
they,
okay,
some
yeah,
I
robert,
would
be
more
familiar
with
anything
metrics
related,
but
it
looks
like
they
want
to
clarify.
They
want
to
sort
of
wrap
up
any
bike
shedding
in
the
spec
around
metrics
and
start
to
focus
on
making
sure
the
implementations
are
getting
there,
which
is
lines
up
pretty
well
with,
where
we're
at
with
ruby,
where
we're
starting
the
metrics
implementation
ourselves.
D
B
That's
a
good
question.
I
don't
know
off
hand.
D
And
you
said
the
ruby
instrumentation
is
starting
to
have
some
metrics
written
against
it.
B
So
yeah
in
the
second
half
of
this
meeting,
my
colleague,
robert
who's,
been
working
on
the
implementation,
can
maybe
talk
he's
been
we've
been
spending
some
of
these
meetings.
He'll
do
a
little
overview
of
like
where
things
are
at
not
to
put
him
on
the
spot
or
anything
you
might
not.
But
yeah.
I
don't
know
robert.
You
know
if
they're
at
feature.
F
The
api
the
api
is
considered
stable.
I
think
that
might
be
a
little
bit
generous,
because
stuff
is
changing.
The
sdk
is
currently
in
future.
Freeze
again,
there's
like
a
lot
of
inconsistencies
in
it,
so
I
expect
a
bit
of
churn
there.
F
Hopefully,
it's
not
like
jarring
churn,
but
again
like
not
trying
to
be
too
critical,
because
I
know
there's
a
lot
of
work
there,
but
there
are
quite
a
few
inconsistencies
like
in
the
sdk
that
will
need
to
get
resolved
and
they
have
been
getting
resolved,
which
is
good
in
terms
of
progress
in
ruby.
It's
not
metrics
instrumentation
we're
working
on
the
sdk
implementation
right
now.
So,
okay,
there
is,
there,
isn't
a
working
piece
there.
Yet.
B
Cool
thank
you
for
the
info
there.
Okay,
I'm
not
going
to
go
through
all
these,
because
it's
boring
and
okay
and
looks
like
there's
some
continued
discussion
on
interoperability
between
prometheus
and
otlp,
which
I'm
sure
it
will
be
a
brief
and
not
controversial
thing.
B
And
I
don't
want
to
go
into
details
of
all
this
because
it
is
super
interesting
and
also
will
take
up
the
entire
meeting.
But
that's
kind
of
the
state
of
where
things
are
at
we're,
trying
to
get
metrics
closer
to
ready
and
finding
out
that
there's
lots
of
rabbit
holes
there
and
cool
okay
and
so
concludes
the
spec
sig
update.
B
Cool
so
yeah
I
mean
we
can
spend
the
second
half
doing
if
there's
pressing
issues
or
questions,
I
would
say
like:
let's
get,
let's
fill
those
and
get
those
like
out
of
the
way
and
then
robert.
I
don't
know
if
you
wanted
to
continue
doing
sort
of
like
an
overview
or
discuss
anything
new
on
either
the
instrumentation
meeting
front
or
the
metrics
front.
But
we
can
take
the
second
half
and
do
that.
F
We
can
discuss
it
as
like
an
open-ended
bit.
I've
pushed
up
a
little
bit
of
code,
but
nothing
too
too
interesting
just
more
about
like
yeah.
We
can
leave
that
for
like
the
later
half,
but
I
think
there's
any
like
open
issues
or
pr's
that
people
want
to
go
over.
Let's
prioritize
that
for
right
now,.
B
For
sure,
I
also
want
to
respect
mr
anderson.
I
want
to
respect
your
time
here
is
like
welcome.
D
I'm
from
scout
apm
we've
been
doing.
We
started
with
ruby
application
monitoring
in
like
2015
we've
been
focused
on
that
for
a
good
seven
years.
Now
we
kind
of
expanded
into
python
and
php
and
node.js
a
little
bit,
but
we
want
to
get
involved
with
the
open,
telemetry
community,
specifically
around
ruby.
That's
really
my
strong
suit.
I
wrote
a
lot
of
scout
apm's
agent
itself
and
its
instrumentation,
so
hopefully
there's
stuff
that
I
can
contribute
to
the
ruby,
open,
telemetry
libraries.
B
Cool
yeah
welcome
scott
yeah,
a
big
fan
of
the
scout
tools
and
yeah,
and
there
you're
I've
probably
looked
at
maybe
one
or
two
lines
of
code
from
that
reba
before
and
I
think
there's
some
shocking
similarities
between
probably
our
instrumentation
packages
and
probably
some
of
yours
so
yeah.
I
think
there's
lots
of
room
to
contribute
and
yeah,
it's
more
a
matter
of
like
where
you're,
where
you're
interested
in
jumping
in.
B
But
do
you
have
any
any
specific
there's
some
smaller,
like
I
put
on
the
agenda,
some
smaller
things
I
wanted
to
discuss.
Did
you
want
to?
Did
you
have
any
sort
of
like
pressing
questions
or
things
on
your
mind?.
D
Just
wanted
to
to
sit
in
and
see
kind
of
how
the
sig
operates
and
kind
of
dip.
My
toes
in
and
start
contributing.
B
Cool
cool
cool,
yeah,
normally
it's
more
organized
matt-
is
much
better
at
this
than
me.
It's
just
an
important
takeaway
here.
So
don't
don't
judge
us
by
to
this
meeting.
D
B
You
judge
a
little
cool
so
for
issues.
I'd
put
one
small
thing
up,
ariel
I'll.
Just
take
three
minutes
here
I
don't
wanna.
I
think
this
is
a
good
discussion.
I
just
wanna
quickly
time
box.
Asking
for
a
review
of
this
was
a
pr
that
chris,
mr
holmes
pushed
up
a
while
ago,
and
it
kind
of
got
stuck
in
you
know.
Back
and
forth.
B
I
tried
to
generalize
it
into
some
like
incredible
utility
thing,
then
that
got
stuck
and
then
he
pinged
me
over
the
weekend
and
said
like
hey,
this
never
got
merged.
All
it
is
is
a
an
option
for
like
the
five
or
six
http
client
instrumentations.
We
have
to
drop
the
query
string
or
the
query
parameters
on
certain
attributes
that
contain
those
so
like
http
target
and
then
like
http
url,
it's
a
it's.
A
pii
issue
carries
for
feedback.
B
B
B
It's
just
cool
and
I'm
on
the
wrong
thing
now
I.
D
Do
have
a
question
on
that
one?
Is
there
standard
naming
for
those
types
of
option
names
across
languages
or
what
kind
of
freedoms
do
we
have?
As
far
as
configuration
naming
goes
so
the.
B
B
B
No,
they
don't,
but
they
should,
and
I
think.
B
D
Everybody
knows
the
naming's
hard,
but
the
the
slight
difference
between
hide
or
do
not
collect
like
the
that
slight
wording
change
whether
it
implies
we
just
don't
collect
it
at
all,
versus
whether
we
collect
it
but
somehow
obscure.
It
is
something
that
we've
run
into
with
kind
of
our
gem
too.
So.
E
So
similarly,
like
the
database
statement,
ones
eric
where
we're
saying
that
we'll
include
or
obfuscate,
but
this
could
you
know,
I'm
gonna
bring
this
back
up
again,
which
is
con.
Maybe
we
should
consider
adding
a
concept
like
an
attribute
processor
that
we
can
use
as
a
reusable
component.
B
Agreed,
I
want
to
do
all
those
things
and
I
actually
think
yeah
and
I
am
open
to
good,
like
smaller
feedback
like
let's
improve
the
name,
let's
maybe
make
it
a
a
triplicate
enum
instead
of
like
a
boolean,
true
false
or
something
like
that.
I
want
to
not
ex
extend
this
into,
like,
I
think
in
a
tribute.
B
Processor
is
a
good
end
state
for
a
lot
of
this
work
and
also
a
great
way
to
never
get
this
shipped
for,
but
I
want
to
do
that,
but
I
mostly
want
to
make
sure
that
the
user
who's
been
asking
for
this
gets
the
thing
they
want.
I
understand
yeah
yeah,
but
yeah.
I
definitely
like
open
telemetry.
Yes,
I
think
is
really
good
examples
of
like
they
just
have
hooks
and
you
can
do
whatever
you
want
at
the
beginning
and
end
of
the
span
and
we
don't
have
to.
B
E
Similarly,
there
was
another
pr,
also
where
someone
was
mentioning
that,
like
the
brielle's,
filtered
parameters
was
not
depending
on.
Does
that
merge
already.
B
That
was,
this
was
the
same
contributor.
Actually
that
was
also
chris,
who
mentioned
that
we
weren't
respecting
sorry.
Well,
just
we
were
not
respecting
the
rails,
filter
param
option,
which
is
meant
to
basically
drop
stuff
like
drop
stuff
from
http
target
in
like
rails
logs,
and
so
we
had
a
pr
to
just
say
like
let's
respect
that
and
we
are
yeah
okay,
it's
one,
I
would
say
a
controversial-ish
thing
about
this.
Is
it's
not
a
config
option?
B
It's
just
like
the
way
like
it's
a
breaking
change.
If
you
were,
if
you
were
using
filter,
parameter
config,
and
you
were
wanting
your
hd
target
to
include
you
know
these
filter
things
and
all
of
a
sudden
now
like
on
a
minor
release.
It's
not
going
to
that
could
be
un
anticipated
and
sorry,
it's
already
merged,
so
but
yeah
I'm
open
to
making
this
a
conflict
option,
but
I
didn't
want
a
bike
on
it.
Okay,
that's
all
I
had
ariel.
Do
you
wanna.
E
Before
I
disappeared
for
a
few
weeks,
we
were
talking
about
the
contribu
repo
and
what
was
the
did.
We
end
up
forking,
essentially
like
reforking
maine,
and
pushing
that
up
or
sorry
the
the
sdk
repo
and
pushing
it
up
or
what
happened
with
that.
F
E
B
B
I
I
don't
know
who
it's
on,
but
if
we're
the
maintainers
of
it
like,
I
guess
I
just
have
been
busy
doing
other
stuff
the
past
week
or
two
and
figured
I
wouldn't.
You
know,
let's
maybe
I'm
down
to
sync
this
week
and
we
can
like
push
something
up
play
around
with
it.
I
think
robert's
advice
from
a
few
weeks
ago
is
good,
which
is
like,
let's,
let's
basically
like
fork.
B
It
see
what
breaks
like
and
and
then
go
from
there
instead
of
having
to
like
you
know,
figure
out
some
like
crazy,
get
script
to
like
bring
over
all
the
commit
histories,
and
do
these
huge
pr's
like
let's
see,
what's
wrong
with
the
the
hacky
way,
and
then
I
have
a
feeling.
It
won't
be
so
bad
that
it's
not
unusable.
D
What
are
the
main
things
that
the
ruby,
specific,
open,
telemetry
developers
or
community
needs
at
this
point.
E
So
some
of
the
feedback
that
we
get
is
like
figuring
out.
You
know
continuing
to
like
build
out
our
auto
instrumentation,
getting
more
involved
in
the
auto
instrumentation
community
and
providing
some
feedback
there
so
that
we
can
ensure
that
you
know
we
don't
we
don't
get
stuck
with
sort
of
like
apis
or
decisions
that
are
make
it
difficult
for
rubyists
to
implement.
E
I
think
another
part
of
it
is
like
you
know.
We
got
a
couple
of
open
pr's
about
you
know,
trying
to
streamline
the
process.
I'd
be
interested
in
picking
your
brain
dave
about
building
the
agent,
so
we
can
try
to
do
something
that
is
less
invasive
for
people
or
requires
less
configuration
from
them.
E
You
know
those
are
some
things
that
are
like
longer
term
and
obviously
providing
support
and
feedback
to
folks,
because
we
do
get
a
lot
of
questions
for,
like,
I
wouldn't
say,
a
lot
like
we're
not
overwhelmed
by
them,
but
we
do
get
some
questions
about.
Like
hey,
I
tried
this.
You
know
this
thing
and
it
didn't
work
and
it's
like
helping
them
try
to
figure
out
how
to
debug
stuff,
because
this
is.
D
Almost
like
happening
slack
or
github
or
github
questions
or
github.
E
It's
a
mix,
it's
a
mix.
You
can
see
like
the
conversations
that
happen,
sometimes
in
things
that
are
like
not
related
to
us
specifically,
but
like
folks
who
say
like
hey
like
you
know,
one
example
I
can
think
of
is
the
sidekick
instrumentation
does
this,
but
I'm
also
using
redis
and
the
spans
are
in
this
structure
and
it's
kind
of
like
giving
people
feedback
on
like
what
they
should
consider
doing
or
or
whatever
or
or
like.
We
just
got
a
a
question
today
where
it
was
just
like
hey.
E
I
tried
to
do
this
with
the
graphql
instrumentation
and
it
gives
me
this
error
and
it's
not
working,
and
it's
like.
We
need
more
details
than
that
right,
like
providing
folks
with
some
guidance
there.
So
I
don't
know
I
eric
robert.
You
all
have
more
thoughts,
I'm
sure.
F
I
I
think
kind
of
like
from
my
point
of
view
right
now,
like
acknowledging
everything
you
said
as
100
accurate
for
me,
it
kind
of
like
I
get
the
sense
that
we're
in
a
nice
increment
and
improved
stage
of
things
like
in
terms
of
the
tracing
perspective,
barring
the
world
of
metrics
and
logs
in
terms
of
tracing
like.
F
I
think
it
is
very
much
increment
improve
like,
like
the
examples
aerials
bring
up
they're
like
I'm
trying
to
do
this,
I'm
trying
to
use
the
thing
that
exists
now
or
like
understanding,
and
sometimes
it's
like
the
the
rails
example
of
like
the
filter
params
like
oh.
This
is
probably
the
right
behavior,
so
we
merge
that
in
and
so
it's
it's
not
like.
I
think,
there's
like
mountains
to
scale
at
this
point,
but
I
think
there
is
still
a
lot
of
room
for
improvement.
F
You
know
this
is
like
coming
from
my
own
personal
perception
of
things
like,
I
think
the
rails
instrumentation
overall
could
be
improved,
not
in
the
sense
that,
like
what
exists,
is
bad,
but
I
think
there's
room
for
better
insights
in
rails,
application
that
we're
not
leveraging
or
providing
things
like
graphql
there's
some
fields
that
we
don't
trace
by
default,
because
they're
very,
very
verbose
or
very
noisy
modifying
instrumentation,
so
that
someone
who
is
like
consuming
this
gem
that
could
maybe
trace
these
fields
conditionally
on
a
single
request.
F
If
they're
trying
to
debug
something
that's
a
little
bit
gnarly
in
production
without
blowing
up
their
telemetry
volume,
adding
client-side
like
graphql
error,
capturing
and
you're
tracing,
because
right
now,
it's
like
everything's
from
the
perspective
of
the
server.
So
if
you
have,
you
know
your
app
talking
to
another
app
and
the
client
has
a
malformed
query,
like
that's
an
area
error
for
the
client,
but
we
don't
actually
surface
that
in
a
trace
so
like
these
aren't,
I
think,
like
huge
battles
to
win
but
they're
like
these
these
little
step
forwards.
F
But
I
would
describe
a
lot
of
how
things
have
been
going
over.
The
last
few
months
is
more
reactive.
It's
like
people
that
come
in
and
say
hey.
F
This
is
confusing,
or
can
we
do
this
or
I
would
like
to
do
that
and
then
we
try
to
react
and
try
to
set
up
the
instrumentation,
so
it
has
defaults,
that's
friendly
to
someone
who's
just
getting
started
right,
but
giving
the
escape
hatches
to
do
opinionated,
weird
things
if
your
your
org
like
needs
it
like
for
reference
like
myself
and
eric
are
shopify
people
we've
been
using
this
in
production
for
all
over
a
year
now,
like
all
of
this
stuff,
and
even
our
our
kind
of
like
flagship
monolith,
is
using
essentially
like
defaults,
open,
telemetry
instrumentation,
just
like
what
you
see
in
the
repo
there.
F
So
I
think
we
are
in
a
good
like
shopify,
is
in
a
good
position
because,
like
we
we're
like
a
rails
shop,
so
we
have
kind
of
a
good
sense
of
what
like
rails
developers
want.
So
we've
been
trying
to
take
that
and
provide
useful
communities
and
like
we
have
ariel
giving
feedback
from
like
github
and
other
massive
rails
drop.
So
like
it's
been
pretty
cool
having
access
to
people
like
that,
so
that
was
kind
of
a
long-winded
way
of
saying
I
think
we're
like
in
incremental
improvement
mode
for
tracing.
F
D
Yeah-
and
you
know,
I
think
that
those
small
smaller
refinements
they
they
never
stop.
As
long
as
you
know,
this
gym
exists.
So
that's
where
we
find
ourselves
is.
You
know
it
took
us
a
few
months
to
build
our
initial
gym,
but
those
refinements
and
those
small
incremental
improvements
they
they
just
yeah.
That's
the
whole.
That's
the
whole
game
right.
F
D
F
From
your
like
just
inferring
a
lot
from
your
introduction,
like
the
experience
that
you
have,
I
think
you
could
potentially
find
some
really
instru
like
interesting
conversations,
there's
a
meeting
that
I've
been
neglecting
I
was
going
to
for
a
while,
just
because
it's
like
quite
a
bit
later
in
the
evening
and
it
conflicts
with
you,
know,
dinner
and
stuff
like
that,
it's
the
instrumentation
sig,
so
you
talked
about
as
their
conventions
around
like
configuration
options.
That's
where
those
conversations
will
inevitably
happen
right
now,
they've
been
or
last
time.
F
I
went
they're
more
focused
around
http
semantic
conventions.
Just
saying
like
can
we
have
a
stable
spec
for
what
http
instrumentation
should
look
like
what
attributes
should
be
there?
How
should
it
behave
around
redirects
and
retries?
Should
we
ignore
fields
that
have
sensitive
values
should
be
on?
What
should
we
do?
I
think
some
of
the
really
big
decisions
that
will
impact
instrumentation
will
come
out
of
that
meeting
and
so
having
the
right
influences.
There
is
really
important.
F
I
do
intend
to
kind
of
rejoin
that
world
when
time
is
more
permitting,
but
if
you're
looking
for
like
a
place
to
see,
what's
going
to
be
happening
and
being
able
to
weigh
in
as
someone
who's
actually
been
doing
it
in
this
space,
especially
from
a
ruby
perspective.
That,
like
is
a
lot
of
that
hits
close
to
home
for
us,
because
a
lot
of
this
right
now
is
being
influenced
by
and
not
not
that
it's
necessarily
a
bad
thing.
F
But
a
lot
of
it
is
coming
from
like
azure
and
amazon,
where
it's
really
heavy
java.
So
there's
a
lot
of
like
java
influences
being
weighed
in
on
there
and
that
doesn't
always
carry
over
very
well
to
ruby
stuff.
Sometimes
it
does,
but
it
doesn't
so
like.
I
started
going
just
purely
with
the
intention
of
like.
Maybe
ruby
has
a
voice
right.
D
Sure
yeah,
so
the
instrumentation
sig,
is
the
one
you
were
saying.
F
Sorry,
yeah,
so
that
that
is
today
it's
in
like
six
and
a
half
hours
from
now.
A
D
F
B
I
would
echo
everything
arielle
and
robert
said,
which
is
like
pretty
good
tracing
wise,
but
a
lot
of
it's
like
user
friendliness
of
you
know
like
getting
at
the
out
of
the
box
that
magical
like
out
of
the
box
experience
and
then
like
instrumentation
friendliness
like
and
also
like
yeah
user
feedback.
B
One
other
thing,
I
would
say,
is
like
figure
out
like
if
the
goal
of
like
you
know,
if
you're
kind
of
like
representing
scout,
broadly
sort
of
like
get
a
sense,
I'm
not
familiar
with
whether
scout
ingests,
otlp
or
hotel
data
and
like
the
ways
they
prefer
to
ingest
that,
whether
it's
like
you
know
direct
from
applications,
whether
there's
the
recommendation
to
run
a
collector
as
like
a
daemon
and
so
on
like
determine,
I
think,
what's
I've
seen
from
other
sort
of
like
vendors
joining
and
myself
previously
as
out
of
vendors,
like
figure
out
what
your
export
model
is
for,
like
how
you
want
to
receive
data.
B
As
you
know,
wherever
your
endpoint
is
like
and
see
what
that
flow
actually
looks
like
then
from
like
rsdk,
and
you
might
find
there's
some
rough
patches
like.
Oh,
if
you,
for
example,
previously
I
had
seen
this
at
datadog,
was
like
we
did
a
lot
of
like
auto
collection
of
like
fargate.
B
You
know
metadata
from
people
running
in
aws
fargate
and
when
I
tried
out
hotels
like
oh,
that
stuff's
missing
and
you
know
so
like
figure
out
where
the
rough
edges
are
for
you
and
like
your
organization
and
there's
definitely
like
you
know,
we
don't
know
be.
We
won't
like.
We
don't
know,
because
we
don't
know
like
because
we
don't
have
that
experience.
B
So,
like
that's
useful
and
then
also
like,
I
think
if
you
want
to
sort
of
like
just
dip
your
toe
in,
like
there's
a
bunch
of
instrumentations
out
there,
that
we've
yet
to
port
to
open
telemetry
biggest
one
is
probably
grpc,
but
there's
lots
of
smaller
ones
that
are
less
gnarly
than
like
attempting
to
do
a
bunch
of
grpc
stuff.
So
don't
feel
like
you
have
to,
but
it'd
be
cool.
B
If
you
did
but
yeah,
you
know
pick
one
if
you're,
if
you
just
kind
of
want
to
get
a
feel
for,
like
you
know
what
the
sdk
feels
like
and
how
to
you
know
what
the
aliases
are
for,
generate,
expand
and
how
context
is
propagated,
like
you
know,
write
instrumentation,
we'll
try
to
give
you
like
solid
feedback,
and
I
think
that's
generally
been
a
good
way
to
get
people
like
familiar
with
the
you
know,
the
toggles
and
the
the
and
the
ways
things
work
and
then
from
there
you
know
the
world
is
yours.
D
Yeah
we've
actually
been
reporting
open,
telemetry
data
to
our
we're,
essentially
building
a
new
platform
around
open,
telemetry
and
otlp
directly.
So
we've
we've
been
ingesting
a
few
terabytes
of
of
our
own
data
a
day
from
our
current
platform
into
this
new
platform,
and
I've
been
poking
around
the
ruby
sdk
just
to
read
it
and
kind
of
get
a
sense
of
it,
but
yeah
definitely
we'll
take
a
look
at
a
little
bit
of
instrumentation
and
all
those
things
you
suggested
and
just
try
to
get
involved
a
little
bit.
B
F
I
think
it's
like
we
didn't
do
like
super
formal
introductions.
I
think
it's
like,
maybe
just
a
little
beneficial
to
like
lay
out
how
things
actually
have
been
working
ariel
and
eric
have
been
really
leading
the
charge
on
everything
instrumentation
pretty
much
everything
that's
going
on
the
repo
like
the
core
maintainers
are
like
myself,
matt
and
francis
ariel
and
eric
are
going
to
be
the
maintainers
for
instrumentation
that
repo
needs
to
get
set
up.
It's
going
to
be
split
out
into
a
contrib
repo,
francis
is
kind
of
I'd,
say.
F
Like
the
original
author
of
a
lot
of
the
pretty
much
all
the
tracing
stuff,
you
look
at
like
the
contributor
graph.
He
set
everything
up
he's
still
around
but
like
indirectly,
I
kind
of
sent
him
reports
just
to
keep
him
in
the
loop.
Matt
runs
these
meetings
and
kind
of
makes
sure
that
we
know
what's
going
on
with
like
the
broader
world
and
brings
it
back
here.
I've
been
really
doing
my
best
to
stay
heads
down
on
metrics
and
for
better
or
worse,
I've
been
sort
of
putting
the
blinders
on
everything
else.
F
F
D
What's
what
are
your
guys's
time?
Allotments
from
you
know
your
your
day,
jobs
at
shopify,
or
you
know
your
your
companies
to
be
able
to
work
on
this
like?
Is
this
a
dedicated,
dedicated
thing
you're
doing
within
shopify
or.
F
There's
an
abundance
of
freedom
like
it's
again
like
francis,
like
looking
at
the
contributor
graph.
You
get
a
sense
of
like
time
and
that's
been
spent
into
it.
Francis
started
this
a
while
back.
He
was
going
to
look
at
taking
over
the
open
census
implementation,
but
it
got
deprecated
in
favor
of
telemetry,
so
he
built
the
open
telemetry
one
and
he
was
given
kind
of
freedom
to
build
that
and
then
I
joined
him,
and
the
same
is
true.
F
But
as
much
time
as
I
can
just
literally
make
when
I'm
not
working
with
other
people
to
work
on,
the
metrics
is
sort
of
like
what
I've
been
doing
so
it
it's
kind
of
a
very
nebulous
answer.
But
it's
like
we
have
the
autonomy
to
just
like
work
on
this
stuff
and
we
we
do
see
metrics
as
like
a
potential
path
forward
for
us.
It's
not
set
in
stone.
Yet
there's
other
stuff
going
on
that.
F
I
don't
know
if
it's
worth
talking
about,
because
it's
quite
internal,
but
we
do
want
to
see
shopify,
adopt
open
telemetry
like
for
all
of
its
telemetry
signals.
E
Similarly,
at
github
I'm
in
charge
of
pushing
hotel
forward
across
the
company,
I
don't
spend
as
much
time
as
the
rest
of
the
shopify
team,
contributing
upstream
other
than
identifying
some
places
where
github
specifically
is
using
these
instruments.
These
instrumentation
libraries,
resources,
etc,
etc,
contributed
to
some
things
that
we're
missing,
but
my
time
mostly
is,
as
I
identify
a
problem,
I
try
to
address
it,
so
I
don't
have
like
a
real
capacity
allocation
to
this
project.
E
Specifically,
I
try
to
respond
to
pr's
questions
and
issues
as
they
arise,
and
I
try
to
my
first
hand
at
fixing
them
if
I
run
into
them,
but
that's
kind
of
where
kind
of
the
github's
whole
participation
is
on
this
project,
as
I'm
now
all
alone
after
andrew
left.
D
I've
seen
you
yeah
definitely
answer
questions
in
the
the
hotel
slack
channel
so.
F
The
better
quality
it'll
be
right,
and
I
think
that's
really
important,
like
shopify,
obviously
has
given
us
the
ability
to
invest
time
into
this
so
like
money
indirectly,
but
at
the
same
time
we've
been
doing
it
from
the
perspective
of
not
what's
best
for
shopify,
but
like
I
was
a
rails
developer
before
I
worked
at
shopify
right
so
like.
If
I
want
to
use
this
in
the
future,
I
want
to
make
sure
that
it's
not
just
useful
for
shopify.
F
F
At
this
point,
I
don't
know
if
anyone
has
anything
specific
they
wanted
to
dig
into.
We
could
just
kind
of
loosely
talk
about
metrics.
If
anyone
has
an
interest
in
that
it'll
be
less
code
and
more
hey.
Look
at
the
spec.
This
is
kind
of
my
next
steps.
Here's
some
things
that
are
a
bit
tricky,
but
blah
blah
blah.
Do
you
guys
want
to
do
that?
F
To
get
a
screen
to
share
sorry,
I'm
bad
for
talking
before
I'm
meeting.
Let
me
just
get
a
screen
to
share
here.
F
F
So
last
time
we
talked
about
this,
I
kind
of
went
over
a
bit
of
the
api,
some
of
the
implementation,
the
sdks
and
the
implementation.
My
last
commit
that
I
pushed
up
basically
fills
out
quite
a
few
blanks
in
the
meter
provider,
so
in
terms
of
meter
creation,
shutdown
force
flush.
F
Just
so
everyone
knows
where
that
is
it's.
It's
going
to
be
this
quite
long
living
whip.
I'm
going
to
try
to
have
decent
commits
that
group
together.
Substantial
pushes
forward
so
like
again,
just
filling
in
some
links
here,
trying
to
make
sure
that
documents
there
that
this
is
all
very,
very
similar
to
the
tracer
provider.
F
That
might
not
mean
much
to
everyone,
but
people
familiar
with
it.
You
can
kind
of
look
at
what
exists,
so
it's
like
what
I'm
trying
to
say
is
it's
nothing
particularly
new.
The
next
step
that
I
was
going
to
work
on
was
the
concept
of
views,
and
I
forget
where
views
came
from,
I
should
know
it's.
It
was
like
open
census
or
open
metrics
or.
F
F
You
could
basically
just
duplicate
information
but
slightly
different.
I
can
understand
why
that
may
be
useful.
It
is
quite
complicated
there.
The
spec
uses
these
nice
examples
from
python.
Python
actually
ripped
this
implementation
out.
So
it's
not
like
there's
any
like
this.
This
art
here
is,
has
gone,
so
it's
not
very
useful
as
something
as
a
comparison
point
javascript,
as
I
mentioned
last
time,
deviates
a
little
bit.
It
doesn't
look
like
this
at
all.
You
have
to,
I
think,
the
java
one
as
well.
F
You
create
this
concept
of
like
you
actually
have
to
put
together
a
view.
Then
you
have
to
put
together
your
instrument,
selection
criteria,
and
then
you
pass
that
to
the
add
view
method
which
in
my
mind,
is
not
like
overly
usually
user
friendly
because,
like
if
I'm
a
consumer
of
this-
and
I'm
like
I'm
gonna,
add
a
view.
It's
like
you
have
to
learn
these
constructs
and
build
them
together.
F
So
I
think
eventually,
when
I
do
work
on
this,
it's
going
to
be
a
little
bit
more
in
line
with
with
what
the
spec
says,
which
I
think
is
nicer
is
that
you
provide
this
method,
that
you
can
provide
a
bunch
of
optional
information
and
then
underneath
it
it'll
do
the
right
thing.
This
is
a
lot
of
like
long-winded
talking
to
say
that,
like
I'm,
not
doing
this
right
now,
I'm
going
to
try
to
punt
this
for
a
little
bit.
F
The
reason
being
is
it
just.
There
is
a
bunch
of
complexity.
There
is
a
bit
of
churn
in
the
spec
that
I've
seen
around
this
again.
The
examples
are
very
much
out
of
date.
I
expect
them
to
change,
so
I
don't
want
to
really
commit
a
lot
of
time
to
something
that
might
flip
on
me.
Instead,
the
the
aggregation
concept,
which
is
like
how
are
you
accumulating
these
metrics,
like
is
your
counter,
monotonic
or
delta?
F
Do
you
want
something
weird,
I'm
going
to
be
jumping
straight
to
that,
and
the
reason
for
that
is,
if
you
don't
have
a
view
configured,
there
is
default
aggregations
to
be
used.
So
your
default
aggregation
is
going
to
be
some
aggregation
for
these
meters
last
value,
histogram
aggregation.
So
the
idea
here
is
like
I
should
have
a
faster
path
forward
to
have
something
that
is
a
potentially
usable,
be
a
lot
easier
to
review
for
the
people
who
are
going
to
be
following
along.
So
I'm
going
to
jump
ahead
and
do
this.
F
You
can
add
your
meters,
you
can
add
your
metric
reader
and
then
you'll
have
this
kind
of
straight
shot
through
the
system
from
like
meter,
provider,
meter
and
instrument
creation
to
your
export
and
and
really
where
I've
kind
of
left
off,
like
the
pen
and
paper
sitting
there
with
like
some
work
in
progress
code
around
like
aggregation,
folder
and
like
sub
aggregation
dot
rb
with
like
an
empty
class
file,
that's
kind
of
where
I'm
at
right.
Now
with
this.
B
So
yeah
I
mean,
I
think
it's
I'm
still
not
sure
if
I
totally
understand
views,
but
I
think
it's
a
reasonable
approach.
You're
taking
in
theory,
you.
F
Know
yeah
we
we
discuss
like
so
when
I
say
we
so
I
meet
with
francis
about
once
a
week
and
we
discussed
this
and
we've
been
kind
of
working
on
this
together.
F
I
asked
him
because
I
I
haven't
spent
a
lot
of
time
in
the
metrics
world
prior
to
like
starting
this
project,
like
I've
done
like
the
basic
things.
I've
added
counters
places
right.
I've
made
very
simple,
datadog
dashboards,
but
in
terms
of
view,
like
I've
never
been
in
a
position
where
I'm
like
gee
whiz.
I
sure
wish
this
counter
could
be
three
different
metrics
right
it
just
it
hasn't
happened
and
like
so
I
you
know
I
talked
to
friends
I'm
like.
F
Can
you
give
me
an
example
of
like
where
you
think
this
might
be
useful?
And
so
he
said
well,
if
you
have
a
histogram,
maybe
you
want
to
take
your
histogram,
but
you
also
want
to
like
emit
a
raw
count,
so
you
could
take
a
view
and
you
could
take
that
histogram
and
you
could
just
take
basically
the
increment
from
it,
but
also
have
it
emit,
like
your
say,
your
histogram
values,
but
you
don't
necessarily
need
a
view
to
do
that.
F
You
can
just
do
like
in
most
observabilities
tools.
You
can
just
pull
a
raw
count
from
it.
So
I'm
not
entirely
convinced
that
views
make
sense
here,
but
I
think
what
it
is
is
that
it's
sort
of
a
requirement
that's
been
imposed
as
this
being
a
successor
to
other
specs,
that's
kind
of
what
I'm
picking
up
on
and
anything
that
I
read.
It
seems
more
of
like
a
compliance
thing
than
I
don't
know.
I
I
there's
probably
an
argument.
F
F
Here
I
think
this
one
is
so
you
have
your
counter
x
and
you
have
your
histogram
y,
so
metrics
from
x
and
y
will
be
reported
as
foo
and
bar
will
be
exported.
So
you'll
have
your
your
x
metric,
but
you'll
also
have
foo
and
bar
coming
out
of
your
histogram.
So
now
you
have
three
metrics
out
of
two
instruments.
D
The
the
thing
that
strikes
me
about
this
is
just
saving
the
performance
and
duplication
of
making
separate
metrics
that
do
kind
of
that
collect
the
same
data,
but
you
need
to
extract
different
numbers
out
of
them
right
because
otherwise
you'd
have
to
track
these
in
multiple
places
to
get
the
what
you
wanted
out
of
them.
If
you
wanted
different
things
out
of
them
right.
F
Yeah,
I
think
you'll,
if
you
hang
around
these
meetings,
you'll
notice,
that,
like
I
guess
like
the
perspective
like
I
should
share
like
at
shopify,
we
we
own
our
entire
collection
pipeline.
F
So
we
would
not
necessarily
do
these
things
at
the
application
level
so
like
when
I
say
oh
like
it,
doesn't
really
make
sense
to
me.
It's
like
well,
if
you're
you're,
an
application
owner-
and
you
don't
own
your
entire
export
pipeline,
then
this
makes
a
lot
more
sense
right.
Like
you're
saying
it,
you
don't
want
to
duplicate
instruments,
but
you
can't
necessarily
do
any
translations
after
the
data
has
left
your
application.
It
just
arrives
at
your
back
end
and
you
can
do
what
it
allows
you
to
do
so.
D
F
Yeah-
and
I
think
that's
like
a
good
question-
I
think
it's
one
that
will
never
be
answered.
There
are
some
people
in
like
the
spec
that
think
that,
at
the
application
level,
they
should
behave
almost
as
if
they're
collectors
that
allow
full
like
mutation
of
the
data
and
then
there's
some
people
that
say
no
like
your
applications,
should
just
emit
the
raw
data
and
not
do
anything
else
right.
B
B
You
can
hope
you
can
get
a
vendor
to
pay
for
it,
for
you
like
it
depends,
it
depends,
is
the
beginning
and
end
of
every
discussion,
but
okay,
that's,
though
this
is
actually
useful.
Thank
you
for
pointing
me
to
this.
This
helps
a
little
bit
grock
views.
I
think
I
just
need
to
actually
put
yeah
hands
to
keyboard
and
get
more
familiar
with
it
this,
but
this
is
good.
F
E
F
Is
something
that
needs
to
be
configurable
at
the
stk
level?
I
need
to
like
comb
through
the
spec.
Again,
I
don't
know
if
it's
per
instrument
or
per
the
entire
sdk,
but
it
should
default
to
this
sum
aggregation.
F
But
you
can
also
say
that
your
default
is
drop.
Aggregation
so
only
emit
the
metrics
that
you
care
about.
So
more
of
like
an
an
opt-in
than
an
opt-out
approach,
it
leaves
a
kind
of
nebulous
to
say,
like
language
authors
can
kind
of
decide
what
makes
sense
here.
How
do
you,
however?
You
want
to
do
this,
but
I
I
don't
know
again:
it's
like.
F
B
Do
you
have
a
sense
of
if
there's
a
particular
language
out
there,
which,
like
kind
of
has
a
really
well
done,
metrics
thing,
and
not
just
for
the
sdk,
but
like
an
actual
instrumentation
with
metrics
like
I,
or
are
they
mostly
at
the
like
sdk
level?
No
one's
really
done
the
like.
Oh.
B
F
I
haven't,
I
haven't
seen
that
and
I
don't
think
if,
like
when
we
get
to
the
point
where
this
is
done.
I
don't
think
we'll
see
that
internally
either
like
talking
about
like
metrics,
auto
instrumentation.
I
think
we'll
see
very
little
of
that
internally.
That's
something
that
that'll
probably
go
away
right
because
we
get
that
offer
spans.
So.
B
Yeah
yeah!
No,
I
agree
I
just
that
would
give
me
a
it's
like
you
know,
a
playground
for
me
to
have
to
do
zero
thought
and
be
like
cool
okay.
Now
I
can
see
this
indent
right.
F
I
haven't
seen
that
no,
I
think
it's
like
the
best
you'll
get
or
the
best
I've
seen
right
now
is
just
like
scrolling
through
and
looking
at
the
like,
ascii
art,
perfect.
B
F
F
I
think
that's
that
thanks
everyone,
thanks
for
even
showing
up
hope
you
had
fun.
Seeing
you
all
see.