►
Description
Monitoring can mean very different things to different people, and this often leads to confusion and misunderstandings. There are many offerings for both free software and commercial software, and it’s not always clear where each fits in the bigger picture. This talk will look a bit at the history of monitoring, and then delve into the general categories of Metrics, Logs, Profiling, and Distributed tracing and how each of these is important in cloud-based environment.
This briefing will explore the core concepts behind monitoring in a Cloud-based environment, and how the inter-related monitoring offerings & OSS projects can help your organization deliver a full monitoring solution for your OpenShift/Kubernetes implementations.
Guest Speaker: Brian Brazil, Founder, RobustPerception.io and core Prometheus developer
A
Hello
and
welcome
again
to
another
OpenShift
Commons
briefing,
this
day's
Wednesday
in
June.
So
it's
been
quite
an
interesting
year
that
people
are
up
to
number
77
in
our
briefing
series,
and
this
is
yet
another
talk
on
monitoring,
because
monitoring
seems
to
be
one
of
the
most
popular
things
and
maybe
some
of
the
most
one
of
the
most
diverse
group
of
things,
because
it
means
so
many
different
things
to
so
many
different
people.
A
B
So
I
says
now:
instead
I'm
Brian,
Russell
and
here's
my
talk
about
squash
monitoring
means
because
a
lot
of
the
time
when
people
are
talking
to
each
other
about
monitoring,
they're
really
talking
past
each
other.
So
to
give
you
a
bit
of
background
about
Who
I
am
I
am
one
of
the
former
developers
of
Prometheus,
even
though
this
is
not
a
previous
talk
at
all.
This
is
much
more
high-level
than
that.
B
I
was
in
Google
for
a
few
years
that
contributed
to
a
number
of
open-source
projects
and
I
work
professionally
in
monitoring,
doing
consulting
and
support
for
Prometheus
in
the
course
of
which
I
interact
with
a
lot
of
under
monitoring
systems,
because
people
want
to
integrate
them,
so
you
learn
a
lot
about
how
they
all
work
and
all
the
differences.
So
let's
consider
the
word
monitoring
monitoring
monitoring
like
when
you
see
this
word.
B
Are
you
thinking
the
same
sort
of
things
that
I
am
thinking
and
that's
kind
of
the
question
I
want
to
look
and
address
here
so
I
want
to
start
off
and
do
some
history,
because
if
you
talk
to
a
lot
of
people
today,
what
we
do
is
really
based
on
things.
There
are
really
good
ideas
many
decades
ago.
This
is
back
in
the
day
and
well
before
things
like
open
ships
existed
and
where
you
had
a
handful
of
machines
like
never
even
a
full
rack.
B
They
were
cared
for
by
citizens
for
more
artisans
and
giving
love,
loving
care
and
attention
to
everything
and
special
cases
were
known,
and
the
thing
is
that
there
are
tools
have
moved
on
greatly.
For
example,
we
went
from
manual
configuration
at
tools
like
chef
and
now
to
kubernetes
and
open
shift,
but
practices.
B
So
one
started
by
just
looking
at
some
of
the
tools
and
that
the
historical
tools
and
many
of
which
are
actually
still
used
today,
so
we're
gonna
start
with
looking
at
mrtg
and/or
D,
so
in
1984,
Tobias
created
a
pro
script
and
which
was
mrtg
and
you
know,
95
was
released
and
it
was
used
to
graph
SNMP
priority,
which
is
Nemec
stats
and
in
fact
there
are
many
of
these
websites
still
around.
Today.
With
these
graphs
anytime,
you
come
to
an
internet
exchange.
They
have
graphs,
they're,
probably
still
a
more
teaching,
and
it
started
off.
B
Storing
that
I
had
just
a
big
ASCII
file
that
was
rewritten
every
time
which
isn't
exactly
performant.
It
was
moves
to
see
like
to
treat
years
later
and
later.
Don
was
already
called
the
round
robin
database
and
which
performance,
rather
than
rewriting
an
ASCII
file
and
was
all
released
and
in
99
and
already
is
actually
the
basis
of
a
lot
of
more
modern
tools
there
like
graphite,
although
it
has
a
more
advances
in
these
days.
B
So
if
we've
ever
seen
a
graph
that
looks
like
this,
it's
from
mrtg,
so
very
common
for
bandwidth,
as
I
said,
so
that's
kind
of
your
graphing.
On
the
other
side,
you
have
your
alerting,
so
it
actually
started
out
in
96
as
an
ms-dos
application,
not
at
all
a
UNIX
thing
and
all
it
did
was
things
and
we
can't
like
a
proper
project
in
98
and
first
places.
99
is
net
st.
and
which
got
renamed
in
2002
because
there
were
legal
reasons.
B
You
have
a
machine
and
it
has
checks
which
are
scripts
that
are
passing
and
failing
and
thing
is
that,
because
we
had
this
world
from
one
hand,
you
had
mrtg
and
the
other
hand
you
had
Nagios
graphing,
which
is
our
what
this
is
all
in.
Your
white
box
faltering,
which
is
looking
inside
the
application
and
alerting
which
is
black
box
so
from
outside
the
application,
and
they
are
separate
concerns,
separate
tools-
and
this
is
all
from
a
world
as
well.
B
So
everyone
asked
what
monitoring
is
then
in
the
modern
age,
and
we
need
something:
that's
not
just
alerting,
graphing
and
jumping
on
everything
that
might
be
a
problem.
We
also
need
to
look
at
things
beyond
add
what
machine
has
we
need
to
care
about
logs
as
well
and
browser
events,
because
well,
Lots
users
are
using
web
browsers
access
things
and
java
script
in
their
browsers
is
getting
pretty
complex
and
needs
to
be
monitored
in
and
of
itself.
So
what
I
think
we
should
do,
then
is
rather
than
looking
at
what
the
tools
have.
B
Let's
look,
instead
at
the
problem
statement
of
what
we're
trying
to
do.
What
are
we
trying
to
do
with
all
of
this
monitoring
and
I
kind
of
see
there
to
be
four
categories
of
monitoring
which
is
19,
some
go
wrong,
debugging,
trending
and
then
plumbing.
So
let's
look
at
each
in
turn,
so
the
primary
thing
for
monitoring
is
alerting.
B
Okay,
if
you're
in
I
guess
that's
almost
always
going
to
be
doing
so.
The
thing
is
that
we're
trying
to
I
think
they're
wrong.
The
question
is:
what
is
the
wrongness
we
want
to
detect?
We
want
to
look
for
a
blip,
because
you
know
the
hack
into
the
package
was
lost
due
to
a
solar
array,
or
we
actually
want
to
focus
on
latency
affecting
end-users,
because
in
the
end
of
the
day,
you
can't
take
care
about
whatever
products.
B
It
is
we're
producing,
whether
that
be
a
social
good
or
something
for
money
or
just
the
back
office
process.
That's
handy
to
have,
and-
and
we
want
to
focus
on
that
sort
of
saying,
rather
than
everything,
because
if
you
inert
on
everything
that
just
isn't
going
to
work,
because
the
thing
is
that
humans
are
very
limited
in
what
we
can
handle,
we
can't
work
24/7.
We
need
reasonable
amounts
of
sleep
and
if
you
get
less
on
every
single
thing,
that
could
be
a
problem.
You're
just
going
to
burn
out
up
some
cash.
B
What's
called
alert,
fatigue
page
your
fatigue,
there's
a
few
other
names
from
it.
It's
basically
burnout
and
burnout
is
bad.
That's
not
the
best
way
to
use
people
at
all
Dre
engineers.
We
should
treat
problems
like
engineers
and
the
kind
of
a
key
insight
there
is
that
you
care
about
thats
a
user
facing
legacy,
and
there
are
hundreds
of
things
like
a
cause
that
a
machine
could
have
failed,
the
Rex
which
could
be
slow.
You
could
have
lost
some
power,
mating,
routing,
changed
and
you're
now
going
long
way
around
Europe.
B
You
cannot
possibly
learn
every
single
one
of
those
there's
hundreds,
maybe
thousands
of
them
and
you're
going
to
miss
some.
However,
why
you
care
about
at
the
end
of
the
day?
Isn't
that
perhaps
which
has
failed?
It
is
that
the
user
is
having
a
bad
experience.
So
if
you
can
emerge
directly
on
the
user
having
a
bad
experience,
that's
just
one
alert
and
it's
going
to
catch
a
multitude
of
problems
real.
B
So
let's
take
the
canonical
example
for
this,
which
is
CPU
usage.
There
are
systems
where
you
cannot
directly
alert
and
license
of
your
servers,
because
that's
just
not
information,
that's
exposing
or
useful,
but
you
do
have
CPU
usage
because
well,
if
you
have
seen
a
process
running
inside
Apache
and
it's
using
all
of
your
CPU,
you
can
bet
the
things
are
slow,
but
they
are
also
going
to
be
false,
positives
there.
So
if
log
rotate
or
whatever
background
processes
that
run
nightly
are
taking
too
long,
that's
going
to
give
you
a
false
positive.
B
If
there's
a
deadlock
in
your
code
and
well,
it's
just
going
to
lock
up
and
use
no
CPU
and
your
contentious
Hector
dieter.
So
what
a
test
tends
to
result
in
is
spam
alerts,
and
you
know
whoever
is
receiving.
These
alerts
just
tends
to
ignore
them,
which
automatically
means
because
of
that
alert
fatigue
that
are
going
to
miss
me
real
problems,
because
it's
going
to
look,
let's
go,
oh
it
stopped
again
and
let's
continue
on
whatever
they
were
doing
so
the
thing
is
alerts
should
require
intelligent
human
action
ray
engineers.
B
You
know
Java
photons,
and
it's
relate
as
well
to
end
user
problems.
Users
do
not
care
in
the
slightest
if
your
machine
has
a
load
average
of
four.
In
fact,
in
modern
systems,
load
average
isn't
even
a
particularly
useful
metric.
However,
they
do
care
if
they
can't
view
your
cat
videos
so
think
about
cat
videos,
not
load
averages.
B
Because,
if
we're
going
to
follow
the
guideline
previously-
and
all
we
have-
is
a
high-level
symptom-
well
that's
great,
but
where
did
we
start
going
and
the
thing
is
if
you're,
a
local,
the
micro
service
architecture
built
and
saw
something
like
open
shifts,
you're
going
to
have
some
form
of
like
tree
structure
and
what
you
want
to
do
is
just
use
the
scientific
method
start
at
the
top
and
drill
down
into
your
problem,
so
a
few
of
high
latency
and
to
backends.
You
might
start
at
the
very
root
of
your
tree.
B
You
know
the
front
end,
HTTP
server
and
say
right:
is
it
overloaded,
yes
or
no,
and
then
check
okay,
it's
backends
has
either
of
them
got
them
slow.
It's
like!
Oh!
This
packet
is
gotten
slow
right
same
process
again.
Is
it
overloaded
as
oh?
Yes,
it
is
overloaded
great.
We
now
we
found
our
problem,
but
its
back-end.
Look.
Fine!
Let's
dig
into
further
that
with
more
tools.
I
think
it's
as
well
is
that
there
is
no
panacea.
There
is
no
one
tool
that
is
going
to
help
you
to
both.
B
You
have
to
bring
in
a
myriad
of
tools
depending
on
how
complicated
the
problem
is.
What
the
nature
of
the
problem
is
so
metrics,
for
example,
are
great
for
figuring
out
roughly
where
the
problem
is,
but
they're
never
going
to
tell
you
exactly
which
requests
from
the
user
is
to
blame.
For
that
you
need
logs.
Neither
metrics
nor
dogs
are
likely
to
tell
you
which
line
of
code
needs
to
be
optimized,
that's
something
for
profiling,
and
then
all
of
those
are
going
to
tie
back
to
source
code.
B
On
the
other
hand,
if
it's
really
up
90%,
maybe
you
can
get
rid
of
some
other
machines
and
if
maybe
you're
instrumenting
your
features
and
it's
no
hey.
So
this
obscure
feature
we
add,
as
well
as
remove,
will
checked
no
one's
used
it
in
two
years.
So
then
it's
pretty
safe
to
just
remove
that
code
and
that's
no
longer
going
to
break
your
continuous
integration
and
the
most
common
one,
of
course,
is
capacity
planning
which
is
quick.
B
Can
I
use
your
monitoring
system
now
this
isn't
monitoring,
but
someone
is
going
to
ask
for
it
if
it's
kind
of
free,
like
they
want
to
transfer
a
log
line
and
minish
or
you
know,
a
metric,
that's
lon
sort
of
even
a
bad
idea,
rather
than
building
a
proper
solution.
Meccano,
let's
get
more
expensive,
so
something
to
consider
what
your
monitoring
system
is.
What
happens
when
people
start
using
it
for
other
stuff?
And
at
what
point
do
you
tell
them
that
you
know
gosh?
B
So
we
have
like
the
tree
goals
of
monitoring
and
plumbing
on
the
side.
What
what
are
we
going
to
do
about?
What
data
do
we
want?
How
do
we
want
to
collect
that
data,
and
the
thing
as
well
is
that
monitoring
isn't
free?
You
can't
collect
everything
all
the
time,
because
that's
going
to
be
more
data
than
you're
actually
processing.
In
the
first
place
now
you're
trying
to
model
your
data
would
explode
exponentially,
so
we
need
to
decide
what
trade-offs
we're
going
to
make.
B
It
might
be
tells
as
a
piece
of
context,
context
associated
with
this
event,
and
there
might
be
millions
of
these
events
per
second.
As
you
know,
you've
got
requests
cascading
through
the
system
and
there's
kind
of
for
roughly
four
classes
of
dealing
with
events
and
how
you
view
them
when
you're
talking
to
someone-
and
they
said
the
word
monitoring-
they
normally
mean
one
of
these
and
the
question
is
which
one
of
them
and
that's
where
a
lot
of
the
disconnects
come
around
the
word
monitoring.
Is
they
mean
one
of
these
or
alerting?
B
So
profiling
is
a
pretty
broad
area.
The
short
version
is
if
Brendan
greg
has
ever
talked
about
just
its
profiling,
so
he's
got
a
great
blog
lots
of
tools
and
I
like
the
Berkeley
packet
filter
and
so
TCP
dump
gdb
esterase
DTrace,
what's
in
common,
is
to
get
you
a
lot
of
the
information
about
individual
events.
The
problem
is
because
that's
a
detailed
information
about
a
visual
events-
that's
kind
of
expensive,
so
you
can't
turn
these
on
all
the
time
because
you're
too
expensive
and
you
can't
point
them
at
everything,
because
it's
too
expensive.
B
So
you
can
end
up
saying
that
right,
I
was
going
to
monitor
this
process
for
like
30
seconds
and
hope
no
noses,
and
we
just
have
CPU
profile
encoding
works.
So
these
are
great
tools
if
you
kind
of
have
an
idea
what's
going
wrong
like
if
you
know
something,
weird
is
happening
in
the
network
and
with
TCP,
then
use
TCP
dump
or
you
know,
hey
do
some
weird
Cisco's
use
s
trace
and
but
you
kind
of
need
to
know
what
you're
looking
for
before
you
start
using
a
profiling
tool.
B
Metrics
then
they
take
a
different
trade
off.
Their
trade
off
is
they're
going
to
ignore
individual
events
we're
going
to
track.
How
often
particular
context
shows
up
so
examples
here,
our
previous
graph
eyes
and
anything
else
in
that
space,
so
you
wouldn't
be
tracking,
like
free
chase
bureaucrats.
The
time
it
came
up
was
a
sh,
but
you
do
know
how
many
do
were
in
the
last,
while
how
many
have
failed,
how
many
questions
always
how
many
or
how
much
not
individual
requests?
B
Now
you
also
have
one
of
these
cases
where
one
of
the
hits
on
our
code
path
and
it's
going
to
increment
a
metric
but
you're,
not
tracking
Israel
events
are
kind
of
just
tracking
how
many
or
how
much
the
thing
is.
Metrics
is
there
handy
because
even
have
lots
and
lots
of
these?
How
many
questions,
but
you
can't
break
them
up
to
many
dimensions
so,
like
you
were
to
break
out
metrics
by
email
address
you.
B
If
you
have
millions
of
users,
that's
going
to
take
out
most
monitoring
systems,
so
what
metrics
are
good
for
is
breadth
across
your
codebase
and
know?
What's
going
on
I
kind
of
just
drilling
down
and
doing
your
initial
debugging
steps
when
you
get
an
alert
and
but
for
tracking
the
individual
events
and
really
getting
down
to
the
nitty-gritty,
you
need
something
else
which
brings
us
to
logs
which
are
kind
of
at
the
opposites
metrics.
So
they
track
individual
events,
but
they
track
unlimited
pieces
of
information
for
us.
So
you
know
it
was
mr.
B
foo,
who
is
do
this
end
point
this
time
got
this
response
with
this
status
code,
but
you
can
only
have
so
many
of
feels
like
50
to
100
and
before
you
run
into
bandwidth
issues,
whether
that
be
disk,
bandwidth
or
network
bandwidth,
and
just
because
you're
tracking
for
every
single
event
and
examples
are
de
ok
stack,
the
elk
stack
there
or
gray
log
and
yeah.
You
would
have
false
commercial
tools
here,
like
smug
and
Bosh
with
logs.
B
It
gets
even
a
little
more
complicated
because
just
as
monitoring
has
like
five
or
six
common
meanings
and
those
just
the
common
ones,
there's
also
a
few
different
types
of
logs
I
need
to
be
cific,
of
which
one
you're
talking
about,
because
each
of
them
have
different
reliability,
requirements,
different
volumes
and
other
considerations,
so
I'm
going
to
say
that
there's
roughly
four
types
of
logs,
so
you
have
your
transactional
logs.
This
is
anything
you
cannot
lose
so
that
will
be
required
for
billing.
B
You
might,
apart
for
legal
reasons
they
might
be
passing
on
to
other
systems
like
losing
them
is
just
not
an
option.
You
must
do
everything
your
power
to
stuff
and
being
lost.
You
have
requests
logs
so
if
you're
logging,
individual
HTTP
requests
or
anything
that's
tied
to
our
request,
its
request
log
and
your
application
logs,
which
are
different
from
request
logs.
B
They
tell
you
about
the
application
and
its
background
processes
and,
what's
generally
going
on
in
the
application
as
a
confirm
management
system
as
this
thing
from
the
actual
requests,
so
things
like
garbage
collection
or
sake
hub
runner,
management,
e
stuff
and
background
yourself
having
a
second
application,
and
then
you
have
the
bug
logs,
which
might
be
very
detailed
stuff.
Like
exact
request,
information
individual
function
calls.
It
basically
is
profiling.
Massive
data
volumes
and
because
of
that
is
generally
not
practical
to
keep
these
for
very
long.
B
But
these
are
all
different
types
of
logs,
and
if
someone
says
you
can't
ever
lose
logs,
they're,
probably
talking
about
transactional
logs
but
they're,
saying
no,
you
must
look
every
detail
ever
they're
talking
about
the
bug
logs,
because
trying
to
reach
the
bug
bugs
as
actual
logs
will
not
end
well
and,
for
example,
application
logs.
You
normally
want
those
to
be
readable
by
a
human,
well,
any
tooling
in
terms
of
volume.
B
The
fourth
one
then
is
distributed
tracing.
It's
really
a
special
case
of
logging,
because
normally
logs
across
different
machines
are
in
the
tenten's
well-distributed
tracing
does
is
each
request
like
each
end,
user
requests
gets
a
unique
ID,
that's
propagated
as
all
of
its
sub
requests,
a
cascade
system
and
as
something
like
open
tracing
the
opposition
like
stitches
these
all
back
together.
So
you
can
see
the
entire
history
of
this
requests.
So
this
is
useful
in
distributed
systems,
particularly
where
you've
got
many
services.
B
Many
interconnections
for
figuring
out
when
weird
stuff
happens,
so
it
is
essential
if
you've
got
a
micro
service
architecture
on
something
like
open
ships.
Here's
an
example
here
from
open
silicon,
and
you
can
see
here
how
we've
got
the
big
overall
request
here
and
here's
my
sequel
part
or
my
sequel
and
all
the
other
servers.
It's
talking
to
you
can
see
how
this
is
traced
over
time,
so
that's
very
useful
for
the
billing.
B
So
if
you
go
back
to
the
question
of
what
monitoring
means,
it's
not
just
some
black
box
alerts
going
to
a
lock,
it's
not
per
host
graphs
or
aggregated
white
box
graphs
like
you
get
from
Prometheus,
it's
not
just
logs.
It's
not
just
metrics
and
it's
not
just
a
big
TV
screen
on
a
wall
which
is
where
a
lot
of
boundary
seems
to
end.
Unfortunately,
so
the
way
I
would
see
it
is
monitoring
is
the
tools
and
techniques
you
use
to
keep
an
eye
on
your
system,
see
what
it's
doing
and
keep
it
functional.
B
There
is
no
silver
bullet
out
there
that
is
going
to
solve
your
monitoring
problems
right.
You
need
multiple,
different
things.
You
need
your
metrics,
you
need
your
logs,
you
need
your
profiling
needed
series
of
tracing
as
well,
keep
in
mind
culture
and
policy,
and
people
are
also
part
of
your
monitoring
system.
It
isn't
just
technology
and
computers.
You
need
to
think
about
how
you're
going
to
organize
your
own
code
shifts
to
make
sure
that
people
still
get
holidays
and
can
see
their
families
and
all
these
teams
come
in
together.
B
So
then,
to
summarize
this
and
the
goals
of
monitoring
as
I
see
them
is
knowing,
when
things
go
wrong,
being
able
to
debug
and
gain
insight,
trending
and
plumbing,
because
it's
going
to
happen
and
then
the
classes
of
monitoring
systems
you've
got
profiling.
It
has
lots
of
data,
but
so
much
that
you
can
only
use
it
very
briefly.
Metrics
are
great
for
Brett,
but
they
don't
work
too
well
with
that,
whereas
lols
they're
great
for
depth,
but
not
good
for
breadth
and
the
servants
tracing.
B
We
need
to
take
advantage,
as
you
go
into
a
cloud
negative
world,
using
great
tools
like
open
ships
to
take
advantage
of
all
the
facets
of
monitoring
systems,
because
we
must
scale
ourselves
as
engineers.
We
no
longer
miss
provision
machines
individually,
right
we
get
Amazon
to
do.
Is
we
use
packer
or
whatever,
and
we
shouldn't
definitely
care
about
a
single
machine
being
dead
or
slow?
We
should
be
caring
with
services
and
end-users
and
and
I.
Hear
kind
of
prometheus
is
good,
as
so
ardor
any
questions.
A
A
Oh
we're
monitoring
is
going
and
by
and
what
I
kind
of
wanted
ejectives
is
a
little
bit
of
the
idea
of
predictive
modeling
idea.
We've
been
I've
been
talking
a
lot
with
some
of
the
Apache
spark
folks
who
have
been
doing
deep,
dives
on
openshift
log
files
and
things
like
that,
and
we
talk
so
much
about
being
event.
Centric
like
this
happened
and
therefore
that
we
know
we
must
be
alerted,
or
you
know
the
profiling
things.
B
Array
should
like
predictive
stuff
and
I
I
kind
of
wish.
People
would
stop
thinking
it's
panacea,
yeah
because
it
isn't,
in
fact
it
barely
works,
because
the
problem
is
and
while
you're
talking
about
there
is
building
effectively
machine
learning
model
of
some
form
and
if
you
assistant
like
from
radius,
which
is
used
to
getting
like
a
thousand
metrics
per
application
instance-
and
you
might
have
a
thousand
of
those
and
you're
sampling
those
once
a
minute
and
you've
got,
you
know,
150
thousand
samples
per
second
coming
into
the
system.
B
There
is
just
gonna,
be
so
much
noise
in
there
actually
putting
out
any
useful
information
with
a
reasonably
signal-to-noise
ratio.
Doesn't
work
so
the
way
that
someone
pushed
me
someone
to
work,
some
machine
learning
systems-
you
know
the
more
traditional
ones
is
that
it
takes
18
months
to
train
a
model
there
which,
if
we
translate
that
to
monitoring,
means
it's
going
to
take
you
18
months
to
set
up
a
single
alert
like
ID.
That.
A
B
Exactly
and
so
you
could,
you
know,
have
someone
figure,
exact
levels
of
traffic
and
so
on,
but
it's
going
to
require
a
lot
of
maintenance
and
tweaking
and
I
would
take
the
approach
that
for
most
things,
the
vast
majority,
a
simple
static
threshold
is
good
enough.
Router
and
you
know
any
amount
of
time
on
something
running
spend
tweaking
anyway
and
I.
B
B
A
And
I
think
that's
the
funny
thing
about
cloud.
Is
people
always
think
of
this
ethereal
floaty
thing
out
there
in
the
ether
and
they
forget
that
they're
actually
server
farms
out
there
somewhere
heating
up
the
environment
and
with
real
machines?
So
there's
this
play
off
of
what
do
we
use
as
people
who
are
developing
apps
and
deploying
clusters
of
pods
onto
clouds
to
monitor
our
systems
versus
you
know
the
people
who
actually
are
putting
those
machines
and
servers
together,
and
you
know
so
there's
this
two
sets
and
it's
been.
A
A
So
I
really
appreciate
your
time
today
on
Brian,
not
seeing
any
questions,
but
I
know
that
may
be
because
it
is
a
high
level
thing
and
we
didn't
actually
be
what
real
demo
here,
but
we
will
do
lots
more
demos
up
and
coming
as
well
so
stay
tuned
for
some
of
our
upcoming
openshift
Commons
briefings,
because
monitoring
means
near
and
dear
to
all
of
our
hearts
and
you
had
an
upcoming
event
in
August.
Calm,
calm!
Yes,.
B
Phone
call,
in
fact,
ticket
sales
started
there
yesterday,
and
so,
even
if
those
at
prom
Khanderao
well,
what's
the
dates
for
that,
it's
August,
17,
18
tickets
are
just
80
euro
or
if
you
want
a
chance
to
win
free
tickets
and
my
company's
actually
roughing
some
off.
So
if
you
just
sign
up
to
our
mailing
list,
which
you
can
find
a
link
on
our
website,
you've
got
a
chance
to
win
some
free
tickets.
Perfect.
Then
it's
Munich.
A
It's
definitely
a
big
community.
It's
it's
happening!
So
if
you
want
to
take
advantage
of
that,
and
also
I'm
sure
there'll
be
a
lot
of
Prometheus
folks
talking
at
KU
con
in
Austin,
where
we're
going
to
host
the
next
ogres
of
Commons
gathering
in
December.
So
hopefully
we
can
get
Ryan
there
as
well.
Coming
on
right,
I
take
Julius
is
going.
Maybe
Julius
will
get.