0. What's this document meant for
   ------------------------------

Big Sister 0.98 introduces a new, improved, modular
monitor concept. The new modules require a slightly
different configuration and also introduce a few new
ideas. This document tries to show you how you can
make use of these new features.


1. Big Sister needs to know more about the machine it monitors
   -----------------------------------------------------------

One of the new features is that now the same test may
be implemented in an optimized way for each target
platform. This means that e.g. a disk usage test might
carry the same name "disk" no matter if it's used against
a Unix machine, if it's run via SNMP, if it monitors
a remote Printer with spool disk, a Windows box or
whatever else - provided that there is an implementation
for this target platform.

A side effect of this is that Big Sister now must know
more about the monitored device than now. In order to
achieve this a new configuration option in uxmon-net
has been introduced, the "DESCRIBE" statement. You use
DESCRIBE to tell Big Sister:

  - what class of device it is monitoring ("computer",
    "router", ...)
  - what manufacturer built the device
  - a list of "features" further describing the
    device (such as "unix", "linux", "hub", etc.)

Example uxmon-net entries are listed here:

    DESCRIBE   features=unix,linux,redhat,redhat71 device=computer localhost
    DESCRIBE   features=unix,linux,redhat,redhat71 rejectix

    rejectix   http://www.microsoft.com/
    rejectix   disk
    localhost  disk

As you can see DESCRIBE is associating a list of features
with an individual machine.

It is important to DESCRIBE the features of a monitored
device using the "features" argument, it is less important
(and optional) to set the "device" and "manufacturer"
arguments.

There are two special features automatically set: the
feature "remote" is automatically added to the feature
list of all non-local target machines, the feature "local"
to all local machines.



2. Getting information about known features and sensors
   ----------------------------------------------------

There is one major drawback with the new concept: uxmon now
knows of virtually hundreds of sensors/sensor flavours.
Also, it is important to know which features are relevant
and will select the right tests. To make it easier for you
to find out both the new "testers" command has been
introduced, e.g.

    bin/testers 

prints out a list of known device types, features and test
names, while

    bin/testers -f unix -f linux -f redhat -f redhat71 tests

will list all tests with a short explanation and detailed
explanation of the arguments it takes for a machine with
features=unix,linux,redhat,redhat71. 

    bin/testers -f unix -f linux -f redhat -f redhat71 -t disk tests

will only print information about the disk test.



3. Selecting between "new" and "old" tests
   ---------------------------------------

Big Sister 0.98 currently will transparently use new and old
style sensors - new style tests are preferred, though.

However, you can force Big Sister into using old style tests
only by just not providing a "DESCRIBE" statement for the
target host in question.



4. Performance graphing
   --------------------

The new style tests all accept a 

	perf

argument enabling performance graphing for the specific
sensor. So the old style etc/perf way of doing this has
gone. A disk test with performance monitoring could
look like:


	DESCRIBE features=unix,linux localhost
	localhost perf=30 disk

This will make the disk test run against the local machine
and submit performance data every ~30 minutes.



5. Developing new sensors
   ----------------------

The development of new style sensors will be explained in
a separate document. So far for now:
 
    - tests are defined in etc/tests.cfg
    - new sensors' implementation are found in uxmon/Requester
