You have the choice of creating a single config file, or a directory of separate config files, which are effectively concatenated together.
The later is useful so that different parts can be generated by different people or different scripts.
For example, the author has one file for each of: unix servers, NT servers, routers, terminal servers, BGP sessions, T1 connections, DSL connections, etc. Certain files are built by scripts from a database, and others are maintained by people.
The application will automatically notice if a config file changes and will reload.
The config file defines what and how things are monitored as well as the layout and relationships of the various items.
It contains both lines of key-value pairs, and grouping constructs
In (rough) EBNF:
file : fileentry + fileentry : data | group | alias data : key ':' value alias : 'Alias' "label" "name" group : 'Group' "label" '{' groupdata + '}' groupdata : data | group | alias | service service : 'Service' type [ '{' data + '}' ]Important bits: a "service" is something that actually gets monitored, "groups" define the hierarchy and relationships (most obviously being the layout of the web pages), "data" define various bits of, well, data, that adjust behavior, layout, or operation.
There are an extremely large number of parameters (data) that can be (or need to be) defined. In general, everything tries to default to reasonable and "Do What I Mean" values.
There is an auto-generated list of all of the parameters, etc, here
Probably good to show an example:
syslog: local1 notify: mail:staff@example.com Group "Servers" { Group "mail" { hostname: mail.example.com Service TCP/SMTP Service TCP/IMAP Service UDP/DNS Service Ping } Group "www" { hostname: www.example.com Service TCP/HTTP Service TCP/HTTPS Service Ping Service TCP { port: 12345 info: YoyoDyne Application Server } } }