►
From YouTube: Scalability Call - Dashboards for Stage Groups
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
Sure
we
can
take
notes
here
and
then
I'll
I'll
take
a
copy
of
this
across
to
the
scalability
meetings.
That's
the
one
that
we
yeah.
That's
cool
my
fault
for
not
linking
that
on
the
agenda
as
well.
So
I
had
a
couple
questions
there.
I'm
just
going
to
move
them
across
to
this
sounds
good
I'll.
A
Like
all
the
dashboards
are
there,
the
limited
contact
is
on
it
and
now
there's
like
two
things
that
we
need
to
like
two
directions.
We
can
go
to
move
forward
like
do
we
make
the
content
better
by
default,
or
do
we
start
spreading
the
news
to
everybody
and
hear
what
they
want
to
get
on
there?
B
So
when
we
say
like
extending
the
dashboards
or
adding
the
data
in
there,
which
issues
are
those.
A
Extending
the
dashboard
like
we
haven't,
we
don't
have
an
issue
for
that,
yet
we
just
had
an
issue
that
was
the
first
one,
create
a
generic
dashboard
kind
of
like.
I
didn't
see
it
right
now.
B
A
So
create
generic
metric
dashboard
for
each
stage
group.
That's
the
one
that
just
kind
of
finished.
We
just
need
to
verify
the
last
bit
of
it,
but
like
the
dashboard
is
there
it
can
be
extended,
but
we
don't
know
what
to
add
for
groups.
So
that's
why
there's
no
issue,
because
we
don't
have
anything
concrete
to
add
there.
B
Okay,
so
this
sort
of
comes
to
one
of
the
points
that
I
added
right.
At
the
end,
I've
started
working
on
like
how
we're
going
to
communicate
this
out
to
the
teams
and.
B
B
So
I
think
that
I
I
think
that
the
two
tasks
need
to
run
in
parallel,
because
we're
going
to
be
communicating
with
teams
which
can
probably
only
really
happen
in
the
new
year
now,
given
how
many
people
are
out
and
at
the
same
time
I
think
we
can
continue
with
improving
the
dashboards
to
a
certain
extent,
adding
the
data
that's
missing,
and
then
we
might
be
then
looping
back
into
creating
the
customizations
for
people
as
well
straight
away.
A
Yeah
there's
some
things
that
I
don't
know
how
much
I
can
extend
this
epic
because
there's
stuff
that
I'm
thinking
about
like,
for
example,
some
groups,
don't
really
care
about
rails,
request
rates
or
sidekick
jobs
because
they
don't
have
any
so
they
need
to
have
a
way
to
remove
that
from
the
default
dash.
A
So
that,
like
that
those
kind
of
issues
I
wanted
to
create
them,
but
I
don't
really
know
where
they
belong.
Well,
I
wanted
to
create
them.
I
haven't
gotten
around
to
creating
them
yet
can
I
just
add
them
to
this?
Epic
and
you'll
put
them
out
when
you
think
like
not
now.
B
Yeah,
so
I
think
for
anything
that
you
think
of
that
needs
to
be
done,
just
throw
it
into
this
epic,
because
I'm
also
I've
also
gotten
to
the
point
where
I
think
that
there
are
many
projects
inside
of
this
piece
of
work,
the
first
one
being
what
we've
accomplished.
Now
we
have
created
the
dashboards
for
the
stage
groups.
They
exist
and
I
think
the
next
piece,
the
next
project
is
going
to
be
communicating
and
then
communicating
it
out
and
the
cut
and
the
like.
The
engagement
with
the
teams.
B
And
I
was
almost
thinking
about
having
one
epic
per
stage.
So
if
you
look
at
that
issue,
number
666
having
one
epic
for
manage
and
one
epic
for
plan,
one
epic
for
create,
etc,
and
then
inside
of
that
having
one
issue
per
group
and
when
we
finish
the
engagement,
then
that
wraps
up,
because
I
think
there's
the
director
level
communication
as
well
as
the
communication
with
the
groups
that
needs
to
happen.
A
B
Okay,
so
let's,
let's
start
taking
notes,
really
hold
on.
A
Sorry,
for
example,
yeah,
as
you
probably
know,
the
geo
dashboard.
We
won't
have
metrics
because
we're
not
using
that
on
gitlab.com.
B
Sorry
between
need
a
way
to
remove
items
that
aren't
important
for
the
group.
That's
one
issue:
removing
groups
within
a
matrix
being
collected.
That's
another
issue.
B
Okay,
then
also
on
the
agenda,
you
said
their
content
is
limited
and
then,
while
then
you've
added
two
items
there.
C
Yeah
so
because
the
only
mentions
that
we
will
need
to
add
some
more
content
to
make
the
dashboard
useful.
However,
at
the
same
time,
we
are
not
really
sure
what
other
style
groups
are
needed
in
the
dashboards.
C
So
I
think
that
we
can
come
up
with
some
more
generic
one
lighted
latency
on
the
filter
that
I
already
mentioned,
and
I
think
that
the
most
system-
those
are
very
common
and
can
be
used
by
on
the
slave
groups,
and
during
that
we
will
continue
to
ask
and
talk
to
the
stables
and
communicate
to
them
to
verify
what
their
specific
requirements.
A
I
think
the
reason
we
haven't
added
real
latency
in
the
beginning,
because,
though
we
have
those
metrics
and
they're
available,
but
they're
very
they're,
expensive
metrics
to
record
because
of
the
cardinality
of
each
bucket
and
they're,
not
accurate.
But
we
do
have
that
information
accurately
in
the
logs.
So
that's
why
the
links
are
there
to
point
them
at
the
logs
and
I
think
andrew.
But
I
don't
want
to
put
words
in
this
spotlight.
A
I
think
andrew
wants
to
point
more
towards
the
sli's
that
include
the
latency
metrics
and
then
like,
like
providing
a
way
to
go
from
slis
to
whatever
in
the
logs.
That
is
more
detailed
because
we
won't
like
if
the
the
latency
metrics
can
be
confusing
because
they
can
like
yeah
because
of
the
buckets,
and
we
want
to
decrease
the
number
of
buckets
even
more
to
have
less
cardinality
there.
So
we
only
really
have
the
buckets
that
we're
using
for
alerting
like
degraded
and
very
bad.
B
So
I
I
think,
if
that's
the
case,
we
need
to
document
like
how
to
use
that
that
piece
of
it.
If
we're
saying
that
we
have
latency
information,
but
we're
not
displaying
it
for
some
reason,
then
we
need
to
like
say
why.
A
B
A
Inside
the
epic
there's
already
one
issue
for
documentation,
which
I
think
create
documentation
and
tutorial
about
stage
group
dashboards
yeah,
that's
the.
C
One
yes,
and
about
the
documentation,
I
really
put
some
items
first
to
discuss
about
and
because
I
used
to
be
in
this
situation
before
that
I
have
to
cross-cut
the
dashboards
and
the
members
to
really
broad
audience.
So
there
are
something
we
need
to
talk
specifically
about
should
be
the
accuracy
of
the
metrics
and
what
does
a
particular
method
mean
because
it's
really
confusing
when
I
first
look
in
geometry,
especially
for
somebody
aggregation
periods,
it's
really
hard
to
tell
whether
the
number
in
the
metric
is
about.
C
So
if
the
dashboard
say
that
it
is
one
request
for
the
project
show
action,
what
does
it
mean?
It
means
that
one
request
per
minute
per
second
on
what
it's
really
hard
to
tell,
and
I
can
only
tell
that
from
the
query
I
read
from
the
dashboard,
but
it's
really
hard
for
other
engineers
to
do
so
because
they
don't
have
me,
don't
have
more
experience
with
the
monitoring
system.
A
That
we've
struggled
with
and
in
the
past
like
communicating
what
the
metrics
were
showing
actually
mean
yeah,
so
on
some
of
the
dashboards
like
the
cpu
saturation
ones
that
I
was
just
visiting
and
we
have
like
a
panel
that
explains
like
how
to
kind
of
read
this:
how
to
proceed
when
it's
saturated.
Maybe
we
should
come
up
with
panels
like
that
for
the
default
metrics
as
well
and
create
an
issue
for
that
later.
A
I
commented
that
in
the
in
the
create
documentation
description,
I
think
we
should
put
it
in
doc,
slash
development,
because
that's
generally
like
when
I
was
on
the
product
side
of
things,
that's
where
I
would
look
for
anything.
A
We
have
a
tendency
to
put
everything
in
the
run
books
while
like
on
the
product
side,
then
we
tend
to
like
document
everything
in
the
in
the
gitlab
rails
repository
and
like.
B
A
C
Yeah,
it
is
obviously
in
mind
because
when
I
first
look
into
gitlab,
I
have
no
idea.
We
have
a
dot
blush
documents,
folder
inside
the
dress
app.
Usually
I
will
go
to
the
handbook
and
type
monitoring
and
in
the
graphic
repository
and
want
the
handbook
so
that
everyone
can
just
go
in
and
find
by
any
item
they
can
file.
C
Well,
it
makes
sense,
or
it
is,
should
be
in
the
opposite,
because
in
the
future
we
may
include
some
information
in
the
dashboard
outside
of
the
rails
and
yeah
putin
there.
We
may
some
miss
some
business
information,
so
I
think
the
handbook
is
the
like
more
emotionally
replaced
documents.
A
I
I
would,
I
would
argue
against
that,
because
we
like
we
keep
a
list
of
most
of
our
metrics,
because
it's
not
always
up
to
date
inside
the
documentation,
like
all
the
metrics,
that
gitlab
rails
emits
should
be
in
the
documentation
in
gitlab
rails,
but
also
we've
moved
workhorse
into
that
repository.
A
So
the
only
other
component,
like
the
other,
only
other
gitlab
component,
two
gitlab
components
that
are
not
in
there
are
a
good
lab
shell,
italy
yeah,
but
we
do
have
like
development
documentation
for
getting
gitlab
shell.
In
that
repository,
I'm
going
to
add
links
to
the
add
links
to
the
documentation
that
already
exists
to
that
issue
that
we're
now
discussing,
and
I
think
we
can
continue
there
to
see
where,
where
it
ends
up,
but
that's
a
good
idea.
Both
places
should
have
a
mention
at
least
to
mention
both
the
handbook
and
the
development.
B
C
A
At
some
point,
when
I
was
building
the
mapping
andrew
started
this
and
that's
why,
like
we
worked
in
parallel
and
we
kind
of
pushed
things
forward
fast,
so
andrew
would
be
unblocked
on
this.
I
think
he
was
talking
about
adding
new,
recording
rules
and
stuff
to
be
able
to
show
something
useful
there,
but
I
don't
know
where,
because
yeah
andrew
was
in
a
bit
of
a
finish
everything
before
my
leave
kind
of
rushed.
So
I
didn't
dig
like
I
didn't
ask
more.
B
So
my
having
had
a
look
through
the
project
and
especially
seeing
how
big
the
communication
issue
is,
I
think
that
this
should
be
its
own
epic
and
it
should
be
removed
and
sort
of
separately,
because
I'm
already
starting
to
see
it
getting
bigger,
and
I
think
that
if
we
control
what
is
happening
in
each
project
a
little
bit
differently,
I
think
we've
got
a
better
likelihood
of
like
shipping
impactful
projects
and
just
having
it
like
the
sprawl
happening.
B
So
I
think
a
task
for
me
is
I'm
gonna
make
this
a
new
epic
and
split
this
out
from
the
project.
A
Okay,
we
should
have
a
chat
with
andrew
about
that
when
he
gets
back,
because
I
think
he
had
a
vision
on
it,
but
I
like
I,
don't
have
it
yet.
B
Well,
I
think
when
all
of
the
projects
are
split
out,
it
will
become
easier
to
see
it
as
well
because
like
if
I,
if
I
lay
out
how
I
think
the
project
goes,
I
think
we've
created
the
generic
dashboards.
B
We
now
start
the
conversations
with
the
stage
groups
and,
at
the
same
time,
produce
any
customizations
or
removals
or
documentation,
like
all
of
that
stuff
happens
in
parallel,
but
another
thing
that's
happening
parallel
is
also
the
slis
for
stage
group
dashboards.
So
it's
almost
like
there's
two
completely
separate
streams
of
work
that
happen.
A
Regarding
the
customization
would
before
we
even
start
reaching
out
to
the
like
the
global,
well
global,
like
every
all
stage
group,
should
we
because
last
week
I
was
in
incidence
with
cheshire
a
few
times,
and
I
saw
that
they've
kind
of
cobbled
together
a
bunch
of
metrics
regarding
their
features
that
I
think
are
useful,
but
they
could
be
improved.
They
have
their
own
alerts,
that
kind
of
stuff.
A
So
maybe
we
could
just
sit
down
with
checkers
at
some
point
in
the
new
year
and
just
see
what
they'd
like
to
add
and
that
way
we
have
an
example,
and
we
know
what
to
document,
and
then
we
can
throw
that
documentation
out.
B
Yes,
I
think
like
use
them
as
the
the
first
he's
verified.
Isn't
he.
B
So
I
think,
then,
what
we
do
is
we
use
verify
as
the
first
group
so
I'll,
create
the
epic
for
verify
I'll,
create
the
issue
for
that
I'll,
create
issues
for
the
teams
inside
of
there.
But
I
think
we
have
the
conversation
with
gregorish
and
see
what
it
is
they
need,
but
I
think
before
we
have
that
first
conversation,
even
though
it's
going
to
be
with
him,
we
need
to
have
that.
B
We
need
to
have
the
video
tutorial
that
at
least
introduces
this
as
like
at
like
a
director
level
or
like
a
a
really
high
level.
Introduction
to
this
is
the
dashboards,
and
this
is
what
they
are
and
we
need
some
sort
of
high
level
documentation
as
well.
It
doesn't
have
to
be
like
all
the
way
down
to
like
the
absolute
fine-grained
details
of
everything,
but
we
have
to
have
something
that
goes
with
the
first
communication,
and
we
can
improve
that
as
we
communicate
with
more
groups.
A
B
I
think
we
we
definitely
need
that,
but
I
don't
think
that
when
we
communicate
that
out
to
the
stage
groups
that
that's
what
they're
interested
in
then
like
the
very
first
look
that
they
get,
what
do
these
boxes
mean?
How
do
I,
how
do
I
connect
what
I
see
on
the
screen
to
what
I'm
coding
every
day
and
what's
running
on
infrastructure?
B
I
don't
think
that
they're
necessarily
interested
in
okay,
certain
symmetric
over
here,
and
then
it
gets
sucked
into
this
piece
here
and
then
it
lands
up
over
there
they're
just
like
what
am
I
seeing
there's
a
lot,
there's
a
lot
going
on
in
some
of
those
graphs
and
what
how
do
they
know?
What's
bad.
A
But
I
mean
more
like
because
right
now,
there's
no
easy
way
to
get
to
those
dashboards
like
how
do
you
find
them?
Well,
I
have
no,
I
don't
I
don't.
I
don't
know
how
to
find
them.
I'm
asking
because
me
and
juan
min.
We
know
where
they
are
we'll
find
them
well.
B
Well,
I
think
that's
part
of
the
that's
part
of
it.
Let's
start
with
group
right
so
in
the
epic
it
is,
you
know,
scalability
is
reaching
out
to
verify
so
that
we
can
give
you
information
about
this.
This
is
where
you
find
it.
This
is
the
documentation.
This
is
the
tutorial.
A
B
So
I'm
gonna
change
665
to
be
the
top
level.
Like
the
high
view
information
about
this,
that
will
be.
That
will
be
the
first
communication
that
will
be
like
the
first
pack
that
we
give
out.
C
A
Yeah,
I
think
for
that.
It
might
also
be
interesting
to
include,
for
example,
ben
from
from
the
observability
team,
who
have
like
a
deep
knowledge
on
how
these
prometheus,
like
what
these
things
that
prometheus
spits
out
for
us
mean
and
like
what
the
queries
mean
and
how
yeah
I
don't
think.
We
need
to
repeat
the
promql
documentation,
but
it
might
help
to
add
some
examples
and
then.
B
B
So
interesting
is
because
the
whole
team
has
looked
at
this
stuff
for
a
year
and
we've
forgotten
what
it
looks
like
when
it
looks
new
and
that's
why
I
think
it's
so
important
to
have
that
view
on
it,
because
other
people
are
going
to
look
at
it
with
the
same
way
that
you
look
at
it
and
go
what
on
earth
does
this
mean?
I
do
not
know,
and
that's
so
we
have
to
capture
that
somewhere.
But
beyond
that,
I
think.
B
Beyond
that
point,
we
wait
for
the
information
that
comes
in
from
other
people
and
the
questions
that
come
in
and
how
we
then
build
it
out
further
than
that,
because
I
know
if
we
just
if
we
start
writing
this
stuff
down,
it's
going
to
take
us
a
long
time
and
meanwhile
people
can
get
more
comfortable
with
it
and
not
need
everything,
but
we
need
to
at
least
show
them.
B
B
I
think
we've
is
we've
sort
of
covered
everything
in
here.
I
think
the
main
the
most
important
thing
bob.
Will
you
have
a
time?
Will
you
have
time
to
record
that
that
high
level
run
through
for
marin.
B
Okay,
any
other
thoughts
or
anything
else.
We
should
talk
about
with
the
last
five
minutes.
C
B
Well,
I
I
drew
up
this
massive
table
last
night
and
then
I
thought
to
myself.
Oh
dear,
this
is
very
big.
So
then
I
went
to
bed
to
deal
with
it
tomorrow,
but
I
think
that
what
so,
I
think
that
the
first
thing
is
just
to
to
split
each
of
the
groups,
so
each
so,
for
example,
verify
we're
going
to
create
their
own
epic
for
them,
and
I
think
we
will
reach
out
to
them
independently.
B
First,
so
before
we
tell
all
the
other
stages
that
the
stuff
exists,
we'll
go
straight
to
verify
and
we'll
tell
them.
These
are
your
dashboards.
These
are
the
tutorials.
Let's
have
a
conversation,
because
gregorish
is
super
interested
and
has
already
engaged
with
us
in
this
and
at
the
same
time,
marin
has
a
conversation
with
some
of
the
directors
coming
up
and
he's
going
to
be
using
that
tutorial.
B
That
bob
creates
to
tell
the
directors
that
this
is
coming
and
by
that
stage
we
should
hopefully
have
had
that
communication
with
verify,
and
we
all
know
what
kind
of
changes
are
needed
and
should
be
made
and
from
there
we
can
finish
building
the
communication
plan
out,
because
I
don't
know
what
kind
of
questions
they
ask
or
where
that
conversation
is
going
to
lead
and
I'm
loath
to
create,
what's
almost
like
11
epics
here
and
then
to
have
to
change
all
of
them
again
at
a
later
stage.
A
B
So
I
think,
let's
I'll
create
the
epic
for
verify
the
issue
for
continuous
integration
and
we
start
there.
Yeah
we'll
start
there
and
then
take
it.
Take
it
one
meeting
at
a
time,
but
another
question:
that's
come
to
mind
while
asking
that
do
you
have
enough
on
this
project
to
do
in
bob's
absence.
C
And
only
mentions
about
the
customization,
so
right
now
this
will
be
not
very
customizable,
so
I
can
work
on
that
during
the
break
of
everyone
and
yeah.
I
think
I
can
start
there
great.
B
A
I'm
going
to
create
those
issues
like
straight
after
this
yeah.
B
B
Great
anything
else.
B
Okay,
well
thanks.
So
thanks
very
much
for
being
on
the
call
yeah,
I'm
very
excited
about
this
project
because
it's
it's,
it
feels
like
it's
finally
connecting
the
teams
together,
the
way
that
the
way
that
I've
been
hoping
to
do
for
the
whole
year
and
it's
all
coming
together-
and
I
think
it's
also
happening
at
a
great
time
because
we
can
get
into
the
new
year
and
start
publishing
all
of
these
things
out
straight
away.
So
this
is
wonderful
and
thank
you
both
so
much
for
getting
to
this
point.