►
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: Panel Discussion and Q&A - Ben Sigelman, LightStep, Morgan McClean & Bogdan Drutu, Google
This workshop will open with a 20-minute overview of the goals and structure of the new OpenTelemetry project, followed by a panel discussion and audience Q&A featuring leadership from OpenTelemetry, OpenTracing, and OpenCensus.
https://sched.co/PTCT
A
All
right
thanks,
everyone,
sorry
for
the
delay.
Are
we
good
on
the
Havey,
but
okay,
all
right?
So
thanks
for
coming
to
this,
we
scheduled
280
minute
sessions.
The
first
20-ish
minutes
of
both
will
be
the
same
presentation.
Sorry
for
people
who
are
planned
in
coming
to
both
but
it'll
just
be
an
overview
of
the
open
telemetry
project
which
we
didn't
have
time
for
at
the
keynote
and
then
in
this
morning,
sessions
and
this
morning
session
will
have
a
small
piano
of
people
from
open
telemetry.
A
We
can
certainly
talk
amongst
ourselves,
but
hopefully,
ideally
we'll
get
folks
from
the
audience.
Who've
you
all
to
participate
either
by
asking
questions
or
by
you
know,
sharing
your
own
experiences
with
this
sort
of
technology,
so
I
guess
I'll
get
started.
I'm,
Ben,
signalmen,
I'm,
one
of
the
co-creators
of
open
tracing
and
I'm,
going
to
hand
off
to
Spiros
who's
been
involved
with
open
census
for
a
while
to
that
something.
A
Thank
you
to
talk
about
the
organization
of
opens
lemon
tree
all
right,
so
this
is
actually
about
dinner.
Did
you
get
off
the
hook?
You're
not
going
to
present
anything
right
now.
You
have
to
hook
right-
okay,
good
yeah,
Bob
gonna,
be
here
this
afternoon
to
present,
but
now
he's
just
watching
because
he
doesn't
like
he
doesn't
like
being
on
stage.
So,
let's
talk
about
open
tracing,
no
consensus.
Briefly,
quick
show
of
hands
are
the
people
who
here
is
doing
some
sort
of
tracing
at
your
companies?
A
Okay,
so
it's
sort
of
like
roughly
half
and
who's
using
open
tracing
right
now,
who's
using
an
open
census
right
now,
okay,
so
some
of
each
so
both
of
these
projects
cover
some
part
of
this
matrix.
What
I
would
emphasize
is
that
telemetry
in
practice.
Right
now,
is
some
combination
of
distributed
traces,
metrics
and
logs
I.
A
Actually,
my
personal
opinion
is
that
distributed
tracing
was
just
kind
of
fancy
logging.
It's
it's
logging,
that's
meant
to
understand
transactions
across
a
distributed
system,
so
you
can
kind
of
group
them
together
and
that's
why
it's
natural
to
expand
from
tracing
into
logs.
But
if
you
don't
have
these
basic
data
types
very
difficult
to
observe
a
modern
micro
services
based
application
now
getting
that
telemetry
isn't
just
a
matter
of
like
collecting
the
bits
and
bytes
there's.
Also,
some
instrumentation
that's
acquired
and
a
big
part
of
the
value
proposition
for
open,
telemetry
and
open
tracing.
A
You
know
consensus
before
it
is
to
do
that
instrumentation
once
and
then
reuse
that
effort
across
you
know
anyone
who
consumes
a
given
framework
or
library
so,
for
instance,
if
you're
in
Java
and
you
depend
on
drop
Wizard,
someone
instrument
drop,
was
or
for
telemetry
once
and
then
you
should
be
able
to
use
that
instrumentation
no
matter.
You
know
what
vendor
open
source
project
you're
using
to
observe
it.
So
there
are
api's
for
that.
A
There's
also
an
implementation
of
a
like
a
telemetry,
SDK
or
library
that
actually
sits
in
your
application
and
collects
the
data
and
guess
the
out
of
the
process.
That's
something
that
takes
a
lot
of
time
and
care
to
do
well.
Open
census
has
a
nice
set
of
implementations
for
this
in
many
languages.
There's
infrastructure,
like
collectors,
the
omniscient
folks
who
are
here
have
done
a
lot
of
work
on
a
very
high
quality
kind
of
sidecar
model.
Is
that
Ferris
gross
for
the
open
census
collector?
A
There
are
other
things
as
well
that
can
be
built
there
and
then
they're
a
bunch
of
formats.
Several
people
in
the
room
here
were
meeting
in
Barcelona
prior
to
coop
cond
as
part
of
the
w3c
effort
to
standardize
on
what's
a
glorified
HTTP
header,
but
it's
a
very
complicated
and
important
HTTP
header
that
they
spent
I.
A
Don't
know
how
many
frequent
flyer
miles
like
over
the
last
couple
of
years
trying
to
get
the
details
perfect,
but
there
are
a
number
of
formats
like
that
that
actually
are
very
difficult
to
get
right
and
telemetry
involves
those
formats
as
well.
So
there's
really
a
pretty
wide
scope,
I
think
that's
what
I'm
trying
to
say.
You
have
several
different
domains
for
the
top
two
layers.
You
have
to
repeat
this
effort
in
every
language
that
people
actually
depend
on
in
production.
A
It's
a
huge
amount
of
work
and
the
open
telemetry
project
over
time
intends
to
have
a
footprint
really
across
this
entire
spectrum,
and
that's
the
scope
of
what
we're
trying
to
accomplish.
What's
absent
here
are
actual
applications
of
the
telemetry
data,
so
that
would
be
things
like
Yaeger
or
Prometheus
in
the
open
source,
world
or
Zipkin.
There
are
a
number
of
vendors
here.
A
I
won't
take
this
opportunity
to
advertise
my
own
company,
but
we
all
are
trying
to
sell
stuff
that
uses
this
data
as
well,
and
that's
part
of
the
reason
that
vendors
are
so
interested
in
these
projects
is
that
we
want
to
have
high
quality
data
coming
out
of
these
cloud
native
applications
and
without
efforts
like
open
telemetry
that
data
just
isn't
there,
but
open
telemetry
itself
doesn't
provide
a
user
interface
to
speak
of
or
like
a
full
solution.
It's
really
just
a
portable
way
to
get
the
data
out
of
your
system
into
other
tools.
A
It
makes
sense
cool,
so
open,
trace
and
open
census
has
been
around
for
a
while
open
tracing
was
I.
Think
the
most
important
thing
to
understand
about
it
is
actually
what
was
problematic.
Open
tracing
was
really
restricted
to
tracing,
so
in
that
diagram
from
before
it
was
just
one
vertical
slice,
and
it
was
also
focused
on
just
the
API
layer.
The
loose
coupling
and
the
small
scope
was
helpful
in
that
it
was
easy
for
people
to
adopt
it
in
a
way,
but
you
would
end
up
instrumenting
your
code
once
for
tracing.
A
What's
for
metrics
and
then
again
for
logging,
which
was
not
great,
open,
senseless
addressed
that
issue
it
had
so,
it
still
has
support
for
many
verticals.
It
had
a
tighter
coupling
between
the
implementation
of
the
of
the
little
SDK
that
gets
data
out
of
the
process
and
the
API,
which
made
it
a
little
bit
more
difficult
for
some
vendors
to
adopt.
A
It
also
made
it
more
difficult
to
add
new
languages,
but
both
these
projects
have
very
wide
adoption,
oh
yeah,
so
these
are
the
these
are
the
you
know.
The
pain
points
that
people
felt
with
these
two
projects
kind
of
highlighted
here.
I
should
say
that
by
far
the
most
painful
thing
about
these
projects
was
just
that
there
are
two
of
them
which
we
did
say
in
the
Hino
I
mean
when
we
talked
to
users,
some
haven't
raced
in
an
open
census.
A
A
This
is
kind
of
good
you'd
like
to
see
things
that
are
widely
adopted,
but
also
not
so
good
and
that
we
were
unable
to
kill
either
project
like
we
could
stop
developing
open,
tracing
or
open
census,
and
the
projects
have
enough
velocity
at
this
point
that
they
would
continue
to
exist,
and
so
it's
necessary
for
us
to
formally
merge
these
two
projects
in
order
to
have
a
way
for
them
to
develop
into
this
third
project
yeah.
So
the
ecosystem
is
confused
and
held
back
well.
A
We
can
share
these
slides
people
want
them,
but
there's
a
Hadoop
ticket
where
you
can
see,
as
they
think
about
how
to
move
HBase
and
HDFS
over
to
open
tracing
or
open
census,
and
the
discussion
just
resolved
in
them
doing
neither
because
they
couldn't
decide
which
one
to
use.
This
is
just
a
very
public
artifact
of
a
discussion
that
we
saw
happening
over
and
over
again
in
the
industry,
where
people
couldn't
figure
out
what
project
to
use
and
we
want
to
make
that
easier
for
people
by
only
having
one
so
yeah.
A
This
project
is
the
next
major
version
of
both
and
that's
really
the
right
way
to
think
of
it.
It's
designed
for
backwards
compatibility
which
we'll
talk
about
in
a
minute,
and
it
doesn't
lock
you
into
anything
vendor
wise.
Nor
does
it
make
it
difficult
to
continue
to
use
open
tracing
it
open
census.
So
there's
a
very
clear
migration
path,
but
open
tracing
and
open
census
will
both
evolve
into
just
being
open
telemetry
over
the
next
year
or
two.
B
Thanks
Ben
hi,
my
name
is
spirit.
Rampage
I
am
the
founder
of
a
vendor
in
the
space
called
ammunition,
who
have
also
been
contributors
to
the
open
sensors
since
the
early
days,
and
just
briefly,
what
I
want
to
do
is
introduce
what
open
telemetry
is
with
more
specific
description
of
each
of
the
components
for
those
of
you
who
are
familiar
with
either
of
the
projects.
Really,
you
can
think
of
open
telemetry
as
a
superset
of
open
tracing
and
open
sensors.
B
So
this
is.
This
actually
derives
from
both
open
tracing
and
open
sensors,
with
some
changes
from
each
one
of
them
really
improvements
from
the
lessons
we
had
over
all
these
years
in
developing
against
these
api's
I'm,
not
gonna,
go
into
the
details
of
what
those
changes
are.
Some
of
them
are
breaking
for
both,
but
there's
gotta
be
compatibility
with
both
via
bridges
but
will
be
delivered
together
with
open
telemetry.
But
anyway,
this
API
aims
to
achieve,
let's
say,
to
build
connect,
obligation,
tracing
and
metrics
and
correlation
between
them
and
the
ventually
locks
as
well.
B
The
other
big
goal,
obviously
of
this
is
to
rely
on
the
existing
adoption
would
say,
and
by
open
source
frameworks
and
libraries
and
broaden
that
so
that
hopefully
eventually
get
to
a
point
where
most
open
source.
Let's
say
what
popular
frameworks
are
instrumented
with
open
telemetry
and
we
really
get
that
for
free
as
application
developers
and
for
those
may
be
familiar
with
open
census.
B
Open
telemetry
also
can
have
a
canonical
implementation
of
all.
These
API
is
in
the
client,
libraries
one
for
its
popular
language.
Those
will
derive
the
great
extent
from
the
existing
open
census
illumination,
which
has
been
used
in
production
for
a
while
and
it's
hardened,
especially
for
the
major
languages.
B
The
open
delimited
libraries
will
support
out
of
the
box
with
all
the
popular
open
source,
backends,
say
Jaeger
and
zip
in
for
tracing
promises
for
metrics,
and
also
we
will
use
the
w3c
trace
context
for
connect
relegation
and
we'll
have
an
open
wire
format
for
tracing
metrics
and
logs.
There
is
no
really
standard
there,
but
that's
also
important,
let's
say
for
openness
and
for
future
proofing.
B
What
we
call
the
open
sensor
service
today,
income,
the
open,
telemetry
agen,
the
collector
already
supports
all
popular
open
source
and
even
commercial
backends
for
tracing
and
metrics.
Primarily
today
it
the
agent
helps
in
a
few
ways:
listen
the
couple,
some
of
or
remove
some
other
functionality
from
the
client
libraries
and
how
the
client
libraries
be
simpler
and
like
have
a
few
things
to
worry
about
there.
B
B
Let's
say
like
envoy,
you
can
even
actually
have
the
instrumentation
built
into
the
binary
and
you
don't
even
have
to
recompile,
because
you
can
configure
well,
you
send
the
data
from
the
agent,
and
also
there
is
even
what
has
been
functionality
like
for
buffering
with
ties
for
tail
based
sampling
that
already
exists
in
the
collector
service.
That
will
also
be
in
open
telemetry.
A
Right,
it's
done
with
the
static
portion
of
this
event.
This
is
an
elephant
in
the
room,
the
the
elephant,
the
room
for
any
project
like
this
is
this
fantastic
cartoon,
I'm
sure
people
are
familiar
with
it
if
you've
been
on
the
Internet
in
the
last
10
years,
but
basically
the
joke
is
that
you
know
there
are
14
standards.
We
need
to
create
a
new
standard
to
unify
across
them.
Now
we
have
15
standards,
of
course,
here
we're
dealing
with
smaller
numbers,
but
the
problem
still
remains.
A
The
way
that
we're
trying
to
do
that
I
mean
a
lot
of
us
have
worked
in
this
I've
worked
in
the
space
for
15
years
now.
I
have
a
lot
of
ideas.
I
have
a
lot
of
regrets.
Pokken,
tracing
and
I
want
to
create
a
new
project,
that's
totally
ideal
like
Greenfield,
and
we're
not
doing
that.
We're
actually
throwing
out
all
of
our
hopes
and
dreams,
squashing
them
under
our
feet
and
creating
a
project
that
is
solely
like
focus
on
backwards
compatibility.
A
But
just
like
the
least
sexy
thing
to
make
your
main
design
goal,
but
that's
kind
of
the
main
design
goal.
The
the
goals
for
the
year
are
to
make
this
backwards-compatible.
The
way
to
avoid
the
standards
issue
from
the
xkcd
cartoon
is
to
have
some
kind
of
demonstrated,
enforceable,
technical
backwards
compatibility
and
that's
the
main
focus
for
open
telemetry.
A
Is
we
co-developed
them
with
shims
that
are
basically
required
to
have
open,
tracing
and
open
census,
instrumentation
accepted
alongside
open,
telemetry
and
instrumentation
in
the
same
process?
We're
also
going
to
guarantee
compatibility
with
open
tracing
open
census
for
multiple
for
two
years
after
this
kind
of
official
read-only
sunsetting
of
them
later
this
year?
So
what
this
means
in
practical
terms,
if
you
want
to
actually
instrument
production
software
today,
like
literally
today,
you
should
still
use
open,
tracing
or
open
census
and
you're
not
going
to
get
left
in
the
dust.
A
If
you
want
to
contribute
to
a
project,
that's
creating
telemetry
for
everyone,
then
you
should
contribute
to
open
telemetry
like
I
suggest.
Active
development
on
the
API
themselves
should
be
focused
in
open
telemetry,
but
if
you
want
to
adopt
tracing
or
metrics
or
whatever,
you
should
continue
to
use
open,
tracing
an
open
census,
probably
for
the
summer.
A
Our
goal
in
the
long
term
obviously
is
to
have
only
one
project
to
avoid
to
xkcd
scenario
and
to
have
this
broad
surface
area,
and
we
want
to
have-
and
we
already
do-
have
very
open
governance.
So
the
people
who
are
here
today
are
basically
the
people
who
could
fly
out
here,
but
we
have
a
governance
model.
That's
actually
essentially
lifted
from
kubernetes,
with
nine
different
seats
that
will
be
elected,
no
benevolent
dictators
for
life,
a
lot
of
rotation
requirements
about
the
maximum
representation
from
any
one
vendor,
etc,
etc.
A
So
this
project
will
be
safe
from
the
influence
of
any
sneaky
vendors,
trying
to
move
in
one
direction
or
another
and
and
I
think
will
hopefully
be
a
model
of
how
projects
like
this
can
be
administered
just
from
a
ecosystem,
standpoint,
yeah,
so
I
think
that's
I,
just
scooped
myself.
If
you
want
to
read
about
this
stuff,
you
can
I
did
want
to
make
a
little
plug
for
this.
So
this
stuff
sounds
fun,
I,
think
it's
fun,
but
I'm
super
biased.
A
You
can
easily
become
a
contributor
to
open
telemetry,
there's
a
lot
of
work
to
do,
given
the
some
credibly
wide
scope
with
a
project
and
we'd
love
to
have
more
members
involved
and
really,
as
probably
I,
think
nine
or
ten
languages
we're
targeting
this
here.
Something
like
that.
There's
a
lot
of
work
to
do
and
it's
pretty
fun.
So
if
you
want
a
spare
spare
time
project,
we
have,
we
have
work
for
you
and
it's
not
difficult.
A
C
A
D
A
E
Hi
my
name's
Steve
Flanders
I'm
head
of
product
and
experience
that
the
start-up
omniscient
with
Spiros
and
then
working
in
the
observer,
observability
cloud
native
space
for
a
while,
previously
at
VMware,
working
on
log
analytics
and
now
helping
contribute
to
open
census.
The
collector
agent
and
client
libraries
I'm.
F
A
F
Yes,
so
yeah,
the
question
was
about
context,
propagation
headers
and
particularly
in
reference
to
w3c,
header
and
and
I
think
you'd
also
asked
you
know,
obviously
we're
standardizing
on
this,
but
we'll
other
things
involve
the
path
of
some
of
your
requests.
Like
proxies
or
or
other
components.
Will
they
interact
with
this
and
will
they
will
they
also
standardize
on
it?
I
think
there's
there's
two
aspects
to
this.
The
first
is
like
yes,
I,
think
I.
F
Secondly,
you
I
think
you
also
made
mention
of
like
mixed-mode
environments,
where
you
might
have
pieces
of
your
application.
That
used,
like
other
headers,
obviously
I,
think
an
open
set.
I
know
an
open
census
and
I
think
an
open
tracing.
You
had
options
to
change
the
header
that
you
used
open
census
historically
by
default,
use
the
w3c
format,
but
you
can
go
use
the
Zipkin
format
or
something
else.
A
G
A
See
yeah,
so
the
concern
is
that
if
something
drops
the
w3c
header
along
the
way,
then
you
break
your
traces.
That's
the
basic
concern.
Yeah
I
mean
I
would
emphasize
this.
What
Morgan
said
I
mean
as
far
as
I
can
tell
the
support
for
w3c.
It's
important
for
projects
like
open
telemetry
to
embrace
it,
but
it's
not
to
the
exclusion
of
other
ways
of
propagating
the
contexts
around.
It
is
a
the
challenge
for
distributed.
Tracing
was
actually
context.
A
Propagation,
the
tracing
part
where
you
record
timing
and
all
that
isn't
nearly
as
difficult
it's
getting
the
context
propagated
everywhere.
So
I
don't
want
to
minimize
the
effort,
that's
involved,
but
it's
not
so
much
about
formats,
it's
more
about
code,
just
correctly
taking
stuff
from
ingress
and
following
it
through
to
egress.
Like
that's
the
part,
that's
been
really
challenging
and
I
believe
that
at
least
the
best
of
my
knowledge
there's
no
particular
reason
that
an
intermediary
that
doesn't
use
that
specific
format
couldn't
be
compatible
with
this
effort.
A
E
So
I
mean
today
I
review
the
questions
I.
Thank
you.
Thank
you.
So
the
question
is
around:
have
a
Greenfield
project
micro-services
base
looking
to
add
observability
telemetry
data,
including
logs
metrics
and
traces,
if
you're
just
getting
started,
what
should
you
should
you
use
open
telemetry?
Should
you
use
open
census,
use
open
tracing?
What
are
your
options
so
today
opens
limit
tree
is
not
ready
yet
to
consume.
You
can
definitely
contribute
to
it.
There's
the
Java
client
libraries
being
ported
over
right
now,
so
some
of
that
is
often
available
in
the
repo.
E
Yeah,
so
that's
that's
four
of
the
five
top
languages
that
open
tracing
an
open
census
support
today
and
will
be
for
the
five
top
languages
that
will
be
an
open,
flim
entry
to
start
with
as
well.
The
goal
is
to
get
those
to
production,
ready
quality
by
the
September
date
that
was
listed
on
the
milestones
and
the
slide
previously,
so
that
will
be
coming
soon
and
you
should
definitely
stay
abreast
of
those
changes
and
get
involved
in
the
community.
E
But
if
you're
looking
to
get
started
today
like
if
you're
like
I,
need
traces
or
metrics
today,
then
your
options
are
open,
tracing
and
open
census.
Both
of
them
provide
a
rich
equals
ecosystem
and
rich
integrations,
depending
on
the
languages
that
you're
using
and
the
frameworks
that
you
rely
on.
Both
of
them
will
offer
a
bridge.
So
if
you
leverage
either
one
of
them
today,
you
will
have
a
way
to
get
to
open
telemetry
and
it
will
be
backwards
compatible.
So
that's
kind
of
critical.
E
It
means
that
you're
not
going
to
be
wasting
effort,
even
if
you
do
use
open,
tracing
or
open
census.
Today
it
will
fully
work
with
open
telemetry.
There
will
be
work
necessary
to
make
that
transition
to
the
open,
telemetry
libraries
eventually
once
the
Sun
setting
is
complete,
but
you
have
time
to
do
that.
So
it
sounds
like
in
your
case.
You
want
to
start
with
logs
and
go
to
metrics
then
go
to
traces.
E
In
that
case,
one
option
that
you
have
is
open
census
because
it'll
give
you
the
metrics
aspect,
but
you
could
still
use
open
tracing
for
the
tracing
aspect
when
you
get
to
that
step.
There's
no
reason
why
you
can't
use
both
right.
So
it
comes
down
to
what
your
your
business
requirements
are.
Gonna,
be
in
terms
of
priorities.
Typically
from
a
micro
services
standpoint,
we
often
see
the
opposite.
Most
people
start
with
traces
is
the
foundation
and
actually
before
even
traces
is
context.
E
Propagation
like
we
were
talking
about
earlier,
because
just
enabling
context,
propagation
aller
allows
you
to
do
correlation
and
context
of
your
micro
services
based
architecture,
whether
you
use
traces,
metrics
or
logs,
and
then
you
can
actually
enrich
the
data,
so
you
can
add
like
tracing
information,
the
trace
IDs
span
ID
into
logs.
That's
very
powerful,
so
I'd
say
that
nothing
prevents
you
from
getting
involved
today.
There's
plenty
of
resources
out
there
and
all
the
communities
are
very
active
on
gator
or
slack.
A
Well,
introduce
Isabel
in
a
second
we're
just
trying
to
well
I
totally
so
you
haven't
said
so.
Your
company
yeah
that
I
just
want
to
make
sure
I
understand
the
question
you're
asking
how
your
customers
are
often
using
some
kind
of
a
traditional
EPM.
You
mentioned
dynaTrace,
AppDynamics,
New,
Relic
and
I.
Think
you're
wondering
if
you
adopt
open
tracing
open
census.
Whatever
are
your
customers
going
to
be
able
to
see
through
your
software
in
their
own
APM?
Is
that
correct.
A
H
So
I
broke
a
time
trace,
and
that
is
that
is
our
goal,
so
we
are
bringing
ourselves
actively
into
the
development
of
open
telemetry,
because
the
goal
is
that,
even
though
we
use
dynaTrace,
which
uses
fully
automatic
instrumentation,
you
can
also
augment
this
with
manual
instrumentation
with
open
telemetry,
and
this
should
go
together
and
merge
together,
and
you
should
see
this
also
in
our
product.
It's
an
eye-opener.
Yes,.
A
He
said
yes,
last
thing,
I'll
add
just
briefly.
It
sounds
like
your
software's
is
being
basically
shipped
on
pram
or
an
a/v
PC
or
whatever
I
would
love
to
see
us
get
to
a
point
where
blackbox
SAS
is
also
partially
instrumented,
so
that
you
can
see
through
at
least
to
understand
how
it's
working
that
involves
standards
that
haven't
been
proposed
yet,
but
that
would
be
great.
Can
we
just
take
a
quick
break
to
introduce
as
eval?
Do
you
want
to
just.
I
F
Yeah,
do
you
want
me
to
answer
that,
so
the
question
was
about
the
choice
to
turn
open
census
and
open
tracing
into
open,
telemetry
versus
continuing
to
evolve
the
existing
projects,
and
it's
it's
interesting.
You
ask
that,
like,
certainly
when
we
started
having
conversations
late
last
year
about
what
we
should
do
to
work
together.
Better
one
of
the
options
that
came
up
was
hey,
we'll
adopt
the
same
API,
but
keep
two
separate
projects
and
I
think
that
could
have
been
a
reasonable
option.
I
think
there
were
a
number
of
benefits
of
doing
a
complete
merger.
F
One
was
we
wouldn't
be
sharing
a
dependency
cross
projects
which
can
be
annoying
when
different
projects
wanted
version
things
at
different
times.
It
make
sure
everything
stays
in
sync.
The
other
was
like,
frankly,
between
both
these
projects,
the
w3c
and
others
like
it's,
mostly
the
same
people
who've
been
working
on
all
these
things
like
it's.
It
was
already
trending
towards
a
single
community
and
it
was
kind
of
arbitrary
that
the
two
projects
were
divided
I
personally
I
view.
F
This
is
the
most
optimal
outcome:
the
complete
merger,
because
it
means
there's
no
division
of
of
sort
of
goals
or
sort
of
you're
less
likely
to
get
certain
people
going
off
on
tangents
or
taking
the
projects
further
away,
because
they're
involved
in
a
single
community
of
a
single
government.
It's
important
everything
else.
I
Also
from
an
instrumentation
perspective,
it
makes
makes
it
easier
to
add
instrumentation
for
now
open
telemetry,
previously
open
tracing
or
the
open
census
into
existing
libraries
and
frameworks.
So
if
you
want
to
add
instrumentation
to
you
know
my
sequel
or
Hadoop
or
kubernetes,
now
previously,
there
was
kind
of
this
big
question
of
okay,
should
they
go
with
open,
tracing
or
open
census?
The
idea
is
that
now
that
now
there's
kind
of
one
canonical
choice
rather
than
this
ambiguous
option
of
one
or
the
other.
D
D
I
Headers,
but
something
we've
also
kind
of
started
talking
about
informally,
and
that
we
should
move
to
a
slightly
more
formal
discussion.
Soon
is
having
kind
of
more
standard
patterns
for
operation
names
that,
for
example,
all
HTTP
clients
would
kind
of
be
expected
to
have,
let's
say,
HTTP,
method
path,
or
something
like
that,
not
necessarily
that
exact
pattern,
but
something
rather
than
you
know
some
that
patterns
I'm
having
just
HTTP
so
I'm
having
just
the
the
method,
something
more
consistent
across
across
libraries
or
frameworks.
D
So
the
question
was:
if
we
are
thinking
to
standardize
on
the
context
API
that
is
going
to
be
used
mostly
inside
the
application-
correct,
not
not
on
the
on
the
wire,
because
that's
the
trace
context
that
we
are
talking
about,
and
so
we
we
in
general
we
try
to
to
work
with
the
best
thing
that
language
offers.
For
example,
as
you
mentioned,
NGO
has
a
notion
of
a
context
very
well
defined
that
we
we
have
to
use
that
one
lesson
recently:
Python
added
the
convar.
It's
called
I
think
it's
since
three
six.
D
D
Where
there
is
nothing,
that's
where
we
try
to
come
up
with
a
with
a
small
light
API
for
this,
and
we
I
think
there
is
a
discussion
on
on
issues
in
in
open
telemetry
java,
yuri
also
wrote
a
document
about
this
thing
so
feel
free
to
participate
in
the
discussion.
But
in
the
end
for
languages
that
we
don't
have
a
context,
we
have
to
have
a
package
called
context,
that
user
can
use
and
other
other
applications
or
other
libraries
can
also
share
the
same.
The
same
context.
J
D
A
There's
a
paper
called
pivot
tracing.
That
was
an
academic
paper
that
describes
a
very
beautiful
like
model
based
on
a
standard
context,
object
I,
think
we
have
tried
to
factor
it
out
as
its
own
from
a
just
a
code,
dependency
standpoint.
The
context
stuff
is
like
the
base
layer
that
everything
else
is
built
around
I,
don't
actually
recall
whether
or
not
we're
building
out
like
a
separate
jar
file
for
context
or
not,
but.
D
A
Haven't
decided
yeah
I
mean
I
would
love
to
see
it
move
in
that
direction.
I
think
in
terms
of
like
the
project
from
a
technical
standpoint,
we
would
like
to
see
that
thing
take
no
dependencies
and
be
as
small
as
possible,
an
actual
fact
I'm,
not
sure
if
it's
going
to
be
possible
in
September
to
depend
on
it,
but
on
the
tree
just
the
context
piece
without
bringing
and
spans
and
all
that
kind
of
stuff
as
well,
I'm,
not
sure
if
that
will
be
feasible,
but
in
terms
of
technical
direction.
A
D
So
far
there
is
no
real
activity
on
that
project.
There
is
not
yet
a
format
proposed
by
them,
but
definitely
we
would
support
that
format
once
that
is
available.
So
there
is
another
problem
that
they
haven't
defined
protocol.
They
just
define
a
format
which
is
a
bit
of
a
problem
for
us
to
say
that
we
support
it,
because
there
is
no
way
to
test
that
you
support
it,
especially
if
you
don't
have
a
protocol.
A
No
yeah
I
mean
I,
think
it'd
be
really
dangerous.
If,
given
the
slide,
we
showed
about
open
telemetry
scope.
If
we
now
say
we're
going
to
absorb
every
project
that
touches
on
the
end
of
that
stuff,
I
think
we
would
spend
all
of
our
time
making
people
very
angry
on
Twitter.
So
it's
not
our
intention
to
strong-arm
anyone
into
like
becoming
part
of
open,
telemetry
I.
A
Think
if
there
are
formats
that
we
can
adopt,
that
would
make
it
easier
to
adopt
open
telemetry,
then
we'll
adopt
them
so
I
think
open,
I'm,
actually
friends
with
some
of
the
people
who
started
up
in
open,
metrics
and
I'd
like
to
see
them
succeed.
If
they
succeed
under
whatever
flag,
they
want
to
fly,
that's
great,
and
we
can.
We
can,
you
know,
adopt
the
formats
they've
created.
A
A
Seriously,
yeah
because
you
know
just
the
actual
names
of
things
and
Google
Cloud
and
I
see
so
open.
Metrics
does
not
solve
that
problem.
It's
the
most
first
thing,
I
should
say:
I
mean
open
metrics.
As
about
no
saying
it's
really,
it's
like
a
protocol,
no,
not
a
pro.
It's
a
format
without
a
protocol
to
describe
the
transfer
of
metric
data
doesn't
say
a
word
about
what
metric
should
be
called
or
anything
like
that.
What
you're
describing
is
very
valuable,
I
think,
especially
in
the
world
we
live
in.
A
Where
they're
you
know
three
or
four
like
major
public
clouds
that
aren't
going
to
go
away
and
you
poured
your
application
from
one
to
the
other
or
at
both
the
same
time
and
everything
breaks
that
sort
of
standardization.
Would
it's
exactly
the
sort
of
thing
I'd
like
to
see
open,
telemetry
be
involved
in
I,
just
want
to
make
sure
that
people
don't
misunderstand
our
intention
to
dictate
how
everything
works
across
the
entire
industry.
I
think
we
would
love
to
be
a
home
for
that
sort
of
effort
to
make
sure
that
people
refer
to.
A
You
know
any
aspect
of
container
health
with
the
same
language
that
that
sounds
like
an
open,
phlegm
Ettore
initiative
to
me,
but
if
someone
else
does
at
first
we'll,
happily,
you
know
adopt
that
terminology,
but
open
metrics
isn't
going
to
solve
the
problem.
You
just
subscribed.
Unfortunately,
yeah
yes,.
I
E
So
the
idea
would
be
like
for
traces,
the
w3c
trace
context.
Header
format
will
be
the
de
facto
standard.
There
are
other
ones
up
there
as
if
can
Yaeger
you
can
use
those,
that's
fine
that
will
be
supported
by
open
slimming
tree
as
well,
but
there'll
be
best
practices
of
like
if
you're
starting
in
a
Greenfield
environment,
you
should
probably
be
looking
at
the
w3c
standard
first.
That
is
the
one
that
most
people
are
going
to
be
consolidating
on
the
other
aspects.
E
Around
data
collection
in
generals
like
client,
libraries
or
integrations
into
different
frameworks
instead
of
having
like
open
census
and
open
telemetry,
where,
if
you,
the
Hadoop
example
is,
was
great,
which
one
do
I
add.
Now
it's
not
a
question.
You
add
open
telemetry,
that's
the
one
you're
going
to
add,
and
that
will
be
the
standard
that's
available
and
then
with
something
like
the
open
telemetry
service
which
will
be
coming
soon
that
actually
handles
translations
into
and
out
of
different
formats.
E
E
F
A
bit
onto
that
just
specifically
on
the
top
of
correlation,
so
this
is
something
that
we
like
specifically
just
like
the
Google
contributors.
Just
for
reasons
on
the
Google
cloud
like
we
are
very,
very
interested
in
at
the
moment.
At
you
know,
historically,
various
APM
tools
have
often
struggled
correlation
where
you
get
a
metric,
but
then
jumping
for
traces
related
to
that
metric
is
not
always
easy.
F
It
is
some
some
of
them
it's
not
at
all,
or
even
correlating
things
like
a
system
metric
to
an
application
metric
right
like
the
latency
of
an
endpoint
to
the
machine.
You
know
machines
that
were
actually
sending
that
data
and
correlate
may
have
like
the
CPU
consumption
of
those
machines.
We
are
doing
work
like
right
now
in
the
open
census
agent,
which
is
gonna,
move
into
open
telemetry,
to
make
that
a
lot
easier,
whether
it's
being
able
to
get
exemplars
races
out
of
things
like
a
latency
metric.
F
So
you
can
actually
get
that
like
hard
linkage
there
to
ensuring
that
the
resources
that
we
capture
system
metrics
from
what
the
agent
are
well
defined
and
those
were
also
correlated
with
traces
and
metrics
coming
out
of
your
application,
because
you're
right
like
at
the
moment,
the
correlation
story
is
not
so
great.
We've
done
a
bit
of
work,
historically,
an
open
census.
We've
done
some
work
to
get
logs
correlated
for
traces,
but
the
whole,
like
resource
story,
is
being
like
super
wishy-washy
for
a
while,
which
is
why
we're
trying
to
fix
that.
A
It's
a
really
good
question
and
I
mean
you're
kind
of
asking.
What's
the
value
prop
here
anyway,
like
generating
bunch
of
data,
doesn't
deliver
any
business
value
unless
there's
some
kind
of
a
PM
or
whatever
that
takes
that
and
I
don't
know
answers
an
actual
question
about
the
relationship
between
CPU
and
latency.
You
is
that
correct.
My
restating
of
your
question
yeah.
K
K
A
A
I
don't
mean
open
telemetry,
but
like
our
commercial
products,
we're
trying
to
solve
that
problem
and
at
the
moment
the
data
stream
that's
coming
out
of
these
applications
is
insufficient
to
do
what
you're
describing
in
some
cases,
I
think
that
they're
missing
they're
missing,
join
keys,
basically
you're,
basically
talking
about
as
a
joint
like
you
want
to
join
metrics
and
traces,
for
instance,
and
the
keys
that
you
would
join
on.
This
literally
aren't
present
and
a
lot
of
the
data
that
we
get.
So
you
can
do
things
like
a
I
like
the
earlier
question.
A
Although
that's,
it
would
be
a
lot
easier
if
the
data
was
cleaner,
so
I
think
part
of
the
idea
with
open
telemetry
is
to
is
to
generate
a
much
cleaner
signal
that
has
the
necessary
information
in
it,
so
that
we
can
even
build
that
stuff
that
the
prop
ilike
the
open
source
ecosystem
in
many
ways,
but
the
fact
that
we've
factionalized
metrics
traces
and
logs
as
three
separate
tools.
It's
a
huge
problem,
a
huge
problem.
It's
fine
from
a
data
standpoint,
but
from
a
solution
standpoint.
A
A
So
I
think
part
of
the
issue
with
the
with
the
silo
ization
of
the
solution
is
that
the
data
stream
isn't
very
good,
so
I
think
open
telemetry
will
help
by
generating
a
higher
quality
data
stream
with
better
correlation
embedded
in
it
and
then
I
think
we'll
see
open
source.
Add
integration
features
once
the
data
is
available,
but
right
now
just
the
data
itself
isn't
sufficient,
so
that
that's
where
open
telemetry
I
think
will
help
with
that.
Does
that
make
any
sense
I
so
make
sure
you
get
good
coverage?
Can.
D
Okay?
So
the
way
how
we
plan
so
G?
Our
piece
is
a
critical
product
for
Google
as
well
and,
as
you
know,
I
work
for
Google
as
well.
So
the
the
way
how
we
plan
to
do
it.
Grdc
already
has
integration
with
dopant
sensors,
natively,
it's
in
Java
and
C++
and
we'll
add
in
all
the
languages,
because
we
use
it
internally
in
Google.
The
the
plan.
How
we
do
to
do
the
transition
will
be
the
same
path
that
we'll
use
for
all
the
users.
A
There's
only
one
microphone
in
this
room.
Sorry
I
also
can
I
repeat
for
the
recording.
What
was
the
elastic
project
called
elastic
comment,
schema
Stan,
so
the
newer
and
whether
there's
a
plan
to
integrate
open
tracing
there.
I
don't
speak
for
Avenue
er,
but
I
do
know
the
people
on
that
project
from
stripe
and
I
know.
A
A
So
the
question
is
about
whether
we're
trying
to
actively
petition
you
said
for
self
a
petition
vendor
is
like
dynaTrace
since
Donna,
etc
to
adopt
our
api's
instead
of
or
in
addition
to
their
own
I,
certainly
know.
Coercion
is
involved.
I
think
dynaTrace,
you
know,
is
interested
in
participating
this
effort,
most
I,
most
offenders,
and
certainly
speaking
for
myself
as
a
vendor
or
as
somebody
worse,
that
a
vendor
I'm
a
human
being,
not
a
vendor.
A
The
sorry
really
tired
flew
in
yesterday
from
California
the
the
there's
very
little
joy
in
trying
to
instrument
the
entire
world
as
a
vendor,
and
we
can
spend
a
lot
of
resources
doing
that
so
I
think
most
offenders
would
actually
like
to
get
out
of
the
instrumentation
business
and
focus
on
building
their
solutions.
So
typically,
we
don't
feel
like
we
have
to
strong-arm
anyone
I
think
if
these
projects
develop
traction,
it's
not
that
difficult
to
bind
to
them.
A
So
what
we
saw
with
open
tracing
and
open
census
was
pretty
wide
support
from
vendors
that
you
know
had
reasonable
staffing,
because
it's
usually
like
a
relatively
low
left
to
integrate
with
these
things,
but
I
don't
think
that
we're
expecting
any
vendor
to
orphan
and
ignore
their
own
integration.
This
is
just
considered
additive,
so
typically
they
will
say
we
support
open,
telemetry
and
open
census
and
open
tracing
and
open
whatever
and
our
own
thing
and
everything
else.
And
then
we
get
all
the
data
into
our
solutions.
A
D
The
question
was:
if
vendors
can
use
open,
telemetry
as
a
foundation
and
build
their
automatic
or
magical
experience,
instrumentation
on
top
of
open,
telemetry
I.
Think,
ideally,
I
would
like
to
see
this
and
I
think.
Ideally,
that
will
also
help
them,
because
they
will
have
less
code
to
maintain.
But,
realistically
speaking,
I
think
there
is
a
lot
of
investment
that
they
did
in
that
code
and
it
will
be
very
hard
for
them
to
to
switch.
But
ideally
yes,
that
that
will
be
the
ideal
world.
D
I
think
the
new
vendors
especially
lies
definition
and
all
the
these
new
vendors.
They
that's
what
they
are
doing
essentially,
but
for
for
more
established
vendors
like
dynaTrace,
nearly
data
dog
and
all
the
the
very
well
established
vendors
I
think
they
they'll
have
a
bit
of
a
hard
time
to
to
do
that,
especially
for
the
complexity
of
the
code
that
they
have.
A
D
C
I
agree
with,
with
everything
being
said,
we're
we're
super
interested
in
making
it
really
easy
to
get
telemetry
out
of
applications
so
that
we
can
do
really
interesting
stuff
with
that
data
inside
our
SAS
solution.
So
we
support
open,
open,
telemetry
and
we're
really
looking
forward
to
that
being
something
that
reduces
your
burden
in
our
burden
as
well
as
far
as
using
like
open
telemetry
agents
or
those
things
as
a
base.
You
know
we'll
see,
I
think
right
now
we
have
things
like
security.
I
And
just
reframing
it
a
bit
also
so
been
mentioned
before
that
instrumentation
is
just
a
really
really
big
job
and
right
now,
with
kind
of
each
vendor
doing
the
same
instrumentation,
again
kind
of,
but
with
their
own
vendor
specific
agents
and
so
on.
It's
kind
of
counterproductive
for
all
of
us,
so
I
think
that,
rather
than
petitioning
vendors
to
use
open,
telemetry,
it's
more
about
incentivizing
them
right
petition
them
to
step
to
help
staff
us
with
resources
or
particularly
humans.
F
Yes,
so
there's
it
takes
both
open
tracing
and
open
census,
so
it
maintains
the
open
census,
implementation
and
the
exporter
interface
for
APM
vendors
that
want
to
just
provide
an
exporter
and
have
open
telemetry
do
all
the
heavy
lifting
but
like
open
tracing.
You
can
also
just
if
you're,
an
APM
vendor
you
can
also
just
bind
against
the
API
is
that
are
normally
used
for
instrumentation
and
provide
your
own
implementation
and
provide
your
own
tracer
and
just
go
from
there.
So.
D
To
clarify
that
we
took
the
lessons
from
the
two
projects
and
we
understood
how
important
is
to
have
a
standard
artifact
just
for
the
API
perspective,
so
we'll
have
a
pure
API
artifact
and
then
we'll
have
a
standard
implementation
provided
by
the
open
telemetry,
which
will
be
very
close
to
what
open
sensors
provides
today
with
exporters
and
in
place
in
process
selection
of
the
vendor.
If
you
want,
we
also
gonna
offer
the
agent
solution.
D
So
if
you
want
to
use
as
a
sidecar
and
that's
useful,
as
during
the
presentation,
Spiro
said,
for
example
in
case
of
HBase
or
amboy,
where
they
wanna,
they
don't
wanna
may
they
may
not
want
to
allow
you
to
do
dynamic
loading
of
exporters
or
anything
like
that.
So
they
will
say:
hey
we're,
gonna
export
using
the
open
telemetry
protocol
and
then
the
sidecar.
Will
everyone
will
deploy
the
the
product
with
the
sidecar,
well
dig
and
choose
whatever
then
that
they
want
to
expose
this
telemetry
to.
G
D
Will
take
this
because
it's
again
frugal
part,
we
are
in
a
huge
amount
of
discussion
with
this
tio.
Unfortunately,
they
they
have
a
big
deadline
for
July,
but
after
July
we'll
try
to
move
everything
to
open
telemetry,
so
they
will
move
to.
They
will
move
to
us
with
everything
and
we
are
also
not
ready
with
open
telemetry
until
July.
So
it's
it's
a
good
timing
on.
A
I'm
no
comment,
yet
it's
difficult
to
to
get
a
github
name,
that's
already
taken
it
turns
out,
even
if
it's
completely
dormant
has
no
commits.
It's
still
really
difficult
to
get.
If
anyone
knows
new
Medicare
hub
and
they
want
to
do
us,
a
favor
try
to
convince
them
to
release
open
telemetry,
but
open
telemetry
on
github
has
a
Java
repo
that
actually
has
a
lot
of
activity
in
it,
and
you
can
see
where
things
are.
Oh,
oh
yeah
specification,
repo.