True, it isn't. It's the replacement of an operator. The main issue here
is that it needs to raise tickets and get reporting stats. For instance,
raise a ticket at 100% CPU (and indeed, our ABS limithard machines do
raise tickets when they are running their batch..<sigh>.) or when a
filesystem is at 100%. The reporting is for instance on CPU and
filesystem usage.

But indeed it can't provide insight in the performance of a guest, other
than detect thresholds. And it doesn't have to either, the monitoring
department can look at top, vmstat or sar to detect that kind of
problems should they need to (yeah right, then they know all about the
entire environment).

Still, as for a case, this is a good point. We need to be able to
address performance related monitoring and nagios can't do that. Or at
least not within the scope of an entire LPAR.

Thanks, Berry.

Op 19-08-10 22:12, Rich Smrcina schreef:
>  A 'general monitoring tool' is not a performance monitor.  In an
> environment where
> efficient resource utilization is critical to the business, a means to
> monitor:
>
> - the performance of the virtual machine environment
> - the virtual machines running in that environment
> - potentially systems outboard from the environment
>
> Is paramount to a successful implementation on System z.  Additionally
> you may want to
> perform chargeback and accounting based on internal procedures that
> may be in place.
>
> Nagios doesn't provide the timing resolution or access to z/VM
> monitoring resources, so
> it loses.
>
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to