►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So,
who
are
we
siobhan
is
our
director
of
product
marketing
here
at
lookout
she
likes
to
practice
yoga
and
make
sure
not
to
take
life
too
seriously.
B
B
Before
we
are
going
to
start
the
quest
of
real-time
data
code
level,
data
and
dynamic
observability,
I
want
to
take
a
step
back
and
see
where
we
are
today.
So
organizations
are
trying
to
reduce
cost
to
optimize
costs.
They
are
looking
for
agility
they're
looking
for
elasticity,
and
this
is
why
they're
moving
their
applications
and
infrastructure
to
the
cloud
adaption
of
cloud-native
applications
and
technologies
such
as
microservices
containers,
dynamic,
orchestration,
devops
are
booming,
and
we
expect
to
see
in
2024
that
70
out
of
all
applications
are
going
to
be
cloud
native
in
2020.
B
So
this
big
trend
brings
many
challenges
together
with
it
and
we
see
and
hear
from
our
customers
that
the
most
common
challenges
are
optimizing
costs,
modernizing
application,
breaking
down,
monoliths,
rebuilding
them
as
microservices,
and
adapting
new
tools
and
new
methodologies
to
support
this
entire
new
ecosystem.
B
In
addition,
we
see
that
another
third
is
going
to
adapt
and
maintain
observability
pipeline
in
the
near
future,
and
although
those
numbers
are
pretty
high,
it's
not
surprising
at
all-
and
this
is
because
clouded
applications
are
very,
very
dynamic
and
complex,
and
the
only
way
to
maintain
their
quality
is
to
be
able
to
get
logs
traces
metrics
on
the
fly
and
in
any
time
and
if
possible,
to
visualize
them.
So
you
can
have
instant
understanding
of
the
state
of
your
application.
B
So
further
highlighting
the
interest
around
observability,
we
see
here
that
galtner
stated
2021
as
the
year
of
observability,
and
we
see
again
they
highlight
the
fact
that
observability
is
not
equal,
equal
monitoring,
meaning
it's
so
much
more
and
we're
going
to
to
see
and
discuss
it
in
the
next
few
slides.
B
A
So
what
is
observability
observability
is
defined
as
our
ability
to
see
and
understand
inside
the
application
when
the
application
is
having
a
problem.
We
want
to
be
notified
about
it.
We
want
to
be
alerted
and
we
want
to
be
able
to
troubleshoot
and
get
to
the
root
cause
of
the
problem
as
quickly
as
possible.
A
Traditionally,
the
observability
tools
are
divided
into
three
pillars,
although
of
course,
as
you
will
see
on
some
of
the
logos
of
the
state,
many
of
them
solve
problems
that
are
in
more
than
one
page.
A
These
tools
need
to
provide
logs,
collect
logs,
deliver
them
to
developers
and
let
them
see
what
happened
as
the
application
was
running.
They
need
to
collect
traces
which
give
us
additional
context
and
tell
us
which
of
the
dozens
or
hundreds
of
microservices
or
serverless
functions
were
involved
in
a
specific
flow
and
the
interconnection
between
them,
and
they
need
to
collect
and
aggregate
metrics
that
allow
us
to
measure
quantifiable
data
over
time
and
understand
the
behavior
of
our
application.
A
Now
these
tools
are
very
popular.
Most
companies
who
develop
cloud
native
applications
use
at
least
one
of
them,
but
these
tools
also
have
some
key
limitations
that
we
need
to
be
able
to
identify
and
address.
A
A
But
you
need
the
context
in
order
to
be
able
to
understand
what
happened
just
a
minute
before
that,
just
a
millisecond
before
that,
and
also
if
you
are
running
a
complex
and
distributed
application
with
hundreds
or
thousands
of
nearly
identical
services,
you
need
to
be
able
to
understand
which
one
of
them
was
invoked,
which
one
of
them
was
seeing
that
special
condition
in
order
to
get
the
full
picture
of
what
was
going
on
and
displaying
that
full
picture
means
printing
additional
logs
and
collecting
additional
data,
which
brings
us
to
another
challenge.
B
Yes,
did
you
write
today?
Context
is
the
number
one
problem,
but
adding
context
printing
more
load
lines
bring
us
to
the
second
one,
second
highest,
one,
which
is
super
high
cost.
When
we
lack
context,
we
find
ourselves
adding
code,
wait
for
another
redeployment.
So
for
sure
we
are
wasting
developer
time.
B
But
in
addition
to
that,
we
are
also
paying
a
lot
of
money,
we're
paying
for
log
collection,
we're
paying
for
a
lot
of
aggregation,
we're
paying
for
log
ingestion
and
we're
paying
for
log
services
and
on
top
of
all
that,
we're
also
paying
in
application
performance,
because
when
we're
printing,
more
log.
A
B
The
application
performance
is
dropping
so
paying
all
around
is
never
good.
Companies
are
in
constant
strive
to
reduce
costs
to
optimize
costs
because
they
want
to
be
competitive.
B
A
B
Is
the
average
annual
cost
of
limiting
the
low
data?
Where
is
it
coming
from?
So,
first
of
all,
when
we
have
an
issue-
and
you
don't
know
where
it's
coming
from,
then
we
need
to
reproduce
it
to
reproduce
it.
We
need
a
setup
in
place
and
this
setup
is
usually
very
expensive.
So
this
is
one
time
second
time.
If
we're
not
solving
the
issue
fast
enough,
then
we
have
a
problem
where
we
have
our
customer
experience.
Dropping
we
have
a
problem
of
losing
actual
money
transition
that
are
not
there
if
the
application
is
done.
B
So
this
is
second
time
and
third
time
we
have
our
developers
that
we're
shifting
their
original
task,
which
is
to
build
code
with
new
features
instead
they're
occupied
with
finding
bugs
resolving
those
issues,
and
unfortunately
these
tests
can
take
days,
and
sometimes
even
tweaks.
So
this
is
one
time
when
we're
not
logging
enough.
A
B
Of
1.8
million
dollars-
where
is
this
coming
from
it's
coming
from
logging
form
fear
of
missing
out,
and
I
think
you
can
all
relate
to
that
developers
are
in
fear
that
when
the
need
is
there,
they
will
not
have
the
debug
data
that
they
need
so
they're.
Pushing
for
for
storing
the
highest
log
velocity
possible
and
those
logs
are
accumulate
to
high
volume
and
obviously
to
very
high
expensive,
so
losing
on
one
side
losing
on
the
other
side.
There
must
be
a
better
way.
A
And
the
third
challenge
we
face
as
we
try
to
use
traditional
observability
tools,
is
the
challenge
of
the
black
box.
Traditional
observability
tools
ask
us
to
add
more
code
and
to
change
the
application.
Every
time
we
want
to
fetch
additional
logs
and
engineers
want
to
see
the
code
and
want
to
add
code
dynamically
so
that
they
can
get
a
look
into
the
blackbox.
A
A
Some
of
them
try
local
debugging
or
command
line
debugging,
which
is
basically
seeing
the
code
on
your
own,
desktop
and
running
it
in
a
way
that
will
stop
whenever
the
application
hits
a
breakpoint
and
then
you
get
to
see
a
full
view
of
the
local
variables
which
is
what's
happening
inside
the
box,
but
in
cloud
native
applications
you
are
not
always
able
to
reproduce
the
issue
or
to
run
the
same
application
locally
on
your
desktop,
and
even
if
you
do,
you
know
an
application
that
is
supposed
to
run
dozens
or
hundreds
of
microservices.
A
Stopping
everything
or
stopping
one
micro
service
will
just
not
help
you
reproduce
the
same
issue.
Other
customers
rely
on
logging
and
tracing,
and
then
they
face
the
challenges
that
we've
already
mentioned
in
this
presentation.
The
lack
of
context
and
the
need
to
pay
a
lot
of
money
for
storing
and
ingesting
logs,
and,
of
course,
there
is
a
performance
tip
that
the
application
suffers
when
printing
too
many
log
lines
and
collecting
too
many
traces,
and
this
all
returns
to
the
root
cause.
A
Where
printing
those
additional
logs,
adding
more
traces
means
changing
code
waiting
for
the
application
to
build
and
redeploy
again
waiting
for
a
restart,
and
it
means
waiting
for
time
for
a
significant
time
before
you
get
to
see
additional
data.
Some
customers
try
remote
debugging,
which
is
between
a
challenge
and
a
completely
impossible
task.
A
When
you
are
trying
to
develop
things
like
kubernetes
and
aws
lambda
and
similar
technologies
and
too
many
of
our
customers
fall
back
to
crossing
fingers,
praying
and
deploying
to
production
blindly,
which
means
that
you
know
there
will
be
a
bug
the
following
day.
You
know
you
will
need
to
deliver
a
hot
fix
or
roll
back
and
have
a
lot
of
trouble
and
inefficiency.
A
So
this
situation
is
just
not
good
enough.
Traditional
observability
tools
help
us
see
inside
the
application
and
help
us
solve
problems,
but
there
has
to
be
a
better,
more
efficient
way
and
happily,
there
is,
if
you've
heard
about
tools
that
describe
themselves
as
production,
debugging
tools
or
live
debugging
tools.
B
So
introducing
dynamic,
observability
traditional
observability
is
a
way
to
ask
questions.
We
set
and
predefine
in
advance
a
few
parameters
that
we
care
about
and
we're
going
to
get
beautiful,
dashboards
and
alerts
when
something
happens
with
them.
But
it's
not
real
time.
If
something
that
is
not,
there
wasn't
defined
in
advance,
we're
not
going
to
get
it
with
dynamic
observability.
B
We
ask
questions
in
real
time
and
we
get
answers
in
real
time,
so
the
magic,
the
mechanism
behind
dynamic
observability,
is
what
we
call
non-breaking
breakpoints
non-breaking
breakpoints
are
disrupted
technology
that
allow
developers
to
get
traces
logs
and
metrics
on
the
fly
they
can
instrument
line,
switch
it
on.
They
can
get
a
debug
snapshot
with
local
variables,
with
stack
traces
and
with
that
they
can
really
change
their
workflow.
They
don't
need
to
wait
anymore,
it's
instantly
there
for
them,
so
this
is
dynamic.
B
Observability.
Now
this
dynamic
instrumentation
power
by
byte
code
manipulation
is
happening
with
the
code,
it's
running
with
the
code,
and
this
is
why
it's
instantly.
This
is
why
you
don't
need
to
wait.
This
is
why
the
data
is
in
real
time,
and
it
is
there
for
you
once
we
have
this
new
debug
data,
we
can
pipeline
it
to
a
set
of
observability
tools
that
are
already
there,
your
favorite
tool.
You
can
choose
and
analyze
it
all
together.
A
B
A
A
developer
can
work,
can
look
at
the
application
from
the
outside
and
see
dashboards
and
metrics
and
actually
bargain
production,
which
is
something
that
not
many
of
the
developers
even
there
to
think
about,
and
on
the
flip
side,
a
devops
engineer
can
have
the
benefits
of
seeing
the
code
of
working
in
context
of
working
locally
without
the
impact
of
hurting
the
application,
while
actually
running
on
a
live
environment
and
in
the
middle
of
those
you
will
find
work
out
and
you
will
find
dynamic
observability
as
the
way
to
to
make
these
two
worlds
meet.
A
It
means
that
you
can
solve
bugs
much
much
faster,
even
in
very
dangerous
and
complex
environments,
such
as
cloud
native
production
environment,
and
when
you
solve
problems
faster,
you
get
happier
customers
and
you
have
more
time
to
deliver
more
business
value,
which
increases
your
efficiency
and
the
efficiency
of
your
team.
You
can
do
that
without
paying
too
much
for
additional
loans
and
traces
without
paying
more
money
for
storage
and
ingestion
and
without
suffering
the
performance
kit
and
the
bottom
line,
and
I
think
that's
the
part
we
all
here
at
rooker,
really
care
about.
A
A
So
we
hope
you
found
this
interesting
and
we
hope
you
are
now
curious
to
try
dynamic
observability
for
yourself.
Thank
you
for
watching
this
webinar
and
if
you
have
any
further
questions
or
comments,
feel
free
to
reach
out
happy
to
hear
from.