Big Sister - NEWAGENT

- 0. What's this document meant for
- 1. Big Sister needs to know more about the machine it monitors
- 2. Getting information about known features and sensors
- 3. Selecting between "new" and "old" tests
- 4. Performance graphing
- 5. Developing new sensors

## 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