<br><font size=2 face="sans-serif">So we both want a basic CPU utilisation
alert.</font>
<br><font size=2 face="sans-serif">Cool.</font>
<br><font size=2 face="sans-serif">Hopefully somebody on the list has done
this before.</font>
<br><font size=2 face="sans-serif">If not, it's time to do a bit of scripting.</font>
<br><font size=2 face="sans-serif">If I have to do it myself, I will post
the results, if you are interested.</font>
<br>
<br><font size=2 face="sans-serif">Regards</font>
<br><font size=2 face="sans-serif">     Vernon</font>
<br>
<br><font size=2><tt>"Kern, Thomas" <Thomas.Kern@hq.doe.gov>
wrote on 13/09/2007 12:56:08 PM:<br>
<br>
> On the mainframes, we are used to lots of tasks waiting for various
<br>
> resources. Main memory, virtual memory, I/O, etc all are important
<br>
> and can be tuned fairly well. When that tuning isn't quite right,
<br>
> throughput can be degraded but the pain is not as bad as when the
<br>
> CPU gets overloaded. CPU is one resource that is hard to change, I
<br>
> have run systems that needed to be less than 50% busy and others <br>
> that the boss wanted at 100% and wished for 110% busy.<br>
> <br>
> The CPU value can also be the first indication of a runaway user or
<br>
> bad database query (this is our most common problem). Once we know
<br>
> from the CPU utilization that something is wrong, we can look for
<br>
> the cause and maybe the other problems are there too.<br>
> <br>
> <br>
> Thomas Kern<br>
> 301-903-2211<br>
> <br>
> <br>
> ----- Original Message -----<br>
> From: vernon.everett@westernpower.com.au <vernon.everett@westernpower.com.au><br>
> To: hobbit@hswn.dk <hobbit@hswn.dk><br>
> Sent: Thu Sep 13 00:23:43 2007<br>
> Subject: Re: [hobbit] CPU utilisation alerts<br>
> <br>
> <br>
> It might be different in mainframe world, but in Unix world, you <br>
> need to look at both the run queue length, IO stats and the CPU <br>
> utilisation to get an idea of what's happening.<br>
> If your CPU is at 100% and your run queue is still small, it's <br>
> probably just a hefty process chugging along, like a compile.<br>
> If your run queue is huge, and growing, and your CPU isn't yet at
<br>
> 100% you need to look at your IO. Disk, memory, swap, any resource
<br>
> that could be generating contention and IO wait.<br>
> If there is major contention for these resources you need to look
at<br>
> adding more, or utilising them differently - spread data across <br>
> multiple disks or mirror the disk to increase read throughput, that
<br>
> sort of thing.<br>
> If your run queue is huge, and growing, and CPU is at 100%, while
IO<br>
> is low, it's probably time to move to a new server, or find the <br>
> developer and tell him to fix his bugs. :-)<br>
> <br>
> So absolute CPU utilisation on its own, isn't particularly <br>
> meaniingful, but if that's what the PHBs want, let's give it to them.<br>
> <br>
> Regards<br>
>      Vernon<br>
> <br>
> <br>
> "Kern, Thomas" <Thomas.Kern@hq.doe.gov> wrote on 13/09/2007
12:07:37 PM:<br>
> <br>
> > I would prefer that the cpu test be the data from the vmstat
command<br>
> > instead of the load values. I am used to a mainframe system and
cpu<br>
> > utilization is more useful that queue length. All of my Linux<br>
> > systems are guests on a mainframe system so their individual
cpu<br>
> > utilizations is not as important as the values from my first
level<br>
> > system and I am working on a client side test for that.<br>
> ><br>
> ><br>
> > Thomas Kern<br>
> > 301-903-2211<br>
> ><br>
> ><br>
> > ----- Original Message -----<br>
> > From: vernon.everett@westernpower.com.au <vernon.<br>
> everett@westernpower.com.au><br>
> > To: hobbit@hswn.dk <hobbit@hswn.dk><br>
> > Sent: Wed Sep 12 23:56:43 2007<br>
> > Subject: Re: [hobbit] CPU utilisation alerts<br>
> ><br>
> ><br>
> > Hi Thomas<br>
> ><br>
> > Thanks for your quick response.<br>
> ><br>
> > A client side script would work, but I was thinking I cannot
be the<br>
> > first person to need this, and that somebody else has already<br>
> > invented the wheel.<br>
> > (I hate reinventing stuff)<br>
> > Alternatively, I was hoping that Henrik has some magic switch
or<br>
> > config setting that will make it work.<br>
> ><br>
> > Regards<br>
> >        Vernon<br>
> ><br>
> ><br>
> > "Kern, Thomas" <Thomas.Kern@hq.doe.gov> wrote
on 13/09/2007 11:46:07 AM:<br>
> ><br>
> > > I don't know if you can alert off one of the values in one
of the<br>
> > > trends graphs. That might take some back-end modifications.<br>
> > ><br>
> > > But you could write a simple client-side script to do the
same<br>
> > > command that is parsed for the trends graphs (vmstat, I
think),<br>
> > > totaling the cpu utilization values and sending a simple
status<br>
> > > message with the appropriate g/y/r color. The hobbit can
do the alert.<br>
> > ><br>
> > ><br>
> > > Thomas Kern<br>
> > > 301-903-2211<br>
> > ><br>
> > ><br>
> > > ----- Original Message -----<br>
> > > From: vernon.everett@westernpower.com.au <vernon.<br>
> > everett@westernpower.com.au><br>
> > > To: hobbit@hswn.dk <hobbit@hswn.dk><br>
> > > Sent: Wed Sep 12 23:36:07 2007<br>
> > > Subject: [hobbit] CPU utilisation alerts<br>
> > ><br>
> > ><br>
> > > Hi all<br>
> > ><br>
> > > I'm baaaack :-)<br>
> > > For those who might have missed me, I spent a few months
contracting<br>
> > > for a company that standardised on BMC Patrol. Wouldn't
even <br>
> look at Hobbit.<br>
> > > BMC is a horrible package, expensive, not very extensible,
with a<br>
> > > huge client footprint and overhead, and is very prone to
crashing.<br>
> > > Sad product.<br>
> > ><br>
> > > But no matter, I am now trying to satisfy my new company
that Hobbit<br>
> > > is the one monitor to rule them all, and my new colleagues
have<br>
> > > identified a "deficiency".<br>
> > ><br>
> > > This has probably been asked and answered before, but here
is <br>
> whatthey want.<br>
> > > I have been asked to generate a yellow/red status when absolute
CPU<br>
> > > utilisation reaches predetermined thresholds.<br>
> > > Yes, I know, without looking at the run-queue this figure
is not<br>
> > > very meaningful, but this is what they want.<br>
> > ><br>
> > > The la1 graph in the trends column does an excellent job
of graphing<br>
> > > the CPU utilisation, but how do I configure an alert based
on that figure?<br>
> > ><br>
> > > Regards<br>
> > >        Vernon<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ========================================================================<br>
> > > Electricity Networks Corporation, trading as Western Power<br>
> > > ABN: 18 540 492 861<br>
> > ><br>
> > > TO THE ADDRESSEE - this email is for the intended addressee
only and<br>
> > > may contain information that is confidential.<br>
> > > If you have received this email in error, please notify
us<br>
> > > immediately by return email or by telephone.<br>
> > > Please also destroy this message and any electronic or hard
copies<br>
> > > of this message.<br>
> > ><br>
> > > Any claim to confidentiality is not waived or lost by reason
of<br>
> > > mistaken transmission of this email.<br>
> > ><br>
> > > Unencrypted email is not secure and may not be authentic.
 Western<br>
> > > Power cannot guarantee the accuracy, reliability,<br>
> > > completeness or confidentiality of this email and any attachments.<br>
> > ><br>
> > > VIRUSES - Western Power scans all outgoing emails and attachments<br>
> > > for viruses, however it is the recipient's responsibility<br>
> > > to ensure this email is free of viruses.<br>
> > > <br>
> ========================================================================
  <br>
> ><br>
> ><br>
> ><br>
> > ========================================================================<br>
> > Electricity Networks Corporation, trading as Western Power<br>
> > ABN: 18 540 492 861<br>
> ><br>
> > TO THE ADDRESSEE - this email is for the intended addressee only
and<br>
> > may contain information that is confidential.<br>
> > If you have received this email in error, please notify us<br>
> > immediately by return email or by telephone.<br>
> > Please also destroy this message and any electronic or hard copies<br>
> > of this message.<br>
> ><br>
> > Any claim to confidentiality is not waived or lost by reason
of<br>
> > mistaken transmission of this email.<br>
> ><br>
> > Unencrypted email is not secure and may not be authentic.  Western<br>
> > Power cannot guarantee the accuracy, reliability,<br>
> > completeness or confidentiality of this email and any attachments.<br>
> ><br>
> > VIRUSES - Western Power scans all outgoing emails and attachments<br>
> > for viruses, however it is the recipient's responsibility<br>
> > to ensure this email is free of viruses.<br>
> > ========================================================================
   <br>
> <br>
> <br>
> <br>
> ========================================================================<br>
> Electricity Networks Corporation, trading as Western Power<br>
> ABN: 18 540 492 861<br>
> <br>
> TO THE ADDRESSEE - this email is for the intended addressee only and<br>
> may contain information that is confidential.<br>
> If you have received this email in error, please notify us <br>
> immediately by return email or by telephone.<br>
> Please also destroy this message and any electronic or hard copies
<br>
> of this message.<br>
> <br>
> Any claim to confidentiality is not waived or lost by reason of <br>
> mistaken transmission of this email.<br>
> <br>
> Unencrypted email is not secure and may not be authentic.  Western
<br>
> Power cannot guarantee the accuracy, reliability,<br>
> completeness or confidentiality of this email and any attachments.<br>
> <br>
> VIRUSES - Western Power scans all outgoing emails and attachments
<br>
> for viruses, however it is the recipient's responsibility<br>
> to ensure this email is free of viruses.<br>
> ========================================================================
    </tt></font><br><br><table bgcolor=white style="color:black"><tr><td><br>========================================================================<br>
Electricity Networks Corporation, trading as Western Power<br>
ABN: 18 540 492 861<br>
<br>
TO THE ADDRESSEE - this email is for the intended addressee only and may contain information that is confidential. <br>
If you have received this email in error, please notify us immediately by return email or by telephone. <br>
Please also destroy this message and any electronic or hard copies of this message.<br>
<br>
Any claim to confidentiality is not waived or lost by reason of mistaken transmission of this email.<br>
<br>
Unencrypted email is not secure and may not be authentic.  Western Power cannot guarantee the accuracy, reliability,<br>
completeness or confidentiality of this email and any attachments.<br>
<br>
VIRUSES - Western Power scans all outgoing emails and attachments for viruses, however it is the recipient's responsibility <br>
to ensure this email is free of viruses.<br>
========================================================================</td></tr></table>