►
Description
Kubernetes provides great means to run distributed multi-cloud applications. By providing a foundation for microservice architectures, Kubernetes solves many of the day to day problems DevOps teams face. OpenShift adds the stability &trust that organizations need when adapting this new paradigm. But a stable container platform can only be the beginning. In order to successfully run & manage applications, teams need to understand the broader context. This starts with a deep understanding of the infrastructure like the OS, the storage, or the network and how they are utilized, but it doesn’t stop there. For microservice based applications the service dependencies are even more important. DevOps teams need to understand how their Kubernetes deployment contributes to their application and what the dependencies within or outside of Kubernetes are. We will cover the importance of understanding the entire context of an application running in Kubernetes.
A
Thank
you
very
much
diane
yeah,
my
name
is
matthias
lipkin
and
today,
I'd
like
to
talk
a
little
bit
of
how
you
know
our
experience
of
running
our
operator,
running
kubernetes
workloads
and
what
we
see
from
our
customers.
You
know
of
the
new
challenges
they
have
running
these
just
a
few
words
about
myself
on
the
pm
for
kubernetes
and
infrastructure
at
insana
got
some
cut
some
experience
on
software
development
all
over
the
place.
A
I've
actually
been
with
red
hat
then
done
some
interesting
stuff
over
there
and
now
within
sana.
We
are,
you
know,
focusing
on
helping
developers
and
devops
teams
to
kind
of
manage
all
this.
You
know
crazy,
crazy
things
that
we're
seeing
and
operators
help
a
lot.
You
know,
I
hope
our
this
talk
helps
a
little
bit
and
yeah
some
of
the
experiences
that
we
had
all
right.
So
basically
one
talk
in
the
slide
right.
This
is
the
agenda.
This
is
the
talk.
A
So
what
I
would
like
to
talk
about
today
is
basically
give
a
you
know,
an
understanding
of
how
of
what
to
look
for
if
you're
running
an
application
in
kubernetes-
and
you
know
we-
we
kind
of
like
separated
the
different
aspects
of
different
perspectives-
and
you
know,
came
up
with
these
three
perspective
basic
respective
different,
different
views
on
this,
and
that's
what
I
would
like
to
share
today
and
also
give
you
very,
very
time
tangible
ways
of
doing
this
on
the
the
slides.
The
contents
have.
A
A
lot
of
you
know
further
links
to
to
deep
dive
on
on
how
how
to
get
it
going
for
yourself.
So
I
hope
there's
a
lot
of
things
to
take
away
all
right,
so
this
was
actually
actually
something
that
that
you
know
brought
up
in
may.
But
I
I
love
that
I
love
the
the
phrasing
of
it
is
when
natives
is
very
good
at
solving
the
problem.
It
reduces
in
your
environment
right
so
you
know.
Kubernetes
and
openshift
are
awesome.
A
Platforms
are
awesome
platform
for
distributed
for
for
managing
distributed,
distributed
setups,
but
at
the
same
time
it.
It
also
introduces
a
lot
of
the
complexity
that
we
might
or
might
have
not
been
exposed
to
initially-
and
I
think
this
is
a
this
is
a
real
challenge
right.
It's
it's
a
it's.
Yes,
we're
techies
and
we
we
want
to
get
this
all
solved,
but
it's
not
it's
not
always
simple
right.
A
So
if
we
take
a
step
back
or
if
we
look
at
what
a
kubernetes
application
actually
introduces,
it's
actually
you
you're
quite
quite
a
few
new
attributes
that
that
make
these
these
things
really
challenging
the
first
of
all.
It's
you
know
we,
you
know,
we've
talked
about
microservices
based
applications
before,
but
to
be
honest,
that
that
hasn't
been
the
scale
as
I've
seen
before,
with
kubernetes
and
with
kubernetes
there's.
A
You
know
a
decent
application
certainly
consists
of
hundreds
of
thousands
microsoft's
very,
very
different,
and
you
can
talk
about
pros
and
cons
of
microservices,
but
the
matter
of
the
fact
is
kubernetes
allows
us
and
gives
a
lot
of
means
to
doing
so.
So
you
know
people
are
taking
advantage
of
it,
but
they
also
need
to
manage
these.
A
The
change
also
increases
dramatically
what
with
developers
openshift
provides
a
great
platform
for
continuous
deployment,
and
you
know
the
increased
change
of
these
is
just
just
tremendous
and
parts
come
and
go
right.
So
you've
got
these
auto
scalers,
you've
got
rolling
deployments
and
everything
is
getting
ephemeral
right.
So
you
know
also
something
that
you
know
at
least
for
me,
but
also
what
I'm
seeing
from
customers
is
something
that
they've
not
not
been.
You
know
really
used
to
it,
and
you
know,
containers
are
awesome
right.
A
A
So
when
you
are
then
looking
off
of
what
what
does
that
mean?
What
are
the
problems?
What
are
the
challenges
that
that
you
face
that
these
are?
These
are
some
of
them
that
that
I
I
hear
hear
most
as
if,
if
there
are
using
estana
or
any
other
other
tool
of
looking
up
of
what
what
the
kubernetes
applications
are
doing
is
like
okay,
so,
first
of
all
what
is
actually
affected
like
like
I'm
building
my
application,
it
has
a
problem
what
are
actually
affected
and
what
what
metrics
do?
A
I
need
to
look
at
like
well,
what
is
the
cpu
utilization?
What
are
the
request
rates
and
where,
where
I
start
looking
at,
what
will
be
actually
all
these
metrics
actually
mean
right?
Okay,
now
I've
got
I've
got
a
list,
but
how
do
these
work
together
right
now,
I've
got
a
couple.
What
else
do
I
need
to
look
at
and
what?
What
is
the
root
cause
to
all
this
problem
and
again
right?
This
is
about
you
know,
developers
devops
that
are
are
now.
You
know,
working
with
this
new
environment
for
them
new
right.
A
A
They
do
codify
a
lot
of
these
things,
but
they
put
another
level
on
this
and
stitching
these
things
together
might
have
their
own
means
of
sharing
that
distributed
load
and
putting
their
own
custom
resource
definitions
and
again
like
which
metrics
do
I
look
at
what
do
these
mean
right,
so
another
layer,
challenges
and
and
managing
the
companies
application
all
right?
Let's
look
at
it.
Let's
look
at
an.
A
A
Not
not
too
unrealistic
example,
let's,
let's
say
we're:
building
an
elastics
or
a
search
application
right
and
and
throwing
throwing
up
using
elasticsearch.
You
know
the
common
common
tool
for
that
so
running
this
in
kubernetes.
You
know,
obviously
means
that
we
have
a
deployment
in
the
name
space.
A
You
know,
then
the
the
elastic
search
itself
is
written
in
jvm,
so
that
jvm
is
running
in
a
container
on
a
part,
most
likely
we're
running
this
on
a
linux
host
right,
which
is
itself
a
kubernetes
node
with
its
own
properties,
and
all
this
thing
is
running
in
a
kubernetes
cluster
and
some
availability
right.
So
the
question
is
like
what
what
do?
I
need
to
know
what
what
happens-
and
I
guess
you
know,
if
you're
looking
at
a
problem
right,
then
these
all
surface
right
so.
A
Is
that
that
we're
actually
talking
about
the
cluster
right?
So
the
elastic
search
is
not
a
single
note,
but
rather
a
cluster,
and
each
of
these
you
know
easily
classes
obviously
mentioned
in
a
couple
of
nodes
and
we
might
have
a
spring
boot
application
or
another
java
application.
You
know
most
likely
with
a
similar
stack,
but
let's
look
at
a
let's
look
at
a
problem
that
that
that
could
could
happen
right.
So,
let's
start
with
the
lower
around
right
hand
corner
the
first
one.
A
Let's
say
that
that
the
node
has
a
an
I
o
problem
right
and
that
that
particular
shard
in
the
elasticsearch
cluster
you
know
is,
is
getting
something
to
to
look
out
for
then
you
know,
maybe
the
the
thread
pool
itself
on
the
jvm
on
the
elasticsearch
node
is
has
a
problem
and
there's
a
warning
sign
right.
So
I'm
I'm
circling
these.
A
So
I
think
the
the
the
the
message
I
want
to
bring
across
is
is
you
know
this
is,
I
wouldn't
say
too
complicated
too
far
off
application,
a
rather
simple
application,
but
you
can
also
see
that
that
you
know
specific
problems
could
be
somewhere
anywhere
in
in
this
in
this
in
this
setup-
and
I
would
like
to
you
know-
give
give
a
little
order
into
this
and
give
a
little
bit
guidance
on
on
where
to
start
and
how
to
look
for
right.
This
is
a
little
little
example
from
up
from
our
tool.
A
So
instanta
is
an
monitoring
observability
tool.
We
do
all
sorts
of
sources
of
what
we
gather
and
we've
got
this,
this
dynamic
graph
that
hooks
up
everything-
and
this
is
actually
you
know
just
a
visualization.
This
is
a
fun
project
of
seeing
the
death
star
of
all
these,
you
know
components
hooked
up
quite
fun.
Actually,
the
live
version
is
even
even
funner,
because
it's
it's
it's
dynamic
and
you
can
see
things
moving
all
right.
So
how
do
we
get
started?
A
A
A
I
just
put
them
here,
but
I
also
think
that
it's
you
know
the
the
the
nice
thing
about
devops.
Is
that
we're
not
building
up
walls
right?
So
we
don't
want
to
cut
off
and
then
say
I
don't.
I
don't
care
about
the
rest.
Just
give
me
a
host
and
I'm
done
with
it.
You
know
we
want
to
combine
these,
so
I
think
it's
also
important
to
share
this
perspective.
A
Share
these
views.
Share
these
metrics
share
dashboards
between
the
different
organizations
and
yeah.
I'm
looking
forward
to
to
what
you
guys
think,
but
that's
that's
that's
my
that's
our
perspective.
Now,
just
just
a
word.
This
is
one
view
of
this
right
and
we,
you
know
kind
of
you
know,
brought
that
to
instagna,
but
there's
obviously
lots
of
all
other
perspectives.
A
A
When
I
was
preparing
to
talk
with
with
a
colleague
of
mine
that
something
else
is
such
more
and
more
important
than
the
three
perspective
I
I'm
talking
about
here,
but
you
know
it's
just
it's
one
view
right
and
if
you
think
others
are
more
important
happy
again
to
to
reason
and
talk
about
it,
but
I
think
these
these
are
generally
applicable
all
right.
So
we've
got
these
three
perspectives.
So
what
what?
What
should
I
look
at?
A
How
should
I
look
at
these
and
then
last
but
not
least,
let's
put
them
in
context
all
right,
let's
start
with
the
service
again
how?
What
am
I
looking
for
so
the
definition
for
services,
for
me
is
something
that
is
is
has
some
logical
context
to
it
right.
So
it's
it's
implementation
and
infrastructure
independent
and
we
care
about
what
the
service
provides
to
that
user
right.
We've
also
got.
A
Now
the
important
piece
is
that
we're
looking
at
an
implementation,
independent
definition
here,
because
technology
specific
kps
can
be
misleading
right
and
you
know,
maybe
you
want
to
exchange
the
servers
with
a
different
technology,
so
you
know
there's
so
many
things
that
you
can
consider
about
the
technology.
So
let's
look
at
the
logical
in
itself,
especially
in
kubernetes,
as
I
I
you
know
briefly
mentioned
with
a
polyglot
environment.
There's
so
many
things.
So
you
know,
let's,
let's
take
the
logical
view
on
this
extract.
A
So
if
you,
if
we're,
then
looking
off
of
what
what
to
observe
what
are
we
looking
into
their
first?
The
first
question
that
you
need
to
to
answer
for
yourself
for
your
team
is
of
the
granularity
of
a
service.
You
know
we're
we're
supporting
very
heterogeneous
environments
and
I
guess
in
kubernetes,
there's
there's
there's
already
a
structure
to
to
what
a
service
is,
but
it
doesn't
have
to
be
right.
A
A
The
other
part
is
that
you
don't
need
to
consider
is
some
sort
of
higher
level
assemblies
you
know,
given
the
operator
right
operator
is
a
good
means
of
stitching
these
things
together,
there's
also
the
application
trd
or
or
helm,
but
you
know
it
doesn't
have
to
be
on
the
kubernetes
side
of
things.
You
can
also
talk.
Think
about
it
differently
of
you
know
many.
Maybe
some
other
back-end
unit
is
also
belonging
to
that
you
know
logical
assembly
and
I'm
I'm
making
this
term
very
very
loosely
we're
calling
these
application
perspectives.
A
Tom
wilkie
from
we
forex
introduced
the
red
method,
which
resonates
a
little
bit
me
more
with
me
because
it
takes
out
the
saturation
which
is
a
technology
specific,
often
a
very
technology,
specific
component.
That
said,
you
know
both
work,
I'm
going
to
go
with
the
raid
errors,
duration
throughout
broad.
A
So
these
are.
These
are
just
some
examples.
On
the
left-hand
side,
you
see
the
it's
it's
on
a
dashboard
right
where
we,
you
know,
show
the
information
of
of
that
service,
but
obviously
this
is
not
bound
to
to
any
tool
whatsoever,
and
so
here
on
the
right-hand
side,
I've
just
you
know,
introduced
a
grafana
dashboard
that
shows
similar
similar
stats
right
and
in
openshift.
You
get
similar
views
of
you
know,
showing
the
the
traffic
showing
the
errors
and
yeah
red
request,
errors
and
duration
all
right.
A
A
The
I
guess
the
most
common
one
at
least
out
there
in
the
space
that
will
that
we're
capturing
these
natively
or
with
some
library
out
of
the
workload
itself
and
in
the
openshift
club
space
prometheus
is
the
standard
and,
if
we're
looking
at
java
again,
there's
tons
of
tons
of
options
of
just
using
using
a
specific
library,
called
client
driving,
client
java,
a
max
exporter
or
micrometer
exporter.
So
that's
the
most
common
one
we're
seeing-
and
you
know,
also
probably
very
straightforward,
a
different.
A
The
advantage
with
that
is
that
it's
a
it's
it's
it's
like.
You
don't
have
to
do
anything
if
you,
if
you're
looking,
for
example,
if
you're
using
a
service
mesh
or
if
you're,
using
a
standard,
you
don't
have
to
do
anything,
you
can
capture
them
automatically
and
the
other
one
advantages,
at
least
within
sauna,
that
you
can
dynamically
change
this
and
it's
not
in
other
tools.
You
can
dynamically
change.
The
service
commit
composition,
the
granularity,
something
that
I
talked
earlier
about.
A
A
That's
always
the
starting
point:
that's
where
we
are
based,
basing
our
sli's
on
our
service
level
indicators,
our
slos,
the
objectives
that
we
strive
for,
and
it's
just
the
kind
of
the
the
starting
starting
point
to
to
it
all
every
if
you,
if
you
do
one
thing,
then
do
this
right,
but
I
think
for
understanding
the
whole
perspective
to
understanding
everything.
I
think
the
other
perspectives
are
equally
important,
which
brings
us
to
kubernetes
so
kubernetes,
as
the
you
know,
probably
don't
know.
A
Something
that
I
haven't
included
in
the
example
earlier
are
persistent
volumes,
persistent
position
volumes
to
the
elasticsearch
environment
so
to
the
electric
search
application.
So
actually
you
know
the
database
can
be
stored,
so
you
know
that's!
That's
the
the
the
job
of
of
kubernetes,
and
has
these
you
know
great
apis?
A
A
If
it's
a
demon
set,
is
it
evenly
distributed
on
all
the
nodes
that
I
want
to
have
taken
care
of
or
and
if
I
have
a
deployment
is
it
you
know
at
the
scale
that
that
I
need
and
if
something
is
going
unavailable
is
that
is
that
still
in
my
you
know,
budget,
or
is
that
something
that
I
need
to
consider
on
the
workload
side
of
things
for
the
scheduler
to
run
for
for
making
sure
that
the
works
are
distributed?
We
have
requests
and
limits.
A
The
the
starting
point
of
you
know
investing
things
and
maybe
a
little
bit
on
the
starting
point.
That's
also
something
that
I
found
very
interesting.
These
three
perspectives
is
no
means.
Is
there
a
we?
We
need
to
measure
the
services,
as
I
said
earlier,
but
it's
not
something
that
that
you
that
it's
also
very
natural
for
people
coming
from
a
different
background,
starting
somewhere
else
right
so
with
the
kubernetes
environment.
Maybe
I'm
I'm
more
on
the
devops
side
and
I
need
to
to
to
to
level
up.
A
I
need
to
make
sure
that
a
new
new
name
space
is
running
smoothly
right,
so
I'll
start
with
the
namespace,
but
I
guess
the
important
pieces
that
you
know
when
you're
starting
kubernetes
that
you
also
understand
which
envir,
how
is
it
running
on
the
on
the
host
itself
on
the
cluster
itself,
that
you
have
some
means
of
getting
there
and
that
you
also
have
some
means
of
understanding
what
the
applications?
What
what?
What
are
actually
the
developers
putting
on
there
right?
Oh
so,
you
know
having
good
starting
points.
A
I
think
it's
it's
important
and
linking
them
again,
which
I'll
talk
about
how
to
measure
that's
actually
pretty
nice
in
kubernetes
right
because
it
basically
is
all
there
right.
We've
got
cube
state
metrics,
which
talks
about
all
the
things
around
the
workloads.
The
configuration
is
the
service
themselves
and
just
provides
provides
these
metrics
on
the
control
plane.
We
have
the
individual,
metrics
endpoints
and
just
you
know
for
for
completeness.
There's
metric
server
to
in
do
dual
auto
scaling.
A
So
there's
everything
is
already
there
and
I
have
the
dashboard
there,
but
with
these
being
provided
as
standard
there's,
also
like
a
lot
of
pre-can
dashboards
ready
to
just
you
know,
have
this
perspective
ready
and
and
easy
to
see,
and
we
have
that
in
grafana
we
have
an
openshift,
so
it's
it's
pretty
pretty
easy
to
to
get
started
with
and
to
to
enhance
with
more
metrics
all
right
infrastructure.
So
why
do
we
then
now
need
to
look
at
infrastructure
and
the
example
that
I
I
gave?
Should
you
know
hint
at
it
right?
A
The
I
o
problem
on
the
host
is
something
that
is
needed
for
the
troubleshooting,
but
also
without
the
trouble
shooting
it's
it's
an.
I
think
it's
something
that
we
shouldn't
be
afraid
of,
or
developers
develop,
shouldn't
be
afraid
of
of
having
this
this
in
mind
and
not
like
you
know,
only
look
at
the
at
my
part
and
my
jbm,
but
also
understanding
of
how
the
jvm
run.
What
what
are
the
threads
doing?
How
is
it
running
on
the
on
the
on
the
host
right?
A
So
yeah,
you
know-
maybe
that's
that's
one
takeaway
for
for
the
talk
right
is
encouraging
developers
to
look
into
this
and
understanding
of
of
what's
happening
there.
Hopefully,
maybe,
with
with
this
talk
a
little
bit
of
of
what
to
look
at
now
very
very
important
right.
We
talked
about
the
services
being
the
starting
point.
That's
still
the
case
right,
cpu
utilization,
as
adrian
cockroft
says,
is
virtually
useless
as
a
metric
in
itself.
A
There's
a
similar
method
here
by
brandon,
greg,
awesome
performance
engineer,
does
lots
of
talks
and
lots
of
great
books
and
the
use
measures
talks
about
you
know
for
all
physical
server
components,
so
we're
looking
at
cpus,
memories
and
storage.
For
all
of
these,
you
know
look
at
basically
three
things.
First
of
all,
look
at
the
errors
right
if
there's
an
easy
way
to
get
at
the
errors.
A
Look
at
the
errors
and
what
do
they
tell
you,
look
at
the
utilization
so
how
busy
the
resource
was
serving
serving
the
work
and
the
situation,
so
how
much
work
is
kind
of
like
queued
up
for
this
resource
to
to
work
at
so
on
the
host
level?
You
know
we
have
all.
You
know
these
gazillion
resources
on
the
horse
itself
or
connected
to
the
host.
So
you
know
something
that
you
know.
A
A
This
is
this
is
another
example.
I
just
found
that
found
an
interesting
on
the
on
the
jvn
side.
Right
jbm.
Being
such
an
important,
important
part
of
our
system
is
that
we
kind
of
you
know
looking
into
it
deeper
and
looking
at
you
know
different
different
metrics
there,
be
it
threads,
be
it
the
the
heap.
The
memory
pools
and
especially
the
garbage
collection
is,
is
something
to
you
know,
understand,
and
you
know
have
ready
when
you're
looking
at
problems.
A
A
Also
c
advisor
is
promoting
a
couple
couple
of
a
good
metrics
on
the
infrastructure
side
of
things,
but
it's
important
that
you
know
some
for
some
performance
reason.
You
need
to
also
look
at
the
instrumentation
itself
that
for
some
performance
reason,
more
native
instrumentation
might
might
be
needed
ours,
our
sensor
and-
and
you
know
that
that's
true
for
other
sensors,
probably
likely
also
is
that
we're
you
know
we're
doing
more.
A
That's
roughly
50
of
the
instrumentation
we're
getting
and
out
of
in
the
native
wages,
just
to
be
more
more
performant
all
right.
So
we've
got
the
service
kubernetes
and
infrastructure
and
the
they're
all
needed,
and
I
guess
you
know
to
be
taken
care
of
in
itself
now.
What
do
we
do
with
the
context?
How
do
we
stitch
these
things
together
and
that's
something
that
you
know
we
within
astana
we've?
You
know
basically
built
our
our
tool
about
upon,
but
it's
it's
something
that
you
know
you.
A
A
And
so
there's
a
couple
of
you
know:
kind
of
tagging,
suggestions
and
in
open
telemetry.
There
are
they're,
not
only
suggestions,
but
there's
also
some
mandatory
required
ones
and
some
optional
ones,
but
I
think
that's
a
pretty
pretty
decent,
pretty
good
starting
point.
If
we
are
thinking
about
how
to
correlate
this
apt
together.
A
So
something
that
serves
the
service,
then
you've
got
an
unique
identifier
of
what
what
this
thing
is
that
actually
serves
this
right
again
and
in
sana
we
also
have
the
service
type
but
which
you
know,
I
think,
makes
a
certain
use
cases
easier
and
easier
to
to
get
at.
But
you
know
open.
Telemetry
does
not
know
this
now,
so
we've
got
the
service
right
and
if
we're
using
this
tagging
theme,
then
we
can
start
correlating
things
together.
We
can
see
okay.
A
This
service
belongs
to
this
container
to
this
host
to
this
kubernetes.
You
know
part,
for
example,
and
the
other
way
also
around
right.
The
the
information
that
we've
gathered
from
all
these
different
other
instances
are
common
tagging
schemes
that
we
can
use
to.
Excuse
me
that
we
can
use
to
correlate
one
to
the
other
now.
A
A
different
way
of
looking
this
is
is
if
we're
looking
at
at
the
trace
phase
world
of
things,
and
I'm
mentioning
this
explicitly
because,
as
I
said
earlier,
the
the
services
that
the
service
metrics
that
we
gather
are
based
out
of
traces.
So
we
infer
a
lot
of
these.
We
and
others
right.
That's
not
it's
not
unique
to
insana,
but
those
who
are
working
that
way.
A
Infer
a
lot
of
these
information
out
of
it
and
the
interesting
or
the
way
to
look
at
it
is
if
you've
got
traces
right,
that
you
use
the
trace
id
in
itself
and
to
correlate
things.
Here's
the
first
one
the
example
is
from
grafana
and
they
talk
about
how
to
use
the
trace
id
and
logs
and
use
a
you
know:
common
service
tags
well
throughout
the
system,
something
that
you
know
this
service
name
here,
they're
using
slightly
different
but
throughout
the
system
so
that
they
can.
A
A
A
And
I
mean
we
could
also
do
a
short
demo
if
you
like,
but
this
is
an
example
of
how
we
are
doing
this
and
how
this
is
visualized
in
sana.
So
the
you
know,
this
is
our
example,
but
basically
we
separate
these
three
different
perspectives,
this
application
perspectives,
kubernetes
application
interest
perspectives
and
basically
on
any
entity
that
you
know
you're
looking
at
you,
you
can
link
to
the
others,
but
you
know
conceptually,
it's
not.
A
You
know
you
can
rebuild
this
with
your
own
tools
or
again,
just
just
give
it
a
give
it
a
try
within
startup,
so
key
takeaways.
If,
if
you
like,
we've
got
service
bananas
and
infra,
please
consider
all
of
them.
Please
also
consider
them
all
of
them
independent
and
make
the
best
use
of
when,
when
you're
looking
at
at
these
independently,
because
there's
always
someone
coming
from
that
particular
background,
and
if
you
overload
them
with
information
from
different
perspectives,
they
might
be
overwhelmed
right.
A
They,
these
different
perspectives,
share
them
right,
make
them
shareable
within
the
team
to
ensure
a
common
understanding
of
what
to
measure,
and
why
do
you
measure
them?
Why
is
this
particular
saturation
metric
for
your
workload,
the
most
important
one
last
but
not
least,
write
context
is
king
link
these
together
make
them
aware
for
everyone
and
link
them
together.
So
everyone
has
the
same
understanding
of
of
what
what
you
can
do
all
right.
I
guess
this
is
it
at
least
for
what
I've
prepared
and
I
think
we've
got
time
for
questions.
C
Well,
keep
sharing
just
for
a
minute.
I
would
love
you
to
do,
and
michael's
michael
managed
to
get
internet,
so
that's
it,
but
what
I
would
love
you
to
do
is
if
you
could
go
over
to
the
instanta
site
and
go
to
the
install
the
operator
page
just
so.
People
have
that
link
too,
because
I
think,
and
that
would
get
them.
You
know
at
least
to
know
where
you're,
where
you
live
and
breathe
in
as
well
and
where
all
the
docs
are
as.
A
A
A
We've
included
it
in
in
our
environments
and
how
to
install
the
agent
or
you
can
just
like
you
know,
get
get
the
source
and
and
get
everything
from
you
know
from
github
directly
now
the
operator
on
the
or
the
agent
operator
does
a
lot
of
like
nice
things
for
us
and
it's
it
helps
us
distributing
of
what
we
do
with
our
agent.
So
you
know
if
we're
going
back
to
the
talk
that
I
talked
about
of
of
correlating
all
these
different
things
together.
A
You
know:
that's
something
that
the
operator
the
agent
does,
and
you
know,
as
you
can
think
of
you
know,
if
we're,
if
we're
taking
this
in
the
next
steps.
Further,
we've
not
only
got,
we've
got
infrastructure,
kubernetes
and
services,
but
you've
got
all
you
know
all
mixed
in
with
all
the
cloud
stuff,
with
different
operating
environments
with
different
runtimes.
C
Well,
michael,
wait
did
manage
to
get
some
internet
and
he
just
put
the
link
to
the
catalog,
the
red
hat
catalog
software
operators
for
your
operator
in
in
there.
So
if
you,
I'm
not
sure
we're
seeing
your
slides
right
now,
we're
not
seeing
your
your
browser.
So
if
you
want
to
pop
over
there
and
michael
has
a
few
questions.
C
B
Yeah
sure
and
I'm
so
sorry
that
I'm
late,
I
have
no
control
over
this,
but
I'm
I've
been
working
for
my
cabin
in
the
mountains
for
the
last
seven
months
and
it's
like
it's
a
dsl
phone
line
running
through
the
woods.
So
when
a
moose
gets
crazy,
things
can
go
down,
so
I
apologize
for
being
so
so
late.
But
I
did
link
the
and
hi
mike
matthias.
How
are
you
it's
nice
to
see
you.
A
B
You
know,
like
the
blueberry,
pillsbury
muffin
man,
seal
of
approval,
that
that
the
the
red
hat
components
and
the
instant
components
are
all
supportable
and
they
can
use
it
in
a
production
environment.
So
that's
that's!
That's
where
our
customers
can
go
to
download
something
and
make
sure
that
they're
getting
genuine
intel
inside
parts.
So.
B
A
Yeah
and
again
the
the
the
the
the
the
operator,
so
you
can
think
of
the
operator
and
multiple
dimensions,
the
so
so
far
we
don't
have
like
in
our
tool
dedicated
supports
of
monitoring
operators.
So
it's
it's.
It's
just
used
as
a
custom
resource
definition,
but
obviously,
as
it
gets
more
and
more
used
by
by
developers
it
it
would
be
one
of
the
additional
perspectives.
A
Okay,
we've
got
the
services,
we've
got
kubernetes,
we've
got
infrastructure.
So
looking
looking
a
deeper
or
more
intelligent,
look
at
the
kubernetes,
and
you
know
kubernetes
layer.
The
operator
gives
means
of
even
better
understanding
and
better
linking
these
together
and
putting
some
semantics
into
the
operations
of
let's
put,
let's,
let's
take
the
elastic
search,
for
example,
right
and
that's
totally
in
a
layer
that
I
can
think
of.
A
B
B
C
B
Probably
two
or
three
years
ago
now,
and
so
me
and
my
team
flew
down
there-
we
bought
you,
know
appetizers
and
drinks
for
the
entire
sales
organization
and
stana.
So
we've
actually
had
a
really
really
good,
close
working
relationship
with
your
whole
team,
including
your
marketing
people
as
well
for
a
number
of
years.
So
this
this
this
this
doesn't
just
happen
by
accident
and
and
we're
we're
doing
these
types
of
things
together
to
make
the
overall
customer
experience
as
as
good
as
it
possibly
can
be
in
a
cloud-native
environment.
A
And
we
we
yeah
and
we
continue.
We
continue
to
do
so
right,
so
this
is
this
is
on
the
asian
side,
but
we
also
have
you
know
lots
of
back-end
components.
So
I'm
not
I'm
not
it's
again
for
another
another
conversation
down
the
road.
I
need
to
get
my
colleague
on
online
for
this,
but
we're
going
to
continue
investing
in
there.
B
C
A
A
Exactly
so
so
in
stana
itself,
so
obviously
you
need
to
have
the
agent
running,
but
we
have
an
on-prem
solution
or
a
self-hosted
solution,
as
we
like
and
kubernetes
is
always
has
been,
or
for
a
very
long
time
been
our
primary
way
of
surfacing.
This
and,
with
you
know,
operators
with
our
experiences
on
the
asian
side,
we're
also
looking
into
you
know
what
we
can
do
on
the
back
end
side
to
make
the
on-prem
install
easier
and
faster.
A
Right
so
so
the
traditional,
the
traditional
on-prem
questions
apply
here
right,
so
making
sure
that
it's
secure
that's
in-house,
but
also
performance
reasons
of
of
ensuring
that
it's
it's
it's
nearby,
the
actual
workloads.
So
so,
there's
there's
a
multiple
way
of
reasoning
about
or
or
motivating
this.
We
don't
take
a
stance
right
there.
We
we
just
try
to
make
it
as
easy
as
possible
and
operators
and
are
a
homogeneous
environment
like
kubernetes
or
openshift,
gives
us
the
means
of
of
installing
it.
B
Yup,
hey
we
gotta,
we
got
another
question,
I'm
gonna,
I
don't
know.
If
you
can,
I'm
gonna
read
it
here
and
maybe
you
can
translate
for
me,
matthias,
but
so
jeffrey
says
hey
in
new
relic
as
we're
using
right.
Now
we
have
the
aptx
which
measures,
satisfaction
or
response
time
based
against
a
set
threshold
to
get
the
insight
of
the
application
health
does
it
have
any
corresponding
features
for
instanta.
A
Right
so
aptx
is
a
really
really
important
and
aspect
of
you
know
monitoring
your
applications,
something
that
we
are
more
leaning
towards.
Is
the
sli
slow
way
of
looking
at
this,
so
we've
we've,
just
we've
just
introduced
that
that
you,
that
you
define
service
level
indicators
on
your
customer
journeys,
define
these
and
learn
on
these,
and
also
with
our
application
perspectives.
There's
you
have
much
more
fine,
granular
control
of
of
which
traffic
of
which
aspect
you're
looking
at
and
alert
alert
on
these.
A
B
Okay,
hopefully,
hopefully
jeffrey
that-
that
addresses
your
question.
If
it
doesn't,
I'm
pretty
sure
that
we
can
get
you
just
about
any
questions
you
want.
Where
would
we
send
people
to
if
they
have
follow-up
questions
I
mean
my
email
address
is
wait,
redhat,
dot
com,
it's
just
w-a-I-t-e
redhat.com
and
I
can
connect
people
with
just
about
anyone
at
any
level
of
the
organization
and
astana.
I
am
from
top
to
bottom,
very,
very
close
with
everyone
over
there
matthias
do
you
have
there
you
go.
There's
your
email
address
as
well.
A
That's
my
email
address
in
stana.com,
there's
a
gazillion
ways
to
reach
out
whatever
ping
ping,
anyone
that
and
sana
and
we'll
get
back
to
you
and
and
if
and
jeffrey.
If
you
would
like
to
talk
about
more
about
the
aptx
standards,
I'm
I'm
happy
to
you
know,
go
and
go
into
some
detail
with
you,
and
especially
you
know.
A
B
But
I
was
gonna,
I
was
gonna,
ask
you,
you
know
you
were
you
were
at
red
hat
for
several
years
and
and
then
you
and
then
you
moved
to
instanta.
How
lucky
are
you
I
mean?
I,
I
think
that
you
know
being
able
to
be
a
part
of
that
team
in
this
time
where
everyone
needs
apm,
for
you
know,
helping
them
to
have
the
visibility
and
insight
into
running
their
business
in
the
hybrid
cloud.
Are
you
just
absolutely
thrilled
to
be
there
or
I
know.
A
Well,
first
of
all,
I
was
thrilled
also
to
be
at
red
hat.
Red
hat
was
was
really
a
great
time
and
we
we
built
some
nice,
really
awesome
tools
in
the.
I
was
more
on
the
developer
side
of
things
there
and
in
the
code
ready,
and
we
really
built
an
awesome
tool
for
analyzing
dependencies.
So
shout
out
all
to
all
my
ex
colleagues.
A
That
was
an
awesome
tremendous
time
and
yes,
obviously
and
stana
is,
is
great
because
we
kind
of
like
you
know,
are
challenged
in
a
new
way
of
you
know
being
being
going
against
other
other
players
in
the
market,
but
using
this
new
micro
service
movement
to
to
our
advantage
and
and
build.
I
think
you
know
something
very
unique
that
is
just
very
suited
to
this
new
to
new
environment.
A
Just
you
know,
just
one
example,
I
think
which
is
really,
which
is
also
very
dear
to
my
heart,
is
that
it's
really
really
easy
to
get
started.
Our
agent
discovers
everything
throws
everything
on
the
dashboard
and,
yes,
you
need
to
tweak
and
configure
things,
but
everything
is
it's
just
there
right,
it's
it's
just
there
and
as
we
as
we're
talking
about
you,
know
different
perspectives
of
what
people
are
looking
at.
A
I
think
for
myself,
but
I
I
also
hear
that
from
customers,
it's
just
great
that
that
you
know
you've
got
a
platform
that
you
look
at
and
then
you've
you've
seen
them
the
majority
of
things
already
there
and
then
you
can
kind
of
then
dive
into
details
and
start
tweaking.
But
you
don't.
You
know,
you're,
not
you're
not
lost
at
the
beginning,
and
that's
that's
something
that
I
value
within
insana.
A
lot
about
and
the
whole
distributed
tracing
is
just
it's
just
a
fun
topic.
It's
just
it's
just
a
fun
technology.
B
Cool,
well,
I
don't
see
we
have
any
more
questions
coming
in
and
I
I
know
chris
short
is
going
to.
Let
us
know
that
we're
that
we're
just
about
out
of
time.
So
I
thank
you
so
much
for
coming
on.
I
mean
I
I
reached
out
to
to
to
star
who's
my
marketing
contact
over
there,
and
I
was
like
you
got
to
find
me
someone
like
really
really
good
to
be
a
part
of
this.