[rtg] rtg status?

[Adriano Amaral]

Heheh I've seen the script before but was a little on the safe side to
put it on prod. Anyway I'm migrating from a SLES 10 to FreeBSD  it will
be a good oportunity to test it
BTW, do you guys have any kind of trouble to get to the CSV  ???

Thanks Matt

Matt Simerson a écrit:
>
> 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
>
> _______________________________________________
> RTG mailing list
> RTG at lists.grdata.com
> http://lists.grdata.com/mailman/listinfo/rtg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.grdata.com/pipermail/rtg/attachments/20090107/aa0ed720/attachment.htm>