►
From YouTube: Scalability Team Demo 2022-02-17
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
A
A
C
C
A
So
the
idea
is,
I
want
to
include
these
kind
of
slis
into
the
error
budget
for
stage
group.
So
that's
here,
query,
durations
and
yeah.
I
think
only
query
durations
for
the
primaries
and
the
secondaries
into
their
budgets
for
stage
groups
because
then
like
if
yeah
slow
queries
get
triggered
too
often
that
would
be
visible
there.
A
The
problem
with
this
well
like,
as
you
can
see
these
these
things
already
have
a
feature
category
on
them.
So
we
could.
If
we
change
this,
to
feature
category
and
source
metrics
like
the
the
magic
string,
then
these
things
would
feed
into
their
budget
and,
like
everybody,
would
be
very
happy
because
we
do
a
lot
of
fast
queries
all
of
the
time
and
those
would
like
hide
everything
else
in
the
budget
and
then
the
thing
that
I
was
thinking
about
to
to
make
this
possible
was
weighting
sli.
A
So
we
could
say,
for
example,
the
the
these
these
slices
only
weigh.
I
don't
know
a
tenth
of
what
a
request
weighs,
for
example.
Okay,
I
don't
know
about
these
numbers
so
yeah
does
anybody
have
thoughts
on
if
we
should
do
that?
If
it's
going
to
be
too
complicated
for
people
to
understand,
or
if
it's
going
to
yeah,
if
it's
even
valuable,
to
have
these
kind
of
more
hidden
things
included
in
them,
the
budget
for
stage
groups.
C
A
C
C
A
Up
the
the
gitlab
sql
primary
duration
seconds
bucket,
then
yeah
like
the
the
metrics,
you
will
see
them
and
the
petroni
logs.
I
think
we
do
this
fancy
thing
with.
What's
it
called
yeah,
it
should
be
there
like
in
a
comment
like
because
we
we
annotate,
like
we
said
that
over
to
the
database
and
so
on.
If
I
remember
correctly,.
A
Of
about
right,
okay,
you
can,
you
can
see
it
like.
If
you
expand
the
details,
you
will
see
yeah,
you
will
see
that,
like
which
feature
category
has
the
slowest
queries
but
yeah.
We
only
look
at
that
during
an
incident
and
then
yeah.
C
A
And
this
is
this:
is
this
leads
into
like
right?
Now
we
have.
We
have
we
kind
of
have
weights
for
things
that
we
do
in
the
general
sla,
dashboard
and
so
on,
but
there's
also
an
issue
about
having
like
an
internal
or
like
trying
out
an
internal
measurement
of
general
availability,
not
using
time,
but
using
events.
C
A
A
C
A
They
are
there
or
where
they
come
from,
but
that's
what
we
do
so
yeah.
My
proposal
would
be
to
to
like
the
the
error.
Budgets
are
event
based
their
budgets
for
stage
groups
are
event-based,
so
then
the
whole
thing
is
how
many
events
were
good
over
how
many
total
events
were
day
and
that's
the
availability
number.
A
A
It
becomes
very
hard
to
explain
because
I'm
already
having
trouble
now
yeah
so
yeah,
so
wondering
what
people's
thoughts
are.
If
it's
something
we
should
explore
or
not
or
if
there's
better
avenues
to
get
stage,
groups
focus
on
database
queries
and
performance,
the
performance
of
a
database
queries.
The
same
goes
for
hitler
goals
in
the
end.
A
Yeah
contribute
more
or
less
exactly.
We
already
have
a
single
metric,
but
the
numbers
have
lined
up
well
enough
that
it
works
like
where,
for
most
groups,
this
just
means
requests
from
rails
and
sidekick
jobs,
and
the
numbers
are
similar
enough,
so
one
doesn't
outweigh
the
other.
C
A
Well,
troubleshooting,
not
like
it
wouldn't
the
way
we
look
at
a
single
sli
on
a
on
a
dashboard,
it's
more
like
if
we
include
this
into
the
budge
into
the
overall
number
and
like
we
could
have
a
people,
can
now
say
that
the
request
is
allowed
to
take
up
to
five
seconds.
If
all
of
these
things
include
queries
that
take
five
seconds,
then
one
is
going
to
be
good,
but
that's
really
not
healthy
for
the
database.
So.
B
I
I
wonder,
if
that's
more
an
issue
of
how
you
set
up
each
sli,
like
maybe
the
what
needs
to
be
adjusted
here,
as
are
the
threshold
within
an
sli,
but
each
sli
has
the
same
weight.
It's
just
that.
Maybe
this
sli
is
more
permissive
with
its
specific
metric
because
of
x
or
y
reason,
but
like
if
right,
exactly,
as
I
said
like
what
constitutes
an
acceptable
database
request
time,
it's
different
to
what
constitutes
not
acceptable
yeah
time.
But
then
what
you
need
to
adjust.
A
But
the
thresholds
for
the
sli
are
already
different
right,
but
if
you
have
like,
if
you
have
a
request
that
takes
five
seconds
and
inside
that
request,
you're
doing
a
thousand
database
queries
that
take
less
than
100
milliseconds,
then
you
would
score
very
well
and
that's
why
I'm
proposing
the
weights
like
because
we
perform
a
lot
more
queries
than
we
do.
Requests.
A
There
was
there
was
we
right
now?
We
we
don't
have
a
problem,
but
if
we
wanted
to
like
the
the
thing
we
want
to
end
up
with,
is
people
looking
at
database
queries
that
they
are
writing
and
if
they
are
going
to
perform
well,
if
they
like
need
to
add
indexes
after
the
fact
and
that
kind
of
stuff,
so
we
want
people
paying
attention
to
that
before
we
have
an
incident.
We
have
a
lot
of
like
slow
query
kind
of
incidents.
A
C
C
C
A
C
Well,
first
of
all,
I
guess
like
including
service
weight
in
the
calculation
you're
you're,
multiplying
the
the
numerator
and
the
denominator
by
the
service
weight
right,
which
is
the
same
value.
So
it
doesn't.
C
B
C
Yeah:
okay!
That's
what
I
thought
so
so
for
I
guess
for
metrics,
where
we
don't
have
as
many
requests.
This
helps
to
balance
them
out
a
bit.
C
A
And
as
to
the
reason
why
we
want
to
try
out
an
event-based
thing
is
because,
like
then
not
every
like
a
sunday
night
will
not
weigh
the
same
as
a
monday
morning.
If
we're
doing
right.
C
To
put
it
another
way,
you're
sort
of
like
normalizing
the
number
of
operations
per
service
right
like
you're,
trying
to
normalize
them
so
that
they're
on
equal,
equal
footing
right
is
that.
Does
that
sound
right.
A
That's
like
the
initial
goal,
like
it
also
is
kind
of
like
a
lever.
I
don't
know
if
we're
going
to
like
look
at
like
we're
generally
doing
this.
Many
database
queries
per
request,
so
we're
going
to
like
say
we
do
five
times
more
database
queries.
Then
we
do
requests
it's
a
random
number.
I
don't
have
no
id,
but
yeah
then,
like
we
might
say
like
the
database
is
pretty
like
we
might
not
do
divided
by
five
for
database
queries.
Just
because
of
that
we
might.
A
C
C
Yeah,
because,
basically,
what
you're
saying
I
mean
what
maybe
what's
missing
or
what
I
didn't
understand.
First
in
this
proposal,
is
that
you
have
many
different
services
that
have
this
ratio,
and
then
each
service
will
have
its
own
service
weight
and
then,
when
you
aggregate
all
that
together
then
you're
looking
at
okay,
this
is
the
slo
for
the
entire.
I
guess.
C
Web
api
right
and
then
and
then
and
and
then
these
these
weights
help
put
the
individual
services
normalize
the
individual
services
so
that
they're
they're
more
equal
yeah.
A
Yeah
and
my
my
like
the
initial
id
that
you
read
in
the
last
and
the
issue
you
just
had
open,
was
to
put.
A
A
service,
but
now
I'm
more
leaning
towards
putting
actually
putting
a
weight
on
a
service
and
or
an
sli
itself
like
we
have
monitoring
thresholds
for
both
like
you
can
define
the
global
one
on
the
sli.
But
you
can
all
also
be
more
specific
inside
the
sli
itself.
C
C
B
C
Yeah,
so,
okay,
so
really
like
it's
not
so
important
that
this
rolls
up
into
the
top
level,
so
the
slo
for
or
the
sla
for
gitlab.com
right
I
mean
like
I
mean
I
guess
that's
also
important,
but
this
is
more
about
the
the
slas
each
stage
group
or
each
service
has.
A
C
C
A
A
Averages,
but
if
you
open
up
because
I
you
are
better
at
screen
sharing
than
me,
if
you
open
up
the
monitoring
dashboard,
which
I've
been
recently
working
on.
C
B
A
So
the
top
number
there
aptx
and
error
ratio
yeah.
Those
can
also
get
like
muddied
by
if
there's
an
sla,
an
sli
below
there
that
has
way
more
traffic
than
yeah
another
one.
A
That's
why
I'm
saying
maybe
we
should
weight
those
as
well
for
the
web,
it's
kind
of
okay,
because
we
have
like
the
workhorse
thing
and
puma
and
they're
actually
kind
of
the
same
thing,
but
they
aren't
so
if,
if
workhorse
alone
goes
bad,
we'll
know
if
puma
alone
goes
back,
we'll
know
often
they
go
bad
together.
Then
we
certainly
know,
but
then
for
example,
image
scaler
is
a
bit
yeah
special.
C
A
Becomes
more
interesting
when
you
add
an
sli
like
the
monitoring
service,
is
now
like
a
big
pile
of
different
things
and
different
services
mushed
into
one
and.
C
C
A
C
It's
really,
I
think
it
would
be
useful
to
work
backwards
from
our
dashboards
to
kind
of
see
what
I
know
this
isn't
explicitly
for
troubleshooting,
but
you
know
kind
of
think
about
what
we
want
to
see
here
first
before
we,
because
this
will
have
like
we'll
be
updating
our
dashboards
after
we
make
this
change
right
like
to
have
these
metrics
broken
out
by
service
by
right
or
not.
A
C
A
A
End
points
that
they
own
yeah.