►
From YouTube: CNCF SIG Observability 2021 03 02
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
A
F
E
D
Well,
so
ambassador
is
trying
to
donate
its
component
to
cncf,
but
the
the
company
used
to
be
called
something
else,
but
the
company
renamed
themselves
to
ambassador.
As
a
result,
they
can't
upload
a
component
called
ambassador
for
ip
reasons,
so
they
had
to
rename
the
component
that
they're
uploading
and
it's
now
called
emissary
ingress
and
I'm
not
sure
how
I
feel
about.
G
C
I
J
A
K
A
K
D
K
I
For
that
let's
say
I
think
this
one
would
be
better
to
leave
to
the
next
meeting.
I
was
expecting
some
colleagues
to
join
me,
but
they
couldn't
join
today.
L
Yeah
so
so
maybe
I
turn
on
my
camera
when
I
speak
so
we
have.
We
have
parked
this
this
paper,
for
it's
been
quite
a
long
time.
We
have
talked
about
january,
but
then
we
it
started
quite
well
so
the
beginning
of
the
paper,
I'm
actually
quite
okay
with
the
content
there.
But
then
we
started
having.
A
L
But
then
he
didn't
have
more
time
to
continue
editing
the
paper
and
I
think
we
should.
We
should
continue
and
have
one
version
for
for
people
here
to
review.
L
So
this
this
has
been
abandoned
a
little
bit
and
I
I
think
we
should
yeah.
We
should
take
it
up
and
some
people
have
experiencing
more
areas
than
others,
maybe
more
in
application,
others
more
in
infrastructure
and
I
think
yeah.
This
is
how
maybe
we
should
share
a
little
bit
small
sections
with
people
that
have
more
experience
in
different
areas
and
then
the
load
is
not
too
much.
I
mean
writing
one
two
three
paragraphs
and
then
somebody
stitching
the
text
together.
It's
it's
not
a
big
something
big
to
ask.
I
L
I
That's
someone
that
has,
I
mean
someone
that
is
willing
to
do
the
work
well,.
K
L
L
We
have
some
so
in
at
least
where
we
start
more
in
the
part
of
data
visualization
and
exploration
they're
basically
empty.
So
there
are
some
names
that
were
written
here
as
candidates.
I
think
michael
was
one
of
them
for
use
cases.
Arthur
was
also
here,
like
just
writing
something
about
beginners
approach,
but
there
is
there.
There
are
some
other
sections
that
are
still
empty.
K
No,
I
think
that's
a
good
direction
right,
like
first
of
all,
there
is
no
expectations
to
like-
I
don't
know
finish.
It
super
super
quickly
right,
it's
community
driven,
so
it's
okay
for
some
periods
to
be
taking
longer
right.
So
I
would
see
this
as
like
some
community
driven
piece
of
documentation
about
observability,
so
I
think
we
just
need
to
yeah,
announce
it
more
and
maybe
split
essentially
interesting
topics
and
that
have
gaps
in
it
and
just
yeah
try
to
ask
personally
as
well
people
who
might
be
interested
so
proposing
candidates.
K
I
think
that's!
That's
really
nice
solution,
but
yeah
artur
and
simon
is
not
no
expectations
that
you
will
write
that
on
your
own.
I
think
that's,
that's
definitely
not
what's
happening,
so
I
would
say
announce
it
better
and
and
try
to
gather
more
people
on
on
those
and
and
kind
of
one
way
would
be
to
also
make
sure
people
are
motivated.
K
L
Yeah,
so
I
really
so,
the
initial
motivation
of
this
document
was
basically
to
consolidate
to
have
something
that
comes
from
cncf
when
somebody
talks
about
you
know
high
level
and
observability,
but
also
going
a
little
bit
more
into
details
like
use
cases
or
if
your
perspective,
if
you're
an
application
developer
versus
you,
are
an
infrastructure
engineer
dealing
with
observability
and
some
other
things
that
are
happening
in
the
community
as
well.
L
So
we
don't,
we
don't,
have
a
very
fixed
structure
there,
but
I,
I
would
very
much
like
to
have
some
input
from
people
here
that
working
in
various
areas
to
to
make
this
document
happen.
L
And
when
you
talk
about
announcements,
you're
talking
about
using
our
select
channel
we're
going
wider
with
that
than
that
actually.
K
Yeah,
I
would
I
would
you
know,
mention
this
wider
and
say
you
know
we
we
can
definitely,
you
know,
make
sure
this
has
some
structure
and
and
go
into
good
direction,
but
we
can
definitely
ask
you,
know
and
say
on
twitter
and
hey
join
our
work
group
and
yeah
just
make
it
more
known,
because
I
think
it's
only
you
know
a
few
people
or
like
at
least
this
observability.
That
is
only
kind
of
seeing
that
and
just
having
more
traction
will
you
know,
give
people
more
motivation
to
also
contribute.
K
A
Before
there's
definitely
interest
from
from
the
wider
community
as
well,
I'm
working
on
the
chinese
version
of
the
observability
community
and-
and
they
also
expressed
interest
so
to
contribute
there
and
then
subsequently
translated
into
mandarin.
So
I
don't
know
what
what's
the
best
way
is
a
tweet
or
a
you
know.
M
I
know
I
have
jumped
in
but
like
from
agenda
or
initial
thing
from
the
from
the
working
group,
we
said
that
we
said
that
the
canonical
places
are
slack
and
the
mailing
list,
with
the
mailing
list
being
a
must
and
the
slack
being
recommended.
That
being
said,
I
do
think
that
we
would
benefit
from
from
also
having
more
public
channels.
So
I
think
we
need
to
split
between
people
who
take
active
interest
of
working
within
and
moving
within
the
sick
and
then
external
communication
of
the
sig,
but
again
I'm
jumping
in
in
the
middle
course.
M
I
M
K
L
Yeah,
I
mean
at
least
from
the
tracer
from
tracing
parts.
I
forgot
his
name
now,
but
the
guy
from
jaeger
he
could.
She
could
do
so.
I
mean
he
could
at
least
read
something
here
and
say
this
is
rubbish
or
or
give
some
pointers.
That
would
be
interesting.
L
I
Helps
this
money,
do
you
want
to
talk
about
more
in
depth
on
slack
later
yeah,
okay,.
L
But
mailing
list
and
other
folks
in
the
observability
groups
that
are
not
here.
That
would
be
probably
my
first
bet
before
we
go
on
twitter
with,
let's
say
a
document
that
is
not
in
a
great
shape.
Yet
I
would
go
on
twitter
if
it's
for
calling
to
call
for
people.
That
would
be
like
something
that
doesn't
have
so
many
gaps
that
we
have
now.
M
M
M
Yeah,
so
just
to
to
have
the
one
thing,
because
I
do
expect
that
hopefully
finishing
the
due
diligence
for
open
telemetry
will
take
the
rest
nna,
who
might
be
on
the
call
or
might
not
be
on
the
call,
took
a
step
at
writing
a
a
end
user
guide
about
distributed
tracing.
So
just
look
at
it
give
feedback
if
possible-
and
I
think
that's
already
it-
what
we.
What
we're
talking
about
that.
So,
let's,
let's
start
with
continue
with
the
open
telemetry
due
diligence.
D
All
right
here
we
go
again
welcome
folks
number
three
richie.
Do
you
still
have
the
action
item
here
I
mean
we
talked
about
it
on
the
toc
call
at
least
bartok,
and
I
were
for
there
do
you
want
to
follow
up
on
this
one
or
what's
the
next
steps
for
number
three,
I.
M
Failed
to
follow
what
do
you
mean
on
the
on
the
question
of
sub
project?
Yes,
no.
I
failed
to
to
email
them,
as
you
probably
noticed,
did
any
guidance
come
from
the
toc
code.
K
B
K
It's
a
it's
a
good
question.
I
think
there
was
nothing
no
clear
decision.
There
was
like
one
opinion
from
this.
Was
that
yeah
it's?
It's
kind
of
you
know
important
to
make
sure
that
you
know
the
incubation
is
high
bar.
So
we
expect
things
to
be.
You
know
kind
of
stable,
but
other
mentioned
other
aspects
where
you
know
there
might
be
communities
and
some
features
are
alpha
and
it's
graduated.
So
it's
fine
and
then
kind
of
I
navigated
that
you
know.
K
Metrics
and
logging
are
kind
of
important
parts
of
the
observability
space
and
you
know
missing
those
are
kind
of
a
major
major
kind
of
part
of
the
open
telemetry.
However
steve
you
pointed
that
there
are
so
many
other
aspects
like
sdks.
K
The
whole
collector
stuff
is
like
many
many
things
and-
and
there
were
two
interesting
experience-
kind
of
from
argo.
I
guess
and
to
be
honest,
I
didn't
get
the
direction
of
it.
Was
it
that,
yes,
we
should
just
if,
if
there's
a
movement
behind
that,
if
there
is
like
a
strong
community
that
we
can
trust
that
you
know
those
big,
even
chunks
of
unfinished
work
will
be
worth
kind
of
recommendation.
D
Yeah,
okay,
that
makes
sense.
I
think
that
makes
sense.
The
way
I
read
into
the
argo
thing
is:
it
looks
like
argo's
going
up
for
graduation
and
has
a
similar
problem
in
that
it's
a
big
project.
There
are
plenty
of
aspects
that
are
experimental
or
alpha
or
whatever
you
want
to
call
it,
and
they
too
have
to
deal
with
it.
So
I
I
don't
personally,
I
don't
think
that
sick
observability
needs
to
solve
this
problem,
just
raise
it
to
the
toc
and
the
toc
needs
to
make
that
call.
K
M
Yeah,
okay,
so
let's
revisit
that
point,
I
guess
also.
We
should
close
all
the
old
comments,
ideally
during
the
call,
so
we
have
a
paper
trail
of
them
being
closed
so.
M
M
M
D
Good
regarding
the
comment
above
since
we
do
want
to
clear
things
out
right,
so
the
we
have
the
adopters
page
updated.
There
was
a
request
around
adding
different
signals.
That's
a
little
bit
harder
because
adoption
is
on
a
client
library
perspective
and
I've
already
received
feedback
from
the
adopters.
D
Saying:
look
we're
not
going
to
keep
updating
that
page
every
single
time
we
change
something
in
our
environment,
so
I'd
like
to
propose
the
update
that
I
basically
wrote,
which
is
that
given
tracing
a
stable,
instrumentation
libraries
adopted,
are
for
the
tracing
signal
today
and
for
the
collector
adoption
is
for
tracing
in
metrics
today.
So
I've
clarified
where
we
are
without
actually
updating
that
page,
because
I
think
it'll
be
a
one-time
update.
That's
constantly
out
of
sync
adoption
is
from
the
components
perspective,
not
necessarily
from
the
signals
perspective.
D
Oh,
so
any
objections
to
resolving
this
comment.
M
D
M
M
Okay,
so
as
we
have
the
comment
that
we
need
to
review
this,
then
at
least
we
need
to
make
a
call
for
consensus
on
if
that
is
a
way
forward.
I
given
the
product,
but
I
think
yes,
but
so
should
we
resolve
that
or
let
me
rephrase
unless
there
are
objections.
I
will
just
close
the
comment
and
to
do
with
the
basis
of
what
steve
just
says.
It's
just
said
all
agreed.
Anyone
disagreeing.
D
Very
good
awesome
next,
one
there's
a
question
about
fork
repositories
and
such
so.
Everything
in
the
adopters
page
is
adopting
upstream
there's
no
easy
way
to
kind
of
track.
This
aspect:
either
I
mean
open
to
suggestions
even
when
vendors
are
listed,
like
vendors
are
adopting
it
internally
as
well.
It
doesn't
necessarily
mean
it's
a
distribution.
D
M
D
So
if
you
go
to
the
community
page,
it
lists
vendors
supported
on
openslimetry,
and
so
here
are
all
the
vendors
and
if
they
have
a
distribution
links
to
those
things
are
applied
or
if
they
just
have
exporters,
and
it
would
link
to
the
exporter
specifically
the
goal
long
term
is
that
hotel
will
likely
certify
distributions
just
like
kubernetes
does
today.
It's
not
doing
that.
Currently.
N
Yeah,
I
mean
just
to
add
to
steve's
point:
we
are
working
on
the
requirements
for
certification
of
distributions
and
and
we'll
be
publishing
that
clearly,
but
you
know
keeping
in
mind
with
the
similar
guidelines
that
kubernetes
also
has.
M
K
Yeah,
I
would
be
curious,
like
can
you
tell
quickly
roughly
like
how
the
certification
would
look
like?
Maybe
I'm
not
familiar
with
kubernetes
one,
because
you
know
the
concern
is
that
those
distributions
can
be
anything
right
now
and
just
claim
open.
Telemetry
incubation,
you
know
incubated
someday,
you
know
on
stage
and
they
will
do
anything
inside
there
and
we
don't
have
any
control
because
it's
like
yeah
some
other
projects.
So
I
wonder
yeah
what
what
are
the
measurements?
I.
N
Mean
some
of
the
measurements
again
murders
are
are
obviously
not
only
clear
guidelines
on
you
know
what
is
integrated
from
a
component
standpoint,
whether
that's
the
collector
component.
So
that's
prometheus,
you
know
end-to-end
support
or
other
components
which
are
in
the
sdks,
that
is,
the
library
implementations,
but
also
stability
guarantees,
whether
that
those
are
you
know,
performance
guarantees,
testing,
guarantees,
support
and
maintainability
guarantees
for
long-term
support
and
and
really
requirements.
D
Yeah
and
again
we're
not
trail
blazing
here,
like
here's,
the
kubernetes
one,
it's
a
github
repo.
You
can
take
a
look
at
kind
of
the
instructions
they
have
automated
processes
that
you
run
that
actually
conforms
make
sure
that
your
distribution
conforms
to
the
guidelines.
It
publishes
results
like
we're
not
going
to
influence
something
new
here,
we're
going
to
follow
something
very
similar
to
this
yeah.
K
G
Also,
just
to
add
a
bit
of
color
just
from
working
at
two
vendors
on
this
project
previously
and
talking
to
the
others
like
just
because
the
project
is
so
focused
on
data
collection.
I
think
most
of
the
vendors
and
contributors
are
racing
as
fast
as
they
can
to
have
as
little
proprietary
code
like
trying
to
push
as
much
as
they
can
into
into
the
core
oss
so
that
they
don't
have
to
continue
maintaining
it,
and
so
they
can
and
they
can
share
it
with
everyone
else.
G
If
this
was
a
project
that
had
the
head
back
end
for
processing,
I
think
the
incentives
there
would
be
very
different,
but
because
it's
just
data
collection,
most,
the
vendors,
don't
want
to
specialize
in
data
collection
and
they
really
don't.
They
honestly
do
not
want
to
have
their
own
data
collection
systems.
Long
term.
K
There
were
mostly
opinions
from
me
and
and
open
telemetry
guests
here,
and
I
wonder
if
kind
of
I
invented
invited
peter,
maybe
peter
you
want
to
give
some.
I
don't
know,
I
don't
know
some
some.
What
do
you
think
about
that?
Because
I
kind
of
I
don't
know
like,
I
feel,
like
you,
had
a
kind
of
nice
experience
on
on
those
monitoring
and
collection
stuff
already
yeah.
H
I
can
say
a
few
words
here,
I'm
I'm
here
as
sort
of
like
bartek
and
I
were
having
a
conversation
about
this
space
just
kind
of
informally,
and
we
touched
on
some
of
this
stuff,
and
so
I'm
like
here,
I
guess
a
sort
of
maybe
just
a
outside
perspective.
I
don't
know
if
this
is
actually
what
anyone
wants
or
needs,
but
I'll.
Just
happily
summarize
just
a
few
things
when
I
learned
about
this
whole
initiative
kind
of
the
points
that
got
raised
in
my
mind.
H
So
just
a
bit
of
background
I
like
was
for
a
long
time
deep
into
really
stuff
in
kind
of
like
go
world
and
function.
Microservice.
H
Universe-
and
I
actually
can
claim
that
I
was
the
one
who
invented
the
three
pillars
of
observability,
if
you
can
believe
it
in
one
fateful
meeting
with
some
key
players
back
in
the
day
so
anyway,
accolades
check.
What
is
interesting
to
me
about
this
whole
conversation.
H
Is
that
what
it
reveals
about
the
role
that
the
cncf
plays,
as
it
selects
projects
to
like
put
little
gold
stars
on
right,
because
my
understanding
was
that
the
things
that
it
lifts
up
into
incubation
and
what
are
the
other,
like
statuses,
that
there
are
there's
like
approved,
vetted
sandbox.
H
Graduation,
yes,
it
says
so
my
understanding
was
that
as
projects
like
move
through
those
stages
and
get
like
check
marks
from
the
cncf,
it
is
because
they
have
proven
themselves
in
the
like
developer
space
like
they're
in
use.
They
are
like
de
facto
standards
for
these
things
and
maybe
not
all
the.
Maybe
all
of
them
have
to
be
all
de
facto
standards,
but
like
basically
that's
what
the
cnc
is
doing
is
like
saying:
hey.
These
things
are
good.
H
You
can
trust
these
things,
but
what
it
feels
like
is
happening
here
is
like
there
are,
a
collection
of
expressed
user
needs
that
are
real
and
need
solutions,
and
the
open,
telemetry
group
is
like
collecting
them
and
then
like
trying
to
suggest
products
that
solve
them
in
various
ways
ultimately
solve
all
of
them,
but
like
haven't
yet
done
so,
and
so
it
feels
like
either
it's
super
premature
or
it
reflects
that
the
cncf
isn't
actually
about
what
I
thought.
H
H
Building
solutions
that
it's
like
customer
companies
or
whoever
is
like
following
the
cncf
to
things
they
need.
Maybe
it's
that
and
maybe
that's
okay.
I
don't
know,
but
that's
not
what
I
understood
anyway
yeah.
This
is
my
perspective
and
like
maybe
the
most
concrete
thing
I
should
have
maybe
opened
with
this
is
like
so
like
before
prometheus
was
in
that
process.
H
I
knew
like
tons
of
people
who
use
prometheus
right
in
my
like
space
in
my
role
but,
like
I
don't
know,
anyone
who
uses
open
telemetry
right,
they
know
of
it,
but
I
haven't
met
anyone
who,
like
has
ditched
their
prometheus
instrumentation
library
for
hotel
right
like
a
couple
of
tried,
but
like
it
just
hasn't
happened
yet
right.
So
that's
what's
interesting
to
me
and
that's
I
don't
know,
maybe
worth
discussion.
Maybe
it's
all
already
been
said.
I
don't
know
what
do
you
think
I.
N
Think
peter
again,
you
bring
up
some
good
points,
but
I
would
say
that
you
know
having
rolled
out
aws
distribution
for
open
telemetry.
We
have
several
customers
who
are
using
not
only
open
telemetry
as
in
commodity
agent,
if
you
will,
but
also
you
know
using
prometheus,
and
it
is
an
win-win
for
both
ecosystems.
It's
not,
you
know,
replacement
necessarily
it's
it's
also.
N
You
know
several
customers,
large
customers,
moving
towards
building
out
their
kubernetes
based
ecosystems,
as
well
as
other
compute
support,
and-
and
I
don't
think
it
is
fair
to
say
that,
because
there
are
several
customers-
and
I
am
happy
to
bring
you
a
list
if,
if
needed,.
H
H
Is
that
they're?
All
private,
though,
is
that
correct,
like
no
corporate
customers,
yeah.
E
But
like
this
is
from
the
doctor's
page,
but
also
like
so
I
think
also
so.
People
are
wondering
like
who
are
the
people
you
talk
to,
because
I
think
one
thing
that
we
need
to
actually
address
about
open,
telemetry
and
what
cncf
has
actually
done
is
cncf
is
used
to
only
talking
to
like
niche
cloud
native
companies
right
who
are
used
to
implementing
everything
on
their
own,
but
where
actually
cncf
is
going,
is
actually
bridging
the
gap
from
everyone
who
used
to
be
on-prem
yeah
and
that's
where
open
telemetry
is
actually
making
the
biggest
inroad.
E
E
Be
actually
wait
right
and
they're
going
to
be
actually
not
using
their
own
implementation
of
things,
but
trying
to
find
like
libraries
there
and
also
especially
when
it
comes
to
observability
space,
where,
like
you
know
like
okay,
yes,
coming
from
splunk
like
we
are,
we
are
quote-unquote.
You
can
cause
evil
overlords
right,
but
all
a
lot
of
our
customers
don't
have
time
to
implement
their
own.
Like
implementation
promises
you're
going
to
want
to
use
libraries
because,
from
their
point
of
view,
it's
not
worth
it
and
that's
like.
A
D
And
the
other
thing
I'd
add
is
like
the
criteria
for
incubation.
I
don't
know
if
everyone's
kind
of
familiar
with
the
cncf
terms,
but
there's
no
criteria
of
like
in
the
incubation
status
being
the
de
facto
standard,
replacing
other
standards
like
being
the
only
solution.
None
of
those
are
criteria
for
incubation
they're,
they're
listed.
H
Here
I
didn't
mean
to
imply
like,
like
the
only
choice
or
like
or
whatever,
but
but
like
wide
adoption
and
and
this
the
question
to
me
was
like
who
am
I
talking
to
right,
which
is
completely
fair.
I
I
totally,
everyone
has
their
own
like
little
lens,
for
which
they.
H
Yeah
yeah
exactly
so
like
the
people
I
talk
to
are
largely
like
open
source
communities
and
adjacent
like
slack
rooms
and
and
mailing
lists
and
github
issues
so
like
stuff.
That
is
public
in
that
sense
often
products
of
corporate
environments,
but
largely
not,
and
I
think,
an
equal
measure,
a
lot
of
small
medium,
some
large
startups
and
companies
that
I
consult
for
often
in
a
go
capacity,
often
in
a
observability
capacity.
So.
H
Right
the
people
for
whom
openstack
has
completely
failed
so
on
to
the
next
thing.
Here
we
go:
let's
try
it
again,
yeah
yeah
so
like
I
have
no
visibility
into
them,
and
if
that,
if
that
is
your
like
user
base,
then
I
can't
speak
to
it
right,
because
I
have
no
idea
well,
it's.
C
A
Sorry,
you
mentioned
one
thing,
which
is
a
little
bit
worrisome
for
me,
and
that
is
standards.
Cncf
is
not
a
standardization
body
right.
It's.
H
A
A
sensation
body
like
w3c
or
itf
right,
it's
not
about
we
are
not
creating.
You
know
here
declaring
this
is
the
standard
I
feel
and
based
on
the
conversations
that
I
have
with
our
customers.
A
I
can
vouch
for
that
that
there
is
certainly
a
huge
interest
there,
especially
around
standardization,
across
different
signal
types,
and
you
know
the
clear
method
that
we
have
here
in
the
sig
is
to
provide
that
due
diligence
in
terms
of
the
requirements
that
we
see
here
in
the
process,
and
that
is
adoption
and
that
to
me
looking
at
what
is
there
is
clearly
given.
I
really
don't
want
to
get
into
that
standardization
discussion
saying
like
you
know,
there
is
a
standard
and
you
know
is
hotel
the
old
dominating
standard
or
not.
A
I
just
let's,
let's
stay
clear
of
this
standard
there.
It
is
a
specification
and
there
is
a
clear
uptake
and
adoption
there
yeah.
What
I
see.
H
But
okay,
okay,
so
maybe
this
is
an
important
point:
does
that
uptake
have
to
be
organic
or
can
it
be
sort
of
like
outward
sales
driven
for
like
work.
M
F
J
M
Document
it,
it
is
much
more
about
the
direction
and
I
don't
have
any
problem
letting
this
this
discussion
continue.
I
just
want
us
to
use
the
time
deliberately,
so
we
can
also
focus
back
on
the
document
or
we
can
discuss
this
more.
Both
is
totally
fine
with
me.
Maybe
one
point
and
I
obviously
have
like
20
heads
and
I'm
very
much
torn.
M
I
would,
from
my
perspective,
most
prometheus
and
prometheus
ecosystem
users
are
not
truly
cloud
native,
I
would
say
more
of
them
are
in
the
brownfield
data
center
space
just
because
of
sheer
numbers,
but
oh
no,
I'm
already
going
into
discussion.
So
should
we
continue
back
on
the
with
the
document
or
should
we
discuss
the
points?
Peter
wrote
up.
Both
is
fine
with
me.
I
just
wanted
to
on.
D
D
If
not,
then
we
should
probably
either
create
another
dock
like
bartik
did
or
like
schedule
another
time
to
have
that
conversation,
because
I
think
the
goal
is
to
try
to
get
through
this
stock
from
a
consensus
perspective
and
if
it's
related
like
if
it's
an
incubation
criteria
thing
and
we're
not
going
to
meet
that
criteria,
for
whatever
reason,
that's
the
the
primary
focus,
I
think
we
should
have
for
this
audience.
K
M
D
M
That's
where
I'm
trying
to
go
that
we
that
we
have
a
consensus,
push
position
of
of
everyone
in
this
call
here
that
that
is
a
statement,
because
I,
like
again,
I
have
20
different
heads
here,
so
I'm
I'm
very
deliberate
about
which
one
I'm
I'm
currently
wearing,
but
for
the
tracing
aspect.
I
do
think
there
is
no
debate
that
there
is
white
adoption.
C
M
M
M
Perfect,
thank
you.
That's
similar
to
how
how
the
prometheus
things
work.
If
you
saw
the
recording
there,
we
we
nailed
down
one
consensus,
and
then
we
built
possible
consensus
on
top
of
it.
M
Of
course,
that
has
shown
to
to
take
the
least
time
to
discuss
so
as
a
first
point
of
consensus,
new
consensus,
because
we're
actually
revisiting
but
okay,
sick
observability
has
consensus
that
there
is
white
and
organic
adoption
of
open,
telemetry
tracing
all
agreed.
Anyone
disagreeing
okay,
just
for
the
record,
I'm
uppercasing
that
one
t!
D
M
With
everything
in
the
statement
about
what
we,
what
what
that's
not
making
a
statement
about
the
whole
project,
this
is
just
trying
to
split
out
the
sub
components.
So
we
in
the
sick
can
find
a
consensus
and
then
just
bounce
this
to
toc
and
they
can
decide
whatever,
because
I
don't
think
we
will
be
making
progress.
Otherwise,
and
I
would
like
to
finish
at
some.
C
D
Have
is
that
there
are
I,
I
kind
of
raised
this
in
the
toc
call,
so
some
of
you
are
on
there.
Some
of
you
were
not
so,
I
think
I'll,
just
repeat
it
for
the
entire
audience,
from
an
open
symmetry
project
perspective,
all
of
the
sigs
have
components.
Those
components
are
adopted
or
not
adopted.
The
primary
components
today
are
the
instrumentation
libraries,
which
are
language
specific
and
the
collector.
D
They
are
in
our
reference
implementation
on
top
of
the
specification,
so
you
have
a
dependency
on
the
specification
to
make
that
work.
All
of
those
components
are
then
tied
to
signals.
I
feel
like
the
last
two
meetings
in
this
audience.
We've
been
focusing
a
lot
on
the
signals,
but
it
says:
does
the
project
have
production
grade
deployments
that
are
high
quality
and
high
velocity
for
all
of
the
components?
D
The
answer
is
yes,
the
the
nuance
there
is
that
that
is
a
yes
for
tracing
signals
and
I
think
that's
what
we've
all
kind
of
gotten
hung
up
so
far
is
that
well
what
about
the
metrics
and
logging
signals
and
then
there's
kind
of
the
back
and
forth
on?
Does
that
matter
or
not?
So
maybe
one
way
to
approach
this
is:
do
we
have
consensus
that
all
of
the
components
in
open
symmetry
are
adopted?
D
First,
then,
we
could
make
a
note
about
the
tracing
signal
specifically,
which
is
what
the
line
in
green
currently
captures
and
then
the
final
one
would
just
be
more
of
a
note.
Metrics
and
logs
are
not
stable
yet
and
are
not
part
of
this
consensus,
or
something
like
just
articulate
that
there
are
additional
signals
that
exist,
but
that's
separate
from
the
project
as
a
whole
right.
You
can
still
adopt
and
be
in
production,
regardless
of
whether
or
not
you
have
those
other
signals.
K
Right
and-
and
I
think
why
I'm
pushing
this
direction
is
that
you
are
right,
those
components
might
be
adopted
right,
but
it's
still
only
only
one
signal
is
implemented
on
those
components
like
collector
the
most
kind
of
implemented
base
and
the
most
adopted
why
people
use
essentially
sdk
and
collector
is
mostly
for
tracing
capabilities
right.
So
all
of
this
is
across
all
the
components.
N
I
don't,
I
don't
agree
with
you,
but
because
you
know
what
I
can
say
is
that
we
have
built
instrumentation
around
aws
monitoring,
back-ends
such
as
cloudwatch
or
which
handles
metrics
or
prometheus,
are
managed
service
for
prometheus,
and
the
collector
components
that
exist
today
are
being
added,
are
being
used
for
by
customers,
for
you
know
again
supporting
metrics.
N
Now
there
is
a
clear
roadmap
for
metrics,
which
is
being
currently
worked
on
by
the
project
and
a
very
clear
roadmap
and
milestones
that
are,
you
know,
have
been
established
in
the
past
few
months
and
work
is
in
progress,
and
so
is
that
happening
for
logs.
So
to
say
that
there
is
no
support.
Is
inaccurate.
E
G
Yeah,
like
like
google,
for
example,
when
they
have
customers
who
come
in
with
windows
vms,
they
tell
them
to
use
the
open,
telemetry
collector
and
they
went
and
added
like
windows
system
metrics
right
like
it's,
it's
more
than
just
a
handful.
M
There
an
overview
or
like
a
lot.
I
I
I
feel
as
if
part
of
our
problem
here
is
we
are.
We
are
discussing
on
qualitative
statements
a
lot
and
not
going
towards
quantitative
statements.
H
M
M
And
always
trying
to
get
people
to
to
agree
for
those
two
decades.
N
Richard
again,
I
agree
with
you
that
you
know
we
are
happy
to
provide
any
quali
quantitative.
You
know
measures
or
whatever.
That
means.
If
we
can
define
that
clearly
and-
and
you
know
we
the
specification,
because
the
implementations
as
steve
pointed
out,
follow
the
specification,
there
is
certainly
a
compatibility,
matrix
or
a
matrix
of
features,
which
you
know
actually
can
be
highlighted.
K
Right,
okay,
I
think
you
know
yes,
I
mean
definitely
the
number
would
be
super
nice,
but
my
my
worry
is
that
you
know
I
always
from
the
beginning
was
you
know,
excited
to
see
open
telemetry?
You
know
protocols
to
be
you
know,
kind
of
de
facto
standards
right.
We
know
what
to
use
for
logging
for
replicating.
K
You
know
log
lines
across
systems
and
from
client
to
the
agent.
Let's
say
the
same
for
traces,
the
same
for
metrics
and
suddenly
we
totally
are
on.
I
mean
open.
Telemetry
looks
like
it's
very
unfocused
on
this
point,
because
we
are
adding
collectors
with
tons
of
apis
and
we
kind
of
we
we
quantify
the
quality
of.
If
it's
incubation,
graduation
by
amount
of
apis.
This
is
not
healthy
for
community.
E
G
I
just
I
just
want
to
be
mixed,
clarify
something
we
talked
about
a
few
meetings
ago
like
we.
We
should
consider
the
logging
part
of
open
telemetry
experimental,
like
the
community,
has
very
purposely
sort
of
put
it
off
in
a
thing
where
we're
slow,
walking
it
and
very
slowly
working
on
it,
because
we're
very
focused
on
tracing
tracing
is
now
ga
metrics
is
next,
but
I
don't
want
to
look
at
our
ambition
of
eventually
bringing
in
some
logging
components
and
doing
some
work
and
logging.
E
E
D
Yeah,
the
other
thing
I'd
add
is,
I
think,
we're
also
blurring
the
lines
between
incubation
and
graduation.
This
is
not
a
graduation
conversation
if
it
was.
I
think
many
of
the
points
being
raised
here
are
completely
valid.
Like
you,
don't
have
any
metric
support,
that's
stable.
Yet
how
can
you
graduate,
but
that's
not
what
we're
talking
about
we're
talking
about
incubation
and
the
criteria
for
that
is
having
production
deployments
that
are
high
quality.
D
We
do,
it
doesn't
say
it
has
to
be
high
quality
for
every
single
thing
like
it
is
high
quality
to
the
point
where
customers
today
have
adopted
in
production
environments.
So
I'd
like
to
make
a
proposal.
I
I
made
an
update
here
and
I
put
three
separate
bullets
that
we
can
try
to
talk
about
to
see.
If
maybe
this
gets
us
closer
to
a
consensus,
so
I'll
read
it
aloud
just
so
we
can
talk
about
it
live
just.
D
D
It's
this
line,
it's
the
exact
same
line.
I
just
moved
tracing
from
the
end
to
here,
but
I
I
didn't
make
it
green,
because
I
think
we
should
talk
about
it
again.
M
I
agreed
just
as
a
point
of
order
everyone
who
touches
a
green
line.
Please
talk
about
it
before
you
touch
the
green
line
because
they
are
present
yeah.
It
does
no,
no
it's
fine.
We
we
caught
it,
but
this
is
like
my
whole
system
is,
is
built
on
the
green
lines
never
ever
being
touched,
which
is
why
I
made
public
or
made
it
explicit.
Also
you
edit
signal
in
hotel,
so
that
that's
my
point
like
I
literally
talked
about
making
the
t
uppercase
to
yeah.
D
Yeah
so
I
removed
the
green
so
that
way
we
don't
even
have
consensus
on
it,
but
I
won't
touch
again
sorry
about
that.
So
I
put
a
paragraph
here
at
the
top
that
people
should
read
real
quick
to
see.
If
there's
any
disagreements
with
that,
and
then
we
can
talk
about
three.
M
M
The
one
point
as
I
usually
fall,
but
this
is
without
my
head,
as
most
of
you
will
know,
I
usually
focus
on
the
wire
forwards
first,
because
this
allows
you
to
to
freely
interchange,
back-ends
and
libraries.
I
think
they're
the
underlying
thing
of
everything
else,
but
I'm
also
fine
with
this
order.
The
other
hat
back
on.
D
Yeah
and
from
a
from
a
stability
perspective,
that's
how
hotel
kind
of
treats
it
too.
So
the
specification
has
to
reach
stability
first
before
the
actual
implementation.
Can.
The
specification
is
where,
like
that,
data
model
and
wire
formats
live,
so
we
follow
the
same
model.
It's
just.
We
kind
of
bucketed
the
whole
thing
underneath
the
signal,
which
makes
it
a
little
bit
confusing
here,
but
okay
in
the
in
the
interest
of
time.
Let's
try
this
so
basically,
given
that
there
are
components,
and
there
are
signals
that
the
components
are
being
used
for.
D
M
Rest!
Okay,
so,
as
this
is
a
slightly
changed
line,
sick
observability
has
consensus
that
there
is
white
and
organic
adoption
of
the
tracing
signal
in
open,
telemetry
all
agreed.
Anyone
disagreeing.
M
K
D
This
one
might
need
clarification
right
because
the
specification
is
not
stable
as
alumitu
is
pointing
out.
There
are
people
using
metrics
in
production
today,
though,
so
I'm
not
sure
how
to
draw
that
distinction.
I
don't
know
bartok.
If
you
have
some
suggestions
on
like
maybe
explicitly
saying
the
specification
is
not
stable,
but
there
are
production
users
of
metrics.
I
don't
know
how
you
want
to
rephrase
it.
N
K
D
That's
demonstration
yeah,
that's
interesting.
I
think
it's
worth
a
conversation
about
that.
What
if
we
do
just
have
line,
what
right
now
lines
one
and
line
three
do
we
have
to
say
anything
about
metrics
and
logs?
K
M
I
mean
with
all
my
hats
on
at
the
same
time,
metrics
logs
and
traces
unification
in
a
single
set
of
of
unified
client
libraries,
collectors
and
a
holistic
design
is,
is
the
core
goal
of
open
telemetry.
As
far
as
I
understand
it.
As
such,
it
should
at
least
be
looked
at.
I'm
completely
fine,
just
saying:
well,
it's
future
work
and
be
done
with
it,
but
I
think
it
should
be
mentioned.
M
M
M
Okay,
so
let's
try
again
thick
observability
has
consensus
that
there
is
some
adoption
of
the
metric
signal.
Open
telemetry,
but
stability
and
compatibility
with
openmetrics
and
prometheus
are
work
in
progress
and
take
note
and
sick
observability
takes
note
of
prometheus
working
group
within
open
telemetry.
E
But
bartek,
as
we
said
in
the
last
meeting,
we
actually
show
that
there's
a
log
sig
right.
We
talked
about
this
in
the
last
meeting.
There
is
a
log.
Stick,
that's
actually
being
worked
on
right,
and
so
I'm
I'm
kind
of
missing
the
point
that
if
we've
shown
that
there
is
active
work
on
it,
how
is
that
being
viewed
as
being
denied
if
there's
actually.
G
G
N
N
A
very
active
amount
of
work
happening.
I
can
send
you,
you
know
specific
projects
that
we
have
done
as
well.
As
you
know,
the
log
model
log
data
model
as
well
as
the
stanza.
You
know,
component
being
integrated
into
the
collector
right
now.
E
M
People's
calendars,
I
I
would
like
to
avoid
he
said
she
said
situations.
M
How
about
alolita,
takes
an
action
item
on
on
putting
some
quantitative
data
on
this
as
far
as
okay,
perfect,
and
we
will
try
and
actually
finish
this,
the
next
time.
K
K
I
mean
I
would
I
would
love
to
know
that,
because
I
heard
you
know
the
other
open,
I
mean
yeah.
This
is
like.
E
K
And
that's
fair
that
you
know
open
telemetry
talks
were
agreed
and
like
kind
of
approved
more
on
the
normal
track,
because
they
are
not
part
of
the
maintenance
track.
There
are
so
many
rejections
because
thanos
and
prometheus
and
jager
and
others
are
already
on
maintainers
track.
Let's
be
fair.
That.
E
Actually,
isn't
the
actual
process,
I'm
glad
to
walk
you
through
the
process,
as
kubecon
co-chair,
who
walks
through
choosing
the
talks,
but
what
we
do
is
we
actually
from
the
observability
there's
a
program
committee
that
gives
us
a
top
10
to
15
talks
and
we
go
through
right
based
on
their
rating
and
then
after
choose
those
things
there.
K
Yeah
yeah,
I
understand
I
just
want
to.
I
think
that
would
be
fair,
that
you
know
to
give
open
telemetry
voice
because
of
there
is
no
maintainers.
So.
E
M
E
M
N
So
richard
would
it
be
helpful
to
highlight
you
know
what
we
are,
what
opportunities
we
are
missing.
Also
very
quantitatively.
You
know
in
terms
of
the
project
opportunities
which
are
really
important
for
the
project,
and
you
know
help
in
in
the
work
that
is
being
done
on
the
project
to
make
progress.
N
M
On
the
on
the
level
of
of
extra
pr-
yes,
no,
I
don't
think
that
matters
on
the
level
of
the
due
diligence.
That
being
said,
I
I
do
note
that
we
take
quite
some
time
to
to
discuss
this
so
completely
orthogonal
from
the
former
point.
I
do
think
it
would
make
sense
to
to
try
and
speed
things
up
and
if
interjecting
a
meeting
helps
with
that
effort.
That
seems
to
make
sense.
M
So
the
same
time
slot
next
week
is
open.
Telemetry,
metrics
data
model
sick,
that's
the
only
clash
which
I
can
see
offhand,
but
it's
not
my
call
to
make.
It
should
be
off
the
call
here.
So
can
we
do
a
show
of
hands
for
saying
yes,
no
on
we
lost
like
half
of
the
people.
K
M
So
everyone
who's
in
favor
of
having
this
this
call
next
week
as
an
interjection.
Please
raise
your
hand.
M
Okay,
so
like
for,
for
the
recording,
two
thirds
are
in
favor.
No
one
is
against.
Does
anyone
want
to
abstain?
M
Perfect,
so?
No
explanations,
so
I'll
talk
to
amy
to
to
put
an
intermediate
thing
into
the
calendar,
but
bartek's
point
is
also
valid.
We
should
try
and
and
as
always,
move
more
out
of
the
calls
and
into
into
the
mailing
list
into
the
document,
blah
blah
blah
blah
blah.
I
would
much
prefer
to
just
go
through
comments
and
such
and
just
close
stuff,
which
has
been
discussed
during
the
week
and
consensus
has
been
reached.
Then
then
discussing
everything
in
depth,
every
every
single
call.