check_proc --metric=CPU - alternatives?

[Jim Avery]

On 10 August 2010 07:12, Sebastian Ries <Sebastian.Ries at dtnet.de> wrote:
> Hi
>
> as I'm not sure if my first attempt to send this message did work here i post it the second time:
>
> I have the following Problem:
>
> We have some Processes which are running but are idle for some time
> (maybe some weeks) and the get used by a user.
> While a single Process is used is should have a cpu usage varying
> between 10 and 50%.
> We have the problem that sometimes a process gets stuck and then is
> running at 100% cpu usage.
> => this is what we want to check via Nagios.
>
> I tried to use check_procs like:
> ./check_procs -w 80 -c 90 --metric=CPU --command=qemu-system-x86
> but this did noch catch the processes.
>
> After some testing and searching on the internet I found out that this
> is depending on how ps calculates the cpu usage:
> It devides the cputime by the runtime of the process, giving the average
> cup usage over the whole process time -> which does not really help :-(
>
> Does anyone know of an alternative check which gives me the cpu usage
> actual of a process (or maybe the average over the last minute)?



"ps -ocputime" will give you the total cputime used since the process started.

You could code a plugin which stores this then next time it's run will
calculate the %cpu from the difference between the old and new values.
 It's a bit of a dirty solution, but this kind of thing is done in
some of the snmp plugins for checking interface traffic counters for
example http://nagios.manubulon.com/snmp_int.html

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null