►
From YouTube: Discuss Dogfooding of Monitor Features
Description
Discussion between Monitor Stage teams and Infra
A
Okay,
recording
cool
and
then
I'll
show
my
screen,
so
the
intent
of
this
conversation
is
that
Devin,
it's
my
understanding
that
you
are
a
part
of
the
infrastructure
team
that
is
kind
of
I,
guess
you're,
maybe
personally,
in
charge
of
the
project
to
have
other
non
gitlab,
comm
properties,
utilize,
more
auto,
dev,
ops
and
other
functionality,
and
so
I
am
particularly
interested
in
this
team.
Is
a
group
of
folks
from
the
monitor
stage
and
interested
in
how
you're
doing
that.
A
If
we
can
help
you
figure
out
other
parts
of
the
tool
that
you
of
the
product
that
you
aren't
using
for
the
monitoring
of
the
various
properties
and
maybe
also
I'd
love
to
get
your
kind
of
roadmap
for
which
properties
are
going
to
be
brought
on
into
this
process
and
how
you
manage
them.
So
it
would
be
good
to
start
with,
like
an
intro
of
your
of
that
effort
on
your
part
and
kind
of
what
your
goals
of
it
are.
Yeah.
B
So
what
the
way
we're
thinking
about
it
is:
we've
got
kind
of
our
core
gitlab
comm
site,
and
then
we've
got
non
core
properties
and
the
non
core
stuff
is
mostly
support
tools,
things
that
that
are
part
of
the
whole
offering,
but
not
actually
part
of
yet
lab
the
product.
So
it's
things
like
the
licensing
tool,
the
customers
tool.
B
We've
also
got
things
like
the
forum,
you
know
the
user
forum
and
the
design
tools
the
pajamas,
so
those
things
are
non
core
they're,
not
really
part
of
the
get
lab
product,
but
we
still
run
them
as
production
instances,
and
so
those
are
prime
for
deploying
with
auto
dev
ops.
Rather
than
trying
to
do
it,
the
the
system
administrator
way
that
we've
been
doing
it
in
the
past.
So
what
I'm
trying
do
is
set
up
all
of
the
infrastructure
parts,
the
the
tariff
lorem.
B
You
know
production
type
of
set
up,
but
not
as
part
of
our
get
lab,
comm
toolset,
because
right
now
it's
kind
of
cluttering.
Our
existing
repos
we've
got
a
lot
of
stuff
in
there.
That
is
really
a
one-off
thing
that
we
don't.
You
know
we
don't
spin
up
all
of
those
tools
when
we
spin
up
a
staging
instance
or
a
test
instance,
so
we're
trying
to
separate
all
of
that.
B
So
we've
got
all
the
tooling
that
we
use
to
run
like
a
gate
lab
comm
instance
and
all
of
the
peripheral
extra
stuff,
so
we're
standing
up
those
as
kubernetes
clusters,
with
whatever
they
need
to
to
do
the
auto
dev
ops
thing.
We've
got
some
cloud
sequel
stuff
that
we're
putting
in
there
for
persistent
databases
stuff
like
that.
The
plan
is
to
use
as
much
of
the
internal
tooling
as
we
can,
even
though
we
understand
that
at
the
moment
it's
probably
not
sufficient
for
our
needs.
As
far
as
monitoring
alerting.
B
A
A
B
For
the
design,
which
is
the
first
attempt,
we
pick
design
kind
of
arbitrarily
because
it
doesn't
have
a
database
attached
which
makes
it
easy
to
get
it
up
and
running
the
harder
part
of
the
other
ones
is
going
to
be
figuring
out.
How
we're
gonna
do
the
database
and
load
the
data
and
stuff
like
that.
So
design
was
fairly
easy.
We
set
up
the
clusters,
we've
got
two
clusters,
we've
got
one
for
production
and
one
for
the
staging
and
review
apps
that
staging
one's
kind
of
shared.
B
B
That's
probably
not
what
we
ultimately
want,
but
my
focus
was
really
on
getting
it
up
and
running
so
that
the
DevOps
pipelines
would
succeed
and
they
could
deploy
it
by
merging
and
that
was
kind
of
the
goal
for
this
round.
One
we're
gonna
have
to
be
a
little
bit
more
complete
with
some
of
the
other
stuff,
because
with
the
design,
it
doesn't
matter
so
much
if
it
goes
down
for
a
few
minutes,
whereas
if
it
goes
down
with
some
of
the
other
stuff,
it's
gonna
be
a
little
more
impactful.
B
A
Yeah,
that's
an
awesome
first
step
by
the
way
and
I
love
the
just
planned
process
for
that
I
guess.
One
of
the
things
that
we
had
had
in
the
discussion
in
this
issue
was
like.
Can
we
help
you
gain
familiarity
with
the
monitoring
tools
and
also
what's
kind
of
coming
in
the
roadmap
and
I
would
also
love
to
see
any?
A
B
B
I'm
also
on
call
this
week,
so
I'm
pretty
much
putting
the
whole
effort
on
hold
until
early
next
week,
but
if
there's
some
easy
way
to
digest
it,
if
there's
some
like
screencast
or
anything
that
you
guys
have
that's,
it
wouldn't
require
sitting
down
and
reading
pages
and
pages
of
documentation.
Yeah
awesome.
A
C
A
So
what
I
thought
Devon
is
I
could
just
briefly
show
you
in
the
settings
for
design
I
got
myself
admin
permissions
here.
I
could
show
you
kind
of
what
monitoring
you
have
today
and
like
this
is
all
out-of-the-box,
because
you
installed
nginx,
then
you
get
these
three
sets
of
data
I,
don't
think
there
are
any
default
alerts
configured
for
any
of
them,
but
you
could
easily
define
a
query
and
an
alert
threshold.
A
Actually,
it
looks
like
that's
already
been
set
here,
but
no
templates-
these
are
just
create
dummy
wants,
but
you
could
also
set
it
up
so
that
it
is
creating
issues
for
you
based
on
a
template.
That
is
the
thing
that
I'm,
like
as
a
product
organization,
we're
most
interested
in
getting
feedback
from
dogfooding
of
that
entire
loop,
like
I,
could
an
Auto,
DevOps
project,
I
set
up
some
alerts
and
then
I
am
having
it
create
incidents
for
me
and
are
those
incidents?
A
Can
I
configure
those
incidents
efficiently
so
that
I
could
actually
triage
and
resolve
that
incident,
and
we
don't
have
anyone
frankly
using
that
in
any
sort
of
production
way
today.
So
that
is
the
thing
that
was
most
interesting
to
me.
I,
don't
know!
If
that's
interesting
to
you,
if
that,
like
breaks,
how
your
process
works
today,
it.
B
Could
be
there's
a
couple
questions
that
pop
up
right
away
is:
how
do
we
get
that
to
go
to
something
like
pager
Duty?
Is
it
just
doing
that,
or
can
we
set
up
integrations
like
a
slack
integration
where
it
goes
to
into
slack
or
whether
it
if
it
goes
to
pager
duty
and
calls
one
of
their
web
hooks,
then
we
can
get
it
into
our
workflow?
Those.
D
Yeah,
we
do
have
a
slack
MVC
one
that
would
hook
up
like
incident
creation
with
posting,
something
in
slack
and
then
being
able
to
use
like
chat
apps,
to
interact
with
that.
We
don't
really
have
any
pager
Duty
integration
right
now,
but
that
is
something
we
want
to
do.
I'm,
not
I,
don't
think
we
don't
really
haven't
designed
out
like
I'm,
not
sure
what
where
those
connections
would
be,
but
you
know
I.
That
is
a
it.
Definitely.
It
feels
like
something
that
we
need
to
do
to
make.
This
very
useful
know.
B
B
Alert
when
certain
conditions
exceed
certain
thresholds
and
that
sends
an
alert
to
pager
duty,
pager
duty
then
has
its
escalation
path,
and
you
know
it
first
sends
a
push
message
to
the
on-duty
person's
phone.
If
they
don't
answer,
then
it'll
text
them,
then
it'll
call
them.
Then
it'll
escalate
up
to
the
next
person.
So
I
don't
know.
If
that
we
want
to
try
and
replicate
any
of
that
functionality.
It's
it's
pretty
involved
and
it's
easy
enough
just
to
call
a
web
hook.
B
The
other
thing
is
that
it
looks
like
from
this
screen
that
the
issue
is
only
opened
in
the
project.
That's
correct,
yeah,
and
we
don't
monitor
that
project.
So
if
we
do
get
an
alert
on
this,
nobody
on
the
info
team
is
gonna,
see
it.
So
if
this
could
open
a
issue
in
the
infrastructure
queue
that
would
be
a
whole
different
story,
then
we
could
set
up
a
template
that
has
all
the
right
labels
and
tags
and
the
right
people
would
see
it
when
it
happened.
A
Cool
sorry
and
then
split
screening
also
trying
to
write
stuff
like
that
down.
Those
are
all
great
issues
that
we
can
create
me
be
sure
I'm
capturing
this,
so
the
other
thing
is
Seth
probed
about
what
interaction
you
would
want.
If,
if
there
was
the
ability
to
like
check-in,
your
alert
manager,
config
and
have
that
deployed.
Is
that
a
shortcut
around
using
this
UI
based
configuration.
B
A
Shortcut
yeah
I
mean
I
would
love
for
you
to
just
be
using
generic
Auto
DevOps,
but
I
understand
that
that
is
not
sophisticated
enough
at
this
point,
but
if
we
could
have
some
weight,
it's
that
Auto
DevOps
saw
your
alert
manager,
config
and
just
deployed
it
to
the
Prometheus
cluster.
That
is
an
issue
that
I
think
we
have
in
the
upcoming
roadmap.
C
A
Are
there,
like
you
mentioned,
you
have
your
own
set
of
metrics.
The
other
thing
that
you
know
you
we
would
love
feedback
on
is.
Are
these
the
right
metrics?
Are
there
other
metrics
that
you
would
want
to
immediately
have
in
these
dashboards
that
you
consider
more
critical,
especially
for
a
project
without
a
database
like
design?
A
B
B
C
A
B
A
B
B
B
A
And
then
yeah,
it
would
be
interesting
to
see
I
don't
know
if
I
like
it
would
be
interesting
to
see
if
you
like,
wrote
your
own
alert
manager
config
for
design
get
lab
comm.
If
we
could
then
look
at
that
and
be
like.
Oh
here's
all
the
places
where
those
metrics
are
missing
and
we
should
have
included
them
or
the
types
of
alerts
and
where
you're
sending
the
alerts,
we
could
use
that
to
target
UI
improvements.
B
B
B
You
know
stuff
like
this
is
useful
for
just
a
quick
and
dirty
dashboard,
but
when
we
get
into
like
a
little
more
heavy
monitoring
like
what
we're
gonna
be
doing
on
get
live,
comm
we're
gonna
have
to
be
able
to
write
custom
queries,
so
it
might
be
nice
to
have
something
like
that
for
people
to
just
get
something
up
and
running
quick,
but
then
also
have
the
option
of
adding
your
own
yeah,
maybe
like
a
custom
option.
There.
A
Yeah
we
have
the
ability
to
add
custom,
metrics
and
alerts
on
those
custom,
metrics
I
think
day
soon,
but
I
do
think.
We
there's
like
the
data
dog
way
of
where
you
can
really
cool,
like
pull
up
the
metric
and
then
draw
where
you
want
the
threshold
to
be
both
in
terms
of
X
and
like
width
and
height
of
where
that
threshold
sits.
A
B
Yeah
he's
working
on
some
newer
stuff
that
we're
gonna
be
using
on
get
lab
comm,
eventually
that
there's
a
little
more
predictive
and
uses
algorithms
to
really
tell
if
there
is
a
problem
based
on
the
historical
data,
it
would
be
really
cool
to
have
some
of
that
stuff
in
here,
but
I
know
he's
not
ready
enough
with
it
for
us
to
even
use
it
on
get
LOD
calm.
Yeah
is.
A
He's
also
been
defining
SLO,
so
there's
this
interesting
collision
because
parts
of
the
monitor
team,
one
group
of
it,
a
PM
group,
also
is
in
charge
of
gitlab
self
monitor
and
we're
moving.
Some
of
the
monitoring
for
how
we
give
the
tooling
we
give
our
customers
to
monitor
their
own,
get
lab
instance
and
which
is
very
analogous
with
the
monitors
that
Andrew
and
others
have
forget,
lab
comm
to
use
these
features
right
so
that
the
when
a
user
is
monitoring
their
get
lab
instance.
A
They
have
a
get
lab
instance,
self
monitoring
project
that
has
dashboards
created
with
some
of
those
metrics,
so
that
is
that
is
kind
of
underway.
But
that
feels
like
much
longer
term,
whereas
you
working
on
some
of
these
smaller
non
core
ones
feels
like
we
can
at
least
get
to
where
you're
actually
doing
incident
management
in
that
full
lifecycle
with
it
sooner
rather
than
later
than
that,
as
I
said
before.
A
B
B
Every
five
weeks
we
have
a
different
person
or
it's
a
five
week
cycle.
So
we
have,
you
know:
I,
go
on
call
every
five
weeks
for
the
North
American
AIPAC
rotation
and
getting
that
kind
of
scheduling
into
the
product
would
be.
It
would
be
very
cool,
but
I
think
it
would
also
be
really
a
lot
of
effort,
and
you
know
because
Pedro
Duty
gives
us
things
like
overrides,
so
you
set
a
schedule.
A
So
you're
gonna
hate
me,
but
just
bear
with
me
as
I
describe
this.
What
if
you
had
issue
templates
like
one
for
each
individual
and
you
just
flipped
that
drop-down
on
the
integration?
Where
is
it
right
here?
That
said
which
template
you're
using
for
a
given
week,
so
you're
like
well,
this
is
who's
on
call,
so
I
chose
their
template
and
that
template
is,
you
know
obviously
part
of
that
template.
You
can
have
quick
actions
that
assigns
it
or
kings
or
add,
mentions
somebody
when
the
issue
is
created.
A
You
could
also
have
like
a
little
bada
runs
around
that
says.
Oh,
this
has
been
created
and
Devon
was
assigned
to
it
and
there
hasn't
been
a
response
in
five
minutes,
so
it
escalates
to
their
manager.
Just
like
we
have.
We
have
internal
triage
BOTS
for
doing
stuff
like
that
I'm
trying
to
figure
out
ways
that
we
could
get
you
using
this.
So
you
start
putting
feedback
into
it
for
something
like
design
without
yeah.
B
B
A
Let's
see
I,
don't
know
what
our
notification
settings
are,
but
I'm
wondering
if
you
could
manipulate
if
it,
because
it
would
be
in
this
project
and
you
would
get
mention
on
it.
You
could
have
separate
notification
settings
for
this
project,
but
yeah
you're
right
at
most
would
still
send
you
an
email
I
mean.
B
A
B
A
B
Hit
a
window
listen
to
see
where
this
process
was
that,
because
I'm
looking
forward
to
getting
feedback,
so
it
was
a
great
introduction
to
what's
going
on
so
thanks,
yeah
I'm
glad
we
can
start
started
integrating
this
stuff,
because
a
couple
weeks
ago
we
wouldn't
have
been
able
to
and
I
hadn't
really
thought
about,
monitoring
other
than
I
had
a
conversation
with
my
manager,
saying
you
know,
are
we
gonna
set
up
monitoring
for
this?
He
was.
He
was
sharing
my
opinion
that
we
should
not.
B
A
And
I
should
have
started
with
this,
but,
like
I,
consider
this
a
high
priority.
You
know
the
monitor
tools
are
great,
but
we're
gonna
be
able
to
move
so
much
faster.
If
we
haven't
some
internal
team
dogfooding
and
pointing
us
to
it,
I
I
would
appreciate
Devin
if
you
like,
made
a
little
bookmark
in
your
toolbar.
That
said,
create
a
new
CEO
and
just
anytime,
you
found
anything.
You
just
do
an
issue
and
thing
to
me
on
it.
That
is
gonna,
be
the
best
way
in
like
very
responsive
to
those.
B
A
B
Yeah
I
like
how
this
is
gonna
shape
up,
and
this
is
a
good
time
to
do
it
because
I
haven't
even
started
thinking
about
it.
Yet
so,
knowing
what
your
vision
is
when
I
do
start
doing,
it
it'll
be
easier.
So
as
far
as
the
integration
did,
what
what
I
did
on
the
design
project
is
that
sufficient
do
I?
Just
you
know,
add
the
Prometheus
pods
to
the
the
integration,
and
it
should
be
good
or
is
there
more
stuff
that
I
need
to
do
to
configure
it?
No.
A
I
mean
by
installing
Prometheus
on
the
cluster.
It
should
auto
populate
those
dashboards.
It
doesn't
set
up
any
alerts,
but
it
if
there,
if
you
did
setup
call
it,
also
create
an
incident
in
that
project
and
so
that
all
happens
by
default.
But
the
the
next
step
would
be
adding
alerts
and
creating
incident
template.
You
would
want
to
use
okay.