►
From YouTube: 2020-09-15 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
Yep,
so
I
have
a
fun.
I
have
a
fun
pr
on
the
datadog
tracer
that
I
think
we
might
want
to
upstream
to
open
telemetry,
but-
and
it's
actually
maybe
applies
to
open
tracing
too-
which
I
guess
matt
is
the
proud
author
of,
which
is
that
there's
a
customer
who
pays
a
lot
of
money.
A
So
we
paid
attention
to
them
that
complain
that
ruby's
wall
clock
is
super
inaccurate,
apparently
and
there's,
and
he
found
this
whole
blog,
it's
actually
really
cool
and
that
we
should
use
monotonic
clock
when
possible
to
measure
duration.
Essentially,
wall
clock
can
drift
in
between,
like
time,
dot
now
invocations.
A
B
Yes,
so
golang's
built-in
time
will
capture
both
the
wall,
clock
and
monotonic
time
and
then
for
computing
durations.
It
will
compute
it
from
the
monotonic
time
yeah.
I
remember
there.
The.
A
Articles,
let
me
find
the
article
it's.
I
guess
cloud
cloudflare
had
a
crazy
outage
some
time
ago
related
to
this,
so
the
dns
simple
folks
get
a
really
good
blog
on
it
anyway.
So
that's
a
fun
one
that
I
was
just
trying
to
explain
to
my
boss
that
maybe
can
apply.
A
C
I
know
I
think
using
the
monotonic
clock
is
probably
the
right
approach
yeah,
but
we're
using
the
wall
clock
like
I
don't
know
the
only
I
I
guess
I
haven't
heard
of
anything
too
terrible
happening
from
that
yeah
in
the
real
world.
Apparently,
but
apparently
there
was
this
outage,
so
that
sounds.
A
Pretty
good,
like
you're,
you
know
it's
like
your
duration
of
one
span
of
a
million
is
off
by
10
milliseconds,
I
don't
know
like,
but
someone
complained
and
they're
an
enterprise
customer.
So
we're
doing
it.
C
A
But
no
that's
cool
anyway!
I
just
wanted
to
share.
I
thought
it
was
it's
a
fun
learning
moment
for
me.
C
So
is
this:
what
you're
up
to
right
now
is
switching
everything
over
to
use
it
yeah.
A
Kind
of
and
there's
all
these
like
weird
edge
cases
where
it's
like
well
what?
If
the
user
supplies
the
finish
time,
but
you
wanted
to
use
monotonic
time,
but
you
weren't
keeping
track
of
when
the
span
started
at
first,
because
you
thought
you
were
using
monetize,
that's
a
go!
Well,
we
have
to
so
now
we
have
all
these
extra.
So
now
our
span
class
grows
to
be
gross
and
have
lots,
lots
more
things
to
track
on
it.
A
A
C
C
C
Right
so
the
spec
sig
actually
just
wrapped
up,
so
it
should
be
somewhat
fresh
in
my
mind,
so
we
can
go
through
that
and
then
hop
over
to
to
our
repo
and
issues
planning
etc.
C
C
C
They
did
triage
quite
a
few
things
in
the
beginning,
like
those
like
new
issues
that
came
in
and
yeah
one
issue
I
felt
was
somewhat
interesting:
was
I've
been
paying
a
ton
of
attention
to
metrics?
I
think
most
of
us
here
probably
haven't
been
as
much
as
maybe
tracing
anyways
but
like
yeah.
C
I
think
I
kind
of
knew
this,
but
it
really
sunk
in
when
somebody
opened
up
an
issue
like
in
for,
like
spans,
all
of
our
key
value
pairs
are
called
attributes
and
the
typing
is
a
little
bit
different
from
metrics
they're
all
called
labels,
and
I
think
they
all
have
to
be
strings,
and
this
was
confusing
for
people
and
there's
some
talk
about
trying
to
maybe
unify
that
some
way.
But
it
seems,
like
you
know,
it's
it's
inconvenient,
but
there's
reasons
it
was
kind
of
the
tldr.
B
Yeah,
I
was
just
curious
about
the
the
otlp
spec
for
metrics,
I
understood
and
possibly
incorrectly
that
attributes
were
reused,
so
there
were
like
the
the
typed
attributes
also
for
metrics,
but
I
might
be
confused.
It
might
just
be
that
they
apply
to
resources
as
well.
B
C
C
C
C
C
Basically,
the
proposal
here
is
that,
for
your
start
span
api,
if
you
want
to
manually,
provide
a
parent.
This
is
proposing
that
you
do
this
by
passing
in
a
context,
not
a
span
context,
not
a
span
and
right
now.
I
think
we
allow,
I
think
we
allow
span
or
a
context.
C
I
think
we
allowed
all
three
at
one
point
in
time,
but
I
think
I
think
I
might
have
opened
the
pr
that
did
that
and
francis
was
like
this
is
a
lot
of
context,
and
I
think
we
at
least
agree
that
having
a
handle
on
just
like
a
random
span
context
after
after
oshap
66,
which
was
the
thing
that
brought
in
this
kind
of
unified
context,
it
just
seemed
like
you
would
have
to
try
really
hard
to
have
one
if
it
was
really
even
feasible.
C
So
so
I
think
we
already
got
rid
of
this
band
context
as
an
option.
So
I
think
it's,
I
think
it's
trivial
to
kind
of
get
rid
of
spam
as
an
option.
Probably
we'd
have
to
look
at
instrumentation,
but
I
think
given
where
we
are.
C
Those
should
be
easy
enough
to
to
work
around,
but
but
the
whole
reasoning
behind
this
is
that,
with
this
unified
context,
there's
a
lot
there's
a
lot
of
stuff
in
the
context
like
baggage
and
other
things
and
right
now,
the
only
thing
we
really
need
out
of
there
is
span
context.
But
if
you
wanted
to
add
baggage
to
as
like
span
attributes
for
example,
then
you
need
the
full
context
if
you
just
pass
in
a
span,
you're
missing,
you're,
missing
part
of
the
picture.
C
So
I
was
kind
of
looking
at
zorro
yesterday
and
I
at
least
left
a
comment.
My
my
only
comment
really
was
that
I
do
think
this
makes
the
api
is
more
and
more
awkward.
That's
my
only.
C
Feedback-
and
that
is,
I
think,
it
makes
start
span
using
start
span
passing
the
stuff
in.
I
think
it
improves
it,
but
I
think
the
fact
that,
like
start
span,
return
to
span-
and
I
think,
half
the
time
you
actually
want
to
span
half
the
time.
You're
probably
gonna
want
a
context.
C
I
guess
it
just
becomes
the
situation
where
some
of
the
inputs
to
some
of
your
api
methods,
our
contacts
and
contacts,
is
just
kind
of
like
lurking
in
the
shadows,
at
least
in
the
ruby
implementation,
it's
kind
of
just
hanging
out
there
and
a
threat,
local
and
there's
an
api
to
get
it.
But
it's
not
really
like
something
that
you're
actively
dealing
with
has
like
a
return
value
for
things,
but
in
general
I
think
this
is
fine.
C
I
think,
for
the
most
part
in
ruby,
you're,
almost
never
going
to
you're
kind
of
going
to
rely
on
this
automatic
in-process
context.
Propagation
you're
always
going
to
pick
up
the
implicit
span,
except
for
I
think,
more
advanced
use
cases,
in
which
case
you
kind
of
know
what
you're
doing
and
having
start
span
return
a
span.
I
think
it
still
makes
sense
because,
like
often
times
you're
going
to
want
to
interact
with
that
span
and
add
events,
add
attributes.
C
Things
of
that
nature,
like
I
think,
go,
has
the
best
of
both
worlds.
In
that
their
start
span
method
returns
both
a
context
and
a
span,
so
you
can
easily
get
a
handle
on
whichever
one
you
you
really
wanted,
but.
C
Yeah
they're
lucky
in
that
multiple
return
values
are,
are
common
and
idiomatic
there,
whereas
they're
really
not
for
for
ruby
and
other
languages
as
well.
So
we're
not
alone
here
but
yeah.
I
think
I
think
in
general.
This
makes
a
lot
of
sense.
I
think
we
do
need
to
kind
of
just
make
sure
that
apis
are
not
too
weird.
B
We
have
a
bunch
of
places
right
now
that
are
doing
certainly
an
instrumentation
where
we're
passing
in
with
parent
context
to
start
spam,
and
I'm
just
looking
at
an
example.
But
it's
the
the
extracted
extracted
context.
So
I
guess
that's
context
rather
than
span
context.
Is
that
right,
yeah.
C
With
context
is
the
actual
context,
which
is
the
thing
that
you
want
to
be
passing
in,
I
don't
think
we
allow
passing
in
a
span
context
any
longer.
The
only
other
thing
that
you
would
possibly
see
is
passing
in
a
span
itself,
but
like
yeah,
I
think
that's
where
things
just
become
ugly,
because
I
think
in
a
forward-looking
sense,
like
there's
gonna,
be
more
to
the
story
than
just
the
span
for
for
parenting.
C
Yes,
yeah,
I
think
you
know
all
this
kind
of
makes
sense
if
you
look
at
how
we
got
here,
but
I
think
I
don't
know,
I
definitely
know
a
lot
of
this
came
from
open
tracing
where
span
context
was
your
only
context
because
tracing
was
the
only
thing
you
were
worried
about,
and
it
was
just
kind
of
like
the
serializable
part
of
a
span
and.
B
So
inside
the
api
implementation
at
least
of
start
span.
There's
we
extract
the
span
context
and
then
pass
that
into
span
new,
but
yeah.
It's
like
we
have
that
one
spot
where
you
can
retrieve
the
active
span
context
from
a
context
and
yeah.
I
guess
that's
a
real
span
context
rather
than
something
else.
C
Yeah,
so
I
think
you
know
we
still
are
going
to
have
that
internally.
I
think
you
are
going
to
want
span
initialize
to
take
a
span
context,
but
I
think
it
should
not
really
be
something
that
that
a
user
would
ever
encounter
and
yeah
that
actually
span
context
is
not
another
thing
that
has
to
kind
of
do
with.
This
is
big
context.
Overhaul.
C
C
Basically,
there's
a
situation
where,
when
you
extract
span
off
the
wire,
all
you
kind
of
have
is
a
span
context.
So
sometimes,
when
you
are
looking
for
that
parenting
information
it'll
just
be
the
spam
context
that
you
pass
to
span
initialize.
C
Sometimes
you
will
have
like
an
active
span
in
your
contacts
like
a
legitimate.
You
know
ruby
object
span.
In
that
case,
you
want
to
span
dot
contacts
to
pass
into
new
and.
C
Yeah
tldr
is:
we
could
always
make
this
a
span
if
we
wrap
that
extracted
span
context
if
we
initialize
a
new
span
with
that
span,
context
on
extract,
and
that
would
clean
this
off
just
a
little
bit.
B
C
Cool
yeah,
I
think
I
think
that's
good.
I
think
we
can
make
sure
that
the
span
context
doesn't
really
get
out.
I
think,
or
it's
much
harder.
C
C
Think
I
think
most
of
these
did
not
actually
get
covered
kind
of
these
additional.
I
think
they
all
kind
of
end
up
being
related
to
this
argument,
but
we
spent
so
much
time
talking
about
kind
of
that
core
issue
that
we
didn't
get
into
all
of
these
details.
C
But
I
think
these
proposals,
these
additional
proposals
and
issues
are,
are
semi-related
and
yeah.
I
think
java
has
a
lot
of
like
context
utils
to
get
at
stuff.
In
the
context,
I
think
our
stuff
is
available
on
different
objects.
I
think
we
kind
of
have
like
some
class
methods
on
trace
or
something
that
help
us
get
some
of
this
stuff.
C
B
Ahead,
yeah,
sorry,
it
looks
like
most
of
our
utils
are
methods
on
tracer
yeah.
C
Yeah,
I
think
I
think
they
ended
up
there.
I
think
at
one
point
I
started
introducing
contextuals
and
it
did
not
go
over
super
well,
but
it
was
somewhat
like
because
of
what
I
was
seeing
over
in
the
java
project,
so
I
think
they
actually
have
kind
of
gone
that
route
a
little
more.
I
do
like
what
we
are
doing
a
little
better,
so
yeah.
I
just
want
to
make
sure
that
we
leave
the
door
open
for
this
approach
because
it
did
seem
like
an
improvement
to
me.
C
C
Yeah
I
mean
I
feel
like
there
are
a
million
optimizations
you
could
make
around
unsampled
like
for
me.
I
think
the
holy
grail
would
be
to
like
not
even
have
to
create
a
new
span
or
anything
that
goes
with
it,
but
I
think
some
of
the
design
decisions
for
hotel
make
this
kind
of
hard,
but
but
yeah.
B
We
don't
create
a
spanner.
We
create
a
an
api
span
which
is
kind
of
the
no
op
span.
That's
just
carrying
the
span
context
around
if
we're
not
sampled
or,
I
think
not
recording.
If
we're
not
recording.
B
So
that's
one
like
tiny,
optimization,
it's
not
very
significant
because
we
do
need
to
generate
the
span
id
before
we
call
the
sampler
that
actually
looks
to
be
incorrect
and
just
looking
at
the
flow
here,
we
could
choose
to
create
the
span
id
later.
C
B
Yeah
I
mean
it
requires
a
trace
id,
it
doesn't
require
the
span
id,
so
the
span
id
isn't
passed
into
the
sampler
anymore.
We
just
pass
it
into
internal
create
span,
but
we
then
only
use
it
in
the
case
where
we're
recording.
B
A
possibility
here,
I'm
actually
just
trying
to
find
the
use
of
span
id.
B
C
So
there
is
this
summary
that
says
from
the
sig
meeting.
If
you
have
an
unsampled
child
propagate
the
parent
span
id
as
the
span
id,
but
then
there
are
some
questions
about
root
stands:
should
it
be
the
all
zeros
or
a
new
span
id
the
trace
id
always
needs
to
be
generated
for
sample
import
focus.
That
is
the
thing
that
I
was
remembering.
B
Yeah
but
at
least
you
only
need
to
create
one
span
id
and
one
trace
id
potentially.
Oh
sorry,
potentially
span
id,
definitely
the
trace
id.
But
if
you're
not
sampled
and
you've
got
something,
that's
respecting
the
parents
sampling
decision,
then
you
can
avoid
creating
spam
id's
for
all
the
children.
C
Yeah,
so
it
seems
like
my
guess,
is
there
will
be
some
amendments
to
the
sampling
spec
as
a
result
of
this.
That
will
pick
up
at
some
point
once
the
details
are
hashed
out.
C
I
don't
think
we
got
to
this,
but
this
has
been
a
hot
topic.
I
was
gonna,
do
this
and
make
sure
to
comment
on
it
today,
but
it's
kind
of,
like
I
don't
know,
there's
a
lot
of
proposals
like.
C
I
think
some
of
the
proposals
have
been
just
drop,
mills
or
nulls,
or
some
proposals
have
been
that
like
if
you
set
an
attribute
and
then
reset
it
to
a
null.
It
means
you
should
delete
the
attribute
and
those
things
sound
weird
to
me.
C
C
C
I
think
technically
this
is
this
is
not
valid.
We
expect,
I
think
we
expect
in
our
export
pipeline,
that
an
attribute
is
like
a
string,
a
number,
a
boolean
or
an
array
of
those,
and
I
know
the
jaeger
exporter
will.
C
Will
fail
to
export
your
data
if
you
actually
have
any
mills
in
it
at
least,
and
there
is
a
pr
yeah.
One
of
these
open
pr's
that
we
have
from
long
long
ago
was
was
attempting
to
fix
that.
We
should
probably
dust
that
off
someday,
but
it
is.
C
It
is
this
deferred
attribute.
Validation
until
finish
is
called,
I
believe,
will
help
help
with
that
issue,
but
yeah
any
opinions
here
as
to
how
null
should
be
handled.
B
B
I've
seen
these
proposals
going
back
and
forth
over
quite
a
long
time
now
for
a
behavior
of
nulls
behavior
of
empty
strings.
All
these
sort
of
things.
A
A
C
A
B
C
There
was
a
little
bit
of
talk
about
async
resource
detection
and
how
this
cramps,
it
definitely
cramps
the
style
of
javascript
and
I'm
sure
it
causes
issues
for
everybody
if
you
think
about
it.
But
ultimately,
I
think
the
the
core
issue
is
that.
C
We
we
have
these
resources,
you
have
ways
to
detect
them,
some
of
them
introduce
some
latency,
I
guess
and
failure
modes
on
top
of
it.
So,
but
your
resources
are
attached
to
spans.
You
can't
really
export
your
span
until
your
resource
has
resolved
whatever.
That
means,
and
if
anything
did
fail,
your
resource
could
be
incomplete.
What
does
that
mean
for
your
application
and
just
kind
of
a
discussion
around
all
of
those
all
the
implications
there?
C
And
I
think
I
don't
know.
I
think
there
are
some
real
concerns
here,
especially
I
think
for
a
lot,
a
long
running
process.
All
of
this
is
just
kind
of
like
a
drop
in
the
bucket,
and
you
know
things
might
be
a
little.
C
You
know
the
first
10
seconds
of
your
process.
Life
might
like
not
go
exactly
the
way
you
would
like
it
to,
but
this
is
how
starting
up
processes
generally
work
like
there's.
There's
things
going
on.
There's
startup
costs,
I
guess,
but
for
things
that,
like
lamb
does
or
other
like
short
running
processes.
These
are
in
a
matter
of
a
very
expensive
bill
at
the
very
least,
and
also
probably
some
perf
concerns.
C
So
I
don't
know
what
the
what
the
answer
or
really
what
kind
of
exactly
the
ask
here
is
other
than
like.
There
are
some
concerns
around
it
all.
C
C
So
yeah
and
because
I
ranted
forever
about.
C
Before
it
was
abandoned,
like
this
is
kind
of
the
next
generation
of
of
that
and
ultimately
on
this
error
hint
pr
that
I
had
it
had
two
components:
it
was
an
arrowhead
semantic
convention,
but
it
also
dovetailed
with
the
record
exception
api,
and
so
we
have
spam
record
exception,
and
I
wanted
you
to
be
able
to
pass
the
error
hint
into
that
and
it
would
kind
of
assign
it
as
required,
and
that
was
actually
the
sticking
point
was
like
you.
You
can
have
the
semantic
convention.
C
People
are
okay
with
that,
but
no
api,
and
I
thought
that
was
I
don't
know.
I
felt
like
you
really
needed
the
api.
I
felt,
like
they
kind
of
went
hand
in
hand
and
that
just
a
semantic
convention
without
the
api
was
just
asking
for
problems.
So
I
started
to
kind
of
just
walk
everything
back
and
I
was
like,
I
think,
we're
better
off
with
spam
status.
To
be
honest,
and
we
should
probably
just
keep
spam
status.
C
Maybe
we
we
could
reduce
it
to
okay
or
not
okay.
I
would
be
fine
with
that
and
then
that
kind
of
idea
evolved
into
this
otep,
which
is.
C
Which
was
championed
by
ted,
because
I
was
fairly
exhausted
by
by
error
hint,
but
as
long
as
this
hasn't
dramatically
changed
in
the
last
day
or
so
the
yeah.
The
key
points
are
that
this
is
basically
reducing
yeah,
so
reducing
the
status
space
to
be
unset,
error
or
okay.
C
So
this
would
change
things
a
little
bit,
whereas
I
think
the
default
spam
status
is
okay
and
I
think
I
don't
know,
I
think
the
idea
for
unset
versus
okay
is
that.
Okay
is
somebody
like
saying
hey.
This
is
okay,
not
somebody
forgetting
to
set
the
status
code,
so
that
would
be
the
difference
between
unsaid
and
okay.
C
I
do
think
that
this
might
say
that
instrumentation
cannot
set
something
to
okay,
which
I
don't
know
that
I
fully
understand
or
agree
with,
but
that
could
have
changed
and
then
there's
this
kind
of
status
source
who
was
setting
the
status
of
the
instrumentation
or
is
it
the
user?
I
think
this
is
here
to
kind
of
give
back
ends
more
information
about
how
much
they
should
trust.
This
personally,
I
kind
of
feel
like
you're
always
going
to
want
to
be
able
to
change
your
mind
on
the
back
end
without
having
to
redeploy
code.
C
So
I
personally
don't
know
that,
like
I
would
be
lobbying
for
this
here,
but
at
the
same
time
I
think
it's
fine,
so
that's
it
fan
status,
would
change
to
be
on
set
error
or
okay
and
it
would
also
kind
of
have
a
status
source.
C
C
It
hasn't
been
approved
yet,
but
it's
looking
like
people
are
generally
okay
with
it.
It
looks
like.
C
C
This
is
very
likely
the
the
rod
that
we're
taking
for
for
indicating
that
a
span
is
okay
or
has
had
an
error.
C
All
right,
I
think,
that's
the
end
of
this
specific.
I
was
hoping
to
be
able
to
like
rattle
through
that
a
little
faster,
because
it
was
a
little
more
fresh
in
my
mind,
but
maybe
the
opposite
happens.
I
had
more
details
to
add,
but
anyhow,
as
it
starts
going
long
always
feel
free
to
like
reign
me
in
and
stop
me.
If
I
get
too
far
off
into
the
weeds
yeah,
I
think
we
can
move
on
to.
C
Two
two
things
more
relevant
to
our
project.
We
had
a
release
last
week,
which
is
exciting.
I
know
some.
C
Some
new
packages
went
out
an
otlp
exporter,
jaeger,
thrift,
compact
thrift
or
http
exporter
and
a
memcache
instrumentation
dolly.
So
I
think
all
that
is
super
exciting.
C
I
was
kind
of
watching
from
the
sidelines
as
the
release
process
happened.
I'm
glad
I
was
on
the
sidelines
I
think,
but
like
it
seems
like
yeah,
it
seems
like
the
first
time
you
run
through
a
new
process.
You
always
have
to
work
awesome
kings.
It
looks
like
those
were
worked
out.
This
is
true.
C
Well,
thank
you
thanks
to
both
of
you
for
working
through
that,
I
think
future
releasers
will
be.
Yeah
will
be
the
benefactor
of
that
whole
experience,
but
it's,
I
think
it's
it's
expected
to
have
some
hiccups
like
this.
I
think
it's
actually
payback
for
the
previous
release
process,
because
if
I
remember
that
went
pretty
flawlessly
and
that
never
happens
so.
C
So
yeah,
I
guess
the
question
is:
do
we
have
what
are
we
working
on
now?
Do
we
have
a
new
milestone.
B
B
I
would
imagine
that,
like
metrics,
I
don't
know
who's
eager
to
work
on
metrics
at
the
moment,
but
I
imagine
that's
going
to
get
punted
again
we're
going
to
have
some
cleanup
items
from
the
spec
changes
that
are
coming
down
the
pipe
you
know,
open
census
will
probably
pump
again
because
I
still
don't
know
what
the
status
of
that
is.
C
Okay
yeah
so.
C
I
guess
it
probably
makes
sense
for
us
over
the
next
week
or
so
to
kind
of
maybe
make
some
decisions
on
this
next
milestone
as
to
like
what
should
really
be
in
and
what
should
be
out
and
kind
of
go
from
there
unless
we
have
strong
ideas
right
now,.
C
A
A
B
A
B
Yeah,
it's
a
fair
bit
of
work
and
there
was
still-
or
there
was
a
lot
of
churn
at
the
time.
I
don't
know
if
there's
still
a
lot
of
children.
It
feels
that
way.
A
A
Yeah,
I'm
I'm
curious
from
any
anecdotal
use
if
any
of
the
other
languages.
How
frequent
is
it
that
these
instrumentations
come
with
metric
packages
as
part
of
the
instrumentations?
Is
that
the
can?
So
if
I
were
tracking
something
as
trivial
as
like
hits,
you
know
on
sinatra?
A
Is
that
intended
to
be
a
metric,
gets
generated
from
application
and
sent
to
collector
exporter
via
you
know
in
a
metric
pipeline,
or
is
that
meant
to
be?
You
know
grabbed?
Is
it
like
vendors
calculated
it
on
their
own
after
the
fact,
based
on
traces
or
sort
of
like?
What's
the
convention
other?
C
I
think
I
don't
know
I
I
I
haven't
seen
metrics
really
being
generated
in
instrumentation,
yet
I
know
there
was
some
work
going
on
in
js
to
like
make
like
the
meter
provider
available
to
instrumentation.
There
were
some
kind
of
more
complications
in
the
design
over
there
to
where
it
was
kind
of
hard
to
get
a
meter
provider
to
begin
with.
Since
that
said,
it
could
enable
such
things,
but.
C
Yeah,
I
think
I
think
this
is
gonna.
This
is
going
to
be
a
common
request
like
if,
if
somebody
said
no
metrics
from
instrumentation,
I
think
you
could
work
around
things
like
that.
Potentially
either
you're
like
you
know,
either
you're
not
sampling
your
spans
and
you're.
You
know
right.
C
But
once
everything
comes
together,
people
will
probably
want
some
kind
of
metrics
for.
B
Yeah,
like
there's
a
a
bunch
of
stuff
in
the
spec,
I
think
around
trace
exemplars
for
metrics
and
there's
kind
of
an
assumption
there
that
you're,
potentially
sampling
at
less
than
a
hundred
percent
and
you're
wanting
to
attach
an
example
traced
to
a
metric.
If
you
happen
to
have
one
so
I
mean
looking
at
go,
which
has
the
most
mature
metrics
implementation
in
the
sdk.
Its
contrib
package
for,
like
net
http,
doesn't
capture
any
metrics.
It
only
records
spans.
A
And
and
so
and
you
can
and
just
to-
and
this
is
because
I'm
I'm
really
not
very
familiar
with
the
collector,
I'm
starting
to
get
a
little
more
comfortable
there,
because
they
kind
of
want
me
to
I
don't
go,
which
is
bad,
but
the
you
can't
send
traces
to
like
a
metric
pipeline
right
and
then
have
some
sort
of
like
metric
calcs
traces
go
to
a
trace
pipeline.
They
will
get
rejected
if
they
go
to
there's
no
such
thing
as
like
some
sort
of
metric.
B
Pipeline
or
exporting
from
traces
you
could
compute
metrics
from
traces
on
a
back
end
or
in
a
collection
pipeline.
This
is
certainly
something
that
I
think
the
light
step.
Satellites
traditionally
did
you
know
the
signalfx
collectors,
also
smart
gateway,
whatever
they
called
it.
That
also
did
this
kind
of
metricization
of
spam
yeah.
B
So
you
can.
You
can
do
that.
It
assumes
that
you're
tracing-
you
know
a
hundred
percent
sure
or
you
want
to
get
activated.
A
Yeah
right
and
then
to
be
clear:
datadog
does
that
on
our
agents,
you
know
it's
just
a
matter
of
like
if
we
want
to
port
that
to
a
collector
it's
like.
Should
I
just
be
shoehorning
that
in
into
a
trace
exporter
or
should
I
be
have
some
sort
of
separate
like
we
have
a
metric
exporter
but
for
trace
metrics,
specifically,
you
know:
is
there
a
separate
metric
exporter?
Is
there
a
or
it
sounds
like
a
shoehorn
in
the
statsd
or
api
stuff
into
a
trace
exporter,
which
is
fine?
Okay,
that.
B
B
Right
now,
just
because
we
don't
have
a
metrics
implementation,
once
we
have
the
metrics
implementation,
then
I
think
we
probably
want
to
make
it
a
little
bit
more
structured.
You
know
it's
an
impediment
right
now.
I
want
to
record
metrics
from
the
otlp
exporter
right
and
I,
like
I,
don't
even
have
an
api
for
doing
that.
Yeah
yeah
yeah,
which
is
cumbersome.
A
No,
I
get
it
and
yeah.
I'm
also
curious
whether
we
should
be,
as
you
know,
if
I'm
doing
integrations
it's
like
do.
I
need
to
keep
in
mind
like
okay,
put
a
little
note
here
being
like
here's,
where
I'm
gonna
marca,
you
know
put
notes.
C
Yeah
I
haven't
seen,
I
guess
it's
something
to
keep
an
eye
out,
for
it
is
how
it's
how
those
metrics
are
being
handled
in
kind
of
the
dovetail
between
metrics
and
and
instrumentation.
C
C
C
A
B
B
Yeah,
I
think
we
should
do
a
pass
through
this.
These
milestones,
or
at
least
like
this
beta07
milestone.
We
probably
want
a
like
a
point
release
before
this.
That
is
just
a
bug
fixed
release
for
some
of
the
things
that
have
been
reported.
B
I
know,
for
example,
like
implementary
state
in
api.
This
is
something
I
realized
we
didn't
implement.
It
was
spec,
maybe
a
month
or
so
ago,
so
yeah
there's
a
couple
of
small
tweaks
like
that.
B
We
may
want
to
release
before
addressing
any
of
the
larger
things.
C
Yeah,
I
I
think,
that's
fine.
I
know
there
has
been
some
issues
that
have
come
in.
I
think
a
lot
of
them
are
around
documentation.
If
anything
but
yeah,
I
could
see
having
a
smaller
release
for
things
that
we
missed,
or
just
small
fixes
or
improvements
to
things
that
we
recently
released
yeah.
I
think
given
given
the
time
we're
unlikely
to
probably
come
up
with
that
milestone
right
now,
but.
B
I
can
work
on
that
over
the
next
week
and
try
to
have
something
reasonable
for
a
quick
follow-up
release
that
will
address
some
of
these
things
like
documentation
and
so
forth.
C
Cool
yeah
and
I
think,
as
always,
I
think
nobody
is
ever
going
to
be
upset
if
an
instrumentation
shows
up,
even
if
it's
not
one,
that
we
had
in
a
milestone.
If
somebody
wants
something-
and
you
know
if
yeah,
if
you
personally
want
something
for
for
something
or
if
a
customer
wants
something
like
feel
free
to
contribute
it
and
nobody's
going
to
be
upset.
A
A
This
is
okay,
it's
not.
A
Oh
yeah,
I
think
I'm
okay,
I
can
try
to
I
notice
one
or
two
stuff
with
the
new
collector,
just
the
readme
docs
scene,
there's
like
just
random
things.
I
can,
like
the
examples,
have
some
some
random
typos.
So
I
can.
I
should
be
able
to
make
a
pr
I
meant
to
do
that
over
the
weekend.
I
don't
have
anything
else.
As
far
as
I
know,.
B
Cool,
we
probably
need
to
clean
up
the
top
level
readme
as
well.
I
think
our
matrix
of
release
information
is
probably
woefully
out
of
date.
At
this
point,.
C
Yeah
yeah
on
that
note,
like
I
did
notice
that
oh,
I
should
have
linked
to
it,
but
there's
the
spec
compliance
issue
and
a
bunch
of
new
tables
appeared
since
francis
filled
it
out
a
couple
weeks
ago.
So
we
should
probably
go
through
and
and
fill
that
out
at
some.
C
B
B
A
B
Need
to
specify
insecure,
true,
so
insecure
defaults
to
false
okay,
yeah,
all
right
yeah,
so
there's
there
may
be
an
environment
variable
for
that,
I'm
not
sure.
Let
me
check
I.
A
B
A
Good
to
know
all
right,
that
was
yeah
containers,
good
times,
cool.