►
From YouTube: OpenTelemetry: Overview & Backwards Compatibility of OpenTracing + OpenCensus - Steve Flanders
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: Overview & Backwards Compatibility of OpenTracing + OpenCensus - Steve Flanders, Omnition
OpenCensus and OpenTracing are merging under the new CNCF project OpenTelemetry! In this session, we will provide an overview of the goals along with the structure of the new project and current roadmap. In addition, we will discuss what this means for the OpenCensus and OpenTracing project including topics like greenfield instrumentation and backwards-compatibility.
https://sched.co/QGLq
A
B
A
There
we
go
all
right,
sorry,
Ron,
so
the
next
sessions
on
open,
telemetry
I
want
to
provide
an
overview
of
what
the
project
is
and
talk
about,
some
of
the
backwards
compatibility
for
those
of
you
coming
from
open,
tracing
or
open
census.
First,
a
quick
introduction,
maybe
see
all
right
cool.
My
name
is
Steve
Flanders,
I'm,
head
of
product
and
experience
at
a
stealth,
startup
called
a
mission.
A
We
are
in
the
observability
space
space
out
of
California
in
the
United
States,
if
you're
interested
in
learning
more
about
observability
or
what
I
do
I've
provided
some
links
here
at
the
bottom,
alright,
so
some
background,
I'm
gonna
start
by
talking
about
open,
tracing
and
open
census.
You
may
have
heard
of
open
tracing
because
of
the
CNC
f
project.
You
may
have
heard
of
open
census
because
it's
very
popular
in
Google
cloud
platform
GCP
or
in
Microsoft
Azure,
both
of
them
use
open
census
today.
So
let's
provide
some
background
here.
A
When
we
talk
about
observability
or
you
might
hear
the
word,
telemetry
there's
really
three
different
verticals.
You
may
have
heard
about
the
three
pillars
of
observability,
which
is
basically
tracing
metrics
and
logs,
but
there's
also
a
few
different
layers
for
each
of
those
verticals,
and
you
have
the
instrumentation.
Api
is
how
you
actually
get
tracing
data
metrics
and
logs.
You
have
the
implementation
detail
of
how
you're
gonna
pull
that
data
out
and
send
it
to
the
backend
of
your
choice.
A
You
have
the
data
infrastructure
to
support
that
and
actually
be
able
to
query
over
it
and
then,
of
course,
the
various
different
formats
as
it
turns
out.
This
is
a
pretty
complex
problem
because
on
top
of
the
verticals
and
layers,
there's
also
a
polyglot
of
different
languages
that
you
could
have
written
in
and
you
have
to
solve
that
problem
for
each
of
those
languages.
So
there
were
two
projects
that
existed.
One
was
called
open
tracing
the
other
was
called
open
census.
They
were
similar.
A
They
were
not
the
same,
so
open
tracing
came
out
first
that
they
came
out
about
2016.
Basically,
it
solved
one
vertical
tracing.
All
it
did
was
tracing.
It
had
one
layer,
an
API,
just
the
API
for
the
instrumentation
aspect.
It
was
loosely
coupled
supported
a
ton
of
different
languages
and
broadly
adopted,
it's
already
part
of
CNC
apps.
That
shows
that
it
was
widely
used
on
the
flip
side
of
the
house.
You
have
open
census.
This
came
out
in
early
2018.
A
It
actually
attacked
both
traces
and
metrics,
so
it
solved
two
different
verticals,
not
only
that,
but
it
addressed
both
the
API
as
well
as
the
implementation.
So
it
was
the
first
solution
to
provide
an
end-to-end
solution
to
this
problem
space.
It
was
more
tightly
coupled
in
terms
of
the
frameworks
and
instrumentations
and
libraries
that
it
supported
I
did
support
a
broad
set
of
languages,
five
of
them
in
beta,
and
it
was
broadly
adopted
now
just
looking
at
this
slide,
you
can
see
that
there's
some
amount
of
overlap
and
these
each
had
pros
and
cons.
A
Let's
talk
about
pecans
open
tracing
only
addressed
tracing
but
I'm,
assuming
most
people
use
metrics
and
logs
today,
so
you
probably
want
more
than
just
tracing
on
the
flip
side
of
the
house.
Open
census
was
tightly
coupled,
while
vendors
specifically
would
prefer
a
more
loosely
coupling
aspect,
so
they
can
differentiate
on
the
different
analytics
that
they're
providing.
So
these
were
kind
of
some
problem
areas
in
each
of
them.
They,
of
course,
each
had
strengths
as
well.
A
Now,
from
a
adoption
perspective,
both
had
very
healthy
ecosystem.
They
were
very
active
on
github.
There
were
a
lot
of
contributions
and
they
were
backed
by
a
bright
wide
range
of
contributors
and
the
open
census.
Side.
Omniscient
was
one
of
the
companies
with
Google
and
Microsoft
to
basically
form
open
census
and
build
the
client
libraries,
as
well
as
the
open
census
service.
The
service
was
made
up
of
an
agent
and
a
collector
that
was
basically
part
of
the
implementation
side
of
the
house.
A
That
was
missing
from
open
tracing
and
other
providers
and
users
were
also
getting
actively
involved
in
open
census
as
well.
Sorry,
one
second,
sometimes
cuts
out
it'll
come
back
there
we
go
so
both
project
projects
were
well
adopted.
Great
well
kind
of
the
problem
is
that
there
was
no
clear
winner.
Both
were
doing
very
well
and
that's
great,
except
for
the
fact
that,
as
user
you
might
be
asking
yourself
well,
do
I
use
open
tracing
or
do
I
use
open
census
or
do
I
use
both
I'm
confused
as
to
what
to
do.
A
This
actually
is
very
well
represented
in
a
Hadoop
ticket.
I
have
a
link
in
the
slides
that
you
can
go.
Take
a
look
at,
or
someone
basically
asked.
Do
we
use
open
tracing
here.
Do
we
use
open
census
and
it's
been
open
for
a
few
years
and
there's
no
answer
not
good
right,
like
people
don't
want
to
have
confusion,
they
want
a
single
solution.
A
Ideally
they
take
one
dependency
and
it
just
works,
and
at
the
end
of
the
day,
if
we
have
an
open
standard,
if
we
have
an
open
API,
if
we
have
an
open
implementation,
that's
possible,
but
as
long
as
we
have
two
different
solutions
that
are
doing
similar
things
with
a
little
bit
of
overlap,
that's
never
going
to
happen.
This
is
a
problem
so
to
solve
that
problem,
open
tracing
and
open
census
are
merging
together
and
the
new
project
is
called
open
telemetry.
So
it's
the
best
of
both
worlds:
it's
not
starting
from
scratch.
A
Basically
we're
taking
lessons
learned
from
both
open
tracing
and
open
census,
we're
taking
contributors
and
members
from
both
of
those
communities
and
we're
forming
open
telemetry.
So
we
can
solve
some
of
the
pain
points
that
I
showed
in
the
previous
slide
and
come
out
with
a
single
standard
and
a
single
solution
that
everyone
can
consume.
This
is
beneficial
for
end-users
because
they
now
know
what
dependency
to
take
and
it's
beneficial
for
vendors,
because
they
now
know
the
standard
that
needs
to
be
followed.
They
don't
have
to
write
their
own
or
come
up
with
side
solutions.
A
This
is
actually
kind
of
unique.
In
my
opinion,
if
you
look
at
CN
CF,
there's
a
lot
of
competing
products
or
even
outside
and
open
source
communities
in
general.
You
don't
typically
see
a
merge
like
this,
but
I
think
this
is
extremely
beneficial
to
the
community.
This
is
a
case
where,
if
I,
if
I
have
to
instrument
my
app
for
a
bunch
of
different
languages,
I
don't
want
to
have
to
mix
and
mingle
and
decide
what
to
go.
A
Choose
I
want
to
have
one
standard,
so
I'm
glad
that
we
could
come
together
and
form
a
single
solution
here,
all
right,
so
open
telemetry
overview
going
back
to
this
slide.
So
what
is
open
telemetry
trying
to
solve
all
of
it?
The
whole
thing
we
want
to
be
able
to
surprise
supply
traces
and
metrics
and
logs.
A
We
want
to
give
you
the
API
and
the
end
and
implementation
we
want
to
handle
the
wire
format
all
of
it,
because
if
that's
done
and
it's
done
well,
then
all
you
need
is
the
analytics,
back-end
and
you'll
be
able
to
point
to
that
or
reconfigure
to
that.
Without
changing
your
code,
it'll
save
software
developers
a
ton
of
time
it'll
make
it
impossible
to
solve
availability
and
performance
issues
with
these.
So
let's
walk
through
each
of
these
instrumentation
api's.
What's
gonna
happen?
Well,
the
goal
is
to
standardize
around
context
propagation,
but
give
you
choice.
A
So
if
you
want
to
use
a
certain
context,
propagation
format
you
can,
the
standard
here
is
going
to
be
w3c
trace
context.
The
first
version
should
be
coming
out
later
this
year.
It's
already
in
its
final
release
and
open
census,
as
well
as
open
telemetry
will
have
native
support
for
w3c.
It's
likely
to
be
the
standard
that
you
see
going
forward
for
trace
context
propagation,
but
it
will
support
others
as
well.
A
So
if
you're
using
Zipkin,
v3
it'll
support
that
as
well,
so
it'll
be
easy
for
you
to
configure
the
context
propagation
format
that
you
care
about,
while
the
initial
focus
will
be
around
tracing
and
metrics.
The
goal
is
to
enhance
this
two
logs
as
well.
If
you
look
at
the
open
census
project,
it
already
started
to
tackle
some
of
the
logs,
at
least
in
the
Java
client
library.
A
So
what
it
provides
today
is
the
ability
of
adding
trace
ID
span,
ID
sampled
information
as
tags
to
your
log
message,
and
why
that's
powerful
is
because
now
your
logs
will
have
context
and
correlation
I
can
say
for
this
given
trace
and
all
of
the
calls
that
it
made
show
me
all
the
logs
or
from
a
given
log
show
me
the
entire
trace
for
that
log.
That's
very
powerful
because
one
of
the
problems
with
metrics
and
logs
is
that
in
distributed
micro
services
based
architectures,
they're,
missing,
contexts
and
correlation,
they
are
symptoms,
they
are
signals.
A
They
are
not
root
cause.
They
cannot
provide
problem.
Isolation
like
they
could
in
the
monolithic
world.
So
with
distributed
tracing
as
the
foundation,
you
can
actually
enrich
metrics
and
logs
and
make
them
more
powerful,
and
so
basically,
what
will
happen
here
is
open.
Telemetry
will
provide
a
tracing
and
a
metrics
API,
and
then
it
will
provide
a
client
library,
implementation
that
you
can
leverage
and
then,
depending
on
what
you're
leveraging
from
an
applique
our
PC
perspective,
it'll
go
ahead
and
hook
up
and
integrate
in
there.
For
you
automatically
the
net
result.
A
Is
you
just
take
a
dependency
and
it
should
just
work
and
if
you're,
using
a
framework
or
library,
that's
already
instrumented.
If
you
have
a
service
smash
like
Sto,
you
can
take
advantage
of
that
as
well
from
an
implementation
standpoint.
The
goal
is
to
provide
one
reference:
implementation
for
every
language,
the
first
version
of
open
telemetry,
which
will
be
coming
out
later
this
year.
I'll
talk
about
that
in
a
minute
will
focus
on
five
primary
languages.
I'll
try
to
get
them
right,
go
node,
PHP
now
go
node,
Python,
Java
and.net.
A
There
we
go
second
time
and
I
got
it,
but
they're
all
the
libraries
will
be
supported
going
forward.
Sig's
or
special
interest
groups
are
firing
up
right
now,
if
we're
interested
in
contributing
to
them.
In
fact,
I
think
I
just
saw
one
for
a
C++
and
C
sharp
they're
just
getting
started.
So
if
you're
interested
in
another
language,
please
get
involved.
I
mentioned
the
w3c
trace
context,
propagation
and
the
goal
is
to
have
a
wire
format
for
tracing
metrics
and
logs
from
a
tracing
perspective.
A
Open
census
already
has
a
wire
format
opens
limitary
will
have
one
as
well,
based
on
the
best
practices
that
we've
learned
so
far.
Data
infrastructure
data
collection,
if
you
will
so
open
census,
has
something
known
as
the
open
sense
of
service
I
mentioned
that
it
had
an
agent
and
a
collector
open
telemetry
will
have
a
similar
piece
of
functionality
that
you
can
leverage.
If
you
want.
The
goal
is
that
it
will
support
all
popular
open
source
software
automatically.
A
So,
for
example,
for
tracing
that
Zipkin
and
Jaeger
from
a
metrics
perspective
that
would
be
Prometheus
and
stats
D,
so
that'll
just
work
out
of
the
box,
but
it's
a
pluggable
architecture,
so
commercial
vendors
can
also
provide
what
we
call
receivers
and
exporters
into
that
architecture,
and
you
can
take
advantage
of
that
as
well.
Many
of
them
are
already
available.
You
can,
of
course,
write
your
own
if
you
have
your
own
custom
implementation
as
well.
A
The
goal
is
to
support
both
tracing
and
metrics
to
start,
but
logging
will
come
so
there's
questions
about
like
flu
and
D,
and
what
does
that
mean
we'll
get
there
we're
not
there
yet,
but
those
questions
will
be
answered
and
then
the
agent,
the
collector,
provide
a
ton
of
additional
benefits
and
feature
functionality.
One
of
the
questions
earlier
at
the
jäger
session
was
I.
Don't
want
to
use
an
agent
well,
the
agents
actually
very
powerful
from
a
client
instrumentation
perspective.
A
I
can
now
point
to
localhost,
which
means
I
don't
have
to
reconfigure
my
application
ever
local
hostess,
and
so
is
there
so
I
can
deploy
this
application
anywhere
and
I'll
know
that
it
gets
to
the
agents.
In
addition,
the
agent
provides
buffering
and
retry
capabilities
and
batching
capabilities.
Those
are
things
you'd
have
to
add
to
your
client,
libraries
and
every
language
that
you're
running
in
otherwise
that's
overhead
for
your
applications.
A
Probably
don't
want
overhead
for
your
application,
so
ideally
you'd
defer
that
to
the
agent
let
the
agent
handle
it
locally
and
then
it
can
send
to
a
collector.
The
collector
can
be
used
for
sending
this
over
a
WAM.
So
if
you
have
latency
or
a
high
throughput
of
traffic's,
you
need
to
buffer
or
cache
more
of
that
data.
The
collector
also
offers
advanced
functionality
like
tale
based
sampling
sampling
is
very
common
in
the
distributed
tracing
world,
but
to
date
it's
been
mostly
head
based
at
least
from
a
open
source
perspective.
A
The
open
census
service
was
the
first
open
source
software
to
have
tale,
based
sampling,
open
sourced
and
available.
Typically,
you
have
to
get
that
from
a
proprietary
vendor
opens
limitary
will
offer
a
tale
based
sampling
as
well,
if
you're
interested
in
that
functionality
opens
limits
your
goals.
So
let's
talk
about
the
elephant
in
the
room,
because
this
is
kind
of
important
I
mentioned
open
tracing
I
mentioned
open
census.
I
mentioned
open,
telemetry
I
said
we
were
going
to
add
the
two
one
plus
one
and
we're
gonna
end
up
with
not
two
but
one.
A
Well,
this
kind
of
sums
it
up
perfectly.
The
fear
is
we
just
invented
another
standard
called
open,
telemetry
and
now
you'll
have
three
choices.
No,
no!
That's
not
the
goal.
One
of
our
goals
is
to
prevent
this
from
happening.
So
how
are
we
going
to
prevent
this
from
happening
and
the
answer
is
we're
gonna,
provide
backwards,
compatibility
and
we're
gonna
sunset,
open
tracing
and
open
census.
What,
if
sunset
mean
those
repositories
are
going
to
go
read-only
by
the
end
of
the
year?
A
That's
the
plan,
so
we're
basically
working
right
now
to
make
the
first
version
of
open
telemetry
that'll
be
available
later
this
year.
Right
now
we're
targeting
September
for
the
five
major
languages
that
I
already
mentioned,
and
then,
by
the
end
of
the
year
by
hopefully
cuke
on
North
America,
we
will
announce
the
sunset
or
the
made
read-only
version
of
open,
Tracy
and
open
census.
But
what
we're
going
to
do
is
provide
a
bridge
that
has
full
backwards
compatibility.
A
So
if
you're
on
open
tracing
or
open
census,
you
don't
have
to
do
anything
by
the
end
of
the
year.
It
will
still
work
with
open
telemetry.
You
have
nothing
to
worry
about
and
we
will
support
backwards,
compatibility
for
at
least
two
years.
That's
the
end
of
2021.
We
have
plenty
of
time
to
migrate
over
to
open
telemetry
as
it
becomes
available.
So
our
goal
is
to
provide
enough
runway
for
people
but
at
the
same
time,
put
some
pretty
firm
dates
in
so
we
don't
end
up
with
three
standards
we
really
want
to
consolidate.
A
We
want
open
telemetry
to
be
the
future.
They
want
there
to
be
one
API
and
one
implementation,
there's
actually
a
medium
post
on
this.
That
has
more
details
if
you're
interested
in
more
specifics,
so
one
projects
not
two,
definitely
not
three.
The
goal
is
to
attack
tracing
and
metrics
API
and
implementation
for
five
major
languages
in
the
first
release.
The
goal
is
to
make
it
loosely
coupled,
so
you
can
take
what
you
want.
You
don't
want
to
use
an
agent
or
collector.
That's
fine!
You
already
have
your
own
client
instrumentation,
that's
fine!
A
A
There
we
go
so
it'll
be
loosely
coupled
and
you
can
only
take
the
pieces
that
you
care
about
and
then
probably
most
importantly,
there's
open
governance
in
fact
we're
following
kind
of
the
kubernetes
model
here,
so
it'll
be
representation
for
many
orgs
and
there'll
be
fixed
timelines
on
how
long
someone
can
serve
on
the
on
the
government's
board.
So
the
project
isn't
pulled
in
any
one
particular
direction
again.
There's
a
blog
post
on
this
on
medium
as
well.
So
government
governance
I
just
want
to
talk
about
this
really
quickly.
A
There
are
special
interest
groups
or
SIG's
that
are
getting
started
right
now.
So
now
is
a
great
time
to
get
involved.
If
you're
interested
in
contributing
to
this,
there
are
github
issues
open
on
open
telemetry
on
github.
That
is
a
gotcha.
It's
not
open
limitary,
it's
open
telemetry
on
github.
Otherwise
you
won't
find
it
sorry
about
that.
Someone
has
opens
limitary,
we're
trying
to
fix
that.
So
there's
special
interest
rube
for
each
of
the
languages
and
then
there's
different
community
membership
things
you
can
become
a
member
of
improver
or
a
maintainer.
A
There
are
certain
requirements
in
order
to
get
approved
for
that.
You
have
to
have
a
certain
number
of
contributions
and
you
have
to
be
active
in
the
community
and
you
have
to
be
recommended
by
someone-
that's
already
part
of
the
community,
if
you're
interested
in
learning
more.
If
you
go
to
open,
telemetry,
slash
community,
that's
where
the
repository
is
with
all
of
these
details
and
then
finally
we're
using
the
CNC
F
code
of
conduct,
open
symmetry
is
a
CNC
F
project.
The
goal
is
to
represent
as
many
different
companies
as
organisations
as
possible.
A
We
don't
want
to
have
unequal
representation
or
one
company
kind
of
driving
the
project.
We
really
want
the
community
as
a
whole
to
drive
the
project
right
now.
Elections
are
based
in
the
kubernetes
model,
so
it'll
be
nine
seats
with
limits
on
over-representation,
so
no
company
kind
of
controls,
the
governance
board,
only
active
code
contributors
get
to
vote
kind
of
important
and
there
are
maximum
limits.
So
again,
the
idea
is
to
rotate
people
and
companies
in
and
out
of
the
project,
all
right.
So
next
up
I
want
to
talk
about
to
backwards
compatibility.
A
So
if
you're
coming
from
open
tracing
and
you're
coming
from
open
census,
what
does
it
mean?
Let's
start
with
open
tracing,
so
open
tracing?
Has
a
few
changes
to
the
API
itself:
apologies
and
advance
these
slides
for
open
tracing
or
a
little
technically
deep,
so
I'm
gonna
summarize
them
for
you,
and
then
you
can
review
them
if
you
care
about
the
specifics.
A
So
the
three
major
changes
for
open
tracing
are
around
sampling,
so
they'll
be
formal
definitions
on
how
sampling
is
handled
terminology
changes
so,
for
example,
in
open
tracing
metadata
was
known
as
tags,
but
an
open,
telemetry
that'll
be
called
attributes,
so
they
leave
some
naming
changes
to
get
used
to
and
then
the
trace
ID
span,
ID
type
changes
to
make
them
more
standard
for
the
w3c.
How
that
context
correlations
handled
would
give
the
w3c
trace
context.
A
That's
coming
out
that
will
formally
make
some
changes
to
be
open,
tracing
a
but
again
it
will
be
backwards
compatible.
You
don't
necessarily
need
to
worry
about
this
as
you
move
to
open
telemetry.
These
are
just
things
to
be
aware
of.
As
I
mentioned,
there's
some
names
naming
changes,
so
tags
are
attributes
logs
become
known
as
events.
These
slides
are
attached
to
the
session
on
the
scheduler
builder,
so
it
should
be
easy
to
get
them
if
you're
interested
and
all
the
other
notions
like
follows
from
and
links
fans
will
all
be
included.
A
So
you'll
have
feature
parity
with
what
you're
used
to
from
an
open
tracing
perspective.
The
tracer
itself
will
also
have
some
changes,
so,
for
example,
instead
of
ending
a
trace
that
terminology
that
function
call
will
be
removed,
hopefully
you'll
see
in
a
second.
Instead,
it
will
probably
support
flushing.
You
see
the
word,
probably
we're
still
defining
the
new
API
and
specification.
That's
actively
going
on
right
now,
but
consensus
right
now
is
that
trace
doc.
Close
will
probably
go
away
and
trace.
That
flush
will
probably
be
introduced.
A
Instead,
again,
you
can
get
involved
in
the
community
and
you
can
follow
this
live
if
you're
interested
in
the
specifics
for
open
tracing
for
open
census,
the
story's
a
little
bit
easier.
The
B
primary
change
is
that
there
will
be
a
clear
separation
between
the
API
and
the
implementation.
That's
really
what
was
missing
in
open
census,
so
the
idea
here
is
you'll
be
able
to
replace
the
API
with
another
one.
If
you
want
to
so
there's
some
other
implementation
area,
all
right.
Some
other
API
specification
you
want
to
follow.
A
You
can
a
previously
that
was
not
possible.
It
was
tightly
coupled
with
the
actual
implementation
itself,
the
divide,
dividing
that
and
clearly
separating
the
two
provides
more
choice
for
end-users:
there's
a
lot
more
flexible
model,
and
basically,
what
that
and
harun
ask
is
other
than
that.
The
instrumentation
API
is
going
to
change
a
little
bit,
but
none
of
the
specifics
are
gonna
really
impact
you
I
do
want
to
kind
of
walk
through
what
a
migration
might
look
like
from
open
census.
It's
kind
of
interesting
visually.
A
So
today,
let's
say
that
you
have
a
service
or
an
application
written
in
whatever
language.
Let's
use
go
and
you
go
ahead
and
you
leverage
the
open
census,
client
library,
it
actually
has
an
API
and
an
implementation.
I
thought
that's
a
tightly
coupled
that's
how
open
census
is
today,
so
once
open
telemetry,
the
first
version
comes
out.
What
you
would
basically
do
is
you
would
take
a
dependency
on
the
API
and
the
implementation,
but
that
will
happen
automatically
you'll
just
basically
upgrade
open
census.
What
open
census
is
going
to
do
very
soon
is
they're.
A
Gonna
do
a
cut
over.
So
when
you
upgrade
to
the
latest
version,
you'll
still
get
the
open
census
API,
but
the
open
census,
API
will
just
go
and
call
the
open,
telemetry
API
and
the
open,
telemetry
API
will
call
the
opens
limit
tree
implementation,
it'll
be
transparent
to
you.
You
won't
make
any
change
other
than
upgrading
your
open
census
virgin
version.
Then
you
will
eventually
take
a
dependency
on
the
opens
limit
tree
library
itself.
So
that's
a
code
change
that
you
make.
A
That
gives
you
a
clear
separation
between
using
open
census,
no
pintel
imagery
and
provide
the
bridge
as
you
make
this
migration
over
and
then.
Finally,
you
would
remove
your
dependency
on
the
open
census
or
library
once
you're
ready
to
do
the
full
cut
over.
So
you
can
make
it
a
four
step
project,
a
process
you
can
make
it
a
one-step
process
again.
A
There's
a
notion
of
receivers,
how
you
get
data
into
the
open
census,
service
and
exporters,
how
you
get
data
out
of
the
open
census
service
and
all
the
open
source
popular
open
source
solutions
are
supported
so
for
tracing,
that's
Yeager
and
Zipkin
for
metrics
at
Prometheus
and
stats.
D,
there's
also
an
open
census,
endpoint
as
well,
and
then
commercial
vendors
have
provided
their
own
exporters.
Traditionally
they
don't
typically
provide
receivers
today
that
are
available.
So
what's
gonna
basically
happen
is
we've
already
ported
the
open
census
service
to
the
open,
telemetry
service.
A
So
very
soon
we
will
cut
a
new
release
and
you'll,
basically
just
deploy
that
release.
It'll
look
exactly
the
same.
It's
basically
just
a
rename
and
then
over
time
we're
going
to
release
the
open,
telemetry,
receiver
and
exporter
the
new
data
format
that
merges
the
best
of
both
worlds
over
time.
You
will
then
migrate
to
that
open
telemetry
service.
Once
you
have
fully
migrated
over
then,
eventually,
in
two
years,
when
backwards-compatibility
gets
removed,
we
will
remove
open
census
as
a
receiver,
as
it
will
no
longer
be
necessary
again.
A
The
transition
should
be
pretty
smooth
and
seamless
for
you,
especially
from
the
service
perspective,
given
that
open
tracing
didn't
have
a
service
today.
This
is
this
via
a
port
over
from
the
open
census
service
itself.
With
that
said,
there
are
some
architectural
changes
that
are
being
made,
they'll
be
transparent
to
you,
but
the
agent
and
collector
code
bases
are
based
on
the
same
code,
but
they're
not
identical
we're
moving
to
an
identical
binary
for
both
with
just
different
configuration
options,
and
we
are
looking
to
overhaul
the
configuration
that
was
used
and
open
census
service.
A
So
then
open
telemetry
there'll
be
a
new
standard
way
of
defining
it.
It's
much
more
scalable
and
Enterprise
ready
that
should
be
available
here
in
the
next
month.
Very
soon,
we'll
be
cutting
as
an
X
release
of
this
you
can
follow
the
open
telemetry
service
to
get
more
details.
Ok,
so,
let's
summarize,
because
I
threw
a
lot
of
words
at
you
what's
next,
the
first
version
of
open
telemetry
is
expected
by
the
end
of
this
year.
We'll
have
support
for
five
languages.
I'll
try
again
go
node,
Python,
Java,
dotnet,
hey
first
try
nice.
A
There
will
be
a
bridge
between
open
telemetry
and
open
tracing
and
open
census.
So,
if
you're
using
open
tracing
no
consensus,
keep
using
it,
it
will
work.
It
will
be
ok.
In
fact,
if
you
plan
on
instrumenting
today,
like
in
a
Greenfield
environment,
you
have
to
use
open,
tracing
or
open
census.
Open
telemetry
is
not
ready,
yet
we'll
be
ready,
we're
working
on
it,
but
it's
not
ready
yet.
So,
if
you
need
instrumentation
today
go
look
at
open,
tracing
and
open
census.
We
try
to
mark
that
in
the
repositories.
A
So,
for
example,
if
you
go
to
the
opens
limit,
Tree
Service,
it
clearly
says:
please
go
use
the
open
census
service,
so
we're
trying
to
make
it
clear
to
the
community
what's
going
on,
but
at
the
same
time
be
transparent
as
new
features
are
available,
the
goal
is
to
sunset:
read
that
means
read-only,
so
going
forward,
there'll
be
no
changes,
the
open
tracing
or
the
open
census,
github
repository
by
the
end
of
the
year.
That's
the
current
targets.
Those
repositories
will
remain
in
read-only
mode
for
at
least
2
years.
We're
backwards,
compatibility
that
backwards
compatible.
A
They
should
last
through
2021,
of
course,
if
they'd
slip
here,
then
we'll
give
you
specific
dates,
but
right
now
these
are
our
targets
and
then
open
tracing
has
some
changes
to
the
terminology.
The
context,
propagation
and
sampling.
As
I
already
mentioned,
an
open
census
will
have
a
clear
separation
from
the
API
and
the
implementation.
Those
are
probably
the
key
takeaways
here
from
the
differences,
as
well
as
the
compatibility
and
the
merging
between
them.
Now,
of
course,
we'd
love
to
have
you
be
involved
in
this
community
now's
a
great
time
to
get
involved
right.
A
So,
if
you're
interested
in
a
particular
language,
if
you
have
feedback
on
direction,
if
you
want
to
contribute
to
the
website
or
the
documentation,
we'd
love
to
have
that
as
well,
the
open
symmetry
community
is
very
active
right
now.
There
is
a
debate
on
whether
we're
gonna
be
on
git,
er
or
slack
right
now,
we're
on
both,
but
you
can
come
find
us
in
one
of
those
two
forums
and
definitely
post
your
questions
there
or,
of
course
you
can
open
github
issues
as
well.
A
All
of
the
SIG's
are
documented
on
the
opens
limitary
community
page
they
have
weekly
or
bi-weekly
meetings
with
meeting
links
in
there
and
you're
definitely
welcome
to
join.
If
it's
not
in
a
friendly
time
zone.
Please
open
a
github
issue
all
right.
We
want
to
make
sure
that
the
community
can
be
involved.
If
that
means
having
every
other
meeting
being
in
a
different
time
zone,
we
were
definitely
open
to
that.
A
When
it's
blue,
nice
I
think
there's
our
github
issue
open
for
this,
so
again
the
initial.
So
when
it's
blue
indeed
coming
it's
the
question,
the
initial
focus
is
traces
and
metrics.
So
for
the
end
of
this
year,
I
wouldn't
expect
to
see
any
logs
it's
possible
if
we
are
able
to
consolidate
and
everything
then
quickly,
we'll
get
it
by
the
end
of
the
year,
but
I
suspect,
when
is
it
coming,
I
would
guess
next
year.
That
would
be
my
hypothesis.
What
you
may
see
is
the
ability
of
adding
trace
of
the
span.
A
A
If
you
want
inside
of
your
application
using
opens
limitary
long-term,
we
can
see
if
it
will
be
changes
to
things
like
fluency
that
was
probably
gonna,
be
maybe
cuke
on
North
America
I'll
have
a
better
answer
as
to
timelines,
let's
just
towards
the
end
of
the
year,
but
right
now
that
isn't
the
highest
priority.
The
highest
priority
is
really
Sun.
Setting
open
senses
and
open
trade
yeah.
A
A
So
open
the
open,
metrics
project
is
primarily
a
data
formats
project.
So
it's
the
format
for
sending
metrics
out
over
the
wire.
Initially,
the
thought
was
to
keep
that
separate,
but
open
census
actually
has
a
format
for
sending
trace
data,
so
we
are
actually
in
active
talks
with
the
open,
metrics
and
Prometheus
focus
about
this.
D
Tracing
and
open
census,
they
provide
a
capability
to
you
know,
configure
the
application
from
the
environment
itself
right,
so
we'll
open
telemetry
have
that
kind
of
capabilities.
When
you
say
from
the
environment
itself,
what
you
mean
so
say:
I
want
to
connect
to
I
get
collected
for
all
the
traces
right
so
I.
My
application
can
read
stuff
from
the
environment
right
which
Auto
configures
the
applications
to
send
it
to
the
given
collector.
A
You're
asking
about
like
environmental
variable,
yes,
yeah,
okay,
so
yes,
Jagr
supports
environmental
variables.
Today,
open
census
supports
environmental
variables.
Today
the
expectation
is
that
opens
limitary
will
is
well.
In
addition,
the
goal
is
to
provide
more
integrations
so,
for
example,
open
census
in
the
ecosystem
repository
actually
supported
a
webhook
admission
controller
to
kubernetes,
where
it
could
actually
tag
in
via
environmental
variables.
Pod
information,
so
for
given
application,
I
could
figure
out
what
pod
it
was
running
on
when
it
generated
that
trace.
A
What
we're
looking
to
do
is
to
provide
even
better
native
hooks
like,
wouldn't
it
be
ideal
if
the
agent
could
just
tag
that
on
and
I
didn't
have
to
modify
the
outer
pod.
So
another
reason
to
potentially
consider
the
agents
is
that
it
will
actually
collect
host
metrics
from
say,
kubernetes
natively,
instead
of
you
having
to
like
get
drop
boys,
or
only
from
your
app
and
not
being
able
to
get
down
to
the
host
itself.
The
agent
can
get
down
to
the
host
level.
A
A
Good
question
so
observability
is
a
common
term
that
came
out
in
the
cloud
native
era
or,
as
you
moved
to
more
micro
services.
The
way
I
like
to
think
of
it
is
observability.
The
term
observability
came
around
because
monitoring
was
in
the
previous
generation,
with
monolithic
applications
who
was
known
as
monitoring
and
the
problem
space
was
different.
You
could
use
just
metrics
and
logs
and
you
knew
where
the
problem
was.
A
It
was
in
the
monolith,
but
as
you
moved
to
a
distributed
based
architecture-
that's
not
the
case
anymore
and
as
errors
propagate
upstream
and
downstream
from
a
call,
traditional
monitoring
doesn't
work.
The
term
observability
can't
kind
of
came
out
of
that.
Telemetry.
On
the
other
hand,
that's
more
of
a
loaded
term.
I
think
we
went
back
and
forth
on
naming
for
the
project.
Given
that
open
tracing
was
taken,
open,
observability
wasn't
an
op
an
option.
A
Open
census
was
the
goal,
wasn't
to
use
open,
tracing
or
open
census?
Do
we
even
want
to
cause
confusion
and
in
the
community
we
wanted
a
new
name,
so
telemetry
kind
of
came
out
of
that
telemetry
data
in
general
is
just
signals.
You
can
think
of
it
as
from
your
application,
which
is
very
similar
to
observability
observability.
You
typically
think
of
the
three
pillars
of
observability.
You
just
think
traces,
metrics
and
logs,
but
as
I
mentioned,
we're
also
trying
to
attack
different
verticals
API
implementation
wire
formats.
A
B
A
So
the
the
binaries
are
support,
Linux
distributions
they
did
support.
At
least
the
open
Center
service
did
support.
Windows
I
think
we
drop
support
for
that,
but
we
can
get
it
reacted,
but
yeah
the
from
a
language
per
sec
perspective.
It's
it's
supported
from
a
cloud
perspective.
Open
census
was
supported
by
Google
cloud
platform
and
Microsoft
Azure
AWS
has
their
own
solution
and
we're
also
talking
to
other
cloud
providers
as
well.
What
we're
hoping
is
that
overall
cloud
providers
will
standardize
on
open
telemetry
as
well,
because
then
I
could
answer
the
question
of.
A
Is
it
my
app
or
is
it
my
cloud
provider?
That's
causing
the
problem
today?
You
can't
do
that,
and
so,
if
you
rely
on
a
platform
service
from
a
cloud
provider,
you
can't
easily
tell
whether
it's
slow
or
not,
and
that
results
in
support
calls
so
we're
working
with
other
cloud
providers
to
try
to
get
them
on
board
with
the
OpenFlow
matauri
project.
B
A
Basically,
after
it
gets
to
the
collector
it's
today,
it's
out
of
scope
provide
your
back-end
of
choice,
whether
that's
a
local
back
end
like
Jaeger
or
an
open-source
back
end
like
Jaeger,
or
to
a
commercial
vendor
like
omniscient
or
Google
stack
driver
or
whatever
your
gonna
use,
that's
kind
of
outside
scope.
With
that
said,
while
it's
in
the
agent,
the
collector
there's
some
amount
of
persistence,
that's
needed
needed
there.
Typically,
today,
that's
done
in
memory,
which
means
it's
a
little
lossy.
A
A
For
example,
the
open
census
service
supports,
as
I
mentioned,
tale
based
sampling,
that's
a
way
of
reducing
the
amount
of
data
that
I
send
to
a
back
end
and
hopefully
increase
the
amount
of
valuable
data
like
arrow
traces
that
I
send
to
it
versus
the
number
of
non
era,
traces
that
I
send
to
it,
but
actually
storing
it
and
persisting
it.
That's
that
typically
consider
the
back
end
problem
outside
the
scope
of
opening
all
right.