►
From YouTube: OpenTelemetry: Backwards Compatibility with... - Ben Sigelman, Bogdan Drutu & Spiros Xanthos
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
OpenTelemetry: Backwards Compatibility with OpenTracing and OpenCensus - Ben Sigelman, LightStep, Bogdan Drutu, Google & Spiros Xanthos, Omnition
This workshop will open with a 20-minute overview of the goals and structure of the new OpenTelemetry project, followed by two 30-minute presentations describing the backwards-compatibility strategies for both OpenTracing and OpenCensus end-users respectively.
https://sched.co/PTCU
A
Okay,
thanks
for
a
journey,
let's
get
started,
so
you
have
probably
attended
a
keynote
this
morning
where
we
announced
open
telemetry.
There
was
another
panel
discussion
earlier
today.
If
some
of
you
attended
that
one-
we're
gonna
repeat
the
first
section,
which
is
a
bit
of
the
background
in
the
introduction
to
open,
telemetry
sorry,
you're
gonna
have
to
go
through
that
again.
But
after
that
we're
gonna
talk.
We're
gonna,
give
like
specifics
about
how
the
backwards
compatibility
with
open
tracing
and
open
sensor
is
going
to
be
achieved.
A
So
I'm
gonna
do
the
first
section.
I'm
gonna
try
to
actually
maybe
give
some
more
background.
If
for
the
people
who
might
have
attended
the
previous
session
and
then
Ben
is
gonna,
talk
about
the
compatibility
with
open
tracing
and
Bogdan
is
gonna.
Discuss
the
open,
sensors
mobility,
I'm
Spiros
I'm,
not
Ben,
might
look
more
like
him
now.
I
am
the
founder
of
omniscient,
which
is
a
observability
company.
A
A
What,
before
we
go
into
that,
it's
probably
worth
revisiting
a
bit
water
gets
telemetry,
so
for
most
of
us,
telemetry
today
means
really
tracing
metrics
and
logs,
typically
or
in
the
world
we
live
today.
For
most
of
us,
these
are
collected
separately
and
analyze
kind
of
separately,
using
different
tools
for
both
collection
and
analysis.
Of
these
things,
there's
a
lot
of
value
in
correlating
these
different
artifacts
together,
but
that
has
not
been
effectively
done
so
far.
A
Obviously,
the
goals
of
both
urban
tracing
and
open
census
were
to
standardize
a
bit
on
some
of
these,
so
that
we
can
better
correlate
and
collect
all
of
this
data
and,
to
some
extent,
if
we
put
effort
as
developers,
let's
say,
to
instrument
our
obligations
or
to
instrument
open
source
frameworks.
We
should
be
able
to
use
this
data
for
whatever
purpose
we
want
with
whatever
backend
we
want.
A
Traditionally,
that
has
been
quite
difficult,
but
anyway,
that's
kind
of
the
goal
of
the
of
the
project.
To
make
that
very
easy
and
very
effective
by
being
able
to
collect
all
these
artifacts
and
correlate
them
using
whatever
button
of
choice
everyone
has
now,
in
addition
to
the
different
artifacts
effective.
A
When
we're
talking.
One
word
transmit
when
were
transferring
this
data
across
services
at
the
wire
format.
Are
the
users
actually
also
for
transmission
of
it?
So
it's
a
fairly
broad
area
and
in
the
past,
open
tracing
up
and
sensors
had
similar
goals
but
approach
the
problem
in
slightly
different
ways,
so
open
tracing
focused
on
tracing
specifically
and
try
to
solve
the
API
layer
problem
by
being
very
focused
support.
A
All
of
the
languages
had
a
lot
of
adoption
is
already
a
part
project
in
CNC,
F,
open
sense,
to
the
other
hand,
try
to
focus
on
actually
more
than
on
vertical,
specifically
tracing
a
matrix
and
started
working
on
lobs
recently
and
also
tried
to
focus
on
just
not
just
the
API,
but
also
the
implementation
infrastructure
for
the
collection
of
this
data
and
support
it.
Five
languages,
five
primary
languages
and
a
few
others
also
also
had
broad
adoption.
A
The
two
approaches
have
some
advantages
and
disadvantages:
I
think
when
it
comes
to
open
tracing,
in
particular
by
focusing
I
guess
just
on
tracing,
it
doesn't
solve
the
full
telemetry
problem.
So,
even
if
some
of
the
work
to
instrument
with
often
tracing
it
would
still
have
to
use
a
different
library
or
a
different
API
for
instrumenting
for
ethics
and
logs
open
census.
A
Try
to
solve
this
by
trying
to
do
both
at
the
same
time,
in
providing
correlation
good
correlation
across
them,
but
also
probably
had
the
coupling
if
an
open
census
was
maybe
too
tight
for
certain
use
cases.
It
made
it
a
bit
difficult
for
developers
will
say
to
choose
only
parts
that
they
wanted
to
use
for
the
product
or
the
project
and
also
probably
made
it
a
bit
more
difficult
for
vendors
and
others
who
wanted
to
contribute
or
use
parts
of
the
ecosystem.
A
A
So
anyway,
for
all
the
these
reasons,
I
guess
we
decided
to
come
together
and
merge
these
two
projects
into
one
both
open
tracing
and
open
sensors
are
gonna,
be
replaced
by
open
telemetry.
Maybe
the
best
way
to
think
about
this
is
that
open
telemetry.
It's
going
to
be
the
next
major
version
of
both
projects
and
we're
going
to
provide
full
compatibility
for
any
simulation
that
has
been
done
with
either
project
so
far,
and
this
is
the
primary
goal
of
this
talk
and
we're
gonna
talk
about
this
in
detail
and
open
sensors.
A
A
A
Open
tracing
and
open
sensors
try
to
cover
a
few
of
these
layers
in
different
ways,
but
really
the
entire
thing
is
in
the
scope
of
work
in
telemetry,
initially
initially
at
least
we'll
focus
on
tracing
new
metrics
and
we'll
cover
like,
but
we'll
cover
the
API
is
the
implementations
and
written
infrastructure
trying
to
become
let's
say,
the
standard
way
of
instrumenting
cloud
native
applications
and
collecting
that
data
out
of
those
applications
looking
at
each
one
of
these
layers.
So,
first
of
all,
there
is
the
instrumentation
API.
A
The
new
API
is
going
to
have
compatibility
with
both
the
existing
instrumentation
that
has
been
done
either
with
open
telemetry,
open,
placing
or
open
sensors,
VA
bridge
and
generally.
The
main
goal
of
this
is
to
rely
on
the
existing
adoption
of
these
projects
and
broaden
that
so
that,
hopefully,
in
the
future,
all
major
open
source
frameworks
and
libraries
are
going
to
be
instrumented.
We
form
a
telemetry
so
that
as
application
developers,
what
I'm
gonna
be
able
to
get
that
for
free
and
not
have
to
worry
too
much
about
it.
A
As
I
mentioned,
the
there
are
going
to
be
canonical
or
C
standard
implementations
for
each
one
of
these
libraries
for
every
major
language.
Hopefully
that's
what
most
of
us
would
thought
would
decide
to
use
and
those
libraries
are
gonna,
try
to
use
or
rely
on
standards
as
much
as
possible.
For
example,
we're
using
the
w3c
trace
context,
call
it
for
variation
standard
by
default,
that's
already
used
in
open
census,
and
it's
going
to
be
used
in
open
telemetry
as
well.
A
There
is
an
open,
wide
format
for
pricing,
there's
no
standard
for
that
yet,
but
we're
gonna
be
using
an
open
wire
format
that
others
can
adopt
for
tracing
medicine
logs
and
also
the
implementation
is
Vendrell
vendor-neutral
completely
vendor
neutral.
By
default.
The
client
libraries
will
support
exporters
for
popular
open
source
buttons,
like
Jaeger
Zipkin,
for
traces
from
history
metrics,
but
obviously
anybody
can
contribute
any
exporter.
They
want
for
open
source
or
proprietary
back
end.
One
important
thing
to
share
here
is
that
the
the
client
libraries
are
not
starting
from
scratch
completely.
A
A
A
Let's
say
that
the
generate
this
telemetry,
so
if
your
back-end
King
it
lies
all
of
those,
you
should
be
able
to
correlate
across
all
of
them.
Also,
it
has
several
other
advantages.
I'll
give
a
couple
examples
like
for
standalone
applications
that
have
already
been
is
tremendous.
Let's
say
good,
open
telemetry,
you
don't
even
need
to
recompile
them
again.
You
can
send
that
data
to
the
agent
and
from
the
aides,
and
you
can
choose
what
back-end
to
forward
it
to.
A
Also,
the
the
agent
has
receivers
for
really
all
the
popular
kind
of
libraries,
for
example,
you
can
have.
Let's
say
you
have
an
existing
application
that
has
been
instrumented
with
open
tracing
and
is
using
the
Jaeger
client
library,
the
that
can
stay
there
and
the
agent
can
accept
that
instrumentation
and,
let's
see
how
maybe
some
new
services
that
have
been
instrumented
will
open
telemetry.
The
agent
can
measure
all
of
that
together
and
export
full
traces
22
to
the
backend
of
your
choice
and
with
that
we'll
jump
to
the
goals.
A
Yes,
so
the
idea
is
that
open
kilometer
is
gonna,
replace
both
replace
both
projects,
but
any
instrumentation
that
already
exists
or
somebody's
doing
today
will
be
let's
say:
open
telemetry
is
gonna,
offer
backwards,
compatibility
effectively.
What's
going
to
happen,
is
these
projects
are
going
to
stay
around
for
at
least
a
couple
more
years?
But
not
no
new
active
development
is
going
to
happen
in
those
after
the
next
few
months.
A
So,
for
I
can
speak
a
bit
about
open
census,
the
goal
was
not
to
support
few
languages.
It
was
just
that,
let's
say
the
mature
languages
were
fewer
than
the
case
of
open
tracing,
because
I
mean
there
is
an
actual
implementation.
It's
a
bit
more
work
to
do
that,
so
I
think
going
forward.
The
goal
is
to
support
all
the
popular
languages.
I
think
the
old
one
has
9
languages,
but
they're
gonna
be
available.
B
Yeah
thanks
a
lot,
and
one
other
thing
I
would
add
is
that
when
you
talk
about
open
tracing
or
open
census
code,
there's
the
code
in
the
core
project
itself
and
then
there's
all
of
the
instrumentation.
That's
in
the
world.the,
the
code
and
the
core
project
will
be
kind
of
put
into
read-only
mode,
ideally
by
the
end
of
this
calendar
year,
and
we
expect
that
they're
all
still
be
additional
instrumentation
being
written
for
some
period
of
time
until
people
have
migrated
over.
B
So
it's
important
to
draw
the
distinction
between
instrumentation
code
and
then
the
core
code.
I
think
the
core
code
is
the
stuff
that
we'd
like
to
stop
adding
additional
features
to
by
the
end
of
the
year.
The
elephant
in
the
room
for
this
project
is
absolutely
the
fact
that
you
know.
There's
the
xkcd
comic
where
you
have
14
standards
and
you
want
to
create
a
single,
unified
way
to
access
them,
and
so
you
create
a
15
standard.
That's
what
we're
trying
to
avoid
the.
B
Hopefully,
this
will
be
just
as
slight,
as
was
some
sort
of
formatting
issue,
but
we'd
expect
that
by
September
we
have
what
we
would
call
parity
across
all
the
languages
that
are
supported
by
open
tracing
and
open
census.
Right
now,
some
of
those
languages
are
more
mature
than
others,
so
I
think
getting
to
parity
for
a
language
that
doesn't
have
a
mature
implementation
is
easier
than
getting
to
parity
for,
say,
Java
or
Python,
where
there's
a
much
more
mature
ecosystem
around
it.
B
I
like,
for
instance,
there's
an
open
tracing
library
and
rust,
that's
actually
very
young,
and
getting
to
parity
with
that
would
be
pretty
easy.
Cuz.
It's
just
getting
started
and
then
by
November
we'd,
like
both
open
tracing
and
open
census,
to
be
in
this
kind
of
read-only
mode,
where
we're
not
making
changes
to
the
core
of
the
projects
anymore,
but
we're
still
supporting
them
for
two
years
after
that
date.
B
A
long-term
project,
of
course,
long
term
goals
to
have
one
project
and
to
have
this
broad
surface
area
and
lose
coupling
I
also
want
to
mention
the
governance
structure
for
open
telemetry
has
been
modeled
pretty
explicitly
after
the
kubernetes
governance.
We
have
nine
seats
in
the
governing
committee.
B
There
are
limitations
on
how
many
seats
can
be
occupied
by
a
single
vendor
or
project.
There
are
limitations
on
how
long
someone
can
be
in
one
of
those
seats,
etc,
etc,
which
should
allow
for
the
project
to
maintain
the
common
interests
that
end-users
and
and
won't
be
dominated
by
any
particular
vendor
or
swayed
in
that
way,
which
I
think
is
also
like
a
nice
thing
that
we
had
sort
of
informally
and
open
tracing
an
open
census.
B
But
it
wasn't
as
explicit
it's
going
to
be
very
difficult
in
open
telemetry
to
do
anything
but
like
operate
in
a
in
a
truly
kind
of
portable
cross,
vender
way
just
based
on
the
governance
structure.
Oh
yeah
I
just
ruined
these
slides
by
saying
you
can
look
this
up
online.
If
you
want
an
open
telemetry,
if
you
want
to
look
at
how
community
membership
works
and
how
governance
works,
but
there
are
three
levels
of
membership
as
contributors
to
the
core
project.
B
Anyone
here
is
welcome
to
become
a
contributor
it'd,
be
great
to
have
more
people
involved,
we're
trying
to
do
a
lot
of
work
very
quickly
and
and
it's
a
it's-
it's
unusual
to
be
able
to
join
a
project.
That's
going
to
move
this
quickly
at
this
stage
and
it
should
be
pretty
fun
if,
especially,
if
you
are
familiar
with
the
language,
that's
not
Java
Python
or
go
where
we
have
a
lot
of
depth.
There's
a
lot
of
work
to
be
done
and
would
be
great
to
have
more
hands
on
deck.
B
So
this
is
kind
of
an
advertisement
as
well.
The
governance
I
already
referred
to
this
a
little
bit.
We
won't
have
any
benevolent
dictators
in
this
project.
It's
going
to
they're
staggered
elections
and
people
will
be
flowing
through
the
governance
relatively
quickly
and
I
think
that
it
should
serve
the
long-term
interests
of
this
entire
ecosystem.
Well,
so
I
think
that
was
sort
of
formally
the
end
of
this
overview.
B
Okay,
great
so
I've
wrote
these
slides
with
the
intention
of
being
clear,
but
if
this
is
not
clear
enough,
just
you
know
ask
questions
or
whatever
here's
this
slide
again.
Open
tracing
footprint
is
tracing
api's,
and
so
it's
kind
of
right
there,
the
rest
of
it.
There
are
things
and
open
tracing
that
touch
on
other
pieces
of
this.
There
are
people
who
have
written.
You
know
open
open-source
implementations
of
open
tracing
formats,
etc,
etc,
but
the
core
of
the
project
is
really
very
narrowly
restricted
to
this.
B
So
part
of
the
effort
here
is
to
broaden
the
surface
area.
The
broadening
is
easy
in
that
we're
just
adding
more
things
and
that
doesn't
create
any
compatibility
issues.
The
compatibility
discussion
is
really
focused
on
things
and
this
slice
of
the
matrix,
because
this
is
where
open
tracing
has
been
so
focused.
B
The
best
place
to
start
is
probably
this
slide,
which
is
taken
totally
unmodified
from
a
presentation
last
year
that
someone,
a
friend
of
mine,
did
on
open
tracing,
so
the
basic
concepts.
Of
course
you
have
the
full
transaction
trace
which
goes
across
services,
it's
composed
of
spans,
which
are
these
time
segments.
B
Typically,
you
have
at
least
one
span
per
RPC
call
and
then
hopefully,
a
few
more
to
help,
explain,
explain
aspects
of
a
request
that
can
greatly
affect
the
critical
path
you
have
the
span
context
which
has
trace
identifier
span
identifier
and
some
other
stuff
in
it.
Open
tracing
did
recent
relatively
recently
add
trace
ID
and
span
ID
as
formal
parts
of
open
tracing,
but
not
nearly
to
the
level
of
detail
that
open
census
or
open
telemetry
do
adopting
the
w3c
spec.
That's
just
kind
of
coming
to
maturity.
B
Around
now,
I
wanted
to
address
where
there
are
changes
and
open
tracing
again,
there's
a
compatibility
bridge.
If
you
speak
Java,
you
can
look
at
it.
Right
now
is
Carlos
here,
I,
don't
see
it.
Carlos
Alberto
wrote
a
bridge
from
oak
and
tracing
an
open
tracing
tracer
to
open
telemetry,
and
you
can
look
at
how
all
the
stuff
is
being
addressed,
but
there
are
some
interesting
changes
between
the
open
tracing
API
and
the
tracing
API
from
open
telemetry.
B
So
here
they
are
so
the
open,
telemetry
span
context
is
which
is
the
you
know,
the
class
that's
responsible
for
reifying
the
trace
ID
and
the
span.
Id
sampled
bits
that
sort
of
stuff
it's
highly
non-abstract,
so
anokhin
tracing.
It
was
a
pure
interface
in
in
open,
telemetry
and
Java.
For
instance,
it's
a
final
class
like
you
literally
can't
extend
it,
and
so
we
have
a
much
more
opinionated
stance
about
the
sorts
of
trace
and
span
IDs
that
we
expect
people
to
have.
B
I
was
responsible
for
the
design
of
the
original
open,
tracing,
API
and
I
wanted
to
remain
open
to
other
models.
Those
models
just
have
not
appeared
in
production,
I
think
everyone's
using
tracing
systems
or
ATMs
that
have
something
like
a
span.
So
this
model
has
been
sufficient,
I
think
in
a
few
years,
or
something
like
that
down
the
line.
You
can
imagine
something
more
general
happening,
but
it's
not
not
happening
now,
so
so
the
span
context
is
much
more
concrete.
B
This
actually
has
a
lot
of
benefits
in
that
you
can,
if
you
want
to
integrate
with
a
logging
system
or
something
you
can
be
guaranteed
that
any
open,
telemetry
implementation
has
to
provide
a
trace,
ID
and
has
to
provide
a
span
ID.
This
has
been
a
feature.
Requests
no
can
trace
in
really
since
the
dawn
of
time
for
open
tracing,
and
that
will
now
be
a
trivial
thing
and
doesn't
involve
any
kind
of
weird
class
cast
exception
that
you
have
to
worry
about
or
anything
like
that.
B
It's
just
part
of
the
interface,
the
baggage
featuring
open
tracing,
that's
a
key
value
pair
that
propagates
with
the
request.
That's
still
there's
an
analogous
concept
in
the
w3c
trades
context
called
correlation
context,
and
so
you
can
still
do
something
similar,
but
it's
not
called
baggage
anymore.
You
also
see
a
more
robust
treatment
of
propagation
of
a
context
within
a
process.
This
is
just
necessarily
various
by
language:
I
can
go,
there's
the
go
context,
which
is
just
part
of
the
idiom
of
programming
ago
in
Java.
B
You
have
a
much
more
heterogeneous
way
of
dealing
with
it,
but
in
every
language
we
want
to
have
a
clear
runtime
answer
to
context
propagation
for
open,
telemetry
users,
and
so
what
that
means
in
plain
English
is
that
statically
you
should
always
be
able
to
access
the
current
distributed
context.
You
shouldn't
have
to
do
anything
funny
to
get
the
distributed
context,
because
either
going
to
be
a
local
variable
or
you
can
access
it
by
a
thread
local
or
whatever.
The
is
propria
for
the
language.
B
Also
open
tracing
did
support
like
a
standard
string
representation
of
whether
there
is
sampling
or
not,
but
it
didn't
have
special
methods
around
whether
the
current
requests
is
sampled
or
not.
Sampled,
open
telemetry
is
banned.
Context
does
put
that
on
the
spam
context.
I
mentioned
this
because
it's
an
important
optimization
for
many
people,
if
you're
not
in
a
sample
trace,
you
can
avoid
extra
work
to
you
know,
create
tag,
values
and
things
like
that.
So
so
that's
something
that
we've
also
added
to
the
open
telemetry
side
for
the
span
itself.
B
So
this
is
the
thing
that
has
a
start
time
and
end
time
and
a
bunch
of
key
value
pairs
and
timestamp
key
value
pairs
on
it,
they're
a
bunch
of
naming
changes,
so
an
open
trace
and
we
called
them
tags
and
open
telemetry.
We
call
them
attributes
and
open
tracing.
We
call
them
quote
unquote
logs,
which
generated
a
huge
amount
of
fury
and
I
regret
that
choice
of
names.
B
So
in
order
to
avoid
the
fury
this
time,
we're
calling
it
events,
but
conceptually
they're,
very,
very
similar,
open
tracing
had
a
notion
of
references
which
is
a
way
of
saying
that
this
span
descended
from
another
span,
which
was
its
parent
conceptually.
What
we're
doing
in
open,
telemetry
is
is
very
similar,
but
not
exactly
the
same,
and
you
know
you
can
look
at
the
API
if
you
want
yourself
in
Java
for
an
example
of
how
this
will
work,
but
there's
a
notion
that
every
span
has
zero
or
one
parents.
B
If
you
have
one
parent,
you
can
say
what
kind
of
parent
it
is
by
talking
about
client
relationships,
server
relationships
and
then
for
things
like
Kafka,
etc.
There's
a
notion
of
a
producer
and
a
consumer.
This
will
allow
for
downstream
UIs
and
analytical
tools
to
correctly
analyze
the
that
kind
of
causal
relationships
between
the
different
spans.
So
in
that
sense,
it's
very
similar
to
references.
There
is
something
that
was
not
an
open
tracing
at
all,
which
we've
added
from
open
census,
which
is
the
idea
of
a
linked
span.
B
So
the
idea
is,
if
you
have
let's
say,
you're-
writing
some
kind
of
shared
service
that
has
to
batch
request
and
then
write
them
off
to
some
database.
All
of
the
batches
require
in
a
single
batch
have
a
shared
fate
in
terms
of
latency.
So
if
you
make
100
requests,
they
all
get
bashed
and
then
that
write
to
your
database
takes
a
long
time.
All
100
requests
will
be
slow
and
the
members
of
the
batch
have
a
relationship
with
each
other.
B
It's
important
to
have
that
represented
in
the
tracing
somehow
so
that
you
can
figure
out
what
went
on
open.
Telemetry
has
this
idea
of
a
linked
span
which
can
be
used
for
many
things,
but
I
think
the
the
usual
use
case
we
talk
about
is
batching
and
other
forms
of
aggregation
between
different
transactions,
so
that
is
now
a
part
of
the
open,
telemetry,
API
and
open
tracing
allows
for
the
explicit
set
of
a
start
and
finish
time
on
a
span.
B
It's
not
a
terribly
difficult
thing
to
support,
but
we
don't
want
to
create
that
surface
area
when
we
think
the
use
case
would
be
better
served
by
directly
consuming
the
data
formats
of
open
telemetry
I
realized
that
when
I'm
doing
this
talk,
this
is
like
incredibly
dense.
I,
don't
know
how
anyone
is
paying
attention
to
this
and
absorbing
any
of
it.
Are
there
questions
on
this
slide
or
the
previous
one
just
to
take
them
in
kind.
B
You
people
are
either
lying
or
very
smart.
Probably
it's
very
smart.
Ok
I'm
impressed
I'm
really
impressed
and
then
for
the
tracer
itself.
It's
not
that
different.
They
both
provide
access
to
current
span.
The
you
know
the
language
changes
a
little
bit.
It's
actually
easier
to
open
telemetry
than
it
wasn't
open,
tracing
and
there's
also,
it's
really
cool
concept
of
a
resource.
So
this
is
the
idea
that
you
want
to
say.
Basically,
you
know
TLDR.
This
tracer
is
part
of
this
process,
and
this
process
uses
a
certain
amount
of
CPU
in
memory.
B
We'd
like
to
be
able
to
get
that
data,
and
in
the
earlier
session
this
morning
someone
is
asking
a
great
question
about
how
we're
going
to
do
correlations
between
different
streams
of
you
know,
metrics
and
traces
and
stuff.
This
resource
idea
is
really
important
there,
where
it's
going
to
be
possible
in
a
portable
way
to
say
that
the
CPU
and
memory
from
your
process
will
be
easier
if
it'll
be
easy
to
reflect
that
in
the
traces
regardless
of
which
vendor
you
use
for
tracing
I.
B
Think
that's
really
important
in
that
a
lot
of
latency
issues
and
reliability.
Issues
have
to
do
with
the
resource
itself
being
overloaded
and
I
think
that
this
will
make
it
much
easier
to
spot
that
sort
of
thing
and
it's
the
kind
of
minor
thing
we
had
this
idea
of
closing
a
tracer
in
open,
telemetry
I.
Don't
think
that
we
kind
of
regret
adding
that
to
the
api.
It
will
keep
a
flush
which
is
important
for
tracing
I'm.
B
Sorry
for
testing,
but
I
think
we'll
probably
get
rid
of
the
clothes
which
was
only
being
used
for
testing
anyway,
so
just
to
dig
into
Java
a
little
bit.
I
tried
not
to
talk
too
much
about
Java,
but
Java
is
where
we're
doing
the
prototyping
I
think
we
feel,
like
that's
the
most
robust
community,
for
both
open
tracing
and
opened
census,
then
probably
an
Enterprise
in
general,
and
so
we
want
to
make
sure
that
that's
the
place
that
we
use
to.
We
want
to
get
all
the
compatibility
working
there
at
first.
B
You
definitely
should
look
at
this.
If
you
want,
especially
if
you
speak
open
tracing,
you
can
go
and
look
at
the
shim
that
we've
written
and
verify
that
it
actually
meets
your
requirements
and
everything
I
think
it
will.
But
the
guts
of
it
is
the
following.
So
the
way
that
the
compatibility
will
really
work
for
open
tracing
users
and,
of
course
this
isn't
written
in
Java,
but
the
same
thing
will
be
true
for
other
languages.
B
You
presently
have
some
line
of
code
where
you're
installing
an
open
tracing
tracer,
which
is
this
thing
up
here
in
your
application.
So
what
you'll
be
doing
is
replacing
that
with
this
tracer
shim,
that
itself
takes
an
open,
telemetry
tracer
as
an
argument,
if
you
add
this,
in
replacement
of
your
open
tracing
initialization
you'll,
be
able
to
mix
open
tracing,
open
census
and
open
telemetry
instrumentation
in
your
single
java
process,
and
it
will
all
just
work
where
we'll
be
doing
similar
things
with
other
languages.
This
is
basically,
you
know.
B
We
said
in
the
he
note
I
think
that
we
think
of
open
telemetry,
as
the
next
major
version
have
open
tracing.
That's
really
true.
We
had
a
major
version.
Well,
I,
guess:
technically
it
wasn't
because
we're
still
in
the
0
dot
release
chain,
but
we
had
a
breaking
change
and
open
tracing
about
a
year
ago
and
we
released
a
similar
shim
to
do
that
and
it
works
well.
So
we're
treating
this
the
same
way.
B
This
is
really
a
version
upgrade
for
open
tracing
where
we're
getting
a
bunch
of
improvements
and
we'll
use
this
sort
of
shim
approach.
But
it's
nice,
because
this
is
the
only
code
change
you'll
have
to
make,
assuming
you
believe
everything
else,
I'm
saying
and
and
that
that's
the
way
that
we've
been
designing
these
api's
and
for
what
it's
worth,
we
won't
qualify
an
open,
telemetry
API
until
we
were
able
to
make
this
work
in
any
language.
It's
part
of
the
requirement
for
the
open,
telemetry
API
is
other
languages.
B
Our
immediate
priorities
are
written
on
this
slide.
We're
expecting
to
have
something
that
you
can
validate
by
September,
I
I.
Think
I
wrote
the
slide
on
the
airplane
that
doesn't
make
any
sense
already
already
working
on
several
begins
soon.
I,
don't
know
what
that
means,
but
we're
starting
many
of
you
soon.
B
So,
that's
probably
what
I
meant
we're
also
I
think
this
is
addressing
your
question
earlier
about
language
support,
so
this
set
of
languages
is
supported
in
open
tracing
with
the
possible
exception
of
straight
C,
which
the
youth
for
that
I
think
was
almost
always
something
that
would
have
been
better
suited
by
just
writing
raw
data.
But
with
the
rest
of
these,
we
expect
to
you
know,
basically
go
through
the
fall.
B
The
steps
that
are
on
this
slide,
the
one
thing
I
would
mention
about
open
census-
is
that
they've
made
an
effort
to
write,
really
high
throughput
high
quality
implementations
of
of
the
API
and
open
census.
B.
We
want
to
write
correct
reference
implementations
as
soon
as
we
can
for
these
languages.
I
I
think
it'll
be
interesting
for
us
to
figure
out.
We
have
this
slide.
We
keep
on
showing
of
I'm
well
the
one
with
the
the
matrix
of
rows
and
columns.
B
It's
probably
the
case
that
we'll
end
up
at
a
mature
place,
the
API
slightly
before
we
have
mature
performant
implementation
and
when
people
will
choose
to
adopt
these
things,
it's
a
little
bit.
Tbd
I.
Think
if
you
want
to
wait
until
the
reference
implementation
is
there
that
will
probably
extend
through
into
November
or
December
for
a
lot
of
these
languages,
but
but
the
open
tracing
part,
which
is
just
the
API,
should
be
ready
earlier.
B
All
we
really
want
to
do
is
verify
that
we
will
be
be
able
to
provide
a
high-quality
reference
implementation
and
we
can
get
there
once
we've
gotten
this
simple
correct
version
done
so
yeah.
None
of
these
things
will
be
considered
done
until
we
have
demonstrated
evidence
we'll
be
able
to
create
a
correct
bridge
from
open
tracing
and
open
census,
and
this
is
obviously
a
huge
amount
of
work.
B
I
just
wanted
to
say
in
terms
of
the
philosophical
alignment:
I
I
did
a
lot
of
talks
to
open
tracing
and
my
biggest
regret
about
it.
I
was
kind
of
right,
but
then
I
didn't
take.
My
own
advice
was
that
that
the
instrumentation
should
describe
the
software,
not
where
it's
going
and
the
troubles
that
we
didn't
do
that
with
I've
been
tracing
like.
If
you
have
a
request,
all
you
should
be
saying
is:
like
I
just
had
a
request.
B
It
took
this
long,
you
shouldn't
it
shouldn't,
be
a
tracing,
API
I
should
just
say
that
happened,
and
then,
if
you
want
to
use
that
for
metrics
or
logs,
you
should
be
able
to
do
that
too
and
I.
Think
one
of
the
complaints
we
had
with
open
tracing
was
that
people
were
adding
open,
tracing,
instrumentation
and
then
also
adding
I,
don't
know
prometheus
instrumentation
and
also
putting
stuff
into
ELQ.
B
This
approach
should
actually
get
closer
to
the
philosophical
orientation
that
we
had
for
open
tracing
originally,
which
is
that
you
just
describe
your
software
and
then
the
telemetry
data
flows.
Out
of
that.
So
this
is
actually
ironically.
The
open,
telemetry
charter
is
probably
closer
to
the
philosophy
we
were
trying
to
espouse
as
I've
been
tracing.
Then
open
tracing
is,
but
you
know
you
always
get
a
second
chance
or
something
yeah.
So
you
know
we'll
be
broadening
what
you
can
get
it'll
be
great
and
I've
done.
So
any
questions
for
the
I've
been
tracing
part.
B
That's
a
really
good
question:
I,
like
the
thought
process
behind
it.
So
just
a
summarized
to
the
recording:
do
we
plan
to
add
some
kind
of
convention
whereby
people
can
tag
where
the
data
is
going
to
be
used
and
also
kind
of
for
how
long
I
guess
like
when
you
can
remove
it?
That
sort
of
thing
is
that
the
idea.
C
B
That's
a
good
question:
when
I
worked
at
Google,
we
had
a
compilation
error
if
you
didn't
had
a
human-readable
description
of
what
a
given
metric
actually
was
for
I,
like
the
idea
of
also
adding
an
expiration
date
like
if
you
don't
react.
This
thing
you
it's
by
default,
removable
or
something
like
that
to
be
honest,
that
we
haven't
actually
created
those
sorts
of
requirements
at
the
compilation,
level
for
open
tracing
or
open
census
and
I,
don't
think.
We've
talked
about
it
for
open
telemetry,
but
I
definitely
understand.
B
We
were
coming
from
I
think
there
are
a
lot
of
pieces
of
telemetry
data
that
are
out
there
in
the
world
and
no
one
knows
if
someone
needs
to
more
who
needs
them,
but
no
one
feels
comfortable
deleting
them.
We
actually
did
do
a
study
when
I
was
at
Google,
where
we
analyzed
their
long
term
time
series
store
to
see
which
data
was
being
accessed
by
an
actual
human
being.
So
you
could
tell
if
the
reader
was
like
a
MapReduce
or
an
actual
human
being,
and
they
found
I'm
gonna
make
it
the
number
wrong.
B
But
it
was
like
way
under
a
tenth
of
a
percent
of
the
data,
was
ever
read
by
a
person
ever
and
so
they're
like
oh.
This
is
very
sensible,
we'll
just
make
a
policy
that,
after
a
month,
we'll
just
delete
it
unless
it's
in
this
white
list
and
people
freaked
out
absolutely
freaked
out,
because
how
could
you
ever
delete
this
data?
What
if
we
needed
some
time
so
people
do
feel
a
lot
of
anxiety
about
removing
telemetry.
B
D
Yeah
I'm
gonna,
present
from
the
open
census
perspective,
what
we're
gonna
do
for
backwards
compatibility
and
how
we
would
support
our
current
users.
What
we
will
do
is
gonna
be
a
bit
different
than
open
tracing.
We
probably
are
gonna,
do
a
more
aggressive
transition
of
our
users,
main
reason
being
the
fact
that
we
have
a
pretty
large
base
not
necessary
for
instrumentation,
but
because
of
the
implementations
and
all
the
exporters
that
we
support
and
being
in
a
state
where
we
have
duplicate
code
for
us
we'll
be
kind
of
unacceptable.
D
There
are
clearly
some
differences
between
open,
telemetry
and
open
census,
the
main
one
being
the
fact
that
we
learn
from
from
open
tracing
that
having
a
clear
API
is
very
important
and
having
this
separation
between
API
implementation
helps
a
lot
of
the
vendors
and
a
lot
of
the
parties
to
trust
more
the
project.
One
of
the
code
that
I
remember
from
Amazon
x-ray
was
like
what
what
if
Google
starts
to
go
crazy
with
their
implementation,
and
we
want
to.
D
We
want
to
have
our
own
implementation
and
just
move
forward
just
with
only
the
API
and
I.
Think
I
think
it's
very
important
that
we
offered
this
ability
for,
for
others
to
completely
implemented
a
p.I
if
they
want.
But
I
also
believe
that
having
a
standard
implementation
in
places
is
the
right
thing
to
do
the
API
change
compared
with
comparing
with
the
open
sensors.
We
have
done
limited
number
of
changes,
not
too
many,
but
there
are
still
breaking
changes,
especially
the
fact
that
the
package
name
changed.
D
D
We
will
also,
at
one
point,
start
supporting
our
agent
collector
infrastructure.
These
are
very
useful,
especially
for
precompiled
binaries
like
HBase
and
void,
for
example.
Instead
of
them
choosing
the
vendor
for
you,
they
will
just
say
we'll
push
the
data
to
a
sidecar,
deploy
the
sidecar
with
whatever
format
you
want
to
use
or
whatever
back-end
you
want
to
use
for
the
open
sessions
library.
D
What
we
plan
to
do
is
actually
changing
the
so
first
we
want
to
get
to
open
telemetry
alpha
release.
After
we
have
a
alpha
release.
What
we
will
plan
to
do
is
immediately
change.
All
our
public
API
is
to
forward
everything
to
the
new
project,
which
means
we
will
delete
most
of
the
code
from
open
census.
As
part
of
the
of
this
transition
point.
D
That
means
that
what
the
open
census
will
become
will
become
just
a
simple
shim
that
forwards
all
the
calls
between
the
between
the
public
operations
API
and
open
telemetry.
This
is
very
important
because
this
will
also
make
the
open
telemetry
implementation
being
used,
and
so
every
part
or
every
problem
that
we
have.
We
have
only
to
fix
that
into
open
telemetry,
and
we
no
longer
have
to
deal
with
a
lot
of
open
source
problems.
D
Then
probably
users
at
one
point
users
will
to
start
transition
their
code.
There
are
API
calls
instead
of
calling
the
open
census.
Public
API
they'll
start
migrating
to
the
new
library.
We.
We
are
very
careful
with
this
step
and
we
would
literally
want
to
avoid
to
avoid
having
our
users
to
do
a
big,
PR
and
change
everything
in
one
PR,
because
that's
almost
impossible.
So
you
like
enforce
that
you
can
have
a
binary
that
works
with
open
tracing,
open
sensors
and
open
telemetry
in
the
same
time.
D
That
will
give
us
enough
time
for
for
this
transition
to
happen
slowly
and
with
the
right
piece
that
we
need,
when
the
last
part
will
be
end
of
the
life
for
open
census
and
partying,
that
we
achieved
the
transition
for
this
project
for
the
agent
thing.
What
we
would
like
to
do
is
we
have
this
sidecar
or
agent
implementation
that
supports
multiple
receivers
and
also
exporters.
D
The
people
didn't
like
the
fact
that
we
have
this
event
different
type
of
events,
so
we
generalize
under
one
event,
so
we
had
to
change
that
into
the
data
model.
I
think
that's
almost
the
the
very
I
think
that's
the
single
breaking
change
that
we
have
so
implementation
wise.
It's
gonna
be
just
a
copy-paste
of
the
the
other
implementation,
but
we
still
have
to,
and
is
that
because
we
use
G
RPC,
the
namespace
is
backwards,
incompatible
like
in
in
a
snobby
or
G
RPC,
changing
the
name.
Space
will
be
backwards
incompatible
for
us.