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/
