On Sun, 29 Sep 2002, Blake wrote:
> My personal opinion is that effort should be put into
> the RRDTool plugin because it is much lighter then
> storing DB data over a period of time (I also think
> the data stored in a DB is incomplete...not sure of
> the details), and RRDTool is great for this purpose.
> 
> Really, all I would really want to do is be able to
> distinguish when the statistics were collected
> preferably a 24 hour period, then average that over a
> week, month, etc.).
> 
> What do you want to do with all that data anyway? 
> RRDTool should collect the data over a 24 hour period,
> save the stats, and start over again ... something
> like MRTG.  But I guess this all depends on what kind
> of information you need from NTOP.
> 
> Any thoughts?

I'm generally in agreement, but I do have a bit of a different
perspective.  I think for most folks that rrdtool is probably a better
tool for managing network-related data than MySQL.  My biggest beef with
rrdtool is that it seems more complex than necessary to set the thing up
for long-term historical record keeping.  (Yes, I've read the man page a
zillion times, but most pages don't take that many passes to sink in.)  
In some sense rrdtool seems biased against long-term archive storage by
design.  And I get that there are plenty of perfectly fine reasons for
that, but most of those reasons aren't big on my list.  And all of the 
Perl interfaces for rrdtool go through pipes to communicate with the 
command-line tool which just seems really nasty.

So, obviously MySQL doesn't have the rrdtool biases and Perl's DBI is the
anti-tower-of-babel to databases, but MySQL lacks the summarization
features and space-efficiency.  I really don't care much about the space
efficiency, but there's no need to burn through ever tick of data when
doing long-term analysis, so some sort of summarization (with optional
archival) process will eventually need to be grafted onto MySQL.  But as
it is, MySQL can handle replication pretty decently and it chews through
heaps of data pretty well.  OpenView and Solstice grafted the
summarization and archival features onto various SQL databases, and it
doesn't strike me as being that hard to fill in that gap in a reasonably
general way.  (It'd make a nice little project for an intern even.)

Anyway, that's more background.  I'm still an ntop newbie wondering how 
any of this would fit into ntop best.

Later on Sun, 29 Sep 2002, Blake wrote:
> oh before I get hit for this one ... I know RRDTool is
> a DB ... when I say DB I mean like MySQL or something.

It didn't confuse me at least.  :)

-- 
</chris>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop

Reply via email to