►
From YouTube: 2021-07-14 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
C
D
E
C
I
know
that's
what
I
was
just
saying.
I
can't
remember
the
last
time
I
came
to
a
spec
meeting
yeah
if
they
weren't
at
8
00
a.m.
Maybe
well,
these
ones
are
not.
I
know
I
don't
yeah
and
and
they're
and
they're
at
a
on
a
topic
near
and
dear
to
my
heart,
so
yeah.
D
Yeah
but
I'm
glad
you're
joining,
let's
see
we'll
look.
F
F
D
D
Anyone
have
any
specific
agenda
items
they'd
like
to
add.
D
D
D
Yeah
people
should
have
a
look
at
if
they
haven't
already
so
I
will
post
that
any
updates
on
this
front
on
our
hog.
This
is
something
you've
been
working
on.
F
D
Yeah-
and
I
think
everyone
on
here
might
be
familiar
with
this,
except
maybe
trask,
but
are
you
familiar
with
this
instrumentation
instrument
or
object
that
honorag
has
been
working
on.
D
D
I
know
that
anthony
the
go
maintainer
was
interested.
It
looks
like
I
have
some
cycles
coming
up,
so
I
could
definitely
help
with
the
go
go
implementation
of
this
which
I'd
like
to
do
to
get
my
hands
dirty.
So
so
I
can
help
help
work
on
that.
My
concern
a
little
bit
for
less
dynamic
languages,
is
that
you
have
an
issue
around
just
kind
of
needing
to
make
an
adapter
to
every
specific
kind
of
object.
D
If
you
want
to
make
this
thing
type
safe
through
the
manner
of
like
you,
give
me
an
object
and
I'll
I'll
pull
off
all
the
relevant
attributes
that
I'm
looking
for.
D
That's
it
seemed
like
that
was
kind
of
the
approach.
It's
like
just
give
me
an
http
request
and
response
object
and
I'll
just
just
grab
what
I
need
off
of
it,
but
you
end
up
needing
to
make
some
kind
of
like
adapter
object
in
the
process,
and
so
I
kind
of
want
to
play
around
with
with
that
versus
like.
D
But
if
you
just
like
say
like
give
me
a
struct,
that's
been
filled
out
with
this
stuff
as
like,
and
then
like
helper
functions
might
be
a
way
to
do
it.
Another
language,
but
anyways,
not
a
big
deal.
F
D
How
to
deal
with
attributes
metrics
right,
where
that's
yeah,
that
it
seemed
to
that
sort
of.
I
think
we
were
talking
about
this
earlier
around
if
you're
trying
to
do
this
stuff.
Are
we
trying
to
make
this
combined
object
live
entirely
in
user
land
right
like
outside
of
the
sdk?
In
other
words,
it
doesn't
have
access
or
know
about
stuff
like
a
span.
Data
object,
I
think,
is
that
what
you're
you're
talking
about
like
you,
don't
have
access
to
that
spam
data
object
and
things
like
that.
It's.
E
Actually
could
I
say
this
morning
in
the
spec
meeting
we
we
talked
about
josh
s
mentioned
the
question
of
whether
a
resource
qualifies
as
a
metric
attribute
when
exporting
to
a
system
with
limited
capacity
for
for
cardinality.
Basically,
it
feels.
C
E
The
same
question
that
that
we're
asking
here
for
the
for
you
know
all
the
metrics
semantic
conventions
around
around
http.
Do
you
include
like
15
attributes,
or
do
you
include
seven
or
do
you
include
two?
This
is
this
connects
with
the
hinge
api
question
in
the
metrics
sig
as
well,
and
I
think
ted
you
you've
been
present
for
this
discussion
about
multivariate
metrics.
E
There's,
there's
some
sort
of
question
about
whether
how
you
couldn't
efficiently
encode
these
events
that
are
like
from
an
instrumentation
like
code
path,
because
they
do
generate
a
lot
of
attributes
that
turns
into
maybe
one
span,
but
also
a
bunch
of
metric
events
potentially,
and
this
is
where
you
might
want
to
filter
those
and
as
josh
s
mentioned
this
morning,
there's
been
a
proposal
which
I
was
involved
with
to
use
the
schema
to
encode
this
information
about
resource.
D
Yeah
yeah,
I
think
I
think,
to
some
degree
we
have
to
get
our
hands
dirty
and
start
implementing
these
things,
but
it
does
seem
like
we
need
a
set
of
defaults,
which
is
what
josh
is
talking
about
this
morning.
Right
like
he
was
calling
them
descriptive
versus
identifying
attribute,
but
what
it
comes
down
to
is
like
what
are
the
the?
D
What
is
the
default
set
of
attributes
if
you're
going
to
produce
like
metrics
on
it,
for
an
http
client,
for
example,
like
what
are
the
metrics
you
want
to
produce
and
what
are
their
label
sets?
So
we
need
defaults
there
and
then
both
for
metrics
and
for
tracing.
D
There
needs
to
be
some
kind
of
configuration
language
like
some
way
for
the
end
user
to
to
be
able
to
modify
all
of
this
crap,
and
I
feel
like
this
instrument
or
object,
is
going
to
be
the
thing
that
has
to
to
deal
with
with
a
lot
of
that
stuff
on
the
metrics
side,
it's
sort
of
like
no,
no,
no,
I
want
a
different
label
set
and
you
you
make
these
metrics
for
me,
or
I
want
different
metrics
on
the
tracing
side.
D
You
know
there's
a
whole
pile
of
things
like
what
status
codes
count
as
a
an
error,
and
you
know
just
like
all
the
usual
things
people
want,
and
so
it
would
be
great
to
be
able
to
bake
definite
all
of
that
stuff
into
the
semantic
conventions
as
well.
Just
like
these,
these
are
all
the
stock
configuration
options.
We
want
to
give
people
for
each
one
of
these
conventions,
and
this
is
the
set
of
attributes
that
should
count
as
like
the
default
labels
when
you're
making
metrics
off
of
these
spans.
A
So
may
I
confirm
my
understanding
so
do
we
think
this
is
something
that
people
will
be
able
to
express
in
the
api
or
it
has
nothing
to
do
with
the
api.
So
basically
the
api.
You
just
admit
what
data
you
have.
You
don't
give
any
hint
about
your
suggestion,
because
if
we
give
that
hinting
capability
to
the
to
the
library
owner
different
library
owners,
they
might
have
different
ideas,
how
they
want
to
handle
that
and
they
will
give
different
guidance.
So
instead
we
don't
give
them
that
flexibility.
A
D
Yeah
yeah,
something
if
we
don't
provide
defaults
and
we
don't
provide
like
a
configuration
language
or
a
set
of
configuration
options.
What
will
happen
is
people
and
I'm
sure
this
is
probably
already
happening
with
instrumentation,
as
people
start
coming
in
and
being
like.
I
want
to
configure
this
thing
over
here.
Could
you
give
me
an
option
to
do
that
this
or
that
yeah
yeah,
and
I.
D
A
Already
see
a
lot
of
knobs
in
the
instrumentation
people
know
it's
preview,
so
they
start
asking
hey.
Can
you
do
me
a
favor
and
just
I
don't
know
and
yeah
and
the
moment
you
start
have
knobs,
then
what's
the
default
behavior
like
the
people,
have
different
understanding.
So
I'm
like
I
won't
be
surprised
if,
like
their
ht
library
in
charge
and
java
and
their
default,
behavior
is
different
or
even
different.
Hdb
clients
in
donetsk
will
have
different
defaults
and
that
seems
to
be
a
bad
provision.
D
D
So
it
seems
like
if
we
could
standardize
the
degree
possible
for,
like
the
basic
stuff,
be
like
if
you're
an
http
client
instrumentation,
provide
these
options,
provide
it
this
way,
please
that
could
simplify
things
and,
in
the
long
run,
could
potentially
lead
to
us
being
able
to
like
create
some
kind
of
like
configuration
file
approach
to
to
doing
this
stuff,
which,
which
would
probably
or
other
things
that
would
make
it
nice
to
operators
basically
to
be
able
to
modify
this
stuff
the
more
standard
it
is
probably
just
the
easier.
It
is.
D
Yeah,
I'm
curious
to
ask
how
much
because
you
know
you
guys
maintain
a
big
pile
of
instrumentation
and
stuff
in
the
agent
like
how
how
much
is
like
configuration
coming
up
there,
configuration
and
defaults
like.
C
Would
help
if
I
wasn't
muted,
not
a
whole
lot
yet
the
a
couple
of
knobs
that
we
have
one
is
the
pure
service
mapping
to
populate
that
based
on
you
know,
hostname
slash
ip
address,
and
I
know
one
that
splunk
wants
to
add
which
motivated
the
the
allowing
nested
client
spans
is
they
want.
Currently
today,
we
by
default,
suppress
nested
client
spans,
and
so
they
want
that
knob
ludmila
and
I
have
a
are
thinking
through
some
stuff
around
that
also
for
the
azure
sdk
use
cases.
C
F
F
F
D
D
F
C
Yeah
yeah
I'd
say
for
the
agent
so
far,
people
are
still
in
that
mode
of
hey.
Look
at
all
this
data
that
the
agent
gives
me
for
free
right
that
they
haven't
quite
gotten
to
that
next
layer,
which
will
definitely
happen
of
hey
by
the
way
like
now.
I've
absorbed
all
this
data,
yeah
they'll
start
asking,
I
know
upstream
in
or
side
stream
or
whatever
we
call
the
datadog
repo.
C
They
have
customization
for
the
status
code.
What
counts
as
an
error.
D
Yeah
suppression,
that's
a
thing
that
was
pretty
common
in
the
past
people
wanting
to
suppress
things
like
like
health
check
like
certain
like
url
patterns,
that
represent
like
noise
in
their
system
and
they
wanna.
That
was
like
a
common
thing
in
the
past
for
outgoing
requests
or
incoming
requests,
or
both,
I
think,
in
those
cases
it
was,
it
was
maybe
both
like
health
checks
were
like
a
common
reason
for
people
wanting
to
just
like
suppress
this
health
check
thing
that
was
just.
C
That's
probably
our
number
one
upvoted
issue
in
the
in
the
java
repo
right
now.
D
C
Somewhere,
I
was
curious
about
the
sir
incoming
versus
outgoing,
because
primarily
I've
seen
the
request.
The
health
check
request
around
incoming
and
for
that
our
our
thought
is
sam
sampler
versus
configuration
of
the
instrumentation.
C
In
that
case,
could
we
pass
the
http
url
in
the
attributes
when
we
create
the
span,
so
the
sampler
has
access
to
that?
Oh.
D
C
B
D
D
Wheel
but
yeah,
that's
that
stuff
is
cool.
I
think
something
that
came
up
earlier
today-
and
I
know
has
come
up
in
the
past-
is
around
like
nested
client
spans.
I
think
that's
another
place
where
we're
looking
for
more
guidance
in
the
conventions
right
now.
The
conventions
just
say:
here's
the
attributes,
you
should
record,
but
they
should
maybe
start
saying.
Like
here's
the
configuration
options
you
should
give
and
also
here's
the
structure
you
should
be
creating
for
managing
things
like
you
know,
logical,
http,
requests
versus
physical
http
requests.
D
C
Yeah
yeah
ludmilla-
and
I
just
were
chatting
for
a
good
while
this
afternoon
about
that
and
I'm
gonna
bring
up
a
proposal
in
the
javasig
this
week
to
kind
of
discuss.
So
what
we've
done
kind
of
just
at
a
high
level
like
what
we've
done
in
java
instrumentation
so
far
is
when
we
create
a
client
span.
C
We
have
two
extra
context,
keys
that
we
populate
so
there's
right.
The
current
span
context
key.
We
also
have
a
server
span
context
key
and
a
client
span
context
key
and
the
the
server
span
context
key
is
helpful
for
us
for
in
routing
frameworks.
When
we
want
to
call
update
span
on
the
server
span,
we
can
get
that
directly
versus
parent
span
might
be
an
internal
span
in
between.
D
C
Is
the
more
interesting
for
this
discussion
is
suppressing,
so
it
kind
of
started
with
the
well.
There
was
a
spec.
The
spec
initially
seemed
to
say
that
you
shouldn't
nest
client
spans,
but
we
weren't
suppressing
them
initially,
and
then
onorak
brought
this
up
last
like
a
year
ago
for
the
aws
sdk,
which
has
uses
http
client
underneath,
but
they
wanted
that
aws
the
span
from
the
aws
sdk
to
be
the
client
span.
C
That
is
what
tracks
the
propagation
and
the
target
sort
of
primarily
around.
I
think
drawing
that
sort
of
app
distributed
application
map
diagram
and
we
actually
have
kind
of
a
very
similar
issue
with
the
drawing
the
application
map
and
when
there's
nested
client
spans
that
becomes
problematic
for
our
back
end.
C
How
to
well
it
sort
of
relies
on
there
being
a
one
client
span
to
one
server
span
and
also,
but
at
the
same
time
the
higher
level
client
span
tends
to
have
better
more
rich
data.
That
makes
more
sense
to
the
user,
a
better
name
of
the
destination.
C
So,
but
in
sort
of
where
some
complications
then
like
you
could
have
a
database
client
span
that
then
calls
http
yeah.
C
We
have
at
least
one
example
in
our
instrumentation
that
does
that
we
have
a
lot
of
http
that
reuse
other
http
clients,
so
we
have
in
the
java
instrumentation.
So
we
have.
D
C
Like
yeah,
it
tends
to
be
like.
Sometimes
they
offer
multiple
underlying
transports
like
you
can
use,
okay,
http
or
neti
or
apache
as
the
plug-in
or
even
http,
url
connection.
The
old
school
java
right.
D
Yeah,
I
was
just
wondering
in
in
those
cases,
though,
is
it
that
is
it
the
solution
that
the
that
higher
level
library
should
just
presume
that
the
lower
level
library
is
going
to
provide
the
lower
level
instrumentation
and
the
injection
and
all
of
that,
and
then
you
just
need
to
make
sure
that
instrumentation
is
installed
as
well.
I'm
just
curious
if
that
would
solve
the
problem
or
if
there's
you
know,
reasons
why
that
wouldn't
work.
C
So
the
biggest
problem-
I
would
say
right
now-
is
that
we're
we
want
to
drop
the
nettie.
We
probably
we
want
to
disable
a
neti
instrumentation
by
default,
because
it's
too
low
it's
too
low
level.
So
there's
literally
no
way
we
can,
when
once
you
start
to
go
if
somebody's
you're
doing
http
2
pipelining
over
a
nitty
connection,
there's
no
way
for
us
to
track
the
request
and
res,
of
course,
the
corresponding
response
for
a
given
request,
because
you're
basically
streaming
multiple
requests
over
the
channel
and
receiving
multiple
responses.
C
No
correlation
there
at
the
low
level
neti
layer
right,
a
higher
level,
http
layer
there
is,
I
see
so
that's
one
problem,
there's
definitely
like
with
http
url
connection
like
if
somebody's
using
like
say
spring
rest
template
is
a
popular
http
client
and
the
default
is
to
use
the
horrible
http
url
connection
from
java
1.0
and
our
response,
our
tracking
of
our
duration
tracking,
is
poor
at
the
http
url
connection
layer,
because
there's
no
concept
of
a
response.
It's
just
bytes.
C
It's
like
you,
get
an
input
stream
and
you're
reading
bytes
and
we
don't
track.
We
don't
then
track
that.
So
at
the
higher
level
we
have,
we
actually
have
better
duration,
metrics.
D
C
Nettie
I
mean
we
we
want
to.
I
think
our
plan
is
to
to
disable
it
by
default.
E
C
The
problem
is,
there's
a
lot
of
the
a
lot
of
people
will
lose
observability
because
they're
using
something
that
is
using
neti
that
we
aren't
instrumenting.
D
C
And
so
we'll
probably
keep
it
around,
but
you
know
people
can
turn
it
on,
but
we'll
just
have
the
disclaimer
that
you
know
it
only.
It
doesn't
work
for
http
2
or
any
kind
of
pipelining
right
for
http
url
connection.
C
D
Yeah,
I
I
guess,
I'm
I'm
curious
whether
I
think
you
know
I
was
following
some
of
that
discussion,
and
it
was
also,
you
know,
is
this
stuff
that
can
be
configured
at
load
time
versus
having
like
instrumentation
being
able
to
like
have
a
way
of
like
suppressing
the
stuff
underneath
it,
because
the
second
one
sounded
like
more
surface
area
and
like
like
I'm
just
curious
about
which,
which
approach
you're
thinking
of
taken
for
this
stuff.
C
I
think
it's
pretty
challenging
to
do
it
at
low
time,
because,
for
example,
like
one
reason
why
you
might
be
using,
you
might
tell
spring
rest
template
to
use
apache
http
client
is
because
you
already
pulled
that
into
your
app
and
that's
what
you're
using
elsewhere.
C
C
And
yeah,
so
that's
why
we've
been
using
a
context
key
which
has
worked
great
for
us.
We
are
today
suppressing
nested
client
spans
for
across
all
java
instrumentation,
but
it's
not.
It
doesn't
interrupt
with
like
manual
instrumentation
of
client
spans,
it's
just
interops
with
other
either
auto
instrumentation
or
library.
Instrumentation,
also
that
we
we
author
against
the
instrument.
C
Problem
for
you
right
unless
they
use
the
instrumenter
api,
where
we
automatically
populate
that
context.
Key
I
see,
which
is
another
reason
to
try
to
get
people
over
to
the
instrument
or
api,
because
then
we
can
get
extra
functionality
like
this
of
tracking
nested
layers
of
things,
without
adding
any
additional
complexity
to
the
user.
Experience.
C
I
I
think
it's
reasonable.
I
think
it's
reasonable
to
have
a
you
know,
sort
of
like
a
verbosity
setting
that
if
you
want
to
see
nested
client
spans.
C
B
C
We
don't
have
that
hook
yet,
no,
no.
A
C
D
Nice,
I
I
wonder
if
this
is
going
to
come
up
with
configuration
in
general,
which
is
that
it's
it's
pretty,
it
seems
fairly
straightforward
for
someone
to
provide
configuration
like
let's
say
in
a
yaml
file
or
palm
or
whatever
for
like
on
an
instrumentation
type
basis
where
it's
like
for
this
all
instances
of
this
instrumentation
plug-in
you
know,
or
this
this
thing
like
configure
it
this
way,
but
it
gets
more
tricky
when
they're
like
when
I'm
using
netty
over
here,
I
want
this
stuff
suppressed.
D
I
want
it
to
work
this
way
and
when
I'm
using
netti
over
here,
I
want
it
to
work
this
other
way.
I
don't
know-
maybe
just
this
is
a
thing
in
java.
You
guys
are
used
to
targeting
in
general,
when
someone's
got
say
multiple
instances
of
something
running
an
application
and
people
want
to
configure
it.
I'm
just
curious
curious
how
you
solve
that
problem
in
java.
C
C
And
this
was
a
concept
that
ludmilla
was
sort
of
was
proposing
of
like
having
database.
You
have
database
clients,
http
clients,
maybe
rpc
clients.
You
know
these
things
that
we
have
semantic
conventions
for
and
within
database
clients
right,
you
can
have
duplication
of,
say,
an
orm
layer,
hibernate
or
net
entity
framework
capturing
the
sql
query.
But
then
you
also
have
the
jdbc.
C
So
you
can
have
duplication
at
that
layer.
You
can
have
duplication
at
the
http
layer
and
so
then,
as
a
user,
you
could
express
sort
of
okay.
I
mean
a
reasonable
default
to
me
seems
like
one
of
each
layer.
We
would
capture,
but
then
users
could
control
that
and
say
either.
I
want
more
meaning.
I
want
every
piece
of
data
or
I
want
less.
I
only
want
the
one
client
span.
I
don't
care
if
the
database
uses
http
under
the
hood.
D
Yeah
yeah,
I
know
that
that
makes
a
lot
of
sense
how
users
would
want
to
control
the
level
of
verbosity
there.
I
just
wonder:
are
we
going
to
have
users
who
are
like?
Well,
I
want
low
verbosity
here
and
I
want
high
verbosity
in
this
instance
over
there,
because.
C
C
I
would
tell
them
for
the
the
java
agent:
no,
they
don't
get.
That
agent
is
about
simplicity,
yeah,
yeah,.
C
Verbosity-
and
you
know
it's
just
yeah-
you
know
common
common
requirements
only,
but
that's
where
you
know
library,
I
think
library
instrumentation.
C
You
know
you
could
on
the
instrument
or
because
you
like,
with
ok,
http
each
place.
You
use
okay,
http,
you
create
the
open,
telemetry
interceptor
and
you
plug
that
into
your
pipeline
and
that's
where
you
could
control
that
verbosity
at
the
you
know,
per
place.
Yeah.
D
C
Really
yeah,
we
can't
even
really
target
we
haven't
even
figured
out
yet
how
to
target
separate
war
files
yeah
that
that
that
one
I
do
for
cs
supporting
yeah
at
some
point
and
we
can.
But
we
don't.
We.
D
Yeah,
because
in
in
all
of
these
languages,
I
can
see
it
getting
to
the
point
where
you
have
some
stock
configuration
file
like
open,
telemetry,
config
and
you're
kind
of
telling
every
plug-in,
or
even
anything
that
becomes
natively
instrumented.
What
you
should
do
is
like
take
in
this
thing
and
use
this
to
configure
yourself
and
like
look
for
your
your
setting
in
that,
or
you
know,
to
a
generic
degree,
be
like
if
you're
an
http
thing
just
go,
look
at
the
http
settings
in
this
thing
and
then
that
would
make
it
really
straightforward.
D
Even
in
more
manual
languages,
you
could
still
automate
the
the
wiring
up
of
that
stuff,
a
lot
easier
if,
if
everything
took
the
same
same
configuration
object
in
and
then
just
found
its
own
chunk
in
there,
something
like
that
versus
all
of
these
plugins
what's
kind
of
happening
and
will
continue
to
happen.
D
It's
like
all
these
plugins
write
their
own
little
configuration
thingy
and
there's
no
way
to
then
bundle
that
thing
up
easily
to
the
point
where
you
could
say
like
you
know,
write
a
configuration
file
in
yaml
or
whatever,
and
then
your
program
just
turns
that
into
this
config
object
and
and
hands
it
out
everywhere
and
now.
There's
like
a
clean
way
for
operators
to
like
go
in
and
like
muck
with
the
configurations
of
this
stuff
without
having
to
like
crack
open
the
code
or
you
know,
bother
an
application
developer.
D
Well,
I
mean
they're,
they
I
mean
that's
just
what
they're
they're
doing
right
now,
so
so
it's
totally
what
what
people
do
is
just
having
been
through
that
rodeo
before
it
it
like
leads
to
having
to
do
it
there
and
having
all
those
things
be
kind
of
like
non-standard
and
and
it
would
be
an
option.
It.
D
It
would
be
a
nice
step
forward
in
in
the
world
of
observability
if
we
could
find
if
in
the
process
of
like
going
through
these
semantic
conventions,
we're
defining
like
how
people
should
be
like
configuring,
the
basic
stuff
they
want
to
configure,
or
at
least
like
the
dsl
for
like
if
you're
gonna
provide
an
option
to
change
which
status
codes
produce
an
error
like
like
format
it.
D
This
way,
like
I'm,
just
wondering
if
we
could
get
to
the
point
where
we
could
potentially
release
a
lot
of
this
stuff
move,
it
move
it
into
some
standardized
configuration
object
that
then
be
able
to
move
this
into
the
place
where
an
operator
could
start
doing
it.
B
On
the
the
okay,
the
rewrite
of
the
oak
https
instrument.
C
All
right
I'll
share,
because
it's
very
on
topic.
C
So
so
currently
for
that
pure
service
mapping,
I
was
mentioning
earlier
so
we
exposed
that
for
the
job
for
java
agent
users,
but
we
were
assuming
that
library,
instrumentation
users
wouldn't
use
that
because
they
have
say
they're
using
it
here,
so
they
would
in
a
particular
location.
I
guess
pure
service
is
a
little
bit
more
specific
and
that
a
particular
code
path
they
may
just
they
already
know
the
pure
service,
so
they
can
set
it.
C
But
it's
similar
idea
here
of
config
of
whether
we
want
to
we
were.
We
were
shying
away
from
having
that
type
of
configuration
in
library,
instrumentation
and
just
exposing
programmatic
configuration.
D
Exactly
right
like,
but
we
if
we
don't,
if
we
don't
come
up
with
some
standard,
if
we
don't
provide
some
mechanism
for
doing
this,
that's
well
thought
out.
Then
it's
like
it
would
show
up
in
ways
that
would
be
like
kind
of
annoying
right
like
like
different
plug-ins
packing
on
environment
variables
that
they're
gonna
sniff
around
for
and,
like
you
know,
other
junk
like
that.
D
D
If,
if
step,
one
is
just
like,
let's
decide
what
these
options
should
be
and
like
for
each
option,
we're
gonna
provide
like
what
what
the
format
for
that
option
should
look
like
and
start
writing
them
down
somewhere,
then,
even
if
we're
still
doing
it,
programmatically
then
there's
at
least
like
okay,
when
I
want
to
like
twist
this
knob,
it's
like
always
for
the
most
part
for
the
instrumentation,
we're
maintaining
it's
like
the
same
knob
like
so
at
least
we're
being
internally
consistent,
and
then
you
know,
when
you
go
to
go
or
python,
you
know
it's
http
is
still
http
and
it
would
be
nice
to
like
have
the
same
knobs
there,
and
so
that's
that's
sort
of
like
maybe
maybe
like
step
one
if
we
could
just
like,
like
start
writing
those
things
down
in
the
semantic
conventions,
because
otherwise,
like
these
conversations,
I'm
sure
happening
in
like
node.js
right
now,
too.
D
Actually
nev
just
pointed
out
they're,
providing
like
an
instrumentation
hook.
Approach,
I
think,
go
is
starting
to
add
some
things
like
that
too,
like
interceptors,
where
you
can
kind
of
mung
stuff
programmatically,
which,
which
is
nice,
but
you
know
still
kind
of
leaves
it
to
the
end
user,
to
figure
out
how
they're
going
to
do
the
thing
they're
going
to
do
so,
I
don't
know
it's.
D
E
D
Because
it
mostly
comes
in
in
this
ad
hoc
fashion,
right
of
end
users
wanting
to
like,
could
you
please
tack
on
a
thing
over
here?
You
know
to
do
this
thing
and
like
that's
like
just
in
general,
right
like
that's
how
software
gets
crafty
right,
like
regardless
of
the
software
is,
is
like
that
the
little
paper
cuts
over
time.
D
You
know
so
anyways
that
that's
kind
of
why
I'm
thinking
about
it,
and
maybe
so,
if
maybe
it's
just
a
request,
if
you
guys
are
thinking
about
adding
things
like
like
thinking
about
just
http
in
general
right
now
and
like
how
to
define
like
the
like,
the
structure
for
client
spans
and
some
of
these
other
things.
D
Maybe
it's
just
a
thing
to
keep
in
mind
as
you're,
seeing
like
config
stuff
and
all
these
other
things
show
up
just
to
just
to
keep
funneling
them
into
the
into
this
spec
under
the
semantic
convention
headings,
so
so
that
they
can.
D
So
I
think
we
actually
need
to
clean
up
the
conventions
in
general
because
they're
kind
of
smeared
out,
but
right
now
we
have
these
semantic
conventions.
So
if
you
can
hear
I
can
open
up
the
spec
yeah,
I
just
haven't.
C
Seen
like
it
seemed
like
very
much
about
the
mappings
as
opposed
to
configuring
and
seeing
any
configuration
stuff
in
there.
D
Yeah
yeah,
so
all
we
have
right
now
are
basically
attributes
where
it's
like.
If
you're
recording
an
http
client,
then
these
are
the
attributes.
You
should
write
down.
D
And
I'm
thinking
it
would
be
nice
to
kind
of
expand
those
conventions
to
be
a
little
more
robust.
So
it's
like,
if
you're
doing,
an
http
client,
you
should
record
these
attributes.
You
should
have
this
kind
of
span
structure
around
like
logical
versus
physical
spans.
Right
like
like
some
of
the
questions
people
come
up
with
like
I
want
to
record
the
tcp
handshake.
Where
should
I
put
that,
if
I'm
doing
like
multiple
redirects?
D
C
Configuration
as
so
like
say,
the
peer
service
mapping,
stuff.
E
D
I
yeah,
I
think
so,
because
it's
sort
of
like
we're
saying
like
right
now.
You
should
record
this
attribute
this
way,
but
for
some
of
these
things,
the
end
user
is
not
going
to
want
these
defaults
like
they're,
going
to
like
for
some
of
these
things.
Maybe
it's
just
like
obvious,
but
for
some
other
things
it's
actually
a
bit
subjective.
D
What
you
would
want,
and
so
you
should
provide
these
options
which,
how
you
know
the
the
classic
one
that
keeps
coming
up
is
what
what
of
these
things
triggers
the
status
code
to
change,
and
so
we're
gonna
say
like
these
http
status
codes
count
as
an
error,
but
you
should
let
the
end
user
like
adjust
some
of
this
stuff
in
some
way
or
suppressing
spans.
D
For
example,
like
you
were
mentioning
like
doing
that
with
the
sampler.
D
We
should
start
adding
some
more
structure
to
the
spec
to
to
be
able
to
record
all
this
extra
stuff
so
that,
like,
if
you're
a
person,
who's
looking
to
implement
instrumentation
or
implement
this
stuff.
When
you
went
to
the
spec,
it
would
be
like
here's
all
the
stuff
you're
going
to
run
into
when
you
try
to
to
deal
with
this
instrumentation
just
so
that
it's
like
a
helpful
reference
for
for
everybody
who
keeps
coming
into
the
same
problems.
But
we
don't.
We
don't
have
that
structure
there.
B
Cool
yeah
ted.
Do
it
you're
something
you
mentioned
a
few
minutes
ago
have
reminded
me
a
little
bit
of
what
I
feel
like
now
that
the
java
sdk
is
stable,
like
50
of
my
job
is
telling
people
that's
a
cool
idea,
let's
get
it
into
the
specs,
so
that
not
everybody
does
it
differently?
Yeah!
That's
a
cool
idea.
Let's
get
that
into
the
specs,
so
then
everybody
that
does
it
differently,
like.
I
feel
like
that's
mostly
what
I
say
these
days.
D
Yeah
yeah
as
we're
moving
up
the
stack
to
like
instrumenting
all
the
things
there's.
I
think
a
lot
of
this
is
going
to
come
up
right
and
I
think
what
we're
going
to
have
to
add
a
bit
more
structure
to
this
spec.
B
Yeah
in
the
sdk
world
like,
for
example,
the
whole
jaeger
remote
sampler,
like
we
have
that
as
something
in
the
sdk
like
as
an
extension,
there's
a
configuration,
and
so
someone
came
along.
It's
like
hey.
We
need
configuration
for
this
and
I'm
like
what
okay.
No
this.
B
We
need
to
be
in
the
spec,
because
everyone's
going
to
do
it
differently,
exactly
I
don't
mind
having
an
extension
there,
but
as
soon
as
you're
going
to
provide
environment
variables
and
et
cetera,
like
we
need
to
be
standard
so
similar,
I
think
we
should
probably
be
doing
the
same.
I
mean
it's
gonna
I
mean
the
cats
are
all
out
of
the
bag
in
a
lot
of
ways
in
the
instrument,
but
when
there's
new
requests
and
new
features-
and
things
like
that,
we
should
probably
also
be
diligent
in
the
same
way.
D
This
is
actually
getting
into
the
realm
of
like
the
stuff
that
end
users
are
going
to
be
interacting
with
on
a
regular
basis
right
like
like
they
don't
interact
with
the
internals
of
the
sdk
and
all
of
that
very
much.
But
all
of
this
stuff
we've
been
talking
about
kind
of
represents
the
surface
area.
D
The
end
user
is
going
to
be
interacting
with,
like
the
data
they're,
going
to
see
the
configuration
knobs
they're
going
to
have
that
kind
of
stuff,
and
so,
if
we
can
try
to
to
keep
this
stuff
clean
to
the
degree
that
we
can
like,
I
think
that'll
actually
improve
the
experience
for
end
users
trying
to
not
just
get
started
with
open
telemetry,
but
then
like
use
it
in
anger
right
like
get
started
just
like.
D
Oh,
I
just
installed
the
agent
and
it
works
and
like
that's
great
and
and
like,
at
least
in
java.
That's
a
really
good
experience.
But
a
lot
of
these
things
seem
to
be
the
like
next
step,
which
is
okay.
Now
I'm
really
wrangling
a
real
production
system,
and
I'm
like
really
looking
at
the
data
and
and
so
like
all
these
other
questions
are
starting
to
come
up
about.
Like
I
want
to
suppress
this,
I
want
to
tweak
that
I
want
to
add
some
extra
attributes
here,
any
it's
not
yet
time
for
your
dinner.
D
Anyways,
I
don't
have
a
a
concrete
handle
on
this
stuff
because
I
feel
like
I'm
a
step
away
from
it
at
the
moment.
So
I
definitely
like
to
to
help
wrangle
wrangle
this
stuff,
but
you
all
seem
like
you're
you're
dealing
with
fielding
these
kinds
of
issues
on
a
on
a
daily
basis,
so
yeah.
C
D
We're
not
yet
because
we
haven't
fully
resolved
what
stability
means
for
all
of
this
stuff,
like
all
these
semantic
conventions,
in
particular,
that's
kind
of
the
thing
josh
surath
is
trying
to
work
on
right
now
is
trying
to
figure
out
like
what,
if
we're,
gonna
change
these
things
like
what's
the
mechanism
for
changing
this
stuff
safely
without
breaking
people's
dashboards,
and
if
we
can
figure
that
out,
then
we
can
mark
all
of
this
stuff
as
stable,
but
it
seems
dangerous
to
mark
any
of
it
is
stable
if
we
think
we're
gonna
potentially
change
the
data
in
such
a
way
that
it
would
break
people's
dashboards.
C
And
also
the
more
of
this
common,
maybe
instrumentary
api
common
configuration
that
we
can
map
out
before
anybody
starts
publishing
stable
things.
D
C
Exactly
and
also,
we
could
even
make
those
gating
on
stable
releases
of
instrumentation
yeah.
In
fact,
it
may
be
worth
like
having
some
kind
of
like
a
gate
on
publishing,
stable
instrumentation.
D
We
actually
do
right
now
in
the
in
the
spec.
You
know
it
it's.
It
says
that,
like
like
none
of
that,
that
stuff
should
be
marked
as
stable,
yet
which
I
feel
like
the
in
general.
The
the
maintainers
are
aware
of.
D
D
If
people
go
to
look
at
what
versioning
and
stability
means
right,
I
remember
we're
like
freaking,
trib
and
telemetry
semantic
conventions
like
we
don't
like
we're,
not
marking
that
stuff
as
stable,
because
we
haven't
decided
what
it
what
it
means
to
be
stable
and
that's
mostly
a
factor
of
like
everyone's
been
kind
of
heads
down,
just
trying
to
get
the
api
and
sdk
stable
and
out
the
door
and
then
metrics
and
all
that
taking
up
a
lot
of
cycles.
So
in
general,
in
the
different
language
groups.
D
Right
now
like
there's
like
a
feeling
that
the
the
core
maintainers,
don't
don't
really
have
the
cycles
to
think
about
contrib,
stuff
and
instrumentation,
they
can
be
kind
of
maybe
reactive
and
help
people
with
it,
but
but
actually
like
taking
a
step
back
and
like
overhauling
that
stuff
or
or
working
on
it.
It's
just
like,
like
just
too
broad,
like
there's,
not
enough
maintainers
to
do
that
and
ship
a
1.0.
At
the
same
time,.
C
D
C
With
that,
I,
like
I,
like
the
the
the
auto
instrumentation,
gives
us
the
easy
out
of
like
nothing
stable.
It's
just.
D
Yeah,
but
we
I
mean
we
want
to
call
it
all
stable,
because
that
would
be
nice
but
anyways.
So
what
I've
been
trying
to
do
is
get
more
help
from
microsoft
and
aws,
and
google
and
splunk
and,
like
the
other,
big
contributors
to
say,
hey,
could
you
could
you
bring
more
people
in
who
have
the
time
to
to
think
about
this
stuff?
And
some
of
it
is
like
a
core
set
of
like
open
telemetry
experts
like
honorarod,
for
example
like
aws?
D
Could
you
please,
like
free
his
cycles
up
to
to
be
able
to
actually
like
like
dig
into
this
stuff,
and
then
also?
Could
you
please
bring
in
some
subject
matter,
experts
to
like
review
what
we're
actually
offering
in
the
world
of
like
databases
and
message,
cues
and
stuff
like
that,
like
like
review
these
conventions
and
all
this
stuff
and
like
make
sure
this
is
actually
what
what
people
want.
C
You
met
connor
deep.
No,
I
haven't
okay,
I
know
she
was
reaching
out
to
for
what
they
were
trying
to
get
subject
matter.
People
involved,
but
not
having
a
lot
of
luck.
D
Yeah,
do
you
know
michael
lee,
yeah
yeah?
I
think
he's
he's
working
on
this
as
well.
I
put
just
posted
a
doc
in
the
zoom,
so
this
is
the
like
kind
of
dock,
we're
putting
together
for
these,
like
product
managers
to
be
able
to
to
kind
of
go
shop
around
to
get
some
resources,
so
actually
yeah.
If
you
wouldn't
mind
like
like
doing
a
once-over
of
this
thing
and
just
seeing
if
like
this,
this
makes
sense
to
you.
D
This
is
just
a
thing
yeah
that
we
we
whip
together,
but
yeah
michael
lee
and
alelita,
I
think,
are-
are
going
to
try
to
join
forces
and
get
this
stuff
try
to
get
some
more
resources
from
microsoft
and
aws,
and
I
think
josh
surith
is
gonna.
Try
to
get
some
as
well
from
from
google
and
likewise
some
splunk
people,
maybe
to
help.
D
But
it's
it's
kind
of
like
this
stuff
we've
just
been
talking
about,
which
is
like
what
what
do
we
have
to
actually
do
to
get
this
stable
and
there's
like
we
need
some
open,
telemetry
experts
in
order
to
like
architect,
some
of
this
cross
language
use,
standardy
stuff
we've
been
talking
about
right,
around
client
spans
and
all
this
kind
of
crap,
and
then
we
need
and
like
the
instrument
or
api
and
things
like
that,
then
we
need
some
subject
matter
experts
to
make
sure
that,
like
our,
what
we're
proposing
how
one
should
instrument
kafka
is
like
reasonable
and
we're
not
missing,
like
information,
people
want
and
then
last
and
certainly
not
least,
is
like
contrib
maintainers
like
can
you
please
supply
some?
D
D
We
need
a
maintainer
pool
like
a
contrib
maintainer
pool
beyond
the
core
maintainers
in
these
other
languages,
because,
like
it's,
it's
unreasonable
to
expect
that,
like
the
core
maintainers
are
gonna,
be
able
to
to
do
all
that
work
and-
and
if
we
don't
put
anyone
on
it,
then
it's
like
open
telemetry
is
going
to
struggle
because,
like
if
the
instrumentation
is
like
jank,
it's
you
know
it's
like
doesn't
really
matter
if
the
api
is
1.0,
so
so
that's
that's
kind
of
where
we're
at
in
other
languages
java
seems
like
it's
in
a
healthier
penny.
D
Yeah,
and
I
think
this
is
what
we
need
in
like
other
languages-
is
like
if
we
can
get
three
or
four
people
who
are
willing
to
like
wrangle
the
instrumentation
and
and
then
like,
do
some
work
around
yeah
inst,
all
the
kind
of
helpers
that
would
help
maintain
this
stuff
over
time
too.
So
things
like
the
instrument
or
api
test
harness
stuff.
You
know
things
like
that
where
we
can
be
kind
of
structured
if
we
have,
but
it
just
needs
more
people
to
have
like
the
cycles
to
do
that.
D
But
if
we
did,
then
that
would
be
stuff.
We
could
then
hand
out
to
the
community
as
well
and
be
like
well,
here's
like
here's
how
we
keep
track
of
this
and
then
that'll
mean
third-party
instrumentation,
hopefully
doesn't
diverge
too
much,
especially
with
stuff,
and
then
that
will
hopefully
lead
to
when
people
start
to
natively
instrument
their
stuff.
We're
not
gonna,
have
native
instrumentation
show
up
that.
We're
actually
like.
D
B
C
Struggling
a
little
bit
with
that.
That's
come
up
in
java,
where,
like
a
couple,
projects
have
added
the
open,
telemetry
instrumentation
and
it's
not
quite
native.
It's
still
like
through
some
shim
layer,
plug-in
sure.
A
C
But
that
is
still
not
quite
matching.
What
we
want
andrag
has
spent
some
time
in
a
couple
other
repos
helping
them
and.
D
Space
yeah
couch
face
been
at
it
for
a
while
and
yeah,
so
it's
just
like
if
we
have
some
people
who
are
able
to
actually
like
feel
this
stuff
and
then
have
time
to
be
thoughtful
about
like
what?
What
should
we
do
about
this?
You
know
and
then,
like
I'm,
a
big
fan
of
like
well
the
more
we
can
give
people
testing
tools
and
like
helpers
and
things
like
the
more
standard
their
stuff
is
going
to,
but
yeah
anyways.
D
D
And
it
turns
out
there's
no
like
immaculate
transference
of
yeah
right
years
over
to
knowledge,
so
so
we're
it's
just
been
kind
of
like
slow
going
like
I
started,
pushing
on
this
like
to
use
like
in
may,
basically
and-
and
it
took
until
the
end
of
june
july,
to
then
have
like
well.
I
now
have
product
managers
who
are
interested
in
this
stuff,
but
they
don't
yet
have
resources.
D
C
Well,
I
finally,
I
finally
got
an
a
head
count.
So
won't
really
help
you
because
it's
in
java,
but
hopefully
I'm
hoping
it
might
free
up
even
a
little
bit
of
my
time
and
then
I
could
help
on
some
other
stuff.
D
Yeah,
well,
it's
been
good
chatting
with
you
so
hope,
hopefully
like
some
of
this
is
is
helpful
and
I
I
wish
I
had
more
cycles
to
actually
drive
some
of
this
stuff.
I'm
gonna
try
to
free
myself
up
to
to
actually
help
wrangle
some
of
these
things,
but
yeah,
probably
not
in
java.
I
think,
if
I
can
help
by
trying
to
do
some
of
this
work
in
other
languages,
that
feels
like
a
voice
you
need
right
now
is
like.
C
Yeah
yeah,
especially
based
on
the
feedback
from
honorable
otep,
sounded
like
trying
to
get
this
rolling
in
one
other
language
would
be
really
helpful,
yeah
and
I'll
I'll
try
to.
I
think
I
can
continue
coming
to
this
meeting
and
and.
D
Awesome
yeah
and
I
think
in
the
meantime,
I
think
the
thing
that
would
help
me
out
the
most
is
yeah
be
on
the
lookout
for
thinking
about
yeah.
How
do
we
get
this
stuff
into
this
spec
like
what
is
a
a
clean
way
like
of
this
stuff,
you're
kind
of
looking
at
over
in
java,
around
structure
and
configuration
and
all
of
that
kind
of
stuff
like
yeah?
What's
the
way
to
get
into
the
spec.
C
Yeah
ludmila
and
I
are
planning
to
push
something
to
this
spec.
We
want
to
prototype
it
in
java
around
this.
This
layering.
E
C
Buy-In
from
the
java
team
prototype
it
there
and
then
propose
it
in
the
spec.
D
D
I
think
I
gotta
go
but
cool
yeah.