The client-local.cfg file is currently used to configure what logfiles the client should fetch data from, to be used as the basis for the "msgs" status column; and to configure which files and directories are being monitored in the "files" status column.
Note that there is a dependency between the client-local.cfg file and the hobbit-clients.cfg(5) file. When monitoring e.g. a logfile, you must first enter it into the client-local.cfg file, to trigger the Xymon client into reporting any data about the logfile. Next, you must configure hobbit-clients.cfg so the Xymon server knows what to look for in the file data sent by the client. So: client-local.cfg defines what raw data is collected by the client, and hobbit-clients.cfg defines how to analyze them.
When clients connect to the Xymon server to send in their client data, they will receive part of this file back from the Xymon server. The configuration received by the client is then used the next time the client runs.
This method of propagating the configuration means that there is a delay of up to two poll cycles (i.e. 5-10 minutes) from a configuration change is entered into the client-local.cfg file, and until you see the result in the status messages reported by the client.
Apart from the section delimiter, the file format is free-form, or rather it is defined by the tools that make use of the configuration.
log:/var/log/messages:10240
ignore MARK
trigger Oops
The log:FILENAME:SIZE line defines the filename of the log, and the maximum amount of data (in bytes) to send to the Xymon server. FILENAME is usually an explicit full-path filename on the client. If it is enclosed in backticks, it is a command which the Xymon client runs and each line of output from this command is then used as a filename. This allows scripting which files to monitor, e.g. if you have logfiles that are named with some sort of timestamp.
The ignore PATTERN line (optional) defines lines in the logfile which are ignored entirely, i.e. they are stripped from the logfile data before sending it to the Xymon server. It is used to remove completely unwanted "noise" entries from the logdata processed by Xymon. "PATTERN" is a regular expression.
The trigger PATTERN line (optional) is used only when there is more data in the log than the maximum size set in the "log:FILENAME:SIZE" line. The "trigger" pattern is then used to find particularly interesting lines in the logfile - these will always be sent to the Xymon server. After picking out the "trigger" lines, any remaining space up to the maximum size is filled in with the most recent entries from the logfile. "PATTERN" is a regular expression.
linecount:/var/log/messages
diskerrors:I/O error.*device.*hd
badlogins:Failed login
file:/var/log/messages[:HASH]
The file:FILENAME line defines the filename of the file to monitor.
As with the "log:" entries, a filename enclosed in backticks means a
command which will generate the filenames dynamically. The optional
[:HASH] setting defines what type of hash to compute for the file:
md5, sha1 or rmd160. By default, no hash is calculated.
NOTE: If
you want to check multiple files using a wildcard, you must use
a command to generate the filenames. Putting wildcards directly into
the file: entry will not work.
dir:DIRECTORYNAME
The dir:DIRECTORYNAME line defines the filename of the file to monitor.
As with the "log:" entries, a filename enclosed in backticks means a
command which will generate the filenames dynamically. The Xymon client
will run the
du(1)
command with the directoryname as parameter, and send the output back to the
Xymon server.
NOTE: If you want to check multiple directories using a
wildcard, you must use a command to generate the directory names. Putting
wildcards directly into the dir: entry will not work. E.g. use something
like
dir:`find /var/log -maxdepth 1 -type d`
The "du" command used can be configured through the DU environment
variable. On some systems, by default du reports data in disk blocks
instead of KB (e.g. Solaris). So you may want to configure the Xymon client
to use a du command which reports data in KB, e.g. by setting
DU="du -k"
in the hobbitclient.cfg file.
Use of the directory monitoring on directory structures with a large number of files and/or sub-directories can be quite ressource-intensive.