►
From YouTube: CNCF SIG Observability 2020-11-24
Description
CNCF SIG Observability 2020-11-24
A
A
A
A
Toten,
this
meeting
was
being
a
little
weird.
I
have
to
join
via
browser
rather
than
the
app.
Oh,
that's
strange,
not
the
first
time
brian
you
just
do
that
and
richie
is
coming
as
well.
Yes,
it
should
be
at
least
he's
had
a
reminder
in
chat
like
a
minute
or
two
ago.
You
might
be
running
into
this
certain
issue.
Yeah.
I
need
to
create
an
account
with
zoom.
A
A
Okay,
so
while
people
are
filing
in-
and
this
is
recorded
I'll
just
open
the
meeting
and
say
this-
is
a
our
sig
observability
meeting
right
before
thanksgiving
in
the
u.s
on
the
24th
here.
If
this
is
a
cncf
meeting,
the
cncf
rules
and
conduct
and
all
that
apply,
everybody
be
cool.
It's
never
been
an
issue,
but
we
always
should
say
it
if
you've
not
been
here
before.
Do
you
want
to
take
a
quick
second
and
and
do
an
intro?
A
A
A
All
right,
anyone
else,
okay,
so
I
put
the
the
meeting
notes
in
the
in
the
we've
got
a
pretty
full
agenda
already,
so
I
guess
partake.
Why
don't
we?
Why
don't
we
start
with
you
in
order
here
sure
it
is?
It
should
be
like
a
super
quick
thing.
So
essentially,
we
talked
about
kind
of
collaborating
better
with
other
well
with
many
cncf
seek
observability
related
kind
of
projects,
but
not
only
with
other
projects
as
well.
A
We
definitely
need
want
to
have
a
stronger,
stronger
connection
and
communication
between
those
we
already,
I
already
kind
of
spoke
with
a
couple
of
teams.
You
might
spoke
as
well
and
we
want.
We
had
this
idea
of
those
introduction
talks,
so
I
would
say:
let's
go
ahead
and
kind
of
craft
some
agenda,
and
I
know
for
a
next
talk
like
in
two
weeks.
We
will
have
kind
of
a
talk
from
captain
project
which
is
kind
of
impressive.
A
They
are
kind
of
collaborating
with
well
kind
of
working
on
on
improving
the
prometheus
scaling
of
configuration
problems.
So
that's
pretty
nice,
but
we
would
love
to
have
all
the
you
know,
kind
of
observability
related
projects
to
maybe
introduce
themselves
and
tell
us
about
you
know
maybe
near-time
actions
or
like
plans.
So
we
can
understand
better
and
maybe
hop
in
on
the
on
the
problems
that
you
know
to
not
reinvent
the
wheel
essentially
and
just
because
we
all
have
the
same
problems
as
a
and
challenges.
A
A
A
A
Is
no
worries
we're
just
talking
about
kind
of
the
idea
of
into
that
introducing
each
project
I
think
anyway,
it's
up
to.
I
guess
us
if
you
have
connect
strong
connection
to
the
any
observability
project,
please
go
to
them
or
like.
If
you
are
from
this
project,
please,
actually
I
should
probably
start
some
dock
where
we
can-
or
we
can
maybe
put
that
here
on
our
agenda
to
essentially
schedule
this
and
have
let's
say
10
15
minutes
of
talk.
A
Introduction
talk,
have
maybe
relevant
issues
as
well
that
you
are
facing
right
now
as
the
project
or
stuff
like
that
in
the
following
meetings.
I
think
you'll
be
amazing
to
to
maintain
this
table
here,
but
anyway,
this
is
for
your
awareness.
If
you
are
a
maintainer,
if
you
contribute
this
project,
please
let
let
them
know
so
we
can
have.
We
can
learn.
Essentially,
so
that's
it
from
us,
oh
sweet.
A
I
I
I
would
suggest
if
everyone,
if
this
makes
sense
to
everyone,
we
just
make
a
github
label
to
track
these
kinds
of
things,
and
we
can
use
github
issues
on
the
kanban
board
to
keep
track
of
all
these
different
projects
because
there's
a
whole
bunch
of
them
litmus.
We
talked
to
a
couple
weeks
ago,
they're
they're
planning
to
make
an
intro
as
well.
So
does
anyone
object
to
that?
A
That
being
said,
I
will
now
officially
recuse
myself
as
chair
of
the
sick
for
the
rest
of
this
meeting,
or
at
least
until
we
are
not
talking
about
openmetrics
again
yeah
down
on
the
agenda,
where
we're
going
to
do
a
review
today,
we'll
take
up
a
good
chunk
of
the
time
on
the
open,
metrics
due
diligence.
They've
applied
for
yeah.
Well,
we'll
get
to
it,
but
first
yeah.
But
first
we've
got
a
couple
things
before
that
to
kind
of
buzz
through
so
arthur.
A
A
I
I
don't
want
to
say
hand
only,
but
just,
but
we
are
most
familiar
with
what
we
are
feeling
comfortable
comfortable
for
writing
about
we're
just
speaking
one
sub
subject
and
writing
elaborating
and
yeah.
That's
what
how
we
are
doing
right
now
and
of
course,
we
are
open
to
anyone
who
wants
to
help
us
write
or
just
reveal
what
we
are
writing
and
the
link
I'll
just
post
on
the
chat.
I
don't
know
if
michael
or
simone
has
anything
to
add.
A
Yeah,
I
mean
just
for
the
others
that
joined
now.
What
we
did
was
basically
to
meet
outside
this
meeting
here,
just
to
agree
what
we
want
to
write
about.
We
have
an
idea
now,
but
we
I
at
least
started
offline
before
I
can
have
text
in
a
shared
document
that
is
worth
reading
yeah
and
we
basically
created
or
we
are.
We
have
a
task
in
the
board
so
to
say,
and
we
set
up
a
deadline
as
well
to
have
something
to
be
delivered.
A
So
we
have,
I
think,
was
beginning
of
january
right.
I
have
at
least
january
first
two
weeks
as
my
mentor
deadline
here.
Before
I
mean
this
is
like
the
final
submission,
but
before
that
we
have
to
iterate
yeah.
This
is
great.
I'm
sorry
I
couldn't
join
on
friday.
We
were
dealing
with
the
docker
apocalypse
fallout
and
I'm
sure
I'm
not
the
only
one.
Who
knows
what
that
means.
A
I
noticed
that
there's
two
issues:
are
we
using
16
and
19
on
the
board
for
that,
or
were
you
consolidating
to
one
of
them
yeah?
I
think
they.
There
are
different
things.
One
is
a
white
paper
and
another
is
an
index
page.
Oh
I'm
sorry!
Yes,
I
looked
at
this
wrong,
so
we
closed
rather
28
and
we're
going
to
be
using
16.
great
yeah.
A
A
A
A
A
A
Do
you
want
to
talk
about
the
prime
migrator
design
dock
first
briefly,
to
I'm
guessing
to
sort
of
introduce
it
and
and
and
then
set
the
stage
for
maybe
in
two
weeks
where
we
could
take
a
deeper
dive
through
it,
and
then
I
guess
we
could
I'm
concerned
that
we
we
might
not
get
to
yours
if
we
start
in
on
the
open
metric
stuff
before
the
end
of
the
hour,
I'll
I'll,
try
to
make
it
less
than
two
minutes
so
pretty
much.
We
started
the
project.
A
The
idea
is
really
simple:
to
allow
you
to
migrate
prometheus
data
between
the
various
prometheus
long-term
stores
and
it
just
uses
the
already
existing
remote
write
and
remote
read
apis
and
prometheus
and
there's
just
kind
of
a
a
pipe
between
reading
either
one
and
the
writing
to
another.
The
idea
here
is:
you
can
move
things
between
existing
self
and
prometheus
into
thanos
cortex
problem
scale.
What
have
you
or
the
other
way
around
or
or
between
any
of
the
long-term
sewers,
so
the
basic
design?
Dockers
up?
A
I
don't
think
we
need
to
go
through
it
in
this
group
necessarily,
I
just
wanted
to
put
it
on
people's
radar,
so
they
are
aware
that
this
team
that
this
tool
is
being
developed
and
maybe
if
people
have
expertise
in
remote
reading
the
remote
right
they
could
go
into
the
dark
and
and
put
their
thoughts
in
right.
So
for
that,
that's
cool
thanks
for
bringing
this
thanks
for
raising
it.
Here
I
I
did
have
a
quick
high-level
question.
A
This
is
primarily
I
aimed
it
looks
like
at
the
dock
at
historical
data
and
backfilling
versus
well,
so
we've
been
going
back
and
forth
about
that,
and
it
would
be
great
if
people
could
could
determine
as
it
is.
The
first
version
will
probably
be
for
backfilling,
but
we
are
wondering
if
we
wanted
to
do
an
online
version
of
this
as
well,
but
we
don't
know
because
prometheus
kind
of
has
already
an
online
thing
with
remote
right
so,
but
but
thoughts
about
this
are
definitely
welcome
yeah.
A
I
think
it
would
be
amazing
if
you
can
share
this
with,
like
pro
materials,
essentially
mailing
lists
or
or
at
least
hook
into
discussions
we
have
with
about
backfilling
and
our
storage
kind
of
ideas
behind
that
because
looks
like
we
are
solving
similar
kind
of
you
know
challenges
here,
but
maybe
you
know
whatever
you
learn
will
be
useful
for
future
backfilling
and
and
and
maybe
export
it
as
well.
So
it's
really
connected
a
little
bit
yeah
yeah!
A
A
Yeah,
there's,
there's
a
there's
another
I'll.
Just
be
brief.
There's
another
adjacent
idea
that
we
had
talked
about
over
the
summer.
I
know
thanos
has
done
some
work
around
it
and-
and
I
I
would
love
to
spend
some
time
on
it
as
a
dev.
I've
not
had
that
time
over
the
last
quarter,
but
a
sort
of
a
a
mirroring
proxy
or
a
smart
sort
of
l7.
If
you
will,
you
know
remote,
write
protocol,
aware
proxy
that
could
do
buffering
mirroring
and
things
like
that.
You
know
right
now.
A
A
A
Yeah
yeah,
neither
do
you
mention
that
it
makes
a
whole
lot
of
sense.
Think
about
it.
So
thank
you,
cool,
yeah
and
again
thanks
for
thanks
for
bringing
this
up
and
we'll
look
forward
to
talking
about
it
in
the
future,
all
right.
So
with
that
before
we
dive
into
the
openmetrics
due
diligence.
Is
there
anything
anyone
wants
to
mention
before
we
before
we
spend
sort
of
the
remainder
of
our
time
there.
A
A
The
secret
sorority
team
together
and
all
members
you
are
kind
of
happy
to
you're,
welcome
to
you,
know,
comment
or
you
know
kind
of
point,
any
maybe
gaps
or
actually
you
know
praise
this
and
and
essentially
go
through
this
and
and
agree
if
we
want
to
recommend
openmetrics
as
as
a
project
that
should
be
in
the
incubated
stage,
not
in
the
sandbox,
as
it
is
right
now
right.
So
the
team,
the
openmetrics
team,
spent
a
lot
of
time
on
doing
this.
So
it's
actually.
A
I
I
read
through
this
and
it's
kind
of
have
everything
in
my
opinion,
but
but
we
can,
I
mean
the
plan
is
to
go
through
all
of
this
and
and
essentially
review
this
together,
and
maybe
we
can
do
this
in
similar
fashion,
as
we
did
previously
with
cortex
and
thanos.
So
please
feel
free
to
comment,
and
essentially
we
go
through
yeah
most
of
the
of
the
sections
here.
A
I
know
that
I
know
that
I
I
would
like
to
spend
some
more
time
with
it,
but
that's
not
to
say
we
shouldn't
walk
through
the
and
and
see
where
we're
at
yeah
I've
skimmed
that
I
haven't
had
an
opportunity
to
add
comments
yet
would
definitely
like
to
take
another
pass
as
well,
but
I
I've
at
least
read
it.
The
first
time.
A
Okay,
then,
it
sounds
like
just
to
set
expectations,
we're
probably
as
much
as
we
would
like
to
just
do
it.
You
know
it
sounds
like
we
might.
We
let's
spend
the
time
today
to
walk
through
it
and
then
see
where
we're
at
as
a
group,
but
I
do
want
to
make
sure
that
we,
you
know
we
we
have
sufficient
time
for
review
by
the
community,
maybe
a
reminder
of
how
the
cortex
and
thanos
due
diligence
was
handled
there.
A
A
Well,
we
can
do
that.
Definitely,
I
think,
with
the
cortex
and
tunnels,
people
had
like
at
least
a
week
noticed,
but
I
think
it's
much
smaller
as
well
as
the
project
is,
is
essentially
about
the
protocol
and
open
for
the
whole
okay
yeah.
That's
established
protocol
as
well,
so
this
isn't
just
most
of
this
should
not
be
controversial
or
new.
For
for
folks
who
are
so
yeah,
let's,
let's
dive
in
then
let
me
actually
so.
Do
you
want
me
to
kind
of?
Do
you
want
me
to
be
the?
A
I
definitely
won't
be
that
efficient,
but
we
can
try
so
first
of
all
governing
let's
go
so
open
observability.
The
governance
was
kind
of
established,
I
think
kind
of
presently.
Maybe
I
don't
know
maybe
richie
and
essentially
maintainers
can
can
walk
us
through,
like
tdr
of
the
coordinates,
is
that
does
it
make
sense?
A
A
A
So
yeah
that
would
be
that
weird.
Does
anyone
has
any
comments?
Any
questions
around
that
I
requested.
Oh,
go
ahead,
matt!
No
after
you,
I
was
just
gonna
request.
Is
this
one
of
the
ones
that
we
can
revisit
because
I
want
to?
I
did
not
have
a
chance
to
read
this
link.
I
read
the
doc,
but
I
didn't
read
the
links
out
yet
so
I'd
definitely
like
to
revisit
this
one
if
we
could
yeah
what
question
I
have
in
the
similar
vein
is:
where
are
the
meetings
and
are
they
you
know?
A
They
are
on
a
fourth
nightly
cadence,
so
we
had
a
ton
of
meetings
recently
they
were
closed,
as
everyone
is
aware
for
the
simple
reason
that
even
people
who
left
for
just
one
or
two
months,
it
was
impossible
to
re-on-board
them
because
we
had
everything
in
our
head
and
needed
to
to
frantically
get
it
out.
That
being
said,
obviously
there
was
documentation
as
code
with
inclined
python
goal
with
inclined
python
and
within
prometheus
proper
itself
going
forward.
A
A
Okay,
in
this
case,
I
think
we
can
essentially
give
some
time
for
review.
I
guess
this
and
again
we
can
get
back
to
this
later
and
let's
move
on.
Is
there
a
documentary?
One
last
question
I
had
around
the
governance
and
and
the
go
forward
plan
is
the
application
to
itf
and
the
various
back-and-forths
that
will
be
happening
there.
Is
that
expected
to
be
done
in
the
open
as
well?
So
folks
can
listen
in
even
if
they're
a
fly
on
the
wall
and
not
a
contributor,
so
within
itf?
This
is
out.
A
A
I
did
send
the
version
which
we
have
to
the
ops
wg
chair
to
do
one
read
through
if
in
case
we
have
any
obvious
mistakes
and
then
it
will
be
submitted
to
the
idf
rfc,
tracker
or
internet
draft
tracker.
Where
everything
is
public,
it
will
be
discussed
on
the
mailing
list,
which
is
public
and
as
currently
there
are
no
itf
meetings.
It
is
done
through
video,
which
is
also
public.
Oh
super
great
yeah,
I
do
realize
that's
out
of
the
scope
of
governance,
but
I
wasn't
sure
where
else
it
was
it.
A
A
A
A
A
Richie
barter:
what
do
you
think
yeah
speaking
as
a
project
member
in
the
scope
of
of
the
question
if
it
is
self-governing,
I
think
we
can
answer
this
as
a
yes
and
as
such,
I
don't
think
there
is
much
more
to
be
discussed
outside
of
just
this.
Yes,
no
question
so
with
my
not
the
chair
head
on
just
the
project
head
on.
I
don't
see
any
reason
for
for
needing
to
follow
up.
That
being
said,
if
that
is
the
group
consensus,
obviously
the
project
will
yield
to
this
sure.
A
A
A
I
think
I
think
we
should
all
just
like
I'll
I'll
speak
for
everyone
and
say
richie.
We.
We
assume
that
for
the
remainder
of
this
call,
you
you
have
your
project
lead
hat
on
and
I
applaud
your
being
specific,
but
I
will
always
be
specific
when
talking
about
anything
procedural
but
yeah.
Yes,
yes,
let's
just
move
on,
indeed
cool.
So
next
one
is
a
very
straightforward
code
of
contact.
Is
there
a
documented
code
of
contact?
A
A
Twice
no
okay
so
looks
like
we
are
happy
next
one
does
the
project
have
production
deployments
that
are
high
quality
and
high
velocity
for
both
yeah?
This
is
related
to
us
here
in
this
case.
So
yes,
two
of
the
most
used
promotes
client.
Libraries
have
supported
openmetrics
and
that's
true
because
I
maintain
one
of
them.
A
Server
and
datadock
have
been
supporting
openmetrics
yeah
two
years
here
already
and
we
are
different
negotiating
open,
metrics
as
well,
and
there
is
exemplars
support
added
as
well,
so
so
like
that,
the
very
powerful
feature
of
open,
metrics,
so
cool
apart
from
links
missing
any
any
comments
and
call
for
consensus.
I
guess
straight
away:
do
we
like?
Is
that
enough
as
a
production
deployments?
I
think
for
me
it's
enough.
A
Okay,
please
feel
free
to
just
speak
up
if
you,
if
you
have
comments
or
like
questions,
that's
totally.
Okay.
Next
one
is
the
project
committed
to
achieving
this
briefly.
I
know
that
originally,
you
know
getting
vendors
to
support
both
both
both
format
to
support
the
format.
For
you
know,
devices
and
other
things
that
are
not
just
a
client
library
was
talked
about,
is.
Is
there
any
references
we
might
want
to
add
to
folks
actually
had
that
I've
implemented
openmetrics?
A
For
you
know
either.
I
think
this
is
something
other
than
client
libraries,
in
other
words
like
embedded
devices
that
are
using
those
or
embedded
devices
that
are
writing
their
own
client.
Libraries
like
how
broad
is
the
the
current
user
base
offhand
outside
of
the
client
libraries.
I
think
there's
only
three
or
four
things
that
have
directly
implemented
it.
For
example,
I
know
that
dovecot
has,
although
I
think
the
pr
is
still
open,
but
I'm
not
aware
of
any
embedded
hardware
devices
have
done
it
yet
because
it's
too
early
in
the
standardization
process.
A
My
goal
here
would
be
if
there
are
even
others
that
are
that
have
started
to
use
it
even
if
it's
not
finalized
or
what
or
what
not.
It
might
make
sense
to
add
it.
So
again
when,
when
our
leo,
when
our
liaison
reviews
this
and
then
the
toc
reviews
this
once
we
because
the
process
here
is,
the
sig
makes
a
a
formal
proposal
that
yes,
this
should
this
should
move.
This
should
be
advanced.
A
A
All
right,
let's
move
on
so
is
the
project
committed
to
achieving
the
cncf
principles
and
do
they
have
a
committed
roadmap
to
address
any
areas
of
concerns
raised
by
the
community?
So
the
answer
is
it's
committed.
There
is
no
roadmap,
but
that's
the
nature
of
standard,
a
sister
projects
to
specify
a
wire
format.
I
guess
this
is
like
a
plant
thing
in
a
road
map
with
an
old
map.
A
sister
project
to
specify
a
wire
format
for
locks
is
next
and
will
happen
under
the
umbrella
of
open,
telemetry
github.org.
A
We're
not
aware
of
any
concert
by
the
community
steve.
Do
you
want
to
maybe
yeah?
So
I
put
one
comment
on
here.
I
actually
have
two
comments,
so
one
was
just:
are
there
any
like
big
rock
things
that
could
be
noted?
I
think,
given
that
it's
most
of
it
hasn't
been
opened
to
date,
like
the
community
as
a
as
a
whole,
probably
hasn't
had
a
chance
to
really
comment
on
it,
so
that
will
probably
change
over
time,
but
does
the
at
least
the
the
committee
today?
A
A
The
reason
why
it
is
out
of
scope
is
course
we,
as
a
project,
made
a
hard
promise
to
retain
comparability
to
prometheus,
so
we
just
couldn't
make
that
work,
but
this
is
something
which
which
we
see
as
one
of
the
highlight
features
of
a
future
version
and
beyond
that,
there's
nothing
super
pressing,
because
else
we
wouldn't
be
comfortable
releasing
this
as
to
the
cncf
principles.
That
is
with
my
project
head
on
how
we
replied
to
the
official
toc
checklist,
so
that
is
basically
the
the
question
in
its
entirety.
A
I
fully
agree
with
with
everything
you
mentioned.
I
do
think
that
we
adhere
to
all
of
these,
obviously
so
yeah,
but
like
giving
this
feedback
to
cncftuc
to
improve
the
checklist
makes
absolute
sense
yeah.
Maybe
this
one
would
be
a
good
one
to
to
review
next
time.
We
meet
too
right
because
I
did
not
compare
it
to
the
to
the
cncf
principles.
A
A
I
I
don't
I'm
not
familiar
enough
with
the
cncf
principles
to
comment.
I
have
a
question
around
the
alignment
with
open
telemetry.
I
mean
you
mention
it
somewhere
at
the
very
bottom
and
I'm
a
little
surprised
that
you
mentioned
the
wire
format
for
locks
here,
but
not
the
wire
format
for
metrics,
and
that
is
certainly
something
that
I
find
quite
worrying.
That
is
something
that
I
would
have
expected
in
the
roadmap.
To
be
very
clear
on
that.
This
is
your
goal.
A
Which
part
the
part
where
you
said
that
we
talk
about
logs
and
not
metrics,
because
the
opposite
is
true.
We
talk
about
metrics
in
our
vlogs.
The
the
the
sentence
here
says
assist
the
project
to
specify
a
wire
format
for
logs
is
next.
Okay,
then
just
a
second.
I
thought
you
were
talking
about
the
section
where
you
left
your
comment.
A
A
A
There
is
no
direct
support
in
this
direction.
Steve
correct
me.
If
I'm
wrong
yeah,
I
think
there's
two
parts
to
that,
though,
right
like
one,
is
open,
telemetry
supporting
sending
to
open
metrics
destinations
in
theory
that
should
be
possible.
I
don't
know
if
any
due
diligence
has
been
done
to
compare
the
otlp
protocol
with
openmetrics
and
confirm
that
it
actually
can
be
fully
translated.
A
A
There
are
some
some
incompatibilities
especially
around
how
histograms
are
with
lower
equal
or
greater
eco,
and
also
about
about
having
deltas
instead
of
counters,
which
makes
it
easier
to
discard
state
immediately
within
open
telemetry.
But
then
you
have
a
more
or
less
mandatory
sidecar,
which
rebuilds
that
state
to
be
able
to
talk
to
all
end
points,
not
only
prometheus
type
endpoints.
A
A
I
have
a
suggestion.
Actually,
oh
sorry,
the
the
thing
that
confuses
me-
and
I
I
see
myself
as
a
proxy
of
many
of
our
customers
who
are
equally
confused
is-
is
their
intention
from
openmetrics
to
enable
any
kind
of
open,
telemetry
support
or
not,
and
the
thing
that
confuses
me
when
I
look
at
that
is
that
you
clearly
spell
out
the
wire
format
for
logs,
but
not
for
metrics,
and
I'm
trying
to
understand
is
that
intentionally
so
or
not?
If
it's
not
so,
then
we
should
spell
it
out
here
in
the
roadmap.
A
Okay,
I
I
think
I
know
I
think
I
understand
where
you're
getting
it
so
again
as
a
wire
format,
it's
next
to
impossible
to
support
an
instrumentation
library
which
supports
a
myriad
of
wire
formats.
That
is
the
wrong
way
around
like
I
cannot,
within
with
a
wire
format,
support
an
instrumentation
library.
This
instrumentation
library
can
support
the
wire
format.
A
Obviously
it
is
the
case
that
open
metrics
is
modeled
after
what
client,
golem
and
client
python
and
such
do,
and
obviously
it's
the
case-
that's
also
one
along
the
lines
of
what
prometheus
has
been
doing
and
which
basically
has
been
has
been
in
existence
since
2014,
based
on
promising
exposition
format,
zero,
zero.
Four.
A
All
that
being
said
again,
I
that
does
not
make
seem
to
make
sense.
We
can
definitely
put
some
more
verbage
around
the
metrics
part
in
that
logs
part
is
more
of
an
outlook
of
what
is
logical,
next
steps
for
for
open
telemetry
as
such
another
way,
so
many
opens
too
many
opens
so
it
says
another
way.
This
is
the
roadmap
section
and
metrics
aren't
mentioned
in
the
robust
section,
because
metrics
are
to
some
extent
done.
A
However,
logs
are
a
potential
future
thing
which
is
wider
in
the
road
section,
so
this
is
all
very
future
looking
right,
whereas
metrics
here
I
get
that
I
get
that.
But
if,
if
I
understand
it
correctly,
then
the
argumentation
that
richard
just
used
for
metrics
in
the
wire
format
would
also
apply
to
logs
or
not.
Why
are
logs
different
than
the
members?
No
they're,
not
again
the
outlook
section
so
for
the
outlook
section
it
did
not
make
sense
to
talk
about.
We
will
specify
metrics,
because
we
just
did
this
right
and
is
it?
A
It's
I
know
it's
this.
There
are
many
open,
open
things
there
right
here
now
it
is
now
it
is
much
clearer
to
me
that
does
make
more
sense.
So
I
I
as
a
point
of
order.
I
I
have
a
suggestion,
maybe
again
like
I
know
some
of
us
have
been
reading
and
steeped
in
in
this
this
noun
soup,
but
we
might
want
to
jump
to
the
context
after
this
section
of
on
roadmap
at
the
bottom
of
the
document,
particularly
for
folks
that
might
be
joining
our
call
for
the
first
time
or
are
not.
A
A
I
propose
that
after
we
finish
with
discussion
of
section
four
and
we
come
to
do
a
call
for
consensus,
we
jump
to
the
bottom
part
of
the
document.
There's
a
section
called
context,
the
last
section
and
that
sort
of
in
my
mind,
that
would
be
one
of
the
first
sections
if
we
were
again
yeah,
just
kind
of
because
it
because
it
just
sets
the
the
stage
and
then
lays
out
some
of
the
the
nouns
and
then
and
and
such
it
might
facilitate
the
rest
of
the
sections
of
the
document
happening
a
little
quicker.
A
A
A
So
the
thing
as
we
have
are
there
actual
concerns
active
concerns,
or
is
this
a
case
of
not
having
read
up
on
the
cncf
principles
and
or
of
toc
checklist
not
being
as
good
as
it
could
potentially
be,
because
this
is
actually
the
same
checklist?
We
went
through
with
cortex
and
thanos,
so
it's
yeah,
so
so,
let's
break
this
into
two
parts.
Number
four
asks
two
questions:
one's
around
cncf
principles.
I
think
if,
if
you're
all
comfortable
that
the
answer
is-
yes,
that's
probably
sufficient.
A
A
I
think
we
could
adopt
the
same.
I
think
we
could
adopt
the
same
process
here
all
right,
so
so
I
think
you're
both
saying
the
same
thing,
a
slightly
different
way
right.
So
so
we've
raised
the
concern.
The
project
can
more
in
parallel,
can
elaborate
the
roadmap
and
we
can
call
for
consensus.
That's
you
know
contingent
on.
A
A
A
A
Are
you
reasonably
concerned
that,
depending
on
the
roadmap,
there
may
be
concerns
right
and
we
we
would
just
address
them
as
they
come
right?
I
mean
yeah.
I
think
this
isn't
the
final
sign
off
right,
yeah,
one
where
near
that?
Oh
sorry,
but
I
just
reread
the
thing:
do
they
have
a
committed
roadmap
to
address
any
areas
of
concern
raised
by
the
community?
So
this
is
not
about
concerns
about
a
roadmap.
It
is
about
current
projects
which
are
then
being
addressed
by
a
wrong
man.
A
A
Yeah-
and
I
think
there
are
several
listed
in
the
bullet
points
above
right,
so
the
ask
is
to
comment
on
which
ones
are
applicable
to
open
metrics
and
what
would
be
the
roadmap
for
those
items
correct
with
my
project
head
on.
I
don't
believe
that
there
are
any
on
open
metrics
as
a
project
beyond
working
in
good
faith
with
the
other
projects.
But
if
that
is
not
the
group
consensus,
then
obviously
it
can't
be
the
consensus.
A
A
Okay,
I
think
let's
move
on
and
I
don't
think
there
is
consensus
in
my
opinion,
yeah
we'll
move
on
and
we
can
also
work
offline
in
the
in
the
next
two
weeks
in
the
talk
and
comments
in
the
cncf
slack
yeah.
But
I
think
we've
we've
made
some
progress
on
this
one,
at
least
on
the
first
part,
and
we
have
some
action
items
for
the
project
to
come,
come
back
and
click
yeah.
Let's
clarify
this.
A
It
would
be
good
to
know
just
just
briefly.
Jumping
in
would
be
good
to
know
like
specifically
what
the
the
outcomes
would
be
desirable
for
that
work,
if
possible,
like
the
only
concern
would
be
doing
it
or
completely.
Asynchronously
would
be
that
there's
some
comments
made,
and
you
know
some
works
done,
but
we
come
back.
You
know
a
few
weeks
later
and
it's
like
yeah
we're
spinning
into
december
and
oh
yeah,.
A
A
So
I
think
some
of
the
concerns
are
around
and
I
think
we'll
see
this
in
some
of
the
other
items
too,
like
how
it
impacts
potentially
open,
telemetry.
Okay,
then
please
write
out
specific
concerns
and
we
can.
We
can
take
the
discussion
above
and
pivot
this
into
specific
concerns,
which
we
can
address
specifically
right.
A
How
do
we
fast-track
this
to
making
people
feel
like
making
people
feel
like
we're
addressing
the
concerns
that
need
to
be
addressed
and
to
me,
it's
not
a
hundred
percent
clear
that
we
have
a
process
for
getting
there
if
yeah,
and
I
think
one
of
the
problems
is
we're
kind
of
doing
it
live
right
now.
So
I
guess
matt.
Maybe
a
question
to
you:
do
you
want
to
put
like
some
sort
of
timeline
around
when
people
have
to
provide
comments
on
this
doc,
so
that
the
other
team
has
something
tangible?
A
I
would
propose,
so
I
think
rob
what
you're
saying
as
well
as
brian
is
completely
fair
and
in
my
mind
a
specific
enumeration
of
concerns
is
what
would
be
requisite
to
actually
commit
to
a
road
map
to
address
them
and,
if
you
don't
know
specifically
what's
being
asked,
then
there's
ambiguity
and
then
we're
we're
into
december
and
next
year.
God
forbid.
So
so
why
don't
we
time
box
this
for
two
weeks?
If
that,
if
that
makes
sense,
I
think
I
think
the
folks
that
are
passionate
about
this.
A
One
final
concern,
basically
right
before
or
even
during
the
call.
Oh
okay.
Well,
I'm
sorry.
I
meant
two
weeks
for
the
entire
activity.
So
that's
that's
a
fine
point
as
well.
So
do
we
want
to
say
like
by
monday
of
next
week
or
or
whatever
I
mean?
No
one
needs
to
write
soliloquies
or
sonnets,
but
you
know
I
we
could.
A
Anyone
object
to
that.
I
want
to
try
to
strike
the
right
balance
here.
You
know
so
that
we
can
address
all
these
concerns
and
but
also
be
time-bounded,
because
I
think
there
is
I'd
like
to
I'd
like
to
move
this
forward.
I
think
I
think
the
community
needs
this
to
move
forward
as
well.
If
I
could
be
so
bold,
so
cool
cool.
That
makes
sense.
I
think
then
spending
last
four
minutes
to
rush
through
the
points
is
not
very
yeah.
A
I
think
we
already
have
pretty
widespread
adoption.
I
think
so.
I
guess
the
only
concern
I'd
raise
is
again
open.
Symmetry
is
going
to
come
up
if
open
symmetry
is
the
client
library
for
all
data
sources
and
it's
not
compatible
fully
converting
to
open
metrics.
Is
that
not
a
huge
inhibitor
to
potential
widespread
adoption?
A
The
question
is
which
way
the
incompatibility
goes,
because
if
you
go
from
prometheus,
which
even
predates
the
cncf
and
which
is
supported
by
literally
all
projects
which
in
within
the
cncf
and
by
thousands
of
others,
I
would
strongly
argue
and
did
argue
in
the
open,
telomere
metrics
calls
that
that
there
is
an
installed
base
to
take
into
account
yeah
totally.
I
mean
I
I
totally
agree.
I
think
the
counter
argument,
though,
is
the
prometheus
client
library
is
just
for
metrics.
If
I
want
logs
and
I
want
traces,
I
need
to
go
use
something
else.
A
A
A
I
I
think
it
actually
inhibits
open,
telemetries
widespread
adoption
by
not
supporting
prometheus.
Everyone's
data
pipeline
is
already
set
up
to
ingest
prometheus
metrics.
All
the
major
vendors
support
it.
It's
it's
widely
deployed,
as
prometheus,
obviously
is
by
cncf
for
folks
that
are
cncf
end
users,
not
supporting
openmetrics
is
a
huge
inhibitor
to
open,
telemetry
being
deployed
in
in
any
real
deployment
as
a
vendor.
I
I
can't
recommend
people
use
open
telemetry
until
it's
until
it
supports
it,
and
that's
generally,
what
I've
seen
in
the
community.
A
B
B
That's
the
way,
that's
you
know
most
folks
around
the
project
have
been
been
looking
at
open,
metrics
and
how
it
relates.
That's
my
assessment
as
well.
You
know
prometheus
being
a
cncf
graduated
project
and
sort
of
the
de
facto
way
to
monitor
all
sorts
of
things,
not
the
least
of
which
is
kubernetes.
B
You
know
that
the
installed
base
is
effectively
prometheus
and
at
least
my
understanding
from
reading
the
openmetric
spec
and
and
this
due
diligence
is
really
exactly
what
you
said.
It's
it's
just
getting
agreement
on
the
wire
protocol,
so
there's
a
lingua
franca
right
that
and
and
and
it's
modeled
after
what
already
exists
as
a
drop-in
with
a
few
a
few
tweaks.
B
B
E
B
Yeah-
and
I
think
maybe
that's
the
biggest
call
out
right
as
long
as
there's
like
commitment
to
collaboration
on
both
sides,
and
maybe
that
just
addresses
this.
There
is
a
potential
compromise,
critical
issue
in
that,
if
open
symmetry
does
not,
then
adoption
could
be
impacted.
The
mitigation
there
is
openmetrics
commits
to
working
with
open
symmetry
and
open
symmetry
commits
to
working
with
openmetrics.
Thus
we
believe
this.
B
F
About
my
currently
linked
to
to
to
do
a
group
explainer
of
open
metrics,
if
you
haven't
seen
the
screen,
I
know
you
weren't
at
that
meeting,
but
I
I
highlighted
you
bockton
and
josh
point
being,
I
wouldn't
have
said
in
all
those
meetings
starting
at
21
local,
if
not,
if
not,
for
an
honest
desire
to
be
interoperable
with
with
open
telemetry
people
are
yelling
at
me.
Of
course
I
need
to
get
into
a
new
call
yeah.
I
think
we've
made
good
progress
here
today.