►
From YouTube: CNCF SIG Observability 2021-02-02
Description
CNCF SIG Observability 2021-02-02
A
B
B
A
Also
fyi,
but
I'll
also
raise
this
once
once
we
start
for
real.
Maybe
we
can
consider
moving
this
call
around
a
little
bit
because
with
it
it's
directly
after
cncftoc
call,
which
means
I'm
not
super
well
prepared
for
either
call,
and
I
hate
that-
and
it
doesn't
do
either
of
those
calls
justice,
because
you
don't
have
any
time
to
just
do.
The
last
fix
ups
with
all
major
external.
A
A
A
A
A
A
So,
but
we're
at
five
minutes
or
almost
anyway,
so,
let's
just
get
started
so
two
high-level
things:
one
fyi
there
is
now
prometheus
working
group
within
open
telemetry
for
anyone
who
who
has
an
interest
there
and
the
other
thing
this.
We
call
is
right
after
the
cncftoc
call,
which
means
I'm
usually
jumping
in
between
the
two,
and
I
can't
really
do
either
call
full
justice
because
all
of
you
notice,
when
you
have
like
two
major
external
calls,
it's
every
any
something
happens
right
before
and
you're
out
of
time.
A
E
C
D
A
A
B
E
E
Done
all
right,
so
I
mean
for
most
of
the
people
on
the
call.
This
is
another
example
of
doing
the
due
diligence
work,
so
same
exact
template
that
we
have
followed
before
the
link
is
in
the
agenda.
Comments.
Welcome
so
please
add
feedback
in
here
we
can
be
sure
to
kind
of
incorporate
all
these
changes,
but
this
is
specifically
for
the
open
telemetry
project,
which
is
currently
a
sandbox
project.
E
E
So
I
will
kind
of
work
through
the
details
of
that
and,
of
course,
the
the
idea
here
is
not
to
break
customers
or
end
users.
So
there
is
something
known
as
a
shim
that
is
available
to
both
open
tracing
and
open
census.
So
you
can
continue
to
use
that
with
open,
telemetry
and
open
symmetry
will
provide
support
for
for
two
years,
so
customers
or
end
users
of
these
products
have
a
path
forward
without
having
to
like
jump,
ship
and
reinstrument
everything
to
kind
of
make
it
work.
E
Now.
The
dock
that
we
have
here
has
gone
through
the
open,
telemetry
governance
board.
We'll
talk
about
governance
in
in
a
while
and
a
little
bit
you
can
see
different
members
of
open
symmetry
that
have
currently
reviewed
it
there's
still
a
few
outstanding,
but
they
will.
They
will
add
their
review
information
in
here
kind
of
soon
and
we
don't
have
the
toc
sponsor
yet,
but
we
will
of
course,
sort
out
those
details.
E
E
C
Can
I
kind
of
interrupt
so
usually
it
was
kind
of.
There
was
some
time
for
review
before,
like
for
an
offline
review,
or
whatever
did
you
share
this?
Maybe
earlier
or
just
maybe
we
can
have
the
time
I
don't
know
to
do
it
offline
as
well,
not
before
I
mean
before
jumping
into
straight
consensus
and
stuff
like
that,
we
did
you.
He
had
exactly
the
same
point
on
on
you
know
on
previous
incubation
dogs
as
well.
E
Yeah,
so
this
was
shared
last
week
in
the
sick,
observability
slack
channel
with
the
link,
and
we
don't
have
to
do
consensus
today,
like
I
assume
this
is
going
to
take
at
least
two
meetings,
so
any
items
that
folks
are
not
comfortable
with,
let's
definitely
table,
and
we
can
definitely
take
feedback
and
come
back
in
two
weeks
and
address
that
feedback.
So
so
no
rush
here
if
there
are
any
concerns
or
areas
that
people
want
to
dig
into
more.
We
have
some
time.
So
I
doubt
we'll
get
through
everything
today.
C
E
I'll
put
the
exact
link,
so
maybe
I
I
just
put
the
link
to
the
agenda
to
say
observability,
because
that's
where
the
link
for
this
document
was
so,
I
probably
just
wasn't
clear
so
I'll,
send
that
up
the
mailing
list
and
to
the
slack
channel
to
make
sure
it's
super
clear.
So
people
have
access
to
it.
A
A
Or
I
think
somewhere
in
the
documentation,
we
say
that
the
mailing
list
is
the
primary,
because
that
can
be
consumed
completely
asynchronously.
On
the
other
hand,
slack
is
basically
half
email
by
now
for
better
or
for
worse
so
yeah.
I
I
I
guess
we
are
just
walking
through
stuff
and
if
there's,
if
there's
anything
which
needs
to
be
followed
up,
as
you
say,
steve,
then
we
just
mark
it
as
such
and
and
yeah
okay.
E
So
open
symmetry
has
governance
committee
charter.
It
follows
kind
of
similar
things
to
other
cncf
projects.
People
can
kind
of
review
it.
It's
a
little
long
here.
One
thing
worth
noting
is
that
we're
kind
of
going
through
a
transition,
so
the
board
has
kind
of
grown
and
is
going
to
reduce
again
in
size.
Again,
that's
all
outlined
on
kind
of
the
readme
here,
but
there
is
a
governance
committee.
There
are
standards
on
how
many
representatives
per
company
there
can
be
to
ensure
that
it's
not
controlled
by
a
single
entity
and
yeah.
E
I
mean
the
there's
a
whole
community,
with
github
issues,
kind
of
outlining
what
the
government
supports
kind
of
responsible
for
areas
of
focus
and
and
what
have
you
so
definitely
review
it?
Let
me
know
if
there's
any
kind
of
comments,
it
follows
a
similar
model
to
what
kubernetes
has
been
using.
So
I
guess
any
questions
on
governance
other
than
people
will
probably
want
to
review
it.
E
E
Correct
yeah,
okay
and
then
there's
a
separate
technical
steering
committee,
which
is
another
board
that
handles
the
technical
aspects
of
it,
and
that
follows
a
slightly
different
process
but
same
idea.
There's
a
max
representation
for
that
board
and
they
handle
kind
of
the
technical
decisions
across
all
of
the
sigs
within
open
symmetry.
A
I
think
there
will
be
no
further
questions
regarding
the
governance,
but
maybe
someone
has
some
so
just
to
make
sure
call
for
consensus.
Is
there
anyone
who
wants
to
look
into
into
the
governance
document
more
deeply?
If,
yes,
now
is
the
time
to
speak
else,
the
suggested
call
for
consensus
is
already
highlighted.
A
E
B
A
A
E
Okay,
next
one
does
the
project
have
production
deployments,
they're,
high
quality
and
high
velocity,
so
I've
included
a
link
to
our
adopters
file.
There
are
a
variety
of
both
vendors
and
end
users
that
are
listed
here.
Anyone
listed
as
an
adopter
is
stating
that
they
are
running
this
in
production
today.
E
What
we
have
not
articulated
is
what
specific
sub-components
of
opensymmetry
are
being
used.
We're
actually
going
to
update
this
page
to
make
it
more
of
a
table
that
actually
outlines
that,
but
there's
a
broad
range
of
both
client
library
and
open
symmetry
collector
support,
which
of
course
means
that
the
specifications
are
being
used
because
that's
a
pre-rack
in
order
to
use
the
client,
library
and
instrumentation
aspects.
E
C
E
I
guess
I
I
will
make
one
note
on
this.
Well,
I
guess
two
notes.
One
is
I
mean
observability
three
pillars
of
observability
open
telemetry
is
focused
primarily
on
tracing
to
start
metric.
Second
and
logs
are
not
even
part
of
really
scope.
Today
there
is
some
amount
of
log
support,
but
I'd
say
it's
very
early,
so
most
of
the
production
deployments
that
you're
seeing
here
are
primarily
around
the
distributed
tracing
aspects.
E
The
other
comment
I'll
make
is
we
kind
of
group,
the
client,
libraries
or
the
languages
together
based
on
maturity.
So
if
you
think
of
like
a
java
or
a
javascript
or
a
net,
those
are
typically
like
the
top
tier
languages
that
are
most
commonly
used.
So
those
are
definitely
production.
Ready
where
say
like
a
php,
for
example,
is
like
a
tier,
2
or
tier
3.
Language
like
there
isn't
as
much
adoption
of
it
today.
C
E
Cool
so
happy
to
provide
that
information,
and
we
can
update
this
for
next
meeting
next.
Is
the
project
committing
to
achieving
cncf
principles
and
do
they
have
a
committed
roadmap
to
address
any
areas
of
concern
raised
by
the
community?
So
the
answer
is
absolutely
open.
Telemetry
is
quite
a
large
project,
so
there
are
many
repositories.
E
The
way
that
we
handle
this
is
that
every
repository
is
basically
its
own
sig
and
every
sig
kind
of
runs
independently
with
their
own
approvers
and
maintainers.
So,
if
you
think
about
issues
being
raised
by
the
community,
they're
usually
raised
by
individual
into
individual
repositories,
so
maybe
I
have
an
issue
with
java
instrumentation.
I
will
go
add
that
to
the
java
repository
each
of
these
sigs
also
maintain
their
own
roadmaps.
So,
for
example,
if
you
were
to
go
into
the
collector
repository
there's
a
docs
folder,
it
lists
roadmap
information.
E
Usually
these
are
around
major
milestones.
So,
for
example,
most
of
the
roadmaps
today
are
talking
about
the
ga
of
open
telemetry,
because
that
is
the
primary
focus,
but
a
longer
term
roadmap,
like
two
three
five
year
type
thing
will
also
be
laid
out
going
forward.
But
yes,
both
cncf
principles
and
addressing
community
concerns
as
well
as
roadmap
information,
are
all
top
priorities
for
the
project
and
and
constantly
review.
E
A
D
E
So
the
project
is
actually,
as
I
mentioned,
the
maturing
of
two
other
projects,
open
census
and
open
tracing,
both
of
which
have
extensive
support
in
the
community
today,
open
symmetry
is
basically
the
next
major
version
of
these
from
a
community
support
perspective,
both
contributions
as
well
as
adoption.
We
have
seen
that
all
three
major
cloud
providers
are
actively
on
board
and
have
their
own
kind
of
announcements
around
support
and
compatibility,
as
well
as
roadmap
information.
E
A
lot
of
major
vendors-
I
mean
not
all,
but
many
most
I
would
say
that
are
in
the
observability
or
monitoring
space
have
some
amount
of
support
for
open
telemetry.
Today,
open
source
projects
are
also
adopting
it.
So,
for
example,
jager
has
moved
off
of
the
jager
collector
and
now
uses
the
open
telemetry
collector,
as
the
collector
for
jager
fluent
bit
has
support
in
the
open
symmetry
collector.
E
So
I
mentioned
there
is
some
log
support,
there's
an
example
of
it,
and
even
outside
communities
like
spring
sleuth
now
has
experimental
support
for
open
telemetry,
so
it
kind
of
goes
beyond
just
the
cncf
end.
Users
both
are
approvers
and
maintainers
of
the
project,
which
means
they
are
actually
committing
engineers
to
develop
open
symmetry
as
well
as
deploying
it
in
their
production,
environment
and
I've
listed
four
examples
of
such
companies
here.
These
are
also
reflected
in
the
adopters
part.
E
Now
from
a
support
perspective,
open
symmetry
is
really
looking
to
address
the
primary
data
sources
and
observability,
so
traces,
metrics
and
logs
are
where
it's
at.
As
I
mentioned,
traces
and
metrics
are
more
mature
logs
are
a
little
bit
longer
out
there,
but
there
is
roadmap
information
for
this.
There
is
kind
of
a
path
forward,
so
we
don't
see
anything
that
would
inhibit
any
adoption
today.
E
There's
also
support
for
all
popular
open
source
things
as
well
so
zipkin
and
jaeger
in
the
case
of
traces,
prometheus
and,
of
course,
the
collaboration
with
openmetrics
for
the
metric
side
of
the
house
and
then
logs
fluentd
fluent
bit
and
very
recently.
Actually,
there
was
just
a
blog
post
on
devops.com
stanza
from
observe
iq
is
being
added
to
the
open
telemetry
project
as
well
for
native,
go
log
support.
C
Cool,
I
have
a,
I
have
a
question
so
I
feel
like
you
are
right
that
I
don't
know
like
those
those
supported
kind
of
projects
there
will
be
supported
in
future
and
like
there
is
a
good
collaboration
already
to
do
so.
But
it's
good
to
mention
that
it's
not
done
or
like
right
now
right,
there's.
Definitely
I'm
not
sure
if
that's
even
related
to
incubation
or
not,
but
would
be
nice
to
at
least
as
far
as
I
know,
it's
not
open,
openmetrics
compatible
right
now
like
there
is
good
effort
to
do
that.
E
Yep
yep
so
from
I
can
comment
on
the
high
level
and
I'm
happy
to
add
more
comments
in
the
in
the
doc
here.
So
jager
and
zipkin
should
be
fully
supported
from
both
a
receiving
and
an
exporting
perspective.
I
mean
technically,
the
same
applies
to
prometheus
and
openmetrics.
The
problem
is
the
translation
layer
in
the
collector
so,
for
example,
we're
using
the
same
go
client
library
that
prometheus
uses.
So
that
means
that
the
receiver
should
be
the
same.
E
The
problem
today
is
the
translation
into
otlp
format
does
not
natively
support
into,
and
out
of
so
we
can
definitely
add
a
caveat
for
that
needs
to
be
addressed,
and
I'd
also
argue
that
say
like
the
prometheus
receiving
capabilities
and
the
collector
are
not
ideal
and
need
to
be
rewritten,
so
there
are
definitely
gaps
from
from
that
perspective,
so
yeah,
if
you
want
to
I
can.
I
can
definitely
articulate
on
here
areas
of
like
we
know
these
gaps
need
to
be
addressed.
I
can
definitely
add
that
here,
yep.
E
D
C
E
Yeah
absolutely-
and
the
answer
is
yes,
so
I
mean
we're
working
directly
with
the
fluentd
and
fluent
bit
maintainers
and
the
stanza
maintainers
right
now
and
we
actually
have
log
support.
So
we
have
elastic
representation,
sumo
logic
splunk,
I'm
sure
I'm
missing
someone,
but
there
are
major
vendors
involved
in
this
conversation
too.
But
logs
are
very
early,
I
would
say
so.
I
would
call
them
alpha
best
case
scenario,
so
there's
definitely
gaps
and
things
that
will
need
to
be
worked
out.
There.
D
A
Okay,
okay,
okay,
so
just
on
the
not
to
drag
this
out
endlessly,
but
just
for
anyone
who
might
not
be
deep.
Look
deep
as
deep
in
this
as
the
two
of
us
are
or
the
three
of
us
who
just
talk,
there's
still
some
data
format,
incompatibilities
between
the
metrics
side
of
open,
telemetry
and
prometheus.
But
this
is
actively
addressed
and
I
think
the
timeline
which
you
just
mentioned
steve
is
absolutely
realistic.
So
maybe
just
a
little
bit
case
of
the
wordsmithing.
C
E
Okay,
next
one
document
that
the
project
is
useful
for
cloud
native
deployments
and
degree
and
what
it's
and
that
it's
architected
in
a
cloud
native
style,
so,
yes,
open
symmetry,
was
built
from
the
very
beginning
to
support
kind
of
cloud
native
frameworks
for
traces,
metrics
and
eventually
logs.
You
can
see
it
listed
in
the
assess
category
from
the
cncf
observability
end
user
survey.
Part
of
the
reason
why
it's
only
assessed
today.
It's
because
open
telemetry
has
not
gade
or
offered
a
stable
api.
E
Yet
we
just
talked
at
a
very
high
level
of
what
that
looks,
like
so
stable
api
for
traces,
let's
say
the
next
month:
stable
apis
for
metrics,
let's
say
the
next
quarter
or
quarter
and
a
half
stable
api
for
logs,
at
least
six
months,
probably
a
bit
longer.
So
there
is
a
path
forward
for
that
and,
as
I've
mentioned,
we're
already
seeing
other
like
library
framework
owners
preparing
for
this
spring
sleuth
is
a
great
example.
They're
only
offering
experimental
supports,
because
the
stable
api
hasn't
been
released.
E
Yet
they've
already
committed
that,
once
the
stable
api
is
released,
they'll
move
from
experimental
to
actually
supported
in
sleuth.
So,
there's
a
path
forward
for
this
as
well.
Clearly,
the
same
applies
for
prometheus
and
openmetrics.
We
have
that
working
group
to
kind
of
work
out
the
details
and
make
sure
it's
fully
compatible,
so
that
will
be
addressed.
It
will
clearly
take
a
little
bit
of
time,
but
we
do
have
a
path
forward
here.
A
E
Correct
I
mean
technically
apis
and
sdks,
because
the
configuration
happens
from
the
sdks,
so
richie
even
add,
comment
on
api
and
I'll
add
the
sdk
as
well,
but
you
need
both.
The
the
biggest
problem
is
like,
if
you
think
of
instrumentation,
there
are
two
primary
ways
of
doing
it:
automatic
which,
like
byte
code,
manipulation,
type
stuff
and
then
manual
where
a
user
goes
in
and
typically
adds
their
own
instrumentation.
E
The
manual
aspect
is
where
kind
of
the
rubber
hits
the
road
like.
If
you
don't
have
a
stable
api
and
you
introduce
breaking
changes.
Well,
you
just
broke
someone's
application
and
if
you've
run
that
on
tons
of
different
servers
in
production,
upgrading
an
entire
fleet
takes
a
really
long
time.
All
the
testing
that's
involved,
like
you,
don't
want
to
be
in
that
state.
So
once
we
get
to
the
actual,
stable
apis
here
backwards,
compatibility
will
be
offered,
and
thus
you
can
take
a
dependency
and
and
still
would
december.
E
All
right
we'll
move
on
a
bit
more,
but
please
don't
hesitate
to
get
involved
next
document
that
the
project
has
an
affiliation
for
how
cncf
operates,
understands
the
expectations
of
being
a
cncf
project,
definitely
like
both
in
the
gc
and
technical
steering
committee.
We
have
folks
from
from
open
tracing,
that's
already
in
the
incubation
status,
so
very
familiar
with
how
cncf
operates,
as
I've
also
mentioned.
There's
cloud
support
cloud
provider
vendor
and
end
user
support.
E
E
I
think
there's
something
in
the
chat
as
well:
yeah
and
jager
as
well.
That's
correct
awesome.
Let's
move
down
to
the
next
section
document
that
it's
being
used
in
production
by
at
least
three
independent
end
users,
which,
with
focus
on
adequate
quality
and
scope,
defines
so
we
have
the
cncf
end
user
survey,
which
lists
customers
that
are
using
it
also
listed
back
to
the
adopters
page.
E
Perfect
next
one
have
a
healthy
number
of
committers.
A
committer
is
defined
as
someone
with
a
commit
bit,
someone
who
can
accept
contributions
to
some
or
all
of
the
project-
oh
yeah,
so
according
to
cncf
dev
stats,
open
telemetry
is
the
second
most
active
project
in
cncf
behind
only
kubernetes,
there
are
a
large
number
of
contributors,
so
I
have
the
the
google
the
open
symmetry
teams.
You
can
only
see
if
you're
a
member
of
the
community,
so
that
link
may
not
work
for
you.
E
B
E
Perfect
next
one
demonstrate
a
substantial,
ongoing
flow
of
commits
and
merge
contributions.
Oh
yeah,
so
there's
open
symmetry
currently
listed
as
number
two
in
kind
of
the
project
here
and
if
you
haven't
used
devstats
before
really
cool
tool.
Hopefully
everyone's
seen
it
open.
Symmetry
is
listed
as
a
project
and
there
are
a
variety
of
different
dashboards
built
in
come
on.
You
can
do
it,
usually
it's
very
fast
here
we
go
so
we
could
see
like
based
on
repository
group.
A
A
C
E
E
We
do
not
call
it
ot,
because
open
tracing
is
also
ot,
but
we
try
not
to
abbreviate
either
so
open
symmetry
is
pretty
unique.
It
seems
to
be
kind
of
certified
to
be
fair.
Someone
owned
the
repository
on
github,
so
we
have
open
dash
telemetry
instead
of
open
telemetry.
But
beyond
that
like
it
is
definitely
a
unique
name.
E
What
does
it
do?
This
is
basically
copied
from
open
telemetry,
I
o.
So
this
is
basically
what
the
governance
board
has
kind
of
defined.
For
what
open
telemetry
is
it's
kind
of
high
level
and
vague,
but
that's
part
of
the
point.
The
way
to
think
about
it
is
both
apis
and
sdks
for
instrumenting
your
app
regardless
of
data
source,
so
traces,
metrics
and
logs,
and
it
offers
an
end-to-end
implementation.
So
you
can
do
both
the
generating
emitting
and
collecting
at
that
telemetry
data.
E
So
everything
you
deploy
on
your
side
of
the
environment
for
the
instrumentation
and
data
collection
aspects,
open
telemetry,
does
not
provide
a
back
end
today.
It
plugs
into
many
back
ends:
it's
vendor
agnostic.
It
supports
both
open
source
and
commercial
back
ends,
but
it
itself
does
not
provide
a
back
end
today.
E
Cncf
charter
mission-
yes
aligned
toc,
already
mentioned
that's
tbd,
the
entire
license
is
apache
2.0
based
everything
is
marked.
All
the
files
make
that
very
clear.
We
follow
the
seal,
cla,
easy,
cla,
bot,
type
stuff.
All
source
control
is
done
in
github
on
the
open,
telemetry
project.
For
what
it's
worth,
we
do
all
of
our
communications
on
gator,
not
on
slack,
maybe
that'll
change
one
day,
but
the
slack
channel
on
cncf
for
open
telemetry,
don't
use
it
go
to
getter.
You
might
talk
to
folks
external
dependencies.
E
I
mean
technically
none,
but
this
is
where
things
get
a
little
bit
more
complicated.
So
everything
that's
a
core
part
of
the
project
is
apache
2.0.
But,
as
I
mentioned,
we
support
like
receivers
and
exporters
which
could
be
other
open
source
projects
or
other
vendor
projects.
So
in
a
way
those
are
dependencies.
If
you
pull
in
those
components,
so
there
are
technically
external
dependencies
and
other
licensing
things
that
could
happen
depending
on
what
you're
pulling
in
from
those
projects
themselves,
but
it's
all
open
source
based.
A
C
E
Cool
next
one
release
methodology
and
mechanics.
So,
as
I
mentioned,
every
sig
kind
of
run
is
runs
independently,
so
cigs
determine
what
they
want
their
release
cadence
to
be
so,
for
example,
some
of
the
client
libraries
are
released.
Weekly
some
are
bi-weekly,
some
are
monthly.
Basically,
the
maintainers
of
each
stig
determine
what
they
want
to
do.
Typically
anywhere
from
two
weeks
to
a
month
is
kind
of
the
the
cadence.
E
And,
of
course,
if
there
are
security
or
what
have
you,
there
can
be
one-off
releases
as
well
in
general,
we've
kind
of
standardized
around
github
actions
for
all
of
the
the
ci
type
activities,
but
the
collector
still
uses
circle.
Ci,
there's
no
real
mandates
to
use
a
single
thing
in
opensymmetry
today,
but
we
are
starting
to
see
a
consolidation
around
github
actions,
so
that
might
be
the
long
term
plan
and
then
publishing
the
bits.
E
Well,
that's
language
specific,
so
like
in
the
case
of
java,
like
you
want
to
publish
to
maven
central,
we
offer
kind
of
the
common
locations
and
then
the
release
page
also
has
links
to
relevant
information.
If
you
need
like
the
actual
compile
bits
and
of
course
you
can
pilot
from
source,
if
you
want
to
run
it
locally,
so
that's
kind
of
the
end
user's
choice
as
well,
but
it
should
support
all
of
the
common
formats.
E
A
E
So
we
are
looking
at
ways
to
kind
of
mitigate
that,
but
today
a
distribution
is
run
by
whoever
controls
it
so
like
aws
splunk
has
them
as
well.
Those
distributions
are
maintained
independently.
They
have
their
own
release
schedule,
there's
no
oversight
from
the
open
telemetry
community
today,
so
everything
I
mentioned
about
relief
methodology
would
be
for
open,
telemetry,
sigs
and
projects
and
repositories
in
the
open
symmetry
github
board.
A
A
A
E
A
E
Oh
good,
all
good,
all
right,
so
the
next
one's
around
community
size
and
existing
sponsorship.
So
again
I
link
to
dev
stats.
There
are
over
92
companies
and
over
500
developers
that
have
contributed
to
the
project
according
to
devstats.
So
you're
welcome
to
go.
Take
a
look
at
kind
of
the
the
links,
but
it's
a
pretty
healthy
community
constantly
growing.
I'm
sure.
If
I
pull
one
of
these
things
up,
you'll
see
it's
it's
always
going
up
and
to
the
right,
which
is
what
you
want
to
see.
E
One
all
right
architecture,
design
feature
overview,
should
be
available,
so
there's
basically
three
major
components
to
open
symmetry.
There's
the
specification
there's
a
repository
for
that
the
specification
kind
of
defines
like
what
it
what
what
is
trace.
What
are
spans
like?
How
are
they
defined
same
for
metrics
same
for
logs?
That's
also
where,
like
semantic
conventions,
go
for
for
the
different
data
sources
that
there
exists
in
open
symmetry,
and
then
you
have
the
collector
and
the
client
libraries
that
kind
of
build
on
top
of
specification.
E
E
It
really
comes
down
to
what
are
your
use
cases
and
then
some
guidance
around
how
you
should
deploy
everything
is
listed
as
part
of
like
the
getting
started
guides
for
open
telemetry
beyond
this
you're,
seeing
additions
being
added
to
the
project
over
time,
but
these
are
kind
of
the
main
main
components
in
terms
of
repositories.
There
are
50
plus.
So
it's
a
quite
diverse
thing.
A
E
There's
a
ton
of
material
I
linked
to
a
webinar
too
it's
about
an
hour
long,
but
at
least
gives
you
a
high
level
overview
if
you're
not
familiar
with
open
telemetry
and
of
course
we
can
drill
into
specifics
of
things.
So
if
people
have
pointed
questions,
let
me
know
we
can
pull
in
the
right
people
bogdan's
on
the
call
here
I
think
morgan
was
here
earlier,
maybe
he's
still
here
he
is
so
like
we,
we
can
get
you
the
right
folks
that
can
answer
any
follow-up
questions.
You
have.
E
E
E
We
haven't
really
planned
for
that
yet,
but
with
otlp,
for
example,
being
the
format
that
is
a
potential
option,
things
that
are
in
scope,
but
beyond
the
current
roadmap,
we've
already
talked
about
logs,
where
there's
already
some
experimental
support
in
the
project,
but
that
is
not
part
of
the
original
ga
scope
that
we're
targeting
and
what
is
out
of
scope.
As
of
today,
as
I
mentioned,
there
is
no
back
end.
This
plugs
into
back
ends.
It's
completely
vendor
agnostic,
but
open
telemetry
is
not
providing
that
back.
End
go
use
another
one.
E
A
E
So
this
might
be
a
good
stopping
place
and
have
people
like
please
review
the
entire
dock.
Even
sections
we've
already
talked
about.
Please
comment
I'll
make
sure
this
goes
out
on
the
mailing
list
and
in
the
slack
channel,
and
hopefully
either
late
tonight
or
by
tomorrow,
I'll
incorporate
the
initial
feedback
we
have
from
today's
meeting.