►
From YouTube: 2021-09-08 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
Five
minutes
pass
good
time
to
start
there's
any
so
this
is
a
instrumentation
cemented
conventions
meeting
also
a
former
apec
spec
meeting.
So
if
there's
other
general
spec
business-
and
we
have
time
for
it,
feel
free
to
add
those
items
to
the
agenda
at
the
end.
B
But
why
don't
we
get
started
with
your
semantic
convention
feedback
james.
C
Yeah
sure
we
talked
about
that
last
week
and
I
just
wanted
to
put
the
kind
of
link
in
there-
and
maybe
I
can
share
my
screen-
we
can
kind
of
just
I
can
just
kind
of
quickly
go
over
the
feedback
and
the
thoughts
behind
it.
One
second.
C
Yeah,
so
basically,
I
kind
of
you
know:
we've
been
using
this
main
convention
now,
for
you
know
many
months
and
just
a
few
kind
of
things
we
had
to
say
about
it.
So
one
thing
that
kind
of
was
a
little
bit.
C
Maybe
like
basically
what
I
said
here:
the
semantic
convention.
It
seems
a
bit
flooded
with
details
about
technologies
that
aren't
really
relevant
for
the
vast
majority
of
users.
C
Now,
maybe
that's
a
maybe
that's,
not
a
bad
thing,
but
that
was
just
my
kind
of
interpretation
of
it
like,
for
instance,
we
talked
about
this
briefly
last
week,
but
cassandra
takes
up
a
sizeable
chunk
of
the
database
trace
convention.
So
is
that
unnecessary
complexity?
For
like
what
could
be
a
more
general
document-
and
here
I
basically
ask
like-
is
it?
Would
it
be
productive
to
kind
of
separate
the
more
specific
technologies
out
into
kind
of
separate
parts
of
the
convention?
C
That
kind
of
extend
the
kind
of
I
guess
core
database
part
which
is
more
general
kind
of
database
attributes,
and
things
like
that,
the
and
I
know
oberon
down
here-
has
replied
saying
that
could
be
reasonable.
C
So
early
early
discussions
about
that,
if
anyone
has
any
thoughts
on
that
feel
free
to
kind
of
yell
it
out,
but
yeah
the
second
problem,
we
found
that
the
http
the
guidelines
for
the
the
http
span
name
were
not
really
practical,
at
least
in
our
case.
Maybe
they're
practical
in
other
kind
of
use
cases.
But
two
examples
of
that
is
well
one
of
the
http
spam
attributes,
not
the
spam
name.
C
In
this
case
it
says
to
send
the
the
full
url
except
we
can't
really
do
that
because
you
know
url
could
have
you
know
user
information
in
like
in
the
path
or
in
the
query
string.
So
that's
and
it's
not
really
clearly
defined
how
that
could
be
stripped
out
and
so
yeah.
C
The
other
thing
is
http
spam
name.
It
says
to
use
the
http
route,
which
we
found
would
kind
of
increase
our
costs
in
lightstep.
Quite
a
lot.
That
wasn't
really
my
analysis
personally,
but
someone,
someone
from
my
team
made
the
point
so.
C
I
know
everyone
down
here
also
said
that
it's
not
really.
C
Yeah,
it's
not
a
it's,
not
a
topic,
that's
addressed
very
closely
yet,
and
the
other
thing
was
just
I
know
ted
you
mentioned
this
last
week.
You
know
kind
of
translation
between
versions
of
semantic
convention
to
kind
of
aid
in
breaking
changes.
That's
the
other
kind
of
thing.
The
problem
three
discusses,
so
those
are
kind
of
things
that
we're
thinking
about.
C
I'm
not
necessarily
sure,
there's
like
an
action
just
yet
to
go
and
implement
any
of
these
things,
but
maybe
more
discussion
here
could
and
in
the
meeting
could
spur
that
along
so
yeah.
That's
that's
basically
that
if
anyone
has
any
thoughts,
then
feel
free
to.
B
Yeah
plenty
of
thoughts,
but
other
people
should
go
first,
johann
say.
A
I
have
a
question
about
the
routes:
the
what
span
name.
What
was
the
routing
issue?
I
mean
the
the
cardinality
issue
with
the
routes.
C
Yeah
we
found
that
the
cardinality
could
just
be
high.
I
couldn't
maybe
maybe
I
need
to
go
into
the
more
specifics
there,
but
I'm
curious
from
that
services
that
have
lots
of
sorry
sorry
go
on.
What
do
you
think?
Oh
no
go
ahead
just
for
services
that
have
a
lot
of.
I
know
a
lot
of
different
kind
of
paths.
It
can
be.
D
C
A
So
are
these?
Does
your
app
have
a
lot
of
like?
Are
the?
Is
it
a
set
of
entry
points
like
I
know,
on
the
java
instrumentation
side,
for
example,
routes
routes
map
to,
for
example,
a
spring
controller
path,
and
so
you
know
most
apps.
Have
I
don't
know
how
many
say
a
hundred
of
those
but
they're
all
sort
of
distinct
entry
points
into
your
app,
so
it
forms
a
pretty
good
bound
bounds,
the
cardinality
pretty
well.
A
So
I
was
wondering
if
your
app
just
has
a
ton
of
those
like
a
thousand.
You
know
controllers
in
that
way
or
if
it
was
an
instrumentation
problem,
that
the
instrumentation
was
capturing
too
much
of
the
didn't
know
about
those
routes
and
so
was
arbitrarily
using
like
the
http
path.
C
I
think,
potentially
in
our
systems
it
wasn't
able
to
distinguish
between
it.
It
became
I
I
wasn't
the
one
who
wrote
this
wrong,
so
I
apologize.
I'm
not
super
well
versed
on
it,
but
you
know
when
things
appear
in
the
yeah,
so
the
route
is
the
path
template.
That's
that's
a
great
thing.
That's.
That
is
a
good
point.
I
I
didn't
really
make
that
distinction
in
my
mind
very
clearly.
A
C
Yeah
maybe
well
this
that
that
problem
with
the
http
span
name-
that's
I
didn't.
I
didn't
actually
bring
that
up
I'll,
go
back
in
I'll,
go
back
and
ask
my
team
and-
and
I
can
kind
of
comment
on
that
there.
But
that
is
a
good
point.
Maybe
http
route
is
is
an
appropriate
cardinality
and
maybe
that
is
actually
fine.
C
I
think
maybe
a
challenge
for
us
was
determining
the
route
in
a
kind
of
general
case,
because
we're
kind
of
providing
the
this
for
the
whole
of
atlassian.
How
did
how
is
the
route
specified?
We
kind
of
wanted
that
to
be
automated?
We
don't
really
know
what
the
route
is
from
any
random
service,
because
it
could
be
used
across
lots
of
different
services.
C
But
no,
let
me
let
us
think
think
that
more
through.
I
think
that
through
more
yeah.
E
Well,
I
I
think
the
spec
tries
to
clarify
it
and
it
tries
to
say
that
you,
you
should
use
the
route
instead
of
the
path
when
you
can
and
if
you
can't,
then
you
should
use
something
slightly
more
general
to
try
to
avoid
the
cardinality
explosion
problem.
You
know
some
of
our
instrumentations
in
the
go
sdk
have
routes
available
because
they're
in
frameworks
that
have
routes
and
expose
them
to
handlers
and
some
don't
like
the
the
native
go
standard
library,
http
instrumentation
doesn't
because
it
doesn't
have
a
concept
of
a
route.
E
It
just
has
paths
that
you
give
it,
and
so
it
just
uses
like
http,
git
or
http
post
for
spam
names
there,
but
we
also
provide
an
optional
spam
namer,
where
you
can
say:
here's
a
function
that
you
you
give
it
a
request
and
it
will
give
back
what
to
name
that
span.
B
Yeah
there
it
there
is
some
trickiness
here
right
like
the
spec
could
be
clear,
but
there
there
actually
is
a
a
problem
with
http,
which
is
just
the
http
protocol
itself
doesn't
have
a
good.
B
It
doesn't
have
a
good
variable
that
matches
an
ideal.
Cardinality
right
you
either
have
something.
That's
so
general.
It's
useless,
like
the
you
know,
method
type
like
get
post,
which
is
what
it
defaults
to.
We
default,
recommend
defaulting
to
the
method.
B
Since
that's
low,
cardinality
and
wouldn't
wouldn't
you
know,
snow
a
system
under
and
then
the
other
side
would
be
the
the
path
which
is
generally
speaking,
much
has
a
cardinality.
That's
that's
much
too
high
to
be
to
be
useful
as
an
index
and
so
route
kind
of
sits
in
the
middle
ground,
but
because
http
clients
have
no
concept
of
it.
This
gets
into
a
sort
of
layered
instrumentation
problem
where.
B
The
piece
that's
often
starting
the
span
has
to
pick
something,
and
so
it
usually
picks
like
the
method
and
then
at
some
later
point.
Some
other
piece
of
technology
in
the
stack
that
understands
routes
needs
to
then
override
the
span
name
and
replace
it
with
the
route.
B
In
other
words,
generally
speaking,
even
when
routes
are
present,
they're
they're
usually
not
present
at
start
time
for
the
span,
and
it's
often
a
different
piece
of
technology
that
or
a
different
library
that
that
adds
it
in,
and
I
think
this
this
also
gets
to
some
this
question
of
of
layering
that
that
we
have,
where
you
end
up
having
multiple
libraries
wanting
to
instrument
and
how
much
instrumenting
they
should
do
is
somewhat
dependent
on
the
presence
of
other
libraries.
B
B
It's
actually
really
unfortunate
that
we
don't
have
routes
right
when
the
span
starts,
because
we
would
love
for
the
span
name
to
be
immutable.
It
actually
causes
a
lot
of
problems
having
the
span
name
change
at
an
arbitrary
point
after
the
span
is
started,
but
unfortunately,
routes
are
like
actually
the
issue
driving
driving
that
design
decision
right
there,
so
so
you're
not
wrong
james.
This
is
like
http
and
span.
Names
is
like
a
uncomfortable
mishmash
situation
that
that
creates
genuine
complexity,
not
just
in
the
semantic
conventions.
B
But
then,
in
this
question
of
like
when
you're
writing
instrumentation,
how
is
all
this
instrumentation
supposed
to
interact
with
each
other?
Should
the
framework
just
presume
some
lower
level,
http
client
created
the
span
and
all
it
should
do,
is
update
the
span
name
or
should
it
not
presume
that
and
actually
try
to
create
the
entire
controller
span,
for
example?
So.
C
Yeah,
I
think
I
think
it's
sensible
to
if,
for
instance,
you
can't
have
the
route
you
can't
get
the
route
for
whatever
reason
just
override
it.
With
with
something
sensible,
that's
low
cardinality,
I
was
just
trying
to
kind
of
find
it
in
the
spec
yeah
is
it.
I
know
someone
someone
before
mentioned
that
you
could
over
the
spec
says
you
could
override
it.
B
Yes,
so
well,
I
posted
a
link
right
there
just
to
the
the
semantic
conventions,
little
section
on
names
which
says
you
know
the
basically
the
default
is,
you
know,
http
method
name
and
then,
if
you
have
a
concept
of
a
route
like
you
know,
it's
like
the
classic
example.
Then
you
should.
You
should
then
override
the
spam
name,
and
if
I
go
to
the
s
tracing
api
spec,
if
you're
looking
for
the
override
there.
B
E
Yeah,
I've
just
linked
it
in
chat
and
there's
an
important
over
there
regarding
samplers
that
head
samplers
can
only
consider
information
that
was
present
when
the
span
was
started.
So
if
you
have
a
sampler
that
depends
on
the
name
and
the
name
is
changed
after
the
span
started,
it
won't
be
able
to
operate
on
it
right.
B
Which
is
unfortunate
and
again
I
could
see
people
wanting
to
make
decisions
based
on
route,
because
you
know
route
and
controller
right.
It's
like
that's
generally.
The
level
of
granularity
people
want
to
break
these
things
up.
It's
like
controller
method.
This
might
be
another
name
for
route,
so
that's
that's
kind
of
like
the
layer
people
want
and
if
that
framework
made
its
own
span,
then
you
could
potentially
have
the
route
or
the
you
know:
controller
name
dot.
B
You
know,
method
name
some
some
route
equivalent
present,
but
then
you
end
up
with
this
extra
like
span
sandwich
where
you're
gonna
have
like
a
a
span
in
there
for
the
controller
method
and
then
a
span
for
the
http,
like
http
server
span,
sitting
directly
underneath
it
and
that
adds
cost,
and
some
people
complain
about
having
when
they
get
their
instrumentation
having
this
kind
of
double
instrumentation
or
layered
instrumentation
like
that,
for,
I
think,
a
variety
of
valid
reasons.
People
don't
want
that
and
want
it
collapsed.
B
F
Yeah,
I
think
that's
a
big
challenge,
because
actually,
when
we're
talking
about
routes,
I
mean,
strictly
speaking,
we're
not
talking
about
http
instrumentation,
but
we're
already
talking
about
web
server
or
web
framework
instrumentation.
It's.
F
And
I
I
think
yeah
it's
gonna
be
very
challenging
to
kind
of
harmonize
those
different
levels,
and
I
just
I'm
not
an
http
expert,
but
I
just
know
from
like
instrumenting
php
web
frameworks.
Remember
that
we
had
different
span
naming
conventions
for
each
framework,
because
non-trainer
were
kind
of
a
span.
Naming
scheme
worked
for
all
of
the
frameworks
so
yeah.
F
I
wonder
if
we
can
help
kind
of
write
those
be
some
anti-conventions
in
a
way
that
kind
of
gives
the
necessary
freedom
to
to
achieve
like
to
achieve
good
results.
In
our
circumstances,.
F
G
Yeah,
I
have
a
quick
question.
The
route
is
a
great
example
and
there's
multiple
conventions
for
each
framework.
I
think
it's
a
great
example
of
the
fact
that
historically,
we've
been
trying
to
create
instrumentation
separately
from
the
web
framework
itself,
so
it's
done
in
a
hacky
way
like
what
we
can
achieve
with
the
hoax.
It
provides
right
but
like
let's
say
an
asp.net
or
where
we
can
write
whatever
we
want.
G
Whatever
we
decide
in
this
group,
we
can
do
the
right
thing,
not
in
a
hacky
way,
and
should
we
design
conventions,
assuming
that
they
are
for
libraries
that
potentially
can
evolve
or
they
are
for
hockey,
workarounds
and
hooks
that
current
frameworks
provide.
I
think
there
is
a
balance
here
and
we
we
should
maybe
consider
both
right.
B
Ludmila,
you
also,
I
feel
like
this
layering
issue.
This
is
something
you've
been
thinking
about
a
lot
about
actually,
and
you
have
a
proposal.
Is
that
correct
or
would
you
mind
maybe
this
is
a
I
would
like
to
get
to
the
rest
of
james
points,
but
since
we
do
want
to
talk
about
http
on
this
call,
maybe
we
could
just
if
you
wouldn't
mind,
pitching
your
proposal
for
dealing
with
layering.
G
Okay,
so
I
think
the
the
principle
I
want
to
bring
the
new
one
we
didn't
have
so
far
is
that
this,
this
concept
of
players,
so
in
an
application
that
we
might
have
there
is,
let's
say,
an
http
server
span.
G
So,
let's
first,
maybe
think.
If
there
are,
there
is
any
controversy
here,
because
we
don't
have
a
clear
guidance.
Sometimes
we
say
that
http
attributes
should
be
stamped
on
database
attributes.
Sometimes
we
just
omit
it
from
any
description.
So
I
kind
of
want
to
understand
what
are
everyone's
feeling
about
this
clarity.
G
E
Yeah,
I
I
think
this
aligns
with
what
I
would
expect
to
see
from
you
know
like.
In
fact
it
aligns
with
what
I've
seen
from
say
the
dynamodb
clients
when
I
was
using
it
in
the
last
application.
I
was
building.
That's
a
db,
that's
built
on
top
of
http
right,
dynamodb
wasn't
instrumented,
but
the
http
client,
underneath
it
was
so.
I
could
see
those
those
clients
and
if
dynamodb
was
that
the
sdk
was
then
I
would.
I
would
expect
that
to
sit
right
in
between
the
two
http
server
and
client
spans.
G
Nice
yeah
and
then
basically
the
thing
I
want
to
introduce
is
this
layer
idea
or
convention.
So
basically
each
layer
is
the
same
as
convention
and
let's
say
we
can
have
some
conventions
that
include
others
like.
I
recently
learned
that
fast,
the
lambda
function
call
which
is
triggered
by
http,
should
have
http
attributes
and
fast
attributes.
G
Then
that's
okay,
like
I'm,
not
going
to
prohibit
that
each
of
the
spans
potentially
can
have
general
attributes
like
thread
id
or
the
code
line
right.
So
we
are
not
going
to
prohibit
that,
so
any
of
them
can
be
general,
but
basically
each
layer
is
a
convention
and
instrumentation
should
not
mix
conventions
together.
B
Yeah,
but
one
comment
on
that-
I
I
think
that
is,
that
is
a
very
logical
separation.
So
getting
back
to
our
http
server
example,
you
would
have
an
http
server
span
that
had
all
the
http
information
and,
as
a
child
of
that
span,
you
would
have
like
a
controller
span.
Let's
say
that
would
then
have
all
of
the
information
about
like
the
controller.
B
You
know,
method
and
anything
else
that
was
relevant
to
that
some
feedback
we
get
from
users,
and
I
think
this
partially
relates
to
how
current
tracing
systems
work,
which
is
that
it
is
often
difficult
to
index
across
spans
within
a
trace,
and
I
think
also
partially
due
to
just
when
operators
are
having
to
look
through
trace
data
having
to
click
kind
of
back
and
forth
across
different
spans,
to
see
all
the
information
results
and
end
users
coming
to
us
and
being
like
hey.
Can
we
get?
B
B
F
I
think
the
usability
is
one
thing,
but
also
something
I
think
that
will
come
up
in
future
or
that
is
already
coming
up
is
like
creating
metrics
from
traces,
and
I
also
think
it's
much
easier
to
create
metrics
from
traces
that
follow
this
one
span
approach,
then
that
followed
this
nested
approach,
because
some
of
the
metrics
could,
for
example,
be
how
much
time
was
spent
in
http
course
and
how
much
time
was
spent
in
database
course
and
then,
when
you
apply
this
like
to
this
layers
here,
that
miller
nicely
kind
of
worked
out,
it's
not
really
clear
how
those
metrics
should
how
they
should
work
like
this
nested
http
color,
because
the
database
client
span
should
discount
towards
the
overall
http
core
duration
of
the
application,
or
should
it
not-
and
I
think
it's
I
I
I
I
I
cannot-
I'm
not
gonna,
I'm
not
saying
here
that
one
solution
is
better
than
the
other,
but
there
is
definitely
each
solution
has
their
own
complications.
G
Yeah,
I
think,
like
we,
we
kind
of
have
to
follow
this
approach,
because
if
we
have
auto
instrumentation
and
if
some
laborer
decides
to
stamp
http
attributes
and
database
calls
regardless,
if
they
do
it
right
or
wrong,
they
will
end
up
with
duplication,
because
users
have
auto
instrumentation
enabled
and
there
is
no
way
to
suppress
it.
Like
per
you,
don't
know
if
it
happens
in
database
call
scope
or
it's
just
the
http
call
you
that
user
application
makes.
G
Okay
and
then
like
this,
this
picture
that
I
painted
here,
it's
not
what
we
get
today.
What
we
get
today
is
something
like
this,
so
what
we
get
today
is
we
have
multiple
server
spans.
They
are
reported
my
multiple
things,
instrumented
like
in
spring,
I
think
there
are
trust,
probably
can
correct
me
and
then
iraq
about
how
many
http
server
spends.
We
suppress
then
for
client
calls.
We
have
http
clients
calling
each
other,
among
other
things,
that
cause
duplication
like
the
client
library,
like
azure
sdks
instrument,
http
plus
auto
instrumentation.
G
We
can
basically
require
instrumentations
to
check
okay
if
this
layer
is
already
instrumented
so
like
if
I'm
apache,
http
client
in
java,
then
let
me
first
check
if
http
client
is
already
on
the
context
and
then
let
I
will
back
off
if
it's
there
with
this
approach
like
there,
there
is
also
possibility
to
work
for
servers
so
like
keeping
that
route
question
aside.
No,
maybe
a
route
is
a
good
example.
G
So
with
routes
we
can
say:
okay,
give
me
the
http
servers
pen,
and
this
is
unambiguously
will
return
us,
the
http
servers
pen.
G
But
when
you
just
call
current
spam,
you
you
don't
know,
what's
current,
maybe
it's
some
con,
maybe
something
created
internal
span
where
you
don't
know
which
http
server
spend
you
refer
to
so
like
this
thing
also
gives
us
some
possibility
for
configuration
like
we
can
say,
suppress
all
of
the
same
type
of
the
same
convention
or
we
can
say,
suppress
all
of
the
same
kind
like
all
clients
or
all
server
spends.
G
So
it's
just
think
we
can
hide
within
the
open,
telemetry
implementation
that
allows
users
to
choose
and
maybe
for
routes.
The
good
approach
is
we
will
let
them
peek
if
they
want
to
like
the
http
server,
the
outer
http
server
span,
or
they
want
controller
to
be
http
server
span.
It's
just
the
question
of
configuration,
it's
just.
G
Basically,
we
we
can
ask
users
how
to
do
it,
but
my
proposal
here
is
barely
to
introduce
this
concept
of
convention
or
layer
and
also
to
say
that
we
can't
suppress
nested
things
by
either
convention
or
kind,
and
this
autumn
describes
how
it
can
be
done.
E
I
worry
a
bit
about
loss
of
information
if
you
suppress
the
the
secondary
spans
like
if
you
suppress
that
servlet
span.
Is
there
information
that
the
servlet
has
that
it
would
try
to
put
on
a
span
that
it
would
just
completely
be
lost
if
it
were
suppressed?
Could
it
instead,
when
it
tries
to
start
a
span,
have
the
sdk
say:
oh
you're,
trying
to
start
a
server
span,
the
the
current
span.
That
you're
is
your
apparent,
is
a
server
span.
Let
me
just
give
you
that
span
back
so
that
you
can
annotate
it.
G
Yeah,
so
this
is
the
question
of
instrumentation
right,
so
I
think
that
the
fact
that
we
have
multiple
is
just
because
we
don't
know
how
users
use
certain
framework
like
spring
and
it
can
have
multiple
layers,
trust
corona.
Or
can
you
picture
and
say
why
we
have
multiple
of
them.
A
Yeah
so
for
in
say
middleware.
This
would
be
we
capture.
In
java,
we
capture
the
server
span
at
the
tomcat
like
native
tomcat
layer,
and
then
we
also
have
servlet
instrumentation,
which
will
capture
it,
for
you
know,
say
some
container
that
we
don't
instrument
natively
and
since
these
are
both
http
server
spans
and
the
conventions,
are
they
both
follow
that
same
convention
they
get
stamped.
With
the
same,
I
think
in
all
cases,
the
same
information.
A
Where
sometimes
it's
a
little
different
as
down
in
the
client,
so
in
the
client
spans
it's
a
little
trickier.
I
do
think,
though,
with
the
like
ludmila's
approach.
The
http
client
spans
should
be
pretty
much
the
same
and
getting
stamped
pretty
much
the
same.
I
don't
see
any
problem
really
with
loss
of
at
least
lots
of
attributes.
A
The
one
thing
that
you
do
potentially
lose
is
that
lower
level,
maybe
you're
missing.
You
know
that
lower
level
sakety
connection
piece
or
you're
missing
a
little
bit
of
timing.
There,
information
that
you
could
say:
oh
it
was
stuck
in
the
google
http
client
before
it
even
got
to
the
apache
http
client.
A
B
Yeah,
I
think
I
might
want
to
make
a
distinction
there
between
there's
one
piece
of
layering
we're
lacking
right
now,
which
is
physical.
I
don't
know
what
we're
calling
these
things.
I
think
we
tend
to
say
like
physical
http
requests
versus
a
logical,
http
request,
you
may
make
a
logical
request
to
get
something
from
a
certain
endpoint,
but
under
the
hood
there
may
be
several
retries
there
may
be
redirects,
and
so
that
one
logical
request
is
then
composed
of
numerous
physical
requests.
B
The
terms
we're
using
people
have
a
better
term
to
distinction,
distinguish
those
two.
I
would
love
it
so,
but
anyways.
That's
that's
like
a
layer
that
I
think
we're
like
missing
from
the
spec
and
we
need
to
to
add
and
then,
as
you
all
are
mentioning,
there's
even
a
layer
below
that
that
that
something
needs
to
capture,
but
the
issue.
B
The
layering
issue
I
think
ludmila
is
talking
about
is
where
you
have
separate
libraries
that
feel
the
need
to
essentially
recreate
the
exact
same
span,
and
I
wonder,
and
and
so
as
a
result,
you
end
up
saying
well,
I
would
like
to
suppress
some
of
these
spans.
If
I
knew
another
span,
another
layer
was
creating
it
and
I
kind
of
wonder
to
what
degree.
B
We
could
simplify
these
things
and
just
say
that
certain
layers
shouldn't
produce
spans
or
certain
layers
should
purely
produ
decorate
spans.
So
the
framework
layer
comes
to
mind
as
a
layer
that
could
be
said
this.
This
layer
should
should
just
decorate
the
whatever
span
is
currently
available
with
its
information,
and
it
should
leave
it
to
a
lower
level.
G
Sorry,
the
prop
there
are
two
problems
with
this
approach.
So
the
first
one
is,
you
don't
know
like,
for
example,
in
java,
it's
typical
for
http
clients
to
use
each
other,
so,
like
a
bunch
of
things,
are
built
on
top
of
nature.
Some
things
are
built
on
top
of
a
page
apache
http.
So
this
is
a
real
example.
G
Google
http
client
uses
apache,
so
apache
http
client
doesn't
know
anything
about
google
http
client
right,
so
this
should
be
instrumented
in
this
way,
like
maybe
a
google
http
client
should
not
be
instrumented,
because
it's
it's
only
built
on
apache,
but
like
it's
already
it's
up
to
users
to
configure,
maybe
one
instrumentation
or
another
or
suppress
one
instrumentation
or
another-
I
don't
know
but
yeah,
maybe
google
http
client
cannot
be
instrumented.
G
G
We
can
add
attributes
that
you
would
use
to
get
support
from
azure
surveys
underneath
the
the
legacy
of
the
correlation
context
stuff
right.
We
cannot
make
also
instrumentation
at
this,
and
we
want
our
users
to
have
those
attributes.
We
cannot
stamp
on
them
on
current
spam
because
it's
not
related
to
anything
and
we
want
them
per
http
request,
because
this
is
how
they
get
support
from
the
service
underneath
then
we
can
provide
better
context.
G
We
can
know
that
404
or
409
errors
or
their
like
success
in
this
case,
because
this
is
what
the
api
was
called
and
creative
not
exists,
404,
it's
perfectly
fine,
it's
not
an
error
right,
so
we
want
to
instrument
those
and
we
we
see
a
huge
value
in
this.
It's
just.
We
want
to
suppress
what
happens
in
auto
instrumentation,
because
we
do
better
job
at
this.
In
this
case,.
E
E
Be
like
the
the
distinction
that
ted
was
talking
about,
though,
between
the
logical
and
physical,
then,
where
the
the
sdk
has
that
logical.
You
know
slightly
higher
level
view
of
the
operation
where
there
may
be
multiple
physical
requests.
Actually
that
happened
to
try
to
fulfill
that
logical
request
from
the
unfortunately.
G
B
Okay,
so
all
of
this
information
would
be
on
each
individual,
redirect
and
and
underneath.
B
Retry,
okay,
yeah,
it's
tricky
yeah
and.
F
I
think
that
just
thinking
about
this
approach
that
luke
miller
proposed
to
you,
because
I
definitely
think
that
is
definitely
a
problem
that
we
have
already
and
that
is
hurting
some
users.
And
basically
the
approach
we
take
here
is
that
we
say
on
the
instrumentation
level.
We
say:
okay,
we
just
clean
up
the
trace
tree
and
we
send,
like
the
nice
trace
tree
to
the
back
end.
F
That
can
be
visualized,
but
then
other
approach
would
just
be
just
to
send
like
the
the
trace
tree,
with
all
the
information
that
we
have
and
just
say,
okay
backhanded
now
you
make
sense
of
this
and
you
kind
of
you
do
your
layer,
suppression
and
you
do
kind
of
you
kind
of
maybe
put
like
unified
two
http
clients,
bands
that
are
parented
to
each
other,
and
I
I
didn't
think
that
through,
but
just
wondering
about
their
pros
and
cons
of
each
of
those
approaches.
G
Think
I
I
have
like
different
configurations
based
on
the
the
like:
it's
probably
a
backhand
choice
and
part
of
distro
like
configuring,
it
so
like,
maybe
backhands
that
want
it,
can
choose
to
press
none
and
suppress
now
right,
but
if
you
use
zipkin
or
jager,
probably
it
will
be
not
not
trivial
to
do
such
logic
there
right.
So
you
probably
may
want
this
thing
or
maybe
just
kind
whatever
works
for
your
current
system
that
your
current
back
end.
B
I
I
kind
of
have
a
feeling
we're
gonna
we're
gonna
need
both
essentially
like.
I
think
I
think
we
need
to
to
maybe
sort
out
like
what
layers
keep
to
themselves
and
try
to
decorate
things
versus
what
layers
recreate
information,
but
even
after
we've
done
all
of
that
work.
There's
still
going
to
be
this
need,
in
general,
to
suppress
specific
pieces
of
instrumentation
right,
like
I
that's
kind
of
the
impression
I'm
getting
like.
We
won't
we're
not
going
to
be
able
to
create
a
whatever
design.
B
We
come
up
with
it's
going
to
be
leaky,
and
there
are
other
reasons
for
suppressing
instrumentation
that
you
know
have
nothing
to
do
with
this,
like
this
nice
design
right
like
for
whatever
reason
users
may
just
want
certain
certain
things
turned
off,
so
I
kind
of
have
a
feeling
we
it's
like
both,
and
I
guess
my
question
around
the
suppression
to
me.
That's
that's
something
you
would
do
at
configuration
time
like
or
maybe
to
rephrase
this
ludmila.
B
Do
you
see
this
as
something
that
the
the
application
owner
or
the
operator
is
in
charge
of
so
in
a
configuration
file
or
elsewhere
they're?
Creating
a
list
of
instrumentation
that
they're
they're
trying
to
suppress,
I
I
think
I
noticed
there
was
maybe
something
in
this
proposal
or
a
prior
proposal
around
having
it
actually
be
information
carried
on
the
context
and
like
individual
instrumentation
libraries
we're
gonna
try
to
to
do
something
fancy
with
it.
So
I'm
curious
what
you
think
about
those
two
two
approaches.
G
Yeah,
I
think
that
that
the
users
should
have
good
default
right.
They
might
be
able
to
configure
it
in
like
more
fine-grained
way,
but
the
default
should
be
good
enough,
and
I
believe
one
of
this
that
let's
say
the
convention
is
a
good
default
to
have
or
it
may
be.
The
kind
like
we
suppress
all
client
stands
by
default,
but
we
cannot
keep
like
suppress
none
option
by
default.
It's
it's
ugly
right,
it's!
We
know
it's
ugly.
We
know
that
there
are
like
not
besides
java
in
python
everywhere.
We
have
this.
G
B
G
And
also,
I
think
the
instrumentation
library
should
not
be
concerned
with
this
configuration
it's
impossible,
like
we
already
have
instrumentations
created
by
open
telemetry
community,
which
are
completely
inconsistent
between
languages
and
then
maybe
even
libraries
within
the
same
language
and
then,
if
we
make
it
instrumentation
concern
it,
it
won't
be
done
so
like
we
should
tell
instrumentation,
maybe
use
this
api
that
we
provide
instrumentation
api
like
from
anarch
suggestion,
or
maybe
we
can
say.
G
Okay,
there
is
this
api
in
in
trace
api,
which
I
would
like
to
have
that
we
can
discuss
it,
which
basically
says
before
you
instrument
go
ahead
and
check
if
the
your
convention
plus
type
span
is
there.
So
I
think
I
have
an
example
somewhere
like
before.
I
call
if
I'm
http
client
before
I
do
anything.
I
call
this
and
it
if,
if
it's
there,
then
I
back
off
right.
So
this
is
easy
and
then
sdk
can
hide.
This
configuration
inside
an
api
just
exposes
apis
right.
We
don't
care.
B
Right,
I
I
huge
thumbs
up
to
not
burdening
instrumentation
authors
with
this
in
general
yeah.
That's
like
the
other
track
of
work.
This
group
needs
to
do
is
how
do
we
provide
tooling
to
correctly
and
easily
apply
all
these
conventions
and,
as
part
of
that,
maybe
apply
some
of
these
features?
B
B
We're
leaking
information,
but,
but
perhaps
I
guess
what
I'm
thinking
about
is
we
tend
to
not
include
any
kind
of
getters
on
span
objects,
because
you
don't
know
what
how
it's
being
implemented
under
the
hood
or
even
if
all
the
data
has
been
dropped
on
the
floor
because
of
sampling
reasons,
for
example,
but
it
looks
like
here
you're
saying:
actually,
this
information
would
not
be
on
the
span
object.
This
would
just
be
another
piece
of
information
in
the
context.
G
It's
on
the
context,
it's
more
like
you.
We
have
a
shortcuts
to
specific
expanse
on
the
context.
The
spin
api
doesn't
change,
but
the
information
we
expose
is
basically
maybe
a
stack
of
spans
right.
So
assuming
we
can
walk
up
the
stack
of
spends,
but
nothing
so
actually
we
don't
even
know
the
relationships
between
them.
We
just
know
that
the
this
http
client
span.
This
is
my
short
card
to
this
pen
and,
let's
say
if
I'm
a
user-
and
I
want
to
stamp-
let's
say
an
exception
or
event
on
http
server
spend.
B
G
Like
we've
done
it
in
java,
it's
just
aesthetic
single
tone,
so
it's
not
even
a
map.
We
can
potentially
do
a
map
later,
it's
just
easier
and
safer
to
start
as
well
known
things
for
the
conventions
with
support,
but.
B
I
guess
what
I'm
saying
just
so.
I
understand
clearly
what
what
you're
proposing
is
you
you
have
a
set
of
keys
and
you
can
say
get
me
this
specific
span.
Don't
get
me
the
current
span
get
me.
The
http
client
span
right
and
I
don't
care
if
it's
current
or
not
current,
just
just
find
find
that
one
for
me.
That's
that's
in
this
specific
context,
though,.
B
B
One
of
these,
these
other
spans-
that
does
make
a
lot
of
sense
to
me,
I'm
like
slightly
nervous
in
general
about
adding
complexity
to
to
our
model.
But
this,
like,
I
wonder
what
the
the
side
effects
are
here,
but
I
guess
it
sounds
like
you've
already
gone
and
done
this
in
java.
So
have
you
encountered
side
effects
from
or
corner
cases
where
this
is
tricky.
G
So
in
java
this
is
actually
in
the
like.
This
is
the
new
instrumentation
api,
where
other
languages
have
this
pop
con
common
contract
thing
where
they
keep
this
common
code
for
different
instrumentations.
G
So
the
side
effects
could
be
that
users
can
access
this
context
and
they
can
potentially
add
random
stuff
there.
They
can
overwhelm
and
overload
it.
They
can
maybe
even
end
spends
that
they
didn't
start
and
it's
like
so
far.
It
was
only
the
case
for
current
span
right
and
we
are
potentially
exposing
new
kinds
of
spend
to
expense
of
like
the
stack
of
dispense
to
this
issues.
G
Personally,
I
I
don't
think
it's
a
big
change
in
terms
of
what
we
expose,
but
there
could
be
risks.
Of
course,.
G
Now,
in
java
they
have
an
awesome
thing
called
instrumentation
api.
This
is
like
the
extra
library
which
provides
convenience
for
instrumentations,
and
I
I
wish
we
could
use
it
in
azure
sdk,
but
we
are
very
picky
about
dependencies
and
we
cannot
at
least
currently
take
dependency
on
this,
but
like
it
provides
like
it
is
basically
the
common
package,
all
instrumentation
that
exists
in
java
use.
F
Because
I
was
just
wondering
now
in
looking
at
this,
whether
this
could,
for
example,
be
implemented
in
some
kind
of
stateful
sampler.
F
The
basic
correlation
spans
are,
for
example,
that
the
http
can
expand.
Is
the
interest
yeah
sampled
out
if
there's
already
like
a
client
spend
somewhere
in,
like
the
parent
stack.
G
Yeah,
it
can
be
done
through
sampler.
It
feels
like
it's
not
that
the
component
that
was
designed
to
suppress
things
and
one
problem
with
the
dead
sampler
is
like
minimizing
the
performance
of
our
head.
But
by
the
time
you
sample
you
already
created
all
your
attributes
that
should
be
available
available,
pre-sampling
right
and
then
you
created
the
dictionary
you
created
allocated
a
bunch
of
strings
and
stuff
like
that,
and
if
you
just
want
to
say
okay,
I
already
done
all
this
job
to
to
drop
this
on
the
floor,
because
the
span
already
exists.
B
Yeah
yeah
I'm
curious
about
how
this
works
when
when
stuff
is,
has
been
sampled,
but
maybe
it's
it's
fine.
I
I
actually
feel
I
I
like
this.
I
kind
of
feel
like
this
part
shouldn't
be
in
the
instrumentation,
should
be
moved
from
that
java
instrumentation
api
down
into
the
lower
level
tracing
api
directly.
B
B
I
would
love
it
if
the
things
you
have
to
have
for
it
to
work
properly,
are
moved
down
into
the
the
core
api
and
are
and
in
the
process
kind
of
like
standardized
across
the
different
languages,
so
that
we
have
this
same
concept
of
you
know
of
a
essentially
of
a
span
type
which
we
banded
about.
B
Do
we
have
like
span
types
or
not,
but
adding
this
concept
of
a
span
type
and
the
ability
to
not
just
say
get
current
span
but
get
you
know,
get
span
type
one
of
these
things
and,
and
you
get
it
back
and
then
we
just
have
an
official
set
of
you
know
a
set
of
constants
like
that.
I
think
that
would
be
great
to
to
add
to
the
api
if
this
is
how
we
want
to
solve
this
stuff
and
then
the
the
instrumentation
helper
stuff
that
lives
on
top
of
it,
then
you
know
utilizes
utilizes.
B
E
But
I'm
I'm
a
little
wary
of
exposing
access
to
all
of
the
the
currently
active
spans
to
all
of
the
instrumentations,
but
I
do
definitely
agree
with
with
you
that
trying
to
push
this
down
towards
the
api
or
sdk
layer
feels
better.
I
wonder
if
a
good
compromise
might
be
to
put
it
into
the
sdk
and
require
that
when
a
span
is
created,
you
include
the
span
type
and
the
the
set
of
conventions
that
it
should
be
using
and
the
sdk
could
then
say.
E
G
B
E
Like
the
the
hard
part
about
that
is,
what
does
it
return
to
you
if
it's
supposed
to
omit
that
span
and
and
that
I'm
not
100
positive
on
right,
like
you
could
return
to
no
op
span,
but
you
want
to
still
be
able
to
propagate
the
the
prior
spam
context.
I
guess
that's.
The
the
non-recording
span
is
supposed
to
include
the
the
span
context
that
gets
propagated.
G
Yeah,
I
think
it's
worth
playing.
Maybe
I
can
play
with
it
and
come
up
with
some
solutions
here,
but
it's
a
great
feedback.
B
E
B
Yeah
well
think
about
a
scenario
where
a
framework
span
wants
to
it's
not
just
creating
a
spam,
but
you
want
to
add
attributes
as
you
go,
for
example,
things
like
routes
or
changing
the
span
name
and
like
all
that
other
junk
people
might
have
to
do.
I
don't
know
please
investigate
this.
I
I
would
love
to
figure
out
how
much
of
this
we
could
do
and
hide
but
yeah.
I
I
kind
of
smelled,
there's
going
to
be
something
a
little
tricky
there.
B
If,
when
you
say,
do
something
with
a
new
span
and
then
it
actually
gives
you
back
another,
or
maybe
it's
just
collapsing
these
after
the
fact
I
don't
know-
maybe
that's
that's
fine.
Maybe
the
sdk
is
keeping
track
of
the
fact
that
you
have
two
spans
and
it's
not
so
it
handles
so
so
you
have
like
you
still
and
I
think
that's
just
to
me.
The
only
tricky
bit
would
be
making
sure
all
this.
The
these
closures
are
all
closed
properly.
D
Hey
ted,
just
real
quick,
I
know
we're
at
time,
but
we
have
this
time
slot
to
be
apac
friendly,
and
you
know
australia,
new
zealand
friendly
and
we
have
the
monday
meetings
at
11
am
and
wondering
I
want
to
ask
here
for
those
folks
that
are
in
the
apac
time
zones,
if
you
would
prefer
that
meeting,
get
moved
to
like
a
thursday
apac
friendly
time
so
that
you
could
join.
D
So
like
that
was
supposed
to
be
for
instrumentation,
specifically
semantic
conventions,
discussions
just
trying
to
get
something
more
friendly
if
needed,.
C
Yeah
I
remember
when
this
meeting
was
initially
kind
of
proposed
and
the
other
semantic
convention
was
initially
proposed.
I
mentioned
that
oh
I'd
like
to
discuss
the
semantic
convention
and
I'm
from
australia
so
and
then
ted
kind
of
said.
Oh
we'll
just
come
to
this
meeting
and
I
think
if
this
meeting
we
can
just
discuss
the
semantic
invention
and
any
kind
of
aspects
of
the
spec,
then
I'm
happy,
but
if,
if
people
see
the
value
in
moving
that
meeting
to
kind
of
unify
it
all,
I
I'm
also
happy
so
yeah.
B
Another
way
of
framing
it,
I
think
what
michael's
saying
is
like.
Are
we
fine
with
one
meeting
a
week
or
do
we
feel
like
we
have
so
much
to
discuss
that
that
we
want
two
meetings
a
week
to
get
through
it
all,
and
I
I
personally
find
coming
to
two
meetings
a
week
that
might
be
too
much
for
for
other
people
or
you
know,
maybe.
D
We
start
with
one
then
ted.
Maybe
we
start
with
one
and
then
you
know
james
and
the
rest
of
the
folks
like
if
you
feel
like
we
need
to
add
another
one,
then
maybe
we
can
we'll
look
at
thursday
a
similar
time
potentially
and
then
now,
I'm
thinking
do
we
even
need
the
monday
meeting
so
I'll
ping
you
offline
to
see
if
we
can
right.
I.
B
I
think
we
should
the
the
tricky
bit
is
actually
that
we
have
people
in
european
time
zones
who
want
to
talk
about
http
and
other
conventions,
and
right
now
we
have
one
morning
meeting.
That's
focused
on
the
messaging
stuff
and
we're
not
really
talking
about
messaging
in
this
meeting.
So
I
think
just
the
only
tricky
bit
is.
I
think
we
have
people
potentially
in
incompatible
time
zones
that
that
want
to
be
discussing
the
same
subject,
which
is
fine
but
yeah,
that
monday
meeting
at
11,
30
or
whatever.
F
B
And
yeah,
we
are
at
time
that
was
a
really
fruitful
discussion.
Sorry
james.
We
couldn't
get
through
the
rest
of
your
feedback
directly
in
this
meeting.
But
if
people
have
feedback,
it
would
be
appreciated
if
they
post
it
to
the
issue.
C
Yeah,
no,
that's
completely
fine!
Please
do
yeah
leave
a
comment
on
the
issue
there.
I
know
some
people
had
some
more
thoughts
but
yeah
we
had
some
good
discussions.
So
that's
fine,
yeah,
yeah
cool.
B
Awesome:
okay:
well
see
you
on
slack
and
yeah
ludmila,
I'm
looking
forward
to
your
investigations.
It's
really
exciting
yeah.