[rtg] Fwd: Results with RTG

[Matt Simerson]

If you *must* monitor and bill traffic based on the physical switch/ 
router/network ports, RTG is the best game in time. But the included  
scripts are barely adequate.

When I was at Layered Tech in 2006-7, they had outgrown the very basic  
scripts included with RTG. I wrote RTG::Report (on CPAN) which greatly  
simplified the process of extracting billing data, custom reports, as  
well as adding new polling targets (the dist includes a better  
target_maker.pl). My version was also much more efficient, reducing  
the time needed to generate reports from days to hours.

But there is a better way to manage bandwidth data. It is called  
NetFlow, and it's rapidly becoming an industry standard. If you can  
use it, you should. LT employees have discussed the move from RTG to  
NetFlow data numerous times. When I was there, we couldn't because the  
core routers were not capable.  They have since been upgraded and I  
wouldn't be surprised if LT moved away from RTG.

As far as better looking graph's, fire up your favorite programming  
language and design one that you think looks great. I recently did  
that using perl and GD::Graph for a project I just finished. The data  
source for that is, you can probably guess, NetFlow.

Matt

On Mar 8, 2009, at 7:30 PM, Harry Marcson wrote:

> 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
>
> _______________________________________________
> RTG mailing list
> RTG at lists.grdata.com
> http://lists.grdata.com/mailman/listinfo/rtg