►
From YouTube: OpenTracing Monthly Call - 2018-10-05
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
All
right
just
popping
the
agenda
dock
into
the
chat.
Please
register
yourself
as
attending
and
if
there's
anything
you'd
like
to
pop
onto
the
agenda,
please
do
it
also
be
good
to
do
a
little
open
tracing
review
for
the
first
half
so
I'll.
Try
to
edit
up
the
notes,
based
on
what
we're
discussing
so
feel,
free
to
add,
notes
and
comments
to
that
section
as
well.
A
A
A
What
do
we
think
we
could
do
better
on
and
where
do
we
think
we
should
be
focusing
our
time
and
energy
for
project
coming
forward
and
fall
so
kicking
it
off
with
good
stuff
sort
of
like
what's
been
going
well
and
I,
didn't
go
grab
a
bunch
of
metrics
and
make
pretty
graphs
for
this.
So
this
is
all
anecdotal
feelings
about
the
project.
A
If
people
do
have
data
that
is
interesting,
but
yeah
what's
been
going
well
for
my
perception,
there's
a
lot
more
open
tracing
users
and
awareness
of
the
project
and
awareness
of
distributed
tracing
in
general
seems
to
be
up
from
where
it
was
last
year.
I
don't
know,
other
people
have
a
similar
experience
of
that
front,
but
that's
been
my
experience
from
going
to
conferences
and
other
events.
A
B
C
A
D
Yeah
I
would
say
one
of
the
worst.
The
real
thing
on
his
friends
I've
seen
is
the
New
Relic
earnings
call
I
think
for
q3
or
sundown
at
rubber
butt.
You
know
the
founding
CEO
of
New
Relic
is
talking
about
distributed
tracing
and
their
earnings
call,
which
is
kind
of
bizarre
to
me,
and
it's
like
10
years
ago,
literally
unknown,
and
it
still
feels
to
me
like
it
should
be
kind
of
implementation
detail.
But
it's
become
a
marketing.
A
One
shift
I
feel
I
see
is
the
move
from
tracing
being
yeah,
this
sort
of
limited
tool
that
did
a
lot
of
sampling
and
you
were
only
using
it
to
get
certain
kinds
of
like
latency
averages
like
a
very
specific
tool
to
this
world,
where
people
just
want
all
of
their
logs,
they
want
all
of
their
event.
Data
contextualized
and
their
systems
are
distributed,
so
they
have
to
propagate
some
context
in
order
to
contextualize
the
data
and
so
tracing
via
context.
Propagation
is
becoming
more
and
more
central
to
just
observability
in
general.
A
F
Something
I'm
really
interested
in
is
features
and
analysis.
That's
on
the
tracing
data,
so
currently
a
Yeager's
primarily
Trace
focused,
and
we
have
some
dependency
graphs
and
everything,
but
I
think
there's
probably
a
wealth
of
exploration
that
we
can
do
on
trace
data
analysis
during
Amadeus
talk
the
guy
mentioned.
It
would
be
interesting
to
have
specs
around
the
data
structures,
not
just
the
collection,
but
maybe
something
that
supports
post
analysis.
F
G
F
A
A
But
if
you
want
to
say
propagate
something
for
the
duration
of
a
single
process
or
even
just
setting
a
tag
on
a
span
and
then
using
that
tag
later
like
right.
Now,
you
don't.
Oh,
that's
not
like
an
explicit
part
of
the
open
tracing
interface
and
people
have
written
some
middleware
things
on
top
of
open
tracing
to
do
this
stuff.
But
it's
not
like
a
thing:
we're
waving
our
hands
about
I'm
wondering
if
that
relates
to
the
sort
of
data
structure,
analysis
you
are
talking
about
I.
F
G
F
Was
more
like
post
analysis,
so
we
have
the
ager
query,
which
you
can
send
it
or
trace
ID
and
get
back
a
trace,
something
like
that
like
where
you
can.
Basically,
you
have
an
interface
that
allows
you
to
work
with
spans
and
traces
in
a
way:
that's
agnostic
to
the
underlying
I,
guess
installation,
so
yeah
girl,
ID
stuff.
So
then
people
can
build
analysis
on
top
of
the
tracing
data,
regardless
of
which
subsystem
it
is
or
which,
which
vendor
of
the
type
thing
so.
F
G
H
F
I
F
F
So
that
note
I
saw
talk
from
the
guy
who
I
guess
started
finagle
and
maybe
started
tooken
Marius,
something
he
wrote
a
like
a
data
processing
framework
and
they're
using
Zipkin
format
to
collect
traces
and
then
pop
it
into
x-ray,
and
then
they're
doing
a
bunch
of
analysis
on
that
data
to
determine
where
they
should
focus
their
developments
on
the
framework
like
where
the
I
guess,
low-hanging
fruits
are
and
also
high
impact
effort.
Sorry,
so
it's
not
really
like
it's
all
based
on
aggregations
yeah!
That's
just
another
example:
I
can.
A
One
place
where
we'd
like
to
see
more
standardization,
both
inside
open
tracing
and
like
across
the
industry,
is
not
just
the
data
format
in
terms
of
like
what
are
the
shape
of
the
protocol
buffers,
but
what
we
refer
to
as
sort
of
semantic
conventions
for
the
actual
keys
and
values,
and
that's
that's
more.
The
the
part
that
people
end
up
seeing
in
the
past
have
seen
as
useful,
like
it's
easy
to
write
a
parser
for
like
one
format
to
another.
But
if
all
the
data
is
different,
that's
where
it
gets
really
nasty.
A
If
you
can't,
if
you're
having
to
like
within
each
span,
maybe
there's
something
called
HTTP
code
or
something
called
HTTP
status
code
or
this
or
that
both
having
more
standards
in
that
field
than
we
currently
have
in
our
semantics
conventions
and
then
also
having
like
more
structured
data
in
our
actual
API
s.
For
entering
that
data
into
open
tracing
right.
Now,
you
sort
of
have
to
look
these
Keys
up
as
constants
and
kind
of
compose
all
of
these
values.
But
people
have
asked
for
things
in
the
past.
A
A
F
A
Are
organ
that
have
tracing
data
that
they
might
want
to
export
or
give
people
but
they're,
not
a
tracing
vendor,
so
some
infrastructure
company,
you
know
Twilio-
is
given
this
example
of
this.
But
anyone
who
has
customers
who
are
using
them
as
a
service
as
part
of
the
backend
is
going
to
start
caring
about
potentially
handing
out.
You
know
the
portion
of
the
trace
that
goes
into
their
system,
so
the
sort
of
like
standard
tracing
trace
contacts
headers
over
time
to
standardize
and
w3c.
A
This
data
format
thing
comes
up
there
in
the
sense
of
like
people
who
aren't
vendors
would
be
more
comfortable
if
there
was
some
standard
format
like
if
you
just
tell
them
here.
Give
us
put
your
data
in
this
format,
and
people
are
guaranteed
to
consume
it.
They
might
be
more
inclined
to
actually
go
through
the
efforts
producing
that
for
their
customers.
A
I
I
I
G
F
A
B
The
simplest
way
is
to
extend
set
tag
interface,
to
take
a
sort
of
a
factory
object
and
then
in
the
country
who
can
create
special
factors
like
HTTP
tags
thing,
and
then
it
will
have
like
with
status
code
with
URL,
blah,
blah
blah
and
then
boom.
So
tracers
don't
need
to
change,
but
they
can
just
ask
that
factory.
Ok,
explode
this
to
me
to
like
a
map
of
tags
automatically
and.
F
A
B
Yes,
because
we
really
like
our
API,
is
already
export
the
constants
for
tags
right,
saying,
like
HTTP
status
code
ester
that
can
account
a
constant
in
in
every
API.
So
instead
of
doing
Khan
just
create
an
object.
Saying
like
this
is
what
you
wanna
set.
If
you
do
an
HTTP
with
like
tight
fields
and
then
pass
that
object
to
the
tracer
and
trace,
will
knock.
F
A
A
B
F
B
B
A
H
H
A
Hey
I'm
gonna
put
you
down,
yes,
okay,
that
that
seems
definitely
useful
kind
of
next
step
thing
getting
back
to
going
through,
like
what
everything's
going
well.
I
also
feel
like
issue.
Do
PR
staleness
responsibility
I
feel
like
that's.
That's
gotten
better
at
the
project.
We
have
more
process
around
things.
So
the
part
where
you
know
there's
like
live
debate
and
responses
responses
happening
feel
better
to
me.
What
doesn't
feel
great
is
is
the
actually
like
closing
out
and
shipping
new
releases
like
there's
a
lag
between?
A
Oh,
we
should
do
this
and
then
debating
it,
and
then
it
seems
like
there's
a
lag
at
the
last
step
of
like
actually
getting
the
api's
at
the
door
and
sometimes
that's
a
good
thing,
because
we
want
to
create
room
for
debate
and
stuff
like
that.
Also
I
think
it's
just.
We
could
like
tighten
it
up
there
yeah
there.
D
Is
an
era
you
know
a
year
plus
ago,
when
we
moved
very
quickly
on
stuff,
like
that
and
I
think
that
ruffle
people's
feathers
and
now
we
don't
do
that
and
I
think
the
result
is
just
an
unnecessary
hit.
The
velocity
for
the
project
I
mean
I,
think
it's
great
to
have
time
for
open
debate,
but
once
that's
over
I
think
that
we've
got
to
just
move
forward.
D
I
mean
this
I
think
the
thing
you're
talking
about
with
you
know
a
type
struc
for
HTTP
calls,
I
mean
I,
I,
think
that's
been
discussed
for
years
and
no
one's
ever
thought
is
a
bad
idea.
It
definitely
is
a
little
than
a
hassle
to
get
over
the
line,
but
but
it's
not
that
big
of
a
deal
and
we
should
just
move
move
these
things
forward.
D
Note
that,
in
the
beginning
of
the
project,
I
think
when
students
you
have
to
cope
and
tracing
on,
it
was
very
really
a
project
for
CMC
yeah,
and
we
got
a
lot
of
attention.
I
think
the
attention
up
in
tracing
us
getting
was
actually
ahead
of
the
puck
in
terms
of
where
the
project
was
then
there's
a
period
where
I
think
it
was
about
it.
D
And
now
I
think
is
actually
other
way.
I
mean
it's
like
open
tracing,
because
it's
sort
of
a
standard
project
we've
intentionally
not
been
making
a
lot
of
changes.
There's
not
that
much
to
announce
about
the
core
API,
which
is
sort
of
a
t-shirt
away,
but
I
think
the
experience
of
velocity
that
I've
heard
from
folks
who
are
there,
for
instance,
and
also
and
other
just
sort
of
mixing
with
the
industry
type
of
situations.
It's
very
widely
deployed.
D
H
D
It's
not
perceived
it's
not
it's
not
documented
a
I,
don't
know
how
it's
perceived.
It's
not
document
and
I
think
that's
a
shift
from
how
things
were
like
a
year
ago
or
something
like
that
for
the
project.
I'm,
not
sure
if
it's
good
or
bad,
it's
just
I'm,
also
curious,
eager
people
here
of
the
different
experience
I've
been
I,
did
some
surprise
for
I,
see
it
coming
up.
B
So
we
did
the
ones
on
the
Jaeger
project.
We
open
a
ticket
called
a
survey
and
we
pinked
people
who
we
knew
were
like
active
on
questions,
etc
to
us
asking
them
to
write
some
short
summaries
like
what
company
you're
working
for.
What's
your
size
and
and
whether
like
why
using
Jaeger
what
issues
you
have.
There
are
some
like
response
to
that
and
there
will
be
in
like
if
we
could
do
something
like
that
for
pond
tracing
and
maybe
get
a
bit
more
data
of
who
is
actually
using
it
and
yeah.
A
I
think
this,
this
pivots
into
you
know
what
I
see
is
sort
of
the
main
thing
we
should
be
focusing
on
this
fall,
which
is
there
may
be
some
quarry
gie
changes
that
we
need,
especially
around
making
context
propagation,
more
useful
and
specifically
thinking
about
metrics
use
case
where
people
have
a
metric
system,
that's
separate
from
the
tracing
system
and
they're
trying
to
dimensionalize
the
metrics
in
some
way.
So
when
you
put
a
product
ID
into
your
tracer
that
you
know
propagates
that
product
ID
and
then
you
can,
you
know,
make
metrics
using
it.
It's.
A
I
feel
like
we
haven't,
put
much
effort
into
that,
and
so
that's
the
other
reason
why
the
project
feels
a
little
quiet
and
especially
if
we
don't
want
to
go
ripping
the
API
apart.
Every
three
months
like,
but
still
want
to
have
like
notable
velocity
for
the
project,
I
think
it
all
needs
to
be
in
that
area
of
just
building
value
for
yours,
so
they're
coming
and
using
open
tracings
like
regardless
of
what
they
think
of
the
API
they're
showing
up,
because
you
know
the
integrations
are
here.
A
For
example,
that's
the
reason
we've
seen
people
sample
bridge
their
homegrown
tracing
system
to
open
tracing
is
because,
like
they're
sick
of
rewriting
these
instrumentation
libraries-
and
they
just
want
to
use
ours,
so
I
think
just
focus
on
making
that
library
ecosystem
work
really
well.
Just
all
the
things
that
make
this
nicer
application
developers
should
be
a
focus.
I
know.
Other
people
have
thoughts
on
how
important
that
is,
and
also
like
what
like
brainstorming,
what
we
could
do,
what
what
they
think
actives
need
to
make
tracing
easier,
I.
D
Oh,
oh,
let
me
I'm
on
it
all
night
and
it's
these
in
this
particular
service
and
figure
out
what
instrumentation
is
out
there
and
plug
it
in
it's
a
little
bit
different
than
just
a
fully
fledged
agent
like
a
lot
dynamics
or
something
it's
more
like
a
discovery
process
followed
by
some
kind
of
automatic,
binding,
I.
Think
like
seeing
that,
through
to
its
natural
conclusion,
you'd
end
up
with
a
sort
of
meta
API
for
discovery
and
configuration
of
tracing
instrumentation
or
something
like
that,
but
with
some
registry
mechanisms
and
so
on
and
so
forth.
D
I'd
love
to
see
something
like
that.
I
think
that
the
active
experience
of
having
to
go
and
discover,
and
and
on
it,
configure
a
bunch
of
tracing
modules.
Even
if
you
don't
have
to
write
them,
it's
still
kind
of
a
hassle,
and
it's
very
very
much
in
line
with
the
goals
of
the
project
to
solve
that
problem.
D
A
I
And
there's
certainly
I
think
there's
like
text
acts
and
there
was
language
languages
and
frameworks
that
work
better
for
that
part
than
others.
Yeah
I
was
chatting
with
someone
about,
like
oh
as
you
Joe,
about
like
dum
dum,
no
tricks
and
like
agent-based,
no
js'
instrumentation,
which
could
either
be
super
hacky
or
like
super,
not
hacky.
Depending
on
how
you
do
it,
you
know
what
native
support
there
is
yeah,
but
then
your
altum
Utley,
you
know
you're
only
hitting
a
certain
amount
of
things
and
are
you?
Are
you
solving
like
the
core
problems?
I
It'd
be
really
cool.
I've
also
think
to
see
just
kind
of
better
framework
support
for
stuff,
like
c-sharp
I
know,
someone's
been
working
on
like
net
core
thinking
that
core
to
web
framework
instrumentation
with
asp.net,
maybe
be
worth
while
casting
around
and
seeing.
If
there's
desire
to
have
like
net
4
5
and
above
if
more
c-sharp
people
are
looking
to
get
into
the
project
or
start
using
open
tracing
seriously.
Yeah.
F
D
A
A
A
F
Maybe
biased
but
I
would
add,
like
a
third
opportunity,
which
is
the
post
analysis
phase
that
I
was
talking
about.
You
know,
first,
to
like
the
instrumentation,
especially
that's,
really
focused
on
collecting
information.
There
then
making
it
actionable
I
think
like
a
I,
could
have
a
wealth
of
possibility.
Yeah.
A
F
Like
if
we
like,
if
jäger
query
and
lights
up
and
whatever
or
whatever
other
systems,
would
want
a
kind
of
a
line
on
this,
if
we
had
endpoints
to
expose
traces
in
a
standardized
structure,
then
there
could
only
you
know
you.
We
would
only
need
like
one
implementation
of
transforming
it
to
like
a
service
dependency
graph
or
one
instrumentation
of
our
implementation
of
differentials,
etc.
Yeah
then
I
could
just
work
across
systems
and
actually
could
potentially
consumed
across
installations.
F
A
A
A
A
Just
so
people
are
aware
there
is
a
sort
of
summit
kind
of
discussion,
meeting
being
planned.
I,
don't
think
like
everyone
in
the
universe,
could
joke
for
this
meeting,
but
there's
at
least
going
to
be
some
high-level
people
from
open
census
and
open
tracing
projects
and
the
CNC
F
and
various
ecosystem
players
sitting
down
to
figure
out
how
these
projects
can
collaborate
better
with
each
other,
because
we
a
lot
of
the
individuals
we
all
collaborate,
just
in
general
on
various
tracing
things
and
then
there's
like
all
this
friction
around
these
two
projects.
A
Some
curious
to
hear
what
people
but
I,
guess
I'm
curious
about
two
things:
one:
what
do
people
find
painful
or
confusing
right
now
and
to
what?
What
is
the
world
people
to
see
in
relation
to
these
two
projects
like
if
we
could
collaborate
more
like?
What
did
people
have
concrete
visions
of
what
they
wish?
They'd
look
like
well.
A
Interesting
to
me
at
least
going
in
there
if
I'm
talking
to
people
from
census,
I
want
to
understand
what
their
goals
are,
but
it
would
be
helpful
to
me
to
understand
what
what
the
goals
are
for
people
who
are
involved
in
the
open
tracing
side.
I,
don't
want
to
be
like
we
passionately
care
about
X,
and
it
turns
out
like
no
one
cares
about
that.
There
was
just
me.
B
What
I
would
like
to
see
is
if
all
the
instrumentation
that
already
exists
for
pond
tracing
it
could
be
used
with
sensors
as
a
sort
of
the
instrumentation
of
the
tracer
right,
and
that
requires
effectively
a
common
API
between
the
two
project.
Even
if
that
API
that
needs
to
change
from
what
open
tracing
is
today
that
changed,
probably
not
going
to
be
super
significant
and
the
instrumentation
themselves
would
be
easy
to
adopt.
B
But
if
we,
if
we
could
drag
if
the
if
open
tracing
would
would
become
the
API
for
that,
then
it
would
be
the
outcome
that
I
hope
for
so
you're
saying
Robin
sensors
should
adopt
interesting
idea.
We
can
agree
on
a
new
API
where
basically
change
it,
but
I
think
one
of
the
things
like
open
standards
currently
bundles
the
API
with
instrumentation
and
governance,
and
how
that
API
even
evolved
right,
like
open
tracing,
has
way
more
governance
and
community
review
of
the
API.
Then
the
consensus
is
I.
A
Think
I'm
sure
these
are
things
that
are
changing.
I
know
they
seem
to
want
more
I
mean
I,
don't
want
to
speak
for
the
census,
people.
You
can
speak
to
themselves,
but
they
seem
like
they're
sort
of
trending
in
the
direction
of
trying
to
open
the
project
up.
It's
also
kind
of
why
this
seems
like
a
good
opportunity
talking
to
them,
so
you
trying
to
bring
Microsoft
know
the
people
in.
So
it's
not
just
a
internal
Google
project.
A
B
A
D
D
I
I
D
It's
positioned
as
a
separate
entity.
I
think
that's
really
in
court
notice
that
my
only
really
significant
temporal
concern
the
census
is
that
they
haven't
done
that
I
think
they
really
need
to
do
that
if
they
did
I
be
happy
to
see
that
no
country
Singh
move
closer
or
become
the
same
thing.
That's
the
thing
that
I
feel
personally
I
feel
really
strongly
about,
and
I
can
make
lots
of
in
the
week
cycle.
D
C
A
And
for
what
it's
worth,
I
think
it's
very
helpful
to
focus
on
goals,
not
implementation
details,
because
I
think
that
is
just
we
will
just
end
up
in
the
weeds
and
bike
shedding.
I
noticed
we
just
because
we're
nerds,
it's
like
red
meat,
if
we'd
start
talking
around
API
specifics
or
things
like
that,
it's
just
that'll
just
derail
the
conversation
yeah.
B
It's
a
valid
argument.
It's
just
not
an
argument
against
the
goal
of
Oakhaven
and
api
right,
but
but
that
discussion
will
happen
and
so
I
wonder
if
we
should
maybe
in
addition
to
goals
and
non
goal,
sections
have
something
like
in
that
regard,
but
it
starts
to
get
in
into
the
argumentative
territory.
B
A
I
I
think
that
I
think
you've
hit
the
nail
on
the
head
is
part
of
where
a
lot
of
this
friction
comes
from.
Is
the
you
know
many
people
feeling
the
elephant
where
all
of
these
things
holistically
are
important.
When
you
go
to
build
a
coherent
tracing
system,
that's
going
to
have
interoperability
between
multiple
services,
potentially
even
multiple
tracing
systems,
yada
yada,
you
need
you
need
all
of
these
pieces
right
like
you
need
a
wire
protocol.
You
need
some
kind
of
data
format,
you
need
and
analysis
systems.
You
need
api's.
A
Like
you
need
all
of
these
pieces
and
because
open
tracing
is
tried
to
say
like
well,
that's
like
too
much
we're
just
gonna
focus
on
the
API
problem.
That
leads
these
conversations
into
the
ground
where
we
say
we're
not
focusing
on
that
or
it
sounds
like
we're,
saying:
that's
not
important,
but
to
other
people.
They
think
that
is
really
important,
and
so
it
sounds
like
we're
disagreeing,
but
usually
what
we're
not
saying
is
that
we're
disagreeing
on
the
importance.
A
It's
just
that
we
chose
that
to
be
out
of
bounds
for
just
the
piece
of
the
puzzle
we
felt
like
we
wanted
to
work
on,
like
we
just
wanted
to
work
on
the
instrumentation
ecosystem
in
code,
basically
and
making
sure
software
actually
is
producing
this
information.
And
so
the
thing
we
cared
about
was
the
API
and
we
were
trying
to
keep
that
separate
from
these
other
problems.
It's
not
that
these
other
problems
aren't
important,
though,
and
there
is
something
to
be
said
about
having
one
organization
that
is
like
the
kitchen
sink.
A
Maybe
it's
well
factored,
but
there's
still
at
least
like
if
we're
talking
about
like
I,
don't
even
no
I.
Don't
want
to
call
it
open,
tracing
or
open
this
or
something
I.
Just
I
want
to
make
up
a
new
term,
but
we're
talking
about
just
like
distributed
bait
standard-issue
distributed
tracing
is
like
all
of
these
pieces.
Wait.
A
So
one
bigger
project,
that's
well
factored
I
think
would
be
better
than
having
a
bunch
of
little
projects
each
trying
to
focus
on
one
part
of
it
that
confuses
the
hell
out
of
users
like
they've,
got
to
come
to
open
tracing
the
API
and
then
go
to
Jaeger
to
get
the
implementation
and
then
like
the
w3c
to
get
the
wire
protocol
like
it
just
under
the
ITF
for
a
data
format
like
it.
Just
that's
like
really
confusing
to
people.
I've
noticed.
B
F
B
But
we
disguise
and
specifically
like
contention
between
no
penetration
and
senses
right
because
like
if
census
continues
to
get
in
steam
with
a
different
API,
then
everything
that
open
tracing
have
done
becomes
useless
right,
if,
like
people,
instead
start
and
then
people
now
have
to
decide.
Oh,
if
I'm
like
instrument
in
my
stuff
today
is
open,
tracer,
no
consensus,
yeah.
It's
super
hard
decision
like
how
do
you
have
to
bet
on
one
technology
to
win
effectively
right,
so
open
census.
F
Is
like
ABC
in
open,
tration
is
like
a
and
so
there's
some
contention
about
like
well
open
tracing,
not
prioritizing
or
valuing
B
and
C
that
I'm
saying
like.
If
we
want
to
align,
maybe
we
can
sort
of
make
a
paradigm
shift
and
make
it
known
that
you
know.
B
and
C
are
important
and
imperative
that
we
align
on
a
B
and
C,
not
to
say
yeah.
B
D
The
way
I
have
started
it
myself
is
sort
of
along
these
lines.
Is
that
there's
a
set
of
problems
that
involve
the
instrumentation
of
software
and
if
it's
a
really
significant
chunky
set
of
problems
and
then
there's
a
separate
set
of
problems
that
involve
everything
downstream
from
that
and
that
actually
can
be
subdivided
into
many
different
projects
potentially
and
the
tenth
point
is
well-taken
that
people
just
want
to
get
done
like
the
idea
that
they
have
to
research.
D
First,
a
lot
to
understand
and
comprehend
and
then
separately
make
decisions
about
each
one
of
these
slots
is
sort
of
overwhelming
I.
Think
for
people,
so
I've
recognized
that
I
think
from
a
long-term
maintenance
standpoint,
making
sure
that
regardless
of
marketing
and
how
things
are
weapons
are
named,
making
sure
that
there
is
some
clean
separation
between
those
two
things.
It's
like
it's
finally
important.
That's
the
thing
I'm
trying
to
say
more
than
anything,
a
mess
that
actually
goes
beyond
whether
or
not
to
merge
projects
or
not.
It's
it's
more
of
like
I
need
to
delivers.
D
The
products
that
I've
been
tracing
continues
to
exist.
Then
there's
automatically
some
separation
there,
but
but
I
think
from
an
engineering
standpoint
that
separation.
That's
the
thing
that
I'm
really
arguing
for
and
I
think
the
trouble
is.
You
have
a
project
that
does
a
B
and
C
it's
much
easier
to
kind
of
cheat
about
the
boundary
between
a
and
B
and
poke
holes
in
the
API,
for
the
conferred
convenience
and
and
for
like
short-term
trade-offs.
D
Basically,
that
assumes
certain
details
of
B
in
the
design
of
a,
and
that
actually
I
mean
I
generally
think
open
census
is
pretty
high
quality
software,
but
they've
done
that
in
a
number
of
places
and
I
do
think
it
limits
the
breed.
The
reusability
of
API
is
when
you,
when
you
make
those
decisions.
So
to
me,
like
the
trouble
with
expanding
open
trades
in
scope.
Is
that
there'd
be
a
similar
temptation
I
to
to
make
assumptions
about?
D
Propagation
have
literally
nothing
to
do
with
latency
analysis,
and
we
need
to
make
sure
that
those
things
we
don't
box,
those
out
I,
think
the
industry
will
be
better
if
you
don't
so
that
that's
been
my
argument
for
separating
the
thing
all
along
was
this
the
the
portability
not
just
across
analytical,
like
latency
and
latency,
an
alpha
system
support
ability
across
completely
different
applications
of
this
instrumentation.
That's
the
thing
that
I'm
really
adamant
about
so
you're
saying
stick
to
a
B
and
C
is
a
separate
problem.
There's
also.
D
More
there's
all
this
stuff,
like
the
agents
that
are
talking
about
all
this.
You
know
standardization
of
semantics,
there's
a
lot
of
stuff
like
a
itself.
We
really
just
built
the
ferment
of
it.
We
haven't
done
any
of
the
higher
level
primitives
that
really
make
this
a
nice
UI
for
a
programmer.
I,
don't
mean
a
plain
clip.
Do
I
bit
like
that
programming,
UI
or
D?
D
F
Interesting
getting
cake,
I,
don't
know,
I
think
there's
a
lot
of
value
in
B
and
C
and
because
the
implementation
is
decoupled,
it
kind
of
gives
us
like
a
that's
like
an
advantage
and
in
terms
of
warding
off
the
pitfalls.
You
mentioned
yeah,
there's
a
has
a
lot
more
depth
and
and
potential
change,
but
I,
don't
know
the
I
guess
the
downside
is
not
putting
any
intention
on
B
and
C
means
we're
also
not
influencing
it.
Yeah.
A
What
we
kind
of
art
is
just
I
mean,
and
that's
that's
what's
weird
about
this-
is
there's
like
discussion
about
how
and
we
should
wrap
up
in
a
minute
just
to
be
fair
to
everyone.
There
is
discussion
about.
Oh
you
know
we
don't.
We
can't
handle
like
the
breath
of
working
on
all
of
these
things,
but
the
thing
I
notice
is
it's
like
when
I
go
to
like
the
w3c
distributed
tracing
meeting,
and
we
bike
shed
about
what
the
wire
protocol
should
be
for
hours.
It's
like
more
or
less
the
same
people
you
know
like.
A
F
A
A
A
Won't
end
with
a
a
final
shill
for
the
people
who
are
left
on
the
call
and
maybe
are
not
aware
of
the
open-
trace-
sorry,
not
open
tracing,
but
the
observability
practitioners
summit.
This
is
a
single
day.
Talk
we're
calling
it
ops
for
short
that
it'll
be
a
single
day.
Talk
single
track
conference
in
front
of
cube
con.
I
can't
announce
the
speakers
yet
because
we're
still
finalizing
that,
but
I
am
very
excited
about
all
the
possible
speakers.
So
it's
going
to
be
a
pretty
rad
conference.