When developing a performance monitor for a combined linux/vm environment, I chose netsnmp over rmfpf for two reasons.
One, netsnmp was very low cost to operate, does not create (large) files on the linux servers, and is a PASSIVE agent. Passive is important, i do NOT want to have an agent waking up every minute to measure an idle guest. With netsnmp, all linux servers could run netsnmp, but it would only "measure" when the server was busy - because requests for measurement are external - and only required when the server is active. None of the other agents are passive, they are ACTIVE. Thus if you want to measure 100 servers, your performance problem would be your instrumentation. The cost of netsnmp is zero cpu for idle servers... Second, netsnmp provides HOST mibs as well as the network mibs, AND it is EXTENDABLE. These host mibs are identical to those provided by SUN, NT, HP, etc. Meaning this gives me a method for providing much more than just a Linux on VM monitor. So from VM, all your NT, Linux, SUN, HP servers (as well as VM) can be measured. On any other platform that is IP addressable. ALL data coming from inside linux derives data from /proc. The netsnmp interface provides access to /proc in a number of different ways, as does RMFPM as does top as does every other agent out there. The implementation provided by velocity software takes the Linux data concurrent with the vm data and "corrects" the linux numbers to provide an accurate perspective. Thus, on one screen, you could look at ALL the processes running in ALL your linux servers and know immediately which ones are consuming your processing resource. You can't do this with the RMFPM implementations. So the best collection tool (imho of course) would use a linux interface to provide access to /proc, that can be extended to meet requirements that were not obvious until linux ran in a shared virtual environment on the mainframe.... One more point about netsnmp, beyond the HOST, MIB-II, and UCD mibs provided by netsnmp, we've extended it to support a set of (growing) velocity software mibs that we have found necessary to meet the challenge of mainframe style capacity planning and performance analysis requirements.... >From: Tom Shilson <[EMAIL PROTECTED]> > >Barton Robinson said: > >I've posted this in the past, the problem is not RMFPM, it >is all linux under vm monitors.... Top is just as bad. > >My standard explanation is posted at >"http://linuxvm.com/topisbad.html"; > >Thanks for the URL. I understand about Linux assuming that it >has the CPU all to itself. Your webpage suggests NET-SNMP. As I >understand it, SNMP is a low-cost way of collecting the data >that it has collected. Its performance numbers are no more valid >that any other collection tool (except a tool like Velocity's >which integrates Linux and VM data.) The SNMP daemon that comes >with the system will also work, it is just that NET-SNMP is more >complete. Yes? > >It seems to me that the best collection tool would not run in Linux at all. >It would follow control-block chains in storage and get the data from >/proc. Is this possible? > >Thanks, > > _/) Tom Shilson >~~~~~ GEDW & VM System Services >Aloha Tel: 651-733-7591 tshilson at mmm dot com > Fax: 651-736-7689 "If you can't measure it, I'm Just NOT interested!"(tm) /************************************************************/ Barton Robinson - CBW Internet: [EMAIL PROTECTED] Velocity Software, Inc Mailing Address: 196-D Castro Street P.O. Box 390640 Mountain View, CA 94041 Mountain View, CA 94039-0640 VM Performance Hotline: 650-964-8867 Fax: 650-964-9012 Web Page: WWW.VELOCITY-SOFTWARE.COM /************************************************************/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
