►
From YouTube: CNCF SIG Observability 2020-12-08
Description
CNCF SIG Observability 2020-12-08
A
C
C
C
D
E
Yeah
we
we
got
a
it's
an
artificial
tree
and
there's
an
app
it's
twinkly,
you
can,
you
can
set
different
patterns,
it's
pretty
neat,
actually
it
maps
the
tree
lights
like
you
point
it,
and
and
then
you
can,
the
kids.
You
know
they
they
can.
They
can
make
custom
things
and
I
seriously
hope
you
have
hooked
it
up
to
the
alert
manager.
That's
what.
E
E
C
C
One
point
of
order
is:
if
we
should
have
the
next
call
on
the
22nd
of
december,
and
I
think
we
should,
because
we
still
have
a
few
work
packages
left.
So
it
makes
sense
to
just
try
and
cover
this
unless
there
is
stronger
position
from
anyone
who
who
doesn't
want
us
to
to
bleed
into
into
the
quiet
days.
E
You
know,
for
example,
annotations
on
service
accounts
and
if
anybody
else
got
hit,
when
docker
hub
started
rate,
limiting
we
needed
to
have
image
pull
secrets
on
all
service
accounts.
In
addition,
we
run
things
pretty
securely
so
that
in
kubernetes
default
servers
accounts.
Don't
have
any
rights
or
permissions,
meaning
that
we
had
to
create
pod
security
policies
and
lots
of
our
back
stuff.
E
So
so
we're
open
sourcing
that
stuff
and
over
the
next
couple
of
weeks
I'll
be
filling
out
the
rest
of
the
configurations,
as
well
as
how
we're
using
the
prometheus
case
on
it,
project,
which
is
a
jsonnet
project.
That
is
an
opinionated
way
to
run
grafana
and
prometheus.
That
has
a
nice
plugable
mix-in
model
so
that
all
of
the
operational
dashboards
to
run
logging
tracing
metrics
back-ends
are
there.
We
found
them
to
be
useful.
E
So
my
hope
is
that
that
github
org
is
a
place
where,
if
other
people
want
to
contribute,
they
they
could
and
and
I'll
also
be
using
that
github
org
to
to
work
on
some
tooling
around
ci
cd,
as
well
as
like
a
there's,
a
vs
code
plug-in
that
that
could
use
some
help
and
and
some
things
like
that.
So
this
isn't
anything
officially
cncf,
but
perhaps
it
could
be
the
nucleus
or
a
way
to
jumpstart
building
out.
E
E
You
know
pointing
to
other
resources
for
a
developer,
so
so
I'm
starting
with
our
production
configs,
but
I
hope
to
backfill
how
you
can
do
this
in
the
case
of
us
as
an
end
user,
it's
been
useful
and
and
worthwhile
as
a
goal
to
have
how
iterative
iterative,
local
development
works
in
terms
of
tool
chain
and
have
that
match
how,
in
our
case,
production
runs
so
that
we
don't
have
a
skills
gap
there.
But
that's
it.
F
E
F
Cool
amazing:
let's
continue
what
we
started
a
week
ago,
two
weeks
ago.
Sorry-
and
I
hope
we
we
have
lots
of
time
for
for
anyone
to
kind
of
review
it
if
they
are
interested.
So
hopefully
we
have
more
context
on
this.
So,
let's
go
actually.
I
can
share
my
screen
as
usual
and
let's
go
for
this
incubation
and
then
check
if
we
have
any
concerns
or
if
we
can
propose
this
to
the
toc
as
our
recommendation.
F
Cool
amazing,
I
just
reverted
like
five
changes
I
made,
because
I
started
to
accept
those
suggestions,
so
it
was
changed
so
now
I
reverted,
so
it
should
be
all
the
fresh
changes
that
we
seen
in
comparison
to
two
weeks
ago.
Okay
and
the
flow.
Hopefully
we
can
do
the
same,
so
I
can
by
default
just
call
for
consensus
and
please
speak
up
if
you
have
any
concerns
or
questions
or
follow-up
comments,
essentially
sounds
good.
F
Okay.
So,
first
of
all,
let's
go
for
the
first
topic
that
was
already
commented
two
weeks
ago.
So
essentially,
if
the
project
is
self
governing
and
the
governance
was
created,
however,
there
were
first
of
all
question
around
more
time
to
revisit
the
whole
topic.
We
definitely
extended
that
to
two
weeks.
So
I'm
happy
to
accept
this.
Where
are
the
meetings
and
are
those
opens?
F
Public
meetings
are
started
from
now
on,
looks
like
that's.
The
response
fortnight
call
intention
to
be
public
soon.
Is
there
application
to
aef
public?
And
yes,
you
can
find
it
on.
The
email
list
looks
like.
Is
there?
Let's?
Maybe
because
okay
is
this
copied
from
okay?
So,
essentially,
governance
is
copied
from
pro
meteors
with
minor
changes,
and
that
was
kind
of
the
the
question
like
what
exactly
is
changed
and
looks
like
cleaner
donation
of
repositories
within
the
github
org,
so
yeah,
that's
pretty
specific.
F
We
have
many
github
projects
in
primitives
that
has
different
kind
of
rules,
so
that
makes
sense
an
itf
rough
consensus
is
not
a
lazy
consensus.
That
sounds
good
to
me
as
well,
and
we
have
a
project
lead
in
openmetrics
looks
like
okay.
Are
we
happy
with
this?
Is
there
consensus
on
that
as
a
sick,
observability?
F
F
No,
no
objection
so
far.
So
let's
move
on
and
I
think
this
part
actually
was
agreed
before,
but,
let's
repeat
all
right-
and
that
was
the
the
the
concerning
point
that
we
spent
some
some
amount
of
time.
So,
let's
see
does
the
project
have
production
deployments
that
are
high
quality
and
high
velocity?
F
F
G
E
F
Please
do
we
would
love
to
see
that
yeah
exemplars
is
also
kind
of
good
point,
because
that's
a
kind
of
nice
feature
of
openmetrics-
and
I
know
thanos
we're
already
kind
of
developing
this
support
but
looks
like
graphene
labs
and
chronosphere
are
already
using
that.
So
there
is
this
question,
I
don't
know
how
broad
is
the
implementation.
G
E
Oh
yeah,
no!
No!
Yes,
I'm
familiar
with
it!
That's
why
I
was
asking
actually
I'm
working.
I'm
working.
We
run
linker
d
in
production,
and
so
we've
been
looking
at
ways
to
contribute
and
I
think,
there's
an
opportunity
if
there
once
there
is
a
opioid,
metrics,
rust,
client
library,
that
is
yeah,
that's
that's
that's
vetted
and
whatnot.
That
would
be
an
opportunity
to
improve
the
project.
F
E
F
C
Maybe
broad
option
was
the
intention
of
that
thing.
That's
what
we
thought
about,
but
apparently
didn't
comment
that
we
thought
it
would
be
a
question
about
adoption
and
not
implementation,
and
as
this
is
based
on
on
premises,
it's
all
across
the
cncf.
I
don't
think
we
should
have
the
comments
in
the
actual
due
diligence
document
once
the
document
is
done,
but
I
also
don't
object
to
it.
It's
just.
C
F
Right
looks
like
this
number
four:
is
the
project
committed
to
achieving
the
cncf
principles
and
do
they
have
a
committed
road
map
to
address
any
areas
of
concerns?
It's
committed?
There
is
no
roadmap,
but
there
is
nature
of
a
standard,
but
this
is
essentially
the
roadmap
is,
if
you
have
any
concerns,
so
is
there
any
concert?
We
have
a
comment?
Okay
and
and.
I
Sorry
this
is
a
very
long
comment
for
me
yeah.
So
I
think
there
are
several
things
here.
One
was
compatibility
with
hotel.
I
believe
that
one
has
been
addressed,
so
there
has
been
meetings
between
om
and
hotel.
The
owen
folks
have
joined
the
hotel
sig
meeting,
and
I
think
this
is
already
commented
here
that
work
to
collaborate
and
ensure
that
things
are
are
met
so
from
an
hotel
perspective.
I'm
I'm
good
with
the
first
part
of
the
comment
that
I
had
unless
anyone
objects,
of
course,.
I
All
right
there
are
several
other
ones
here,
though
I
don't
know
if
these
have
been
addressed.
Okay,
so
support
for
dots
and
metric.
I
some
of
these
are
kind
of
generic,
so
maybe
just
take
the
second
to
the
bottom.
One
like
many
github
issues
have
been
idle
for
for
years.
I
don't
know
if
that
one
has
been
addressed
so.
C
We've
all
been
closed,
with
references
to
the
specific
parts
of
of
the
documentation
and
such
or
of
the
specification
of
the
documentation,
but
they've
all
been
closed,
except
for
two
one
is
a
more
generic
scraping
thing
and
one
is
a
request
for
readme
on
differences
and
synergies
with
open
telemetry.
But
as
we
have
the
joint
call
in
two
days,
we
thought
we
would
wait
for
that
one
before
we
move
forward
on
on
that.
One
issue.
C
Have
more
so
yeah
so
I
mean,
as
they
are
referring
to
issues
within
which
have
been
closed.
Maybe
we
can
just
jump
at
those
for
the
dots
and
metric
names.
I
can
already
tell
you
it's
an
incompatibility,
which
is
which
cannot
be
covered
by
openmetrics,
because
else
we
will
be
breaking
with
prometheus,
but
that's
been
clear
from
from
the
get-go
of
the
whole
project
for
better
or
for
worse.
C
We
did
have
that
discussion
within
the
working
group
several
times,
but
in
the
end,
dots
are
just
not
in
metric
names,
which
has
implications
towards
how
how
to
map
things
within
open
telemetry
inside.
We
will
work
on
those,
but
that's
outside
the
scope
of
the
due
diligence
for
just
the
project,
which
will
conclude
job
visit
integration.
You
can
just
click
it.
I
already
brain
flushed.
What
we
answered
and
yeah
the
idleness.
That's
been
that's
been
addressed.
Let
me
check
the
job
wizard
stuff.
G
I
C
Specification
when,
when
implemented,
you
have
everything
which
you
need
for
emitting
metrics
through
that
wire
format.
Within
that
one
specification,
so
I
mean
obviously
there
are
one
or
two
references
to
outside
standards
and
such
which
pull
in
the
definitions
from
the
other
standards.
But
beyond
this
there
is
nothing
which,
which
is
left
hanging
in
thin
air.
Everything
is
either
defined
within
the
specification
or
it
has
a
specific
and
explicit
reference
to
a
another
specification
pulling
those
definitions
in
which
is
a
hard
requirement
from
itf.
F
F
Here
looks
like
not
okay,
next
one
document
that
the
project
has
a
fundamentally
sound
design
without
obvious
critical
compromises
that
will
inhibit
potential
widespread
adoption,
given
that
was
yeah
that
was
based
on
the
prometheus.
It
has
kind
of
strong
background,
but
there
were
lots
of
comments.
Oh
a
bit
of
comments.
I
The
biggest
one,
I
think,
yes,
I
think
the
biggest
one
was
from
me
from
open
symmetry.
But
again
we've
been
resolving
this,
so
I
don't
see
any
blockers
as
it
stands
right
now
between
the
two
projects,
nor
any
blockers
from
a
due
diligence
standpoint.
So
at
least
from
an
open
symmetry
perspective.
I'm
I'm
good
on
this
one.
F
F
E
F
F
F
C
F
A
E
I
have
a
question
on
this
one
like
we're
listed
there.
I
I
mean
we're
not
like
in
an
ever
quotes
case,
we're
using
prometheus
and
remote
right
right,
right,
right,
we're
using
remote
right.
Is
there
an
implication
that
there's
something
specific
about
this,
or
is
this?
Basically,
anyone
using
prometheus
and
remote
right
is
using
this
format,
because.
C
E
E
E
C
F
I
copied
them
perfect.
We
have
comment,
though,
from
arthur.
It's
official
document
required
something
like
adopters,
it's
a
good
question
and
I
don't
think
it's
required
for
you
know
that
the
concrete
mean.
How
do
you
provide
the
adopters,
but
it's,
I
guess
nice
to
have
them
on
on
website,
but
I
don't
think
there
is
agreement.
F
C
E
C
F
Yeah,
but
it's
not
needed,
I
think
anyway,
let's
go,
have
a
healthy
number
of
committers.
A
committer
is
the
finance
someone
with
the
commit
permissions.
I
guess
someone
who
can
accept
contributions
and
we
have
yeah
four
of
those
car
active
maintainers
so
and
yeah.
I
can
definitely
confirm
they
are
active,
but
is
there
any
comment
and
objections
towards
that
call
for
consensus.
D
F
Caveat
here
is
that
github
was
not
used
for
most
of
part
of
the
work
right.
It's
mostly
google
doc.
So
I
think
this
applies
to
me
but
worth
to
kind
of
refing.
This
question
then
flow
of
comments
flow
of
merged
contributions.
I
think
this
applies
actually
that's
fine.
We
we
make
a
hard
commitment
to
keep
development
in
public
rare
on
boarding
previous
maintainers.
Even
after
a
half
year,
yep
and
plan
is
to
have
cold
contributions.
E
E
C
F
F
D
C
F
Large
sections,
okay,
project
description,
open
metrics,
creates
an
open
startup
from
transmitting
cloud
native
metrics
at
scale,
with
support
for
text,
representation
and
protocol
buffers
and
the
fact
of
standard
it's
kind
of
bigger
section.
So
let's
quickly
have
call
for
consensus.
Any
objections
to
this
description.
F
I
think
that's
okay
for
me
license
opportunity
github
repository.
Is
there
external
dependencies?
That's
important
one!
This
question:
okay,
external
dependencies
of
the
spec
we
don't
depend,
we
do
depend
on
several
ied
rfc
and
the
protobuf
specification.
That's
well
that's
dependency
to
me
and
yeah.
Let's
have
a
call
for
consensus
of
any
objections
on
external
dependencies
on
open,
metrics
of
open,
metrics.
F
Okay,
let's
move
on
release
methodology
and
that's
a
that's
interesting
one.
How
do
you
release
standard
and
patches
right
being
a
standard?
We
are
moving
slowly
and
deliberately,
and
chances
are
considering
costly
from
geoscope,
externals
and
communities,
all
of
them
cncf
projects
and
steve.
You
had
some
question.
C
K
I
F
F
F
F
I
D
E
E
H
E
F
E
F
E
G
G
F
Okay,
let's
move
on
what
are
the
primary
target
cloud
native
use
cases
which
of
those
can
be
accomplished
now
all
cloud
native
metrics
use
cases
are
covered
and
given
that
it's
kind
of
similar
to
prometheus,
I
tend
to
agree-
and
let's
have
maybe
like
and
call
for
consensus
for
all
of
those
four
can
be
accomplished
with
reasonable
additional
effort.
Idf
rsc
release.
Yes,
so,
given
a
new
release
we
can
I
mean
openmetrics
can
can
do.
F
Improvements
are
in
scope,
but
beyond
the
current
rollback
for
the
next
month.
So
what
what
kind
of
cloud
and
diffuse
cases
are
like
that
yeah,
current
probe
map
is
efficient,
histograms
and
that's
it
and
out
of
scope,
logging
and
tracing
are
out
of
scope,
also
see
additional
documentation.
Yeah.
That's
feel
fair
to
me
and
I.
A
A
D
F
C
F
F
Okay,
one:
what
exactly
are
the
failure
modes?
Are
they
well
understood?
Have
they
been
tested?
Do
they
form
part
of
the
continuous
integration
testing
and
are
they
appropriately
given
the
intended
usage,
the
main
failure
mode
of
a
spec?
If
it's
not
the
main
failure
mode
of
a
spec
is
if
it's
not
followed.
Okay,
this
specification.
H
E
I
showed
I
showed
the
spec
to
a
colleague
and
and
just
to
kind
of
get
their
feedback.
You
know
like
fresh
eyes
and
while
I
don't
think
it,
it
might
just
be
again
like
not
necessarily
like
so
what
they
raised
is
that
you
know
the
spec
doesn't
call
for
any
kind
of
like
check
summing
or
or
or
you
know,
knowing
that
in
in
a
secure
way.
These
have
been
delivered
and
what
I
said
well,
this
is
a
wire
format
and
whatever
protocol
would
handle
that
would
be.
E
C
K
C
F
I
F
I
C
But
that's
part
of
the
spec,
where
we
talk
about
that.
This
is
that
we're
just
building
on
the
transport
like
we
can
put
something
in.
I
don't
think
for
the
purpose
of
this
due
diligence.
It's
needed
to
write
more
here
because,
again
part
of
the
spec,
but
like
what
specific
wording
would
you
like
to
see
addressed.
I
I
I
guess,
like
I
was
looking
at
the
open,
metrics
spec,
the
the
scope
section
that
you
that
you
have
it's
intended
to
provide
telemetry
for
online
systems.
It
runs
over
protocols.
I
mean
explicitly
saying
that
it
is
not
a
protocol,
maybe
would
be
ensure
that
it's
just
out
of
scope
when
it
comes
to
like
performance
type
things.
It's
just
more
of
a
suggestion
like
I'm
not
very
hard
and
fast.
H
E
With
my
comment
I'll
add
a
lot
of
proposed
line
async
as
well
to
the
due
diligence
document.
Just
calling
out
specifically,
the
trade-off
like
it's
implied
here
like
proto,
is
much
more
efficient
on
the
wire
than
than
other
alternatives.
I
think
you
say
operational
considerations
in
the
first
paragraph,
but
I
mean
that
that
is
the
nugget
right.
That
proto
provides
a
much
more
efficient,
scalable
implementation
of
it
of
the
of
the
wire
format,
there's
implied
there,
but
we
might
want
to
just
add
some
of
this
to
in
case
whoever's.
C
F
F
K
F
F
I
F
F
F
All
right,
what
is
the
cicd
status?
Any
code
coverage
matrix
if
not
any
automated
tests,
and
although
it's
about
spec
there
is
mention
about,
implementations,
have
ci
integrations
and
there
is
even
test
cases
that
were
already
mentioned.
So
I
can
agree
with
that,
and
the
python
reference
implementation
has
what
quite
huge
implementation.
B
F
D
E
A
F
Let's,
let's
super
quickly
go
through
that,
but
not
like
and
have
a
bigger
call
for
consensus
at
the
end,
so
it's
growing
thriving.
Yes,
it's
aligned.
Yes,
we
talked
about
that.
Do
we
believe
it
can
eventually
meet
the
graduation
criteria?
Hopefully,
yes
should
it
start
a
sandbox.
Okay,
it's
already
offered
as
incubated
my.
A
C
C
C
F
F
I
I
C
C
Yet
that
is
part
of
where
the
initial
thing
is
coming
from
to
have
a
a
politically
neutral
place,
but
obviously
heavily
inspired
and
compatible
with
everything
which
the
cncf
graduate
projects
are
doing.
So
that's
the
that's
the
thing
to
to
phrase
it
differently,
so
I
I
think
we
we
we
support
or
do
you
have
specific
concerns
which
are
not
being
answered
by
what
is
written
there?
E
I
Yeah,
I
think
part
of
my
question
comes
because,
like
open,
symmetry
took
a
different
approach
like
the
same
applies
to
otlp,
but
otlp
is
part
of
open
symmetry.
It
could
be
a
separate
project,
but
why-
and
that
was
just
more
of
a
question-
I
don't
think
it
necessarily
matters.
I
don't
think
it
changes
anything.
I
just
wanted
to
raise
the
question.
C
F
C
F
C
For
a
wire
format,
they're
not
of
course
none
of
them
are
wire
formats
and
we're
deliberately
not
touching
the
implementations,
and
so
there
are
outside
the
scope
of
considerations
for
a
wire
format.
The
wire
formats.
You
can
make
a
point
that
modbus
should
be
considered,
but
it
really
is
not
for
metrics
beyond
that.
There
are
no
widely
adopted
wire
formats
which
deal
with
metrics.
E
C
F
All
right
time
is
up
so
time
is
for,
like
I
guess,
full
recommendation
call
for
consensus.
Are
we
happy
to
recommend
that
to
tlc
as
project
for
incubation
stage
looks
loose
green
to
me
any
objections,
any
comments
going
once
going
twice.
Okay,
looks
like
it's
green.
Thank
you,
everyone.
I
was
kind
of
again
elaborative,
okay,
so
one
one.
C
C
We
have
a
few
things
left.
I
think
also
matt
wanted
to
update
on
what
he
did.
We
have
something
by
simone
asimona
which
which
she
wanted
to
present,
I
think
going
into
the
holidays
with
with
oh,
yes,
sorry,
I'm
putting
on
my
my
chair
head
again
at
the
moment.
We
have
plenty
of
stuff
and
we
had
a
point
of
order
at
the
beginning
that
we
will
have
that
call
because
there's
enough
work
to
be
done.
So,
okay
go
we'll
just
hammer.