Monitoring System Configuration

File Format

Most configuration files have the format described in this section. They consist of one or more sections. Sections consist of a name, an optional title string between brackets ('[', ']'), and the section body between angle brackets ('{', '}'). A hashmark ('#') indicates that the rest of the line is a comment. Example:

Common {
	# This is the section named "Common"
}

Module["load.so"] {
	# This is a section named "Module" with title "load.so"
}

Section names are case-independent, section titles are case-sensitive.

A section body might contain colon-terminated (';') variable definitions or other sections. A variable definition is a name-value pair separated by whitespace. Variable names must start with an ASCII letter and may contain letters and numbers. Variable names are case-independent. The supported value types:

Integer and double precision floating point numbers.
Strings between double quotes ('"'). A quote character inside the string itself must be escaped by a backslash ('\'), a backslash must be escaped by another backslash.
Boolean values: "yes" or "true" meaning true, "no" or "false" meaning false.

Example 1. Sample configuration fragment

Common {
	ModulePath "/usr/lib/monitor";
	AutoLoad no;
}

Module["hostsensor.so"] {
	Priority 10;
}

There is also a compact format for specifying a variable inside a section:

Common::ModulePath "/usr/lib/monitor";
Module["hostsensor.so"]::Priority 10;

Configuration Files

These are the base configuration files following the above described format:

libmonp.conf. Configuration of the consumer library libmonp.
lm.conf. Configuration of the Local Monitor.
mm.conf. Configuration of the Main Monitor.

Common Sections

The base configuration files may contain the following sections:

Common. The Common section contains configuration information for both the consumer and producer libraries. The following values are understood:

ModulePath (string). The directory name where the consumer or producer library will look for loadable modules. Default value: the module installation directory specified at compile time.
AutoLoad (boolean). If set to yes, modules found in the ModulePath directory will be loaded even if they are not mentioned in the configuration. If set to no, modules found are loaded only if there is a Module section with the same title as the name of the module, and it explicitly requests loading the module. Default value: true for the consumer library, false for the producer library.

Module. The Module sections contain configuration information for loadable modules. The only commonly recognized variable is the Load boolean value which specifies whether the module should be loaded or not. If there is no Load variable, the value of Common::AutoLoad decides whether the module will be loaded or not. Sensor modules have other common variables called Priority, External and User. Priority specifies a preference value as an int32 number. If more than one sensor modules provide the same metric, the one with the highest priority will be used. The External boolean variable specifies if the module should be loaded into a stand-alone process. The User string variable specifies a user account to run the external sensor as. All other variables are interpreted by the module itself.

Daemon. The daemon section contains configuration parameters for producer daemons. The following variables are understood:

PidFile (string). The name of the file where the daemon will store it's process id. Must be on a local filesystem.
LogTarget (string). Where to send log messages. The following formats are accepted:
- SYSLOG:[facility]: Send messages to syslog. If facility is missing, "daemon" is used.
- STDERR:: Send messages to the standard error.
- FILE:filename: Append messages to filename.
LogLevel (string). Only messages with a level of at least LogLevel will be logged. Possible values: debug, notice, info, warning, err.
LogIdent (string). Identity string to use in log messages.
Listen (string). URL to listen on for requests.
ExtSensorSocket (string). The filename of the Unix domain socket used by the ExtSensor interface.
AclFile (string). The name of the access control lists file which contains rules for authorisation. Default value: @sysconfdir@/acls.

Access Control List files

The monitoring system uses Access Control Lists (ACLs) to control what services users are allowed to use. ACL entries can allow or deny access to certain functions for certain users. The generic form of an ACL is:

permission object to requirements

Permission can be either allow or deny. When testing for access permission, ACLs are evaluated in the order they are defined. The result of the test is the permission value of the last ACL where object matches the requested operation and requirements matches the capabilities of the authenticated user entity. If there are no matching ACLs, permission is denied by default. There are two categories for object:

monitor metric name [metric parameters]
The ACL refers to the metric metric name. If the optional metric parameters list is also given, the ACL matches only if the parameters supplied by the user match the parameters listed in the ACL.
control control name [control parameters]
Likewise but for controls.

The requirements part is a boolean expression that can refer to the capabilities of the authenticated user entity and the parameters of the requested metric/control. Currently the following expressions are supported:

user user name
True if the authenticated user identity is user name

Example 2. Sample Access Control List file

allow monitor * to everyone;
deny control * to everyone;

allow monitor app.events to user "admin";

The `cluster_hosts` file

In a cluster environment the main monitor needs a list of URLs of local monitors in @sysconfdir@/cluster_hosts filled by the system administrator. The format of the cluster_hosts file is the following:

<hostname> <url of the local monitor on that host>

Example 3. Sample cluster_hosts file

frontend-node.cluster   monp://localhost:3571
node1.cluster           monp://node1.cluster
node2.cluster           monp://node2.cluster