►
From YouTube: CNCF SIG Observability 2021-02-16
Description
CNCF SIG Observability 2021-02-16
A
D
D
D
F
Yep
go,
hopefully
folks
can
see
it.
So
I
left
all
the
comments,
so
we
can
all
review
them
live,
but
try
to
comment
to
everything.
So
hopefully
there
are
updates
to
any
outstanding
items.
I
know
many
of
you
reviewed
it
over
the
last
two
weeks.
So
thank
you
for
taking
the
time
to
add
some
amount
of
assessment,
so
we
can
continue
kind
of
going
section
by
section
seeing
if
the
updates
are
kind
of
covered
or
if
more
additional
information
is
required.
F
So
I'll
skip
the
sections
that
are
green
because
I'm,
assuming
that
we
are
happy
with
that
section,
we
can
always
revisit.
If
someone
has
concerns,
please
raise
them
so
back
to
number
three:
does
the
project
have
production
quality
high
demand,
high
velocity
quality
type
stuff?
There
was
a
link
to
the
adopters
page
and
there
was
an
ask
to
actually
update
this
with
what
has
been
adopted.
F
G
G
D
Okay,
the
one
thing
which
I'm
pretty
certain,
so
I
I'm
just,
I
think
we
also
talked
about
which
components
you
call
them
components,
so
is
this
then
valid
for
metrics,
logs
and
traces
for
all
for
all
of
them
or
is
the
or
do
I
assume
correctly
that
those
are
the
traces
part
I'm
not
going
into
that
battle
on
on
the
document.
Just
asking
for
the
overview
so
are
all
of
those
and
tracing,
or
do
others
also
use
metrics
and
or
logs.
F
F
I
actually
recently
put
in
a
whole
bunch
of
documentation
updates
to
kind
of
cover
this,
so
you
can
see
the
different
components
that
make
up
the
project
with
instrumentation
libraries,
of
course,
being
language
specific.
The
specification,
proto
everything's
kind
of
built
on
top
of
but
data
sources
kind
of
represents.
Another
nuanced
thing
here
in
that
traces,
metrics
and
logs
are
in
scope
for
open
telemetry,
and
each
of
these
different
components
may
support
some
amount
of
any
one
of
these
data
sources.
F
So
I
did
not
explicitly
list
the
data
sources
in
this
table
to
answer
your
question
directly,
richie
from
a
client
library
perspective.
All
of
these
are
tracing
specific,
but
in
the
case
of
the
collector
it
is
likely
both
traces
and
metrics,
because
many
people
pass
metrics
through
the
collector
today.
D
D
F
D
D
A
So
I
think,
in
terms
of
showing
this
to
other
people,
it
makes
a
lot
of
sense
right,
like
as
a
potential
user,
it's
nice
to
see,
we
may
struggle
a
bit
to
get
users
to
actually
bother
to
insert
their
names
here
and
provide
that
level
of
detail.
But
you
know
as
an
end
user.
It's
always
nice
to
see
that
stuff.
F
Yeah,
we
also
try
to
call
this
out
per
language,
so,
like
java
choices
are
in
beta.
Actually
it's
rc.
Now
this
needs
to
be
updated.
Metrics
are
alpha,
logs
are
experimental,
so
you
can
see
it
per
data
source
within
each
of
these
sigs
as
well.
We
don't
explicitly
call
that
on
the
adopters
page,
but
each
of
these
repositories
lists
the
state
of
the
different
data
sources.
D
A
D
So,
just
to
be
clear
also
from
from
the
initial
ask
from
from
the
toc
which
is
put
into
that
into
that
checklist.
I
don't
think
we
need
an
exhaustive
list
like
absolutely
not.
It
would
be
unfair
to
ask
this
of
any
project,
it's
much
more
about
just
showing
that
there
is
adoption
and
that's
it
as
there
are
so
many
orthogonal
aspects
of
of
what
observability
means
which
are
handled
within
open
telemetry.
F
And
I
think
that's
kind
of
an
interesting
topic,
so
I
mean
I
might
be
mistaken.
I
don't
want
to
speak
on
behalf
of
cncf,
but
the
project
is
open
symmetry.
It
can
be
made
up
of
various
different
components
and
those
components
can
be
in
different
statuses,
but
the
project
is
up
for
incubation,
not
the
tracing
part,
and
I
I
kind
of
look
at
this
similar
to
kubernetes,
which
is
another
very
large
project
within
cncf.
F
There
are
plenty
of
things
in
kubernetes
that
are
in
alpha,
but
the
kubernetes
project
is
graduated,
so
I
don't
think
it
really
matters
that
just
the
tracing
data
source
is
more
ga-ready
than
the
other
data
sources,
and
I
wouldn't
want
to
sub-divide
by
that
just
the
data
source,
because
it's
the
project
as
a
whole.
That's
going
for
incubation,
not
the
traces
part
of
it.
J
You
know,
excited
to
adopt
things
because
they
think
things
aren't
stable,
but
I
think
our
adopters
list
actually
shows
that
that
isn't
an
issue
with
us
as
a
whole
project
and
yeah
until
excuse
point
where,
like
large
projects,
there's
always
gonna
be
some
sections
of
it
that
just
aren't
stable
right.
You
can
even
make
that
argument
with,
like
envoy,
like
envoy,
has
a
core
set
of
filters
that
are
fully
supported,
and
then
they
have
things
there
that
are
always
gonna,
be
experimental
or
other
things
like
that.
D
D
Looking
at
subprojects,
I,
with
my
chair
head
on,
I
deliberately
do
not
hold
a
strong
opinion
here
for
the
very
simple
reason
that
I
can
see
very
good
arguments
in
both
directions,
but
I
don't
think
it's
it's
fair
of
of
of
a
mere
seek
to
to
simply
say
yes
or
no
to
to
actually
interpreting
policy.
This
heavily
again,
I
can
see
very
good
arguments
in
both
directions.
I
I
agree
with
steve's
point
on
it
being
unconscious.
D
I
think,
on
this
being
better
to
move
as
a
project,
because
it
just
shows
the
overall
velocity
of
the
project.
I
can.
I
can
also
see
bartek's
point
about
this
being
potentially
confusing
when,
when
it's
this
difference
in
in
in
readiness
or
in
in
actually
being
used.
But
again,
I
don't
think
we
within
the
sikh
should
make
a
hard
decision
either
way
unless
someone
strongly
disagrees
or
even
slightly
disagrees.
K
H
K
A
recommendation
and
if
people
feel
strongly,
then
we
can
point
out
yeah
there
are.
You
know
there
are
concerns
around
that
or
whatever,
which
is
part
part
of
our
due
diligence,
review
and
and
again
think
of
of
in
case
of
kubernetes.
No
one
ever
said
greatest
can't
graduate,
because
you
know
csi
is
not
there
yet,
and
and
if
it's
in
the
case
for
communities
which
is,
you
know,
arguably
a
little
bit
wider
than
open
telemetry,
then
I
think
the
same
applies
for
open
telemetry.
K
It
is
the
project
that
may
or
may
not
have
certain
parts
that
are
on
a
certain
level
as
long
as
you're
explicit
about
that,
it's
clearly
saying:
look
traces,
ga
whatever
you
want
to
call
it
production
ready,
whatever
you
want
to
call
it
logging.
This
is
experimental.
This
is
something
you
might
want
to
try
out,
but
it's
not
something
that
we
consider
yet
ready
for
production.
D
D
H
H
K
Hang
on
hang
on.
Why
would
we
request
advice,
advice
for
what
we
we
can?
We
can
point
out
something,
but
we
otherwise
it's
like
they
ask
us,
you
know,
can
you
do
the
due
diligence?
We
say
oh
yeah
sure,
but
you
know,
give
us
advice
and
then
what
then
does
that
mean
another
round
we
meet
again
and
talk
about
that?
I,
I
would
not
say
request
advice.
D
Not
trying
to
to
keep
it
in
just
first
reply
to
your
question:
sick
observability
is
special
in
as
much
as
toc
told
us.
We
should
be
doing
or
we
could
be
doing
more
due
diligence
than
other
six,
because
the
others
are
not
as
clearly
scoped,
and
so
we
basically
said
offered
to
do
more,
and
they
said
yes,
so
that
is
why
we
do
more
on
the
due
diligence
than
other
six.
D
K
D
Like
this,
the
second
we
have
consensus
here
or
much
more
to
the
point
right
after
this
meeting.
I
would
be
poking
poc
about
this,
so
they
know
about
it
as
soon
as
possible
and
then
can
act
on
it.
This
shouldn't
be
but
again,
unless
someone
feels
strongly,
we
just
have
as
a
call
for
consensus
and,
let's
just
do
this
sick
observability
requests
a
decision
from
cncftoc
on
project
versus
subproject
comments.
Anyone
against
all
agreed
perfect.
J
F
All
right
next,
one
we're
moving
on
to
four
yep.
Is
the
project
committed
to
achieving
cncf
principles?
They
have
committed
roadmap
and
address
any
concerns,
so
add
a
link
to
roadmap
information.
So
I've
added
several
kind
of
roadmaps
here,
as
well
as,
like
a
project
board.
That
kind
of
articulates
this
as
well
again.
Remember
that
open
symmetry
is
comprised
of
many
different
components,
so
roadmaps
are
typically
done
by
those
various
components
from
a
high-level
project
perspective.
F
F
Of
course,
that
is
working
with
prometheus
openmetrics
teams
to
ensure
that
we
address
the
current
outstanding
issues.
There's
a
working
group
for
that
to
figure
out
those
details.
Logging
is
then
planned
for
next
year.
Arguably,
it's
already
started,
but
from
a
ga
perspective
that
won't
be
until
2022.
At
this
point.
C
Right,
so
this
this
topic
is
like
very
fuzzy
again,
because
what
does
that
mean?
What
does
it
mean
addressing
concern
right
at
what
point
the
concert
is
addressed,
so
this
brings
essentially
I
mean
we
can
simplify
this
by.
You
know
the
points
raised
by
the
community
and
concerns
raised
by
the
community.
I
don't
know
this
is
what
I
gather
from
and
shared
on
the
friday.
So
are
we?
F
Yeah
so
I
mean
the
way
I
would
frame.
This
is
open,
symmetry
is
completely
open
source
and
anyone
can
come
contribute.
So,
like
the
document
you
put
together
is
great,
I
think
you've
already
seen
multiple
people
from
the
open,
symmetry
community
and
outside
comment
on
it,
and
then
we
should
figure
out
like
how
to
get
this
incorporated
into
the
roadmaps.
But
how
everything
is
tracked
today
is
like
any
other
github
project.
We
have
issues,
we
have
release
milestones.
F
We
have
project
boards
and
now
we
have
github
discussions,
we're
actually
getting
off
of
gitter,
which
is
super
exciting,
so
I'd
say
that
make
sure
anything
that
you
need
or
want
captured
is
captured
in
issues
or
discussions,
and
then
they
absolutely
will
be
addressed.
The
same
applies
to
the
sigs
and
the
working
groups
so
take
prometheus
and
open
metrics,
for
example.
The
whole
point
of
the
working
group
is
to
solve
the
current
issues
between
the
compatibility
between
otlp
and
the
openmetrics
wired
format.
C
F
J
Point
yeah
also,
when
is
it
necessarily
like?
I
think
this
is
kind
of
common
for
all
projects
like
open
source
projects.
One
is
always
the
like
nebulous
like
will
it
ever
happen
because
we
all
are
relying
on
you
know
like
people
working
from
different
companies
to
contribute
right.
I
think
the
most
important
thing
here
to
notice
is
that,
like
we
are
tracking
this
information
and
that
you
know
also
like
that
one's
a
good
thing
to
notice,
but
also
all
the
things
that
we've
committed
to
in
the
past.
F
Yeah,
I
guess
I
I
would
ask
anyone
on
the
call
really
does
anyone
have
examples
or
concerns
that,
like
open
symmetry
is
not
taking
this
feedback,
not
incorporating
it
into
into
like
a
working
group
or
a
roadmap
or
some
sort
of
item?
Because
if
that's
the
case,
then
I
would
argue,
number
four
is
not
being
met.
F
C
Okay,
so
I
will
bring
it
up
first,
one
logging,
api
right,
I
have
I
mean,
and
also
I'm
like
you
know,
observer
of
all
these
things,
so
I
I
already
work
multiple
multiple
times
wrong.
So
what
I'm
seeing,
but
what
I'm
seeing
right
now
is
that
the
logging
is
some
important
goal
and
scope
of
this
open
telemetry
project,
but
plenty
of
people,
especially
from
the
at
least
what
I
spoke
from
the
fluentd
community,
were
like
actively
rejected
to
in
in
terms
of
contribution
or
starting
even
discussing
about
the
logging.
C
A
So
so
a
couple
things
like
we
were
talking
about
how
we
stick
to
our
road
map
like
tracing
and
then
metrics
has
always
been.
The
roadmap.
Login
came
up
because
a
few
members
wanted
it
and
you're
right.
There's
some
work
has
happened
on
it.
It's
still
experimental
and
I've
been
involved
in
that
and
t
grant
and
jonah
and
others
have
been,
but
that's
us
sticking
to
the
road
map
by
not
not
making
logging
front
and
center
not
wanting
to
push
out
the
things
that
we've
already
committed
to.
A
Secondly,
I'm
not
aware
of
people
who've
been
rejected
for
making
contributions
like
I've
attended,
almost
level
logging
meetings.
I
find
that
surprising
that
people
were
saying
that
their
contributions
were
rejected.
Sometimes
people
had
reached
out
and
said:
hey
is
this
ready
for
prime
time?
And
we
said
no,
absolutely
not
you
know.
Tracing
is
still
our
number
one
priority.
Metrics
is
the
number
two
priority
will
become
the
number
one
priority
after
tracing
is
done,
but
at
no
point
have
I
ever
seen
anyone
be
discouraged
from
participating
other
than
just
warning
them.
F
Yeah,
so
I
think
for
logging,
specifically
there's
a
sig
dedicated
to
this.
With
with
meetings,
I
was
just
pulling
up
the
meeting
notes
real
quick.
I
mean
there's
representatives
from
elastic
fluent
bit:
google
walmart
aws
sumo
splunk,
so
I
think
that
people
are
definitely
getting
together
and
things
are
being
discussed
if
there's
a
fear
that,
like
something's
not
being
accepted
or
like
advice,
is
not
being
taken,
then
we
should
clearly
go
address
that
but
like
this
would
be
the
forum
to
kind
of
raise
those
concerns,
and
definitely
anyone
is
welcome
to
attend.
F
K
C
I
think
the
rejection
might
be
you
know
to
brutal
world
and
I
agree
sorry
for
I'm
not
like
you
know
native
speaker,
but
what
I
rather
meant
is
that
the
thing
I
heard
a
couple
of
times
is
that
open,
telemetry
said
that
you
know
let
we
don't
want
to
focus
on
logging
right
now.
We
want
to
focus
on
metric
and
tracing
so
yeah.
We
are
not
talking
about
that
right
now.
F
J
K
Me,
let
me
understand:
is
it
about
that?
The
scope
of
open
telemetry
is
not
clear
enough
for
you
in
terms
of
is,
is
like.
Is
the
community
behind
it
open
to
to
get
logging
in
there
or
not,
or
is
it
that
actually,
someone
tried
to
get
logging
in
there
and
the
open
telemetry
committee
said
no,
we
don't
want
logging
in
there,
which
one
so.
G
Obviously
tracing
was
the
big
rock
right
and
that's
the
focus
and
we're
finally
getting
to
the
point
where
you
know
we
can
now
have
people
use
it
in
production.
That's
awesome,
metrics
is
next,
but
we
have
a
vibrant
and
strong
community
in
metrics
around
prometheus
and
openmetrics.
That's
part
of
cncf,
that's
one
discussion
point
and
then
secondarily,
logging
standards
are
really
really
difficult
and
there
are
some.
G
You
know
well
established
open
source
standards
for
this
like
ecs,
which
is
an
apache
open
source
framework
for
logging
that,
instead
of
like
embracing
and
extending
things
that
already
exist,
we
seem
to
want
to
reinvent
the
wheel
when
it's
already
invented
and
it's
functional,
and
so
I
think
that's
the
frustration
that
bartek
is
talking
about.
I
feel
the
same
way
I
stopped
going
to
the
logging
meetings
because
it's
just
way
over
engineered,
I
mean
like
the
spec
for
logging-
is
the
most
over
engineered
specification.
I've
seen
for
logging.
That's
ever
been
done
by
anyone.
J
J
J
J
Open,
metrics
barely
got
any
attention
over
the
past
few
years,
right
like
and
so
in
terms
of
velocity
in
terms
of
people
talking
about
it
right,
there
are
like
you
know,
you
can
make
the
argument
that
open
metrics
wasn't
quite
as
visible
compared
to
say
open
telemetry
over
the
past
few
years.
Wonderful
thing,
too,
is
it's
cncf,
where,
like
cncf,
has
competing
projects,
linker
d
and
envoy
are
great
examples
right,
and
the
thing
is,
is
that
it's
not
meant
to
say
this
is
the
only
way
to
do
it.
J
Cncf
is
trying
to
host
set
of
projects
to
give
people
different
tools
to
do
whatever
they
want
in
a
way
that
they
want
to
do
it,
so
people
might
want
to
use
open
metrics
over
over
open
telemetry.
That
is
great.
Also.
One
thing,
too,
is
that,
like
open,
telemetry
isn't
necessarily
only
about
forcing
people
to
use
open,
telemetry
like
if
you
look
at
a
lot
of
the
implementations
like
if
you
look
at
the
languages
and
also
the
collector,
it
also
gives
people
a
lot
of
tools,
so
they
could
say
like
hey.
J
F
Yeah,
I
guess
the
one
thing
I'd
add
is
just
like
there
isn't
one
standard
in
the
market
today,
so
that's
part
of
the
problem
that
open
symmetry
is
trying
to
solve,
for,
like
I
don't
know,
use
anything
jaeger
and
zipkin
two
competing
projects
both
do
tracing
b3,
header,
propagation
versus
w3,
trace
contacts
both
exist
in
the
wild,
so
open
symmetry
needs
to
provide
a
mechanism
so
that
people
have
a
path
forward.
For
that.
F
The
same
applies
for
metrics
like
openmetrics
is
not
the
only
metrics
thing
out
there
yeah,
it
might
be
the
cloud
native
one,
but
people
are
not
all
fully
on
that
today,
and
so
they
might
even
be
in
a
hybrid
world
where
they
need
to
support
like
two
standards.
At
the
same
time,
how
do
you
do
that?
The
answer
is
often
like
you
have
to
deploy
two
different
stacks
and
find
a
way
to
go.
Integrate
them
like
open
symmetry
is
trying
to
make
that
easier.
So
I
mean
the
final
comment.
F
G
Yeah
I
just
find
that
we're
creating
a
lot
of
like
additional
complexity
without
a
lot
of
benefit.
There's
no
clear
explanation
why
we
have
a
new
metric
standard
in
open,
telemetry
versus
using
something
that's
used
by
hundreds
of
thousands
of
companies
in
production
today?
Why
do
we
need
a
new
metric
standard?
I
understand
why
we
need
one
for
tracing
logging.
I
don't
know
that
we
need
another
standard.
It's
not
clear.
What's
missing
what
needs
to
be
changed
enhanced!
G
And
and
constance,
getting
back
to
your
other
comment,
these
are
not
like
projects
where
someone
can
go
and
implement
it
like
open.
Metrics
is
basically
a
a
standard,
a
specification,
so
this
isn't
something
that
a
user
can
just
go
and
implement.
They
obviously
need
to
adopt
a
technology
that
implements
open,
telemetry
or
implements.
You
know
open
metrics,
for
example,
but
it's
fine.
Obviously
people
don't
want
to
discuss
this.
I
think
it's
a
big
issue
and
it
overshadows
the
whole
project
at
this
point
beyond
tracing.
A
G
C
F
F
If
there
are
issues
there
are
forums
to
actually
discuss
them
and
like
any
issues
raised
or
like
there's
a
sig
meeting,
there's
a
working
group
there's
I
mean
there
are
forums
to
address
that
feedback,
getting
consensus
from
everyone
in
on
the
planet.
Right,
like
I,
don't
think,
that's
a
goal
but
like
taking
that
feedback
and
trying
to
incorporate
it
and
ensure
that,
like
everyone,
has
a
say
and
decisions
are
going
to
be
made
on
that,
I
think
does
exist,
which
is
what
number
four
is
asking
for.
C
F
I
don't,
I
don't
think,
there's
anything
hiding
it's
all
happening
in
open
source
forums
today
like
if
there
are
concerns
about
logging.
There's
a
logging
sig
to
discuss
that
and
logging
is
not
ga.
So
it's
not
like
that
feedback's
not
being
taken
if
we
were
having
a
conversation
about
logs
gaining
and
there's
big
concerns
about
introducing
another
standard.
I
think
that
would
change
the
conversation
here.
Quite
a
bit.
C
J
F
F
D
Yeah,
one
suggestion
which
I've
been
trying
wanting
to
make
is
a
set
of
specific
statements,
which
can
be
added
as
part
of
the
reply
to
number
four
to
to
make
your
concerns
visible
and
ideally
address
stability.
So,
for
example,
by
making
explicit
that
as
of
right
now,
logging
was
next
year
and
is
not
a
priority
just
making
this
super
explicit
and
writing
this
down,
putting
not
a
timeline
down
to
the
second
to
to
the
metrics
effort,
but
at
least
having
a
a
timeline
on
this.
C
Think
no
I'm
open
for
propositions,
but
you
know
I
feel
like
we
are
putting
this
no
kinks
making
rule
you
know
forward
as
a
rule.
That
is
that's
happening
sure.
I
agree.
The
same
happened
with
cortex
and
tunnels.
Both
are
competing
right,
but
both
were
accepted
to
incubation,
but
this
is
much
different
situation
where
we
have
open
telemetry
with
well-defined,
solid
tracing
and
not
defined
logging
and
barely
defined
metrics.
In
my
opinion,
sorry
for
being
brutal
but
and
somehow
we
know
they
are
overlapping
with
existing
well-adopted,
well-defined
solutions.
D
D
A
little
bit
so
maybe
to
to
address
the
open,
metrics
thing
course
there's
back
and
forth,
and
I'm
uniquely
positioned
to
speak
about
that
one
and
about
how
how
the
utilities
are
supposed
to
work
with
my
open,
metrics
and
prometheus
heads
on.
Obviously,
I
would
prefer,
if
other
projects
adapted
that
standard
flat
out
period.
That's
obvious.
D
The
one
thing
which
which
I've
seen
raised
in
the
past
and
something
which
is
one
of
my
main
concerns,
is
confusion
around
the
actual
level
of
support
of
open
telemetry
for
commercially
slash
open
metrics,
because
most
people
just
assume
it's
fully
there
and
it's
just
not,
which
is
fine.
It's
absolutely
fine
to
not
be
there
or
to
be
there
after
x
amount
of
time.
As
long
as
the
messaging
is
clear,
so
I
would
much
rather
try
and
focus
on
putting
a
timeline
in
on.
D
We
will
take
x
amount
of
time
to
achieve
compatibility,
and,
yes
with
my
prometheus
and
openmetrics
head
on,
I
know
that
we
need
to
define
even
more
on
what
compatibility
actually
means
like
on
top
of
the
test
suite
and
everything
which
we
have.
There
is
plenty
of
reference
code
which
data
have
used
and
such
yet
it's
clearly
not
enough,
so
we
need
to
deliver
more
sick
head
on
again,
and
this
is
I'm
being
very
deliberate
in
those
different
trains
of
thought
sick
head
on.
C
D
D
D
D
C
C
Actually,
you
know
results,
because
we
have
clear,
clear
points
that
were
listed
up,
which
are,
I
mean,
there's
no
even
clear
idea
how
to
solve
them,
and-
and
even
some
some
of
them
are
trivial,
like
this
label
ge
or
le
on
the
histograms,
push
versus
pull
and
kind
of
how
to
integrate
all
of
this,
and
by
just
saying,
hey,
we
will
yeah,
it
will
be
compatible.
Yes,
everything
will
be
fine.
C
This
is
this
is
great,
but
if
I
assess
technically
I'm
up
to
recommend
something
and
or
recommend
anyone
in
red
hat
to
use
open
telemetry.
If-
and
I
I
don't
see-
because
I
know
the
technical
details
of
it-
that
the
agreement
is
not
possible
easily,
and
there
is
also
some
kind
of
you
know-
other
concerns.
Whatever
discussions,
how
can
I
recommend?
How
do
I
see
this
as
a
result?
K
K
We
are
also
there
right,
but
you
know
at
some
point
in
time:
hotel
wants
to
graduate
right
wants
to
be
a
you
know
like
kubernetes
and
promoters,
and
others
wants
to
be
that
kind
of
project
and
obviously
people
including
ourselves,
will
be
held
accountable
if
we
say
well,
you
know
this
is
what
we
committed
to
or
agreed
upon
in
the
context
of
gradation
to
incubation,
and
we
haven't
done
that
right.
But
to
me
this
is
not
the
end
of
the
road.
This
is
clearly
one
stepping
stone
towards
that.
K
K
C
Yeah,
I
think
no,
no,
I,
I
kind
of
you
know
think
about
this
process
as
some
step
towards
graduation.
So
if
I
see
kind
of
this
some
concern
already,
I
just
want
it.
I
want
to
point
it
out.
Definitely
like
this
can
be.
You
know
kind
of
fine
for
incubation,
but
the
goal
is
really
ultimate
goal
is
like
full
adoption
and
graduation.
So
can
we
point
this
down
to
to
the
to
the
dock?
F
Why
are
we
talking
about
graduation,
though
right,
like
the
goal,
is
incubation
and
like?
Can
these
concerns
be
addressed
or
are?
Is
it
a
flat
out
no
like
there's
a
road
map
and
that
road
map
could
be
years
but
there's
a
roadmap,
and
so
I
think
you're
right
that
if
we
were
in
incubation
talking
about
graduation,
then
it's
a
whole
new
conversation,
but
we're
not
we're
talking
about
moving
from
sandbox
to
incubation.
I
think
this
is
a
known
issue.
I
think
there's
a
working
group
to
address
it.
K
Right
and
that's
exactly
what
I
what
I
I
mean
I
tried
to
address
bartex,
if
I
understand
correctly
worry
that
oh
yeah,
you
know
we
put
that
down
here
and
then
nothing
ever
happens,
and
I'm
saying
well.
This
is
not.
This
is
quote
unquote
just
incubation.
This
is
not
yet
graduation,
so
obviously
there
would
be
another
due
diligence
held.
You
know
towards
graduation
and
you
know
clearly
that
will
come
up
again
right.
So
to
me
this
is
an
argument.
Let's
move
on,
let's
you
know.
We
clearly
pointed
that
out
here.
J
J
D
The
first
is:
is
full
prometheus
and
open
matrix,
countability
part
of
1.0
and
ga
yes
or
no,
and
that's
I
don't
I
explicitly
don't
have
opinion
it
just
should
be
noted
and
then
based
on
everything
which
was
added
if
we
can
achieve
consensus
or
if
anyone
wants
to
be
on
the
record
and
not
as
not
a
queen.
Those
are
the
two
questions
which
seem
to
be
relevant
for
for
the
discussion
and
moving
on
yeah.
A
But
we
can
speak
on
that
one
bargaining
week
I
mean
we
can
answer
that
right
now,
since
the
first
day
of
the
project,
since
open
telemetry
was
founded
being
able
to
import
prometheus
metrics
to
pull
those
in
from
prometheus
clients
and
also
export
any
metrics
captured
to
a
prometheus
server.
Those
have
always
been
explicit
requirements
for
metrics
and
open
telemetry
like
we
would
not
ship
without
doing
that.
D
Okay,
that's
a
clear
answer
to
to
address
the
one
point
of
doctrine:
it's
not
the
case
that
it
doesn't
exist
because
a
we
have
the
reference
implementation
which
is
being
rendered
by
several
other
projects,
and
we
have
even
competing
companies
who
do
not
interact
with
with
the
promises
community
at
all,
just
implement
prometheus
and
implement
open
metrics
just
from
what
they
found
on
github
and
in
the
spec.
So
it
it's
there,
but
I
do
agree
that
it
that
make
it
more
visible
and
giving
specific
pointers
adhere.
D
D
Sorry,
if
you,
the
one,
is
if
you
ingest
data,
it
should
come
out
the
same,
and
the
other
is
if
you
emit
data,
both
your
implementation
and
prometheus
should
ingest
the
same
thing.
So
those
are
the
two
definitions
in
the
in
the
functional
sense,
which
is
obviously
not
the
do
to
the
comma
version
of
of
a
spec,
but
on
the
function
level.
That
is
the
intention
of
prometheus
compatibility,
and
I
think
we
have
maintained
that
for
like.
L
L
L
I
do
understand,
but
there
are
some
other
scenarios
and
other
things
that
we
may
not
fully
support
and
that's
why
that's
why
I
I
think,
in
order
for
us
to
make
a
stamp
and
say
we
are
fully
100
compatible
with
prometheus,
it's
probably
hard
to
have,
but
limiting
this
code,
but
we
accept
prometheus
data
and
emit
prometheus
data
in
specific
format
and
so
on.
It's
it's
way
more
reasonable.
But
anyway,
I
don't
want
to
touch
it
right
now,
but.
D
Sorry,
just
to
close
this
ventilator
now
I
explicitly
don't
wear
the
sick
observability
head,
but
the
prometheus
and
openmetric
set
on
the
functional
level.
It's
clear,
because
both
stillness
handling
and
up
metric
are
core
design
principles
of
how
prometheus
functions
and
basically
all
users
heavily
rely
on
those
properties
and
that
hasn't
changed
again
since
since
google
done
in
2017
that
that
has
been
consistently
be
the
same
reply.
I
know
we
keep
revisiting
this
topic,
but
the
reply
hasn't
changed
to
to
be
fully
compatible
with
prometheus.
That
is
part
of
how
prometheus
operates.
D
If
you
want
to
have
the
discussion
about
just
the
data
format,
which
is
completely
fine-
and
that
is
different,
but
that
is
then
not
what
is
currently
written
here
and
how
I
understood
morgan.
So
I
don't
care
so
to
speak
about
the
actual
reply.
I
just
care
about
it
being
explicit
in
here.
I
think
so,
morgan
is,
it
will
include
full
or
is
it
just
the
the
data
format
or
the
wire
format?
Or
what
is
the
intention.
L
D
D
C
F
D
D
L
A
D
A
D
A
Think
we
should
call
it
out
as
a
goal.
I
don't
know
if
any
of
us
on
the
call
can
give
the
the
firm
answer
to
that
just
because
of
where
we
are
with
metrics
and
because
there's
only,
I
think,
three
or
four
of
us
I
I.
I
would
expect,
though,
that
we
would
target
that.
I
don't
know
if
I'm
speaking
out
of
turn
but.