Now previously we've been focused on how we can effectively parse memory
information from
our devices.
What I now want to turn your attention to is how we can do a similar thing but
for CPU
that is our computer processing.
So naturally if our processes happen to be overworked then what is going to
happen is
the CPU is not going to be freed up for other tasks and thus we're going to get
sluggish
performance.
Now previously we also used this particular utility stress NG and once again we
're going
to use this same command this time with a different option so that we can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to use this same command this time with a different option so that we can
stress the
CPU.
So let's look at some of the commands that we could use with respect to our CPU
and
then we'll begin parsing some information.
So obviously one we can use would be the top commands as we can see here we
have our
column specifying all the CPU information.
If you so wish you can parse that information in a similar way what I would
recommend though
is when you use a top command if you go into the man page here and scroll on
down the option
I would specify would be the dash B flag for batch mode this is going to allow
you to
effectively send the output from top into other programs or to a file pretty WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
effectively send the output from top into other programs or to a file pretty
much we
specify the dash N option so that we can specify how many iterations you want.
So if I just say top dash B N1 and to enter as opposed to having our
continually updating
and interactive top output instead we just get this one snapshot captured here.
Check this out see that.
So to make things a little bit easier to read let's pipe this output into the
head command.
So the top few lines let's just focus on this one here CPU what I could do is
just
correct that output for CPU and check this out right here here is all the CPU WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
correct that output for CPU and check this out right here here is all the CPU
information
once again if you want to pass this information into arc you could parse that
no problem at
all so like I say let's just parse it again and we can just begin printing our
values here
to first we can get the second value the third isn't really a value as such
however the fourth
value is and once again just like we saw before we can convert these numbers
into integer
or float values and begin at running comparison so that is one command you can
use you could
also use the uptime commands now in this case here we're going to see the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
also use the uptime commands now in this case here we're going to see the
actual load average.
Now this is what I'm going to focus in on in this particular video so can you
recall
how to interpret the load average we have three different values here one is
the load
average which is pretty much a little snapshot of the general activity on the
system and
we see it in three different time increments.
The first one here is the load average over the past one minutes the next one
is the load
average over the past five minute period let me just draw that a little bit
clearer here
we go five minutes and the last one here the third one this is the load average WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we go five minutes and the last one here the third one this is the load average
over the
past 15 minutes now the general rule of thumb is that you really don't want to
have a load
average greater than the number of CPU cores on your systems so if I just go to
my terminal
here now say LS CPU we have a whole bunch of information popping out.
If I scroll on up we can see our CPUs in fact let me just wait for that to make
it a little
bit easier as we can see here from my output I have two CPUs so in the case of
my uptime
if I saw any of my load averages approaching the 2.0 mark that would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if I saw any of my load averages approaching the 2.0 mark that would
potentially be a cause
for concern especially for prolonged periods so if you saw it in the third
column then
this would definitely merit some investigation now as opposed to actually
getting this information
via the uptime commands and trying to parse it via you know if I print one or
five you
really recommend all these values one and five I figure all the way up to eight
for example
notice I'm now getting these numerical values but I'm also getting a trailing
comma similarly
let's go to the next value so I'll use dollar sign nine there's the next we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's go to the next value so I'll use dollar sign nine there's the next we
also have a
comma and now we get to the third load average via the value 10 and we don't
have a comma
at the end you see that look at the information here we have two commas when it
comes to comparing
these numerical values we would actually have to manually strip out the commas
for two of
the values and that is just a little bit additional work we can get the same
information but in
a slightly different format that is more conducive to our playbooks just by
simply going into
the command or rather into the file should I say proc load avg so let's just
cat this
particular file right here and check this out this here these first the values WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
particular file right here and check this out this here these first the values
are actually
the load averages but we don't have to contend with this weird formatting of
dealing with
the commas so let's use this particular command and again we really don't want
to be seeing
the value over two but just for a general warning how about we write a playbook
to warm
us if the value ever gets greater than one so let's go and do this then let's
create
a playbook called play three dot yml go into insert mode have a three hyphens
give it a
name we'll just say play three testing cpu usage again we'll target the all-g WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
name we'll just say play three testing cpu usage again we'll target the all-g
rit within
our host gather facts will be set to false and they will define our tasks so I
will say
is I'll pull the one minute load average and I'll use the answer will built in
shell module
so again if I cat my proc load average file if I take that output and I feed it
into the
all commands and then I'll have my quotations and curly braces and I'm going to
specify
that I want to print the very first value that we get the first column should I
say
that will be this value right here if I answer notice the value in this case WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that will be this value right here if I answer notice the value in this case
here just happened
to change these values are in flux after all depending on the CPU utilization
if I happen
to do dollar sign to we get the five minute average and then dollar sign three
we get the
fifteen minute average so this command here will parse out the one minute
average which
will be much more variable so let's go back into our playbook okay so let's
paste this
in and let's register this I'll say this is the variable one minute average and
now I'll
write a task to test the one minute average so now let's use the answer will
built in
the debug module and the message is going to be warning the one minute load WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the debug module and the message is going to be warning the one minute load
average is
above one and then what I can do is actually use my double curly braces and
then print out
the one minute average and I'll take the STD out so let's save this and writing
quits now
if I happen to run the playbook right now it's always going to print out that
warning
message as we see here warning the one minute average is above one point zero
and then it
shows us the value which in this case here is only 0.04 and then in this case
here for
the blue box is 0.0 very very low so pretty much this statement is not actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the blue box is 0.0 very very low so pretty much this statement is not actually
true we
only want the warning to print when a particular condition is met so let's go
in here go into
our playbook and we will only print this particular message when something
happens and what is
that going to actually be them but if I take my one minute avg.stdout value
which is by
the way what we just saw printed on the screen right here in this case of the
yellow box it
was 0.4 and the blue box 0.00 these are float values by the way now remember we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
was 0.4 and the blue box 0.00 these are float values by the way now remember we
don't want
this to be string values so I'm going to use a filter to convert it into a
float so not
using integer this time because we're using the point zeros let's use the float
and what
I want to do is I want to print this when that particular value when it is
converted to a
float when that value is greater than one so let's save this right here now if
I just
run this at the moment nothing should actually print because the load average
is really quite
small at the moment but if I go to my device here let's maybe go to the blue
box and I say WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
box and I say
stress ng-cpu2 to use two CPUs and I say the timer is 100 seconds watch what
happens
if I go to a new terminal window if I just say uptime for example to see the
load average
this here is beginning to creep up and again let's do it again arrow up it's
beginning
to get high and higher basically it's now greater than one so if we run the
playbook
we should actually see that reflected over on the blue box device let's try
this one
more time and to enter look at what we're getting here we're pulling the
command for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
command for
both devices in the case of the yellow box the print message is skipped because
the condition
was not met but in the blue box we're actually getting this warming the one
minute load average
is above one and it shows us the value 1.46 at the snapshot so what I could do
is I could
actually build out my playbook and I could effectively just copy all this right
here
and then paste this in and all I will do is I'll make some modifications for
the second
one here I will change the name to pull the five minute average so it's nice
and descriptive
my awkward is going to print out the second value which will be the five minute WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
my awkward is going to print out the second value which will be the five minute
average
and I'll change the name of the variable here to be five minute a vg and then
down here
where we run the test I'll change the name to test the five minute average and
change
the morning message to be the five minute average as above one and again I'm
going to
change the value here to be the variable five minute a vg dot s ed out and
again the condition
here once again change to five minute average and again let's just scroll on
down let's paste
all this in one more time and all I'm going to do once again is just change WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
all this in one more time and all I'm going to do once again is just change
this value
here to be 15 minute average when I cat the proc value I'm going to get the
third column
and I'll register the variable as 15 minutes and again moving on down test the
15 minute
average and then have the average here 15 minutes reference the correct
variable here
as 15 minute average and again 15 minute average down here so essentially we've
now written a
playbook that is going to test for all over three different load averages
across three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
across three
different time periods and give us a warning if we happen to have a value over
a particular
value that we deem worrisome or at least worthy of notification and again adapt
these values
to whatever your system is and to whatever levels you want to see so let's last
ly just run the
playbook once again and to enter we'll probably see the same type of output
once again so the
playbit runs if we scroll on up we can see here the 15 minute average and five
minute average have
both been skipped over because the actual stress test has not been running long WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
both been skipped over because the actual stress test has not been running long
enough to affect
those averages but once again on the one minute average we still have a value
of 1.29 which is
above the value 1 and therefore the warning message was triggered.