►
Description
ushing Docker and OpenShift-based applications into production will radically change the way you monitor and troubleshoot your environment. Sysdig’s Knox Anderson and Apurva Dave will review the challenges of this new infrastructure and get live examples of monitoring and troubleshooting docker for optimal efficiency. During this webinar you’ll learn:
– How should you monitor services built on top of containers?
– What metrics become more relevant in docker-based environments?
– How do you construct alerts most effectively?
– How do you troubleshoot containers that are rapidly coming and going?
The webinar will focus on demonstrating both open source and commercial tools that can help you solve these new challenges. You’ll walk away with ideas that you can immediately put to work in any scale environment.
A
A
Hello
and
welcome
again
to
the
open
ship
Commons
briefings
we're
really
pleased
here
to
serve
a
day
from
cystic,
going
to
give
us
a
talk
on
best
practices
for
monitoring
your
openshift
pause
and
I.
Think
actually,
that's
pause
is
a
dead
word
now.
I
think
we
call
it
a
container
application
platform
or
a
cloud
application
platform,
but
yes,
pause.
B
A
A
We
go,
live,
live,
see,
ICD,
workflow,
live
all
right,
anyways
I'm,
going
to
let
a
pervert
introduce
himself
and
take
it
away,
and
you
can
ask
questions
in
the
chat
one
of
his
colleagues.
Knox
is
on
the
chat
and
we'll
try
and
save
most
of
the
Q&A
for
after
the
presentation.
But
if
you
have
a
pressing
question,
please
raise
your
hand
interactive,
but
take
it
away
good.
B
Morning,
everybody
or
good
afternoon
or
good
evening,
wherever
you
are
thanks
so
much
for
joining
us
today,
my
name
is
apoorva
Davi
and
I'm
really
excited
to
have
you,
along
with
this
ride,
on
best
practices
for
monitoring
your
openshift
container
application
platform.
As
Diane
noted
I
think
talk
is
cheap,
powerpoint
slides
are
cheap,
so
we
want
to
do
as
much
demo
as
we
can
here.
So
we're
going
to
be
demoing
a
real
openshift
environment.
B
We're
gonna
be
showing
you
assisting
alongside
of
it
and
really
what
I
want
you
to
walk
away
with
your,
regardless
of
whether
your
interest
is
insisting
or
not.
What
I'd,
like
you
to
walk
away
with
is
a
few
key
best
practices
that
you
can
take
and
apply
to
any
open
shift
environment
to
help.
You
understand
how
you
really
operated
in
production
and
how
you
get
the
intelligence
and
visibility.
You
need
to
really
understand.
What's
going
on
so
a
couple
things
here.
B
First
of
all,
I
love
to
talk,
but
I
love
to
answer
your
questions
more
than
anything
else,
please,
please
keep
firing.
Those
questions
in
that'll
make
this
much
more
entertaining
we'll.
Try
answer
them
in
line
if
we
can
and
if
not
we'll
we'll
take
them
out
of
band
and
waffle
will
answer
them
offline.
B
But
if
you
are
looking
to
build
a
true
platform
and
if
you
were
looking
to
build
a
true
container
platform,
then
the
process
by
which
all
of
your
platform,
consumers,
monitor
and
troubleshoot
their
environments
will
be
really
different
than
what
you've
looked
at
in
the
past.
Do
you
bring
those
two
changes
together
and
you
know
it's
like
it's
like
a
little
bit
of
a
science
experiment,
you
put
the
two
right
chemicals
into
into
your.
You
know
your
fake
volcano
and
you
watch
it
overflow
right.
B
Alright.
So
before
we
go
deep
into
technical
details,
so
I
have
it
I
have
a
usual
gimmick,
I'm,
not
doing
my
usual
gimmick
today.
My
usual
gimmick
is
that
if
you
can
stump
me
with
the
question,
then
I'm
gonna
send
you
a
cool
t-shirt,
but
today,
I'm
just
so
excited
to
be
here
with
the
open
chef
community
that
I
want
to
send
to
everybody
a
t-shirt.
So
if
you
want
to
drop
me,
your
name
and
email
in
chat
we'll
make
sure
you
get
one
of
these
t-shirts.
B
If
you
give
me
the
mailing
address
great,
if
not
I'll,
just
email,
you
directly
we'll
get
your
mailing
address
and
we'll
send
you
one
of
these
shirts
sweet
so
as
again
find
the
chat
window.
Send
me
your
name
and
email.
This
is
kind
of
my
my
way
of
also
getting
you
to
use
chat
first,
so
that
then
you
don't
feel
so
shy.
Asking
right
on
here
we
go
all
right.
So,
let's
talk
about
the
first
sounds
first
in
the
second
one.
Second,
do
you
remember
the
first
one?
It
was
simply
about
monitoring
containers.
B
Why
is
it
different,
fundamentally
micro-services
and
containers?
You
will
find
break
your
legacy
and
monitoring
and
analytics
tools-
and
this
is
the
origin
of
Cystic
yeah-
we're
the
first
company
that
can
natively
monitor
any
infrastructure,
including
container
based
ones.
I
want
to
go
into
another
level
of
depth
here
about
why
containers
break
these
legacy
tools.
In
order
to
do
that,
you
have
to
understand
a
little
bit
about
sistex
history,
though
the
creator
of
Cystic
was
one
of
the
co-creators
of
Wireshark.
B
For
those
of
you
who
aren't
familiar
with
Wireshark,
it
was,
is
the
premier
network
analysis
and
sniffing
tool?
It
has
about
20
million
users
in
its
open
source,
community
and
Loras
the
Creator,
a
co-creator
of
Wireshark
realized,
as
containers
were
coming
about
that
there
was
an
entirely
new
problem
here
to
solve
in
terms
of
not
only
how
you
understood,
what's
happening
it
from
Network
layer,
but
what's
happening
at
the
application
layer
as
well,
and
so
he
launched
systems
open
source
project
in
2006
2013.
B
You
can
go
to
Cystic
org
to
see
our
our
command-line
Linux
visibility,
troubleshooting
suite.
On
top
of
that,
we
launched
a
commercial
product
that
helps
customers,
visualize,
monitor
and
troubleshoot
a
distributed
environments
and
that's
what
we
sell
and,
not
surprisingly,
part
of
the
reason
we're
here.
We
have
deep
integration
with
openshift
we're
in
use
at
major
enterprises
and
we're
open
shift
product
hooray
for
openshift
all
right.
So
now,
let's
go
deeper.
Why
did
Loras
when
he
created
Cystic,
see
a
challenge
with
containers
and
insight
into
containers?
B
And
here
we
have
to
talk
a
little
bit
about
what
containers
are
and
why
they
work
the
way
they
do.
I
like
to
think
of
containers,
fundamentally
as
a
box
and
a
black
box
could
be
really
good
or
not
so
good
black
boxes
are
really
convenient
for
development.
This
abstraction
layer
or
this
ability
to
wrap
up
individual
processes
inside
this
lightweight
form
of
virtualization
is
really
great
for
portability.
B
It's
easy
to
take
your
environment
that
you're
running
on
your
laptop,
bring
those
to
your
cloud
environment
or
your
container
platform
and
get
the
exact
same
experience
running
your
container
awesome
for
developers
who
are
trying
to
deliver
reliable
code
into
production,
but
that
black
box
comes
at
a
cost.
How
do
you
see
inside
that
that
form
of
virtualization?
The
second
big
challenge
is
that,
as
you
move
containers
into
a
production
environment,
you
have
some
form
of
an
Orchestrator.
B
Typically,
that's
moving
and
scaling
these
containers
without
intervention-
and
this
is
the
key
part
without
intervention,
so
you
don't
have
a
human
who's
sitting
there.
All
the
time
saying
well
looks
like
we're
getting
a
lot
of
my
sequel
queries.
Maybe
I
need
to
triple
the
number
of
containers
that
we
have.
You
don't
typically
have
that
kind
of
experience,
you're
looking
to
automate
it.
B
The
next
step
here,
which
I
kind
of
alluded
to
is
you,
then
have
services
that
are
built
on
many
distributed
containers.
So,
if
you're
trying
to
understand
again
how
your
my
sequel
service
is
doing,
that's
doing
a
lot
more
than
simply
understanding
what
one
containers
doing
now,
you
have
to
understand
what
all
three
or
what
all
five
of
your
containers
are
doing,
which,
by
the
way
may
be
on
separate
nodes
or
may
even
be
in
separate
physical
data
set,
and
you
may
not
even
know
where
they
actually
are.
B
If
your
say
the
developer,
who's
just
consuming
a
container
platform,
you
simply
wouldn't
know.
Do
these
challenges
make
it
very,
very
difficult
for
your
average
monitoring
tool
like
last
generation
monitoring
tool
to
kind
of
instantly,
give
you
the
information
you
need.
So,
while
the
black
box
is
great
for
developers
who
are
trying
to
bring
you
code
online,
when
you
think
about
the
operations
aspects
that
those
developers
need
to
deal
with
or
the
operations
aspects
that
your
DevOps
team
needs
to
do
with
deal
with,
you
need
actual
visibility.
B
You
need
to
see
what's
running
inside
the
container,
you
need
to
be
able
to
aggregate
across
containers
in
order
to
see
what
information
is
there
and
you
need
to
be
able
to
react
to
not
only
what
the
containers
are
doing.
But
what's
your
answer.
So,
let's
talk
about
how
we
address
this
challenge.
There
are
a
couple
ways
to
address
it.
B
One
way
which
which
I'll
talk
about
a
little
bit
later
is
what
I
call
sidecar
containers
and
that's
the
idea
of
taking
every
single
pod
that
you
deploy
an
open
ship
and
putting
a
sidecar
container
in
that
pod
to
share
resources,
share
faith
and
kind
of
do
some
internal
networking
to
try
and
collect
information.
It's
pretty
complex
and
again.
This
is
where
one
of
lorises
insights
were
were
when
he
found
insisted
which
was
there's
a
cleaner
way
to
do
this,
and
it's
by
providing
a
new
form
of
system
instrumentation
that
we
call
container
vision.
B
When
you
deploy
a
Cystic
container
on
a
host,
we
can
automatically
tap
into
the
system
calls
of
that
host
and
we
can
see
every
single
system
call,
but
every
container
executes.
That
means
we
can
understand
what
the
application
is,
what
it's
doing
and
we
can
understand
the
underlying
host
resources,
as
well
as
network
resource.
So
from
the
single
point
of
instrumentation,
you
can
see
app
container
host
and
network.
B
That's
pretty
powerful,
so
I'm
gonna
go
down
one
more
one
more
layer
here.
This
is
our.
You
know:
hypothetical
host
and
operations
with
the
Linux
kernel
down
at
the
bottom,
who
you
can
tell
this
is
hypothetical,
because
it
seems
pretty
unlikely
that
you're
going
to
take
a
host
and
you're
gonna
run
a
couple
non
containerized
apps,
a
docker
container
rocket
container
and
LXE
katare,
but
humor
me
humor
me
for
a
second
yeah.
Okay.
B
So
now
we
see
that
obviously
all
of
these
containers
would
be
interacting
with
the
kernel
in
order
to
execute
commands,
whether
the
are
accessing
underlying
resources
or
guaranteeing
their
own
resources,
and
it's
there,
where
Cystic
inserts
a
thin
layer
of
instrumentation.
So
we
can
see
these
system
calls
and
from
these
system
calls
we
can
then
derive
a
significant
amount
of
information.
We
can
derive
host
Network
and
container
metrics,
but
we
can
also
see
custom
metrics.
That
means
custom.
B
Based
on
all
of
these
system
calls.
We
can
also
automatically
determine
what's
running
inside
the
container,
so
just
looking
at
the
system
calls
without
any
human
intervention,
we
can
say:
oh
we'll
look.
This
is
the
custom
node
application.
This
is
the
API
server.
This
is
the
my
sequel
database
and
so
on
and
so
forth.
B
Instead,
what
I
need
to
know
is
how
well
are
my
endpoints
performing
on
my
API
server?
How
slow
or
fast
are
the
queries
to
my
database
server
and
what's
going
on
with
garbage
collection
in
my
Cassandra
database,
these
are
the
types
of
metrics
that
really
help
you
monitor
and
troubleshoot
your
environment.
B
So
here's
a
quick
glance
at
all
of
these
Auto
discovery
mechanisms
or
Auto
discovery,
application
components
we
have
in
place.
This
is
all
customizable.
So
if
you
have
a
different
app,
if
you
create
a
custom
application,
you
can
customize
Cystic
in
order
to
collect
that
information
all
right.
So,
let's
keep
going
here
so
now,
we've
we've
we've
instrumented
the
kernel.
We're
seeing
these
system
calls.
We
turn
them
into
metrics.
What
do
we
do
with
them?
That's
where
the
Cystic
container
in
user
space
actually
comes
into
play
here.
B
B
Let's
step
it
up
there,
we
go
okay,
all
right
so,
while
I'm
a
while
I'm
doing
this
demo
right
after
this
demo,
I'm
gonna
stop
for
questions.
So
if
you
do
have
burning
questions,
let's,
let's
use
this
as
an
opportunity
for
you
to
get
them
into
chat
right
now.
Okay,
so
here's
my
blank
environment.
This
is
a
very
sad
environment.
There
is
no
data
here
to
to
visualize.
So
let's
fix
this.
B
We
come
over
here
come
over
to
agent
installation,
and
you
see
here,
we've
got
some
pretty
standard,
installs
docker,
linux,
kubernetes,
kubernetes
and
OpenShift
work
very
similarly,
here's
our
OpenShift,
install
and
kind
of
just
link
you
here
we're
going
to
do
it
for
this
first
one
we're
going
to
do
a
raw
install
okay,
so
all
I
need
to
do
is
copy.
This
docker
run
command.
Come
back
to
my
terminal.
B
B
Great
and
now
what's
happening
here
is
docker
is
running,
and
this
D
flag
is
basically
saying
run
it
in
the
background
the
Cystic
agent.
Now
there
is
one
of
the
key
trade-offs
you
need
to
make
in
order
to
get
this
great
visibility
that
I
described,
which
is
we
run
in
privileged
mode
that
gives
us
access
to
install
our
kernel,
module
and
see
all
of
the
data
we
need
to
see
as
I'll
show
you
a
little
bit
later.
B
We
can
isolate
this,
this
assisted
container
through
OpenShift,
to
restrict
and
limit
the
exposure
that
to
your
overall
team
in
container
platform,
all
right.
So
now,
let's
head
back
over
here
and
we'll
head
over
to
Explorer-
and
wouldn't
you
know
it
here-
we
go.
There's
my
IP
address
and
I'm
starting
to
see
CPU
memory
network
data
from
this
host.
That's
nice!
B
Honestly,
though,
that's
pretty
standard
right!
This
is
kind
of
what
you
see
in
any
monitoring
environment.
Now,
our
Explorer
tab
is
kind
of
like
each
top
for
your
distributed
environment
if
you're
familiar
with
HIV
a
really
powerful
tool.
Well,
we
can
drill
down
here
and
not
only
see
a
post,
but
we
can
see
the
individual
containers.
So
I've
been
talking
a
lot
about
my
sequel
this
morning.
Why
don't?
We
just
continue
that?
Let
me
click
on
my
sequel
here
and
you
will
see
that,
let's
start
with
an
overview
by.
B
Let's
start
by
an
overview
by
process
here,
and
you
can
see
we
can
drill
down
in
this
individual
container
and
see
memory
CPU
so
on.
But
you
know
what's
more
interesting
here
is
this
is
equal
right.
So
let's
click
on
this,
my
sequel
view-
and
let
me
expand
this
for
you
now
we're
looking
at
very
much
my
sequel,
specific
information,
so
you'll
see
here,
you're
gonna,
see
top
queries
by
number
of
requests,
top
tables
by
number
of
requests,
the
lowest
queries,
the
lowest
tables
and
even
request
types
select
and
set,
and
so
on.
B
So
what
you're
seeing
here
is,
of
course,
with
one
single
instrumentation
command.
I'm,
now
able
to
tell
you
what
are
the
slow
queries
running
within
my
sequel?
This
is
a
really
powerful
approach
that
our
instrumentation
enables
so
we're
able
to
see
your
container
look
inside
your
container
understand
what's
running,
grab
the
relevant
data,
combine
that
with
underlying
host
and
network
data
as
well.
B
Alright.
So
that
is
the
end
of
demo
number
one
I
assume.
If
you
were
in
the
room
with
me
right
now,
you
would
be
applauding
either
that
or
you
would
be
so
stunned.
Your
your
job
would
be
open
and
you
didn't
know
it's
because
I'm
willing
to
bet
you
go
to
very
few
demonstrations
where
people
actually
show
you
the
grungy
process
of
instrumenting
instrumenting,
a
host
and
instrument
in
containers
Dyanne.
Let's
take
this
moment
to
stop
and
see.
If
we
have
any
questions,
there's.
A
B
Roadmap
question
already:
I
love
it
that's
fantastic!
Yes,
in
fact,
I
can
confidently
say
that
our
design
and
engineering
team
are
working
on
the
ability
to
alert
on
events.
As
we
speak,
I'm
sure
my
product
manager
would
kill
me
if
I
gave
you
a
date,
so
I
will
avoid
that
and
I
will
instead
say
it's
coming
very
soon.
All.
A
B
Good
question,
so
we
use,
we
use
a
function
called
DKMS
which
allows
dynamic
compilation,
so
in
general,
you
do
not
have
to
reinstall
will
take
care
of
any
updates
that
we
need
to
I
say
in
general,
because
if
there
is
a
huge
breaking
change
there
may
be
some
modification
we
we
need
or
some
manual
intervention.
That
is
very,
very
rare.
All.
B
Question
you
do
need
credentials
to
get
my
sequel,
specific
specs
if
you've
set
up
your
my
sequel
database.
That
way
and
a
relatively
new
feature,
we've
added
is
basically
a
set
of
environmental
variables
that
people
can
include
as
they
deploy
their
software
that
allow
us
to
access
the
credentialed
container
appropriately.
So
that's
really
perfect
for
platform-as-a-service
or
container
application
platforms
where
the
the
operator
may
not
have
access
to
the
you
know
the
container
itself
or
the
credentials
themselves
and
needs
the
developer
or
owner
to
provide
them.
A
B
Super
question
and
in
fact
it's
a
perfect
lead-in
for
my
instrumentation
best
practices
here.
So
let's
talk
through
this
and
that
point
is
actually
my
second.
The
question
raised,
I
should
say
is
my
second
point,
which
is
the
best
practice
that
you
should
have
in
mind.
Is
a
single
container
agent
per
host,
not
per
pod?
B
That
means,
if
one
of
those
container
dies
they
all
die.
So
you
with
this
per
pod
model,
you
have
higher
resource
usage,
because
every
pod
needs
a
sidecar
container.
You
have
higher
complexity
because
you've
got
increased
networking
through
within
the
pod.
You
have
an
increased
chance
of
breakage
if
one
dies
they
all
die
and
you
have
an
increased
attack
surface.
There
are
more
containers
that
someone
can
try
and
hack
into.
B
So
when
you
do
that,
when
you
flip
that
around
and
say
look
I
only
want
a
single
agent
per
host,
you
reduce
all
of
these
issues,
absolutely
critical,
and
we
believe
this
is
a
fundamental
best
practice
for
for
instrument
to
instrument
in
your
environment.
The
second
key
is
that
platform
operators
should
instrument
as
much
as
possible.
There
shouldn't
be
manual
efforts
on
the
part
of
your
consumer
of
your
container
app
platform,
consumer
or
your
developer.
To
have
to
do
this
instrumentation
themselves
and
what
we
mean
by
that
is.
B
When
containers
are
dropped
into
an
environment,
you
should
be
able
to
automatically
see
the
hosts
and
network
metrics.
You
should
automatically
be
able
to
tag
with
relevant
openshift
in
kubernetes
metadata,
and
you
should
have
this
idea
of
non-intrusive
collection
of
application.
Metrics
and
I'm
gonna
push
this
a
little
bit
further
in
our
next
demo.
B
When
I
actually
show
you
an
open
shift
environment,
but
you
know
the
key
is
if,
if,
in
that
last
demo,
I
was
the
developer
and
I
was
just
coming
in,
and
spinning
up
that
those
WordPress
and
my
sequel
containers
I
should
be
confident
that
the
underlying
platform
is
automatically
instrument
and
here's
another
thing.
I
didn't
show
this
to
you
in
the
last
environment,
but
I
believe
I
can
show
to
you
in
the
next.
One,
which
is
developers
should
be
able
to
easily
add
custom
instrumentation
with
regard
to
container
placement.
B
So
again,
if
you've
got
complex,
/
/
pod
models,
if
you've
got
complex
requirements
around
how
things
need
to
be
set
up,
then
developers
have
to
do
things
just
so
to
ensure
that
their
custom,
stats,
D
or
JMX
metrics
will
exit
their
container
and
be
consumed
by
a
correct
endpoint.
We
think
developers
shouldn't
have
to
think
about
that
at
all.
All
they
should
have
to
do
is
omit
the
metric,
and
the
underlying
system
should
capture
those,
and
not
only
should
they
capture
them.
B
They
should
Auto
tag
those
based
on
container
host
application
micro
service
for
later
analysis.
So
that
is.
That's
me
on
my
soapbox
for
a
moment,
but
you
came
for
best
practices,
so
here
you
go,
you're
gonna
get
them,
and
this
is
the
way
we
think
about
instrumenting
systems
all
right.
So
let's
keep
going
here.
Let's
talk
about
visualization
and
troubleshooting
here
so
go.
A
Ahead,
you
getting
one
more
question
on
the
prior
before
we
head
in
down.
He
is
asking
if
we
have
a
scenario
where
we
deploy
a
sequel
container
with
an
environment
password
and
users
may
reset
the
sequel
password.
We
noticed
users
tend
to
do
this,
as
we
have
many
situations
where
the
OpenShift
health
probes
failed
due
to
password
changes.
What
measures
approach
do
we
take
here?
A
different
environment
would
dedicate
a
user
for
cystic.
What
would
you
suggest
yeah.
B
That's
a
very
good
question,
and
so
I
I
believe
that
this
is
where
our
environmental
variables
for
credentials
come
into
play.
So
as
long
as
the
user
keeps
those
credentials
updated,
you
won't
have
that
problem
now.
If
they
don't
keep
that
updated,
then
you
will
have
that
issue,
but
it's
relatively
easy
to
keep
those
up
to
date.
So
that
is
our
that's
our
best.
B
That's
our
best
step,
1
step
2
is
you
can
start
alerting
on
conditions
which
are
associated
with
those
metrics
going
away,
for
example,
if
my
sequel
connection
counts,
there
could
be
two
reasons
like
one
you're.
My
sequel
environment
is
failing.
Two
we're
not
able
to
see
those
connections
because
somebody
changed
something
in
the
underlying
system,
so
you
could
set
up
that
alert
and
have
that
fired
back
to
the
owner
of
the
container.
Who
can
then
say?
Oh
what's
going
on
here.
This
looks
bad.
Let
me
check
it.
Oh,
it
looks
like
my
you
know.
A
B
The
CPU
is
tunable,
so
you
could
go
into
the
agent
and
set
a
lower
harder
cap
and
what
happens
is
if
we're
consuming
up
to
our
limit
in
underlying
resources,
we
will
start
sub
sampling
data
so
that
we
don't
overstep
our
bounds,
because
we
realize
that
it's
more
important
to
give
those
resources
to
your
application
versus
our
agent.
Okay,.
A
And
there
is
one
more
it's
just
going
to
keep
coming,
how
did
developers
control
what
information
is
emitted
to
the
system
system?
This
concern
is
that
Cystic
should
not
be
capturing
the
sensitive
customer
data
like
credit
cards
or
security
numbers,
etc,
can
developer
scrub
data
that
is
being
emitted.
B
B
Let
me
see
here
if
I
have
another
answer
to
controlling
that
data,
we
do
have
some
ways
within
our
application
to
turn
off
particular
forms
of
data
collection,
so
that
for
customers
who
are
very,
very
sensitive,
we
can
avoid
collecting
particular
forms
of
data.
I,
probably
don't
have
time
to
go
into
more
detail
there,
but
if
that's
a
you
know
real
concern,
I'd
say
step,
one
is
making
sure
cystic
works
for
your
environment
and
then
step
two
would
be
kind
of
tuning
data
collection.
B
I
have
actually
a
third
answer
which
we
will
address
in
the
demo,
which
is
cystic,
can
allow
you
to
isolate
sets
of
data
for
particular
users.
So
you
can
imagine
that
the
users
who
work
or
the
developers
who
work
on
say
your
billing
system
will
probably
actually
need
to
access
a
lot
more
data
than
people
who
work
on
your
API
server.
So
can
you
isolate
those
two
teams
and
give
them
access
to
only
the
right
data?
B
So
how
do
you
give
developers
the
right
level
of
access
and,
more
importantly,
how
do
you
give
developers
the
ability
to
collect
deep,
troubleshooting
data
when
you
don't
want
to
give
them
access
to
the
underlying
platform
and
resource
allocation
is
elastic
and
dynamic?
The
developer
does
not
actually
know
where
their
container
will
be
running
yet
they're
responsible
for
understanding
why
their
application
is
not
performing
the
way
it
is.
B
This
is
a
really
difficult
challenge
and
we've
needed
to
layer
on
multiple
ways
of
thinking
about
data
in
order
to
solve
this
problem,
and
it,
of
course,
all
comes
back
to
that
instrumentation
I
was
describing
before
with
previous
instrumentation.
Typically,
you
would
see
CPU
memory
disk
few
other
metrics,
and
it
was
good
enough
to
relate
to
the
performance
of
your
application.
After
all,
in
kind
of
the
static
monolithic
age,
you
had
an
app,
it
was
running
on
a
host,
and
you
know
those
those
the
host
in
the
app
were
intricately
entwined.
B
Number
two:
is
this
idea
of
service
based
access
for
teams?
So,
if
I'm,
the
development
team
concerned
with
the
API
service,
I,
probably
don't
care
quite
as
much
about
these
other
services
and
I.
Don't
need
to
be
burdened
with
having
to
look
through
that
data
unless
I'm
troubleshooting
a
complex
system,
wide
problem
and
then
finally
getting
down
to
troubleshooting.
How
do
you
go
deeply
within
this
container
application
platform
to
allow
a
developer
to
see
actually
what's
happening
under
the
surface,
without
just
giving
them
the
keys
to
the
platform
and
letting
them
run
amok?
B
So
let's
go
deeper
here,
we'll
walk
through
each
of
these.
Alright,
so
you've
got
this
environment.
Here's
our
container
application
platform.
So
can
the
dev
team
on
you
know
who's
covering
service
to
the
Green
Service,
actually
understand
how
the
service
is
performing.
So
can
you
answer
the
question
of
you
know
what
what
percent
of
my
CPU
shares?
Am
I
using
across
service
to
it's
actually
a
pretty
hard
question
right
and
imagine
this
not
not
being
on
eight
containers
but
8,000
containers
or
800
containers?
B
That's
pretty
challenging,
and
so
one
of
the
things
we
allow
you
to
do
on
the
fly
within
the
application
is
dynamically
aggregate
information
across
containers
using
the
metadata
of
your
service.
So
you
can
group
those
together
on
the
fly
and
say,
okay,
how
service
to
performing?
What's
the
response
time
of
my
my
sequel
service,
that's
currently
distributed
over
three
data
centers
or
my
Cassandra
service
or
my
Apache
service.
What
are
the
slowest
queries
or
the
slowest
endpoints?
What
are
the
key
metrics
here
and
how
can
I
view
them
in
aggregate
the
way
we
do.
B
This
is
through
a
deep,
real
understand,
real
time,
understanding
of
orchestration
metadata
and
as
I'll
show
you
in
a
moment
as
that
data
flows
in
we
tap
into
your
Orchestrator,
your
open
shift
environment,
we
capture
all
the
relevant
tags
for
your
containers
and
hosts
and
dynamically
aggregate.
Your
metrics
on
that
metadata,
enabling
you
to
answer
these
questions.
B
We
talked
a
bunch
about
this,
but
in
order
to
do
that
effectively
you
have
to
auto
discover
applications
at
the
same
time.
I'm
not
gonna
spend
a
whole
lot
of
time
in
there.
Instead
I'd
like
to
talk
about
this
idea
of
service
based
access
control,
this
dig
will
also
allow
you
to
not
only
aggregate
information
based
on
that
metadata.
It
will
allow
you
to
isolate
information
on
that
metadata,
so
you
can
isolate
your
pradhan
vironment.
B
You
can
isolate
the
the
sensitive
billing
application
to
a
particular
team,
or
even
a
particular
person,
or
only
provide
access
to
it
temporarily.
When
you
know
some
troubleshooting
needs
to
be
done.
This
is
a
really
new
functionality
of
assisting
and
it's
highly
differentiated
I
think
that
in
the
old
world,
people
were
comfortable
with
role
based
access
control,
hey
I'm,
the
director
of
the
team.
B
Therefore
I
have
a
higher
level
of
access
service
based
access
control,
however,
is
relatively
new
and
is
kind
of
a
characteristic
of
dynamic
environments
like
open
shift,
I'm
really
excited
to
demo
this
one
to
you
and
finally
trace
driven
troubleshooting,
doe
I.
Think
plenty
of
monitoring
tools
can
give
you
a
graph
that
go.
You
know
kind
of
up
into
the
right
or
down
into
the
right
when
something's
going
bad
plenty
of
tools
will
also
give
you
dashboards
it's
nice
to
have
full
stack
dashboards.
B
There
are
a
couple
interesting
things
that
Cystic
can
do
on
top
of
that
which
make
it
possible
to
troubleshoot
faster
more
effectively,
even
in
environments
where
you
don't
have
complete
access.
First
of
all,
we
can
correlate
events
to
your
systems.
This
means
that,
in
addition
to
collecting
metrics,
we
can
capture
events
from
kubernetes,
docker
and
custom
event
that
you'd
like
to
send
to
our
API
for
you
to
overlay
them
with
your
metric
and
understand.
B
You
know
what
events
may
have
impacted
the
performance
of
your
service
and
then
finally,
we
enable
something
very
interesting
with
with
alerting
which
is
called
capturing
a
trace
file,
so
a
trace
file
essentially
gives
you
an
entire
system
capture
of
every
single
system.
Call
that
was
happening
when
an
alert
fired.
That
means
you
can
troubleshoot
these
containers
remotely
and
you
can
even
troubleshoot
them
after
those
containers
are
long
gone
because
your
Orchestrator
may
kill
off
a
poorly
performing
container,
but
you
still
need
to
troubleshoot
it.
How
do
you
do
that?
B
Here's
an
example
replay
the
state
of
my
system
last
night
when
the
off
service
alerts
fired
five
minutes
before
I.
We
saw
the
whole
app
go
down
and
show
me
all.
The
system
calls
from
all
the
containers
that
had
been
destroyed.
Imagine
doing
that
with
one
of
your
legacy.
Monitoring
tools.
It
just
wouldn't
happen.
B
Let's
up
here.
This
all
looks
good,
make
sure
everything's
running
properly,
okay,
I
think
we're
in
good
shape.
Here,
close
your
eyes.
For
a
moment,
everybody
I
need
to
switch
dashboards.
Ok,
as
always,
keep
those
questions
firing
in
for
those
of
you
who
joined
late.
Remember
drop
your
name
and
email
in
chat,
I'm,
sending
a
free
t-shirt
to
everyone,
because
I'm
excited
about
showing
off
this
new
demo
environment.
So
here
we
are
an
open
shift.
This
environment
is
real.
It's
our
r-mo
environment
here.
B
So
a
couple
things
I
want
to
note
here:
you'll
notice,
your
projects
here,
we've
got
a
Java
app
and
a
WordPress
app
we're
going
to
be
digging
into
beat
each
of
those
in
some
detail
in
the
middle.
Here
you
have
an
interesting
project
which
is
the
Cystic
project,
and
it's
these
are
all
the
monitoring
agents
for
the
platform
as
a
service
or
for
the
container
application
platform,
and
things
to
note
here
the
way
this
is
set
up.
Is
you
set
this
up
as
a
separate
project?
B
You
can
then
use
open
strips
the
open
ships,
administrative
controls
to
decide
who
gets
access
to
the
underlying
instrumentation.
This
is
super
clean,
super
easy.
It
means
that
none
of
your
developers
need
to
worry
about
instrumentation.
Your
ops
team
can
take
care
of
it.
It's
also
deployed
using
a
kubernetes
daemon
set.
So
as
you
expand
and
grow
your
environment,
it's
easy
to
pin
a
cystic
agent
to
every
single
physical
host.
B
We
can
drop
into
each
of
these
environments
and
for
those
of
you
who
are
familiar
with
with
OpenShift
you'll
see
here,
you
know,
we've
got
a
bunch
of
containers
running
so
Cassandra
Redis
Java.
This
is
like
a
you
know.
This
is
like
a
this
is
like
database
heaven.
Basically,
we
also
have
a
client
running
here,
which
is
you
know,
which
is
kind
of
giving
us
a
synthetic
load
across
this
application.
So
that's
cool.
Of
course
you
know
you
can
deploy
some
health
checks
and
health
checks.
B
Give
you
really
basic
information
about,
what's
going
on
here,
all
right
time
to
hop
over
into
sis
dig-
and
you
do
this
here
out-
ok
time
to
hop
into
Cystic
here
and
start
examining
this
data,
so,
first
of
all,
we're
dropped
into
what's
called
a
physical
topology
map.
This
is
a
dynamically
created
map
so
because
we
understand
all
the
network
connections,
in
addition
to
your
hosts
performance,
we
can
automatically
determine
who's
talking
to
who
and
you'll
see
here
that
we've
got
our
various
hosts
that
are
that
are
all
talking
to
each
other
in
various
forms.
B
Now
we
have
a
functionality
that
we
call
Google
Maps
for
your
infrastructure,
which
is
you
can
actually
zoom
in
here
and
see
what's
running
on
this
individual
house.
So
this
is
pretty
cool.
I
can
get
down
to
the
individual
container
and
I
can
drill
down,
frankly,
even
all
the
way
into
the
process.
Now
that's
great,
but
this
is
a
mess
like.
Could
you
imagine
troubleshooting
this
like
troubleshooting,
these
network
connections?
Wow,
that's
crazy
and
there's
no
real
relationship
here
to
your
application
itself.
B
B
Aha,
now
things
start
to
get
much
more
interesting,
so
here
you
can
essentially
see
you
can
see
the
Java
app
deployment,
which
is
an
abstract
concept
from
kubernetes,
and
you
can
see
the
actual
replica
sets
that
make
up
that
job
application,
and
you
can
see
that
they're
all
talking
to
cassandra
and
Redis
and
so
very
quickly
and
very
easily.
We
were
able
to
reorganize
this
data,
and
now
I
can
troubleshoot
across
a
service.
B
Now
I
can
troubleshoot
across
a
replica
set
now
I
can
understand
this
at
the
logical
layer
of
my
application
and
not
the
physical
layer
of
my
underlying
infrastructure,
all
right,
I'm
gonna
get
into
a
moment
in
a
moment.
I'm
gonna
get
deeper
into
how
we
created
this
view
and
how
we're
able
to
take
this
service-oriented
view
before
we
do
that,
let's
take
on
over
an
overview
of
our
Java
Java
project
here,
and
this
gives
you
an
example
of
a
dashboard
that
would
aggregate
information
across
across
an
entire
service.
B
B
You
can
see
some
of
the
recently
data
were
collecting
here.
Things
like
CPU
shares,
top
namespaces,
most
important
resources
consumed
across
our
service,
and
you
know
kind
of
kind
of
this
related
information
file
system
memory,
so
you're,
seeing
everything
from
the
high
level
of
how
is
the
application
performing?
What
type
of
requests
are
we
getting
down
to
underlying
resource
utilization?
B
These
are
our
dashboard
environments.
You
can,
of
course,
create
a
you
know.
Kind
of
you
know
any
kind
of
in
dashboards
that
you
want
entirely
custom.
You
can
use
our
our
Wizards
to
create
simpler
environments
as
you
please.
Now,
let's
go
into
the
Explorer
view
and
as
I
was
describing
before
the
Explorer
view
is
kind
of
like
H
top
for
your
entire
environment.
Now
up
here,
we
see
the
metadata
we're
using
to
help
understand
our
environment,
so
here
we're
grouping
things
by
host
and
then
container
ID.
B
So
you
can
see
here
a
host
and
I
can
drill
down
on
container
ID
I.
Can
click
on
any
row
of
this
table
and
I
get
that
dynamic
aggregation
of
information
across
whatever
group
I've
selected
so
now
I'm
getting
an
overview
by
process
for
this
IP
address.
Very
very
cool
super
helpful
great.
If
you
can
drill
down
here
but
again
what
if
instead
I'd
like
to
see
this
in
something
that's
more
relevant
to
to
my
particular
application.
So
instead,
let's
do.
B
And
what's
happening
right
now
is
we're
dynamically
rear,
dynamically
aggregating.
This
information
and
you'll
notice
this
these
namespaces
are
akin
to
these.
Namespaces
are
akin
to
the
projects
we
had
running
in
our
openshift
environment.
So
this
is
cool
so
now,
I
can
understand
this
exactly
in
the
same
way
that
openshift
is
describing
my
life
application
in,
and
you
can
see
here.
We
have
three
replicas.
We
have
three
replicas
sets
for
a
dis
job
application.
So
I
can
click
on
this
and
now
I'm
getting
the
aggregate
of
information
for
this
job
application.
B
I'm
gonna
show
you
a
couple
more
things
here
and
then
we're
gonna
stop
for
questions
before
we
go
into
the
final
component,
which
is
alerting,
but
what
I
want
to
show
you
here
is,
first
of
all
we're
getting
an
overview
by
process.
That's
interesting,
but
this
is
Java.
So
let's
take
a
look
at
JVM
metrics,
so
you
can
see
here
four
four,
four
JVM
we're
collecting
a
heap
usage,
garbage
collection
and
thread
count
we're
actually
this
environments
pretty
rudimentary.
B
So
we're
not
really
doing
any
meaningful
garbage
collection
here,
but
you
can
see
interesting
stuff,
like
the
thread
count.
Dropping
off
we're
you
kind
of
setting
up
a
little
birds
as
we
go
and
I'll
talk
about
alerts
in
a
moment.
Let's
do
one
other
thing
here,
let's
hop
over
to
a
metrics
view,
though,
since
we're
looking
at
the
Java
app,
we
may
find
some
JMX
metrics
here.
So
let's
take
a
look
here.
These
are
all
Kassandra
based.
So
let's
do
this
hop
over
to
Cassandra.
B
Metrics
and
now
we
can
see
every
single
JMX
metric
that
is
executed
by
the
system.
The
important
part
here
is
that
the
developer
didn't
have
to
tell
or
point
to
our
agent
as
an
end
point
for
this
metrics
and
they
didn't
have
to
include
a
local
poller
in
their
pod.
We
automatically
see
these
metrics
running
through
the
system
calls
and
we
can
capture
them.
This
makes
instrumenting
java
based
environments,
insanely
easy.
B
B
This
is
a
stats
D
metric
that
we're
we're
showing
in
the
same
way.
The
key
here
is
that
assisting
becomes
kind
of
this
one
place
where
you
can
aggregate
all
of
your
system,
metrics
all
of
your
custom,
metrics
all
in
one
place,
and
everyone
can
access
the
right
data
at
the
right
time,
all
right.
That
was
a
whole
lot
of
information.
I'm
assuming
there
are
some
questions,
they're,
always
questions.
A
B
Injection
correct,
okay,
I
got
the
question,
I
understand
it,
so
no
we
do
not
provide
line
by
line
transaction
tracing.
That
is
the
realm
of
the
new
relics
and
app
dynamics
of
the
world
and
fundamentally
we're
we're
pretty
different
product.
Now,
as
the
question
probably
came
up
because
many
of
the
metrics
we
provide
start
to
bleed
into
that
territory,
but
we
do
something
different
here.
B
So
what
we
find
is
that
in
many
cases
we
provide
enough
APM
that
customers
are
happy
using
us
and
because
of
how
we're
designed
and
designed
to
scale
across
your
environment,
you
could
deploy
this
everywhere
in
dev
and
prod,
which
is
something
you
probably
would
never
do
with
an
APM
product.
Next
question:
please
all.
B
We
do
have
a
best
practice,
documentation
that
we've
deployed
on
we
put
up
on
our
support
site
and,
in
fact,
by
hot
back
here
for
a
moment
this
is
a
slide
I
skipped
over
the
URLs
down.
Here,
it's
probably
not
super
readable,
but
if
you
search
for
cystic
install
openshift
on
google,
you'll
find
it
and
basically
it's
a
four-step
process.
You
have
to
modify
the
security
context
constraints
install
as
a
kubernetes
Damon
said
and
while
step
four
is
your
dime.
So
it's
pretty
easy.
It's
pretty
straightforward!
All.
A
Right,
the
other
one
just
popped
in
and
there
are
a
bunch-
and
we
are
gonna
I'm,
just
gonna,
say
right
now,
if
you're
able
to
run
over
time,
I'm
fine
with
hanging
out
if
we
run
over
time
and
sometimes
okay
in
kubernetes
api
diverges
when
replica
sets
were
added
to
kubernetes
system
temporarily
started
ignoring
OpenShift
replication
controllers.
How
are
you
managing
this
going
forward?
A
B
Trying
to
be
better
better,
more
faster,
all
the
time
is
our
goal:
yeah
we're
a
company.
We
have
a
big
challenge,
which
is
we
do
want
to
maintain
a
functional
parity
between
OpenShift
and
kubernetes.
I
will
also
say
that
OpenShift
has
become
more
and
more
important
to
us
as
a
company
as
we've
grown.
We
have
a
great
customers
who
are
using
open
chef,
and
that
gives
us
higher
priority
to
continue
to
invest
in
openshift,
so
I
apologize
for
the
temporary
divergence
and
we're
gonna
do
our
best
to
make
sure
that
doesn't
happen.
All.
A
B
B
A
There
was
one,
does
Cystic,
find
the
bottlenecks
and
the
app
pinpointed
down
to
the
line
of
code
and
I
think
that's
the
same
as
the
trees,
actual
freaking
people
and
the
other
one
that
I
think
someone
answered
for
him.
What
was
the
kubernetes
tool
that
allows
you
to
make
sure
it
deployed
on
all
the
compute
nodes
and
somebody
and
so
Damon
said
that's.
B
Great
cool
yeah,
let's
move
along
we're
close
to
the
end
here,
I
think
we'll
be
roughly
on
time
and
then
I
can
stay
late
for
Q&A.
I
love
answering
questions,
but
we
talked
about
this
idea
of
data
security
and
kind
of
isolating
data
so
that
the
right
teams
get
to
look
at
the
right
information.
There
are
actually
two
benefits
to
that.
One
sure
there's
a
security
benefit,
which
is,
if
you've
got
a
sensitive
app.
You
don't
want
everybody
to
have
access
to
it.
B
You
may
not
want
everybody
to
have
access
to
your
prod
environment,
but
there's
also
a
troubleshooting
benefit.
If
you
get
dropped
into
a
huge,
complex
monitoring
tool
and
there's
a
lot
of
data
and
you're
trying
to
firefight
and
solve
a
problem,
it's
man,
it's
messy
right,
you'll,
understand!
What's
going
on,
you
don't
really
understand
what
the
makeup
of
somebody
else's
app
is
and
how
you
see
it.
You
really
want
to
be
able
to
focus
down
on
your
data
and
the
relevant
data,
and
that's
where
we
built
a
functionality
that
we
call
teams.
B
Teams
gives
you
service
based
access
control,
so
using
the
same
metadata
we
use
to
group
information
into
logical
ponents.
You
can
isolate
data
based
on
those
cases
as
well.
So
you
can
see
up
here
we're
in
the
default
team.
The
default
team
is
essentially
the
platform
view,
meaning
I
can
see
everything,
but
I
can
switch
teams
and
we've
got
a
couple
teams
here.
We've
created
a
Java
team
and
a
WordPress
team.
So
let's
do
this:
let's
go
into
the
actually
before
I.
Do
this?
B
Let's,
let's
reaffirm
here
so
we've
got
I'm
gonna
shrink
this
a
little
bit
okay,
so
you
can
see
that
we've
got
this
Java
namespace
and
we've
got
the
Cystic
namespace
and
we've
got
this
a
wordpress
demo,
namespace,
okay,
and
so
now
let's
go
into
the
teams
here
and
switch
to
the
Java.
To
give
this
a
moment,
the
system
is
ensuring
that
I
can
access
this
team
they're
ensuring
what
metadata
is
relevant
to
this
team
and
what's
going
to
happen
here,
is
we're
going
to
shrink
down
this
environment
come
on.
You
can
do
it.
A
B
A
B
And
missing
the
group
information
here,
what's
really
going
to
happen
to
our
brand
new
feature
by
the
way
it's
actually
live
later
this
week.
Aha,
finally,
it
is
now
you
see.
The
only
thing
we
can
see
is
the
job
application
demo
and
now,
as
a
Java
user,
Java
team
user
I
only
have
access
to
this
information.
B
This
includes
all
relevant
dashboards
and
all
relevant
alerts,
so
I'm
be
able
to
scope
down
your
environment
based
on
the
same
metadata
that
OpenShift
in
kubernetes
use
in
order
to
give
control
and
an
insight
into
the
right
people
at
the
right
time.
This
is
service
based
access
control
and
is
a
critical
part
of
deploying
a
monitoring
product
that
works
properly.
With
your
your
container
application
platform,
alright.
A
B
B
Go
back
to
the
alt.
Actually,
you
know
what
we'll
stick
to
Explorer
and
the
interest
of
time.
We'll
do
one
thing
here,
which
is
we're
going
to
set
up
a
service
based
alert.
So
honestly,
if
you
had
to
get
alerts
on
individual
containers,
you'll
probably
kill
yourself,
and
instead
the
way
to
think
about
this
is
how
do
I
alert
on
an
aggregate
of
containers.
So
here
you
can
see.
I
won't
go
into
the
whole
alerting
process,
but
you
can
aggregate
across
any
tag
or
metadata
in
your
system.
B
So
here
I'm
saying
give
me
an
alert
across
Java
app
demo
and
where
the
replication
controller
is
Kassandra
one.
Let
me
kill
this
now.
I
have
an
alert
across
my
entire
Java,
app
demo
environment.
One
alert
that
could
service
that
whole
environment
in
I
could
also
segment
that
alert.
So
I
could
say:
one
I
could
create
this
one
alert
and
have
one
per
per
replication
controller
or
replica
set
one
for
per
deployment
and
one
for
me
so
on
and
so
forth.
B
B
This
one
is
a
massive
file
that
runs
across
an
entire
kubernetes
environment
and
captures
data
across
an
entire
namespace
and
now
I
get
in
inside
the
open
source,
Cystic
tool,
I
get
the
ability
to
troubleshoot
each
and
every
process
down
to
its
arguments
down
to
its
connections
down
to
its
payloads,
and
this
is
something
that
no
other
monitoring
tool
can
provide.
You
and
no
other
monitoring
tool
has
the
ability
to
give
you
this
view
into
your
container
application
platform.
B
B
Thank
you
just
very
quickly.
You
know
why
assisting
we
exist
because
we
love
tech.
We
also
need
to
make
money
along
the
way.
So
we
sell
a
couple
products.
I
wanted
to
tell
you
about
those
assisting
clouds
are
hosted
offering.
Where
you
know
you
can
do
an
individual
host
all
the
way
up
to
thousands
of
hosts,
monthly
or
annual
assisting
on-premise
it's
the
same
product.
But
then
you
you
take
our
software.
You
run
it
in
your
environment,
its
annual
only
with
a
minimum
commitment
and
Cystic
open
source
man.
B
We
love
troubleshooting
Linux
systems
and
that's
what
Cystic
open
source
is
all
about
system
org
check
it
out
and
we
also
love
free
trials,
so
come
onto
our
website
we'll
give
free
trial.
You
can
see
this
kind
of
core
functionality
that
I
was
talking
about
from
viewing
microservices
all
the
way
down
to
keep
deep
container
visibility.
We've
got
the
goodness
for
you.
I
would
love
to
interact
with
you
directly
and
get
you
running
on
the
trials
just
come
to
fisting,
calm
and
we'll
get
you
started
on
that.
B
Yeah
sure
I
would
love
to,
and
this
is
this
is
really
new
functionality
for
us,
so
I'm
happy
to
clarify
role
based
access
control
typically
happen
based
on
a
person
and
service
based
access
control,
happens
on
the
intersection
of
a
person
and
an
environment.
So
if
I
hop
over
here
to
settings,
you
can
come
over
here
to
teens
and
I
can
show
you
how
you
define
a
team.
B
So
if
I
click
on
the
Java
team
see
here,
okay,
so
within
the
Java
team,
here
we're
doing
a
few
things
we're
determining
whether
the
information
is
scoped
based
on
a
host
or
container
you're
determining
what
that
scope
looks
like
here
and
that
scope.
This
is
the
important
part
the
scope
is
defined
by
metadata
of
your
system.
This
is
the
service
in
service
based
access
control.
Your
service
is
defined
by
some
scope
of
metadata.
It
could
be
something
like
dev
prod.
B
It
could
be
something
like
you
know
the
the
Java
deployment
it
could
be
down
to
a
replica
set
that
you
care
about.
That's
that's
for
you
to
decide
and
then
finally,
you
can
determine
what
users
actually
are
allowed
inside
that
team,
and
so
you
create
this
team
based
on
the
service
and
then
decide
which
users
have
access
to.
Hopefully
that
helped
answer.
The
question
think.
B
B
So
I
missed
the
last
part.
Let
me
start
by
answering
the
first.
So
what
about
Seth?
That's
a
great
question.
It
seems
like
a
softball
to
me
because
we
just
published
a
three-part
series
on
monitoring
Seth
in
OpenShift
environments,
so
go
to
Cystic,
calm,
slash,
blog
and
it'll
be
right
at
the
top
of
the
blog
role,
but
we
do
a
killer
job
monitoring
stuff.
A
A
B
Sure
we
will
not
exactly
sure
when,
but
we
will,
in
terms
of
bandwidth,
absolutely
I
believe
it's
on
our
network
overview.
So
you
can
see
you
can
see
the
actual
consumption
of
bandwidth.
We
don't
track
what
your
say.
Bandwidth
limits
are
or
anything
like
that,
but
that
would
be
relatively
easy
to
do.
But
fundamentally
we
do
have
network
data
and
right
now
I'm
showing
this
across
the
you
know.
The
replica
set
here
I
could
drill
down
all
the
way
into
an
individual
container
and
I
could
show
you
CPU.
You
know
this.
A
B
A
B
Sure
so
what
I've
been
showing?
You
primarily
have
been
service-oriented
views,
but
you
know
kind
of
the
reason
we
do.
That
is
that
basically,
people
expect
us
to
be
able
to
monitor
at
the
physical
layer,
and
we
can
absolutely
do
that.
So
in
fact,
going
all
the
way
back
to
where
we
started.
I
can
switch
this
view
to
a
physical
view,
and
so
this
physical
view
now
tells
me
the
individual
hosts
that
are
running
this
environment
and
the
aggregate
utilization
of
file
system,
CPU,
network
and
memory.
B
You
can
drill
down
individual
containers,
so
the
beauty
of
Cystic-
and
you
know
what
we
described
early
on
is
you
have
to
be
able
to
tag
metrics
in
many
many
different
ways
so
that,
as
you
come
in
to
troubleshoot
an
environment,
you
can
slice
and
dice
it.
However,
you
need
to.
This
is
what
we
do.
This
is
a
fundamentally
different
approach
to
monitoring.
Then
other
systems
provide
you
from
an
interface
perspective
and
it's
part
of
what
makes
this
take
so
powerful.
Okay,.
A
B
A
A
B
That's
a
good
point,
so
just
a
quick
note
on
that
which
is
we
recently
open
sourced
a
new
project
called
cystic
falco
and
if
you
go
to
cystic
org,
slash,
falco
you'll
learn
all
about
it.
It's
a
security
monitor
for
containerized
environments,
and
so
you
can
easily
detect
anomalous
behavior
like
a
container
spawning
a
shell
or
a
container
accessing
sensitive
files
and
then
alert
on
those
behaviors
so
that
you
can
troubleshoot
and
solve
problems
before
they
become
really
big
issues.