►
From YouTube: 2023-04-13 Scalability Team Demo
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).
B
Yes,
is
this
in
Prometheus
or
Thanos
Prometheus.
B
B
A
Yeah
anyway,
I
was
also
going
to
check
whether
the
any
CPO
memory
got
hit
quite
significantly
during
this
period.
If
it
doesn't
then
I
guess
it
makes
sense
to
try
with
a
longer
interval
for
the
recording
rules.
B
A
A
B
B
B
B
B
So
here's
the
issue
that
I'm
talking
about
this
is
basically
preventing
integer
overflows
like
for
primary
keys
or
whatever
in
the
database.
We
have
a
column
type
with
integer,
but
then
we
add
a
lot
of
jobs.
It
could
run
out
when
we
hit
hip.
C
B
Ceiling,
so
we
want
to
monitor
that
and
replace
the
the
type
if
necessary,
we
have
that
in
timeland
for
yeah,
basically,
a
very
select
number
of
tables,
so
the
database
team
is
working
on
expanding
that
to
all
tables
great
they're,
proposing
a
system
of
alerting
and
yeah
notifying
people
of
that.
That
is
not
timeland
and
like
that
this
works
a
little
bit
different
and
I.
Think
Roger
Wu
had
a
a
proposal
here
and
I
think
we
should
Maybe
get
in
line
like
get
these
things
aligned.
So
we
can
use
one
thing.
C
C
Yeah
I
think
that
one
of
the
things
I've
been
talking
with
Roger
about
is,
is
how
do
we
actually
tie
some
of
the
things
they
want
to
do
together
because
in
some
of
the
data
we're
presenting
for
like
the
table,
size
and
costs,
and
things
like
that,
I
think
that's
really
great
and
and
a
great
start.
C
But
how
do
you
tell
the
story
to
like
some
of
the
other
folks
at
the
company?
Maybe
not
completely
engineering
focused
of
why
that
matters
and
connect
the
database
teams.
You
know
kind
of
abstract
will
be
100
gigabyte
tables
and
no
bigger
to
the
metrics
kind
of
we
can
we
can
Expose
and
and
show
to
users?
So
if
we
have
that
it's
great
I
think.
C
And
you
know
any
alerting
we
can
add
to
make
those
things
actionable
is
great
and
I.
Think
the
part
of
the
the
problem
here
right
is
is
the
other
functions
of
the
other
teams.
Don't
know
how
much
stuff
we
already
have
and.
B
We
have
a
lot
of
stuff
already,
but
we
don't
know
what
they
actually
want,
because
we
built
something
that
we
are
currently
using.
So
like
here,
they're
proposing
four
different
thresholds.
We
currently
have
two
and
they're
proposing
a
notification
issue
whatever
when
the
threshold
is
breached
and
we
do
a
prediction
of
when
a
threshold
is
breached
so
like
yeah,.
C
Yeah
well,
I
think
that's
that's
one!
That's
on
my
list
to
go
back
and
look
at
and
just
kind
of
respond
in
that
thread,
but
we
do
need
to
bring
those
things
together.
I
think
we
have
some
quite
a
lot
of
agency
with
what
we've
done
already.
That
seems
to
work
and
I
think
that
the
value
add
for
the
database
team
will
be
tying
some
of
those
things
together.
C
So
if
we
can
use
the
stuff
we
already
have
in
Taman
to
notify
or
make
those
things
actionable
when
they
need
to
be
actioned,
I
think
that's!
That's
probably
where
we
want
to
head
overall
right
and
presenting
usable
users
with
actionable
information,
as
well
as
the
the
kind
of
prediction,
because,
with
the
you
know
the
primary
key
overflows
if
it
stops
working,
it's
it's
a
bit
of
a
hard
recovery.
C
Yeah
and
then
I
think
there's
it's
it's
kind
of
the
the
database
team's
problem
to
solve
right
in
terms
of
you
know
you
are
going
to
overflow.
What
steps
do
you
take?
You
know
to
do
about
that,
so
there's
probably
some
work
there
to
figure
out
how
to
align
those
things
best
and
that's
on
my
my
to-do
list.
C
A
B
You
need
anything
from
me,
let
me
know,
but
I
think
yeah
we
can.
We
can
figure
something
out,
but
we
should
also
be
mindful
of
what
teams
actually
want.
We,
we
have
defined
two
thresholds
now
and
we
allow
customizing
them
and
everybody
can
actually
customize
them
if
they
want,
but
we
only
have
two
thresholds,
so
maybe
they
want
some
something
more
or
more
types
of
actions
or
I
haven't
read
entirely
true,
but
now
we
just
create
an
issue
and.
A
C
B
Yes,
I
think
that's
fair.
We
have
a
most
of
the
time
like
historically
when
we
talk
about
alerting,
it's
always
been
alert.
The
SRE
on
call
to
do
something
because
something
is
burning
down,
and
now
we
want
to
move
that
to
the
left
some
more
and
then
it's
not
always
the
most
urgent
thing.
They
should
look
at
so
yeah
yeah.
C
That
makes
sense
and
I
think
if
we
had
a
complete
approach-
and
you
know
I'm
not
sure
it's
anywhere,
you
know
it's
sensible
to
ever
get
to.
There
is
just
one
approach
to
do
it.
We
could
just
put
it
in
there,
but
maybe
we
have
to
take
a
bit
of
a
a
custom
approach
and
see
what
works
with
the
customers
and
what
they
engage
with
and
then
make
some
decisions
about
whether
to
invest
more
heavily
in
that
kind
of
learning
approach,
yeah.
B
And
one
thing
that
is
difficult
about
this
specifically
for
capacity
planning
is
that
we're
actually
having
three
stakeholders,
for
example,
with
the
database.
We've
got
us
we're,
building
the
capacity
planning
framework
to
predictions,
and
we
made
assumptions
on
what
people
want
to
be
notified
about
and.
A
B
We've
got
the
database
team
who
are
responsible
for
the
resource
like
the
and
responsible
for
the
for
the
resource,
and
they
also
want
to
serve
their
customers,
which
are
the
users
of
the
database,
and
they
want
them
to
help
yeah
do
the
right
thing.
So
that's
actually
three
levels
that
we
need
to
get
through
here.
C
One
thing
just
was
run
the
topic
in
the
the
database
team
that
might
be
interesting
is
I,
think,
there's
a
there's
a
case
for
service
owners
to
have
slightly
different
prediction
levels
or
timelines.
One
of
the
things
that
I've
talked
about
with
Roger
and
with
a
couple
of
other
folks
is
that,
for
you
know,
pieces
of
our
core
infrastructure
like
database
that
we
need
to
vertically
scale
they
can
see
benefit
of
having
quite
a
long
prediction
out.
C
You
know,
12
months
to
18
months
to
say
am
I
at
least
trending
in
the
right
track,
or
you
know,
because
database
upgrade
is
a
substantial
piece
of
work.
I
want
to
be
able
to
plan
that
early
in
my
kind
of
planning
cycle
and
I,
don't
know
how
hard
that
is.
Given
all
the
timeland
stuff
is
plotted
on
there
equal
graph,
all
the
way
down
right.
C
I
think
you
stopped
sharing,
but
for
for
some
of
those
service
owners.
If
it's
a
matter
of
extend
the
prediction
a
bit
for
them,
I
think
that
would
be
a
a
quick
win
and
a
good
way
to
get
buy-in
to
show
that
we
care
about.
You
know
what
they
want.
B
We
have
the
Separation
by
service
here
now.
These
are
all
the
same
graphs
but
and
I
like
that.
It's
the
same
routes,
because
you
can
call
correlate
things
right
like
if
you
look
at
yeah
here,
async
primary
pool
and
CPU
and
for
example,
they
could
have.
A
B
C
And
I
think
it's
it's
very
correlated
with
the
work
that
is
required
to
shift
Direction
substantially.
So
you
know
on
on
postgres,
that's
significant,
maybe
for
a
micro
service.
That's
much
easier,
so
you
don't
have
to
predict
as
far
out
yeah.