►
From YouTube: Monitor:APM Weekly Meeting
Description
Weekly meeting for the Monitor Stage - APM Group. Discussed ongoing meeting format and 12.3 issues
A
A
Yeah
thanks
for
everyone
for
joining.
We
I
think
we
had
a
a
p.m.
meeting
for
a
short
time
and
then
it
kind
of
fell
off
and
not
really
sure
why
and
then
now
we're
back.
So
this
is
the
first
one
I
wanted
to
kind
of
copied.
Some
of
this
so
I
think
I
wanted
to
start
with
some
kind
of
meeting
logistics,
so
we
can
can
figure
out
how
to
make
this
work
best
for
everyone,
and
then
we
can
talk
a
little
bit
about
the
rest
of
the
agenda.
A
So
the
first
thing
is:
I
just
picked
this
meeting
time.
This
is
kind
of
when
the
health
team
has
their
meeting
I
think
every
other
week,
but
it's
not
very
good
for
this
team
since
we're
fairly
widely
distributed.
So
we
one
thing
that
personal
everyone
Mentos,
maybe
I,
should
start
there.
Hey
I
just
wanted
to
make
sure.
A
A
So
for
now
I'll
schedule
them
at
these
times
going
forward
repeating
so
every
week,
alternating
just
the
thing
the
next
point
I
have.
There
is
a
real
record.
All
of
these
will
take
notes,
so
your
attendance
isn't
required.
I'll
try
to
be
at
all
of
them.
I
think
douve
would
like
to
be
at
all
of
them
other
than
that.
If
you
can't
make
it
at
the
times,
don't
work
like
other
meetings,
feel
free
not
to
not
to
attend,
and
you
know
we'll
make
sure
everything
is
recorded.
A
Well,
okay,
I'm
glad
to
see
Amelia
here,
because
I
think
I
forgot
to
invite
you
so
I'm,
very
sorry
about
that.
But
besides
the
so
I
just
sent
it
to
the
APM
team,
alias
which
I
think
covers
the
front
and
a
back-end
team,
or
maybe
oh
yeah,
okay
Amelia,
you
are
on
there
on
that
list,
that's
good!
What
is
there
other
people
that
need
to
be
invited
that
aren't
on
that
list?.
A
So
then
just
kind
of
a
outline
of
just
general.
What
we
would
talk
about
in
meetings
would
be
kind
of
review.
The
milestone
the
planning
board
I
can
oh
there's
a
link
to
that,
like
I,
said,
then
go
into
the
issues
review
any
bugs
that
we
have.
If
there's
questions
or
comments,
we
can
talk
about
that
and
then
the
last
thing
is
just
a
reminder
to
enter
things
into
our
ongoing
retrospective
and
I
can
add
a
link
to
that
too.
A
Okay,
this
first
meeting
is
different
because
it's
our
first
one,
so
you
gotta
kind
of
get
everyone
on
the
same
page,
first,
so,
okay
and
then
we
don't
really
need
to
talk
about
it.
But
there
is
I
posted
a
link
here
from
the
health
team.
They
did
a
little
survey
to
talk
about
their
weekly
meetings
and
how
they've
been
going
so
here's
the
results
of
that.
That's
what
that
issue.
A
Is
there
it's,
so
we
don't
have
to
do
the
same
thing
as
a
health
team
for
sure
we
have
to
do
what
works
best
for
us,
but
I
think
there's
some
good
learnings
in
there.
So
I
think
it's
interesting
to
kind
of
read
through
and
then
just
to
kind
of
keep
things
in
mind
as
we're
kind
of
kicking
off
this
meeting.
A
The
big
things
that
I
pulled
out
of
there
is
that
they
thought
the
kind
of
a
50-minute
meeting
was
good,
although
they
only
do
that
I
think
every
other
week,
so
we
can,
as
a
APM
team,
decide
what
works
best
for
now.
I'll
schedule
it
for
an
hour,
but
we
definitely
minutes,
but
we
don't
have
to
take
all
that
time.
A
C
C
Going
forward
and
I
think
sometimes
something
everyone
should
know
is
you
know
we
had
a
PN
team.
A
team
in
the
industry
is
actually
stem
from
something
very
specific.
I
always
tell
it
to
the
people
that
I'll
talk
with
I
think
our
team
is
actually
more
aligned
to
be
called
team
and,
as
you
may
know
know,
may
not
know
observability.
The
three
core
pillars
of
observability
is
logs
metrics
and
in
cases
this
is
exactly
what
this
team
focuses
on
so
going
forward.
C
Ideally,
I
want
us
to
make
sure
we
are
gaining
progress,
note,
verticals
and
logs
metrics
and
once
we'll
have
like
the
building
blocks
for
those
three,
then
you
can
see
how
we
can
collate
those
together.
We
need
us
everything
into
the
same
the
same
picture
so
as
I
mentioned
1203,
not
a
lot
that
I
change,
but
definitely
in
1204.
C
You
would
see
a
I
think
some
heavy
issues
around
logging
on
tracing
which
I
think
need
some,
like
you
know,
an
extra
push
so
that
country
we
have
like
done
a
decent
focus
and
metrics
with
respect
for
PO
meteors
still
have
a
lot
of
room
to
do,
but
with
yeah
girl,
pricing
and
and
logs,
not
as
notice
aligned
to
how
we
progress
with
with
matrix
so
yeah
I
mean
we
have
some
topics.
We
can
cover
them
in
this
meeting
or
we
can
cover
them
in
the
next
meeting.
If
you
want
and
the
open
for
suggestion.
A
A
People's
reference,
I
guess,
make
sure
I'm
sure
here
so
twelve,
three
each
milestone
we
try
to.
We
have
to
have
the
engineering
work
done.
The
17th
is
the
I
believe
the
date
we're
shooting
for
that
gives
us
about
five
more
days
so
kind
of
early
next
week.
We
want
to
be
wrapped
up
with
any
of
the
engineering
work.
We
still
have
30
issues
in
this
12.3
release
that
are
open,
so
my
goal
would
be
to
think
about.
A
E
Yeah,
ok,
I
know
I
added
those
to
the
document,
but
basically
I
have
two
features:
flag.
Removals,
tiny
packin,
because
if
we
merge
the
front
end
without
the
back
end
feature
from
the
configure
team
is
gonna
break.
So
I'm
waiting
for
that
and
be
support
for
is
that
column,
charts,
I
need
annual
Prometheus
questions,
so
I
can
run
some
of
the
queries
needed
to
show
the
stat
column
charts
and
we
need
to
move
that
to
either
twelve
point
four
twelve
point:
five:
okay.
E
D
E
E
A
F
A
G
G
A
I
Right
yeah
I
wanted
to
mention
the
anomaly
detection
MVC
issue,
so
it's
kind
of
a
large
project,
I
guess
but
there's
this
issue
that
says
well.
We
should
try
to
build
out
one
animal
other
with
using
Prometheus
since
here
it
works,
didn't
hear
to
me
the
what's
what's
next
for
this,
the
code
is
done,
but
it
doesn't
really
provide
any
value
to
the
user
as
as
the
issue
is
region,
so
I
went
to
to
mention
it
and
see
if
we
could
discuss
the
future
direction
to
this
or
what
to
do
with
it.
Basically,.
J
Sure
yeah
one
idea
we
have
with
Adriel
is
to
to
see
if
we
can
cook
some
from
from
QL
queries.
The
current
anomaly
chart
component.
The
anomaly
chart
component
is
in
maintainer
review
and
it
should
be
okay
too
much
soon,
but
the
particular
queries
will
take
longer.
So
this
is
not
something
we'll
have
in
12.3.
J
Well,
first
approach
would
be
to
define
a
common
metric
that
has
some
kind
of
behavior,
that
is,
that
is
relatively
stable
over
time,
and
then
this
this
could
be
put
into
an
anomaly
chart
so
that
if
we
see
anywhere
any
big
variation,
we
would
see
it
as
an
anomaly.
But
it's
not.
It
would
not
be
in
the
first
stage
connected
to
the
back
end.
Is
it's
just
visible
in
the
front
end
as
as
a
red
dot
that
you
see
as
abnormal.
F
F
We
can
use
those
two
weeks
and
form
a
general
idea
of
what
an
anomaly
would
look
like
and
display
a
chart
based
on
that,
just
using
straight
up
from
12
queries
and
passing
it
you
know,
does
the
back
end
I'm,
not
sure
if
that
feature
flag
is
lifted
yet,
but
we're
closed,
if
not
right,
so
we're
going
to
be
passing
that
on
to
El
response
transparently
right
through
to
the
front
end,
so
we
could
just
use
those
queries
and
display.
You
know
those
anomalies.
I
Luke
wished
regression
we
found
that
is
which
metric
do
you
want
to
elect
on,
because
right
now,
the
as
the
issue
I
mentioned
is
written.
It's
using
the
nginx
request
rate
and
that's
a
bit
unfortunate
because
you
have
to
enable
it
on
a
project
that
already
has
requests
coming
in.
If
you
don't
at
some
point,
you're
gonna
have
you're
gonna
generate
anomaly
alerts
just
use
visiting
the
page,
the
first
time
you
enable
it,
for
example.
So
it's
red
it's
not
that
clear
which
which
metric
do
you
want?
Do
we
want
to
learn
so
yeah.
F
I
The
other
thing
I
was
wondering
about
is
so
I'm
not
too
familiar
with
mythos
yet,
but
the
way
I'm
doing
doing
it
right
now
in
the
prototype
is
amusing,
recording
rules
so
that
the
queries
I
mean
the
the
metrics
specifically
are
already
pre
generated.
I'm,
not
sure
if
you
can
do
the
same,
computations
using
just
like
a
standard,
query
or
I
would
have
to
check
that
I'm,
not
sure
it'd.
G
F
K
F
Question
is
just
whether
we
negatively
impact
a
Prometheus
server.
If
we
start
doing
those
type
of
queries,
without
recording
rules
in
place,
I
mean
is
the
load
significant
enough
that
we're
actually
damaging
our
Prometheus
servers?
By
doing
that,
that's
that
part
I
guess
would
need
some
exploration
and
some
further
investigation.
I
A
F
F
I
guess
the
question
is
I
mean
because
our
goal
thus
far
hasn't
even
really
been
on
the
logging
in
tracing
side
of
things.
We've
been
very
focused
on
the
self
monitor,
sorry,
I'm,
the
self
monitor
side
of
things.
So
is
this
now?
What
point
at
what
point?
Do
we
need
anomaly
alerting?
Is
this
gonna
be
I,
don't
think
it's
necessarily
getting
us
to
viable?
F
I'm
not
sure
where
we
want
to
prioritize
that,
but
we
can
also
pivot
as
well.
I
mean
partially.
We
developed
the
front
end
out
because
that
looked
like
it
was
the
next
thing
that
was
slated
on
our
prioritization
list,
which
it
was
I
mean
it
was
on
12
304
whatever,
but
we
may
need
to
rethink
that
now.
It
sounds
like
based
on
based
on
what
we've
been
finding
as
we've
gone
to
implement
it.
I
C
Usually
it
comes
like
in
the
form
of
trees
like
three
days
per
day
three
weeks
the
week
three
months
per
month,
and
if
you
want
to
you
know,
detect
like
some
sort
of
anomaly
like
to
focus
something
and
see,
because
the
idea
normally
is
that,
once
you
have
this
model,
then
you
can
detect
it
once
it
happens.
It's
forecasting
in
order
to
see
what's
going
on
right
now,
I
I
need
to
be
very
understanding,
but
for
me
I
also
like
my
hunch,
is
that
still,
as
you
mentioned
at
the
end,
it's
it's
not.
F
Thing
yeah,
I
think
the
other
thing
I
mean.
Maybe
then
what
we
do
is
instead
of
trying
to
make
it
a
common
metric.
We
can
just
expose
the
front-end
component
so
that
you
know
self-hosted
customers
who
do
have
that
amount
of
data
I
mean
I.
Imagine
the
people
who
are
using
this
are
gonna,
be
our
enterprise,
customers
and
I.
Imagine
they
have
data
going
back
years
of
years.
So
maybe
that's
the
point
where
we
start
for
now,
since
we
have
I
mean
the
front
end
is
basically
there
right.
F
The
a
visualization
piece
is
already
pretty
much
ready.
Correct
me
if
I'm
wrong
together,
that
was
my
understanding,
but
I
think
we're
pretty
much
ready
more
or
less
right.
So
you
know
we
could
at
least
add
it
in
as
an
option
and
not
worry
about.
You
know
putting
it
in
our
common
metrics
for
now
and
then
we
just
have
you
know:
users
who
want
to
make
their
custom
dashboards
or
version
control
dashboards
can
utilize
it
as
an
as
an
option.
F
F
I
will
focus
on
that
more
than
on
the
front
end
side,
just
basically
making
it
a
feature
available.
We
may
need
a
little
help
from
back
and
coming
up
with,
like
a
potential
query.
If
you've
done
some
of
that
Adrian,
maybe
you
mean
we
kind
of
put
our
heads
together
up
just
even
how
to
test
it.
I
think
that's
our
biggest
thing
right
now
is
testing
it
with
an
example
query
and
then
we'll
have
that
component.
There.
I
I
So,
let's,
let's,
let's
I'll,
share
with
you
what
I've
done
and
we
can
discuss
that
and
so
for
the
issue
at
hand,
so
I
think
I'm
gonna,
just
close
the
llamar
cuz.
It
doesn't
provide
anybody
and
probably
and
close
the
issue
or
something
or
open
another
one,
but
I
don't
think
we're
gonna
deliver
something
into
about
three.
A
B
I,
don't
know
that
we've
it
it
doesn't
seem
like
that's.
This
functionality
could
be
arm,
could
be
replicated
just
by
changing
all
the
weights
and
priorities
to
the
same
value
right
instead
of
you
know,
taking
all
that
functionality
out
and
not
allowing
us
to
be
able
to.
You
know
just
to
sort
based
on
weights
and
priority
in
the
dashboard.
So
I'm
willing
to
you,
know
dogged
leap,
push
to
get
this
thing
merged,
but
I
mean
it
seems
like
it
was
a
lot
of
care
and
feeding
went
into
putting
in
this
functionality.
H
B
I
guess
the
goal
is
to
be
able
to
sort
your
dashboard
by
just
the
order
of
the
animal
entries
in
the
file
which
again
there's
there's
some
amount
of
sorting
that
needn't
go
on
from
the
front-end
and
I
guess.
This
needs
to
be
in
there
for
the
for
the
front
end
to
be
able
to
sort
them.
But
if
we
just
changed
all
the
priorities
and
and
weights
to
the
same
value,
then
they
would
come
out
in
that
order.
So.
B
F
See
I
mean
yeah
I
mean
the
idea
was
basically
that
we're
trying
to
make
it
easy
for
a
user
to
reconfigure
the
dashboard
from
their
llamó
files.
So
if
they
go
in
and
see
oh
I,
don't
like
the
ordering.
You
know
just
move
it
around.
Instead
of
trying
to
figure
out
like
a
proper
way
to
switch
priorities
around
right,
because
I
mean
even
either.
B
Way
if
the
weights
of
priorities
is
the
way
that
they're
sorted
now
I
mean
this
based
on
the
waste
parties.
It
may
not
be
obvious
as
to
you
know
what
comes
first
waiter
I
mean
you
know,
but
but
and
we
did
want
to
do-
we
did
and
and
there's
some
traffic
in
the
issue
about
having
this
as
configuration,
our
configuration
is
code
so
that
you,
you
know
commit
these
things
to
the
making.
Em
are
automatically
through
the
gillip
front,
end
to
adjust
as
the
ordering.
B
B
F
I
mean
I,
don't
see
any
problem
with
that.
Necessarily
the
question
I
have
is
if
a
user
setting
up
a
dashboard
and
they
don't
provide
a
weight
or
priority
field,
does
that
still?
Okay,
it's
still
considered
a
valid
like
it's
okay
with
that
right.
It's
not
gonna
error
out.
If
you
don't
have
those
keys
there
right,
but
dip
or
well.
B
I
can
I
don't
think
it's
not
gonna
air
out
for
those
those
guys.
It's
gonna
get
a
nil
back
from
the
from
the
Imo
key
and
it'll
just
sort
of
you
know,
but,
but
that
that
may
be
the
better.
That
may
be
the
better
things
tests
and
functionality
to
make
it
less
or
make
it
ensure
that
it's
not
brittle
and
in
terms
of
those
keys
being
present.
That
may
be
the
correct,
correct
implementation,
but
leave
the
sorting
available,
but
yeah.
F
B
B
F
But
I
think
I
mean
the
first
piece
of
it
was
just
to
basically
honor
the
order
so
that
a
user
can
very
easily.
If
they
want
to
rearrange.
They
don't
have
to
worry
about
figuring
out
how
to
use
priorities
and
weights
and
keys.
It
seems
a
little
more
intuitive
for
a
user
to
just
go
in
and
move
a
chart
up,
and
then
they
see
it
happen
on
the
dash.
But
that
was
the
that
was
really
the
discrepancy.
F
Was
you
go
into
common
metrics,
yeah
Mille,
for
instance,
and
you
see
them
in
an
order
and
then
you
can
rearrange
them
and
nothing
happens,
because
it's
pooling
from
priority
instead
of
that
ordering.
So
you
know,
I
I,
don't
have
a
huge
problem
if
you'd
rather
leave
all
that
functionality
in
there
and
then
well,
I'm
even
pulled
the
keys
out
of
common
metrics.
If
we
wanted
and
still
leave
that
functionality
there
as
an
option
for
ordering
yeah
if
I
make
it.
If.
B
I'm,
if
I'm
sure
that
it's
not
brittle
in
terms
of
the
keys
not
being
available,
then
then
that'll
leave
it
there.
For
you
know
in
case
it
becomes
something
that
in
case
something
we
do
want
to
rename
Olinda
in
the
future,
so
I'll
revisit
that
that's
less
than
a
day's
worth
of
work
to
get
that
to
revisit
that
so,
but
it
didn't
feel
it
just
absolutely.
G
I
just
wanted
to
add
so
in
that,
mr,
we
are
currently
removing
the
sorting
logic
for
even
the
old
way
of
the
old
way
that
gives
to
serve
up
dashboards.
So
I
think
the
issue
originally
was,
as
Sara
commented,
that
we
wanted
to
remove
the
sorting
logic
only
in
the
new
way,
the
dashboard
method.
So
that's
only
in
the
matrix,
both
stages
fortify.
B
A
A
So
there's
we
can
I'll
take
care
of
kind
of
moving
those,
so
we
can
better
plan
12
for
going
forward.
I
think
I
think
we
over
committed
a
little
bit
for
12,
3
and
I.
Think
part
of
that
was
we
over
committed
for
12th
and
then
had
to
pull
a
bunch
of
stuff
from
12
2
into
12
3.
Now
we're
having
that
same
problem
again
here
so
I'd
like
to
we
can
to
break
that
cycle,
and
so
I
think
this
will
help
that
at
least
we
can
be
like
honest
about.
A
What's
actually
gonna
get
done,
move
that
into
12
for
from
this
case,
and
then
we
can
better
plan
going
forward
for
these
that
I'm
moving
I
might
ask
people
to
if
you're,
if
they're
in
progress,
just
maybe
put
a
comment
in
there
to
say
you
know:
are
they
you
know
in
progress
because
we
just
need
you
know,
unblock
or
finish
the
merge
request?
Is
it
something
you
haven't
started
yet
now
that
will
just
help
us
might
help
us
plan
better
too.
A
A
Don't
know
so
12
for
already
has
way
too
much.
In
my
opinion,
in
it
I
mean
there's
50
issues
already
in
there.
So
that's
gonna
have
to
be
adjusted
as
well.
So
things
are,
you
have
to
move
out
of
there,
so
I,
don't
know
what
the
best
practice,
what
any
open
to
suggestions
for
where
they
should
move.
I
think
what
we
did
in
the
past
is
just
anything
that
didn't
get
done
and
one
milestone.
We
would
just
move
kind
of
the
top
of
the
next
milestone,
though
I'm
not
sure.
If
that
still
makes
sense
feels.
K
C
A
Okay,
so
for
now,
I
will
move
them.
How
about
for
now
move
them
to
twelve
four
and
then
I
can
work
with
dough
or
whoever
to
help
prioritize
and
Adriel,
and
we'll
try
to
get
the
twelve
for
board
pared
down.
So
as
we're
doing
that
we'll
decide
if
these
issues
need
to
go
back.
Log
12
for
12,
5
or
kind
of
further
out
does
that
sound.
A
I
A
D
How
many
people
are
working
on
features
versus
bugs
as
ad
and
said?
Two
per
person
sounds
good,
but
should
be
also
kind
of
focus
on
the
number
of
bugs
people
are
picking
up
so
that
it's
not
just
features
features.
And
then
we
introduced
a
huge
stack
of
bugs
and
then
now
we're
just
fitting
through
bugs.
A
Yes,
I
think
bugs
definitely
need
to
be
prioritized
alongside
of
features.
I
know
a
12-4.
There
was
a
couple
security
related
bugs
that
need
to
get
addressed.
I
think
there's
a
couple
higher
priority
as
well,
so
those
definitely
will
have
to
do
so.
Maybe
it's
not
maybe
it's
yeah,
so
maybe
one
or
two
features,
plus
one
or
two
bugs
something
I
don't
know
well
I
may
have
to
play
with
that.
A
little
bit
going
forward.
F
A
I
know,
on
the
back
end
for
12:3
a
number
of
bugs
came
up
or
were
related
to
some
of
the
new
features
we
were
working
on
and
we
kind
of
just
closed
those
out
pretty
quickly
and
I
fixed
them.
So
that's
good
that
we
can
get
to
them
quickly,
but
we
should
also
maybe
I,
can
take
a
pass
at
looking
at
12
3
and
how
many
things
kind
of
came
into
12
three.
A
C
F
G
A
Yep
and
so
there's
also
a
number
that
are
have
been
closed
for
twelve
point
three,
so
those
well
it's
gonna
say
those
are
all
ones
that
are
done,
that
we've,
the
work
is
done
for,
but
I
think
a
number
of
those
when
I
remember
looking
at
them
closer
we're
closed
because
we
they
were
their
duplicate,
so
we
didn
t
work
for
them,
so
I
was
gonna
suggest
just
looking
at
the
list
of
all
the
clothes.
If
you.
C
C
F
C
If
so,
what
I'm
going
to
do
is
next
week
so
I'm
working
on
Sunday
on
Sunday
I'll
start
looking
at
those
a
if
any
of
you
are
walking
on
an
mr,
an
issue
that
you
know
it's
going
to
be
video
like
90
percent
by
possibly
know
that
it's
going
to
get
in,
you
know,
DME,
send
me
the
link
and
I'll.
Add
it
to
the
worst
thing
was
I
can
remove
it,
but
you
know
you
know
you
can
send
me
a
private
message.
A
Okay,
great
we're
kind
of
at
time,
I
hope
this
meeting
was
useful
to
people
I
think
well,
as
we
get
more
into
the
routine,
it
will
become
and
we
kind
of
catch
up
I
think
we
have
a
kind
of
a
backlog
of
items
that
discuss.
We
talked
about
a
number
of
them
here,
so
as
we
kind
of
get
through
that
will
I
think
these.
Will
these
meetings
will
kind
of
get
into
a
good,
routine
and
I'm
kind
of
excited
about
that.
So.
A
Good
I'm
glad
and
I'll
go
ahead
and
take
some
action
items
that
I'm
going
to
take
care
of
here,
including
setting
up
the
recurring
meetings
going
forward.
So
look
for
those
in
your
calendar
once
I
this.
This
meetings
record.
It's
all
upload
it
and
share
the
link
with
that
as
well.
Okay,
thanks
everyone
and
I'll
soon,
thanks.