The main configuration lives in monitor.ini in the same directory as the code.
Section names are lowercase in square brackets. Settings are defined as key=value. Lines can be commented with #.
Section names and option values (but not option names) support environment variable injection. To include the value of an environment variable, use
%env:VARIABLE%, which will inject the value of
$VARIABLE. You can use this to e.g. share a common configuration file across multiple hosts, but have each host name its monitors differently.
|interval||defines how many seconds to wait between running all the monitors. Note that the time taken to run the monitors is not subtracted from the interval, so the next iteration will run at
|monitors||defines the filename to load the monitors themselves from.||no||
|pidfile||gives a path to write a pidfile in.||no|
|remote||enables the listener for receiving data from remote instances. Set to 1 to enable.||no||0|
|remote_port||gives the TCP port to listen on for data.||if
|key||shared secret for validating data from remote instances.||if
|hup_file||a file to watch the modification time on, and if it increases, reload the config||no|
|bind_host||the local address to bind to listen for data.||no||all interfaces|
hup_file setting really exists for platforms which don’t have SIGHUP (e.g. Windows). On platforms which do, you should send the SimpleMonitor process SIGHUP to trigger a config reload.
Note: The config reload will pick up new, modified and removed monitors, loggers, and alerters. Other than the
interval setting, no other configuration options are reloaded. Note also that monitors, loggers and alerters cannot change type during a reload.
loggers lists (comma-separated, no spaces) the names of the loggers you have defined. (You can define loggers and not add them to this setting.) Not required; no default.
alerters lists the names of the alerters you have defined. Not required; no default.
If you do not define any loggers or alerters, then the only way to monitor the status of your network will be to watch the window the script is running in!
Monitors go in monitors.ini (or another file, if you changed the monitors setting above).
Let’s have a look at an example configuration.
What does this configuration do? Firstly, it only polls every minute. It has one logger, writing a logfile, and three alerters – two emails and one SMS.
The logfile is written to monitor.log and only contains failures.
An email is sent to firstname.lastname@example.org when a monitor fails. After a monitor has failed another four times, an email is sent to my boss. After it’s failed another five times (for a total of ten), I get an SMS.
Now we need to write our monitors.ini:
This is what it all means:
This example configuration contains several combinations of monitors you probably won’t use on the same server – particularly a diskspace check for a mounted partition (not a drive letter) and a Windows service monitor. I just put them all together here as an example :)