►
From YouTube: Monitor:APM Weekly Meeting - 2020-08-05
Description
Weekly meeting for the Monitor:APM team
A
B
We
finalized
the
protocol
for
q3
and
I
wanted
to
make
sure
we
are
verbalizing
them
and
obviously
taking
a
question.
There
is
an
mr,
so
you
can
ping
me
on
that
ml
as
well,
and
so
basically
in
this
quarter,
we'll
try
to
make
sure
and
the
goal
we
define.
The
goal
is
to
enable
gitlab
user
to
be
able
to
display
any
metric
on
any
gitlab
dashboard
from
any
prometheus
instance
or
instances,
and
basically
want
to
make
this
experience
as
easy
and
smooth
as
possible
and
we've
captured.
B
Three
kills.
One
has
been
able
to
connect
multiple
parameters,
instances,
and
this
will
be
followed
by
the
issue
around
implementing
or
connecting
multiple
prometheus
instance.
There's
a
spike
issue
that
is
undergoing
and
hopefully
will
be
followed
by
an
implementation
issue.
B
Implementation
issues
and
one
of
the
things
that
we've
realized
is
that
in
real
world,
users
tend
to
have
more
than
one
prometheus
instances
for
for
multiple
reasons,
and
one
is
that,
obviously
it's
not
it's
not
scalable,
it's
not
high
available.
B
So
sometimes
they
have
like
more
than
one
and
sometimes
you're
talking
about
like
different
clusters
and
different
locations
and
spread
across
different
geographical
locations,
and-
and
this
is
why
users
tend
to
have
more
than
one
prometheus
instance,
and
so
today,
as
you
know,
we
can
only
connect
a
single
committee's
instance
and
we
want
to
make
sure
to
accommodate
a
real
world
scenario.
So
this
is
the
first
kr
and
one
more
thing
to
add
is
that
we
are
leaning
towards
making
this
feature
a
premium
feature
based
on
our
buyer
model.
B
And
so
obviously
it
is
more
likely
that
if
you
have
like
multiple
prometheus
instances,
then
you're
talking
about
a
full
team.
So
this
is
why
we
believe
that
this
specific
feature
need
to
be
like
a
paid
feature.
So
as
a
user,
if
I'm
starting
to
work
on
on
on
on
my
metrics
use
case,
I
can
be
very
successful
with
a
single
one.
B
I
can
see
how
it
works
and
then,
when
I
want
to
connect
more,
then
this
is
where
I
should
probably
purchase
the
paint
like
purchase
it
as
a
paid
feature
and
the
second
one
is
the
add
metric
to
a
custom,
dashboard
workflow,
and
this
is
like
the
big
epic,
the
big
thing
that
we
are
walking.
We
start
to
work
in
this
iteration
and
we'll
continue
to
work
on
that
in
the
following.
B
It's
not
and
the
second
one
is
around
logging,
because
you
know
we
have
like
two
pillars:
one
for
metrics
and
one
for
logging
is
to
make
sure
our
user
will
be
able
to
view
all
logs
across
the
entire
kubernetes
cluster
in
gitlab
ui.
Today,
users
are
able
to
see
the
logs
that
are
coming
from
the
deployed
application
to
a
ci
job
and
we
recently
added
the
option
for
maintenance
to
see
logs
that
are
deployed
in
the
manage
in
the
gitlab
manage
app
namespace.
So
those
are
the
applications
that
we
deploy
for
the
user.
B
But,
as
you're
probably
aware,
we
want
to
accommodate
a
real-world
scenario
in
the
real-world
scenario,
the
deployed
application
and
the
managed
gitlab
application
is
just
a
subset
of
the
services.
Sometimes
the
miner
subset
of
all
the
services
and
applications
are
deployed
to
a
cluster
so
having
this
ability
to
expose
and
surface
all
the
logs
from
all
the
cluster,
helping
our
users
with
the
problem,
the
challenge
of
searching
to
and
aggregated
logs
will
be
very
helpful.
So
this
is.
B
Thanks
and
the
second
issue
is
around
alert
related
bugs
and
issues,
so
obviously
we
want
to
make
sure
that
our
decisions
are
data-driven
and
we've
seen
that
the
number
of
users
that
are
using
our
alerting
feature
is
not
high
we're
talking
about
less
than
10
in
in
a
month.
So
when
I
come
to
prioritize
features
that
or
bugs
that
are
related
to
to
alerting,
I
probably
won't
put
them
as
like
p1
or
p2,
unless
it's
like
something
that
is
critical
like
broken
functionality,
and
so
I
just
want
to
provide
this
message
to
the
team.
B
So
if
you
are
opening
a
bug
about
alerting
and
you're,
not
sure,
what's
the
priority,
you
can
ping
me,
it
is
probably
more
likely
that
we'll
schedule
other
more
impact
high
impact
bugs
around
metrics
around
blogging
and
we'll
prioritize
them
over.
Overall.
Now,
I'm
not
saying
that
we're
going
not
going
to
invest
in
alerting.
There
will
be
a
time,
then
we'll
start
working
on
alerting
but,
as
I
said,
alerting
is
like
something
we
build
on
top
of
our
of
our
metrics
and
logging.
B
So
once
we
have
like
our
log,
our
metrics
will
be
in
like
in
a
better
shape.
This
is
where
we
can
start
focusing
on
question
around
the
second
item.
B
The
third
one
is
is
just
an
fyi.
A
I
message
is
on
slack,
so
I've
created
an
epic
to
capture
all
the
improvement
that
we
have
around
visualization
and
I've
created
sub
epic
for
each
each
type
of
visualization,
heat
map,
stack,
column,
column,
chart
bar
chart
and
so
on
and
so
forth.
So
it
will
be
easier
for
all
of
us
to
track
and
identify
those
related
issues.
B
So
when
you're
opening
issues
on
different
visualization
try
to
map
them
to
the
right
to
the
right
sub-epic
and
in
the
coming
iteration,
we
are
going
to
implement
telemetry
to
understand
what
is
the
usage
from
our
users
on
those
visualization,
and
it
will
help
us
prioritize
the
work
on
improving
those
visualizations.
So,
obviously,
if
we
see
that
more
users
are
using
a
line
chart
and
then
area
chart
or
or
something
else,
then
we
can
prioritize
those
features
over
over
the
other.
B
C
Cool
yeah,
I
just
wanted
to
share
real
quick
matt,
and
I
are
going
to
work
on
this
okr
for
q3
from
an
engineering
perspective,
we
want
to
work
to
reduce
the
frequency
of
new
bugs
are
introduced,
so
I
realized
the
way
the
title
is
set
up
is
a
little
bit
confusing,
but
we
just
picked
a
random
number
to
start
with,
like
the
goal
of
reducing
the
new
bugs
introduced
by
30,
and
then
the
arrow
shows
zero
percent
progress
and
not
to
say
they
will
never
have
any
bugs.
C
That
would
be
unrealistic.
So
what
we
plan
to
do
is
trying
to
to
do
some
metrics.
First
logging
kind
of
kind
of
what
new
bugs
have
been
introduced
in
the
quarters
and
then
the
months
trying
to
identify
any
common
themes
so
similar
to
what
sophia
has
been
talking
about
in
the
past
doing
some
more
retrospective
stuff
on
the
bugs
to
try
to
see.
If
we
can
draw
some
common
themes,
maybe
there
are
certain
things
that
we
could
get
better
at
and
then
try
to
see.
C
If
there's,
maybe
some
new
process,
we
can
introduce
or
training
or
measures
to
reduce
the
bugs.
I
think
we've
done
a
really
good
job,
getting
really
good
velocity
over
the
last
quarters.
Increasing
mr
rate,
but
in
my
opinion
there
is.
It
feels
like
there's
a
lot
of
bugs
being
introduced,
or
at
least
not
good
stability
and
so
not
to
point
anyone
out,
but
this
is
just
something
that
we
can
do
as
a
group
to
kind
of
raise
the
bar
in
our
efforts
as
we
continue
to
move
forward.
C
So
if
anyone
is
interested
in
participating
and
helping
out
in
this
process,
please
check
me
on
the
issue.
It
is,
you
know,
quite
a
big
scope
and
we
definitely
welcome
anyone
who
is
interested
in
helping
out
to
help
out
that's
about
it.
Matt
did
you
want
to
highlight
anything
else.