MonAMI provides messages containing information about events that occur during runtime. The destination of these messages is controlled by a set of configuration parameters that all begin with "log".

Each message has a severity; the four severity levels are:

The destination of messages (and whether certain messages are ignored) can be configured on the command line, or within the [monami] section of the configuration file.

Normally, a user is only interested in "critical" and "error" messages. If MonAMI is not working correctly, then examining the messages with "info" severity might provide a clue. Supplying the -v command-line option tells MonAMI to return info messages.

If MonAMI is running as a normal process (using the -f option), then critical and error messages are sent to standard error (stderr) and other message severity levels are ignored. If MonAMI is running verbosely (using the -v option) then info messages are sent to standard output (stdout), if running more verbosely (with -vv) then the debug messages are also sent to stdout.

If MonAMI is running as a daemon (i.e. without the -f command-line option) then, by default, critical and error messages are sent to syslog (using the "daemon" facility), info is ignored (unless running with the verbose option: -v) and debug is ignored (unless running more verbosely: -vv). Any messages generated before MonAMI has detached itself are either sent to stdout, stderr or ignored.

Other destinations are defined as follows:

Some examples:

[monami]
  # ignore all but critical errors
  log          = ignore
  log_critical = syslog

[monami]
  # store critical and error messages in separate files
  log          = ignore
  log_critical = /var/log/monami/critical.log
  log_error    = /var/log/monami/error.log

MonAMI needs no special privileges to run. In common with other applications, it is possible that some bug in MonAMI be exploitable and allow a local (or worse, remote) user to compromise the local system. To reduce the impact of this, it is common for an application to “drop” their elevated privileges (if running with any) soon after they start.

There are two options within the configuration file to control this: user and group. The user option tells MonAMI to switch its user-ID to that of the supplied user and to switch group-ID to the default group for that user. The group option overrides the user's default group, with MonAMI adopting the group-ID specified.

In the following example, the [monami] stanza tells MonAMI to drop root privileges and assume the identity of user monami and group monitors.

[monami]
  user  = monami
  group = monitors

Often, a server may have multiple services running concurrently. Maintaining a monolithic configuration file containing the different monitoring requirements may be difficult as services are added or removed.

To get around this problem, MonAMI will load all the configuration files that end .conf within a named directory (/home/paul/MonAMI-test-install/etc/monami.d). If a new service has been installed, additional monitoring can be indicated by copying a suitable file into the /home/paul/MonAMI-test-install/etc/monami.d directory. When the service has been removed the corresponding file in /home/paul/MonAMI-test-install/etc/monami.d can be deleted.

Auxiliary configuration directories are specified with the config_dir option. This option can occur multiple times in a [monami] stanza. For example:

[monami]
  config_dir = /etc/monami.d

Summary of possible attributes within the [monami] stanza: