►
From YouTube: Monitor:APM Weekly Meeting 2020-04-15
Description
Weekly meeting for the Monitor:APM group
A
A
C
C
C
And
I
want
to
present
the
problem,
how
to
present
the
proposal
and
get
your
thoughts.
Are
there
right
now
on
the
issue?
So,
basically,
today,
if
you're
familiar
with
our
long
Explorer
and
you
can
filter
today
by
two
parameters,
you
can
drop
down
where
you
can
select
the
environment
and
the
pod
to
see
to
see
the
logs
from
that
board.
Now.
C
The
thing
is
that
if
we
have
this
drop
down
for
the
environment,
we
are
actually
limiting
our
capability
to
service
to
surface
all
the
logs.
That
elasticsearch
is
collecting
for
us,
because
a
lack,
lastic
search
actually
collects
the
logs
form,
the
entire
cluster
so
from
the
deployed
application
form
kubernetes
and
from
the
manage
apps,
for
instance,
epoxy
or
all
the
nginx.
Now.
C
So
there
should
be
some
separation
between
different
users
as
a
developer.
I
should
not
see
a
lobs
application
of
project
that
I'm
not
involved
with
now.
The
thing
is
that,
as
I
mentioned,
we
do
want
to
surface
the
other
logs
that
we
are
collecting
and
the
question
is:
how
are
we
going
to
do
that?
And
so
there
have
been
two
to
proposal.
Okay,
the
first
one
is
by
by
by
Adrienne,
is
to
create
another
love,
Explorer.
C
The
kubernetes
cluster,
as
you
see
here
like
to
add
some
sort
of
a
tab
here
for
logs
and
when
you
click
on
this
one,
you
see
only
the
logs
for
the
cluster
or
for
the
managed
apps,
so
you
probably
have
will
have
like
different
filters
and
only
specific
users
will
be
able
to
see,
because
not
everyone
are
allowed
to
go
into
admitting
I'm
a
developer
and
not
be
able
to
see
those
logs
I'll
be
limited.
When
I
look
at
the
log,
Explorer
I'll
see
a
only
the
logs
that
relevant
to
my
project.
C
If
I'm
a
maintainer
or
minister,
then
I
can
go
to
those
to
this.
Second
flavor
of
the
log
Explorer
and
I
can
see
those
bone,
so
the
pause
as
I
mentioned
is
that
there
is
a
clear
separation
between
the
logs
that
I
am
getting
form
application
and
the
logs
from
the
manager
app
and
the
cons
is
first
of
all
this.
What
I'm?
C
The
advantage
here
is
obviously
we're
using
the
single
of
Explorer.
So
there's
no
confusion,
there
is
a
single
user
flow
and
the
problem
here
that
I
see
is
we'll
have
two
personas.
Both
of
them
will
see
a
different
flavor
of
of
the
UI
of
the
low
Explorer.
So
those
are
the
two
options
that
we
have
in.
There
is
like
some
discussion
here
between
we
add
Rhiannon
and
Nadia
and
I
wanted
to
get
your
thoughts
on
that,
and
maybe
you
know
at
your
comments
either
in
the
issue.
D
C
A
I
also
think
the
option
to
keep
all
logs
in
one
interface
makes
more
sense
for
the
workflow
that
we're
solving
for
and
I
don't
see
a
lot
of
problem
with
having
different
permission
levels
to
information
within
the
logs
I
think
it
makes
sense
and
I
don't
think
it
would
come
as
a
surprise
to
someone
with,
let's
say,
developer
access
that
they
don't
have
access
to
those
types
of
logs
that
the
maintainer
would
have
access
to.
So
I
think
it
seems
like
a
much
better
solution.
E
Yeah
sorry,
it's
late,
yeah
I
want
to
go
over
some
of
the
things
that
we've
made
clear
for
what
our
expectations
for
spike
in
the
team.
So
if
you
get
a
chance,
please
take
a
look
at
the
handbook
as
well
as
2mr
link
it
kind
of
talks
about
how
we're
trying
to
be
more
explicit
with
kind
of
what
we
want
outcomes
of
spikes
to
be
expectations,
so
that
we
make
sure
that,
after
doing
a
spike
that
were
best
set
up
for
success
for
working
on
the
feature.
E
So
please
take
a
look
at
that
and
then
the
other
thing
is.
We
noticed
that
the
the
demo
hour
has
it
really
have
had
much
usage
from
the
team
we
want
to
iterate
on
it.
Originally,
it
was
created
when
the
teams
were
formed
when
monitor
was
separated
into
APM
and
health
and
as
a
way
to
kind
of
see
what
people
are
working
on,
but
over
the
recent
months
it
looks
like
the
agenda
hasn't
had
anything
so
no
one's
really
been
participating.
E
So
we
still
want
to
see
if
we
can
foster
that
original
vision
for
that
meeting,
but
we're
thinking
about
changing
some
things
and
the
health
team
has
proposed
and
created
at
issue,
so
I
want
to
broadcast
it
to
the
APM
team
to
see
if
there's
feedback
here,
that
we
can
provide
because
you'd
like
to
take
action
sooner
and
later.
So
please
take
a
look
at
that
issue
and
comment
back
to
you.
Deb.
C
From
the
story,
team
he's
also
the
DRI
for
the
dogfooding
metric
project
that
we
are
embarking
and
and
I
had
an
interesting
conversation
with
him,
as
he
walk
me
through
the
entire
feature.
The
features
that
he's
using
on
graph
on
ax.
So
there
is
the
video
and
also
some
sort
of
a
requirements,
talk
that
he
created
so
as
most
of
you,
if
not
all
of
you
are
involved
in
some
way
in
the
dogfooding
metric
project.
I
would
highly
recommend
all
of
you
to
view
this
video.
C
It's
almost
one
hour,
video
of
him
going
through
or
the
future,
and
the
required
document
has
like
very
interesting
anecdotes
and
things
that
he's
using
that
we
sometimes
may
overlook
and
don't
really
think
about
those
details
around
time
stamp
around
the
variables
that
we
are
working
on
bill
downs
in
so
encourage
all
of
you
to
go
to
that
and
yeah
I
think
it
will
provide
a
lot
of
clarity
about
where
we
are
heading.
Obviously,
the
dogfooding
metric
is
a
project
that
we
will
continue
to
focus
on
in
the
coming
iteration
and
so
yeah.
D
D
C
C
Yeah
we
can,
we
can
set
up
ball
time
with
with
Andrew
and
asked
him
specifically
to
discuss
it
on
this,
but
I
think
we
have
quite
a
lot
of
issues
that
we
can
take
on
regardless,
so
it
should
not
I,
don't
think
it's
something
that
should
hold
us
back,
but
yeah
I
agree.
If
we
think
that
we
need
more
clarity,
we
can
definitely
can
definitely
recharge.
C
B
B
But
they
also
have
this
weird
parameter
called
resolution,
which
apparently
they
what
they
do
is
they
tie
pixels
from
your
screen
to
points
in
in
time
in
according
to
the
resolution,
is
the
amount
of
data
that
is
displayed,
but
that
also
causes
a
graph
on
out
to
somehow
add
more
points
that
do
not
exist.
When
you
do
the
query
in
tennis
or
Prometheus,
it's
kind
of
weird,
like.
C
F
B
D
D
So
there
was
an
issue
in
12
attend
for
determining
what
format
you
want
to
allow
for
defining
templating
variables
and
not
podium
L
files.
So
this
is
just
the
conclusion
that
we
came
to
I
just
wanted
to
bring
it
here
in
case
anyone
has
any
input.
D
So
if
everyone
can
see
that
image
there,
that
has
two
different
kinds
of
variables,
one
is
a
simple
custom
type
where
you
can
define
every
single
possible
value
that
the
variable
can
hold,
so
that
will
be
shown
on
the
UI
as
as
a
drop-down
and
the
user
can
select
the
value
for
his
variable.
For
that
variable,
the
other
type
is
a
free
text.
Variable
you
can
see,
there's
a
type
text
there,
so
that
one
will
allow
the
user
to
type
any
text
that
he
wants
as
a
value
for
that
variable.
D
But
the
most
useful
type
of
variable
that
they're
sorry
speak
about
is
one
way
you
can
put
a
Prometheus
query
and
the
value
for
the
variable
will
be
all
the
different
label
values.
So
if
you
scroll
down
there's
a
second
iteration,
so
in
that
you
can
see
type
metric
label
values,
metric
comes
for
label,
underscore
values,
so
this
one
corresponds
to
the
graph
on
a
feature
that
that
is
kind
of
like
a
pseudo
function.
C
C
C
There
is
an
existing
epic
just
like
open
the
relevant
issues,
come
in
like
implement
the
custom
type
Bible
tags
and
the
dynamic
values
against
the
or
should
live
like
in
a
separate
issue,
and
so
because
I
assume
it
is
broken
down
by
like
an
MVC.
So
I
know
how
exactly
but
I
guess
we
are
not
going
to
take
like
all
of
those
types
into
into
the
first
iteration
we're
going
to
break
them
into
like
right.
D
D
E
We
care
for
how
we
want
to
refine
this,
so
we
can
better
scope.
What
first
iteration
MVC
looks
like,
because
I
think
one
of
the
conversations
is
maybe
even
having
dropdowns
for
the
first
MVC,
so
that
it's
only
passed
through
the
URL,
which
I
think
is
a
good
first
step
like
we
don't
like.
So
for
an
example,
one
of
the
dashboards
we
have
in
Griffin
ax
is
the
Marquis
customer,
where
you
pass
in
the
Salesforce
ID
of
the
customer
to
pull
the
dashboard
for
those
customers,
and
they
only
pass
it
through
URLs.
E
It
sits
in
the
URL
so,
like
you
say,
like
customer
ID
equals
123
and
then
that
passes
into
the
query.
But
then
again
we
talked
about
how,
in
this
proposal
we're
not
passing
those
variables.
Oh
I,
don't
know
if
we're
passed,
never
post
until
iteration
two,
so
maybe
that
doesn't
work
either,
but
I
think
Devin
I
should
work
on
what
the
scope
should
be.
E
D
C
E
E
D
There
are
any
alternate
methods
of
doing
it
for
the
second
iteration
we
need
to.
We
had
to
choose
some
way
of
you
know
having
dynamic
queries
that
populate
variable
drop-down.
So
for
that
I
chose
the
method,
the
graph
animator
that
seems
to
be
most
used
by
the
Saudis,
which
is
the
label
on
score
values.
So
if
you
could
consider
other
possibilities
there,
if,
if
this
is
not
the
most
useful
second
iteration.
D
D
F
D
D
C
H
Because
I
noticed
that
this
dynamic
values
are
different
from
the
dynamic
that
we
are
using
for
the
other
types
of
variables,
like
the
musing
options,
44
the
custom-
and
it
might
be
a
good
idea
to
have
this
unified
so
having
very
different
keys
for
the
similar
concept,
could
be
very
confusing
for
the
end-users.
So,
for
example,
having
options
and
dynamic
values,
I
think
I
I
may
be
confused
if
I
would
be
trying
to
learn
new
syntax.
So
that's
just
so.
Just
for
myself
are.
H
C
D
C
C
E
So
another
thought
is
since
we're
talking
about
see
I
like
a
yam,
well
definition
thinking,
it
might
be
a
good
idea
to
consult
people
from
the
CI
team
since
the
CI
AI
most
most
popular
yam.
Well
definition,
we
have
a
gate
lab
just
to
see
if
we're
making
the
best
decisions
for
how
to
organize
these
keys.