►
From YouTube: OpenTelemetry: The Road Ahead + Meet the Co... Morgan McLean, Alolita Sharma, Ted Young, Daniel Dyla
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
OpenTelemetry: The Road Ahead + Meet the Community - Morgan McLean, Splunk; Alolita Sharma, Amazon; Ted Young, Lightstep; Daniel Dyla, Dynatrace
This session is for anyone interested in observability or OpenTelemetry to learn more about the project, and to meet and discuss our status and roadmap with maintainers! We will begin with a brief presentation of our recent releases and roadmap for the next year, followed by a panel discussion hosted by governance committee members, technical committee members, and maintainers.
A
So
welcome
everybody
to
the
maintainers
track
session
for
open
telemetry,
so
we'll
introduce
ourselves
and
we'll
get
started
with
a
very
quick
background
on
the
project,
because
I'm
assuming
most
people
here
are
pretty
familiar
with
open
telemetry.
At
this
point,
followed
by
our
current
status,
then
we'll
talk
about
the
road
ahead
and
we'll
wrap
up
with
a
q
a
amongst
maintainers.
A
So
once
we
finish
the
road
ahead
section
we'll
invite
the
maintainers
to
come
on
stage,
we've
got
a
hand
mic
here
and
then
we'll
take
questions
from
the
audience
until
they
give
us
the
boot
out
of
here.
So
to
start
with
introductions,
my
name
is
morgan
mclean,
I'm
a
director
of
product
management
at
splunk.
I've
been
with
open
telemetry
since
the
beginning
and
open
sentence
before
that.
A
B
C
D
B
The
open,
telemetry
sdk
observes
your
various
libraries
either
by
having
those
libraries
natively
instrument
themselves
or
by
installing
an
instrumentation
plugin.
You
then
export
that
data
from
the
sdk
to
a
collector,
either
running
as
a
side
car
or
as
a
pool
behind
the
load
balancer,
and
you
send
that
data
through
otlp,
which
is
open,
telemetry's
native
protocol.
B
The
collector
itself
is
a
really
awesome
swiss
army
knife.
It
takes
input
from
a
huge
variety
of
sources.
Not
just
otlp
connects
all
of
that
data
into
complex
processing
pipelines
that
you
can
write
in
order
to
do
things
like
data
scrubbing
and
enrichment
and
all
that
fun
stuff
and
then
outputs
it
again
in
otlp
or
a
variety
of
other
formats
and
what
makes
open,
telemetry
special
beyond
just
being
very
friendly
standard.
C
Thanks
ted,
I
I
guess
I'm
going
to
talk
about
sort
of
how
do
I
next
this
one
all
right,
so
I'm
gonna
talk
about
what
we've
accomplished
over
the
past
12
months
before
I
start
how
many
people
in
here
have
contributed
to
open
telemetry
in
the
past
12
months.
Can
I
get
a
show
of
hands
all
right,
pretty
good
yeah.
C
Thank
you
to
all
of
you
guys,
because
none
of
this
would
have
been
possible
without
everybody
contributing
so
for
those
that
don't
know
over
the
last
12
months,
we've
done
a
lot
of
work
on
logging,
which
is
going
to
be
completed
fairly
soon.
Here,
I
think
so
we're
excited
about
that.
We
announced
the
general
availability
of
tracing
in
open
telemetry.
Roughly
a
year
ago,
we
implemented
something
called
telemetry
schemas
which
helps
out
with
instrumentation
stability
and
upgrade
paths,
and
things
like
that.
C
We
started
a
new
client
instrumentation
sig,
which
is
working
on
building
a
lot
of
like
front-end,
instrumentations
and
stuff
like
that
and
an
end
user
working
group
to
do.
Research
on
you
know,
end
users:
what
are
their
problems
and
how
can
we
solve
them
and
as
of
this
morning,
we
announced
the
metrics
general
availability
1.0
so,
depending
on
language
by
language,
I
think
we
had
a
handful
of
of
languages
included
in
the
1.0
and
more
will
be
rolling
out
in
the
coming
weeks.
Yep.
A
A
Hopefully,
but
but
this
is
effectively
the
the
general
availability
announcement
for
open,
plummetry
metrics-
this
is
big
because,
like
tracing
has
been
really
really
well
adopted,
I
mean
there's
enough
people
in
this
room.
I
think
it
shows
how
popular
this
project
is,
but
metrics
is
part
of
the
original
promise
for
open
telemetry.
So
it's
fantastic
that
now,
like
a
few
years
in
we've,
actually
gone
and
achieved
that
goal,
so
something
we're
really
proud
of
is
the
community
something
we
want
to
celebrate
together.
A
So
we
promised
the
road
ahead,
so
I
see
a
number
of
familiar
faces
here
who
came
to
our
our
three
or
four
hour
long
open,
telemetry
community
meeting
yesterday,
a
big
chunk
of
that
community
meeting
was
us
drafting
the
or
at
least
aligning
on
the
set
of
things
that
the
community
wants
to
work
on
going
forward
right,
so
traces
and
metrics.
Those
were
the
original
promise
of
open
telemetry
about
a
year
into
the
project.
A
A
So
we
just
pasted
the
whole
table
into
here,
but
the
most
popular
item
amongst
attendees
yesterday
was
logging,
not
a
surprise,
logging
logging's,
probably
about
halfway
done
at
this
point,
it's
already
fairly
robust
for
a
for
a
small
set
of
use
cases.
That's
the
one!
That's
garnering
the
most
community
attention,
it's
the
thing
that
we
want
to
drive
to
completion.
Next,
interestingly,
the
next
most
popular
was
profiling,
so
adding
some
kind
of
statistical
profiling
to
open
telemetry's
data
collection.
A
There
are
examples
of
statistical,
continuous
profiling
tools
that
have
been
out
there
in
the
industry,
with
some
amount
of
success
for
each,
but
I
think
it
would
be
incredibly
powerful
for
us
to
be
able
to
capture
this
data.
These
effectively
stack
traces
and
other
low-level
performance
information
from
applications
and
then
correlate
that
with
distributed
traces
with
metrics
with
logs
and
finally,
probably
most
prominently
with
the
other
resource
metadata
that
we
have
today
within
most
observability
solutions
that
consume
open,
telemetry
data
or
their
own
data.
A
There
is
a
bit
of
a
gap
or
disconnect
between
code
level,
performance
information
and
service
and
infrastructure
performance
level.
Information
openslametry
is
historically
focused
on
that
service
infrastructure
view.
I
think,
there's
a
huge
amount
of
power
to
be
unlocked
by
being
able
to
tell
people
like
your
service
is
slow,
because
we've
already
traced
it
down,
because
this
one
function
is
screwing
up,
and
so
this
is
it's
really
exciting
that
there's
so
much
enthusiasm
about
this.
A
The
third
most
large
item
is
improving
our
operationalization
documentation,
project
confidence,
basically
improving
improving
the
onboard
experience,
onboarding
experience
for
contributors
and
for
users
of
open
telemetry
and
giving
them
just
more
collateral
things
they
can
use
to
guide
them
on
that
journey.
You
know
there
were
comments
that
we
were
made
in
our
project
meeting
that
in
many
ways,
open
telemetry
is
ahead
of
some
other
open
source
project
than
this.
This
tends
to
be
a
sore
point
of
most
open
source
projects.
A
A
This
up
for
the
q
a
so
the
first
is
a
big
update
on
logging
to
be
clear
for
everyone
here,
if
you're
not
already
invested
or
knowledgeable
about
open
telemetry
logging,
there's
really
two
paths
of
work
being
done
in
in
parallel
with
the
same
group
of
people,
but
there's
sort
of
two
paths
for
data
that
we
expect
to
see
in
the
future.
The
first
is
open,
telemetry
being
able
to
capture
data
from
existing
logging
sources.
So
there
was
a
donation
made
to
the
open
telemetry
collector
last
year
called
stamza.
A
A
You
might
have
different
annotations
different
pieces
of
data
on
those
logs
and
so
we'd
like
to
have
this
more
strongly
typed
system
where
we
can
actually
bring
in
the
logs
and
perhaps
like
a
binary
format
or
something
and
process
them
very
quickly,
where
they're
all
guaranteed
to
have
the
same
metadata.
There's
actually
been
a
lot
of
work.
That's
been
done
on
this
effort.
There
was
a
conversation.
I
wasn't
actually
party
to
it,
but
there's
a
conversation
to
aleda
and
some
others
on
the
open.
A
A
Okay,
I'm
going
to
speed
up
a
little
more
through
the
others,
because
we
want
to.
We
want
to
save
a
lot
of
time
for
the
q,
a
there's
going
to
be
investments
over
the
next
year
and
basically
in
perpetuity
to
improve
the
ease
of
use
of
open
telemetry.
This
includes
just
building
more
integrations
that
work
out
of
the
box.
This
includes
automatically
turning
on
instrumentation
and
things
like
the
collector
making
it
so
people
in
most
scenarios
can
go
use
download
one
of
our
artifacts
from
the
oss
repos
get
started
with
it.
A
It
goes
to
instruments
their
app
instruments,
their
infrastructure
without
any
additional
configuration.
So
we
want
to
make
some
big
investments
there.
Some
are
already
happening,
we're
also
going
to
invest
more
in
the
experience
of
documentation,
improving
usability,
simplifying
configuration.
Finally,
there
is
work.
That's
been
kicked
off
on
building
a
control
plane
for
open
telemetry.
This
is
basically
a
messaging
and
transmission
system
that
will
allow
the
open
slime
machine
collector
and
probably
the
sdks
and
language
agents
to
be
have
their
config
change
remotely
live.
Obviously,
for
some
you
know
companies
or
people
using
this.
A
If
you're
already
like
up
to
speed
with
ansible
and
everything
else,
you
probably
are
saying
like
hey.
I
don't
need
this
right.
This
works
fine
today,
but
there's
a
lot
of
organizations
out
there
who
rely
on
open
telemetry
who
have
challenges
rapidly,
deploying
things
and
it'd
be
nice
for
them
to
be
able
to
update
their
configurations
and
update
how
they
use
open,
telemetry
very
quickly
and
manage
that
centrally.
A
There's
an
obvious
opportunity
here
to
also
capture
information
from
things
like
front
end,
web
pages,
android
applications,
ios
applications
and
others
to
extend
observability
to
the
full
stack
to
be
clear.
The
open,
telemetry
javascript
sdks
that
dan
works
on
have
supported
that
technically
since
day
one,
but
we
haven't
had
a
strong
specification
or
standards
for
this,
and
so
we
want
to
bring
the
same
level
of
commitment
and
standardization
that
we
have
to
all
of
our
backend
solutions
where,
where
the
same
metrics
are
captured
across
different
languages,
the
the
same
traces
are
captured
the
same
way.
A
We
want
to
bring
that
to
to
front-end
applications
as
well.
So
there's
already
investments
here
expect
to
see
that
continuing.
I
already
talked
about
profiling.
We
expect
to
see
that
as
a
new
signal
type,
that
would
be
the
fourth
sort
of
core
signal
type
inside
of
open
telemetry
in
terms
of
new
signal
sources.
There's
also
some
investments
that
have
been
kicked
off
in
the
evpf
space.
A
This
would
capture
to
be
clear,
like
traces,
metrics,
logs
and
profiles,
it's
still
the
same
signals,
but
you
can
pull
out
signals
in
ways
or
from
different
sources
that
you
haven't
been
able
to
before
with
ebpf.
One
of
the
first
examples
that
this
group
has
been
investing
in
investigating
is
pulling
in
a
lot
of
like
network
telemetry.
So
today,
if
you
use
otel
or
other
tracing
solutions,
you
have
two
services
you
capture
trace
between
them.
A
You
get
a
span
that
captures
like
the
rpc
like
rpcs
that
go
between
them
that
rpc
today
or
that
span
today,
gives
you
no
way
to
dig
into
how
long
was
spent
with
application
processing.
How
much
with
how
long
was
spent
on
applica
on
network
telemetry
or
what
part
of
that
span
represents
something
like
a
dns
lookup
and
waiting
for
that
with
ebpf.
A
We
can
add
that
really
low
level
system
information
into
that
application,
telemetry
and
correlate
it
and
you
could
see,
for
example,
on
every
span
if
it
was
network
latency
that
made
it
long
or
actual
application,
like
actual
actual
actual
application,
slowness,
there's
other
you
know
plenty
of
other
interesting
uses
of
dpf,
that's
probably
just
the
most
like
the
first
one.
That's
been
proposed
and
sort
of
what
you'll
see
initially
next
is
there
will
be
investments
in
a
demo
application
for
open
telemetry.
A
A
So
the
qr
code
here
that
you
can
scan
and
and
that
scenario
that
we
want
to
invest
in
a
lot
next
year,
as
I
mentioned.
Finally,
we
are
interested
in
getting
a
lot
more
end
user
feedback,
so
open
telemetry
is
used
by
a
large
consortium
of
companies.
You
know
splunk
and
dynatrace
and
lightstep
and
new
relic
and
microsoft,
and
google
and
various
others
all
contribute
and
their
customers
use
it.
A
And
so
we
want
to
hear
more
from
end
users
as
an
open
source
community,
because
typically
the
feedback
gets
funneled
to
one
of
those
firms,
and
while
some
of
us
here
it
is,
it
can't
always
be
shared
as
broadly
so,
if
you're
an
end
user
like
one
way,
you
can
really
help
the
community
is
by
providing
us
feedback
directly,
and
so
we've
got
an
end
user
work
group
that
meets,
I
think,
every
week
or
every
two
weeks
it's
on
the
community
calendar.
That
is
a
great
place
to
join
and
just
express
your
feedback.
A
We
also
have
some
folks
here,
like
shar
and
some
others
who
are
going
to
be
collecting
feedback
from
end
users.
So
if
you
want
to
give
feedback,
please
stay
at
the
end
and
we
can
do
like
various
types
of
feedback
sessions,
including
video
interviews,
that'll,
be
used
amongst
all
the
members
of
the
community
to
improve
open
telemetry.
A
So
with
that,
we've
talked
about
the
paths
of
open
telemetry
and
the
future.
We
have
some
time
now
for
a
maintainer
q,
a
which
was
promised.
So
if
you
are
a
maintainer
of
open
telemetry,
if
you're
a
maintainer
of
one
of
the
sigs,
please
come
forward,
we
have
a
hand
microphone.
We
can
share
around
we'll
just
take
a
minute
or
two
for
the
maintainers
to
come
up,
and
then
we
will
start
taking
questions
from
the
audience.
A
A
E
D
A
A
So
we've
only
got
one
hand
mic.
So
what
we'll
do
is,
if
you
want
to
ask
a
question:
please
raise
your
hand
if
we
point
at
you,
then
just
yell
it
pretty
loud
after
we
point
at
you
and
then
we'll
repeat
into
the
microphones
for
the
live
stream
and
then
we'll
use
the
hand
mic
amongst
these
three,
because
we
already
have
our
headsets
and
we'll
answer
it.
So
just
starting
right
up
front.
A
A
Yeah,
so
that's
a
good
question,
so
I'll
repeat
it
for
everyone.
Thank
you.
So
the
question
was
for
the
profiles.
Are
they
going
to
be
represented
effectively
stack,
traces
that
are
regularly
captured,
and
the
second
was
for
this
profiling
work
when
when
we
have
and
basically
what
an
error
log
that
we
get
today,
can
we
correlate
those
who
feed
those
back
in
so
the
for
the
first
half
we
haven't
actually
started
work
on
profiling,
yeah
like
it
was
literally
yesterday
when
the
community
sort
of
decided
to
make
a
commitment
to
it.
A
So
I
don't
know
at
the
same
time
like
I
used
to
work
on
pro
distributed
profiling
at
my
last
job.
So
yes,
I
fully
expect
it'll
be
like
a
basically
a
regularly
sampled
stack
traces
that
are
coming
out
across
a
set
of
services.
That
correlation
you
mentioned
was
not
one
that
I
had
worked
on
previously
but
like
that
seems
like
an
obvious
sort
of
next
step
that
we
should
include
where
yeah,
if
you
have
a
profile
that
happens
to
have
been
captured
when
there
was
some
catastrophic
error
that
you
would
perform
those
correlations.
A
A
B
B
The
problems
that
ebpf
faces
is
that
it
is
often
injected
at
such
a
low
level
in
this
stack
that
it
can
be
hard
to
access
some
of
the
other
information
you
would
want
in
order
to
do
these
correlations,
for
example,
with
network
traffic
you
are
getting
in
at
you
know,
level
four
low-level
network
packet
stuff.
If
you
want
to
attach
that
information
to
a
trace,
you
would
want
to
gain
access
to
the
trace
id,
but
the
trace
id
is
held
in
a
header.
That's
potentially
encrypted
almost
certainly
encrypted.
B
Right,
so
that's
that
is
just
a
a
tricky
problem
that
there
is
not
a
just
off-the-shelf
solution
for
so
so
that's
a
difficulty.
Likewise,
there's
some
really
interesting
work
around
using
ebpf
for
automatic
instrumentation
of
language
runtimes
like
there's
one
for
for
some
people
wrote
for
go
recently.
B
That
looks
really
cool,
but
you
have
this
problem
where,
if
you're
also
doing
manual
instrumentation
or
you
know,
context
propagation,
all
the
normal
stuff,
you
would
be
doing
normal
like
existing
stuff,
whether
or
not
that
ebpf
instrumentation
can
interact
easily
and
effectively
with
other
forms
of
instrumentation
is
kind
of
like
an
open
problem.
I
don't
know
if
you
have
any
thoughts.
E
Yeah,
I
think
one
of
the
challenges
there
is
that
ebpf
from
the
application
perspective
is
read-only.
It
can
get
the
information
about
what's
going
on
in
the
application,
but
it
can't
you
know,
change
the
context
that
the
application
is
using,
so
it
can't
get
propagated
down
that
it's
tied
to
a
span
that
was
created
by
ebpf.
So
it
is
a
great
way
to
get
started
with
some
visibility
into
an
application.
That's
a
black
box
to
you.
E
B
A
C
A
D
A
So
I'll
repeat
the
question
then
anthony
you're,
probably
the
best
suited
answer
it.
So
the
question
was
the
oakland
telemetry
collector.
Some
parts
are
considered
like
ga
generally
available.
There
are
other
parts
that
are
not
one
of
the
parts
that
isn't
is
persistent
storage,
so
actually
buffering
things
on
on
disk
effectively
before
they're
sent
out
as
a
result,
there's
sometimes
some
network
challenges,
but
I'm
guessing
you're,
probably
sending
like
some
things
get
buffered,
but
someone
gets
screwed
up
and
too
much
data
tries
to
go
out
at
the
same
time.
E
Yeah,
so
there
is
a
persistent
storage
component
that
is
intended
to
store
the
internal
representation
that
the
collector
uses
to
an
object
store.
I
think
we
have
disc
back
implementations
currently,
as
you
mentioned,
that
is
in
kind
of
an
experimental
state.
One
of
the
things
that
would
be
very
helpful
for
us
as
collector
maintainers
would
be
to
get
usage
reports
from
that.
E
So
if
people
will
go
out
and
deploy
that
in
environments
where
perhaps
failure
might
be
tolerable,
but
you
can
still
get
feedback,
I
think
that
would
be
very
helpful
for
us
to
because
as
maintainers
we
we
can
build
it.
We
we
can
run
it
in
some
environments,
but
we
don't
have
the
opportunity
to
get
a
breadth
of
experience
that
comes
from
the
community
going
out
there
and
using
it
and
telling
us
what
works
and
what
doesn't.
A
So
the
question
was:
do
you
work
for
a
you're
in
a
security
background?
Is
there
already
a
format
or
process
for
for
defining
security
alerts
that
can
be
sent
from
open,
telemetry
and
just
a
quick
question
back
like
when
you
say
security
alerts?
Do
you
mean
like
specifically
like
a
new
type
of
signal
or
like
logs,
that
have
a
security
tag,
or
do
you
have
anything
in
mind.
A
B
Yeah,
so
the
answer
is
is
not
yet
that
that
does
sound
like
a
great
working
group
to
form
to
define
some
semantic
conventions
there.
I
would
want
to
double
check
whether
elastic
common
schema
already
has
anything
in
it
related
to
security.
If
so
that,
we
would
want
to
use
that
as
our
starting,
because
that'll
just
get.
E
D
A
You
know,
interestingly,
no
one
has
actually
brought
this
up
before.
As
far
as
I
know
like
it's
been
brought
to
me
by
my
own
customers,
but,
like
I
don't
know,
if
anyone
in
the
community
has
raised
their
hand
and
said
we
should
put
together
something
comprehensive,
so
people
can
point
at
it.
I
don't
know,
that's
a
really
good
idea.