►
From YouTube: GitLab 13.4 kickoff - Monitor:APM
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
Hi
everyone,
my
name
is-
and
this
is
the
apn
13.4
kickoff
video
in
this
video-
I'm
going
to
walk
you
through
some
of
the
highlights
we
have
for
this
iteration
to
start
with
the
goal
of
the
milestone
go
number
one.
We
want
to
continue
the
work
that
we
started
in
the
previous
iteration
on
the
add
metric
and
in
this
understa
in
this
iteration
we
are
going
to
focus
on
mvc2,
which
is
focused
more
toward
the
back-end
work
that
we
need
to
do.
A
A
Now,
let's
go
over
the
issues.
Issue
number
one
add
metric
mvc2
and,
as
I
mentioned
in
this
epic,
we
are
going
to
focus
more
on
the
backend
part,
so,
as
you
probably
will
in
the
first
iteration
mvc1,
which
we
just
just
released,
we've
added
the
preview
of
an
add
panel.
So
whenever
a
user
wants
to
add
the
panel,
they
need
to
define
the
yaml
and
once
they
are
done
with
that
user
are
able
to
view
how
this
panel
will
look
like
and
now
in
this
iteration.
A
We
want
to
continue
this
workflow
and
allow
the
user
to
actually
add
that
panel
into
a
metric
dashboard,
because,
right
until
now,
user
will
need
to
take
this
yaml
definition
copy
paste
it
manually
into
the
yaml
file,
and
we
want
to
do
it
automatically
for
them.
So,
basically,
we
want
to
cover
this
entire
workflow
of
adding
a
metric
preview
metric
and
then
doing
the
commit
in
order
to
update
the
dashboard
with
the
new
with
the
new
panel.
A
We
believe
that
this
will
improve
the
user
experience,
because,
right
now,
whenever
user
touch
any
control
in
the
dashboard,
they'll
need
to
reload
the
entire
dashboard
and
it
is
not
recommended,
especially
if
you
have
like
multiple
charts
and
you
have
multiple
backend
calls
to
promote
use,
and
basically
this
is
not
the
user
experience
that
we
want.
We
also
saw
that
other
solutions,
such
as
grafana,
do
understand
the
same
experience,
so
definitely
something
that
will
improve
our
experience.
A
Issue
number
three
is
a
spike
issue.
Storing
the
dashboard
in
a
database
and
despite
the
spike
issue,
actually
came
out
out
of
our
objective
to
have
a
singular
experience
for
both
out
of
the
box
and
custom
dashboard.
Today,
it
is
very
confusing
for
our
users
that
will
have
two
types
of
dashboard
and
different
actions
that
are
that
they
can
do
on
those
dashboards.
A
We've
seen
with
some
of
the
telemetry
work
that
we've
been
collecting,
that
the
fact
that
we
have
two
separate
workflows
or
actions
for
those
dashboard
actually
helping
our
hurting
our
users
and
without
helping
our
ability
to
to
gain
more
adoption.
So
storing
those
dashboards.
A
We've
also
done
a
spike
issue
in
two
iterations
ago,
and
and
the
purpose
of
of
this
of
this
epic
is
to
make
sure
user
will
be
able
to
quickly
see
metrics
in
the
dashboard,
because
today,
whenever
you
define
a
promoter's
instance,
and
it
doesn't
matter
if
it's
an
internal
on
the
external
one,
you
need
to
create
an
environment,
and
it's
not
a
good
user
experience,
and
we
want
to
allow
our
user
to
connect
parameters
into
github
and
immediately
see
metric
dashboard.
A
They
want
if
they
want
to
add
environment,
they
can
do
that,
but
this
should
not
be
like
another
barrier
for
him
for
them,
seeing
metrics
in
a
dashboard.
So
we
want
to
this
would
probably
this
is.
This
is
an
ethic
that
will
spend
because
multiple
iterations,
you
want
to
start
the
preparation
work
same
with
issue
number
five,
and
this
is
also
something
that
will
spa
an
epic
that
will
span
across
multiple
iterations
the
purple
for
supporting
multiple
committees.
A
Instances
we've
seen
in
real
both
scenarios
that
users
have
more
way
more
than
a
single
prometheus
instance,
and
they
want
to
connect
it
to
gitlab.
If
you
have
like
multiple
clusters,
you
have
like
multiple
parameters,
so
you
want
to
make
sure
you
have
high
availability.
A
You
have
multiple
parameters,
so
there
are
a
lot
of
use
cases
where
users
are
using
that
and
we
want
to
allow
them
to
connect
not
only
one
formative
instance,
but
as
many
as
they
like-
and
this
is
a
prep
work,
and
maybe
another
issue
to
highlight
is
issue
number
six
create
a
self-monitoring
project
by
default
for
new
gitlab
installs.
A
So,
basically,
whenever
you
have
a
new
installation
of
gitlab,
we
want
to
create
the
self-monitoring
project
by
default
out
of
the
box,
and
we
believe
that
this
will
increase
the
exposure
that
we
have
on
the
metric
users
and
that's
it.
And
if
you
have
any
questions,
feel
free
to
reach
me
or
you
can
ping
me
on
this
issue
thanks.