0. What's this document meant forBig 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 monitorsOne 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 sensorsThere 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" testsBig 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 graphingThe 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 sensorsThe 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 |