►
Description
Getting Started with OpenTelemetry - Ted Young, Lightstep
This talk introduces OpenTelemetry to developers and operators. First, learn about each open telemetry component, the core concepts, and how they all fit together to provide flexible and robust observability. Second, learn the easiest way to set up and deploy opentelemetry across your entire system.
A
A
All
of
these
signals
on
the
back
end,
in
addition
to
the
data
collection,
open
telemetry,
provides
a
data,
processing
and
pipelining
facility
that
allows
you
to
change
data
formats,
manipulate
your
data,
scrub,
it
etc,
etc.
All
the
tools
you
need
to
build
a
robust
telemetry
pipeline
in
a
modern
system.
A
A
A
A
A
A
A
We
have
easy
installers,
it's
usually
just
a
line
or
two
of
code
or
in
some
cases,
even
a
command
line,
configuration
to
get
everything
installed
and
going.
Okay.
Let's
just
show
how
easy
it
is
to
get
started
by
trying
it
in
java.
So
I've
got
my
pet
clinic
app
here.
This
is
just
a
java
sample
application
and
I'm
going
to
just
boot
it
up.
So
you
can
see
what
it
looks
like
so
java
jar
pointing
at
target
there
we
go.
So
that
starts
the
application
up
it's
java,
so
it
might
take
a
bit.
A
There
we
go
looks
like
we're
off
to
the
I
go
here
and
take
a
look
there.
It
is
there's
pet
clinic
click
around
very
nice.
Okay
kill
that
app.
Now
I've
already
downloaded
the
open
telemetry
java
agent,
it's
wrapped
in
a
little
launcher.
That
makes
it
easier
to
work
with
light
step,
but
it's
basically
just
the
java
agent,
and
so,
if
we
just
attach
that
to
our
prior
command.
A
A
Cool-
and
this
exception
you
can
see-
because
I
actually
triggered
an
exception
here-
this
will
trigger
an
exception
in
the
app
and
since
all
of
this
is
hooked
up
into
my
account
in
light
step,
if
I
go
here
in
light
step
and
go
have
a
look
at
our
explore
page
boom,
I
can
see
all
this
stuff
coming
in
from
our
example:
pet
clinic
gap.
Okay,
so
that's
the
basics!
A
A
Okay.
So
let's
look
at
a
quick
example,
so
we
understand
the
kind
of
transactions
we're
talking
about
here.
So
imagine
you
have
a
mobile
client
that
wants
to
upload
a
photo
and
a
caption
okay,
so
this
client
will
make
a
request
to
a
server
quote
unquote,
but
that
server,
of
course,
will
be
a
lot
of
servers.
A
A
A
So
this
view
here
is
more
of
a
service
map
approach
to
looking
at
this
transaction.
Let's
change
gears
and
look
at
this
transaction
from
the
perspective
of
a
call
graph
in
this
graphic,
each
line
represents
an
operation.
The
length
of
the
line
represents
how
long
that
operation
took,
and
we
can
see
how
these
operations
are
connected
to
each
other
via
network
calls.
Now,
as
an
operator
there's
a
number
of
things
we
care
about
when
we're
observing
our
system.
A
First
of
all,
we
care
about
latency.
Why
is
it
slow?
Is
such
a
cranky
question
to
answer
so
when
we
look
at
our
transactions,
we
want
to
know
where
the
time
went
specifically,
which
sub-service
actually
was
spending
the
time,
and
where
did
we
spend
time?
Waiting
next,
of
course,
is
that
we
care
about
errors.
A
A
A
A
Imagine
we
have
two
servers
and
they're
connected
to
each
other
via
network
request,
all
of
open,
telemetry's
indices
and
other
transactional
data
is
stored
in
an
object
called
the
context.
This
context
object
follows
the
flow
of
execution
through
the
program
when
a
transaction
moves
from
one
service
to
the
next
via
a
network
call.
All
of
these
key
value
pairs
must
come
along
as
well
sending
along
the
contents
of
the
context
object
as
metadata
on
the
network
request
is
called
propagation
on
the
client
side.
A
A
The
first
header
is
called
trace
context.
It
has
two
header
fields.
The
first
one
is
trace
parent.
The
second
one
is
trace.
State
trace
parent
contains
several
specific
ids
that
are
important
to
tracing.
First
of
all,
it
contains
the
trace
id.
The
trace
id
is
the
transaction
id.
This
is
the
id
that's
going
to
be
stapled
to
every
event
and
operation
in
your
system.
A
The
next
id
is
the
span
id.
This
id
represents
the
parent
operation
of
your
current
operation,
so
every
event
occurs
not
only
within
a
transaction
but
also
within
an
operation,
and
those
operations
have
unique
ids,
there's
also
a
sampling
flag
to
check
whether
sampling
has
been
enabled,
and
then
there's
a
second
header
called
trace
state
which,
honestly
you
don't
really
need
to
worry
about.
This
header
is
just
for
internal
details
for
tracing
systems
to
share
with
each
other.
A
The
real
important
part
is
that
by
standardizing
these
headers
through
the
w3c,
we
can
get
everyone
to
start
agreeing
on
what
headers
we're
actually
using
what
value
types
we're
actually
using,
and
this
is
going
to
be
really
important
for
something
that
depends
on
interoperation
as
much
as
distributed
tracing
does
okay,
so
those
are
the
tracing
specific
headers.
There's
another
set
of
headers
called
baggage
and
baggage
is
for
arbitrary
context.
Propagation
literally
baggage
headers
can
carry
arbitrary
key
value
pairs.
The
entire
point
of
baggage
is
just
to
propagate
context,
from
service
to
service.
A
You
gain
access
to
a
project
id
and
while
later
services
in
the
transaction
may
not
directly
have
access
to
that
project
id
you
may
still
want
to
index
some
of
their
operations
or
metrics
by
project
id,
in
which
case
you
can
throw
that
project
id
into
baggage
and
then
pull
it
out
of
baggage
later
and
attach
it
to
your
operations
and
metrics,
and
that
is
the
power
of
open
telemetry,
so
we're
getting
close
to
the
end.
Let's
do
a
recap
if
you
want
to
get
started
with
open
telemetry.
A
The
first
thing
to
do
is
audit
your
system
and
cross-check
whether
the
languages
you're
using
are
ready
to
go
in
open
telemetry.
As
I
mentioned
before,
the
four
most
production-ready
languages
are
go
python
java
and
javascript.
Erlang
is
also
getting
ready
to
go.
There's
a
whole
bunch
of
other
languages
raiding
in
the
rings,
but
it's
best
to
go
actually
say
hi
to
the
implementation,
working
group
or
otherwise
kick
the
tires
before
rolling
the
stuff
out
into
production
because
it
really
is
still
in
beta.
A
If
you
are
interested
in
go
java,
javascript
or
python
check
out
opentelemetry.lightsip.com,
that's
where
I'm
putting
together
all
of
the
guides
getting
started
material
helper
functions,
bootstrappers
everything
to
get
started,
quick
with
open
telemetry
that
isn't
currently
baked
into
core,
but
I
would
kind
of
like
the
cncor
is
currently
going
on
opentelemetry.lightset.com,
that's
just
sort
of
where
I'm
hacking
trying
to
push
the
edges
of
understanding
how
open
telemetry
works
today
and
how
it
should
work
tomorrow.
So
there'll
be
a
lot
of
great
content
getting
added
there
soon.
A
If
you
want
to
know
when
new
content's
getting
posted,
you
can
follow
me
on
twitter,
I'm
ted,
suo,
otherwise
come
check
out
open
telemetry.
We
have
a
lot
of
meetings
every
day
of
the
week.
There's
an
open,
telemetry
meeting.
You
can
find
them
all
on
our
calendar
check
out
our
getter.
If
you
want
to
just
come
in
and
chat
and
say,
hi
we're
on
gitter
all
the
time
and
otherwise
please
kick
the
tires.
Give
it
a
shot,
give
us
feedback,
we
hope
you
get
involved.
Thank
you,
yellow,
yellow.
A
Cool,
so
this
is
my
first
time
on
hop
in
it's
not
entirely
clear
to
me
whether
people
can
use
voice.
It
looks
like
people
can
only
use
chat
for
feedback,
hi
david
good,
to
see
ya.
So,
first
of
all
any
questions
about
open
telemetry
in
general.
There's
no
dumb
questions.
It
can
be
super
basic
questions.
It
could
be
super
specific
or
techno
questions.
I'm
happy
to
answer
any
open,
telemetry
related
questions.
At
this
time.
A
And
if
we
don't
have
a
lot
of
questions,
I
actually
have
questions
I'm
trying
out
a
new
presentation
style.
This
is
actually
my
first
time
trying
to
put
it
together.
It's
definitely
a
bit
of
a
rough
draft,
but
I'm
curious
how
it
went
over.
There's
aspects
of
that
presentation
that
you
liked
things
that
you
didn't
like
or
anything
that
was
confusing
so
either
here
or
dm
me.
I'd
love
to
get
feedback,
so
jonathan
molina
asks
the
java
library
I
spoke
about.
A
It
can
actually
be
used
with
jager
or
stackdriver,
so
to
explain
what
the
open
telemetry
launchers
are
they're,
just
an
open,
telemetry
distro.
In
other
words,
if
you
use
open
telemetry
today
the
setup
code
in
particular,
it's
it's
got
a
fair
amount
of
boilerplate.
It
hasn't
really
been
packaged
up
into
something
that
makes
it
look
kind
of
nice.
A
In
particular,
there
were
some
settings
we
needed
to
touch
like
grpc,
headers
and
stuff,
so
it
was
just
a
little
ugly
to
set
up
without
wrapping
it
up.
So
that's
what
the
launchers
are.
You
can
crack
open,
open,
telemetry
and
add
any
configurations
that
you
want.
So
there's
no
reason
you
can't
use
the
launchers
with
zipkin
or
jaeger
or
any
other
system,
and
if
there
is
a
feature
that
you
think
they're
missing,
we'd
love
to
get
pull
requests
and
eventually
I
hope
to
get
something
like
the
launchers
baked
back
into
open
telemetry.
A
Cool,
so
david
mentions
that
there
used
to
be
some
competing
standards
on
open
tracing.
Can
you
help
clarify
the
difference
between
open
telemetry
tracing
and
competing
standards?
Okay.
So
when
we
talk
standards,
there's
a
couple
of
different
pieces
people
are
talking
about,
so
one
piece
is
context.
Propagation,
so
like
we
were
talking
about
in
the
video
there
is
a
protocol
for
sending
context
from
one
system
to
the
next
is
metadata
on
a
network
call
and
for
http
you're
doing
that
as
http
headers.
A
Now
there
are
several
headers
out
there
in
the
wild.
The
most
popular
is
probably
the
zipkin
b3
headers,
so
those
are
the
ones
when
it
comes
to
in
our
operation.
Today,
those
zipkin
headers
are
probably
the
most
popular.
Of
course,
every
single
tracing
system
has
their
own
custom
headers.
So
it's
sort
of
a
bespoke
landscape.
A
A
That
was
basically
everyone
in
the
distributed
tracing
community
who
really
wanted
to
work
on
a
particular
project
in
a
particular
way,
which
was
standardizing
the
language
we're
using
to
describe
systems,
and
since
we
had
these
two
projects
that
were
nearly
the
same,
both
trying
to
create
a
standard,
it
was
starting
to
turn
into
that
xkcd
comic
where
you
end
up
just
creating
17
standards,
and
so
we
ended
up
merging
those
two
projects.
So
that's
actually,
where
open
telemetry
comes
from,
it's
sort
of
the
version
2.0
of
open
tracing
and
open
census,.
A
And
david
asks
whether
open
telemetry
supports
open
tracing,
that's
correct,
open
telemetry
is
100
backwards,
compatible
with
open
tracing.
We
really
care
a
lot
about
backwards,
compatibility
not
just
between
open
telemetry
and
open
tracing,
but
also
with
any
future
version
of
the
open,
telemetry
apis.
A
A
A
A
Okay,
david's
got
a
good
question:
how
does
this
all
tie
in
with
log
monitoring,
analytics,
apm
etc
is
open?
Telemetry
is
sort
of
the
future
consolidation
of
all
these
older
disciplines,
capabilities
into
a
single
pane
of
glass
sort
of
it
really
is
about
having
the
right
context
and
the
right
indices.
That's
to
my
mind,
the
primary
difference
between
open
telemetry
and
pre-existing
logs
and
apm
solutions.
A
Obviously,
all
of
the
data
within
open
telemetry
is
structured,
so
it's
better
than
unstructured
logs,
but
compared
to
say
a
structured
logging
system,
the
distributed
tracing
and
open
telemetries,
not
really
any
different.
Except
you
have
all
these
amazing
indices
right.
You
have
a
transaction
id
and
without
some
form
of
context,
propagation,
there's
really
no
way
to
get
a
full
transaction
id.
A
You
can
get
request
ids
that
will
cover
from
one
hop
to
another,
but
if
your
system
really
starts
to
sprawl,
you
find
you
end
up
having
to
close
together
like
a
set
of
ids,
just
to
kind
of
see
what
your
transaction
looks
like.
So
having
access
to
those
extra
indices
is
really
what
pulls
distributed
tracing
ahead
of
run-of-the-mill
structured
logging.
In
my
opinion,
and
likewise
for
metrics,
the
open,
telemetry
metrics
api,
I
think,
is
actually
really
interesting.
I
think
it's
a
step
above
what
we've
seen
in
the
past.
A
So
that's
that's
the
main
difference.
So,
for
example,
an
apm
system
without
distributed
tracing
can
give
you
a
lot
of
information
about
one
service
and
what
that
service
is
doing,
but
it
becomes
hard
to
piece
together
a
complete
picture
of
your
system
once
your
transactions
start
to
involve
two
three
four.
A
A
That's
why
open
telemetry
is
really
a
telemetry
system.
There's
no
analysis
portion
of
the
system.
The
idea
is
just:
can
we
cross-index
all
of
these
different
streams
of
data
and
produce
a
canonical
data
format
that
just
has
all
of
it
in
it,
so
you
can
consume
it
as
a
fire
hose
and
that's
kind
of
novel
in
the
past
systems
tended
to
be
one
of
these
pillars
right.
A
A
I
think
it's
going
to
make
it
really
easy
for
people
to
experiment
and
build
sort
of
one-off
forms
of
analysis,
because
one
of
the
big
barriers
to
entry
is
having
to
build
this
whole
honking
telemetry
system
and
all
of
these
integrations
and
instrumentations
just
so
that
you
can
experiment
with
a
particular
form
of
analysis
and
not
not
having
to
rebuild
any
of
that
is
really
one
of
the
things
that
I
think
will
accelerate
development
of
analysis
in
the
observability
space.
So
that's.