This document contains general and reference information to help the user understand the moomps application and its configuration.
Moomps is a monitoring daemon which works using dashboard (.moo) files created by the moodss (Modular Object Oriented Dynamic SpreadSheet) graphical application. It monitors objects defined within the dashboard files. It loads moodss modules, without using a GUI, to perform all the activities defined within moodss dashboard files except for displaying and graphing data (graph definitions are ignored), and predicting data behavior (in the current version). For example, it can:
Moomps can load an unlimited number of dashboard files (.moo) created by the moodss GUI and automatically and dynamically reloads them when it detects they have been modified.
Using moodss with moomps can provide the following benefits:
Important: if you have created a database using a moomps daemon prior to version 2.3, please follow the instructions in the upgrade database section.
You will need: moomps, moodss, tcl, tk, tktable and blt, tclx and either (if you want to use the database archiving feature) mysqltcl, tclodbc or sqlite (file based SQL library).
If you are using a Linux Red Hat system (7.0 or above), then use the moomps rpm file (available at http://moodss.sourceforge.net/) for installation. It requires the tcl and tk rpms (likely to be included in your distribution), moodss (available at http://jfontain.free.fr/), along with the tclx rpm (readily available) and either mysqltcl (available at http://www.xdobry.de/mysqltcl/) or tclodbc (available at http://jfontain.free.fr/). You need also moodss to be able to generate the moomps preferences and configuration files (see moodss documentation).
Red Hat 8.0 and above unfortunately no longer provide blt, which you can find at http://jfontain.free.fr/ instead.
On a Suse system, moodss, moomps and all the packages they require are included in Suse 8.1 and above. The only missing parts (mysqltcl of tclodbc) can be found and used as described above.
Finally, if you use moodss modules in a language other than Tcl, such as Perl or Python, you will need the tclperl or tclpython libraries, all available from http://jfontain.free.fr/.
Otherwise, for other UNIX systems, grab the latest moodss tarball (at http://moodss.sourceforge.net/).
For the current version (5.8), the following packages must be installed before attempting to install moomps:
and, if you want to use the database history feature, either of the following:
The stooop (Simple Tcl Only Object Oriented Programming) library is included in the self contained moomps application file. Therefore, it is not required to install the stooop package, unless you want to work on the moomps source code itself. However, should you want to get more information on those extensions, you will find the latest versions:
at http://jfontain.free.fr/, along with the source code for moodss, also required for development on moomps.
Finally, if you use moodss modules in a language other than Tcl, such as Perl or Python, you will need:
also at http://jfontain.free.fr/.
Moomps loads configuration files generated by moodss (.moo files created under the File Save menu). Such files contain the name of the moodss module to load, optionally a list of data cells whose history over time is to be stored in a database (defined in the moodss GUI from the Edit Database menu), and any number of thresholds (defined under moodss using drag and drop or the Thresholds menu).
When running, moomps periodically store data cells values in the database, checks the threshold conditions and possibly send email alerts to the addresses defined for those thresholds, or execute user defined scripts.
If storing data cells history in a database, while recording, errors, such as disconnections when the database server becomes unreachable, are handled by gracefully disconnecting and retrying to connect at each update, thus greatly enhancing reliability.
The poll time is kept independent for each configuration file.
When a threshold is crossed, a corresponding message is generated in the system log with the importance level (in parentheses) preset in the moodss thresholds interface (also see syslog manual for further information on the processing of importance levels).
Examples of syslog entries:
Mar 31 13:53:19 localhost moomps: ./moomps 1.4 starting... Mar 31 14:09:39 localhost moomps: (info) "random: Bill xedit disk" = "380" (triggered "up" threshold "4") Mar 31 13:52:53 localhost moomps: ./moomps exiting...
The application periodically checks loaded files for their modification time (also see the -p (--poll-files-time) option).
If any loaded file is modified while the application is running, moomps will detect it and reload that particular file, forgetting the previous configuration defined by that file. For example, it is then possible to load a configuration file in moodss, change a few threshold values, the poll time, ... and have it automatically taken into account by moomps once that configuration file is saved in moodss.
Note that only the files loaded at startup time are checked.
For example, if some of moodss arguments are directories, only the configuration files in those directories present at moomps startup time are checked. That means that files deleted or added (for safety reasons) to those directories are ignored during the lifetime of the application.
Whenever a configuration file is reloaded, a corresponding informational message is generated in the log.
Whenever an unexpected error occurs in a module (either by unforeseen conditions or coding bugs), the corresponding error message, tagged as critical, is written to the log (or the standard error output in foreground mode), including a source code error trace if in debug mode.
Note: before moomps version 2.15, such errors would result in the core being halted.
Note: if you are upgrading from a moomps version before and including 2.1, make sure to read the upgrading section.
Trivial if you are on a Red Hat system: install the moomps rpm (more information can be found in the INSTALL file).
If you are on another UNIX compatible system, first install moodss (follow the INSTALL file instructions) and make sure that it runs properly.
Note: at this time, moomps does not run on Windows systems.
Then copy the .moo files (configuration files generated by moodss) that contain the thresholds and/or data cells to monitor, that you are interested in, into the /srv/moomps/ directory (symbolic links also do the job).
You may directly edit those files in place from moodss using the File Open menu.
Note: since the configuration files are in XML format, you may also (carefully) edit them by hand using any textual editor.
Then you should create global preferences (read this if you are upgrading from a moomps version before and including 2.1), unless the following hard-coded default values suit you:
In order to create a preferences file for moomps, launch the moodss application and edit the preferences, daemon section first, where you will choose the location of the moomps preferences file (/etc/moomps/rc by default).
Then, when you validate the preferences from the moodss user interface, the variables relevant to the moomps application will be saved in the chosen moomps preferences file.
Note: if you choose not to use the default for the moomps preferences file, make sure to use the -r option in the command line used to start moomps.
Note: since the preferences file is in XML format, you may also (carefully) edit it by hand using any textual editor.
Then, from the moodss preferences, thresholds section, set the emails from address and the SMTP servers used to send the outgoing thresholds email messages.
Note: testing that the from account actually works for sending email is recommended prior to the first moomps launch. You may use the moomps -m command line option for that purpose.
Last, from the moodss preferences, optionally fill the database section, if you want to use that feature in moomps (see the database configuration section.).
Note: more help can also be obtained using the help button from the moodss preferences dialog box.
After and including moodss version 16.8, all preferences and configuration files are saved in XML format.
Moomps is backward compatible with old (non XML) format configuration (.moo) files.
Note: you can always convert those to the XML format by loading them in moodss and saving them again, after having made a backup copy, just in case...
Unfortunately, as far the as the moomps preferences file goes, moomps has no way to tell whether it is a valid moomps preferences file in the old format or not. You must therefore move or possibly delete the old references file before re-entering the moomps related data in the preferences dialog box of the moodss graphical application (thresholds, daemon and possibly database sections).
If you are on a Red Hat system and you installed the rpm, start the moomps daemon as any other service. For example:
# service moomps start
Related information, warning and errors messages are traditionally visible in /var/log/messages, under the [moomps] header.
If you are on another UNIX system, just launch moomps using the command line switches for now.
You can also start moomps from a terminal using the following options:
$ moomps -h Usage: ./moomps [OPTION]... [DIRECTORY|CONFIGURATIONFILE]... --debug module errors verbose reporting -f, --foreground run in foreground as opposed to daemon mode -h, --help display this help and exit -m, --mailto send an email to specified address at startup -p, --poll-files-time loaded files monitoring poll time in seconds --pid-file file containing the daemon process ID -r preferences file name --version output version information and exit
After the options described above, specify any number of moodss generated configuration files (.moo files) or directories. For a directory, moomps will load all .moo files in that directory as if they were directly passed on the command line.
The -p (--poll-files-time) option defines the length of the periodic checking of loaded files modification times. A zero value cancels any checking, and implies restarting moomps for changes in loaded files to be taken into account.
By default, files are checked every 60 seconds.
Note that that time is also used to periodically set the modification time of the process identifier file (as in the UNIX touch command): see the high availability section for an application.
The -m (--mailto) option is used with a valid email address (the software will do a basic validity check and possibly report an error). A test message will be sent to that address at startup time, so that the application email capability can be validated.
The -r option is used to specify a preferences (also known as resources) file other than the /etc/moomps/rc default. This can be useful if the moomps preferences file location is changed in the moodss preferences interface, daemon section.
The moomps daemon can stop, fail or hang for several reasons:
Using the UNIX cron facilities, it is possible to restart the moomps daemon when it crashes (by monitoring whether it is actually running), or restart it when it is hung (by monitoring whether the process identifier file has not been recently refreshed), as the following examples show (taken from a Linux Red Hat system, with automatic restart of a crashed daemon in less than 5 minutes, and automatic restart of a hung daemon in less than 7 minutes):
*/5 * * * * root /etc/init.d/moomps status | fgrep -q 'is running...' || /etc/init.d/moomps start */7 * * * * root find /etc/moomps/moomps.pid ! -cmin -5 -exec /etc/init.d/moomps restart \;
A: Here is the road map from start to finish:
A: If a configuration file that is monitored by moomps (see configuration files and directory parameters in the usage section), is:
A: Once the states are changed, the edit database dialog closed and the configuration file saved using the File/Save menu, the moomps daemon sees that the file has been updated and reloads it, provided of course that the file is part of the configuration files that the daemon is monitoring (see configuration files and directory parameters in the usage section).
Thus such changes are taken into account quickly (depending of course on the monitoring poll time of the configuration files, as described in the usage section).
Please report bugs to comp.lang.tcl or firstname.lastname@example.org.