There are three overriding issues with monitoring linux guests. 1) Overhead of monitoring. If each agent takes 5% of a processor for monitoring, multiply that by say 50 servers, is this good? Or will turning off your monitor solve your performance problem?
2) The CPU numbers from inside Linux are just WRONG. This is so very easy to prove - but not obvious when you are just testing. Wrong by and order of magnitude happens.... 3) You are sharing resources. 80% of your servers are idle, and in reality, maybe less than 80%, but exactness doesn't matter. Should you monitor an idle server? should you monitor only a few servers because you can only afford to? Most agents for Linux wake up every few seconds or minute and say, "hey, what am i doing? - oh, nothing, guess i'll wake up in 3 seconds and see if that has changed". So at any point in time, your agent is wasting maybe 5% of a processor to find out nothing. So if you have an agent that uses a lot of resource and provides you bad data, should you run it? ESALPS solves these 3 problems. 1) the netsnmp agent takes between .3 and 1% per server, usually on the lower side, somewhat tuneable. 2) the data is integrated with z/VM data, so the process data is corrected. 3) vm identifies inactive guests, why wake up an inactive guest to find out it does nothing. So ESALPS does not monitor idle servers. And yes, alerts are provided as well as lots of other things you haven't thought about yet.... (And sorry David, i know you said no vendors, but since nobody seems to talk about the issues of production type installations, it was necessary) >Date: Fri, 12 Aug 2005 10:48:26 -0400 >From: Jon Brock <[EMAIL PROTECTED]> > >I am pondering how to go about monitoring the Linux guests here at my = >shop. We have ASG's TMON for our z/OS system, but I don't think they = >have a Linux product yet. For the moment, I'm thinking about trying = >some unholy combination of the VM Performance Toolkit, top, and maybe = >Nagios or mon. Nagios, mon, and other such products are capable of = >producing e-mails to lists of support personnel. (In our case, we can = >use an e-mail to trigger a pager if we want.) > >We also have ACF2 on z/OS, but I don't think there are any plans (yet) = >to expand that to Linux; it wouldn't surprise me, though, if we = >eventually went to some sort of LDAP setup. > >We use FDRINSTANT for our backups. We bring the VM/Linux volumes online = >to z/OS, shut down the Linux guests, run the snapshots, restart the = >guests, run the backups, and then vary the volumes back offline. I have = >not yet gotten an opportunity to try a test restore of the backups, = >though. =20 > >Jon > ><snip> >Just a couple of quick questions. >Does anyone use any 3rd party tool,like OmegaMon, to monitor zlinux? >Has anyone every tried to implement CA's eTrust ACF2 Security for = >zLinux? >Has anyone tried doing volume level backups using FDR or DFSMS? >Do companies have a production control area monitoring the monitor? Or = >do >you page when alerts happen? > >Reason for questions. We are trying to build a case for the use of = >zLinux >in our shop. Management wants to be assured that all the pieces are = >there >before they will go forward. Thus the fact finding mission. "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
