►
From YouTube: 2021-11-17 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
Hello,
everybody
we'll
give
people
a
couple
more
minutes
to
filter
in.
But
if
you
can,
please
add
your
name
to
the
agenda
and
any
items
you
wish
to
discuss
and
then
we
can
start
working
through
it.
A
Okay,
let's
go
ahead
and
get
started.
Do
you
want
to
talk
through
the
issues
you're
having.
B
Yeah,
I
want
to
ask
regarding
the
honor
time
stamp
behavior.
This
is
regarding
the
prominent
receiver
test
that
brought
mr
and
myself
are
currently
doing
working
on
so
in
the
honor
time
stamp.
B
So
I
discussed
this
issue
in
the
previous
segmenting,
so
what
I
did
as
per
as
discussed
in
the
previous
submitting
I
provided
a
distinct
time
stamp
to
every
metric
in
the
in
the
test.
Data
and
the
output
is
something
like
this.
B
The
point
timestamp
is
the
distinct
timestamp
that
was
provided
in
the
test
data
to
the
every
metric,
but
in
case
of
counter
the
start,
timestamp
that
that
is
seen
that
comes
out
is
the
time
stem
that
was
given
to
the
metric
of
go
through
gauge
metric.
But
in
the
case
of
histogram
and
summary,
the
point
times,
the
start
timestamp
is
is
the
same
as
point
timestamp
which
was
given
to
the
metric.
B
So
because
there
is
a,
I
assume,
because
the
counter
histogram
and
somebody
all
are
cumulative
types,
so
they
they
would
have
same
behavior,
but
in
case
of
counter
the
start.
Timestamp
is
not
from
the
distinct
time
stamp
that
was
given
to
it
in
the
test
data
it's
coming
from
the
go
through.
I
just
wanted
to
confirm
this
behavior
for
the
expectations
and
validations.
C
B
So
you
mean
like
every
quantile
like
every
quantile
should
have
a
data
point
also
should
have
the
timestamp
here.
Yeah.
C
Is
it
matters
more
now
in
the
case
of
the
histogram,
which
is
matter
more
like
in
theory,
you
could
have
summaries
at
two
different
times,
and
one
of
them
only
has
the
quantile,
and
one
of
them
only
has
the
sum
in
the
count,
which
would
be
weird,
but
it's
valid
for
the
histogram
above
that,
on
the
other
hand,
there
always
has
to
be
plus
inf
bucket,
so
you
couldn't
separately
just
have
a
summon
count,
because
that
would
be
incorrect,
because
the
plus
infinite
would
be
missing,
but
it's
just
mostly
a
matter
in
this
case
of
put
the
timestamps
on
the
other
ones.
C
A
C
B
B
Okay,
yeah,
but
in
case
so
which
behavior
is
right
here
is
the
behavior
of
counter
is
right
that
the
start
time
stamp
should
be
from
should
be
the
distinct
time
step
that
was
given
to
it,
or
it
should
be
from
the
timestamp
that
was
given
to
the
first
metric
in
the
in
the
test
data
or
in
the
whole
script.
A
I
think
it
only
looks
to
has
the
value
exhibit
a
behavior
that
looks
like
a
reset
and
that's.
We
will
reset
the
start
time
stamp
to
the
current
points.
Time
stamp.
I
don't
think
we've
done
anything
to
say
if
the
point
time
step
is
prior
to
the
current
time
stamp.
What
do
we
do
then?.
A
We
we
derive
a
start
time
sample,
it's
not
explicitly
provided
so
should
we
assume
that
the
point
times
the
the
time
stamp
if
the
timestamp
is
explicitly
provided,
that's
the
point
time
stamp
and
we
could
use
it
as
a
start
time
snap
if
we
have
no
point
time
stamp
or
if
we
have
no
prior
start
time
stamp,
but
we
shouldn't
try
to
reset
the
start
time
stamp.
If
it's
earlier.
A
Okay,
I
mean-
I,
I
think,
that's
what
we're
currently
doing
and
it
seems
plausible,
but
it
it'll
lead
to
potentially
weird
data
where
the
start
time
stamp
is,
after
the
point
time
stamp,
and
I
don't
know
how
downstream
systems
will
deal
with
that.
But
that's
what
we're
being
told.
C
Yeah
we've
got
a
similar
notice
in
openmetrics
spec
itself
that
hey
this
can
happen
and
also
exempt
our
timestamps,
because
you
know
normally
in
prometheus,
scrape
timestamp
is
attached
by
prometheus.
The
exemplar
timestamp
is
coming
from
the
application
they're
on
different
machines.
They
could
be
off
by
a
few
milliseconds,
even
in
the
best
of
situations.
C
A
Yeah,
there's
nothing
odd
about
that,
and-
and
even
in
that
case
I
I
don't
know
that
we
can
do
anything
that
just
that
becomes
a
a
thing
for
the
downstream
system-
that's
receiving
it
to
figure
out.
What
do
I
do
with
a
start
time
stamp
that
significantly
after
the
point
time
stamp
does
does
that
have
meaning
for
me,
is
this
a
record
that
I
could
even
do
something
with
or
do
I
have
to
toss
it,
but
I
don't
know
that
we
can
make
that
decision.
A
B
But
it's
only
with
the
case
with
counter:
it's
not
the
case
with
the
histogram
and
summary
so
like
the
start,
and
point
are
same.
That
was
given
to
a
distinct,
particularly
over
in
the
dash
data.
C
A
C
A
B
Yeah,
this
difference
comes
like
gets
adjusted
in
the
metric
adjuster.
Only
like
the
data
which
scraper
feeds.
It
is
this
data
only
but
metric
adjuster,
adjusted
to
the
start
times
time
to
to
the
timestamp
of
the
point.
A
Okay,
next
issue.
B
Sure
so,
for
this
I
would
just
keep
the
behavior
like
I
would
just
validate.
This
validation
is
like
this
is
the
right
behavior
for
to
pass
this
to
pass
this
data,
like
is.
A
This
expected
or
actually
yes,
yes,
I
believe,
that's
the
the
expected
behavior,
the
behavior
of
the
histogram
and
and
summaries
may
not
be
correct,
but
that's
that'll
be
within
our
metric
adjustment.
We
need
to
look
at
that
and
and
see
if
it's
doing
the
wrong
thing
there
in
some
situations
it
should
be
behaving
more
like
the
counter.
A
B
Thanks
the
next
thing
I
wanted
to
discuss
is
regarding
the
metric
relabeling,
so
basic,
basically
provided
this
config
for
the
metric
relabeling
to
the
hotel,
prometheus
receiver
and
and
basically
it
converts
all
the
metrics
that
it
treats.
B
So
if
it's
encounter,
histogram
or
or
summary
it
converts
them
to
cause,
so
so
want
you
to
understand
like
if
this
is
the
expected
behavior,
because
when
I
feed
this
same
data
with
renaming
metric
to
prometheus
server
on
the
web,
ui
like
I
s
on
multiple
pages
actually,
so
it
does
rename
it
to
four,
because
that's
that's
what
the
config
mentioned
and
I'm
able
to
use
the
rate
query
here.
B
So
it
doesn't
say
that
it's
counter,
but
because
I'm
able
to
use
rate
query
here,
so
I'm
suspecting
that
it
is
counter.
So
just
want
you
to
understand
like
is
it
intentionally
converted
to
cause
double
in
the
hotel
prometheus
receiver?
And
is
it
the
expected
behavior.
C
So,
like
prometheus
doesn't
use
those
types
at
all,
just
meta
that
if
the
user
can
do
something
with
and
gauge
is
not
correct
because
you
don't
know
like,
if
you
don't
know,
you
should
probably
be
using
unknown
or
on
types,
but
in
general,
like
the
way
we
can
look
at
this
in
prometheus
is
metric.
Relabeling
is
a
last
resort.
C
Please
try
not
to
do
that,
fix
it
in
the
application,
but
like
from
a
correctness
standpoint
either
try
to
follow
things
along
and,
if
you're
doing
any
sort
of
complex
type
like
a
histogram.
If
it's
only
half
done
yeah,
who
knows,
but
the
most
correct
thing,
if
you're
not
going
to
try
and
follow
things
through,
is
put
it
down
as
untyped
or
unknown,
depending
on
where
it
is.
B
So
test
data
in
this
was
a
counter,
so
I
gave
a
counter
metric
with
the
renaming
config
and
it
converted
that
into
a
gauge
the
hotel
collector
prometheus
is
here.
D
So
the
impact
is
nothing
right.
Now
the
metric
stays
the
same.
You
can
do
rate
on
it
on
the
counter
right.
The
values
are
not
changed.
A
C
C
D
C
C
A
B
Okay,
yeah
and
metric
renaming
without
replacement,
produces
up
zero
in
the
hotel
prometheus
receiver,
but
when
this
same
data
with
the
renaming
config
without
replacement,
was
packed
to
committee's
server,
it
does
the
renaming.
B
So
what
do
you
mean
by
up
hyphen
zero?
Oh
I
mean
just
it
dropped
the
metric.
The
value
of
the
up
was
zero.
That
was
the
only
I
mean
it
created
a
it
dropped
the
metric
when,
when
I
gave
it,
the
config
of
this
particular
config
without
the
replacement,
the
hotel
from
it
is.
B
B
C
B
Yeah
on
prometheus
server,
it's
succeeded,
but
not
on
the
hotel,
prometheus
receiver.
C
Yeah,
but
to
be
honest
in
this
case,
you're,
presumably
having
clashing
metrics.
That
is
not
a
sensible
config
in
any
way,
and
to
be
honest,
filming,
the
scrape
is
possibly
even
better
than
what
prometheus
currently
does,
because
it
makes
it.
B
The
right
configuration
actually
because
prometheus
server
did
rename
it.
As
for
the
given
configuration.
B
C
B
Okay,
so
so
I
will
move
on
to
the
another
issue.
So
this
is
another
issue
that
is
there
regarding.
So
there
is
a
test
to
see
if
the
non-numerical
values
like
man's
normal
lens
still
lands
and
infinity
are
passed
through
the
equilibrium
receiver.
B
So
there
is
a
problem
that
the
output
that
is
there
that
comes
out
from
when
there
is
a
failed
scrape,
is
non-deterministic.
B
So
output
comes
out
different
in
every
run,
and
that
happens
because
in
this
fade
loop,
the
previous,
the
metrics
that
was
seen
in
the
previous
scrape
is
stored.
You
know
the
labels
are
stored
in
our
map
c
dot
series
prep
and
this
map
it's
a
map,
so
it's
not
organized
by
the
sorted
in
a
organized
using
the
metric
labels,
so
so
like
that
over
here
we
have
http
request
total.
B
Then
we
have
go
threads
and
then
we
have
http
request
total
so
like
these,
because
they're
not
organized,
but
the
metric
builder
expect
them
to
come.
You
know
in
the
organized
fashion
and
because
it
doesn't
happen
like
that,
so
I
mean
the
logic
it
only
for
histogram
and
summary.
It
cares
about
only
cares
about
count
to
build
a
metric
so
because
of
that,
the
output
that
comes
out
is
is
non-deterministic.
Every
time
like
this
sum,
I
would
have
a
zero
or
a
nand
value.
B
Buckets
could
be
zero
or
many,
but
it
would.
It
may
or
may
not
reflect
what
was
seen
in
the
previous
scrape.
Actually
so,
and
the
count
value
that
comes
out
is
main
integer
64
that
because,
because
of
the
casting
from
float
to
integer
and
and
so
it's
and
the
only
thing
that
reliably
that
comes
out
is
count
so
now
it's
not
possible
to
differentiate
between
normal
man
or
a
steel
man
or
infinity
and.
A
So
when
we
discussed
this
yesterday,
it
seemed
that
this
was
a
result
of
an
interaction
between
the
scrapers
iterating
over
stale
values
in
a
non-deterministic
manner,
just
because
it's
iterating
over
a
map
right
and
map
iteration
is
not
ordered
and
our
receiver's
expectation
that
it
does
receive
all
of
the
points
for
a
metric
family
in
succession
right
that
that
it
doesn't
receive
points
or
metric
family
with
something
else
in
between
brian.
Am
I
correct
in
assuming
that
getting
the
sale
points
iterated
in
assorted
order
is
a
non-starter
from
the
prometheus
side.
C
Well,
yeah
from
a
performance
standpoint,
yeah
plus
you'd
have
you'd
have
to
organize
it
all
and
in
addition,
there
is
no
requirement
for
the
prometus
text.
Format
that
things
be
in
any
particular
order
like
you
can
literally
have
a
random
order,
every
time
as
technically
valid,
not
for
open
metrics,
but
yes
for
the
prometus
format,
which
is
annoying
in
many
ways,
but
it
is
permitted.
C
A
Yeah,
okay
and
that's
that's
what
I
discussed
with
peruse
yesterday-
was
the
the
way
we
ought
to
do
it
for
stalemetrics.
But
I
I
think
that
that
just
convinces
me
that
we
should
just
do
it
for
every
metric
type
that
we
don't
even
need
to
try
to
deal
with
stalematrix
separately
anyways.
B
Yeah,
so
only
issue
that
I
was
having
with
the
discussion
that
we
had
yesterday
is
like
to,
because
what
we're
trying
to
do
here
is
like
if
a
matrix
is
dropped.
That
means
it
was
like
which
happens
in
case
of
still
marker.
B
So
then,
instead
of
then,
instead
of
converting
it
to
matrix
straight
away,
we
converted
it
in
the
we
converted
in
in
the
metric
in
the
very
end
like
after
everything
is
after
the
whole
process
is
done,
but
it's
like
because
the
length
of
the
map
is
not
known
here.
So
it's
not
possible
to
know
like
when
is
the
when
this
like
build
metric
builder
will
end,
and
then
we
need
to.
A
It'll
it'll
end
when
commit
is
called
on
the
transaction
so
we'll
we'll
handle
all
of
that
in
whatever
is
called
by
commit
or
in
incommit
itself.
Okay,
okay,
yeah,
yeah.
So.
B
A
A
Thanks
cool,
so
it
looks
like
we're
getting
down
to
fewer
and
fewer
issues,
and
fewer
of
them
are
scary
and
not
solvable.
So
that's
good.
D
So
anthony,
do
you
know
if
we
have
a
an
issue
to
track
to
move
the
stainless
representation
to
the
otp
10
protocol.
A
That,
oh
okay,
yeah,
if
there
isn't
one,
please
go
ahead
and
create
it.
So
some
of
the
work
that
the
persian
and
mr
fund
have
been
doing
is
helping
us
move
down
that
path
right,
so
emmanuel
had
started.
A
The
work
of
creating
a
metrics
builder
that
built
otlp
instead
of
open
senses,
parish
and
team
have
been
working
on
converting
all
of
the
tests
that
used
to
convert
peat
data
into
open
senses
for
testing
to
just
operate
directly
on
the
p
data,
which
gets
us
one
step
closer
to
being
able
to
swap
over,
to
generating
p
data
directly
and
and
then
testing
that
directly.
So
I
think
we're
moving
along
that
path,
and
once
we've
got
all
of
these
tests
converted,
we
can
start
looking
for
stillness
markers
in
the
p
data.
A
I
I
expect
they
won't
be
there
until
we
convert
over
to
the
p
data
generation
side
of
things,
and
that
may
need
to
be
taken
somewhat
slowly,
because
we
need
some
confidence
that
there's
equivalent
behavior
on
both
sides,
but
we're
we're
making
progress
in
moving
in
that
direction,
and
I
think
that
I
would
say,
probably
in
the
next
month
or
two,
we
should
be
able
to
start
producing
that
value
out
of
the
p
data
and
using
the
p
data,
at
least
in
you
know,
in
something
that's
gated
by
a
feature
gate.
A
Okay:
okay,
if
there
are
no
more
issues,
give
everybody
a
half
hour
back
and
we'll
see
you
all
next
week.
Thank
you.
Everyone.