►
From YouTube: GitLab 13.1 Kick-off - Monitor:Health
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
You
hi,
my
name
is
Sarah
Waldner
and
the
SEMA
product
manager
for
the
monitor
stage,
Health
Group.
This
is
the
13.1
kickoff
call.
So
in
13.1
for
the
health
group,
we
are
still
focused
on
progressing
alert
management
and
grunty
Donato.
We
will
have
matured
it
to
minimal
and
we
are
moving
into
our
viable
plan.
We've
got
a
handful
of
scenes
for
this,
milestone
that
I'm
going
to
dive
into
first
and
foremost
for
developing
an
identification
scheme
for
alerts
that
people
are
sending
they
get
lab
from
their
external
services,
so
that
we
can
do
alert.
Deduplication.
A
Identifying
and
deduplicating
alerts
is
really
important.
The
triage
workflow!
Imagine
your
triaging
analyst
of
alerts,
and
you
know
there's
an
alert
storm
going
on.
You
don't
want
specific
items
for
each
event
of
an
alert
that
comes
in
you
want
get
lab
to
identify.
Those
is
all
of
the
same
alert
and
provide
you
one
view
for
that
alert.
So
there's
two
different
ways
that
you
can
identify
an
alert
one
is:
we
can
give
the
user
the
ability
to
define
the
schema
themselves.
A
So
that's
part
of
13.1
is
we're
enabling
the
user
to
set
what
we
are
calling
the
fingerprint
attribute
on
an
alert
where
they
map,
whatever
value
they
want
from
their
external
or
to
that
fingerprint
field,
and
whenever
an
alert
comes
in
with
that
fingerprint,
we
are
grouping
them
together.
The
other
way
to
do
this
is
to
I
to
create
that
identification
schema
ourselves.
So
the
kit,
lab
definition,
is
going
to
be
a
concatenation
of
different
fields
within
the
alert
payload.
A
The
next
handful
of
features
that
we're
working
on
for
alert
management
are
all
focused
around
streamlining
the
triage
of
alerts
in
a
list
and
then
adding
functionality
and
features
to
the
detailed
view
of
those
alerts.
All
of
this
is
to
help
a
responder
to
quickly
understand
and
find
important
information
when
they're
working
in
a
firefight,
so
first
up
is
organizing
alerts
by
status
in
a
ListView,
so
just
checking
out
the
design
for
that
here.
We've
got
our
alerts
list
within
gitlab
when
someone
starts
working
on
an
alert.
A
Very
common
thing
for
them
to
do
is
to
change
the
status
of
it
to
acknowledge.
This
indicates
other
people
on
the
team
that
this
alert
is
in
fact
being
investigated
and
someone
is
owning
it
once
that's
been
moved
to
acknowledge
someone's
identified
a
problem
and
remediated
it,
or
perhaps
the
system
stabilizes
by
itself.
That
alert
is
going
to
change
to
resolved.
That's
another
state
for
an
alert
that
we're
going
to
support
in
get
lab.
Each
of
these
states
represent
something
different
that
a
responder
needs
to
do.
A
A
So,
following
on
this
issue
in
13.1,
we
are
adding
the
ability
to
assign
alerts,
we're
going
to
use
the
same
component
as
we
do
for
issues,
and
it's
going
to
look
like
this.
So
this
is
an
important
part
of
the
triage
workflow.
Imagine
I'm
an
incident
commander,
I'm
creating
my
alert
list.
I
have
new
items
that
have
come
in
at
the
top
I'm
able
to
assign
this
to
different
team
members
so
that
they
know
they're
responsible
for
investigation
and
me
as
the
incident
commander.
A
I
can
assign
a
handful
of
different
alerts
to
different
team
members
to
make
sure
I
have
full
coverage
of
different
problems.
That
may
be
happening
in
the
services
that
I'm
responsible
for
a
common
pattern
within
get
lab
with
Marg
requests
or
incidents.
When
something
is
assigned
to
you,
we
create
a
get
lab
to
do
for
that
individual.
So,
as
we
are
adding
the
ability
to
assign
alerts,
we
are
also
going
to
be
adding
gitlab
to
do's
for
alerts.
A
So
when
you've
been
assigned
an
alert,
we
create
a
get
lab
to
do
for
you
so
that
you
are
notified
using
to
do
a
very
common
notification,
patterning
gitlab
and
we
can
further
integrate
alert
management
into
the
common
patterns
that
our
users
of
gitlab
are
used
to,
and
then
last
but
not
least,
and
13.1
will
be
sending
alerts
to
slack.
So
we
have
a
slack
notification
service
that
you
can
turn
on
and
activate
for
any
gitlab
project.
There's
a
handful
of
development
pipeline
events
that
you
can
send
a
slack.
A
You
can
send
issues
to
slack
creation
updates.
Deletions
slack
is
often
uses
a
central
communication
platform
where
users
are
notified
of
a
bunch
of
different
events,
assistance
applications,
monitoring
that
they're
responsible
for
so
we're
going
to
follow
that
same
pattern.
That
gitlab
has
within
their
slack
notification
service
and
add
alerts
to
it.
That's
it
for
the
monitor
health
group
in
13.1.
Thank
you.