►
From YouTube: Monitor:APM Weekly Meeting - 2020-06-24
Description
Weekly meeting for the Monitor:APM team
A
B
B
A
Think
we
started
working
on
this
last
fall
or
sometime
I.
Think
we
we're
looking
at
this
I
think
David
started
on
it
and
had
some
implementation
that
we
ended
up.
Just
closing
I
think
the
worry
which
I'm
not
saying
we
shouldn't
do
this
I
think
at
the
time.
The
concern
was
that
users
who
had
priority
and
these
weights
their
dashboards
might
change
order
on
them.
I'm,
not
sure,
that's
a
big
issue
or
not
I
think
one
of
the
options
was
gonna
be
to
if
it
had
priority
and
weight,
then
use
it
otherwise
sorted
by.
A
D
B
E
B
G
C
G
C
D
C
A
B
G
We'll
keep
following
up
there.
I
mean
I
just
realized
that,
since
we're
moving
in
cluster
held
metrics
to
core
we're
gonna
end
up
moving
the
e-file
to
core.
So
if
this
issues
probably
related
to
that
other
one
and
the
cluster
health
issues
scheduled
for
this
release,
so
I'm
just
gonna.
Try
to
link
that
to
you.
B
G
F
So
today,
I'm
just
been
looking
at
our
metrics
dashboard
and
noticed
a
few
things
that
I
think
can
be
improved.
So
currently,
the
default
out
of
the
box
dashboard
is
called
default
and
that
doesn't
tell
the
user
anything
about
the
dashboard.
What
kinds
of
metrics
it
contains.
So
it
kind
of
you
know
if
you
have
a
very
long
list
of
dashboards,
it
makes
it
difficult
to
understand
what
what
the
dashboard
is
about.
F
F
Maybe
any
of
you
have
any
other
suggestions
on
dracu
suggested
home,
so
I'm
currently
working
on
a
design
for
setting
a
dashboard,
that's
home
screen,
and
then
the
next
milestone
will
be
implementing
that,
so
the
user
will
be
able
to
set
any
dashboard
as
their
home
screen.
So
I
think
it's
better
if
we
have
some
more
descriptive
name
that
reflects
the
kind
of
metrics
are
in
that
dashboard
and
it
should
probably
be
well.
Those
are
some
pretty
common
metrics
that
econometrics
makes
sense
to
me.
But
if
you
have
better
suggestions
to
let
you
know
yeah.
C
I
just
follow
the
same
pattern
as
we
are
doing
with
the
rest
of
our
dashboard
naming
and
we
are
using
the
Alpha
and
that's
the
name
of
the
amplifier.
So
I
said:
let's
do
that,
if
not
also
added
some
in
the
issue
itself,
like
maybe
like
general
metrics
or
overview,
and
we
can
also
do
that
and
originally
I
think
I
thought
that
what
made
more
sense
is
to
break
this
dashboard
into
separate
dashboard.
C
Yeah,
that's
like
the
long
term,
but
I
think
right
now,
just
just
renaming
from
default
because
default,
just
like
it
has
like
some
meaning
around
around
it
and
I
need
that
this
is
not
right.
Man
for
dashboard,
so
maybe
like
a
quick
solution
for
now.
Let's
change
it
and
then
think
about
how
to
break
it.
B
F
So
a
related
idea
was
to
remove
the
dot
VM
file
extension
from
the
dashboard
names
in
the
dashboard
drop-down.
So
I
noticed
that
we
just
take
the
name
file
with
this
extension
and
I
think
we
should
just
drop
the
extension
and
just
use
just
show
the
name,
because
the
user
is
done
browsing
the
files,
the
user
is
speaking
dashboard,
even
though
in
the
background
who
are
changing
the
files.
B
B
C
Well,
I
think
when
you
create
a
dashboard
and
when
you
create
a
dashboard,
if
we
will
work
with
the
with
the
UI,
then
we
will
specifically
ask
to
use
a
dashboard
name
and
behind-the-scene
will
just
use
the
use
easy
to
populate
the
file
name.
So
we
can
do
that.
Maybe
we
can
automatically
also
populate
the
dashboard
key
with
this
name
as
well.
I.
B
C
H
F
C
I
think
it's
I
think
it's
important
to
understand
what
are
the
settings
that
we
will
give
the
users
to
change,
and
this
will
probably
dictate
the
permission
level,
not
sure
what
it
is
today.
But
if
it's
like
setting
up
time
like
UTC
and
stuff
like
that,
I
think
we
should
let
developers
do
that.
But
if
it's
just
I
don't
know
like
simple
things,
then
we
should.
C
F
The
in
the
settings
we
have
the
dashboard
cam
zone,
so
you
can
choose
between
UTC
and
the
users
time
zone,
and
you
can
also
add
the
external
dashboard
URL.
So
to
me
it
seems
like
that,
for
time
zone
it
should
be
available
to
any
user
to
developers
as
well,
but
external
dashboard,
URL,
it's
something
probably
like
the
owner
or
maintain
of
the
project,
should
define.
B
F
B
And
by
the
way,
if
we
are
looking
at
splitting
the
requirements
for
each
each
setting,
that
will
be
a
larger
change
than
simply
making
all
those
settings
available
to
say
developer
role,
because
the
way
it's
currently
made
is
it's
such
that
it
just
takes
one
setting.
So
if
you
want
to
break
it
up,
that'll
be
a
larger
issue.
F
Okay,
cool
that
helps
and
I
promise.
The
last
question
so
as
I'm
working
on
this
setting
dashboard
as
a
homescreen
I've
been
wondering
about
the
use
case.
So
do
we
want
to
allow
only
maintainer
or
the
owner
of
the
project
to
set
a
specific
home
screen
and
then
that
home
screen
will
be
displayed
for
everyone
who
uses
metrics?
F
C
But
it
will
not
be
our
responsibility
to
keep
them
up
and
running,
and
basically
it's
not
doesn't
make
sense
for
us
to
do
that
and
then,
when
they
decide
that
it's
the
time
they
will
turn
off
your
phone
and
whoa.
So
there
are
like
clear,
theorize
who's
doing
what
and
why
will
still
need
to
refine
a
bit
more
than
the
demo.
But
those
are
this
is
the
highlights
of
so
any
questions
around
this
process.