►
From YouTube: GitLab 12.6 Kickoff - Monitor:APM
Description
12.6 Kickoff meeting for the Monitor:APM team
Also discussed other topics for the Monitor:APM weekly meeting
A
A
B
B
Okay:
okay:
first
issue
is
an
investigation
or
a
spike
issue,
and
we
spoke
about
it.
I
think
previous
conversation
and
I
want
us
to
try
to
find
a
database
that
lets
go
metrics
for
permittees
know
that
we
talked
about.
Fairness
is
an
option
but
I,
don't
think,
based
on
conversation
that
I
had
with
several
engineers
that
use
tennis
I,
don't
think
it
should
be
the
one
that
we
need
to
work
on
ie
ice,
that
we
need
to
investigate.
I
put
them
some.
Some
suggestions
here.
B
B
B
B
Basically,
what
we
want
to
do
is
to
take
the
deployment
view
that
we
have
today
and
enhance
it.
So
we
can
see
the
pod
health
view
across
multiple,
multiple,
multiple
metrics.
So
the
idea
here
is
to
provide
some
sort
of
a
drop-down
box
when
you
click
on
it,
you'll
be
able
to
choose
metrics,
for
instance,
CPU
memory,
network
traffic,
inbound
Alba
on.
So
there
is
a
separate
issue
on
collecting
those
metrics,
and
this
issue
is
about
this
drop-down.
B
B
B
B
E
F
F
B
And
we
should
allow
also
to
choose
like
old
containers,
so
we
need
to
have
like
a
wild
card
here
as
well
as
it
is
walking
today.
Let's
say
that
I
want
to
see
only
the
the
pot,
the
logs
from
the
pods
like
we
have
it
today.
We
should
also
allow
this
to
happen.
Basically,
the
co-infection
ality
no
need
to
remove
some
functionality.
F
B
B
B
G
B
Okay,
the
other
two,
this
one
and
the
one
after
world
talks
about
Cabana
I
know
that
we
discuss
whether
we
want
to
add
cabana
to
two
elasticsearch
or
not,
and
I
think
that
regardless
I
think
that
we
need
to
do
this
book
and
then
this
side,
if
we
want
to
have
given
I,
think
for
now,
for
now,
we
will
have
probably
have
Cabana
and
Cabana
by
the
way,
is
the
visualization
for
elastic
search.
That
elastic
is
using
so
by
the
end
of
this
release.
B
If
we
will
see
that
we
that
elastic
search
is
there
and
walking,
but
we
still
unable
to
deliver
the
padlock,
any
functionality
will
probably
lodge.
This
will
have
this
really
sweet,
Cabana,
so
users
plan
customers
can
access
the
logs
that
are
collected
by
from
elastic
search,
long-term
I
do
think
that
we
need
to
remove
Cabana
and
so
put
it
behind
the
feature
flag
and
because
we
don't
want
to
encourage
our
customers
and
users
to
use
external
tools.
B
This
is
a
bug
that
I
think
was
raised
also
yesterday
in
the
slack
conversation
and
but
basically
when
you
are
doing
zoom
and
you
zoom
in
going
to
chart-
and
you
ended
up
stuck
I-
think
maybe
it
related
I,
so
David
you
mentioned
that
it
might
be
related
to
the
to
the
browser,
but
it
work
differently
with
Firefox
or
Chrome,
but
still
I.
Think.
B
D
B
E
So
when
you
I
don't
know
if
you
have
tried
you
cop
the
link
to
a
chart
from
the
dashboard-
and
you
put
it
in
any
markdown
area
such
as
a
issue
description,
you
should
be
able
to
see
the
chart.
However,
right
now
the
chart
would
not
be
correctly
displayed
yeah
because
you
could.
The
chart
is
only
displaying
the
time
serious
type.
So
you,
you
might
see
something
different
from
what
you
copied.
I
think
this.
This
might
be.
G
G
B
H
D
B
E
So
right
now
there
are
two
versions
of
the
logs
page
and
one
is
built
using
Hamel
and
the
other
one
is
built
using
view
and
the
view
version
will
help
us
moving
forward
to
display
more
sophisticated
dropdowns
that
have
search
or
that
to
some
interesting
things,
and
then
we
would
like
to
switch
completely
to
view.
So
this
is
the
task.
Okay,.
C
E
A
B
D
H
C
G
E
E
Yeah
actually
I
have
a
question
about
that.
Currently
we
have
the
custom
metrics
that
get
stored
in
the
database
and
they
seem
to
be
associated.
We
enter
the
Enterprise
version,
however.
Users
are
able
to
create
their
own
metrics
very
easily,
using
using
their
own
dashboards.
So
I
think
there's
a
bit
of
conflict
of
how
the
custom
metrics
are
supposed
to
work
right
now.
I.
B
B
B
So
there
is
an
initiative
to
move
a
bunch
of
feature,
features
for
monitoring
form
ultimate
Tuco
I
strongly
by
the
way,
support
that
and
of
course
you
need
to
go
to
the
relevant
forces,
and
you
know
the
relevant
people
need
to
need
to
approve
it,
and
so
I
don't
want
us
to
get
in
the
middle
of
like.
Should
we
develop
this
feature
because
it's
in
call
because
of
its
ultimate.
B
E
E
Able
to
put
it
through
the
custom,
metrics
UI
and
it
creates
different
things
in
like
one
creates
an
entry
in
the
database
and
the
other
one
is
create.
Is
the
llamo
like
infrastructure
Asarco
us
code,
so
it's
kind
of
contradicting
and
I
think
we
should
choose
which
one
we
want
to
provide
I
think
we
should
eventually
remove
them.
The
custom
metrics
from
the
database,
yeah
I.
B
H
I
think
it's
I
mean
the
one
advantage
that
custom
metrics
has
going
for.
It
is
that
it
has
a
user
interface.
Now
we
we
do
have
a
plan
for
getting
a
user
interface
in
place
for
making
custom
dashboards,
and
once
we
do
that,
and
maybe
we
can
use
some
of
the
same
code-
I
don't
know,
but
once
we
get
that
in
place,
I
agree,
I,
think
you
know
we
could
consider
deprecating
custom
metrics
in
favor
of
just
making
custom
dashboards.
D
B
B
A
A
Yep
just
to
follow
on
I
just
want
to
make
sure
everyone
as
soon
as
you
realize
her
or
as
soon
as
you
know,
that
an
issue
is
not
going
to
be
completed
by
12:00.
5
I
mean
we.
That
means
they're.
Probably
we
have
about
two
days
before
they
need
to
be
merged,
since
it's
the
13th
then
make
sure
just
to
move
them
as
soon
as
you
can
and
then
put
the
correct
label
and
the
weight
on
them.
So
we
can
manage
them
appropriately.
A
B
A
E
You
have
I
put
a
comma
in
there,
I
don't
know
if
it
makes
sense
to
address
this.
Also
from
the
front
and
sides
say
we
don't
request
any
kind
of
time
frame.
We
we
round
down
with
requests
only
like
maybe
every
minute.
So
then,
if,
if
you
refresh
the
page
ten
times
in
one
minute,
you
still
keep
the
same.
E
F
C
B
B
B
The
discussion
is
on:
how
are
we
going
to
allow
our
users
to
move
from
cube,
CTL
viewing
logs
the
way
with
you
today,
directly
from
kubernetes,
using
the
cube,
CTL,
comma
and
versus
allowing
the
users
to
use
elasticsearch
and
consume
logs
from
the
same
UI
using
elasticsearch?
Now
there
are
like
two
opinions.
B
B
B
You.
Don't
need
to
do
anything
else,
so
the
discussion
is.
Should
we
allow
the
user
to
to
have
the
option
to
select
and
move
between
different
sources,
or
should
we
simply
say
the
default
is
elastic
search
if
you
have
elastic
search
and
if
not,
you
have
a
cube
CTL.
So
that's,
basically
what
what
we
are
discussing
and
I
would
very
much
like
to
hear
your
opinion
about
that.
G
D
It
seems
like
that
the
friction
to
adopting
gitlab
is
lower.
If
we
say
okay
bring,
you
know.
If
we're
not.
If
we're
saying
you
know
we're
not
going
to
support,
you
know
our
support
Cabana,
you
know
from
up
from
a
long-term
standpoint.
We
had
a
if
we
a
solution
for
okay.
You
can
bring
Cubana
until
I,
don't
know
where
I'm
going
with
that,
but
it
seems
like
that
as
a
as
an
ops
person.
D
B
Yeah
I
think
that
okay,
so
let
me
clear
some
of
the
confusion.
I
don't
think
that,
for
now
we
are
at
the
point
that
we
tell
our
users.
Okay,
you
use
the
elasticsearch
used,
lovely
use,
logic
drop,
all
of
them
forget
about
it,
use
what
we
have.
No
I
think
that,
for
now
we
are
addressing
the
developer.
B
If
you
have
a
kubernetes
cluster
and
you're
deploying
your
application
to
github,
we
can
easily
get
those
log,
ideally
the
push
of
the
button,
and
you
can
see
everything
you
know
you
know
get
LePew
I
development,
but
you
don't
mean
to
move
to
another
to
know
talking
about
production
use
case.
Yet
so,
let's
this,
let's
assume
that
we
are
in
this
case,
and
we
know
that
using
elasticsearch
has
the
benefits.
B
Okay,
as
we
deploy
elasticsearch
to
to
the
cluster,
we
can
collect
all
the
all
the
logs
from
the
clusters
from
all
the
next
phase
and
Luco.
They
look
at
them
in
story.
We
can
map
them,
we
can
search
to
them.
There
are
a
lot
of
load
analytics
use
case
that
you
can
do
on
that
specific
environment
and
the
debate
he'll
dude.
We
pull
the
switch
off
cube
CTL
when
a
user
install
a
lasting
search,
or
should
we
allow
the
user
to
select
both
okay?
B
If
you
want,
you
can
use
cube
CTL,
but
if
your
elastic
search,
you
can
use
the
elastic
search
as
well.
Now
the
the
the
different
opinion
and
different
approach,
then
you
will
you
give
the
customer
too
much
choice.
You
may
end
up
confusing
him,
so
this
is
the
this
is
why
we're
saying,
maybe
not,
and
why
why
why
I'm
saying
yes,
is
that
I
think
that
cube
CTL
has
the
own
benefits
and
I.
B
Don't
think
that
we
should
simply
remove
a
functionality
that
is
working
today
and
it's
pretty
good,
because
we
just
you
know,
bring
on
a
different
functionality.
Maybe
maybe
you
know
further
down
the
order,
and
we
see
that
you
know
we
have
like
a
complete
feature
authority
and
the
use
case
with
elastic
search
perfectly.
Then
maybe
we
may
end
up
saying
OK
cube
CTL.
We
don't
need,
but
so
now
you
know
it's
very
easy
to
pull
logs
from
from
port
now
from
container
soon
in
a
push
of
a
button.
So
that's
the
that's.
The
discussion.
D
E
B
F
B
So,
for
instance,
what
will
happen
if
magma,
my
fear,
is
what
will
happen
if,
for
instance,
something
will
will
not
work
with
elasticsearch,
you
know
we
will
run
out
of
storage.
A
5-bit,
which
is
the
component
that
is
pulling
blocks
from
from
the
application,
will
stop
collecting
lots,
and
then
we
end
up
with
a
broken
solution.
B
C
B
B
B
C
B
B
So
it's
not
like
the
tailing
experience
like
live
streaming
of
logs
and
there
are
several
windows
like
similar
Jake
I
got
a
dog
that
provides
you
with
both
options
like
tailing
alone,
and
you
get
like
the
black
screen,
and
it's
like
the
console
like
experience
or
just
viewing
the
aggregating
log
with
in
histogram
from
them.
The
amount
of
logs
that
arrive
and
a
way
to
do
like
a
quick
search.
D
H
Mean
it
sounds
like
we
should,
you
know,
there's
no
harm
in
keeping
both
of
them.
I
think,
maybe
if
we
make
the
UI
a
little
clearer
and
make
some
of
their
like
use
cases
clear
to
the
user
that
may
be,
you
know,
I
mean
even
just
the
fact
that
you
know
being
able
to
tail
logs
I
think
is
enough
of
a
value.
Add
to
keep
it
but
but
yeah.
F
F
E
Eventually,
those
those
api's
would
have
to
diverge,
I
think
because
with
elasticsearch
we
will
be
able
to
query
in
a
different
way,
then
keep
CP
on
one's
right
like
right
now
the
cube
CTL
ones
are
very
rigid,
like
we
have
to
say
what
we
have
to
say:
environment,
pod,
container
and
drill
down,
and
then
an
instead
lasting
search.
One
is
going
to
be
more
like
a
number
of
parameters
and
maybe
as
a
keyword
that
you
put,
and
maybe
a
label
or
a
time.