►
From YouTube: Monitor:APM Weekly Meeting 2020-04-08
Description
Weekly meeting for the Monitor:APM group
A
A
B
You
hear
me
how's
everybody
doing
good
cool
yeah,
we
can
get
started.
Dov
is
not
gonna,
be
here.
Cuz,
Passover,
Eve
and
I.
Think
that's
also
not
available
so
I
had
a
few
things
want
to
talk
about.
First
is
just
a
good
reminder
for
everybody
in
general
that
we
should
always
consider
the
context
of
writing
issue
titles
in
description.
B
So
just
a
good
reminder
for
everyone
to
just
sometimes
it's
good
to
take
a
step
back
and
look
at
it
from
a
different
lens
from
a
customer
perspective
or
from
you
know,
or
SIDS
perspective,
just
a
little
bit
removed
from
the
from
the
current
context
that
you
might
be
working
on
an
issue
so
that
helps
everyone
out.
So
just
just
a
good
reminder
on
that.
Any
questions
about
that
specifically.
B
Cool
and
then
my
second
one
is
that
we
had
some
one
to
recap
on
the
retro
takeaways
and
if
someone
wants
to
take
notes,
that
would
be
great.
So
a
few
things
from
the
retro
that
we
wanted
to
kind
of
talk
about.
We
had
some
conversations
about
how
with
logging
specifically
in
terms
of
some
of
the
features
feeling
like
it,
it
was,
potentially
you
know,
lower
quality
than
we
expected,
and
so
with
that,
we've
had
some
couple.
Some
more
conversations,
a
lot
of
it
came
from
miscommunication
and
I.
B
He
can
take
the
responsibility
if
it
needs
to
be
if
the
scope
needs
to
be
the
same
as
well
as
if
it's
cut
how
to
prioritize
that
follow-up.
So
just
want
to
iterate
reiterate
that
that's
gonna
be
key
moving
forward
and
then,
as
we
do,
that
we
want
to
make
sure
we
document
these
as
issues
follow-up
issues,
they're
very
clear
kind
of
here's,
a
feature
gap
that
we're
explicitly
deciding
not
to
implement.
B
For
now,
it
may
seem
like
a
bug,
but
we're
not
classifying
as
a
bug
because
we're
intentionally
deciding
not
to
move
forward
with
this
feature.
So
hopefully
that
helps
a
little
bit
with
kind
of
understanding,
whether
we're
decreasing
the
the
quality
versus
like
trying
to
be
small,
iterations
and
and
kind
of
trying
to
find
the
right
balance
for
that.
B
So
hopefully
that
that
should
help
if,
as
we
move
forward,
if
we
develop
features-
and
we
don't
document
kind
of
the
gaps
that
take
place,
I
would
still
consider
those
bugs.
So
we
should
always
make
sure
that
we
document
those
those
feature
gaps
as
issues
so
that
we're
intent
were
intentionally
deciding
not
to
add
certain
features
rather
than
not
realizing.
B
This
doesn't
work
until
later,
on
which
I
would
consider
the
second
part
to
be
more
of
a
bug
than
an
intentional
D
scoping
and
as
we
move
forward,
we're
gonna
try
to
find
better
ways
to
refine
issues
so
that
the
team
has
small
scopes
to
start
with,
so
that
the
opportunities
for
cutting
scope
during
development
is
less
than
the
news
today,
but
those
kind
of
play
hand-in-hand.
There's
any
questions
about
that
specific
part.
B
C
Okay,
so
we
have
an
issue
for
decoupling,
the
environment,
environments
and
the
matrix
dashboard,
because
that
was
a
topic
that
was
discussed
in
today's
meeting
with
the
asari
team.
So
I
just
wanted
everyone
to
have
a
look
at
the
issue
and
maybe
think
about
any
consequences
that
are
not
yet
described
in
the
description,
for
example,
current
predefined
variables
that
we
have
like
CI
environment
slug.
C
They
have
to
be
removed
because,
if
you
don't
know
which
environment
the
user
wants
to
see,
data
on,
you
can't
really
substitute
the
environment
variables,
but
I
wonder
if
we
can
automatically
have
a
drop-down
at
the
top
of
the
matrix
dashboard,
which
has
all
the
environments
values.
Something
about
which
really,
you
know
prevent
us
from
having
to
deprecate
variables
that
are
quite
well
used.
A.
C
Yeah
but
yeah,
but
that's
because
it's
coupled
with
the
environment
right.
So
if
you
see
the
URL
of
the
metrics
dashboard,
the
environment
ID
is
in
it.
So
that's
how
we
know
that
for
a
particular
dashboard
we
should
substitute
a
particular
environments,
log
or
name.
So
if
you
decouple
that,
if
you
have
the
matrix
dashboard
display
independent
of
the
environment,
you
don't
know
which
environments
data
you
should
be
substituting
with.
A
C
Okay,
so
to
give
you
an
example
of
Gravano
everything
over,
there
is
a
variable
that
you
know
you
have
dropped
down
for
right,
there's,
no,
it's
not
like
gitlab,
so
there's
no
predefined
variables!
Well,
there
are,
but
it's
not
related
to
environment
data
and
stuff,
so
we
are
kind
of
going
towards
that
direction.
A
C
C
D
Somewhat
related
question:
we
have
another
feature
that
we
want
to
probably
tackle
on
for
later,
milestone,
which
is
supporting
different
variables
on
the
yellow
files,
but
I
remember
that
the
sea-ice
log
was
going
to
be
deprecated
because
security
concern.
Does
that
mean
that
we're
not
gonna
support
anymore
Bibles
in
the
future,
or
perhaps
we
might
want
to
look
into
another
type
of
implementation?
D
Basically,
what
this
issue
well
that
big?
What
we
want
to
accomplish
with
this
epic
is
that
we
want
to
have
the
control
of
the
multiple
labels
in
prometheus
as
dropdowns,
so
we
have,
for
example,
we
have
the
environment
label
and
then
we
can
have
some
other
types
of
labels.
The
answer-
a
team
loves
to
use
the
type
and
stage
labels
to
the
swap
between
different
production
environments
like
cannery
production
staging,
and
they
also
do
type,
so
they
don't
have
to
change
the
context
of
what
they're
looking
at.
D
They
just
have
to
change
the
components
that
they
want
to
look
at
so
for
apdex
scores.
They
have
four
dip
services,
web
services,
sidekick
and
CI
registry
I
believe
so
the
greys
are
the
same,
but
the
labels
are
not
so
this
disrupt
downs.
Well,
this
is
something
we
want
to
do
to
be
as
close
to
the
front
as
possible,
but
if
we
do
it
to
create
the
environments
drop
down
to
me
feels
that
we
might
not
want
to
support
variables
in
the
future.
Does
why
I
was
asking.
B
It
feels
like
to
move
forward.
We
kind
of
maybe
need
a
spike
to
technical
spike
to
really
understand
what
it
would
take
to
decouple
them.
I
think
for
the
most
part,
everyone
would
probably
agree
it
should
be
decoupled
in
some
ways
like
I
shouldn't
have
to
right
now
so
I'll
give
you
an
example
is
let
me
share
my
screen,
the
full
or
setting
up
the
metrics
dashboard
on
on
Caleb
comm.
We
we've
set
it
up
a
manual
connection
through
like
the
Prometheus
endpoint,
but
then
I'm
not
able
to
load
this
unless
I
create
an
environment.
B
So
we
need
you
to
figure
out
how
to
decouple
that,
but
how
we
do
it
I
think
it
sounds
like
there's
there's
different
thoughts.
I
do
think
long
term.
We
want
to
add
ability
to
add
dropdowns
for
variables,
but
we
also
want
to
make
sure
we
take
advantage
of
the
single
application,
a
DevOps
lifecycle
stuff,
so
maybe
there's
a
way
to
kind
of
meet
both
without
requiring
certain
things
to
load.
This
feature.
E
B
Cool
Ruben
would
you
mind
taking
the
lead
on
updating
your
issue,
to
convert
to
a
spike,
to
kind
of
cover
kind
of
what
we
talked
about
in
this
meeting?
Sure,
okay
and
then
we'll
try
to
see
if
we
can
schedule
for
next
release
or
the
release
after
to
investigate,
because
I
think
I
think
we
need
to
figure
this
out
sooner
rather
than
later
cool,
but
so
yeah
I
wanted
to
give
a
brief
update
as
well
on
kind
of
how
we're
doing
on
a
dogfooding
metrics.
B
So,
thanks
to
the
help
of
Jose
and
SRE
team,
we
were
able
to
actually
get
run
books
to
load
the
metrics
dashboard
on
Ghaleb
comm,
previously
weren't
able
to
load
it
only
on
ops
because
of
some
proxy
rules.
With
the
way
we've
set
up
our
the
Prometheus
metrics.
We
don't
want
everybody
in
the
world
to
be
able
to
pull
all
our
metrics
and
so
ops.
It's
kind
of
firewalled,
so
in
that
ops
instance
was
able
to
pull
it.
B
But
the
problem
is
ups
only
deploys
on
the
monthly
basis,
because
ops
instance
needs
to
be
stable
and
that
has
been
challenging
for
us
to
iterate
quickly.
On
the
metrics
dashboard
and
through
some
work
with
the
SRA
team
were
able
to
for
now
able
to
pull
the
information
through
long
term.
We
want
to
add
a
lot
support
to
manual
prometheus
instance
configuration
so
that
we
can
be
more
secure
with
how
we're
putting
that
information
and
connecting
it.
B
This
is
said
for
13.0,
and
this
would
actually
enable
our
team
to
use
the
same
prometheus
endpoint,
which
is
here
using
OAuth
with
our
Gilad
credentials
to
actually
start
pulling
those
metrics
for
our
development
usage
as
well
to
like
pull
in
the
data,
so
I
think
that
should
be
helpful
for
everybody.
So
I'm
very
excited
for
this.
This
feature
and
it
doesn't
seem
too
complicated,
but
fingers
crossed
so
yeah.
So
that's
really
cool
to
see
the
progress
here.
B
The
goal
of
end
of
q2
q1,
which
is
an
April,
is
still
to
replace
the
Griffin
a
dashboard.
So
this
is
the
original
dashboard
that
we
were
trying
to
replace
as
kind
of
our
our
okay
are
replacing
this
with
the
metrics
dashboard,
not
having
the
thresholds
and
not
having
this
text
part,
but
the
data
being
the
same.
B
So
we
still
have
a
little
bit
of
kinks
to
work
out
and
we're
working
through
that,
but
I
just
want
to
show
that
the
progress
we're
making
here-
and
it's
really
great
there
is
the
caveat,
though,
is
that
this
SLA
dashboard
in
order
for
us
to
remove
this,
it's
also
a
customer
facing
dashboard
that
people
use
to
make
sure
our
SLA
scores
are
good.
So,
in
order
to
delete
this
or
have
a
have,
this
page
literally
say
go
to
the
metrics
dashboard
URL.
B
We
need
to
make
sure
this
is
public
to
the
world
and
right
now
this
is
tied
to
developer
and
above
permission,
scope.
Access
for
this,
even
though
run
books
project
is
open.
The
metrics
dashboard
is
is
only
available
for
internal
project
users.
Only
so
we
have
this
issue
that
was
originally
stated
for
I,
don't
remember
or
set
for
yeah
set
for
thirteen
point
zero
as
a
filler
issue,
the
ability
to
toggle
public
public
or
private
for
your
metrics
dashboard,
and
so
there's
some
preliminary
conversation
about
an
MVC,
maybe
adding
kind
of
a
check
box.
E
E
B
Cool,
that's
good
to
know
so,
maybe
not
as
straightforward
as
I
originally
thought,
but
we
need
to
add
the
ability
to
me
get
public
so
that
we
can
meet
our
okay
are
for
q1
end
of
April.
Be
able
to
have
this
page
basically
have
a
link
here
that
says:
go
to
the
metrics
dashboard
and
everyone
and
the
Internet
can
go
to
this
page.
So
I
was
trying
to
get
a
good
feel.
I
know.
B
Dov
is
out
so
I
wanted
to
get
a
good
feel
from
the
team
to
see
whether
this
is
something
that
we
could
add
on
as
a
deliverable
to
our
existing
workload
or
whether
we
could
add
this,
and
do
you
prioritize
something
else
or
we
could
potentially
push
it
for
like
a
deliverable
for
13.0
like
try
to
do
the
first
week
and
still,
which
continues
to
delivery,
get
it
on
Caleb,
calm
before
end
of
April,
but
that
might
be
pushing
it.
So
I
wanted
to
have
that
conversation
and
see
what
the
team
thinks
about
this.
A
B
B
Is
I
which
I
would
buy
public?
That's
a
good
question.
Buy
public
I
mean
probably
the
same
access
as
seeing
the
project
details
so
right
now
the
project
details
is
right.
Now
it's
a
public.
Anyone
can
access
without
authentication,
so
I
know
you
can
do
public
project,
internal
or
private.
So
I
would
assume
that
that's
a
good
question
so
like
the
toggle
would
be
inherit
the
highest
permission
or
the
lowest
permission
privileges.
So
in
this
case,
since
run,
books
is
public,
it
would
be
public,
you
don't
need
authentication.
B
B
So
it
would
be
really
incredible
if
we
can
pull
it
off
to
by
the
end
of
q1.
Have
this
page
go
away
and
just
have
a
text
boxes
go
to
here
and
this
works
for
our
customers,
because
then
they
can
start
associating
metrics
dashboard.
As
you
know,
more
usable
than
Cortana
and
see
our
movement
towards
that.
C
B
E
If
I
heard
you
correctly,
because
it's
catchy
the
as
far
as
I
checked
right
now,
we
had
this
matrix
dashboard
in
the
environs
controller
and
it
arises
the
REIT
environment
permissions.
So
why
is
it
here?
We
most
likely
will
be
able
to
override
the
permissions
just
for
the
one
end
point
of
this
controller,
so
you
may
have
workaround
for
this,
but
nevertheless
it
is
a
somehow
related
to
the
decoupling
environments
with
the
metrics.
What.
B
B
C
C
E
D
E
B
Take
a
look
at
it
as
well:
okay,
cool
yeah,
so
Brian
Ruben.
You
have
capacity
to
look
at
it
like
this
week
next
week.
I
think
that
be
don't
be
great
yeah.
If
we
can
ship
it
in
this
release,
it'll
be
really.
It
would
look
really
great
on
the
team.
So,
let's
see,
if
we
can
make
it
happen
and
in
front-end
we
can
support
I,
think
the
I
mean
we're
just
adding
a
toggle.
B
So
it's
fairly
straightforward
on
our
side,
cool,
alright,
so
I
plan
on
that
I'll,
let
Matt
know
keep
them
in
the
loop
and
let
them
know
as
well,
and
hopefully
we
can
get
the
ball
rolling
under
this
one,
pretty
quickly
cool
and
then
the
last
thing
I
wanted
to
share
is
I'm,
not
sure
if
y'all
saw,
but
we
have
a
new
really
cool
perk
of
gitlab
is
with
the
cove
in
19.
We
are
now
able
to
expense
up
to
two
meals
up
to
25
US
dollars
as
long
as
we
virtually
hang
out
and
eat
together.
B
So
it'd
be
nice.
If
we
can
see
a
time
that
works
with
people
in
the
monitor
stage
of
some
other
APM
and
I'm
on
our
health
and
see
what
what
best
times
we
can
pick
before
the
end
of
month
and
yeah
I
know
that,
unfortunately,
some
places
all
even
takeout
is
closed.
So
I'm,
sorry
for
y'all,
but
you're
welcome
to
eat
with
us,
but
for
the
other
ones,
yeah
I
think
this
is
a
cool
perk
and
hopefully
we
can
use
this
time
to
hang
out
and
we
can
also
use
this
one.