[rtg] rtg status?

[Matt Simerson]

On Jan 7, 2009, at 10:18 AM, Drew Weaver wrote:

> The poller is pretty great for RTG, I just wish the target maker was  
> a little smarter.

http://search.cpan.org/src/MSIMERSON/RTG-Report-1.16/bin/

See the file named target_maker.pl. :)

Matt


> It would be highly beneficial if you could do something like this  
> with the targetmaker:
>
> When a ports data is 'no longer needed' a flag would be set on the  
> row in the table for that port which tells rtargmkr the next time it  
> runs to move the data for that port into another table or  
> ([archiving] database altogether) then after the data is archived,  
> if the target maker sees that the port comes 'back' it just creates  
> a new entry for it. Which would be a good way of cleaning data which  
> is obviously useless out of the database.
>
> Like Matt said, the biggest problem we've had with rtg is "what to  
> do with all that data" as deleting hundreds of thousands of rows a  
> few times a day in MySQL is not terribly efficient.
>
> -Drew
>
>
>
> -----Original Message-----
> From: rtg-bounces at lists.grdata.com [mailto:rtg-bounces at lists.grdata.com 
> ] On Behalf Of Matt Simerson
> Sent: Wednesday, January 07, 2009 1:05 PM
> To: rtg at lists.grdata.com
> Subject: Re: [rtg] rtg status?
>
>
> Or they are just running the latest version of RTG and are quite
> content with the way it works. When I was a Layered Tech, we monitored
> several thousand switch ports with it. We use it at Spry as well, but
> only as a reference. I only have a few problems with the released
> version of RTG:
>
>    1. if the RTG poller loses the connection to the DB, it does not
> reconnect. Ever.
>    2. the perl scripts for reporting sucked.
>    3. databases get absolutely enormous after a few months worth of
> polling N thousand ports
>
> The solution for 1 is easy.  The application could be fixed to test
> the DB connection and reconnect after failures, or it can worked
> around. Just write a script that checks the last time a DB insert was
> made. If it has been more than 2X polling interval, then restart the
> polling daemon.
>
> Solving #2 required a bit more work but I published the solution here:
> 	http://search.cpan.org/~msimerson/RTG-Report-1.16/
>
> #3 is also solved by the record_consolidator.pl script in the
> RTG::Report dist.
>
> Of course, other people have had different problems with RTG and
> developed their own solutions. But you might want to just give the
> stock RTG a whirl. It may just do everything you need as is.
>
> Matt
>
>
> On Jan 7, 2009, at 9:37 AM, Adrian Chadd wrote:
>
>> People are running their own hacked up versiosn of RTG, and noone's
>> really stepped up to create an RTG fork to include all the various
>> patches, stuff from the Y!rtg, etc.
>>
>> Anyone up to the challenge? :)
>>
>>
>>
>> Adrian
>>
>> On Tue, Jan 06, 2009, Jeremy Guarini wrote:
>>> been using version 7 myself as I didn't see anything firm for
>>> version 8 or 9
>>>
>>> --Jeremy
>>>
>>> Quoting John Center <john.center at villanova.edu>:
>>>
>>>> Hi,
>>>>
>>>> What is the status of this project?  We've been using an older
>>>> version of rtg.  I saw a discussion about various patches floating
>>>> around, but it doesn't look like there has been any further
>>>> development.  Could someone please update the list?
>>>>
>>>> Thanks.
>>>>
>>>> 	-John
>>>>
>>>> -- 
>>>> John Center
>>>> Villanova University
>>>> _______________________________________________
>>>> RTG mailing list
>>>> RTG at lists.grdata.com
>>>> http://lists.grdata.com/mailman/listinfo/rtg
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> RTG mailing list
>>> RTG at lists.grdata.com
>>> http://lists.grdata.com/mailman/listinfo/rtg
>> _______________________________________________
>> RTG mailing list
>> RTG at lists.grdata.com
>> http://lists.grdata.com/mailman/listinfo/rtg
>
> _______________________________________________
> RTG mailing list
> RTG at lists.grdata.com
> http://lists.grdata.com/mailman/listinfo/rtg