Dear Ladies and Gentlemen,

I am writing with some prelimainary remarks about 2.1.55.

2.1.55 is a candidate successor to the very successfull 2.1.50. This
release was the most stable ntop I have seen.


1 Net
 /24 LAN with < 50 Win 9x clients running MS apps from a local file
server and accessing corporate apps (Internet and J2EE) via a 128 kbps
WAN.

 ntop collects data using an Intel Pro 10/100 (at 10 Mbps) from a
spanned port on a Cat switch.

 ntop only captures data entering or leaving via the WAN 

2 Ntop host (don't laugh)

 NIC fxp driver to Intel Pro 10/100

 FreeBSD 4.7-RELEASE

 166 - 233Mhz/32-64 MB - no other applications

3 Building Ntop

 The release engineering of this product is simply superb; I'm expecting
it to make my lunch next.

 I installed automake-1.6.3 in a non system directory (following Mr
Strauss's very clear instructions), put its path ahead of the system
paths in my environment and watched configure and gmake build ntop
without any problems.

 4 Comments

 It's too early for me to comment on 2.1.55s stability since I have only
started running it today.

 I am interested in protocol usage of the WAN link, so for some time I
have been using the Perl programs supplied in the (former) RRD sub-dir
of the www directory to harvest data from the web interface and store it
in a local RRD.

(These programs work well but need an alarm signal handler because
sometimes the LWP::Simple::get hangs and fails to return).

 This has let me store protocol byte counts (eg SSH, Ntop, BEA, Mail) in
one DS in one RRD. Futhermore, RRD 1.1 (dev) at the central site - where
the data is harvested from the satellite ntops and stored in a
corresponding RRD - allows jake Brutlag's Holt-Winters based abberrant
detection system to provide predicted upper and lower bounds for the
protocol usage.

 The rrd plugin on the other hand seems advantageous in that the data is
stored locally and if I want to consolidate it centrally I can harvest
it with rrdfetch over an ssh connection (or similar).

 Unfortunately, the plugin creates a single point in an rrd containing
that protocols data, so I have to run a procedure that extracts the last
data point from each of the interesting rrds, or extract from each in
turn.

 Would it be better for the rrdplugin to produce fewer rrds, with for
example all the protocol measurements in one rrd, all the IP protocols
(tcp/udp/icmp) in another, all the ether stats in another etc ?

 More generally, how do people use the rrdplugin to provide a data
source for consolidating data from collector ntops into a central rrd
for (perhaps) analysis and graphing - using rrdcgi.

 Have I completely missed the point of the rrdplugin ?

Yours sincerely.

-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to