Chapter 3. Configuring MonAMI

Table of Contents

3.1. Structure of a configuration file.
3.2. The [monami] stanza.
3.2.1. Logging Messages from MonAMI
3.2.2. Dropping root privileges
3.2.3. Auxiliary configuration file directories
3.2.4. Attributes
3.3. Features common across plugins
3.3.1. The name attribute
3.3.2. The cache attribute
3.3.3. The map attribute
3.3.4. Estimating future data-gathering delays
3.4. Monitoring Plugins
3.4.1. AMGA
3.4.2. Apache
3.4.3. dCache
3.4.4. Disk Pool Manager (DPM)
3.4.5. Filesystem
3.4.6. GridFTP
3.4.7. Maui
3.4.8. MySQL
3.4.9. null
3.4.10. NUT
3.4.11. Process
3.4.12. Stocks
3.4.13. TCP
3.4.14. Tomcat
3.4.15. Torque
3.4.16. Varnish
3.5. Reporting plugins
3.5.1. filelog
3.5.2. FluidSynth
3.5.3. Ganglia
3.5.4. GridView
3.5.5. grmonitor
3.5.6. KsysGuard
3.5.7. MonALISA
3.5.8. MySQL
3.5.9. Nagios
3.5.10. null
3.5.11. SAM
3.5.12. Snapshot
3.5.13. R-GMA
3.6. sample
3.6.1. The read attribute
3.6.2. Timed sample targets
3.6.3. Named vs Anonymous samples.
3.6.4. Adaptive monitoring
3.6.5. Sample attributes
3.7. Configuring Event-based Monitoring
3.7.1. dispatch
3.8. Example configurations
3.8.1. On-demand monitoring example
3.8.2. Polling monitoring example
3.8.3. Event monitoring example
3.8.4. A more complex example

MonAMI looks for the configuration file monami.conf. It will first look for this file in the /home/paul/MonAMI-test-install/etc directory. If monami.conf is not found there, the program will check the current directory. If the configuration file still cannot be found, MonAMI will exit with error code 1.

The configuration file can describe four things:

As will be discussed later, it is possible to split parts of MonAMI configuration into different files. This allows a set of monitoring definitions to be stated independently of other monitoring activity, which may prove useful when MonAMI is satisfying multiple groups requiring monitoring of services.

3.1. Structure of a configuration file.

Comments can be included by starting a line with the hash (#) symbol. White space (consisting of space or tab characters) before the hash symbol is allowed in comment lines.

Each configuration file is split into multiple stanzas (or sections). Each stanza has a section title line followed by zero or more attribute lines.

A section title is a line containing a word in square brackets ("[mysql]" for example). The case used for the section title does not matter: "[MySQL]", "[mysql]" and "[mySQL]" can be used interchangeably.

All lines following a section title line until the next section title line (or the end of the file) must be either a blank line, a comment line or an attribute line. Attribute lines are keyword-value pairs separated by an equals symbol ("="), for example:

name = myMonitor

White space at the start of the line, either side of the equals symbol and at the end of the line is ignored. Other white space, if significant, is preserved.

If a line ends with a back-slash symbol ("\") then that line and the one following it are combined into a single line. This can be repeated, allowing a single very long line to be broken into several shorter (and more manageable) lines; each of the shorter lines, except the last one, must end with a back-slash symbol.

Example configuration files are include in Section 3.8, “Example configurations”.

The following sections describe the different sections that may appear in a configuration file, along with the valid assignment lines that further refine MonAMI behaviour.