►
From YouTube: 2021-06-01 meeting
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).
A
B
A
A
A
C
A
All
right:
well,
I
think
we're
gonna
get
started
sound
good.
A
Okay,
so
did
anyone
have
any
topics
that
they
wanted
to
add?
I
left
some
room
here
for
that.
Okay,
first
of
all,
let's,
let's
start
with
follow
on
topics
and
see
where
things
stand
there.
So
last
last
meeting
we
had
talked
a
bunch
about
how
to
deal
with
stillness
markers.
A
We
have
a
pr
out
to
mark
what
we've
done
is
stable.
A
And
two
important
things
to
call
out
here:
one
is
the
status
of
the
metrics
data
model
is
mixed.
We
have
components
that
are
marked
as
stable
and
then
the
component,
that's
not
marked
as
stable,
is
come
on
load,
is
around
understanding,
gaps,
resets
and
overlap.
A
These
sections
are
all
around
guidance
of
like
what
to
do
given
the
current
data
model
and
we're
not
sure
that
we've
kind
of
nailed
it
to
some
extent.
So
we
had
this
blocking
issue
around
understanding,
staleness
markers
coming
out
of
prometheus
and
understanding
push
based
on
this
marker.
A
So
we
had
a
discussion
last
time
and
we
came
to
an
agreement
that
shoving
nan
into
the
current
data
model
was
not
really
the
direction
we
wanted
to
go
with
the
data
model,
so
instead
there
was
talk
of
having
like
an
integer
like
flag
bit
representation
thing
on
metrics,
where
we
can
flag
different
statuses
for
metrics.
A
For
example,
we
have
an
issue
where
we
want
to
know
whether
dot
a
metric
is
considered
stale,
and
so
whether
or
not
that
metric
has
whether
or
not
its
value
can
be
used
would
be
in
this
bit.
So
you
might
encode
the
value,
as
man
and
you'd
also
have
this
bit.
That
says
hey
this
was
stale.
We
couldn't
actually
grab
the
metric
or
any
kind
of
pool
based
metric
there'd
be
another
bit
usage
here
where
we
had
a
discussion
around
histograms
and
whether
or
not
histograms
allowed
negative
measurements.
A
However,
in
open
telemetry
we
don't
care,
so
we
wanted
to
have
a
bit
so
that
the
prometheus
exporter
could
understand
that
nuance
and
decide
whether
or
not
to
use
the
sum,
but
open
telemetry
could
still
provide
a
sum
right.
Okay,
so
we
had
a
discussion
around
flag
for
stillness
and,
if
I
recall
correctly
victor,
you
had
some
follow-up
stuff
that
you
were
looking
at
here.
Do
you
want
to
give
us
an
update?
Oh
my
gosh.
A
What
just
happened
there
do
you
want
us
give
them
give
us
an
update
of
things
that
you
learned
things
that
what
you're
thinking
kind
of
current
status
yeah,
of
course,.
D
Yeah,
so
I
sorry
as
a
long
weekend,
so
I've
you
know
catching
up,
but
I
did
enter
on
the
chat
I
opened
at
issue,
309
to
start
recording
some
of
my,
I
guess
work
per
se.
So
to
start
off
with,
I
just
did
a
quick
initial
check
with
benchmarking
on.net,
and
I
think
it
just
basically
confirms
a
few
basic
things
that
we
I
tried.
Two
things.
One
is
basically
just
using
a
bunch
of
booleans.
D
D
It's
about
nine
percent
larger
in
binary
size
as
well
right,
and
then
I
also
tried
the
you
know
using
basically
a
32-bit
word
to
basically
do
a
you
know
bit
flag
setting
per
se
boolean
flag
operation,
and
that
is,
you
know,
slightly
slower
because
we're
doing
more
work.
Okay.
So
the
next
couple
of
steps,
I
think,
is
I
need
to
find
out
whether
or
not
there's
a
way
to
if
we
use
the
bit
flag
we're
going
to
have
some
compatibility
issue.
So
I
don't
know
enough
about
protobuf
to
see.
D
Maybe
we
could
somehow
encode
the
existing
thing
that
we
have,
which
is
monotonic
and
just
retain
the
same
key
field
number,
and
maybe
it
will
be
treated
as
a
value,
in
which
case
we
could
convert
it
to
bit
field.
I
don't
know
I'm
just
kind
of
thinking
out
loud
along
that
line
to
see
what
we
could
do
there
and
then
and
then,
of
course,
I
once
we
have
that
I
could
try
and
re-verify
this
on
go,
but
that's
as
far
as
I've
taken
it
at
this
point.
D
A
D
So
right
now
we
have
so
right
now
we're
using
a
boolean
to
say
it's
monotonic
right.
So
if
we
convert
it,
oh.
D
D
The
result
benchmark
that
I
do
here
this
is
actually
for
the
summary
kind,
which
is
the
simplest
that
I
could
get
to
and
in
the
summary
kind
at
the
first
level.
We
have
summary:
we
have
a
you
know
gauge.
We
have
a
histogram
stuff
and
at
that
first
level
we
typically
have
a
bunch
of
like
properties.
That
says
this
particular
kind
is,
is
a
monotonic
or
so
forth,
and
then
there's
a
second
level.
If
you
go
deeper
than
within,
like
the
histogram,
then
for
each
of
those
particular
fields,
then
we
also
have
that
same.
D
You
know
issue
as
well
right,
so
so
at
the
top
level.
So
for
summary,
we
have
currently
a
boolean
for
monotonic.
If
we
wanted
to
quote
convert
that
boolean
to
a
flag,
then
you
know
then
there'll
be
some
compatibility
issue,
for
example.
A
We
were
suggesting
doing
that,
but
I
do
agree
with
you
that
that
does
make
things
inconsistent
yeah.
Let
me
just
grab
the
link
here
for
folks.
So
it
is.
Monotonic
is
right
on
some
yup
like.
E
Go
ahead,
josh,
sorry,
I
I
wasn't
sure
how
to
respond.
I
think
I
I
see
the
the
value
or
the
reason
why
victor
would
suggest
that,
and
I'm
point
tried
to
point
out
in
this
issue.
Yours
is
303
and
then
I
failed
one
in
number
308
about
all
the
sort
of
different
questions
about
not
just
sum,
but
also
count.
This
sort
of
to
me.
It
gets
into
that
question
territory
of
gage
histogram
and,
to
me
I
thought
about
having.
E
Maybe
if
we
changed
something
that
today
is
a
boolean
into
an
integer
like
bit
field,
you
could
you
could
potentially
map
the
zero
value
and
the
one
value
that
we
currently
have
into
bit
fields
that
would
perhaps
be
compatible
it's
possible.
I
think
right
and
then
I
I
sort
of
agree
that
that's
the
right
place
to
put
this
this
thing.
Well,
actually,
I'm
not
sure
about
that,
though.
E
The
point
is
that
we
are
trying
to
represent
when
a
field
is
missing,
so
our
data
data
value
is
missing
and
if
you
put
the
the
field
where
you're
talking
about
josh,
you
go
back
yes,
so
we're
looking
at
message
sum
if,
if
we
were
to
put
this
bit
field
at
the
same
place,
where
is
monotonic
lies
today,
then
we're
going
to
be
forced.
E
We
won't
have
the
way
to
say
one
particular
point
was
missing
and
it
means
that
we'll
have
to
aggregate
together,
just
the
the
man
values
in
one
place
and
all
the
other
points
in
a
different
place.
It's
like
this.
This
field
needs
to
go
in
the
actual
data
point
not
in
this
level,
and
I
don't
know
what
to
call
this
level
in
the
protocol.
A
Yeah
right,
okay,
so
we
should
get
a
name
for
these
at
some
point,
but
this
this
is
not
the
level
yeah.
I
I'd
agree
with
that.
That's
basically
what
I
was
going
to
say
was
these
the
reason
we
wanted
to
use
a
bit
set
was
efficiency
and
the
reason
we
needed
efficiency
was
because
we
wanted
it
down
at
the
number
data
point
specifically.
A
So
this
notion
of
is
monotonic
is
more
about
the
sum
as
a
whole
like
more
about
the
metric
itself
right.
The
notion
of
the
things
we
wanted
to
record
in
the
the
data
set
is
more
about
the
data
point.
I
think
when
it
comes
to
this
stillness
marker.
So
if
you
look
at
metric
data
point
right,
it's
more
about
is
this:
can
you
trust
this
value?
A
A
A
It's
inherent
in
the
metric
right
right
and
I
think
I
think
that's
something
that
if
you
look
at
this
as
a
way
of
denoting
whether
or
not
the
sum
is
non-monotonic
for
a
histogram
point,
I
think
that
you're
right
victor
that
would
belong
up
at
this
level
as
something
inherent
to
the
metric
itself,
right
as
opposed
to
this
flag
that
we
were
talking
about.
One
of
the
reasons
we
liked
using
it
for
both
was
that
you
know
it
it's
flexible.
A
It
allows
different
kinds
of
things
that
we
can
add
to
the
protocol
in
the
future,
but
it
was
also
at
that
point
level.
So
you
could
have
you
know
I
couldn't
find
this
particular
metric,
but
I
did
find
this
particular
metric
like
for
some
reason
in
this
particular
sample
period.
This
set
of
labels
didn't
give
me
a
metric,
but
this
other
set
did
right.
You
could
you
could
encode
that
yep
at
least
two
levels.
A
Yeah,
well
that
one
of
the
ideas
of
using
the
bit
set
is,
if
you're
not
using
it,
to
specify
anything
it
should
call.
It
should
be
free,
but-
or
I
mean,
depending
on
your
language,.
A
A
E
E
We
may
want
bits
to
represent
different
types
of
monotonicity,
let's
say,
and
we
don't
currently
have
that
histogram,
but
we
could-
and
I
think,
there's
actually
two
bits
of
authenticity,
which
is
what
I
said
in
issue
308,
but
that's
totally
separate
from
this
stay
on
this
question
and
whether
there's
a
bit
or
a
field
of
bit
flags
in
the
point
right.
A
Yeah
yeah,
so
let's
divorce
the
two
problems,
then
I
think
I
think
we
can
agree
that
we
shouldn't
solve
them
the
same
mechanism
because
there's
something
that
is
up
here
that
is
kind
of
more
about
the
histogram
metric
itself
and
less
about
the
data
stream
of
the
histogram
right
that
we
want
to
denote
information
about
the
instrument
that
was
used
to
record
the
histograms.
A
A
Whereas
for
the
specific,
like
missing
data
point,
that
is,
that
is
at
this
level
like
inside
of
the
data
point
level,
that
is
for
this
particular
stream,
I'm
missing
a
point
here:
that's
not
inherent
to
the
entire
instrument
being
missing,
it's
literally
at
a
stream
level
or
time
series
level.
I
guess
so.
If
we
split
the
problem
back
in
half,
let's
focus
on
just
the
stillness
marker.
A
D
The
other
option,
you
know
another
option
which
we
probably
don't
do
because
it's
going
to
be
expensive,
is
because
you
have
a
number
right
now
we
have
a
number
data
point,
but
really
a
staleness
is
really
a
kind
of
number,
rather
than
necessarily
a
flag
of
a
particular
number.
So
so
at
a
logical
level,
it's
really
just
one
of
a
kind
of
number
data
point
right,
rather
than
just
a
flagging
of
a
particular
data
point
per
se.
D
D
Okay,
I
think
that's
in
general,
the.
E
A
D
E
B
A
F
E
That
over
time-
and
I
think
bogdan
always
wanted
us
to
keep
it
a
separate
histogram
point-
and
I
felt
maybe
that
was
consistent-
maybe
not
consistent
with
the
you
know
the
use
of
number
data
point
for
both
scalar
valued.
You
know
numbers
and
then
using
separate
point.
Clients
for
histograms
felt,
you
know,
has
to
be
justified
on
its
own,
but
it
does
cost
a
lot
to
have
an
extra
one
of
everywhere
and
it
didn't
seem
like
people
would
truly
be
mixing
these
histograms
and
they
don't
merge
properly.
Yeah.
E
But
that
wasn't
discussed
in
this
pr.
This
was
discussed
gosh.
I
made
a
proto
pr
at
one
point
where
we
discussed
this
yeah.
I
did
propose
a
one
of.
E
Right,
you
end
up
saying
use
it
when
it's
not
present,
but
don't
use
it
if
it's
present,
which
sounds
terrible,
yep
yep.
However,
if
you
had
a
bit
at
the
his
at
the
metric
object
level
to
say
whether
someone's
meaningful
or
not,
then
you
would
care
less
about
whether
the
field
was
present,
except
even.
A
In
even
in
prometheus
right,
the
some
some
doesn't
have
to
exist
like
openmetrics,
allows
histograms
with
negative
measurements.
You
just
can't
fill
out
some
when
you
do
so
yeah,
so
you.
A
You
still
the
issue
of
how
do
you
denote
that
something
didn't
exist
right
like
we
have
two
issues
with
histogram,
which
is
one
is
we
need
to
know
whether
or
not
we
can
export
this
value
to
open,
metrics,
yes
or
no
right,
and
then
the
second
thing
is
we
need
to
know
if,
for
this
particular
string
label,
if
we
had
a
value
when
we
last
scraped
or
if
we're
just
reporting
that
time
series
and
saying
we
couldn't
find
the
metric
right,
so
we
have
both
of
those
bits
we
need
to
somehow
denote
here
or
or
within
this
hierarchy
of
this
histogram
right.
E
Does
anyone
disagree
with
that?
I
think
you
meant
at
the
point
level
with
the
last
sentence
you
said
notion
of
present
or
not
present
is
at
the
point
level.
The
point
level
yes
and
like
monotonicity
or
presence
of
some
is
at
the
metric
level
instrument
level
effectively,
and
there
is
no
time
series
level
sure.
E
Resource
attributes
span
attributes
metric
attributes,
but
this
point
property
of
being
present
or
not
could
be
just
another
attribute
and
if
we
start
giving
special
interpret
interpretive
rules
for
attributes,
we
might
then
have
some
built-in
attributes
to
say
this
point
was
a
was
not
present
and
then
to
convert
to
prometheus.
You
just
make
a
nand
value,
so
the.
A
Downside
to
that
I
mean
that
I
I
like
it
actually
as
a
workaround.
The
the
problem
we
have
is
so
that
would
localize
the
solution
to
missing
values,
to
basically
inside
of
a
collector
or
inside
of
an
sdk
and
that's
fine,
but
the
when
we
talk
about
metric
stream,
identity,
you're,
basically
changing
the
identity
of
the
metric
stream
by
adding
that
label
because
of
how
we
defined
identity.
E
Yeah,
so
that
that
breaks
the
identity
rules
in
a
way
that
would
be
extremely
awful.
So
that's
why
I
said
it.
I
do
think
that
there
will
be
other
opportunities
in
hotel
for
us
to
just
use
more
attributes
that
have
meaning,
but
I
think
this
is
not
one
of
those
cases
for
the
reason
in
case
these
are
the
reasons
you
just
said.
A
Well,
it
might
be,
it
might
be
in
the
collector
like
that,
could
be
how
we
specify
the
prometheus
collector
to
deal
with
stimulus
coming
from
prometheus
and
we
don't
handle
staleness
in
the
specification.
I'm
not
super
comfortable
with
that
solution.
Long
term,
like
I
think
we
should
probably
address
stillness
eventually,
but
that
could
be
like
for
now
hey
prometheus
people
when
you
need
to
address
stillness,
here's
what
we
recommend,
here's
a
way
that
will
work
within
the
collector,
and
we
can
guarantee
that
this
is
fine
within
process
right.
E
Yeah,
I
think
that's
a
good
answer.
You
know
it
might
be
that
we
should
step
back
a
little
bit
and
think
about
what's
actually
trying
what
we're
actually
trying
to
do
here
and
whether
we
need
a
nand
value
in
every
one
of
those
series
or
whether
you're
truly
trying
to
convey
that
like
an
entire
target
went
missing
and
at
some
level
we
could
create
new
point
kinds
to
express
missing
identities,
missing
points,
and
I
don't
think
that's
what
the
user
actually
wants
to
see
like
do.
E
Resource
is
not
not
present,
then
all
of
its
metrics
are
somehow
maybe
I
mean
I
guess
I
guess
I'm
trying
to
say.
We've
spent
a
lot
of
time
talking
about
how
to
put
not
a
number
into
time
series
and
what
what
is
actually
happening
is
not
that
what
we're
really
trying
to
do
is
mark
a
whole
bunch
of
serious
as
as
as
not
present,
and
I
I
feel
like
every
time
I
go
down
the
avenue
of
thinking
about
a
way.
E
To
put
this
into
a
point,
I
find
myself
building
in
a
lot
of
extra
structure
when
what
I
really
really
just
want
to
do
is
say
in
this
time
range.
This
resource
was
not
a
number.
This
and,
and
there's
problem
is
that
the
time
range
is
all
the
way
down
in
the
point,
and
so
I
need
a
way
to
say
time,
range
and
resource
without
talking
about
points
here.
E
A
Yeah,
I
agree
with
that.
I
also
want
to
call
out,
though,
that
remembering
what
labels
and
streams
you've
seen
so
far
is
not
something
you
want
to
push
on
the
consumer
necessarily
right,
because
whoever
is
producing
these
metrics
whoever's
doing
the
scraping
is
the
one
who's
like.
I
know
what
metrics
I
saw
last
time
that
I
expect
this
time
and
I
can
tell
you
here's
all
the
metrics
that
I
expected
to
see
and
I
didn't
see
them.
That's
that's
like
the
the
mechanism,
we're
modeling
from
prometheus
here
right.
A
So
someone
knows
these
metric
labels
from
a
protocol
standpoint.
If
I,
if
I
report
at
just
a
resource
level,
that
means
I'm
forcing
a
stateful
understanding
between
two,
you
know
the
person
generating
the
metrics
and
the
person
consuming
them
of
you
have
to
know
what
metrics
my
resource
was
producing.
So
when
I
send
you
a
stillness
marker
and
a
resource
level,
you
can
then
consume
that.
A
So
I
don't
think
I
don't
think
we
necessarily
want
to
encode
that
I
think
like
if
we
get
laser
focused
on
the
prometheus
use
case
of
stillness
markers
and
we
we
take
that
abstract
view
of.
Does
open
telemetry
killer
care
about
stainless
markers
well
from
a
push-based
model?
I
think
our
consensus
before
was
this
is
something
that
you
should
be
able
to
detect
in
your
back
end
based
on
time
series.
The
prometheus
thing
is
the
thing
that
we
want
to
try
to
solve
here
it
I.
A
I
don't
think
we
want
to
reinvent
how
prometheus
encodes
staleness.
I
think
we
just
want
to
find
a
way
to
take
what
they
do
and
put
it
within
our
protocol.
So
if
you
have
prometheus
on
one
end
and
prometheus
on
the
other,
it
works,
I
don't
think
we
want
to
go
kind
of
much
further
past
that
and
to
your
label.
Suggestion
like
to
the
extent
that
we
don't
need
to
add
a
bunch
of
contortions
to
our
protocol.
To
do
this.
I
think
that's
a
good
idea.
D
So
so
what
so,
at
least
in
my
experience
in
the
past,
you
know
systems
we
keep
the
keep
alive
or
stay
on
this
market
as
a
separate
metric.
What's
the
downside
of
that?
Besides,
you
know,
you
have
a
separate
metric
per
se
and
usually
that
metric
is
at
the
in
our
case,
our
agent
level,
which
is
just
for
the
whole
resource
level
rather
than
each
individual
metric
is
there
you
know
I
could
see.
Potentially
certain
metrics
may
not
follow
the
whole.
A
So
what
it,
what
I
just
tried
to
say
is:
I
think
that,
like
we
can
rethink
how
we
want
to
do
this
in
open
telemetry,
that's
fine
and
it's
fine
to
have
those
discussions
and
like
open
telemetry
could
do
something
better,
but
I
want
to
stay
laser
focused
on
we're
talking
about
how
prometheus
does
things
today
and
we're
talking
about
how
do
we
encode
stillness
markers
from
prometheus
end
to
end?
A
So
from
that
standpoint,
I
think
we
have
to
be
laser
focused
of
can
we
encode
these
end
to
end
or
not,
and
the
whole
like?
How
does
open
telemetry
denote
staleness?
I
think
we
can
probably
do
something
different
that
we
like
better,
but
we
can't
ignore
the
fact
that
we
do
need
to
solve
this
specific
problem.
So
there's
the
laser-focused.
How
do
I
model
prometheus
and
then
there's
the
abstract?
How
should
open
telemetry
deal
with
stillness?
They
don't
have
to
be
the
same
answer,
but
when
we
talk
about
like
oh,
let's
do
this
resource
thing.
A
I
think
we
we
might
be
throwing
out
the
use
case
that
led
to
this
like.
Why
do
I
care
about
stillness
right.
D
I
mean
I,
I
think
that
maybe
not
necessarily
for
histogram
for
for
the
number.
You
know
for
the
number
data
points
I
mean
instead
of
nand,
you
could
just
those
one-off
values
are
optional,
so
you
know
we
could
just
say
a
special
case
where
you
have
a
data
point,
but
no
value
rather
than
a
nand
rather
than
a
flag.
You
know,
but
they
all
denote
the
same
thing
still.
A
B
A
If
maybe
you
didn't
have
traffic
that
generated
that
metric.
If
it's
a
synchronous
instrument
based
on
whether
or
not
the
resource
was
there
or
not
right,
so
a
metric
disappearing
doesn't
necessarily
doesn't
correlate
with
the
resource
being
down
right
depending
on
the
metric,
especially
for
push-based
metrics.
A
In
any
case.
So
if
we
stay
laser
focused
on
this
prometheus
thing,
I
think
what
we
want
to
do
going
forward.
I'm
gonna
throw
out
a
proposal.
Tell
me
what
you
think
here.
My
proposal
would
be
that
we
figure
out
a
place
on
histogram
to
denote
the
absence
of
a
metric.
A
I
don't
care
what
it
is.
It
could
be
a
bit
set,
it
could
be
a
boolean,
but
we
make
a
proposal
for
how
to
denote
it
in
histogram
for
number
data
point.
We
also
make
a
proposal
for
how
we
support
it
and
it
could
just
be.
You
know
that
we
add
a
new
value
to
the
one
of
it
could
be
that
we
fill
out
man
here
doesn't
matter.
A
The
real
problem
is
we
didn't
know
how
to
do
it
in
histogram.
So
let's
make
a
proposal
for
how
we
want
to
do
a
histogram
we'll
take
whatever
we
decide
on
for
histogram
and
make
it
similar
in
number
data
point
we'll
make
sure
that
that
thing's
backwards
compatible
and
then
we'll
call
the
first
step
of
stillness
like
the
most
important,
immediate,
pressing
value
of
you
know
our.
A
Can
we
encode
prometheus
stillness
done
and
we
can
have
a
more
meta
discussion
on
how
we
deal
with
stillness
and
open
telemetry
going
forward
in
in
kind
of
a
better.
You
know,
broader
time
horizon
with
more
time
to
kind
of
walk
through
specifics.
You
know,
like
I
really
like
the
things
I'm
hearing
around
resource
based
up
down
all
that
kind
of
junk,
that's
cool,
but
very
specifically
for
prometheus
right.
How
do
they
import
histograms?
A
Let's
just
let's
solve
that
right
now,
so
my
proposal
would
be
we
put
either
a
boolean
or
a
bit
set
on
to
histogram
data
point,
and
we
toy
around
with
that
notion
and
kind
of
get
people
to
comment
pros
and
cons,
because
I
just
don't
see
any
other
place
on
histogram
where
we
can
denote
this
information.
B
Use
case
to
start
add
acceptance.
A
A
To
address
backwards
impact
concerns,
so
this
is
the
thing
so
so
follow
on
work.
There
would
be.
We
have
to
address
these
backward
compatibility
concerns
of
if
we
add
this
boolean
field
right
and
I'm
a
consumer
of
otlp
metrics-
and
I
don't
know
the
boolean
field
exists.
A
A
I
think
we
just
need
to
specify
like
here's,
what
the
new
metric
will
look
like
and
here's
how,
if
you
have
the
old
version
of
the
protocol
buffer,
this
thing
will
be
consumed
and
dealt
with
and
agree
that,
like
we
think
this
is
acceptable.
We
think
this
is
okay.
We
think
this
is
not
going
to
cause
any
problems
that
didn't
already
exist.
A
Cool
okay,
so
that
sounds
like
that
sounds
like
a
good
path
forward
for
this
we're
limiting
the
problem,
we're
focusing
the
problem.
There
is
still
this
issue
of
the
the
second
problem
that
we
didn't
talk
about,
and
I
want
to
kick
this
discussion
to
later,
because
we
spent
40
minutes
on
this.
If
that's
okay,
second
problem.
B
No
proposal
yet
is
how
to
identify
information
intrinsic
to
a
metric,
for
example,.
A
Okay,
so
the
second
problem-
I
think,
maybe
we
can-
we
can
discuss
this
a
little
bit
more
next
time
this
one.
I
think
that
we
have
enough.
We
can
actually
start
discussing
in
pull
requests
in
the
future.
This
one,
I
think,
maybe
we
need
to
chat
more
about
next
week.
Anyone
anyone
disagree.
Anyone
have
other
thoughts,
opinions,
ideas.
D
Yeah
so
quick
question,
so
the
one-off
stuff,
how
harshly
should
we,
you
know,
really
avoid
the
one-off,
because
I
mean
in
my
mind
I
could
think
of
you
know
it's
just
a
different
kind.
If
you
had
a
one-off,
it
may
potentially
solve
the
issue
easily.
You
know,
but.
A
So
so
I
would
avoid
the
one
of
at
the
lowest
level,
so
we
have
a
one-off
at
the
metric
point
level
right
now.
We
do
and
I
think
that
one's
that
one's
kind
of
not
at
the
metric
point
level.
Sorry
we
have
one
at
the
metric
level
and
then
there's
a
one
of
in
the
metric
point
level
for
number
data
kind.
A
I
really
don't
think
we
want
to
add
more
to
number
data
kind,
because
I
think
that's
where
we
pay
the
most
performance
cost.
But
if
you
add
a
one
of
and
you
write
a
performance
evaluation
and
you
show
that
it's
not
significant,
then
I
think
that's
fine,
like
in
terms
of
avoiding
one
of
it's
more.
When
we
see
a
one
of
we
know
to
investigate
performance,
yep.
D
E
D
A
A
Yeah
or
like
the
exponential
bucket
histogram
right
out
there
right
it's
more
intrinsic
to
the
histogram
itself,
as
opposed
to
like
at
the
data
point
level,
just
because
we
know
once
you
get
down
that
that
you
know
the
amount
of
duplication
and
repeated
work
at
that
data
point
level
is,
is
somewhat
significant,
so
we
want
to
keep
those
optimized.
There
is
a
proposal
for
columnar
data
from
the
I
don't
know.
A
If
I
need
to
dive
into
that,
I
guess
I
can,
because
I
might
be
using
jargon
from
the
multivariate
time
series
folk,
they're
working
on
this
notion,
where
you
would
actually
denote
kind
of
labels
and
then
you'd
have
like
different
metric
values
underneath
that
group
of
labels-
and
this
would
be
kind
of
an
alternative
api
to
what
we
have
so
you
could
either
use
you
know
row
based
data
or
column-based
data,
and
maybe
they
both
interact
in
fun,
good
ways.
A
A
Okay,
I
don't
know
if
that
was
useful
at
all,
but
real,
quick
before
the
before
I'd
like
to
I'd
like
to
move
on.
So,
let's,
let's
next
time,
we'll
discuss
some
more
how
to
identify
intrinsic
information
specifically
around
this
non-monotonic
sum.
Let's
see
if
we
can
resolve
this
problem,
you
know
for
now
I
think
we're
in
an
okay
state
and
I
look
forward
to
prs
and
things
victor.
You
still
are
owning
driving
this
forward
right,
okay,
good,
good
good!
A
I
want
to
talk
a
little
bit
about
a
new
and
state
set
in
prometheus
and
how
we
might
think
about
modeling
this.
So
I've
only
done
a
little
bit
of
investigation
and
kind
of
understanding,
but
openmetrics
state
set
defines
a
way
of
encoding
enumeration
metrics.
Okay.
So
if
you
look
at
this,
I
think
this
is
going
to
take
us
to
it.
A
state
set
is
a
series
of
related
boolean
values
or
a
bit
set
like
we
were
talking
about
with
these
integers.
A
So
the
way
the
way
in
a
new
is
encoded.
You
have
a
state
and
then
a
boolean
value
per
state.
So
your
state
is
basically
like
a
label
or
a
set
of
labels
and
then
like
a
true
false
value
for
that
label.
A
A
If
the
code
states
that
enums
must
have
exactly
one
boolean,
which
is
true
within
a
metric
okay,
so
the
state
set
could
be,
let
me
think
of
some
examples.
A
I'm
actually
really
having
trouble
thinking
of
a
good
real
world
example
for
this.
Besides,
I
know
openmetrics
has
this.
Anyone
know
of
a
good
state
set
that
they've
used
where
you
have
a
bunch
of
true
false
values.
Coming.
A
D
I
mean
I
don't
know
whether
this
is
right
or
not,
but
I
would
imagine
you
know
thinking
about
it.
It's
like,
if
you're
trying
to
provide
a
metric
for
let's
say
http
error,
you
know
like
404s
and
you
know
200,
then
you
know
each
of
these
numbers
is
not
a
number,
but
it's
a
state.
That's
you
know
you
have
404
is
true
versus
200
is
true.
I
don't
know
if
that's
what
this
is,
but.
A
Yeah
I
mean
you,
could
you
could
do
that,
but
that's
that's
you'd,
probably
record
like
a
count
of
the
number
of
404s
right.
This
is
like
I.
I
have
a
gauge
kind
of
a
thing
where
I'm
recording
it
a
state
set
at
at
given
points
in
time.
So
it'd
be
like
you
know,
my
service
is
on
true
or
false.
The
this
is
yeah,
I'm
I'm
literally
having
trouble
thinking
through
good,
real
world
examples.
I've.
E
Always
just
used
a
gauge
with
value
one
or
zero
for
this
application.
I
have
one
in
the
prometheus
sidecar,
where
I'm
just
reporting,
which
metrics
are
failing,
so
the
state
is
actually
the
the
name
of
a
metric,
and
I
prefer
that
we
model
this
sort
of
thing
by
by,
as
you
say,
having
a
set
of
counters.
E
So
the
boolean
is
true
when
the
count
is
non-zero
and
then
the
way
I
would
prefer
that
we
model
this
type
of
data.
Is
you
have
a
set
of
metrics
which
have
their
own
distinct
label?
Sets
the
labels
are
the
things
that
we
have
called
attributes
and
the
values
are
just
one
or
zero,
so
that
you
know,
rather
than
having
a
new
data
type
here,
just
have
a
collection
of
metrics
and
distinguish
them
by
attributes.
A
A
When
I
encoded
the
new
values
in
metrics,
it
was
I
I
would
actually
kind
of
sum
them
together
like
how
many
of
this
particular
thing
that
I
get
so
I
always
use
counts
of
labels,
as
opposed
to
you
know
a
particular
new.
A
So
the
only
I
I
agree
with
you,
that's
one
way
to
encode
it
into
open
telemetry.
We
just
also
need
the
way
to
get
it
out
of
open
telemetry
back
into
state
set
if
we
want
one
to
one,
but
maybe
that's
something
we
just
push
on
the
prometheus
working
group
and
say
you
know
you.
Let
us
know
how
you'd
like
this
to
happen.
We
think
that
for
open
telemetry
these
should
all
be
exported
as
gauges
of
one
or
zero.
E
Is
there
ever
an
instrument
that
anyone
has
for
entering
this
information,
because
this
may
fall
into
the
gauge
histogram
category
of
data
types
that
you
compute
in
functional
form
and
then
the
function
that
computes?
That
data
point
can
say
that
it
should
be
a
state
set
so
that
maybe
there's
somewhere
in
our
processor
pipeline?
Where
we're
computing
information
and
we
still
need
some
sort
of
hint
or
like
metadata
to
say
that
this
belongs
in
an
open,
metrics
state
set.
And
I
don't
know
how
to
answer
your
question.
E
A
A
Yeah,
it's
it's
more,
so
open,
metrics
define
state
set
and
how
to
export
them,
but
you're
right
around
instruments
like
if
you
look
at
a
state
set,
and
you
look
at
a
a
gauge
you,
you
almost
get
the
same,
look
and
feel
for
the
two
you
know
like
there's,
hardly
any
difference
between
a
gauge
that
reports
one
and
zero
and
a
state
set.
A
Besides
the
fact
that
you
have
more
metrics
kind
of
grouped
together
in
a
state
set
likely
and
there
could
be
back-end
implications
for
it,
but
maybe
it's
just
too
new
to
figure
out
how
to
deal
with.
I
guess
from
from
my
question
is:
if
we
don't
model
state
set
at
all,
and
we
just
say
you
have
gauges
and
your
gauges
can
be.
You
know
one
zero
values
have
we
lost
anything
in
open,
telemetry
right
if
we
take
state
sets
and
turn
them
into
gauges,.
D
A
Yeah
and
like
the
other,
the
other
usage
for
state,
so
you
mentioned,
like
various
things
of
state,
I'm
also
thinking
of
like
cube,
state
metrics
and
like
the
state
of
your
system
and
having
like
in
a
new
of
like
I'm,
on
right
now
or
I'm
off
right
now,
right,
that's
like
a
thing
you
can
do
so
you
can
also
say
you
know,
like
this
version
of
the
system
is,
is
using
the
my
prod
layout.
A
This
one
is
using
my
you
know
this,
this
I'm
thinking
of
spring
sorry,
but
you
know
how
you
can
have
like
different
profiles
of
like
I'm
running
in
this
particular
profile
or
that
particular
profile
and
then
injects
different
surfaces.
Based
on
that,
you
can
actually
have
a
metric.
That
tells
you
you
know
this
service
at
this
particular
thing
is
running
this
profile
and
you
can
check
like
configuration,
rollouts
and
stuff.
A
So
from
an
enum
standpoint,
I
would
have
I'm
using
this
version
of
my
config
right
and
if
I
have
the
ability
to
push
config
live
into
different
services.
A
I
can
say
this
particular
service
is
using
this
version
of
this
config,
because
this
new
value
of
the
version
the
config,
is
set
to
one
and
then,
when
I
look
at
the
metrics,
I
actually
look
at
that
that
that
attribute
of
the
config
version-
and
I
can
actually
like
render
like
when
rollouts
of
new
config
go
out
to
the
fleet
or
I
could
have
versions
of
binaries
right.
I
can
actually
the
metric
reports.
This
version
is
on
this
version
is
off
so
that's
kind
of
like
that.
A
That's
the
idea
behind
a
state
right
like
it's,
it's
it's
it's
one
or
zero.
I'm
reporting,
like
you
know
which,
which
pieces
of
my
fleet
are
using,
which
version
I
can
track
version
rollouts.
I
can
track
cubes
like
I
keep
saying
cube
state,
but
you
know
what
I
mean
like
I
can
track.
What's
out
there
state
wise
it's
it's
more
static
right.
I
have
a
question
about.
E
This
josh
so
I've.
I
remember
various
people
defending
this
idea
of
an
enum
or
state
set
who
are
not
in
the
meeting
and
I'm
trying
to
remember
what
they
all
said.
And
there
was
this
question
about
whether
there's
such
a
thing
as
a
string,
valued
metric-
and
I
think
you're,
just
kind
of
touching
on
that
right
now,
which
is
to
say
that
it
seems
like
what
people
are
asking
for
is
a
way
to
say.
E
I
have
a
metric
whose
value
is
a
string,
because
I
also
have
other
metrics
that
are
correlated,
and
I
want
to
choose
a
label
value
or
an
attribute
value
equal
to
this
string
value,
which
was
in
a
metric
at
a
time
in
order
to
look
up
a
series
of
information
somewhere
else
in
a
correlated
way.
So
we
almost
want
to
say,
there's
a
value
here,
that's
a
string
and
and
recommend
you
to
join
it
with
an
attribute
value
of
some
other
metrics.
A
That
in
our
model,
right
now
and
to
me
to
me
the
best
use
case
is:
I
want
to
track
rollouts
of
versions.
In
fact,
here's
a
fun
example
like
you
know
how
we
have
instrumentation
library
version
and
open
telemetry.
A
Can
I
track
what
versions
of
what
instrumentation
libraries
are
I'm
using?
So
I
can
see
if
something's,
stale
and
kind
of
check
my
my
deprecation
risk.
You
know
across
my
infrastructure
you
know
do.
Can
I
see
these
things?
Can
I
watch
one
of
them
go
up
and
one
of
them
go
down
like
that's.
That's
the
use
case
that
I
think
state
sets
are
meant
to
solve,
and,
yes,
we
can
encode
all
this
as
gauge
and
I
think
we're
actually
fine.
You
can
do
that
today.
With
all
of
these
things.
A
The
user
needs
to
decide
on
the
aggregation.
I
don't
I
actually
don't
want
these
things
aggregated.
I
don't
want
you
to
be
able
to
easily
remove
a
label
and
say:
oh
yeah.
I
can
remove
this
label,
and
this
is
fine
because
you
can't
right
like
these
are.
These
are
like
specific,
state-based
information
around
a
particular
resource.
It's
not
like
they
shouldn't
aggregate.
I
think
gauge
is
the
right
thing
here
like
if
the
user
aggregates
they
need
to
decide
what
that
means.
C
E
D
D
A
Yeah
yeah
yeah,
okay,
okay.
Unfortunately,
we
only
have
two
minutes
left,
so
I
am
gonna
have
to
cut
it
there.
Sorry,
I
actually
just
noticed
the
time,
because
I
got
too
engrossed
in
the
conversation,
that's
bad
when
the
person
is
supposed
to
pay
there's
a
time
that
doesn't
so,
I
feel
like
we
kicked
off
this
discussion.
I
want
to
talk
about
next
steps.
A
I
think
we
we
have
next
steps
for
next
meeting
to
kind
of
talk
about
this
non-monotonic
sum
and
histogram
thing
a
little
bit
see
if
we
can
make
a
little
bit
of
progress
there.
I
think
we're
going
to
follow
up
with
this
particular
thing
in
pool
requests.
We
already
stated
that
in
terms
of
the
newman
state
set,
do
we
have
follow-up
activity?
We
want
to
work
with
here.
I
think
we
had
a
really
good
discussion,
understanding
the
problem,
understanding
the
concept.
A
I'm
going
to
throw
out
there
that
I
think
encoding
these
things
as
gauges
for
now
actually
probably
is
okay
in
the
near
term,
and
there's
no
hurry
to
address
this.
I
just
wanted
to
have
some
consensus
and
understanding
of
if,
if
we
get
pushed
on,
if
the
prometheus
working
group
asks
about
state
sets,
what's
going
to
be
our
answer
for
now
right,
I
feel
like
we
could
give
a
decent
answer
that
we
might
all
align
on.
E
I
agree
with
you
on
gage
josh.
I
I
wanted
to
clarify
that
again.
The
the
up
down
thing
that
I'm
talking
about
in
this
count
in
this
context
is
a
count
of
how
many
gauges
there
are,
and
this
all
makes
sense
to
me,
but
I
don't
think
we
should
talk
about
it
right
now.
A
Okay,
so
so
this
is
not
next
steps.
Is
there
anything
else
on
the
docket
and
agenda
that
we
should
prep
for
discussing
next
time
as
an
fyi?
We
have
a
bunch
of
things
we
can
actually
talk
through
with
histograms.
You
know
we're
dealing
with
some
to
have
negative
measurements.
A
A
I
don't
think
we've
dove
into
kind
of
exemplars
too
much
here,
but
that's
an
area
that
might
be
worth
diving
into
and
yeah
we
just
did
a
newman
state
set.
So
there's
also
this
notion
of
raw
aggregation
that
I
think
victor
brought
up
that
we
want
to
talk
through
at
some
point
and
gage
histogram,
so
those
are
kind
of
like
big
things
to
discuss.
A
A
B
D
A
All
right
that
sounds
that
sounds
great
look
forward
to
talking
to
all
of
you
next
week.
Sorry,
it
ran
a
little
long
thanks
again
thanks
everybody.