►
From YouTube: SIG Instrumentation 20201001
Description
SIG Instrumentation October 1st 2020
A
B
Okay,
next
point:
actually
I
think
I
just
spoke
to
lily
and
she
said
that
you
can
make
today,
so
we
can
move
that
point
to
the
next
to
next
time.
I
think
I
think
there
was
something
about
v1
k,
log
compatibility
or
incompatibility,
not
being
she.
She
heard
that
people
didn't
feel
like
that.
It
was
announced
well
enough,
so
maybe
we
can
try
to
have
kind
of
a
public
announcement
about
changes
there.
B
A
B
C
Yeah,
I
I
was
doing
some
like
looking
at
prs
for
signal
and
a
few
of
them
like
it
started
with
deduplication
of
events.
I
needed
some
input
from
sig
instrumentation
and
then
I
decided
to
just
put
more
sig
instrumentation
related
prs
in
one
place.
So
if
you
have
time
to
help
with
that,
it
will
be
great.
So
main
topic
is
deduplication
of
events,
so,
like
it's
second
second
section
in
a
document,
so
there
are
two
events
with
deduplication.
C
C
So
there
is
an
event,
that's
saying
that
container
failed
to
start
and
it
doesn't
include
container
name
which
may
be
beneficial
for
some
people
to
troubleshoot,
and
the
jordan
commented
that
his
container
name
this
event
description
wouldn't
be
repetitive
enough,
so
the
duplication
would
wouldn't
work.
So
I
was
trying
to
understand
what
to
do
here.
A
C
B
B
C
It's
okay.
I
can
reach
him
on
the
slack.
I
was
just
wondering
if
there
is
some
guidance
document,
because
in
other
pr
in
the
same
category
about
failed
mount,
it
includes
error
messaging,
an
event.
So
I
was
just
like
contradicting
myself.
So
on
one
hand,
we
don't
want
to
put
container
name
in
the
event
and
other
hand.
We
put
error
message,
an
error,
maybe
whatever
so
it
kind
of
doesn't
align
with
my
hat
in
my
head.
So
I
was
wondering
if
this
secant
has
like
is
there
somebody
on
this
call?
Who
has
enough
context
here.
B
B
B
A
I
don't
think
we've
ever
tried
to
work
on
seven
caps
simultaneously
before
so
we
did
this
last
meeting
and
I
thought
it
was
very
helpful
and
certainly
the
release
team
told
me
it
was
very
helpful.
So
let's
do
it
so
can
everybody
see
my
screen?
I'm
sharing
the
caps
I
see
some
nodding
sounds
good
and.
A
A
E
A
E
A
E
Yeah,
it
still
needs,
so
I
got
ciao
from
api
machinery
to
review
it,
but
I'd
still
like
lava
lamp
daniel
to
approve
it.
Okay,
I
did
ping
him,
he
said
yeah
you
can
us.
I
think
it
already.
Is
this
time
yeah?
Okay,
it's
cool!
I
I've
pinged
him
on
sak.
He
said
he
will
review
it
not
yesterday.
So
maybe
today
and
I
do
need
to
add
the
test
plan,
but
I
think
it's.
A
Like
singing
and
dancing
here,
I'm
just
that
excited
okay.
So
let's
take
a
look
at
structured,
login
merrick.
I
think
this
one
was
like
in
the
best
shape
of
all
of
them,
so
at
least
from
what
I
we
last
looked
at
it.
So
I
guess
the
beta
work
on
this
was
a
maybe
for
120..
So
I
have.
How
are
we
do?
We
have
the
availability
or.
F
I
assume
that
will
not
like
it's
smart,
defining
that
finishing
the
the
work
that
or
like
static
analysis.
That
needs
to
be
done.
I
would
be
more
focused
on
the
the
second
cap,
which
is
to
two
locks,
which
is
like
sanitization
to
make
sure
that
we
have.
I
think,
the
the
missing
part
that
it's
much
smaller
just
in
chest
plan
here.
I
didn't
have
too
much
time
to
for
structure
logging.
I
didn't
have
too
much
time
to.
I
will
look
look
at
it,
but
I
don't
think
I
will
be
able
to
do
that.
A
A
A
A
E
A
A
A
E
B
Yeah,
I
actually
commented
on
that.
So
for
all,
like
standardized
resources,
we
should
definitely
have
separate
metrics
for
this,
so
like
cpu
cores
memory
etc
for,
like
extension,
ones,
I
don't
think
we
can
get
around
doing
something
generic,
but
for
everything
that
is
like
standardized
core
resources.
We
should
definitely
have
separate
metrics,
because
it's
kind
of
the.
B
So,
even
if
that's
the
case,
I
think
the
proposal
was
to
put
the
type
of
resource
into
a
label
and
even
that
already
kind
of
violates
the
like
rule
of
thumb
of
prometheus,
which
is
like
any
metric,
must
be
summable
in
all
dimensions
and
still
makes
sense,
essentially
which,
when
you're
mixing
types
of
resources,
it's
kind
of
gibberish
the
result
right.
But
if
you're
like,
let's
say
cpu
metrics
or
something
right,
you
some
all
of
those
overall
clusters,
you
all
make
sense
right.
The
result
makes
sense,
but.
G
I
mean
frederick,
like
it's
a
rule,
but
if
it
doesn't
match
the
what
people
actually
need,
is
it
a
good
rule
right,
like
I
understand
the
tension
on
there?
I
just
don't
think
the
discoverability
of
prometheus
around
metric
label
around
metric
names
is
good
enough
to
justify
that
right.
Like
that's
the
challenge
like
okay,
clayton,
yeah,
sorry,
I
was
late.
I
had
another
meeting,
no
problem.
G
Oh
yeah,
perfect,
it's
a
huge
topic
right
like
I
don't
want
to
like
try
and
like
negotiate
it
like
now
I
just
like
how
do
I
go
find
all
of
the
things
that
are
related,
I
gotta
go.
Do
wild
card
queries
on
metric
names?
That's
awesome!
If
only
I
had
some
sort
of
system
for
categorizing
subsets
of
series
within
a
group
right
like
that's
the
counter
argument
to
that
rule
of
thumb.
B
B
G
Live
with
that,
I
struggled
with
splitting
it
like
I
I,
after
splitting
out
the
concrete
ones,
they
can
have
a
good
description,
so
you
know
it
kind
of
comes
down
to.
When
you
split
out
a
metric
series,
you
can
have
unique
metadata
on
the
description.
Do
we
do
a
good
enough
job,
exposing
that
all
the
places
in
prometheus
or
other
monitoring
systems?
No,
but
that
would
be
an
argument
for
the
individual
metric
name.
G
But
discoverability
is
pretty
rough
and
I,
as
an
admin,
I
do
not
care
about
all
the
different
extension
resources,
whereas
I
know
every
time
I'm
probably
gonna,
I
mean
the
vast
majority
of
admins
are
gonna.
Look
at
cpu
and
memory,
ephemeral,
storage
say
we
added
network
every
every
new
thing
we
add
to
the
standard
model.
I
think
there's
a
reasonable
assumption.
They're
gonna
look
at
those
and
they're.
You
know
they
do
that
for
container
memory
metrics
today
and
there's
like
five
different
variants
in
container
memory.
G
Each
of
those
has
a
unique
meaning.
They
each
need
a
description,
but
then
you
start
getting
into
extensions,
and
the
system
can't
give
you
good
metadata
about
them.
Is
the
right
thing
to
do
to
be
a
little
bit
more
formal
about
resource
assignment
in
kubernetes
and
say
there
should
be
a
way
in
kubernetes
to
name
the
meaning
of
extension
resources.
We
don't
have
that
today
we
could
move
down
that
path,
in
which
case
that
would
be
an
argument
for
you
know
for
every
one
of
those
that
we
had
metadata
on.
B
G
G
The
worst
one
for
extension,
resources
was
every
extension
resource
is
going
to
have
a
slash
and
a
dot
in
the
name
and
probably
dashes
which
transliterates
to
metric
names,
abysmally
and
so
already
an
end
user.
Would
struggle
like
you
would
not
be
able
to
cut
and
paste
the
resource
and
then
use
it
and
find.
G
You
would
have
to
apply
those
rules
yourself,
so
that
would
be
probably
the
strongest
argument
for
extension
and
I
can
buy
the
argument
of
the
generic
mechanism
if
everybody's
okay
with
living
with
it-
and
we
can
always
get
feedback.
You
know
if,
if
people
find
out
that
they
really
want
to
do
this,
some
and
they're
they're
uncomfortable
putting
the
slice
in
some
room
to
change.
A
A
A
A
A
E
E
A
Yeah
he's
reviewed,
so
that's
great
cool,
so
I
think
that
one
is
chugging
along
and
hopefully
it's
clear
what
the
release
team
wants
there.
So
is
there?
That's
all
the
caps.
Is
there
anything
else
that
we
want
to
go
over
in
the
cap
review
or
anything
else?
I
guess
that
we'd
want
to
discuss
in
terms
of
any
of
these
caps.
B
E
E
Oops,
let's
do
this
one,
so
I
spent
a
little
bit
of
time
working
on
a
little
proof
of
concept
for
something
to
monitor.
Systemd,
mostly,
I
feel
like
it's
really
hard
to
monitor
it.
The
cubelet
today
will
monitor
docker
and
it
or
where
it'll,
monitor
the
cubelet,
it'll
monitor
docker
and
that's
it
but
oftentimes.
I
run
a
bunch
of
stuff
like
npd
and
I
maybe
want
to
know
information
about
journal
d
as
well
c
advisor
does
an
okay
job
with
this.
If
I
run
it,
but
it's
really
expensive.
E
If
I
just
want
to
monitor
one
c
group
for
npd,
for
example,
and
kubernetes
is
kind
of
hard
to
configure
as
well
and
there's
this
other
there's
the
node
exporter,
which
has
some
really
cool,
systemd
metrics.
But
it's
not
resource
usage.
It's
just
basically
state
metrics,
so
is
it
running?
Is
it
not
running
and
I
kind
of
want
both
of
these,
but
just
for
a
small
small
set
of
services
like
cubelet
docker
npd
journal
d?
E
E
E
E
So
if
I
query
this,
it's
just
giving
me
the
same
sort
of
cpu
metric
that
I
would
get
from
c
advisor
the
same
sort
of
memory
metric
that
I
would
get
from
c
advisor.
But
also
then
I
can
get
sort
of
node
exporter
style,
state,
metrics,
and
so
I'm
not
actually
planning
to
do
anything
with
this.
But
I
wanted
to
present
it
just
to
kind
of
share
it
with
everyone,
and
maybe
this
will
be
a
useful
thing
to
pursue
in
the
future.
D
That's
really
cool.
I
actually
kind
of
found
a
similar
project
by
paul
villas.
He
wrote
a
systemd
export,
I'm
not
sure.
If
you're
aware
he
actually
has
like
the
united
states
stuff
in
there
and
a
bunch
of
similar
things,
so
it
might
be
worth
sharing
the
effort
in
that
case,
especially
if
you
don't
plan
on
like
maintaining
it
going
forward
or
something
no
yeah
yeah.
I
can
link
you
to
that.
I'm
like
running
this
on
my
local
machine.
Just
for
the
sake
of
having
these
metrics
of
system
b.