►
From YouTube: 2021-10-20 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
Hi
vishwa,
how
are
you
doing
hi
grace.
A
All
right,
I
think
I
think
we
can
probably
wait
for
another
30
seconds
and
get
started,
because
we
have
some
updates,
must
fan
and
parish.
Were
you
guys
going
to
walk
through
your
findings
and
questions
so
far
on
the
prometheus
receiver
tests.
A
I
think
muslin
you
might
be
on
mute.
A
Yeah,
let's
get
started
because
again
we
have
vishwa
and
grace
so.
B
Your
screen
is
visible,
yes,
okay,
so
basically
in
our
let's
just
one
second
yeah.
So
basically
what
we
have
here
so
in
our
current
receiver
test.
So
we
are
running
three
targets
so
target
one
target,
two
target
three,
as
shown
here
in
this
excel
and
in
this
target
we
have
code
500
in
between,
so
we
are
expecting
that
we
will
get
stale
scrape.
So
now
we
have
a
question
like
myself
and
mustafa.
B
We
worked
on
this
like
to
get
the
timestamps,
because
we
wanted
to
verify
like
what
the
time
systems
would
be
after
a
steel
script
is
generated.
So
here
we
have
the
results.
So
our
test,
current
tests
are
failing
at
target
one
script,
two
so
target
one
has
like
five
matrix
gauge
pointer,
histogram
and
summary,
and
then
the
stale
scrape
is
generated.
So
in
the
first
target
one
is
scrape
one.
B
We
have
the
timestamp
generator
667,
which
is
the
starts
timestamp
and
it's
equal
to
the
point
timestamp
in
the
still
script
we
have
the
timestamp
which
defers
like
in
counter.
The
start
stamp
is
667
and
in
summary,
the
start
stamp
is
668
and
a
histogram
is
missing
from
this
scale
script,
and
there
is
one
more
thing
which
I
wanted
to
highlight
like
for
the
values
of
summary.
B
For
some,
it's
not
coming
up
as
nan
it's
coming
as
an
empty
so
and
in
the
code
it
assumes
that
it's
zero
so
and
for
target
one
script.
Two.
We
have
the
timestamps
for
counter
six
six
seven
for
histogram,
because
I
think
the
script
wasn't
generated.
So
it's
taking
the
start,
timestamp
from
the
first
script
itself
and
for
scrape
2,
because
the
scrape
was
generated
it
didn't
take.
B
The
timestamp
starts
timestamp
of
a
new
timestamp
it
it
took
the
timestamp
from
the
still
script,
so
just
wanted
to
confirm
like
if
this
behavior
is
what
it
is
like
expected
or
like,
or
the
the
that
should
be
based
on
this
behavior
or
so
just
wanted
to
confirm.
In
this
regards.
A
Yeah
it
doesn't
it
doesn't.
I
mean
at
least
from
the
definition
of
an
m
that
doesn't
look
right.
D
D
D
C
Yeah
yeah,
we
were
a
bit
confused
with
like
when
we
have
a
stale
script.
So
subsequent
scripts
should
should
they
have
a
new
start
timestamp
for
the
series,
or
should
they
be
what
the
timestamp
was
for
the
series
before
the
stale.
E
B
You
said
what
you're
actually
saying
so
the
stale
scrape
is
something
like
it
has
up
value
of
zero
and
all
the
values
of
gauss
counter
histogram
and
summary
that
are
none,
but
in
some
cases
in
some
tests,
the
histogram
and
summary
value.
They
don't
come
as
nan
like
in
this
case.
Histogram
is
missing.
Somebody
comes
at
like
null
value,
but
other
values
like
count.
They
are
com.
It's
a
n64
value,
it's
coming
as
like
minimum
int,
which
is
like
minus
2
power
63.
B
D
B
Okay
make
sense
yeah,
because
we
have
this.
We
have
this
code
500,
where
we
are
reading
null
pay
another
state
so
yeah
it
should
create
a
failed
script,
so
make
sense.
D
Yeah
yeah
and
then
it
should
be
so
I
know
that
you're
tracking
stillness
differently
in
open
telemetry,
like
just
a
separate
bit
for
it,
but
yeah
like
this,
shall
be
consistent
as
well
across
the
types
because
it
looks
like
right
now
that
only
histogram
is
kind
of
handling
it
correctly,
and
only
then
on
the
first
failed
script.
D
B
Yeah
because
it
also
generates
one
more
film
script
after
after
after
the
script
two
and
it
could
be
because
it's
I
I
don't
understand
like
why
it
is
generating
one
more
failed
scrape
here.
It
could
be
because
we
are
like
we
are
not
feeding
it
any
more
pages.
So
is
that
why?
But
in
this
one,
so
we
have
all
three
values
like
we
have
six
we
have
for
counter.
We
have
for
histogram
and
for
summary,
as
well.
B
Like
which
timestamp
is
it
I
believe
it's
the
timestamp?
It
it
scraped
the
the
metrics.
D
Okay,
so
it's
the
ingested
time
stamp.
In
that
case,
it
should
be
the
same
as
the
scrape
time.
So,
in
which
case
the
question
is.
Why
is
the
counter
on
the
second
field
scrape
going
667
rather
than
670,
because
it
should
be
six
seven
zero
and
at
least
in
prometheus
terms,
it
will
be
a
stale
man
in
open
telemetry
you'll
be
setting
the
haters
to
steal
this.
D
D
This
is
why
I'm
asking
like
is
this
meant
to
be
the
creation
time
of
the
counter,
in
which
case
it
should
not
be
the
same
as
when
it's
scraped,
except
in
you,
know
rare
cases
or
like
I'm
just
confused
as
to
why
this
is
updating,
because
I
don't
understand
the
semantics.
This
number
is
meant
to
have,
because
this
this
here
isn't
consistent
at
all.
C
C
Yeah
from
what
we
understood
from
the
semantics
like
technically
the
series
time
stamps
should
be
cached
from
the
first
script.
So,
like
the
first
time,
you
encounter
a
metric
for
for
any
series
that
timestamp
should
be
used
for
all
for
the
series
that
timestamp
should
be
consistent
and
then
for
the
point
timestamps.
They
should
be
whatever
the
timestamp
for
the
current
script
was.
B
A
spot
it
says,
on
the
design,
dot
md,
where
they
have
explained
about
the
metrics.
A
A
C
B
D
D
B
D
B
Yeah,
so
that
happens,
but
it's
not
happening
for
like
it's
not
happening
for,
let's
say
for
histogram
sometimes
and
for
somebody
sometimes
it
comes
as
nan.
Some
values
comes
at
nam.
Sometimes
it
doesn't.
So
that's.
D
F
So
so
you
guys
are
seeing
the
start.
Time
is
the
one
that
is
problematic
right.
B
Yeah
the
start
time
stamp
is
the
problem.
The
points
time
point
time
stamp
is
it
comes
all
right.
It
seems
it's
consistent
across
all
the
test
cases.
Okay,.
B
Oh,
this
one
does
show
nan
values
well
like
in
these
ones.
The
the
value
of
the
metric
is
not.
I
can
show
you
this
one.
D
B
Yeah,
so,
okay,
this
is
okay,
so
this
metric
is
not.
B
Yeah,
so
this
is
the
failed
scrape
that
is
getting
generated.
So
in
this
one,
the
metric
descriptor,
the
name
of
the
metric,
go
threads,
which
is
a
gauge
metric.
The
value
compared
nan.
The
timestamp
is
the
point
timestamp,
which
is
the
yes.
D
D
F
B
F
C
But
the
summary
value
isn't
a
nan
in
this
case
so
like
the
count
is
like
the
negative
initialized
to
the
negative
value.
B
G
B
Count
this
like
max
a
negative
value
like
min
into
64.
and
sum
is
null,
and
then
we
have
a
counter
value
over
here
in
counter
we
have
nan
and
then
again
we
have
one
more
counter
value,
because
we
have
two
values
in
this
one.
This
is
also
none,
but
we
don't
have
its
missing
histogram
in
this
one,
and
the
up
value
is
zeros
yeah.
C
Just
a
quick
question
regarding
the
summary:
what
should
we
expect
for
the
summary
values
in
case
of
a
still
stillness?
Should
it
be
a
nan,
or
should
it
be,
then,
in
64
min
in
64
value.
D
D
Cool
so
anything
else
that
you're
wondering
about
or
want
to
ask
the
group.
B
No,
this
was
the
question
which,
like
the
current
test,
actually
it's
just
failing
at
these
two
values
which
is
like
when
it
goes
to
assert
certain
timestamp
so
yeah.
Just
because
I
couldn't
see
the
consensus
consistency
so
just
wanted
to
find
like
what's
the
yeah.
A
F
Also,
the
the
last
column,
the
j
column
that
we
have
selected
now,
the
seven
zero
should
also
last
two
yeah,
those
two,
the
one
on
the
below
that.
D
We
do
actually
have
that
note
metrics.
So
if
you
have
a
created
sample
which
exists
for
well
counters
summaries
and
histograms,
you
can
pull
it
from
that.
However,
not
everything
has
it.
D
But
yeah
like
openmetrics.
Has
it
because,
well
be
honest,
basically
open
telemetry
monitors,
it's
gonna
be
a
short
version
and
hopefully
for
me
you
should
be
able
to
take
advantage
of
it
at
some
point,
but
largely
it's
there,
because
you
know
you
have
a
use
for
it.
A
That's
helpful:
that's
helpful,
bran,
hey
porous,
which
version
of
the
we
were
doing
version
36
right
of
the
collector,
it's
the
latest.
I
know
37.
A
Okay,
any
other
questions
you
had
in
terms
of
the
behavior
again
just
wanted
to
better
understand.
F
No
looks
looks
like
this
time.
It's
the
start
time
it's
yeah.
D
A
A
B
There's
just
one
more
question
regarding
the
failed
scrape,
so
what's
the
like.
So
in
this
logic,
what
we
are
just
I'll
share,
one
link,
because
in
our
logic,
we
need
to
actually
filter
out
the
failed
scripts,
because
so
in
this
one
currently
like
the
the
way,
the
logic
is
that
we
are
looking
for
the
up
metric.
If
the
up
metric
is
zero,
the
value
of
the
up
metric
is
zero
and
all
the
and
all
the
values
of
all
the
matrix
is
then
a
stale
nand.
B
So
is
that
the
marker
of
a
failed
script.
B
Because,
like
there
are
more
scrapes
when
we
are
running
the
test
like
in
which
ups
are
zero,
so
there
are
four
more
scripts
that
are
generated
here.
The
up
is
zero
and
the
values
of
the
of
the
matrix
are
non-none,
so
they
are
like
yeah.
D
G
That's
it
okay
makes
sense.
I
believe
that
logic.
Actually,
we
just
use
from
prometheus
itself
we're
we're
not
doing
anything
to
up
metrics
or
stalemates
ourselves,
we're
just
when
a
stalemate
gets
appended.
We
treat
it
like
a
regular
data
point
and
when
the
up
metric
gets
appended,
we
do
the
same
thing.
Yeah.
D
A
Yeah
we
can
check,
but
I
I
agree
with
david.
I
don't
think
there
was
any
additional
logic,
but
we'll
verify
it
for
sure.
G
A
B
Yeah
so
yeah
so
basically
like
in
the
existing
tests,
so
they
were
failing
because
they
were
because
the
current
tests
were
generating
failed
scrapes
and
the
testing
logic
was
not
able
to
was
not
handling
that
these
steel
scrapes.
So,
for
example,
if
I
scrape
has
more
than
five
metrics,
which
are
which
are
the
default
metrics
and
the
up
is
so,
it
is
expecting
in
those
metrics
up
value
one.
B
So
if
it
is
c
is
up
value
zero
in
those
metamatrix,
then
the
current
tests
are
failing,
so
yeah,
so
so
in
our
we
wanted
to
filter
those
those
failed
scripts
out,
so
that
the
current
lodge
the
current
test
function.
So
yeah-
and
apart
from
that,
like
we
have
the
design
dock
ready
for
for
all
the
other
objectives
of
from
this
receiver
test.
So
yeah
there
is
a
plan
to
work
on
those
ones
as
well.
C
Yeah,
so
this
table.
Basically,
if
you
can
see
my
screen,
we
have
itemized
test
cases
that
are
already
covered
by
existing
tests,
so
these
are
the
ones
in
yellow.
These
are
the
ones
that
first
stop
just
talking
about
like
the
issue
with
stillness
markers.
So
these
tests
are
failing
at
the
time
stamps
timestamp
checks,
so
yeah
and
the
ones
in
red
these
test
cases.
So
these
are
from
these
are
all
the
test
kits
from
the
design
dock
that
we
were.
C
A
Sounds
good
thanks
for
going
through
that
list
again.
This
is
the
line
with
the
requirements
that
we
had
initially
captured
on
the
dock.
F
A
Okay,
any
other
items
grace.
I
know
you
had
a
question
on
the
prometheus
dev
list
on
the
ui.
Was
that
specifically
specific
to
the
prometheus
implementation?
Did
you
have
any?
Were
you
going
to
add
the.
H
I
Two
weeks
ago,
yeah,
so
it's
mostly
just
being
able
to
like
directly
reuse
the
prometheus
ui
for
hotel,
since
we
already
have
like
the
scrape
manager
and
stuff
prometheus
has
a
web
package.
So
I
have
a
just
created
a
web
handler
with
that
and
passing
this
great
manager
to
that
and
it
handles
setting
up
the
server
and
having
all
the
info.
I
The
biggest
issues
is
like
how
we
want
to
like
be
able
to
build
that
or
use
like
the
react,
static
files
right
now,
like
reusing
the
package,
since
it's
kind
of
built
just
to
use
with
like
prometheus's
build,
I
have
to
actually
copy
the
files
into
the
container
where
I'm
running
the
open,
telemetry,
collector
binary
and
then
the
second
part
is
like
if
we
want
to
be
able
to
kind
of
refactor
the
code
to
have
options
for
what
pages
we
want
to
display.
I
A
Okay,
so
is
there,
did
you
get
what
you
needed
from
the
the
prometheus
side,
because
I
think
you
were
trying
to
optimize
right
to
see
if
you
could
reuse
the
same
files
and
then
and
the
same
npm
packages.
I
Yes,
yes,
so
there
isn't
a
published
npm
package.
So
that's
what
I.
E
A
Otherwise
we
can
brian,
do
you
know
who
would
be
the
right
person
to
ask
in
the
prometheus
community.
D
A
A
Yeah
good
good
point:
I
think
you
have
not
filed
a
bug
yet
right.
We
should
file
it
for
sure.
A
We'll
we'll
create
a
issue
with
david
for
sure.
Thank
you
very
much.
I
mean
that's
the
idea
right
that
we're
going
and
verifying
all
the
the
implementation
versus
what
what
do
you
expect.