# ourmon.sh start
Or it can be stopped just as easily with:
# ourmon.sh stop
The probe is configured via an ASCII configuration file called
ourmon.conf, which is supplied but needs some customization. For example,
it is important
to set an enterprise
home network address
plus mask.This enables
ourmon to determine if IP addresses belong to your enterprise or are
external.The probe runs (we hope) forever and is typically
started at the boot
time for the system.The probe can run on Linux or FreeBSD. We prefer
FreeBSD for heavy packet loads, but Linux will work. (We will talk in
Chapter 9 a bit more about how to optimize the probe).The
probe produces
a set of heavily aggregated output files.These ASCII files are fed as inputs to
the
back-end graphics engine
.The probe’s output files thus become the back-end
graphics engine’s input files.
We should point out that as an optimization it
is possible to install the
probe on a separate box and then arrange for the output files to somehow be
copied to the back-end graphics engine box.This enables you to devote more
CPU to the probe host and also to isolate the Web server behind a firewall
(out of your DMZ) if desired.The simplest installation
is to put all parts of
ourmon on the same host, though (which will be our assumption for this
book).
One other point to make about the probe and the graphics-engine soft-
ware is
what we might call
cycle-times
.There are a number of cycle-times in
the system.This concept is fundamental to network management and ourmon
at base is a network management system that happens to do interesting
anomaly detection as well.The probe runs in a 30-second cycle. In other
words, every 30 seconds it generates a snapshot of
packet inputs in its various
output files (for example, the main output file for the probe is called mon.lite,
but it’s just an ASCII file full of data). So basically the probe runs for 30 sec-
onds, generates a bunch of statistics in various forms, and then writes those
stats out and zeroes its counters, starting over.This
gives us a view of the net-
work that is shown in the back end that we can call the “current” view.This
view never lags more than one minute behind what is going on now. So in
summary the probe produces data at 30-second snapshot intervals.This is not
a real-time view, but is typically described as “near-time” because it does not
Do'stlaringiz bilan baham: