(My age surely is catching up with me, I forgot to include the URL for dstat)
[1] http://dag.wieers.com/home-made/dstat/ Rgds, On Oct 26, 2011 8:27 AM, "Pandu Poluan" <pa...@poluan.info> wrote: > (Sorry for the late reply; somehow this thread got lost in the mess) > > On Oct 12, 2011 2:03 AM, "James" <wirel...@tampabay.rr.com> wrote: > > > > Pandu Poluan <pandu <at> poluan.info> writes: > > > > > > > The head honcho of my company just asked me to "plan for migration of > > > X into the cloud" (where "X" is the online trading server that our > > > investors used). > > > > This is a single server or many at different locations. > > If a WAN monitoring is what you are after, along with individual > > server resources, you have many choices. > > > > It's a single server that's part of a three-server system. The server needs > to communicate with its 2 cohorts continuously, so I have to provision > enough backhaul bandwidth from the cloud to my data center. > > In addition to provisioning enough RAM and CPU, of course. > > > > Now, I need to monitor how much RAM is used throughout the day by X, > > > also how much bandwidth gets eaten by X throughout the day. > > > > Most of the packages monitor ram as well as other resource utilization > > of the servers, firewall, routers and other SNMP devices in your network. > > some experimentation may be warranted to find what your team likes best. > > > > Currently I've settled on a simple solution: run dstat[1] with nohup 30 > minutes before 1st trading session, stop it 30 minutes after 2nd trading > session, and send the CSV record via email. Less intrusion into the system > (which the Systems guys rightly have reservations of). > > > > What tools do you recommend? > > > > OH boy. I like JFFNMS very very much. It has a very old version in > portage > > (masked) but a very new version out there for Debian and Ubuntu. It > > runs on all nix, if you want to driectly compile and install. > > > > I'll be putting together a new ebuild, as soon as I get it working > > with the latest postgresql. Mysql works out of the box. Postgresql-9 > > has many new and very cool features. > > > > Cool! I *love* Postgresql! Update me when the ebuild's done? > > > > Remember: The data will be used for 'post-mortem' analysis, so I don't > > > need any fancy schmancy presentation. Just raw data, taken every N > > > seconds. > > > > Personally, I have some large, high risk design work going on. JFFNMS > > and pg9 are the best choices from my research. A whiz like yourself > > could easily look at the old JFFNMS ebuild and create a new one. > > Naaah, I'm going to wait for your ebuild. I'm sometimes lazy, you know ;-) > > > PG-9 (please no flame wars on mysql vs pg9) is very cool and what > > my work is migrating too, once I get some breathing room. > > > > Craig at jffnms.org is very cool and responsive. He also works closely > > with those that submit patches. Nagios is a large, disorder array that > > had many devs fork off since the project leader (was/is an a_ole) > > is quite difficult to work with. > > > > That sounds really cool. I've been hesitant to go the Nagios route because > of the mess. I'll sure to be checking out JFFNMS. > > > JFFNMS rules and is very cool for managing cisco and other routers, > > not to mention a myriad of snmp(1,2.3) devices and all types > > of servers. The original guy, Javier, was snapped up by someone > > worth billions, to manage and extend his financial network, but, Craig > > is probably stronger coder, and extraordinarily nice human being. > > It's mostly php. Lots of folks extend JFFNMS, Craig keeps it clean > > and well written and documented code. > > > > http://www.jffnms.org/ > > > > hth, > > James > > > > Thanks for the heads-up! Although the original problem is solved already > (granted, in a somewhat kludgy way), your post is a great write-opener! Much > appreciated :-) > > Rgds, >
