[rtg] Fwd: Results with RTG
Leech, Jonathan
jleech at virtela.com
Mon Mar 9 13:37:57 EDT 2009
I recommend moving to JRTG. http://jrtg.sourceforge.net
1. JRTG has no memory leaks. I run my instance for months on end between
restarts, which are typically for code upgrades, backend maintenance,
etc.
2. Same graphs. JRTG is just the poller, it uses targetmaker and
rtgplot. JRTG makes it easy to write custom backends, however.
3. Someone else mentioned -z for RTG, JRTG writes nulls no matter what,
and not zeroes. For my custom backend / graphing engine, this shows up
as an empty section in the graph. I don't know what rtgpolot does with
nulls. Nulls are more appropriate than zeroes, if you're going to write
data to represent nothing. The default JRTG behavior of not writing
values at all is just as correct, but rtgplot shouldn't connect the
dots, and to do that would need to know the polling interval.
4. Not sure what you mean.
5. JRTG uses targetmaker, you'll have to script that, then similar to
hupping RTG you can make JRTG re-read the target file on the fly via
Java MBeans. And you can do a whole lot more entermprise management of
JRTG on the fly using MBeans.
Additionally, JRTG scales to more devices / interfaces (and puts an
order of magnitude less SNMP traffic on the network), properly handles
counter wrap, and the dependency / compilation / installation burden of
RTG goes away as JRTG is built in Java.
As others have mentioned using Netflow, I see Netflow as complimentary
to SNMP data, as it might / must be sampled, depending on the router
configuration and throughput on the interface. Also, my understanding is
that the directionality of flows must be inferred from the flow data,
i.e. there is no strong correlation of the flow to an inbound / outbound
direction, you must determine that by the source and dest ip addresses
in the flow data. We use flowtools at my company to collect and process
Netflow data.
Sincerely,
Jonathan Leech
Virtela Communications
________________________________
From: rtg-bounces at lists.grdata.com [mailto:rtg-bounces at lists.grdata.com]
On Behalf Of Harry Marcson
Sent: Sunday, March 08, 2009 8:30 PM
To: rtg at lists.grdata.com
Subject: [rtg] Fwd: Results with RTG
We are looking to integrate RTG into our system, because it seems to be
the only option for our setup. We are looking to poll about 100
switches, connecting about 2000 servers.
Our current RTG testing results for 1 switch polling showed us that RTG:
1- Seems to have memory leaks, not new news after reading through the
mailing list, but was wondering how people are surviving with this,
especially the ones with the bigger setups. did you apply any specific
patch such as yahoo rtg (yrtg) or own fixes?
2- Has really boring and bad-looking graphs. Good graphs would be the
ones that are from Cacti for example.. If anyone has a better
rtgplot.cgi or improved graphing code, please do share it!
3- Bugs in the graphs. A simple example is a server that got a 800Mbps
DDOS attack and got nullrouted.. RTG did not move the line near the
0Mbps, when it crashed. The end result is, once the server was restored
a few hours later, the graph line went down to the actual usage of about
10Mbps, but showed that during the nullroute a 800Mbps usage.
4- Makes matching the actual switch port with the RTG device id a bit of
a hassle. Has anyone come up with a solution for that?
5- Lacks automation when it comes to discovering new devices. Adding
switch ips is an easy one, but how to run rtg targetmaker.pl every time
a new server is added to a switch, aswell as restarting the RTG process
is a more difficult one.
I am also very interested in knowing wether any big companies are
utilizing RTG for their bandwidth monitoring or billing. I saw in the
mailinglist that Layeredtech, Gnax, Savvis are some examples. Any others
that would like to convince us that RTG is worth it in the long run?
Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.grdata.com/pipermail/rtg/attachments/20090309/04f4ab50/attachment.htm>
More information about the RTG
mailing list