On Mon, 2011-04-11 at 15:23 -0500, Gary Gatten wrote:
> Hmmm.  I don't *think* ntop will give you the granularity nor history
>  you speak of - not without major tweaking.  I could be wrong, but 5
>  minute granularity is about all you can expect, in some cases 60
>  seconds.  Going back "n days" will also prove problematic, unless you
>  have lots of RAM / small numbers of hosts /etc and make them
>  "sticky".  Many "detail" counters age out after 24 hours.
> 
> You mentioned playing with rrd - MAYBE some knob turning will give you
>  what you need, but I'm thinking not.  One second granularity for
>  several hours is hard enough, let alone several days.  And, if I'm not
>  mistaken sflow is a periodic sample anyway, and as accurate as the
>  claims of sampled data may or may not be, I suspect it's not even
>  close if you're looking second by second.  Netflow won't even help
>  much then.

I'm not looking at flows second by second - I'm interested in counters
second by second - the per-interface counters on my switches.  I don't
have nearly as great an interest in the flow samples and may not even be
configuring switches to send flow samples.

> You may want to consider nTop as the "big picture view" and something
>  like Wireshark capturing "everything" you're interested in and saving
>  to a new file every hour on the hour for 72 hours (or whatever). 
>  You'll need lot's of disk :)  You can save some space by only
>  capturing headers and skipping the data.

My current "plan B" is using sflowtool to dump counter samples, but then
I have to find the nice ways to turn that into pretty pictures.  Again,
I'm not really interested in flow samples (or I guess at least I've not
learned I'm interested in flow samples :) just counter samples.

> LMK what you come up with

First thing I come-up with then is a question :) Well, perhaps more than
one :)

When I go the RRD plugin preferences page:

http://127.0.0.1:3000/plugins/rrdPlugin

There is an entry for "Dump Interval" and the web form allows me to set
it to "1" - what then am I actually storing? I was ass-u-me-ing the
interface stats would be dumped, and perhaps other things, based on the
"Data to Dump" check boxes further down.  I wasn't sure though how that
might interact with sflow counter samples that do not arrive more often
than 5 or 10 or 20 seconds per switch port.

Similarly, I'm permitted to set "Throughput Granularity" to 1 second.

"Dump Hours" and "Dump Days" and "Dump Months" seemed like they would be
doing bidding similar to my desires wrt aggregating data for longer
term.

BTW, there appears to be a typo in the "RRDcached Path" description - it
reads in part "overloads ntop from RRD file update."  I suspect that was
meant to be something like "offloads RRD RRD file update from ntop."

rick

> 
> G
> 
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Rick Jones
> Sent: Monday, April 11, 2011 3:06 PM
> To: Luca Deri
> Cc: [email protected]
> Subject: Re: [Ntop] known double free bug in 4.0.3?
> 
> On Mon, 2011-04-11 at 20:51 +0200, Luca Deri wrote:
> > Rick this is a problem that from time to time shows up. I have analyzed
> >  the code a few times and not been able to spot this bug. I appreciate
> >  if you could help
> 
> I will see what I can find while I'm blindly trying to feel my way
> around the elephant (that old adage about the several blind men trying
> to describe an elephant and each saying something completely different
> based on what part of the elephant they were at :)
> 
> That will be while I'm poking around the sFlow and RRD areas - I am
> anxious to figure-out if indeed I can get "pretty pictures" down to one
> second granularity if I happen to have sFlow counter samples arriving at
> that rate.  The whole N days for interval stats and such heirarchy seems
> quite well suited to my desires - which is to be able to look at what
> was going-on down to a one second granularity going back oh three or
> five days, but letting it aggregate after that.
> 
> rick
> 
> > 
> > Thanks Luca
> > 
> > On Apr 11, 2011, at 7:18 PM, Rick Jones wrote:
> > 
> > > So, having temporarily worked-around the bit with the libraries not
> > > being found, I left 4.0.3 running on an Ubuntu 10.10 system over the
> > > weekend, receiving sFlow counter and flow samples from a switch.  When I
> > > got in this morning I saw an abort message:
> > > 
> > > *** glibc detected *** /usr/local/bin/ntop: double free or corruption
> > > (fasttop): 0x00007f6db04e7990 ***
> > > ======= Backtrace: =========
> > > /lib/libc.so.6(+0x774b6)[0x7f6dc0a584b6]
> > > /lib/libc.so.6(cfree+0x73)[0x7f6dc0a5ec83]
> > > /usr/lib/libntop-4.0.3.so(ntop_safefree+0x16)[0x7f6dc0fb5826]
> > > /usr/lib/libntop-4.0.3.so(dequeueAddress+0x49a)[0x7f6dc0faa54a]
> > > /lib/libpthread.so.0(+0x7971)[0x7f6dbfb91971]
> > > /lib/libc.so.6(clone+0x6d)[0x7f6dc0ac792d]
> > > 
> > > is this a known thing, or is it new and requires a more formal bug
> > > report? 
> > > 
> > > rick jones
> > > <dump.txt>_______________________________________________
> > > Ntop mailing list
> > > [email protected]
> > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > 
> > ---
> > We can't solve problems by using the same kind of thinking we used when we 
> > created them - Albert Einstein
> 
> 
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop
> 
> 
> 
> 
> 
> <font size="1">
> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 
> 0in 1.0pt 0in'>
> </div>
> "This email is intended to be reviewed by only the intended recipient
>  and may contain information that is privileged and/or confidential.
>  If you are not the intended recipient, you are hereby notified that
>  any review, use, dissemination, disclosure or copying of this email
>  and its attachments, if any, is strictly prohibited.  If you have
>  received this email in error, please immediately notify the sender by
>  return email and delete this email from your system."
> </font>
> 
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop


_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to