►
From YouTube: 2021-12-07 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
It's
not
the
usual
time
that
we
start
probably
had
a
long
enough
of
awkward
silence
or
no
are
we
expecting
anybody
else.
B
All
right
go
ahead
and
recap:
the
specs
egg.
B
The
first
thing
that
came
up
is
there
is
this
remote
configuration
the
op
amp
spec
and
for
now
it's
kind
of
been
scoped
to
the
collector,
but
I
think
it's
trying
to
talk
about
whether
or
not
it
should
be
used
to
be
able
to
configure
sdks.
B
This
is
all
about
kind
of
like
remote
configuration,
so
I
think
right
now,
there's
just
an
issue
where
people
are
discussing
these
things.
B
I
haven't
seen
exactly
how
this
will
work
with
the
collector
but
like
in
general,
like
I'm,
in
favor
of
being
able
to
configure
these
things
in
whatever
way
is
most
easiest,
but
having
worked
on
some
of
these
telemetry
clients
where
they
are
remotely
configurable
like
there's
like
this
weird
things,
get
really
weird
when
you
start
up
knowing
like
what
your
configuration
should
be
because
you
kind
of
have
like
local
configuration,
and
you
can
run
with
that
until
you
hear
back
from
your
remote
configuration
like
what's
happening
and
it
just
creates
interesting
race
conditions
and
other
things
at
startup.
B
I'm
not
sure
if
anybody
has
any
opinions
here.
D
So
is
this,
like
your
collector,
could
manage
the
configuration
on
your
clients.
B
It
seems
so
if
we
back
this
up,
I
feel
like
you
have
just
something
else
that
can,
I
think,
it's
just
defining
a
protocol
for
like
sending
a
configuration
to
a
thing
and
that
thing
has
been
the
collector
so
far,
so
I
don't
know
that
would
be
like
collector
to
sdk
necessarily,
but
it
could.
D
What
yeah,
just
yeah,
just
I
was
wondering,
because
it's
something
we've
like
kind
of
talked
about
loose
in
the
past,
is
like
what
if
we
could
configure
all
the
configuration
defaults
for
all
of
our
clients
through
the
collector.
That
way,
we
don't
have
to.
B
B
B
I
guess
I'll
keep
an
eye
on
this
and
try
to
figure
out
exactly
what
what
all
the
components
are
and
where.
What
the
flow
of
configuration.
B
Was
kind
of
a
misnomer
in
some
situations,
for
the
thing
that
is
kind
of
producing
the
telemetry
and
they
were
talking
about
changing
instrumentation
scope.
Possibly
they
ultimately
decided
that
this
was
not
a
good
change
and
it
did
not
actually
solve
the
problem
that
it
was
proposed
to
solve.
B
B
I
think
for
logs
they
would
like
to
add
an
observed
timestamp.
So.
B
I
don't
know
what
to
say
about
that,
but
that's
there.
This
ended
up
getting
discussed
for
a
while,
and
I
think
we
discussed
this
again.
B
Last
week,
a
bit,
but
ultimately
there
right
now,
service
name
is
a
required
attribute
on
a
resource,
and
this
is
what
a
lot
of
telemetry
backends
want
to
use.
As
kind
of
like
the
thing
that
identifies
you
know
the
application
that's
generating
telemetry.
B
There
is
a
client-side
sig,
that's
kind
of
been
spinning
up
and
they're
dealing
more
with
like
browser
applications
in
other
client
applications.
I
think
you
know
like
ios
and
iot,
and
they
don't
like
the
name
service
name
does
not
well
does
that
work
super
well
for.
B
For
client-side
stuff,
not
that
it
can't
be
made
to
work,
but
it's
it's
not
a
great
name.
So
I
think
there
was
some
discussion
about
adding
in
just
like
appgot
name
and
that
ends
up
working
in
a
lot
of
situations,
but
not
in
all
situations.
Then
you
kind
of
end
up
with
this
scenario,
where
maybe
you're
interested
in
service
name,
if
it's
a
back-end
service
and
maybe
you're
just
an
app
name.
If
it's
a
client,
I
think
there
was
maybe
a
compromise
where.
B
Martin
was
proposing
a
telemetry
dot
source.
I
think
this
is
a
whole
namespace,
so
it
might
be
like
telemetrysource.name
or
something
and
maybe
a
few
other,
a
few
other
things
and
that
could
potentially
be
generic
enough
to
cover
like
service
name
or
app
name.
B
B
I
don't
know
in
general,
I
feel
like
this
is
maybe
headed
slightly
in
the
right
direction.
I
would
really
I
feel
like
we
can
come
up
with
a
a
generic
name
that
works
for
everything
which
I
think
would
be
preferable
to
having
like
multiple
different
names,
depending
on
whether
it's
a
back-end
service
or
client,
client,
side
application.
B
B
We
didn't
go
into
great
detail,
but
it
was
which
is
kind
of
mentioned,
to
take
a
look
at
this.
I
don't
know
amir
if
you
have
been
going
to
this
sig
or
have
any
anything
to
add.
A
It's
a
working
progress
like
there's
a
lot
of
discussions
and
I
believe
it
will
continue
for
a
month
or
two
until
we
stabilize
on
something.
So
it's
very
complex
landscape
and
there
could
be
so
many
scenarios
and
we
need
to
cover
all
of
them
if
someone
is
interested
feel
free
to
join
it's
on
a
thursday
an
hour
before
this
meeting
in
your
time
zone.
B
Cool
thanks
thanks
for
the
update
yeah,
I
guess
the
rest
of
us.
E
Is
the
has
the
semantic
conventions
touched
propagation
at
all,
or
is
that
out
of
the
scope.
F
Discussion
so
yeah,
I
didn't
get
the
last
sentence:
propagation
yeah,
sorry!
I
live
in.
E
A
faraday
cage,
probably
okay,
context
propagation,
I
guess,
would
be
the
thing
that
impacts
us,
because
I
think
what
we've
chosen
is
not
is,
I
think,
a
good
approach.
The
way
we
do
propagation
with
like
the
triplicate
options,
but
it
would
be
interesting
to
see
if
that
gets
formalized,
or
we
need
to
change
that
if
this
gets
stabilized.
A
A
The
possible
ways
to
approach
it,
but
we
haven't
converged
into
a
solution
yet,
but
I
think
no
matter
what
solution
will
be
chosen.
I
think
the
links
will
always
be
present.
This
is
the
current
talk.
So
even
if
there
is
parent-child
relationship,
there
will
still
be
a
link
from
the
process
to
the
create
spam.
E
A
B
B
B
B
With
tracing
there's
no
kind
of
implicit
attaching
of
baggage
to
anything,
it's
like
if
you,
if
you
use
the
apis
and
add
something
to
baggage
like
and
have
wired
up,
the
right
propagators,
it
will
get
propagated,
but
it's
all
kind
of
like
a
pretty
manual
process.
If
you're,
if
you're
interested
in
something
in
the
baggage,
you
have
to
go
ask
for
something
on
the
package
from
from
metrics.
B
I
think
either
way
I
could
see
wanting
to
just
standardize
this
for
tracing
as
well.
It
seems
to
be
like
an
additive
thing
that
wouldn't
break
things.
B
Yeah,
I
think
that's
all
that
I'll
say
about
the
metrics
part,
if
anybody's
more
interested
in
diving
deeper
into
any
of
these
things.
They
are
here
on
the
the
dock
but
yeah.
I
think
that's
a
special
update.
E
Sounds
good,
I
guess
no
there's
nothing
in
the
sig
for
trace
state
on
sampling.
I
know
that
feels
like
it's
is
that
at
a
has
that
been
merged
yet
or
are
they
still
there's
still
a
little
bit
of
oh?
I
mean
I
just
was
late
and
missed
it,
my
bad
just
my
bad
I'll
catch
up
basic.
B
It
wasn't
mentioned,
but
it's
still
open.
Let's
see
what
the
last
feedback
was
17
hours
ago.
Something
happened.
G
B
Yeah,
I
think
so,
especially
if
anybody
has
green
arrow
or
green
green
check
privileges
on
the
spec
sig.
That
would
really
help,
but
there's
one
green
check
and
two
grayish
checks.
Oh,
I
see
yeah.
E
B
But
yeah
worth
a
reason,
a
revisit
if
you're
interested
the
rest
of
us
will
continue
to
optimistically
say:
it'll
be
merged
anytime
soon.
F
B
D
There
wasn't
too
too
much
because
it
was
kind
of
like
hey
most
of
like
it
was
a
white
attendance
and
everyone's
like
yeah,
probably
gone
for
the
next
month.
So
I
was
just
trying
to
kind
of
plan
q1
and
figure
out
what
kind
of
work
they
want
to
commit
to
and
see
if
we
get
it
done
so
the
focus.
A
lot
of
these
meetings
has
been
around
the
semantic
conventions
for
http
stuff.
D
There's
a
pr.
That's
been
like
I've,
linked
it
a
bunch
of
times
in
the
past,
but
it's
basically
like
we
should
look
at
prototyping
it
they're.
Looking
for
people
to
help
prototype.
Some
of
these
things,
like
you
know,
remember,
andrag's,
instrumentation
api
that
he
had
put
up
a
while
back
again,
I
can
re-link
it
in
a
sec,
but
basically
looking
for
people
to
actually
just
try
to
like
implement
in
their
language
to
dejavify
that
proposal
a
bit.
D
So
it's
not
just
us
like
them,
pushing
java's
implementation
into
the
spec,
but
instead
getting
like
different
languages
to
try
to
implement,
to
identify
parts
that
are
a
little
too
java
centric.
Some
discussion
around
like
setting
up
test
harnesses
for
instrumentation
so
that
you
can
like
say
we
have
our
instrumentation
for
http
libraries.
D
This
is
all
just
like
talking
about
things
we
want
to
do
in
q1
and
trying
to
get
people
to
commit
to
it.
There's
some
discussion
around
like
hp
target
like
the
attribute
what
we
should
do
with
that
one,
because
it
can
contain
sensitive
information
right
and
we
just
kind
of
kicked
the
can
and
said
like
we'll,
just
include
it,
because
people
are
gonna,
want
it
and
we'll
have
to
deal
with
like
how.
How
should
we
manage
these
potentially
risky
attributes
that
can
contain
sensitive
information
right?
D
D
So
that's
that's
really
kind
of
what
was
discussed.
I
I
think
it'd
be
interesting
to
see
if
anybody's
like
wants
to
take
a
stab
at
it.
Another
xpr
I'll
link
that
in
a
sec,
if
anyone
wants
to
try
to
implement
it
in
ruby
and
see
what
it
looks
like
and
actually
find
out,
if
it's
really
awful.
B
D
That
that's
a
different
thing
altogether.
There's
still
resistance
on
that
on
multiple
fronts,
but
I
don't
know
I
don't
know
what
that
one
seems
to
be
kind
of
paused
at
the
moment.
Just
because
I
was
pretty
resistant
to
it
vocally
and
like
last
time
it
came
up.
I
it
was
asked
for
feedback.
And
again
I
just
said
I
was
like
the
the
sincere
answer.
Is
that,
like
I'm,
super
biased
against
that
approach?
Purely
because,
if
you
don't
want
some
form
of
instrumentation
in
your
application,
just
don't
include
it.
D
So
the
the
pr
you
have
open
there,
the
one
I
link-
that's
the
one
where
we're
looking
for
help
from
for
different
languages,
to
try
to
take
a
crack
at
implementing
that
and
see
what
it
looks
like
what
I
said
before
it
was
terrible.
I
didn't
actually
mean
like
the
work
is
terrible.
I
just
mean
the
java
isms
in
ruby
might
not
be
so
nice.
D
Even
the
http
spec
that
I'll
try
to
dig
up
isn't
a
similar
situation
where
we
want
to
see
if
these
things
are
possible
like
redirecting
or
linking
back
to
a
failed
like
a
retry
attempt
or
a
redirect,
like
some
of
the
http
libraries
that
I've
looked
at
in
ruby,
they
seem
like
this
shouldn't,
be
a
huge
ask,
but
some
of
them
look
like
they'd,
be
quite
difficult,
so
maybe
even
having
that
as
feedback
and
being
saying
like
this,
can't
be
a
firm
requirement
for
a
library
that
doesn't
support
it
right
like
if
it's
just
not
possible
to
do
that
doesn't
mean
you
shouldn't
have
instrumentation
for
it,
and
that's
this
one
here.
D
This
is
the
work
here
this.
The
second
part
where
a
lot
of
the
emphasis
has
been
from
these
meetings
is
just
around
really
solidifying
the
conventions
around
http
and
then
marking
it
as
stable.
So
people
can
start
knowing
what
to
expect
right.
D
I'd
say
like
pretty
much
since
I
started
attending
these
meetings.
Most
of
it
has
been
circling
around
these
two
pr's
in
some
way
or
another.
They
all
kind
of
relate
back
to
this,
and
it's
a
bit.
It's
a
bit
nebulous.
It's
really
hard
trying
to
even
establish
clear
like
what
are
we
gonna
be
delivering
here,
I'm
more
interested
in
things
like
configuration
like
that's
where
my
I'm
really
attending
these
meetings
is.
I
want
to
see
how
we
come
up
with
a
formal
way
of
like
how
do
we
configure
all
this
instrumentation?
D
How
do
we
keep
it
consistent
across
instrumentation
libraries
in
a
way
that
is
not
painful
for
everybody
involved,
but
we
really
haven't
even
scratched
that
surface,
yet
we're
just
trying
to
come
up
with
like
how
should
hgv
instrumentation
work?
What
attributes
are
required
which
are
optional?
How
do
we
behave
around
redirects
and
retries.
D
D
Not
the
spam
collapsing,
but
just
like
reading
through
the
spec
and
like,
for
example,
our
http
instrumentation.
None
of
it
will
apply
a
link
to
a
retry
there's,
no
there's
no
behavior
around
retries.
It
just
gets
captured
as
a
separate
span
right
so
seeing
if
you
can
actually
do
that
in
the
ruby
http
libraries
would
be
interesting
because
they
want
to
make
that
part
of
the
instrumentation
spec.
D
So
when
we're
looking
for
help,
we're
looking
for
help
to
see
if
like
what's
being
proposed
here,
is
even
possible
in
various
languages,
because
I
think
the
author
of
this
is
coming
from.net
and
I
think,
there's
a
lot
of
good
support
for
this
work.
So
they're
like
they
know,
what's
possible
in
their
chosen
language.
But
again
a
lot
of
this
is
they.
They
want
input
from
various
language
implementations
to
compare
notes
to
make
sure
that
it's
not
favoring
a
spec
isn't
favoring
one
language
over
the
other.
B
H
I
think,
oh
sorry
about
it.
I'd
also
on
the
topic
of
sensitive
fields.
My
preference-
and
it
might
be
naive,
would
be
to
have
a
pattern
for
like
configure
a
batch
span,
processor
to
filter
out
or
redact
sensitive
fields,
rather
than
add
more
knobs
to
instrumentation
for
configuration,
because
there's
such
a
thing
as
too
many
jobs.
D
The
debate
there
becomes,
then,
is
your
sdk
just
another
collector
and
there
are
forces
that
push
against
that
and
their
forces
that
support
it
like.
I
would
say
that
if
you
have
that
sensitive
information,
you
should
just
do
that
work
in
your
collector,
but
not
everyone
is
running
their
own
collector,
which
I
understand.
D
But
if
you
look
at
the
spec
and
the
span
data
that
is
passed
through
to
your
batch
stand,
processor,
your
attributes
are
actually
frozen,
so
you
would
have
to
duplica
duplicate
or
make
a
immutable
copy
like
a
shallow
copy.
We're
doing
that
internally
on
something
potentially,
which
is
kind
of
a
little
bit
yucky,
but
you
would
be
creating
a
shallow
coffee,
that's
mutable,
to
modify
it,
so
you
have
to
do
some
really
weird
stuff
in
the
span
processors
to
make
that
possible.
Let's
see.
H
D
H
E
I
D
E
Last
I
heard
they
did
want
to
do
that,
but
I
think
it's
there's
nothing
in,
but
I
think
it
was
just
like
someone
on
the
back
of
an
envelope
said
like
oh,
we'll,
probably
need
to
support
that,
but
I'm
not
sure
if
there's
an
implementation-
and
I
don't
think,
there's
a
specification
around
that
at
this
point
any
I
think
any
anything
schema
url
related
in
specification
is
that
all
of
that
happens
outside
in
a
collector
or
separate
process.
E
But
from
my
understanding,
the
when
attempting
to
actually
implement
schema
url
like
in
an
application,
some
sort
of
like
actual
application,
they
found
issues
with
it
and
the
resolution
seemed
to
be
do
the
upgrades
in
process.
But
I
don't
think
I've
seen
any
spec
related
to
that.
So
maybe
that
that
seems
like
yeah.
It
seems
like
there's
a
conflict
between
that
resolution
and
the
current
specification
around
what
a
processor
actually
is
supposed
to
do,
and
that's
probably
indicative
of
the
fact
that
people
want
more
flexibility
in
their
processors.
E
Given
that
our
internal
use
cases
require
it
as
well.
So
I
guess
we'll
see
next
year,
not
before
christmas,
because
everyone's
busy
at
the
end.
B
Yeah,
I
feel
like
we
are
kind
of
at
a
pivot
point
here,
and
I
will
definitely
say
that
I
am
in
rob's
camp,
where
I
really
think
that
we
need
to
fix
our
processor
or
spam
processor
pipeline,
like
you,
should
actually
be
able
to
process
fans
in
it,
or
we
should
introduce
like
a
new
thing
that
allows
for
that
and,
if
yeah,
but
ultimately,
I
think
these
things
are
just
gonna
end
up
becoming
like
a
rat's
nest
of
configuration
knobs,
that
nobody
knows
how.
B
If
you
there's
just
like
a
lot
of
room
for
clash
and
problems,
and
I
feel
like
as
as
much
as
people
should
probably
just
be
using
a
collector
and
we
shouldn't
necessarily
have
to
like
re-implement
all
the
collector
processors
and
ruby
I
do
like
that
symmetry
and,
if,
like
you,
aren't
going
to
use
a
a
collector
but
need
similar
functionality,
I
guess
that's
the
next
best
thing
I
just
feel
like
this
cascading
nightmare
of
knobs
is
going
to
be
like.
B
H
E
H
I
do
have
a
question:
it's
maybe
not
burning,
but
it's
a
you
know:
smol
bring
yeah,
let's,
let's.
H
Bouldering
questions
I
threw
it
on
the
agenda.
It's
we've
had
had
some
customers
and
and
troubleshooting
it
ourselves,
getting
more
information
out
of
the
exporter
when
it
fails
to
export
the
behavior.
That
we've
seen
is
that
short
of
monitoring
short
of
looking
at
the
one
metric
that
the
otlp
exporter
emits
when
net
http
bad
request,
client
error
or
server
error
that
it
will
emit
a
metric
about
that.
But
all
the
other
error
cases
in
this
in
this
handler.
H
H
D
Because
because
the
idea
is
you
use
use
both
together
right,
like
you,
have
the
batch
span,
processor
metrics
and
then
you
have
the
otlp
exporter
metrics.
So
if
you
see
a
spike
and
like
fail
to
export
in
your
batch
band
processor,
you
look
at
your
otl,
p
exporters
and
you'll
see
potential
like
you
should
see
a
corresponding
error
spike
right
because,
like
if
you
look
at
lines
say
202
there
there's
a
timeout,
you
would
see
a
spike
in
timeouts
right
and
then
it
would
fail
to
export,
say
50
spans.
H
E
I
think
it's
reasonable
in
a
scenario
like
grab
spacing
where
some
user
comes
in
our
left
field.
It's
like
hey.
We
have
a
one
week
trial.
This
isn't
working
fix
this
now,
it's
unreasonable
to
say
you
have
to
set
up
a
metric
system
to
fix.
Your
tracing
issue
feels
like
a
gross
response,
even
though
that's
like
the
right
response,
so.
E
To
figure
out
the
health
of
yeah,
but
you
guys
and
having
been
on
your
side
to
advocate
for
you,
you
get
sort
of
like
a
certain
number
of
bullets
of
interactions
where
it's
like
we'll
try.
This
try
this
and
then
by
the
third.
Try
this
they're,
like
you,
know
what
like.
Actually,
I'm,
not
like:
good
luck
with
your
life,
so
in
so
many
words
so
yeah,
maybe
we
can
general,
like.
E
I
think
it's
fine,
I'm
comfortable
with
debug
logs
like
no
one's
ever
as
well.
Maybe
we
could
just
generalize
this
into
like
a
general
thing
where
it
defaults
to
our
you
know
like,
like,
I
feel,
like
the
information
we're
already
sort
of
passing
in.
We
just
choose
to
admit
it
as
metrics
and
tags
but
like
that
could
just
be
an
interface
and
you
could
a
class
or
something
and
you
could
supply
a
logger
to
it.
I'm
try,
I
don't
know,
but
I
think
it's
reasonable
and.
H
H
H
E
H
H
The
journey
of
these
people,
because
we
get
a
lot
of
people
just
onboarding,
to
open
telemetry
and
on
their
journey
of
learning.
How
to
do
this?
We're
like
all
right,
you're,
familiar
with
logs
turn
on
logs
and
you'll,
see
what
the
errors
are
and
then,
when
the
question
comes
up,
what
do
I
do
with
these
logs?
You
don't
do
anything
you
look
at
them.
E
So
yeah,
I
think
like
right
now
you
could,
like
I
think,
rob's
implying
or
linking
to
like
you
could
just
add
your
own
class.
You
could
extend
metrics
reporter
to
kind
of
do
whatever
you
want,
like
it's
technically
doesn't
have
to
report
metrics.
Maybe
it's
poorly
named,
but,
like
you
could
just
wrap,
you
know
you
could
provide
a
subclass
of
this
and
say,
like
you
know,
blog
just
entered
out
probably
should
be
a
way
to
do
that
easier
and
so
that
you're
not
providing
them
a
bunch
of
custom
code.
E
They
have
to
add,
and
it's.
H
H
D
The
reason
I'm
pointing
at
the
metrics
reporters
like
eric
picked
up
on
is
that
you
could
just
have
it
log
to
centered
out,
and
then
you
like,
we
can
just
keep
using
it
as
is,
and
we
don't
have
to
figure
out
where
the
right
place
to
put
a
log
is
everywhere
right,
verbosity,
it's
like
you,
we're
emitting
all
that
data,
no
matter
what
you
just
have
to
like,
give
us
a
place
to
send
it
out.
So
it's
like
there
could
be
a
generic
like
blog
metrics,
reporter
right,
like
statsd.
D
Has
that
and
the
ruby
implementation
is
you
have
the
log
sync
and
it
just
like
spits
out
all
your
metrics
to
logs,
and
you
could
see
it
so
like
you
could
just
recreate
that
and
like
now.
That
being
said,
it's
like.
Maybe
the
right
answer
is
to
just
like
litter,
the
code
with
like
logs
everywhere
at
debug
level.
But
do
we
want
to
do
that.
H
Well,
it's
it's
conceivable
that
like
eric's
idea
was
a
metrics
reporter
when
you
increment
a
counter,
if
debug
levels
high,
I'm
also
going
to
crank
it
out
to
a
logging
statement
like.
I
I
It
would
it
would,
it
would
make
sense
right,
but
because,
for
example,
in
my
case
like
buffer
full
is
interesting
or
but
if
I've
got
something
that
says,
export
failure,
but
no
details
about
that
export
failure,
because
that's
all
that's
in
the
label
available
for
me
to
see,
and
then
I
have
to
correlate
that
somehow
to
a
different
metric.
I
I
I
want
to
see
some
correlation
at
like
a
thread
level
id
and
be
like
hey.
This
particular
thing
is
failing
because
of
end
of
fouler
and
these
two.
It.
I
H
D
Which
is
kind
of
what
we
did?
We
instrumented
our
export
pipeline.
We
were
tracing
our
export
pipeline,
so
we
could
actually
debug
export
failures.
Eventually,
right,
like
you,
would
get
all
the
failed
attempts.
You
get
all
the
information
captured
because
you're
actually
tracing
that
whole
that
whole
flow.
But
I
guess
if
you
can't
emit
any
traces
and
that's
what
you're
trying
to
debug
then
you're
kind
of
as
well
right,
yeah.
H
E
I
think
I
think
it's
fair
to
say,
like
we
don't
want
to
just
introduce
a
bunch
of
like
it's
a
bad
pattern,
just
like
well,
let's
add
debug
logs
everywhere,
because
it
just
is
a
gnarly
thing.
It's
also
probably
unreasonable
to
say,
like
people
need
to
write
entire,
like
classes
of
software,
just
to
get
a
little
more
information,
but
I
just
don't
know
what
the
right
like
happy
path,
what
the
right
middle
ground
is
and
like.
E
How
can
we
provide
a
little
more
information,
still
be
like
kind
of
broad
and
extensible
and
like
yeah,
I
don't
know,
I'm
totally
not
opposed
to
just
like
in
because
this
one
is
a
particularly
not
like
a
choke
point
of
like
well.
If
this
is
going
wrong,
like
we
probably
want
to
be
a
little
extra
noisy,
I
don't
know.
E
B
Yeah,
I
think
hacking
a
metrics
reporter
that
actually
outputs
logs
is
not
a
terrible
idea,
but
if
that
works
out
well,
it
might
not
be.
It
might
be
a
slightly
better
idea
to
just
kind
of
make
a
more
generic
interface
for
for
these
things
and
you
can
register
like
a
you
know,
an
export,
debug
log
handler
or
a
export.
You
know
metrics
handler
and.
H
E
Let
me
ask
you
this:
do
you
ship
a
distro
of
this
library,
or
is
it
like
if
you
guys
had
a
district?
This
would
be
you
know
you
could
just
provide
your
own
interface
and
be
easy.
It's
harder
when
folks
are
you're
having
to
provide
them.
Custom
code
is
like
I
can
empathize
with
that
being
like
a
pretty
unsatisfactory
way
of.
We
don't.
H
I
I
I
What's
what
for
stats
instrument
and
one
for
a
data
dog
metrics
that
we
use
internally
and
then
we
can
add
a
logging
one
and
then
folks
can
and
then
we'll
write
a
guide
to
say:
here's
all
the
metrics
that
get
omitted
if
you
want
to
use
metrics
what
their
data
types
are
and
their
backend
systems
and
that
because
I've
got
all
this
stuff
internally,
I.
I
A
H
E
I
want
to
make
sure
you
nev,
in
a
mirror,
have
time
as
well
they've
been
sitting
very
patiently
to
discuss
getting
their
their
crap
approved,
not
crap
their
great
work.
My.
B
G
G
E
Yeah,
okay,
I
was
the
one
who
reviewed
them
a
big
chunk
of
this
I've
kind
of
softened.
My
approach,
I
also
opened
an
issue,
basically
there's
just
no
extraction
right
now,
but
I
think
it's
unclear
what
extraction
looks
like
in
sqs
and
I
specifically
don't
have
the
production
context
to
you
know:
inform
that
decision
and
there's
messaging
conventions
as
well.
I
actually
opened.
E
If
you
go
to
discussions,
I
made
a
discussion
with
lots
of
cute
little
drawings
this
morning,
because
I
wanted
to
make
sure
and
even
amir
like
felt
like.
We
were
communicating
on
this
and
there's
basically
a
lot
of
ways.
You
could
do
extraction
and
I
know
matt
like
last
week
we
tried
to
talk
about
it
and
I
realized,
like
my
mental
models,
were
like
all
over
the
place,
and
I
wasn't
just
doing
this
on.
Camera-
isn't
actually
a
good
way
to
explain
things.
E
So
I
think,
like
it's
fair,
to
say
that
there's
a
lot
of
ways
you
can
do
parent-child
relationships
or
links
or
none
or
some
combination
of,
and
it
depends
on
the
system
itself
and
the
users
like
under
you
know,
and
it
doesn't
need
fit.
Super
neatly
with
how
we
do
this
like
triplicate
option,
because
sometimes
it's
a
blend,
so
my
original
thing
was
like.
I
don't
think
we
should
merge
this
without
extraction.
E
It
doesn't
have
to
necessarily
like
be
used,
but
at
least
have
it
available
for
folks
and
if
no
like,
we
shouldn't
let
perfect
get
in
the
way
of
good
and
the
you
know,
the
injection
is
works
perfectly,
and
the
extra
metadata
and
attributes
are
very
useful.
E
So
I'm
comfortable
with
like
merging
this,
as
is
given,
if
as
long
as
we
would
add,
like
maybe
just
an
api
for
extraction
that
isn't
used.
If
that's
fair,
I
I
don't
have
that
being
said.
Like
I'm
open,
I'm
not
I'm
not
a
maintainer
of
this
repo,
so
I
don't
and
I
don't
and
I'm
open
to
other
opinions,
but
that's
kind
of
my
so
that
was
the
only
thing
outstanding.
I
think
everything
else
in
this
pr
was
pretty
good.
Maybe
there's
been
some
small.
E
You
know
details
I
missed,
but
yeah
it's
it's
all
it's
really
doing
or
not
all,
but
what
it
adds
is
it
allows
you
to
view.
Sqs
and
sns
spans
is
produce
correctly
correctly,
labels
them
as
producers
and
consumers,
which
is,
I
think,
appropriate
and
then
grabs
better
metadata
about
them
and
then
also
gets
the
span
names
to
be
more
appropriate
to
the
topics
or
the
arn's.
There
was
one
small
knit
I
had.
I
don't
think
phone
numbers
should
be
in
a
span
name.
The
cardinality
is
far
too
high.
E
Besides
that,
I
think
this
is
fine
and
the
extract-
and
at
least
writing
a
wrapper
for
like
how
you
would
extract
message.
Attributes
from
sqs
is
that's
where
I
stand
on
it
and
it
looks
like
you.
I
haven't
reviewed
the
changes
you've
pushed
up.
Okay
does.
I
Everyone
else
have
thoughts,
so
the
question
is:
how
does
if
we
were
to
inject
without
extracting
what
value
does
that
provide?
I
A
I
A
I
Okay,
so
I
think
what
eric
you
originally
said,
that
we
should
probably
include
the
extraction
anyway
at
a
minimum,
so
that
it's
on
like,
if,
because
that
way,
it's
a
metric
with
the
other
ones
and
that
we
should
add
the
context
propagation
flag
as
well,
so
that
it's
symmetric
with
the
other
ones
or
setting
which
is
like
in
you
know.
A
I
Client
or
whatever,
and
then
the
last
thing
that
I
would
add,
is
I
don't
know
how
people
the
maintainers
and
robert?
I
I
don't
know
how
you
feel
about
this,
but
would
it
be
okay
to
minimize
the
number
of
headers
that
they
send
over
and
so
for,
like
this
specific
instrumentation
to
only
support
something
like
x-ray
or
the
w3
context,
as
opposed
to
like,
if
somebody
was
using
multiple
propagators,
like
you
know,
jager
or
zipkin,
right
like
where
the
b,
the
b3
versus
ot
trace,
because
I
think
like
where
it
gets
funky
is,
if
we're
using
the
like
the
composite
map,
propagators,
there's
going
to
be
header
explosion.
I
If
people
are
using
baggage,
for
example,
because
the
way
that
that's
the
way
that
the
the
text
map
processor
maps,
those
out
is
one
attribute,
equals
one
entry
in
the
text
map
that
was
my
own,
like
that.
That
was
my
bigger
concern
was
that
we
would
overflow,
like
the
message
headers,
and
I
know
that
janevan
amir
have
like
mitigated
that.
But
I'm
wondering,
if
like
we
can
get
away
with
like
omitting
and
only
keeping
the
essentials,
which
are
the
x-ray
and
the
trace
context
for
w3.
D
D
E
I
know
so
just
to
clarify
that
what
what
you
described
was
like
originally
what
I
felt
should
happen.
I
think
the
hurdle
for
doing
extraction
properly,
with
all
the
configuration
options
is
very
high
and
there's
no
clear
right
answer
and
you
know
it's,
you
know
I
don't
even
think
the
way
node.
Does
it
no
offense.
I
know
you
guys
wrote
it
is
correct,
like
I
don't
think,
that's
something
necessary.
I
think
it's
fine.
E
It
works
for
in
practice,
but
like
for
the
open
climate
specification,
I
don't
think
it's
correct
so,
like
I'm
kind
of
in
favor
of
one
like,
we
definitely
need
to
have
it.
I
think
have
it
off
by
default
or
like
have
a
configuration
for
injecting
being
off
and
on
as
someone
else
commented
like.
That's
a
must.
Okay,
no
worries,
but
oh
right,
I
needed
to
comfortable.
Oh
that's
right.
I've
been
asking
him
to
review
your
pr
if
it
makes
you
feel
better,
but
the
extra
I'm
comfortable
kicking
the
can.
E
E
But
I
don't
think
we
need
to
provide
extraction
in
the
implementation
right
now
and
if
people
come
in
and
say
we're
like
in
practice,
this
is
going
to
be
used
in
a
lambda
like
no
one
is
no
one.
Is
writing
ruby,
lambdas,
they're,
writing,
lambdas
and
node
they're
doing
the
extraction
or
wherever
like?
If
and
so
if
people
come
back
and
say
like
we
need
to
do
extraction
and
ruby
like
we
cannot
handle
that.
I
think
for
now,
like
it's
probably
fine
to
just.
E
Do
the
injection
make
sure
there's
a
flag
to
turn
it
off,
write
the
api
to
extract
it,
but
don't
actually
provide
extraction
in
the
code
and
if
then
people
come
back
and
say
we
want
to
do
extraction,
we
can
bug
you
guys
to
to
support
it,
and
hopefully,
by
that
time
there
will
be
more
like
I've
asked
anthony,
mirabella
and
anarag
from
aws
to
tell
us
like
how
would
you
guys
like
to
see
extraction
done
for
sqs
and
they
said
like?
Oh,
we
have
no
idea
so,
like
hope.
E
Maybe
by
that
time
they'll
have
more
input
or
the
messaging
semantic
conventions
will
be
firmer
and
we,
but
right
now
like
wow,
it's
experimental,
I'm
comfortable,
like
leaning
on
that
experimental
nature
and
yeah.
I
don't
want
to.
I
don't
I
want
to
make
sure
you
guys
are
enabled.
So
that
being
said,
like
I'm,
not
matt,
robert
or.
A
E
So
unfortunately
my
opinion
is,
you
know
whatever,
but
I
can
comment
on
the
pr
to
that
effect
and
as
long
as
you
guys,
maybe
just
add
the
api
for
extracting
I'll
approve
it.
You
know
and
we'll
see
where.
E
E
Cool,
thank
you
yeah,
just
ping
me.
Thank
you.
E
I
E
Worries
yeah,
I
mean
not
everyone's
celebrate
christmas,
myself
included,
but
I'm
gonna
use
this
time
to
not
to
relax
yeah.
I
was
gonna
say
it's
really.
We
have
some
a
ton
of
stuff
going
on
internally
for
context,
so
yeah.
E
Same
here,
yeah,
I'm
sure,
okay,
anyone
else
have
anything
they
want
to
discuss.
I
know
we've
ran
over
and
it's
been
a
lot
of
me
talking
so
and
rob's
being
very
polite
by
hanging
out
10
minutes
best.
Okay,.
C
Don't
want
to
drag
it
further,
but
I
linked
the
active
record,
grail,
7
stuff.
Dolly
is
still
failing,
my
ci,
but
I
think
otherwise
it's
ready
for
reviews.
I
think
rob
had
some
concerns
whether
we
should
support
grail,
seven
alpha
yeah.
E
Yeah,
I
I
fixed
the
dolly
thing
temporarily
in
a
separate
pr
arielle.
Thank
you
for
reviewing
that
long
term.
I
think
we're
going
to
refactor
that
so
that
doesn't
break
every
two
seconds.
I
think
your
approach
is
fine
tim.
I
know.
There's
feedback,
I
think
at
the
I
think
the
very
reasonable
middle
ground
is
don't
is
keep
the
pr
open
or
whatever,
and
so
people
know
what's
going
on,
but
wait
until
rail
seven
goes
rc
before
we
merge
it.
Okay,
when.
E
C
E
Be
careful
here
to
separate
like
what
makes
sense
for
us
as
employees
of
companies
from
like
what
makes
sense
from
the
sdk
of
an
open
source
library
to
do
and
it's
hard
because
our
experience
is
drawing
upon
things
that
are
maybe
different.
But
anyway
the
context
is
rail.
Seven
has
breaking
changes
on
active
record,
and
so
we've
made
we've
max
versioned
any
rails.
E
7
any
active
record
support
to
be
rail
6,
which
what
will
happen
is
people
will
start
to
use
the
rc
and
be
annoyed
that
their
active
record
instrumentation
disappeared,
but
that's
better
than
it
breaking,
but
right
now
like
because
it
could
still
break.
Do
we
really
want
to
merge
a
fix
and
then
have
it
break
again
and
then
merge
another
fix,
or
do
we
just
want
to
wait
until
we
have
a
stable
thing,
I'm
comfortable,
not
waiting,
but
anyway,
okay,
we
got
to
get
that
instrumentation.