►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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: Meet the Community, Build the Roadmap - Morgan McLean, Splunk; Daniel Dyla, Dynatrace; Ted Young, Lightstep; Alolita Sharma, Apple
Speakers: Ted Young, Alolita Sharma, Morgan McLean, Daniel Dyla
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 in-person feedback from users and maintainers, and we will finish with a panel discussion hosted by governance committee members, technical committee members, and maintainers. This session provides a forum for end-users, contributors, and maintainers to meet in person, discuss the project's successes, improve our processes as a community, and to collaborate on the overall project roadmap.
A
C
D
C
A
Cool
and
again
just
complete
my
introduction
on
member
of
the
open
Telemetry
governance
committee
have
been
contributing
to
the
project
for
multiple
years
now
and
I
also
Lead
Series
observability
at
Apple,
so
super
happy
to
be
here
today,
all
right.
So
with
that
said
again,
I
wanted
to
kind
of
run
through
what
we
have
accomplished
on
the
project.
A
We
also
started
working
on
Telemetry
schemas,
specifically
the
open
Telemetry
specification,
as
many
of
you
who
may
be
using
open,
Telemetry
or
have
looked
at
the
project.
The
specification
again
provides
a
requirement
spec
for
the
project
to
implement
both
on
the
collector
agent,
as
well
as
the
11
language,
apis
and
sdks
that
exist
on
the
project
for
instrumentation
of
your
applications
and
then
going
on
from
there.
We
also
start
ensured
stability
of
the
logs
data
model,
which
was
also
announced
at
the
Valencia
kubecon
conference
earlier
this
spring,
going
forward
fast
forward
from
there.
A
This
also
includes
the
real
user
monitoring
integration
that
was,
and
the
definition
and
the
semantic
conventions
that
has
been
done
on
the
Sig,
the
end
user
working
group
was
established
which
actually
enables
end
users.
You
know
companies
that
are
adopting
open
Telemetry
for
collection
to
actually
participate
in
the
project,
provide
feedback,
provide
requirements
and
be
able
to
work
together
with
the
maintainers
and
contributors
to
the
project
to
implement
the
spec
and,
last
but
not
least,
big
accomplishment,
metrics
GA,
which
the
project
you
know
has
completed
and
has
delivered.
A
So,
needless
to
say,
the
open,
Telemetry
demo,
which
also
many
of
the
contributors
have
been
working
on,
is
also
now
available
and
with
that
said,
I
also
wanted
to
call
out.
There's
more
instrumentation
down
the
line,
better
documentation,
work,
that's
happening
on
the
project,
lots
of
activity
on
C,
plus
plus
erlang
and
Swift,
and
some
of
the
other
improvements
that
we
will
step
through
as
we
talk
through
some
of
the
slides
that
are
coming
up
all
right.
So
with
that
said,
Daniel
over
to
you,
yeah.
D
So
I'm
going
to
give
a
short
Community
update
for
those
that
were
at
the
community
meeting
on
Tuesday.
Some
of
this
will
look
familiar,
but
we
really
wanted
to
highlight
how
much
of
a
collaborative
effort
open
Telemetry
is
and
has
been
and
continues
to
be,
even
more
so
for
those
that
don't
know,
we
are
the
second
most
active
cncf
project
behind
kubernetes,
which
you
may
have
heard
of,
and
this
is
what
our
contribution
graph
looks
like
for
the
last
year.
D
Yes,
graphs
that
go
up
are
always
good
on
the
slide,
but
in
this
case
it
really
shows
that
the
two
numbers
are
not
only
the
number
of
active
contributors,
but
the
number
of
active
contributing
companies.
So
it's
an
extremely
collaborative
environment
and
more
and
more
companies
and
individual
contributors,
and
particularly
end
users,
have
really
been
stepping
up
in
the
last
year,
which
has
been
awesome
and
really
great
to
see.
D
We
have
just
pulled
out
a
list
here
of
some
of
the
larger
contributing
companies.
What
we
really
wanted
to
highlight
here,
though,
was
you
know
a
handful
of
these.
Almost
half
really
are
end
users
and
not
really
vendors.
So
the
project
started
as
sort
of
a
very
vendor
heavy
project,
but
we
always
had
a
vision
for
it
to
be.
You
know,
built
and
maintained
by
the
people
who
use
it,
and
it's
been
really
nice
to
see
that
actually
begin
to
start
happening.
D
One
other
thing
that
I
did
also
want
to
mention.
We
did
just
finish
our
GC
elections
for
the
last
year.
This
year
we
had
513
eligible
voters,
219
of
which
actually
voted
So
for
anybody
here
that
participated
in
the
election.
Thank
you
for
your
for
your
participation
without
people
to
tell
us
what
they
want,
then
the
project
really
wouldn't
go
anywhere
and
it
was
nice
to
see
that
you
know
numbers
were
very
healthy.
D
B
Yeah,
so
one
thing
I
want
to
dig
into
that
I
think
is
especially
of
interest
to
the
community.
Is
the
new
open,
Telemetry
demo
project
so
just
to
walk
through
really
quick
what
this
is
and
what
it
does.
It
is
your
classic
kind
of
distributed
micro
service
application.
It's
a
web
store
that
sells
telescopes,
because
that's
what
we
like
around
open
Telemetry
and
it's
made
up
of
a
variety
of
different
services
in
a
variety
of
different
languages,
all
instrumented
with
open
Telemetry.
B
So
if
you
click
to
the
next
slide,
it
also
has
a
feature
flagging
for
being
able
to
enable
and
disable
different
kinds
of
problems
within
the
demo
application.
So
what
you
can
do
is
very
easily
stand
this
up,
especially
using
like
a
kubernetes
operator
or
Docker
if
you're
running
it
locally
and
hook
it
up
to
your
back
end
of
choice
or
a
local
Jaeger
instance,
for
example,
and
enable
some
of
these
problems
and
then
go
do
your
own
investigation.
B
So
it's
a
great
way
to
actually
see
open
Telemetry
in
action
go
to
the
next
slide.
It's
also
a
great
place
to
look
if
you're
thinking
about
standing
up
open,
Telemetry
yourself,
the
source
code
is
available
for
every
service,
so
you
can
go
in
and
see
how
we've
actually
added
instrumentation
to
that
service.
So,
if
you're
getting
started
with
open,
Telemetry
and
you're,
just
looking
for
a
nice
easy
like
copy
paste
example
for
how
to
get
started,
the
a
demo
project
is
actually
a
great
place
to
to
find
that
code.
B
A
And
I
just
wanted
to
call
out
on
the
demo
project
again,
as
you
can
see,
you
know,
there's
a
very
ontology
that
is
built
across
the
dependencies
of
the
different
components
as
well.
As
you
know
what
you
instrument
with
so
again
go
check
it
out.
It
is
really
interesting
and
would
love
to
see
more
folks
contribute.
You
know
to
add
your
own
use
cases
to
it.
That's
it
Morgan
yeah.
C
So
we're
going
to
talk
about
the
roadmap,
so
Ellie
did
a
great
introduction
of
all
of
the
progress
that
we've
made
since
openstulture
is
founded,
and
certainly
in
the
last
year
on
the
project,
so
things
like
Hotel,
metrics,
going
GA
and
other
really
critical
components.
But
it's
we're
an
interesting
time
now,
like
metrics
and
distributed
tracing,
were
the
original
promise
of
open
Telemetry.
Those
were
the
two
data
types
we
originally
called
out.
C
Similarly,
in
in
May
in
cubecon
Valencia,
we
announced
that
the
metric
specification
was
now
stable
and
here
at
kubecon
Detroit
we're
able
to
show
off
the
various
languages
in
which
metrics
functionality
is
now
fully
baked
and
that's
considered
GA
stabled
or
going
to
be
no
breaking
changes
there
going
forward
unless
there's
a
like
another
major
release
of
open
Telemetry
years
into
the
future.
So
we've
we've
achieved
like
a
lot
of
success
here
on
metrics
blogs,
of
course,
being
the
column
on
the
right.
C
What
this
means
in
Practical
terms,
if
you're
an
end
user
or
someone
who's
interested
in
adopting
open
Telemetry
organization,
is
that
you
can
use
open
Telemetry
today
to
capture
spans
to
capture
system,
metrics
application,
metrics
and
metadata
from
your
services
and
from
your
infrastructure
as
well
as
a
few
other
sources.
You
can
pre-process
this
data.
Typically
with
the
open
television
collector,
there's
a
lot
of
flexibility
and
capabilities
there,
and
then
you
can
send
it
to
any
destination.
You
want
for
final
processing,
storage
or
analytics
right.
C
This
is
the
original
promise,
an
intent
of
open
Telemetry,
and
it's
something
that
we've
now
generally
achieved
at
this
point,
which
is
you
know,
we're
celebrating
as
a
community,
and
we
see
certainly
across
the
industry.
Like
hundreds.
If
not
you
know,
thousands
of
large
organizations
are
already
adopted
or
in
the
midst
of
adopting
open
Telemetry
as
a
result,
because
it
gives
them
these
capabilities
and
allows
them
to
send
their
data
wherever
they
want
in
a
nicely
structured,
correlatable
format.
C
There's
a
few
things
that
we're
working
on
now.
Unfortunately,
this
is
animated
one
by
one,
so
I
think
Alita
already
mentioned
the
end
user
working
group,
so
I'm
not
going
to
Touch
Too
Much
on
that.
But
the
critical
items
here
on
the
roadmap
are
that
we're
working
We've
expanded
our
web
maintainer
team,
which
is
working
on
documentation
in
the
open
slouchy
website,
which
makes
it
easier
to
adopt
easier
to
use.
C
So
this
is
an
open,
Telemetry
control,
plane,
that's
being
specified
and
developed
right
now.
Today,
you
can
configure
open,
Telemetry
components
relatively
easily.
The
Collector,
for
example,
has
a
large
set
of
yaml
markup
that
you
can
modify
and
Implement
to
go,
configure,
processing
on
The,
Collector
and
and
configure
what
it
receives
data
from
and
where
it
sends
that
data
to,
but
you
have
to
go
and
deploy
and
distribute
that
yaml
file
alongside
the
collector
on
every
host
that
it's
running
on.
C
Similarly,
there's
there's
configuration
for
other,
open
Slumber
components
like
language
agents
and
language,
libraries
with
op
amp.
What
we'll
be
doing
is
allowing
those
components
optionally
to
be
controlled
via
apis,
so
that
in
in
Syria
and
eventually
in
practice,
you
could
have
a
central
server
or
service
somewhere.
That
is
actually
controlling
and
configuring.
C
Your
open
Telemetry
components
live,
so
you
can
make
configuration
changes
on
the
Fly
and
you
can
more
easily
manage
the
configuration
of
your
thousands
or
tens
or
hundreds
of
thousands
of
open
Telemetry
components
that
you
have
running,
live
in
production
or
non-prod
environments.
It's
early
days
for
op-amp,
but
it's
very,
very
exciting
and
I
know.
There's
there's
a
lot
of
community
enthusiasm
around
it.
Another
item
in
the
roadmap
is
client
instrumentation.
So
yes,
if
you
looked
closely
in
the
past,
you
would
have
noticed
open.
C
Telemetry.Js
has
said
support
for
capturing
some
level
of
instrumentation
from
front-end
websites.
This
is
now
being
formalized
and
extended
so
that
we
can
extend
people's
visibility
not
just
to
their
backend
services,
but
extend
that
all
the
way
out
to
their
client
applications
running
on
mobile
phones,
running
on
desktops,
running
on
on
front
and
websites
that
anyone's
accessing.
C
So
you
can
have
true
end-to-end
observability
across
those,
for
example,
you
can
have
a
distributed
Trace
that
that
is
starts
from
a
client
and
actually
shows
you
the
amount
of
like
client,
latency
or
client
wait
time
that
was
incurred
like
due
to
local
processing
and
also
you
can
use
it
to
determine
the
amount
of
like
internet
latency
that
caused
slowness.
That's
one
example
of
what
you
can
do
with
this,
but
I
think
there's
a
lot
of
power
and
potential
coming
out
of
this.
C
The
next,
and
probably
the
most
sort
of
topical
for
here
is
profiling,
we're
adding
profiles
as
a
new
native
data
type
within
open
Telemetry.
This
is
a
topic
that
actually
came
up
at
kubecon
Valencia.
The
community
meeting
it
hadn't
really
been
considered
previously
and
is
now
going
to
be
a
major
part
of
open
Telemetry.
C
It's
also
kind
of
exciting,
because
open
Telemetry
I
think
in
the
early
days
there
were
a
lot
of
familiar
faces.
The
same
sort
of
people
working
on
everything.
Profiling
is
one
place
where
it's
brought
an
influx
of
new
users
and
contributors
to
the
community,
which
is
also
really
exciting,
and
it's
people
who
literally
showed
up
to
the
community
meeting
in
Valencia
and
various
others
who
got
engaged
and
involved,
which
is
great,
we'll
also
be
working
on
fully
implementing
logs
within
open
Telemetry.
C
We've
talked
about
this
one,
a
lot
at
previous
kind
of
conferences
not
going
to
go
in
too
much
detail
on
it.
Just
there's,
you
know,
the
logging
support
will
exist
for
existing
log
sources,
so
files
on
disk
that
get
tailed
as
well
as
an
open,
Telemetry
native
logging
type
that'll
be
extremely
performant.
It's
a
binary,
strongly
typed
format
for
capturing
logs,
so
you
don't
have
to
parse
logs
multiple
times
with
agents
and
back-end
processors
very
exciting,
but
of
course,
for
traditional
for
existing
apps.
C
You
would
use
the
files
on
disk
Ted
already
mentioned
the
demo
application
so
I'm
going
to
skip
right
past
that
there's
also
some
proposals
around
file
based
configuration.
This
ties
into
op-amp
so
using
yaml
files
to
configure
all
open
symmetry
components,
not
just
the
collector
today.
Most
of
them
are
configured
through
other
means.
We
want
to
make
that
consistent
for
people
who
choose
to
have
that.
C
I'm
going
to
skip
through
these
because
I
already
talked
about
them,
but
effectively
client
instrumentation
again
allows
you
to
do
things
like
see.
Traces
from
your
client
apps,
all
the
way
through
to
your
back
end,
back-end
Services
as
you
that
today,
that's
somewhat
segregated,
but
in
the
future.
With
this
you
can
see
those
traces
or
other
types
of
telemetry
spanning
all
the
way
from
user
interactions.
All
the
way
to
services
to
database
calls
on
the
back
end.
A
I
wanted
to
kind
of
go
through
some
of
the
areas
that
have
been
discussed.
You
know
in
the
last
few
months,
as
well
as
in
the
project
discussions
that
we've
had
earlier
this
month
this
week
at
kubecon,
where
these
are
some
of
the
proposals
that
have
been
you
know
brought
up
by
the
larger
Community
by
end
users,
as
well
as
other
developers
and
I
just
wanted
to
kind
of
run
through
some
of
them,
so
that
you
know
very
interested
in
kind
of
getting
feedback
from
all
of
you.
A
You
know,
as
we
work
through
as
some
of
these
and
consider
them
as
proposals.
First
of
all,
CI
system,
cicd
systems,
where
we
build
and
deploy
our
applications,
are
becoming
increasingly
integrated
into
what
is
observable
and
capturing
Telemetry
from
CI
CD
systems
and
defining
semantic
conventions,
for
those
is
something
that's
super
important
and,
as
you
deploy
production
systems,
and
you
want
to
ensure
that
what
you're
pushing
to
the
client
or
to
the
server
or
services
for
that
matter
are,
you
know,
fully
observable
and
tested
out
right.
So
again,
we
will.
A
You
know
this
is
a
proposal
that
was
made
by
some
of
the
you
know
some
parts
of
the
community,
and
so
it's
under
consideration.
Another
area
that
you
know
is
also
being
discussed
is
how
do
we
actually
enable
more
kubernetes
metadata
to
be
visible
and
observable
and
increasing
the
visibility
into
the
infrastructure?
You
know
kubernetes
based
infrastructure,
that
most
of
us
use
for
our
applications
and
services.
A
Another
proposal
is
the
and
again
this
is
a
contentious
one,
but
you
know
again
also
a
project
in
itself
having
a
standard
query
format
for
being
able
to
query
Telemetry
data,
because
here
you
are
you're
going
to
collect
petabytes
and
petabytes
of
observable.
You
know
Telemetry
data
coming
in
from
different
system
components
both
on
the
client
and
we
have
and
the
service
side.
And
how
do
you
actually
query
this
kind
of
data?
Is
it
useful
to
have
a
standard
query
format
and
for
many
of
you,
you
might
have
used
some
query
languages
SQL?
A
How
many
of
you
use
SQL
many
of
you
prom
ql,
some
of
you?
What
about
elastic
query
language
right?
So
there's
so
many
different
query
languages
in
the
observability
space?
At
this
point
that
it
also,
you
know,
is
something
that
intersects
very
much
with
the
collection
process
and
really
making
it
a
much
richer
experience.
But
that
said
again,
I
think
this
is
something
under
discussion
that
we
will
take
to
the
tag
observability
work
group
to
work
through
there
and
then
figure
out.
You
know
how
we
can
work
through
a
standardized
query
format
proposal.
A
Hopefully
everyone
but
again
usage
and
spend,
is
a
big
deal
for
most
organizations
and
we'd
like
to
better
understand
right
how
that
infrastructure
actually
is
being
used
by
US
different
teams
across
the
orgs
use
this
infrastructure,
and
and
how
does
that
then
measure
into
what
you
plan
for
in
terms
of
provisioning
the
year
the
next
year?
So
there's
a
lot
of
intersection
there
and
just
I
was
curious.
Please,
you
know,
raise
your
hands
if
you're
interested
in
Cloud
spend.
A
If
you
are
subject
matter,
experts
are
just
working
in
that
space.
I
invite
you
all
to
consider
joining
in
into
our
discussions
on
the
project
as
well
as
helping
us
establish
those
semantic
conventions
that
can
then
be
used
by
everybody
right.
So
again,
it's
an
easy
process
to
get
involved.
We
have
weekly
Sig
meetings
and
Sig
calls
and
they're
all
on
the
Google
Calendar
for
cncf
and
would
really
love
for
you.
You
know
many
of
you
to
get
involved
more
actively.
C
Morgan
we
wanted
to
talk
a
bit
just
to
close
the
set
about
our
long-term
Vision
right,
observability
and
open
Telemetry
being
a
part
of
observability
I
think
you
know,
people
have
heard
pitches
and
things
from
open
source
groups
from
vendors
from
others.
Talking
about
how
critical
it
is,
but
I
think
in
practice.
Today,
most
people
use
their
observability
tools
as
a
last
resort.
C
It's
the
thing
you
run
to
when
the
alarms
are
going
off
when
you
get
paged
when
everything's
gone
wrong
and
it
tells
you
what
went
wrong
and
hopefully
how
to
fix
it
right.
That's
how
we
interact
with
these
certainly
observability
I.
Think
for
most
people,
there's
a
perception
to
grow
out
of
monitoring
tools
and
monitoring
tools
are
typically
used
in
that.
C
In
that
kind
of
scenario,
our
vision
was
open,
Telemetry
and
our
expectation
is
that
over
time,
observability
tools,
which,
of
course,
are
enriched
and
powered
by
the
data
that
comes
out
of
open
Telemetry,
are
going
to
be
used
much
more
frequently
right,
like
I'm
sure,
there's
people
here
who
have
been
in
situations
in
their
career,
where
they're
working
on
a
sufficiently
large
set
of
Services.
Of
course,
Technologies,
like
Cloud
infrastructure
and
kubernet
studies,
make
it
very
easy
for
us
to
spin
up
all
these
services
and
make
them
communicate
and
I'm
sure.
C
This
is
one
example
of
a
place
where
I
think
observability
tools
will
be
used
more
in
date
in
people's
day-to-day
lives
right
if
you're
a
developer,
if
you
can
rely
on
having
a
surface
map,
for
example,
again,
it's
just
one
example:
that's
drawn
that's
totally
reliable
from
your
observability
tooling,
and
indeed
you
can
investigate
that
service
map
to
see
how
certain
interactions
are
processed.
It
means
that
when
you're
told
to
go
extend
your
services,
because
maybe
you
work
at
an
e-commerce
company
and
you've
been
told,
go
Implement.
C
You
know
the
sales
of
bundled
products,
for
example,
which
maybe
wasn't
done
before
your
e-commerce
stack
you're
told
to
implement
that
you
now
need
to
go
touch
like
10
15,
different
services.
To
do
it.
These
tooling
is
going
to
help
you
during
the
design,
phase
and
implementation
phase
of
doing
that
in
a
way
way
that
today,
you'd
have
to
go.
You
know,
liaise
with
a
whole
bunch
of
people
to
find
out
how
things
work.
E
C
Know,
Source
control
and
various
other
things,
or
at
least
within
the
same
order
of
magnitude.
There
are
other
scenarios
like
testing
and
others
that
I
think
also
will
benefit
very
strongly
from
open,
Telemetry
and
observability
tooling,
as
it
becomes
more
and
more
adopted
across
the
industry
and
certainly
within
the
open,
Telemetry
Community.
This
is
something
we're
really
really
excited
to
have
a
part
in,
because
it's
going
to
make
everyone's
lives
and
jobs
and
everything
way
way
better
and
and
easier.
C
C
Can
you
click
next
slide?
Oh
perfect,
to
conformally
wrap
this
up
next
steps
for
people
if
you're
a
if
you
want
to
use
or
using
open,
Telemetry,
there's
never
been
a
better
time
to
adopt
it
like
chasing,
is
super
robust,
it's
being
used
across
the
industry.
Metrics
now
is,
is
stable
and
and
really
we're
seeing
it.
It's
adoption
really
accelerate
across
the
industry,
which
is
exciting.
Open
Telemetry
gives
you
that
flexibility
of
sending
your
data
and
processing
your
data
anywhere
you
want.
C
Indeed,
you
can
send
your
your
production
Telemetry
to
to
any
number
of
destinations
at
the
same
time,
and
it
also
gives
you
that
really
nice
strongly
correlated
sort
of
structured
data
out
of
your
applications
and
infrastructure
in
a
way
that
you
may
not
have
had
it
previously.
Our
basic
logging
functionality
is
also
fairly
robust.
There
are
companies
already
using
it
in
Fairly,
High
scale
production
like
earlier
this
year,
I
was
at
a
talk
by
I,
think
Lockheed
Martin
about
how
they're,
using
it
across
other
kubernetes
infrastructure
like
you
can
go
use
it.
C
It
works,
it's
marked
unstable
just
because
it's
possible
the
configs
or
things
will
change
in
the
future
and
we're
adding
more
functionality
and,
of
course,
more
advanced
logging
scenarios
that
the
sort
of
native
locking
type
I
described
earlier.
Profiling
and
client
instrumentation
are
all
coming
to
open
Telemetry
soon,
and
it
means
you
can
adopt
them
very
very
easily
if
you're
already
using
open
telemetry.
C
Secondly,
if
you
want
to
contribute
to
open
Telemetry,
if
there's
a
particular
part,
either
existing
functionality
or
things
on
the
roadmap
that
we've
discussed
today
that
you're
interested
in
please
like
join
us
like
join
our
our
CNC,
our
channels
on
cncf,
slack
or
join
the
weekly
Sig
calls
open
Telemetry.
It's
it's
not
a
business
right
like
we.
We
have
this
roadmap.
This
proposed
roadmap.
We
have
up
here,
but
you
know
I
and
Ted
and
Daniel
and
Leda
and
other
people
can't
you
know,
go
and
tell
everyone
what
they.
F
C
To
work
on
developers
and
the
contributors
vote
with
their
feet
right,
and
so,
if
there's
a
thing
here
that
you
want
to
see
enhanced
or
put
more
Firepower
behind,
please
like
come
in
join
us.
You
are
always
welcome.
This
community
you're
always
welcome
to
help
things.
Initiatives
like
profiling
have
started
and
taken
off,
because
you
know
tens
of
developers
have
come
in
all
at
once
and
said
like
I,
want
to
add
this
and
I'm
going
to
work
on
the
design
implementation
of
it.
So
if
you
have
any
interest
in
that,
please
join
us.
C
We'd
love
to
have
you
and,
as
I
mentioned,
the
best
way
to
get
involved
is
by
joining
either
a
weekly
Sig
call
or
the
slack
channel
for
that
particular
area
in
which
you
are
interested
and
with
that
we
are
done.
We'd
love
to
take
questions
from
anyone.
I
see
a
couple
open,
Telemetry
maintainers
as
well,
if
you
guys,
if
you're
just
in
taking
questions,
please
come
up
here
if
you're
a
no-tel
maintainer.
Otherwise,
if
the
audience
has
any
questions,
we
and
the
maintainers
are
happy
to
answer
them.
C
G
C
Our
data
I
think
we
mentioned
that
one
mostly
because
there's
there's
clearly
an
appetite
for
it.
Like
especially
the
last
few
months,
people
have
been
asking
like
many
different
people
have
come
and
asking
for
this
to
be
clear.
This
project
may
not
in
fact,
likely
won't
end
up
being
part
of
open
Telemetry
like
we
want
to
keep
Hotel
very
bounded
on
data
extraction
and
data
collection,
but
I
think
as
El
leader
mentioned,.
A
The
cncf10
I
mean
we
are
actually
going
to
start
a
series
of
discussions
on
exactly
you
know,
kind
of
working
through
the
nuances
of
what
a
proposal
would
look
like
and
also
yes,
we
have
looked
at
the
graphql
model
and
several
other
query
languages.
Obviously,
graphql
is
very
popular.
There
are
other
query
languages
also
on
the
client
side
that
should
be
looked
at,
but
again,
let's
go
through
that
process
and
again
super
happy
if
you
can
join
in
for
those
discussions,
yeah.
B
Just
to
add
some
color
onto
that
one
of
the
things
when
you
look
at
it,
you
have
some
like
very
general
purpose
kind
of
querying
things
right
like
SQL,
and
then
you
have
stuff
that
was
like
built
to
purpose
in
the
observability
space.
But
it
has
been
built
to
like
a
specific
subset
of
the
kind
of
grouping
of
signals
that
we're
doing,
and
there
hasn't
yet
been.
As
far
as
I
can
tell
like
an
open
query
language
that
was
built
specifically
to
Target.
B
The
data
set
that
we're
looking
at
so
that's
kind
of
like
one
of
the
big
questions
is:
how
can
we
use
like
pre-existing
work
but
then
adapt
it
to
something?
That's
specific
enough
to
the
kind
of
data
that
we're
looking
at
that?
It's
not
that,
like
overly
generalized
the
way
SQL
might
be,
for
example,.
E
A
That
I
mean
typically
how
that
works
is
that
if
there
are
collaborative
projects
and
again
there
can
be
overlapping,
you
know
feature
sets
and
functionality
that
is
being
looked
at
or
discussed
or
worked
on
in
in
different
cncf
projects.
So,
typically,
you
know
that
does
as
we
work
through
the
semantic
conventions
as
we
work
through
the
proposal
itself.
Of
what
you
know
a
baseline
looks
like
we
typically
would
try
to
go
and
intersect
with
those
projects
also
and
see
if
we
can
leverage
some
of
the
work
that
they
have
done.
F
Data
accession
and
data
collections-
certainly
you
know
part
of
the
story
you're
trying
to
achieve
that.
But
data
storage
is
another.
You
know
piece
of
the
puzzle
right
any
roadmap,
any
thoughts
around
data
storage
because
you
know
organizations
like
us
if
you
want
to
implement
you
know
the
next
question.
People
like
it
next
question
comes
is
how
do
we
Implement
in
across
300
different
things
right?
That's.
C
Why
the
scale
matters
we've
purposely
avoided.
Doing
data
storage
and
open
Telemetry
like
to
be
clear,
there's
many
reasons
for
it.
One
is
that
open
Telemetry
has,
as
I
think
Daniel
now
later
showed
like
there's
a
lot
of
end
users
contributing,
but
there's
also
a
lot
of
vendors
in
the
space
by
keeping
the
project
bounded
to
just
data
collection.
C
It
means
they're,
very,
very
collaborative
and
very
Cooperative
I
think,
there's
a
concern
that
if
the
project
started
getting
to
data
storage
and
analytics
and
things
like
that,
that
would
perhaps
change
the
level
of
cooperation
there,
but,
secondly,
legitimately
there's
there's
a
number
of
cncf
projects
that
already
focus
on
this
right.
Prometheus
is
a
great
metrics
back
end
to
processes.
Metrics
Jaeger
has
a
really
it's
really
great
at
processing
distributed
traces,
there's
other.
You
know
various
open
source
solutions
for
logging,
elastic,
probably
being
the
most
popular
and
so
I.
C
A
I
think,
just
to
your
point,
storage
is
very
important.
Obviously,
in
the
observability
pipeline
and-
and
you
know,
a
unified
experience
is
also
equally
important
to
users
who
are
actually
building
such
complex
pipelines
right
so
interoperability
from
The
Collection
side
in
terms
of
being
able
to
connect
with
a
diversity
of
data
syncs,
whether
that's
Prometheus
or
metrics,
or
you
know,
Jaeger
for
tracing
or
other
logging
databases
again,
they're
a
multitude
of
exporters
that
are
already
available
in
the
collector
in
the
open,
Telemetry
collector
and
you
can
use
those.
A
But
if
there
is
a
data
sync
that
is
missing
in
the
open
Telemetry
you
know
Integrations,
then
please
feel
free
to
you
know.
Work
with
us
make
a
proposal,
and
typically
you
know
they
get
added
very
quickly.
So
there
is
a
huge
diversity
of
data
sources,
as
well
as
data
things
that
are
actually
integrated
into
open.
Telemetry
and
again,
if
you
see
anything
missing,
just
please,
you
know
propose.
B
So
it
really
feels
like
that's
not
a
place.
You
want
to
standardize
right
now.
Instead,
you
want
to
be
very
flexible
working
with
all
the
people
trying
to
develop
new
stuff.
So
that's
that's
like
Beyond,
just
like
there's
vendors
involved,
I
think
it's
it's
like
not
feasible
to
standardize
on
that
and.
D
Yeah
sure,
while
we're
waiting
for
him
I
would
also
add
that
projects
Like,
Jaeger
and
Prometheus
have
been
working
much
more
closely
because
the
the
Telemetry
data
between
your
traces,
metrics
and
logs
are
now
so
much
more
like
contextually
related
in
a
way
that
they
never
were
in
the
past.
It
allows
those
other
projects
to
to
collaborate
in
a
way
that
they
maybe
couldn't
have
before.
So,
as
those
projects
continue
to
improve,
maybe
the
need
for
a
single
data
storage
for
all
three.
H
So,
on
a
specification
level,
it's
all
true
right,
so
we
don't
want
to
specify
a
data
format
to
you
know
we
don't
want
to
tell
people
how
to
store
data
on
disk.
On
the
other
hand,
there
are
some
efforts
like
establishing
an
otlp
data
format
for
culinary
storage
and
that
one
can
be
used
by
The
Collector
to
do
a
collector
exporter
that
then
writes
hlp
data
to
disk,
which
then
can
be
read
by
by
other
systems
right.
So
this
is
not
a
specification,
but
it
is
an
effort
from
individuals
like
Morgan
mentioned.
H
We
are
action.
The
actions
of
the
individuals
actually
Define
the
roadmap
actually
Define.
What
is
the
the
features
that
have
been
developed
and
there
have
been
people
on
in
in
the
community
that
have
has
written
exporters
to
write
things
to
disk,
so
you
can
store
you
can
read,
but
it's
not
part
of
any
specification.
I
Is
it
difficult
to
only
use
a
portion
of
the
open,
Telemetry
or
yeah
the
open,
Telemetry
Library
so
say,
for
example,
I'm
already
using
the
language
specific
Prometheus
library
for
metrics
I've
already
got
a
mostly
functioning
log
setup
and
I'm
just
interested
in
the
tracing
portion?
Is
that
relatively
easy
to
set
up
or.
C
A
B
And
to
add
slightly
more
flavor,
there's
we've
also
done
a
lot
of
work
to
separate
out
the
API
that
you
instrument
with
with
the
client
or
implementation
that
you
would
plug
into
that.
So
it's
also
feasible
to
say
if
you
do
end
up
with
instrumentation
that
say
like
open,
Telemetry,
metrics
instrumentation,
it's
it's
fairly
straightforward
to
create
a
bridge
from
that
instrumentation
say
into
like
a
Prometheus
client
that
you're
already
running
there.
So
we
really
care
quite
a
bit
about
that
kind
of
flexibility.
All.