►
From YouTube: UX Showcase: Logging Updates | 5th February 2020
Description
Monitor: Logging Updates
by Amelia Bauerly, Product Designer – Monitor
A
A
So
to
just
talk
about
what
logs
are
and
what
they're
not
not
trees.
Obviously,
but
they
are
a
detailed
list
of
applications,
information
system,
performance
or
user
activities.
They
can
be
useful.
Sorry,
but
I
have
a
pop-up
that
disappeared.
They
can
be
useful
for
keeping
track
of
computer
use,
emergency
recovery
and
application
improvement,
and
so
they're
used
by
developers
when
something
is
has
gone
wrong
to
see,
what's
gone
wrong
and
to
start
investigating.
Why.
A
Yet
there
were
other
priorities
that
had
come
up,
but
when
the
new
APM
group
started
in
June,
there
was
now
space
to
look
at
this
feature
and
there
was
engineering
capacity
again
to
re-examine
this
feature
and
see
how
we
could
improve
it.
And
in
picking
this
up
and
reviewing
where
we
were
at,
we
suspected
there
were
several
things
we
could
improve
about
the
logging
experience.
A
A
A
We
wanted
to
start
by
talking
to
people
internally
and
externally,
to
hopefully
better
understand
a
what
logging
tools
people
are
currently
using
be
how
reviewing
logs
fits
into
their
workflows,
see
how
important
logs
are
to
them
as
a
feature
and
D.
If
anyone
is
even
using
their
ped
logs,
how
useful
are
they
currently.
A
So
we
talked
to
some
users
and
in
talking
to
people
I
think
the
biggest
takeaway
was
how
important
logs
are
to
their
workflow
that
they're
critical.
In
fact,
you
can
see
some
of
these
stickies
they're
critical
their
big
deal,
so
that
I
think
reminded
us
that,
like
having
them
more
prominent
in
the
UI
would
probably
be
a
helpful
change
that
we
could
make.
We
also
learned
about
why
logs
are
important
in
addition
to
metrics
and
people's
workflow.
A
We
had
spent
a
lot
of
time
thinking
about
metrics,
but
since
we
were
new
to
logs,
this
was
useful
information
for
us.
So
we
learned
that
logs
capture
a
lot
of
information,
but
since
they
capture
so
much
information,
users
need
a
way
to
manage
them,
search
through
them
and
surface
insights
from
them,
and
that's
those
are
all
opportunities
basis
for
gitlab,
because
at
that
point
we
didn't
offer
any
of
that
functionality.
A
A
Think
my
favorite
learning
from
the
study,
though,
that
there
was
that
there
are
essentially
two
pieces
of
logs
that
are
important
to
users,
there's
the
actual
logs
themselves,
which
capture
all
of
the
events
that
occurred,
but
there
is
also
the
analysis
layer
on
top
of
that
that
it's
that
analysis
layer
that
users
are
primarily
interacting
with
because
of
the
number
in
size
of
logs.
It's
the
analysis
layer,
that's
that's
really
critical,
and
that
was
the
layer
that
was
completely
missing
from
gitlab.
At
this
point,.
A
So
from
our
research,
we
generated
a
list
of
products
that
our
users
were
already
using.
So
next
we
wanted
to
better
understand
you
really
what
these
products
look
like.
How
did
it
work
and
what
features
do
they
offer
with
logs
there's
some
giant
players
in
the
space?
There
are
entire
companies
that
build
logging
products,
so
we
started
off
looking
at
a
few
of
them
just
to
get
a
sense
of
what
they
offered.
So
we
did
a
quick
look
at
elastic,
search
data,
dog
and
cabana
and
logs
and
in
reviewing
these
competitors.
A
We
notice,
rather
than
just
showing
a
single
log,
which
is
what
we
were
doing.
They
were
all
displaying
a
basic
table
view
that
aggregated
all
of
the
logs
from
lots
of
different
sources
and
having
a
table
like
this
allowed
users
to
search
through
logs
filter
the
logs
by
specific
times.
So
this
is
that
analysis
layer
that
we
learned
about
from
our
customer
interviews
and
that
was
currently
missing
from
get
labs
offering.
A
So
this
kind
of
reminded
us
that
we
need
to
figure
out
some
way
of
introducing
a
long
explorer
to
get
them
and
from
a
technical
point
of
view.
One
of
the
big
hurdles
to
implementing
this
feature
was
that
we
were
going
to
need
a
fight
to
find
a
way
to
aggregate
all
of
the
logs
and
lots
would
need
to
be
aggregated
combined
into
one
place.
A
Just
in
order
to
do
any
of
that
searching
and
filtering
that
the
competitors
and
the
space
are
doing
and
that
our
users
were
asking
for
so
based
on
the
what
we
learned
from
the
research
and
the
competitive
analysis.
We
created
a
bunch
of
issues
to
improve
the
log,
offering
our
first
step
was
to
increase
the
visibility
of
the
logs
by
moving
them
into
the
main
nav,
so
they're,
no
longer
hidden
behind
a
separate
nav
item
and
a
data
visualization.
A
We
also
introduced
elastic
stack
as
a
get
lab
manage
app.
So
introducing
elastic
stack
is
what
allows
us
to
aggregate
the
logs,
so
that
helps
us
to
start
introducing
all
of
the
search
and
filter
options
that
our
users
are
asking
for.
We
also
started
creating
designs
for
a
simple,
lock,
Explorer
and
to
start
introducing
the
ability
to
search
and
filter
the
aggregated,
logs
and
I'll
just
show
a
couple
of
the
designs
here,
and
these
were
just
for
MVC's
of
a
log
Explorer
and
what
it
could
look
like
in
our
UI.
A
So
this
sort
of
log
Explorer
would
start
to
introduce
that
analysis.
Layer
I've
been
missing
from
our
logs
and
start
moving
their
logs
into
more
of
the
the
table
view
that
we
were
seeing
in
our
competitors,
products
and
in
designing
this.
We
wanted
to
use
as
many
of
the
existing
patterns
and
make
it
web
UI
as
possible.
A
So
the
experience
of
searching
through
logs
could
be
similar
to
how
we
search
through
pipelines
and
mrs
and
issues
all
of
all,
of
the
other
things
that
we
just
searched
through,
and
we
were
also
hoping
that
going
in
this
direction
would
allow
us
to
utilize
existing
patterns
and
components.
So
we
can
build.
They
build
this
faster
and
ensure
consistent
experience
across
Skylab
and
similar
to
searching
and
filtering.
A
This
is
how
we
we
wanted
to
introduce,
search
and
filter
in
a
similar
way,
that
we
do
it
on
the
issues
page,
so
that
users
can
quickly
narrow
down
their
logs
by
name
space,
pod
or
container.
So,
if
there's
a
problem
and
they
need
to
find
a
specific
log,
they
can
really
quickly
dive
down
and
find
that
log
and
you'll
notice.
These
icons
were
all
placeholders,
but
Jeremy
has
been
making
some
beautiful
icons
for
us,
so
you
will
see
those
soon,
which
is
very
exciting.
A
A
Our
way
towards
solutions
is
that
the
intermediate
steps
don't
always
look
the
way
that
we
want
them
to,
and
this
was
very
painful
for
me,
which
is
why
I'm
sharing
it
here,
we
were
able
to
create
an
aggregate,
aggregated
collection
of
logs,
which
is
a
huge
step
forward,
but
we
weren't
able
to
make
any
of
the
visual
or
UI
improvements
we
had
originally
planned.
So
essentially
the
filtered
search
component
that
we
were
hoping
for,
hoping
to
be
a
little
utilized
wasn't
available.
A
B
A
A
If
there's
a
gigantic
amount
of
logs
and
users
need
to
find
one
specific
log.
Amongst
that,
amongst,
like
great
amount
of
logs,
we
need
to
allow
them
to
be
able
to
do
that
and
then,
once
these
pieces
are
in
places,
we
can
start
a
debt
adding
in
additional
announced
dis
layers.
On
top
of
all
of
that,
so
that's
all
I
had.
If
you
have
questions,
please
voice
them,
otherwise,
ed
bans.
The
docker
send
me
a
message:
I'd
love
to
hear
any
thoughts
or
questions
or
comments.
B
I
have
a
comment
and
a
question
my
commend
is
this
is
deeply
thoughtful
work
I'm
very
impressed.
So
thank
you.
My
question
is
pardon
me.
You
did
a
really
good
job
of
laying
out
like
what
you
learned
and
then
how
you
prioritize.
What
the
next
steps
are.
Can
you
talk
a
little
bit
about
how
that
process
happen
so
that
you
knew
like
basically
how
to
prioritize
those
items.
A
Sure
sure
I
think
it
was
a
conversation
with
a
team,
I
think
I
would
say
we
have
the
user
feedback.
Saying
users
are
saying
this
is
really
important
and
then
we
also
had
to
balance
so
engineering.
You
know
considerations
in
terms
of
technical,
like
this
is
what
we
need.
These
are
the
steps
that
we
need
to
do
in
order
to
make
this
possible
like,
for
instance,
we
had
to
allow
elasticsearch
to
be
installed
as
a
gate
lab
managed
app
before
we
could
even
aggregate
the
lock.
A
So
from
a
technical
point
of
view,
there
were
a
series
of
steps
that
we
had
to
go
through
in
order
to
have
the
functionality
be
available,
so
it
was
definitely
a
continuing
conversation
between
here's.
What's
important
from
like
a
users
point
of
view
and
from
you
know
a
design
point
of
view,
here's
what's
important
from
a
product
and
from
an
engineering
point
of
view,
and
it
was
Farrell.
A
It
was
a
lot
of
negotiation
and
a
lot
of
balancing
and
I
think
yeah
I
don't
know
if
there
was
like
one
clear
thing
that
that
made
the
decision
for
us
ultimately,
but
it
was
balancing
all
of
those
competing
considerations
and
trying
to
have
as
many
open
conversations
about
all
of
those
things
as
we
could
as
a
team.
So.