1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<!-- $Id: moomps.htm,v 1.60 2005/02/22 18:49:25 jfontain Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Jean-Luc Fontaine">
<meta name="Description" content="user and reference manual for using moomps">
<title>moomps (Modular Object Oriented Multi-Purpose Service)</title>
</head>
<body bgcolor="#FFFFFF" style="font-family: helvetica, verdana, arial">
<center><h1>moomps</h1></center>
<center><h2>(Modular Object Oriented Multi-Purpose Service)</h2></center>
<h3>Contents:</h3>
<ul>
<li><a href="#about">1. About this document</a>
<li><a href="#introduction">2. Introduction</a>
<li><a href="#required">3. Required software</a>
<li><a href="#architecture">4. Architecture</a><ul>
<li><a href="#architecture.errors">4.1. Error handling</a>
</ul>
<li><a href="#installation">5. Installation</a><ul>
<li><a href="#upgrading">5.1. Upgrading</a>
</ul>
<li><a href="#usage">6. Usage</a>
<li><a href="#ha">7. High availability</a>
<li><a href="#faq">8. Frequently Asked Questions</a>
<li><a href="#misc">9. Miscellaneous information</a>
</ul>
<h3><a name="about"></a>1. About this document</h3>
<p>This document contains general and reference information to help the user understand the moomps application and its configuration.
<h3><a name="introduction"></a>2. Introduction</h3>
<p>Moomps is a monitoring daemon which works using configuration files created by the <a href="moodss.htm">moodss</a> (Modular Object Oriented Dynamic SpreadSheet) graphical application. The configuration files contain the definition of thresholds, which when crossed, create messages in the system log, and possibly trigger the sending of email alert messages or the execution of user defined scripts.
<p>It is also possible to use a database as a storage mean, so that data history is for example available for presentations and graphs, via commonly available spreadsheet software.
<p><i><b>Important</b>: if you have created a database using a moomps daemon prior to version 2.3, please follow the instructions in the <a href="database.htm#upgrade">upgrade</a> database section.</i>
<h3><a name="required"></a>3. Required software</h3>
<b>Prepackaged as rpms:</b>
<p>You will need: <i>moomps</i>, <i>moodss</i>, <i>tcl</i>, <i>tk</i>, <i>tktable</i> and <i>blt</i>, <i>tclx</i> and either (if you want to use the database archiving feature) <i>mysqltcl</i>, <i>tclodbc</i> or <i>sqlite</i> (file based SQL library).
<p>If you are using a Linux <b>Red Hat</b> system (7.0 or above), then use the moomps rpm file (available at <a href="http://moodss.sourceforge.net/">http://moodss.sourceforge.net/</a>) for installation. It requires the <i>tcl</i> and <i>tk</i> rpms (likely to be included in your distribution), <i>moodss</i> (available at <a href="http://jfontain.free.fr/">http://jfontain.free.fr/</a>), along with the <i>tclx</i> rpm (readily available) and either <i>mysqltcl</i> (available at <a href="http://www.xdobry.de/mysqltcl/">http://www.xdobry.de/mysqltcl/</a>) or <i>tclodbc</i> (available at <a href="http://jfontain.free.fr/">http://jfontain.free.fr/</a>). You need also moodss to be able to generate the moomps preferences and configuration files (see moodss <a href="moodss.htm">documentation</a>).
<br>Red Hat 8.0 and above unfortunately no longer provide <i>blt</i>, which you can find at <a href="http://jfontain.free.fr/">http://jfontain.free.fr/</a> instead.
<p>On a <b>Suse</b> system, <i>moodss</i>, <i>moomps</i> and all the packages they require are included in <b>Suse</b> 8.1 and above. The only missing parts (<i>mysqltcl</i> of <i>tclodbc</i>) can be found and used as described above.
<p>Finally, if you use moodss modules in a language other than Tcl, such as Perl or Python, you will need the <i>tclperl</i> or <i>tclpython</i> libraries, all available from <a href="http://jfontain.free.fr/">http://jfontain.free.fr/</a>.
<p><b>From source:</b>
<p>Otherwise, for other UNIX systems, grab the latest moodss tarball (at <a href="http://moodss.sourceforge.net/">http://moodss.sourceforge.net/</a>).
<p>For the current version (4.6), the following packages must be installed before attempting to install moomps:<ul>
<li>Tcl version 8.3.1 or above (at <a href="http://tcl.sourceforge.net/">http://tcl.sourceforge.net/</a>)
<li>TclX<b>*</b> version 8.2 or above (at <a href="http://sf.net/projects/tclx/">http://sf.net/projects/tclx/</a>)
<li>optionally, the latest moodss version (at <a href="http://moodss.sourceforge.net/">http://moodss.sourceforge.net/</a>), in order to be able to generate the moomps preferences and configuration files (which could come from another machine if you want to avoid installing moodss)
</ul>
<p>and, if you want to use the database history feature, either of the following:<ul>
<li>mysqltcl<b>*</b> package (at <a href="http://www.xdobry.de/mysqltcl/">http://www.xdobry.de/mysqltcl/</a>) for the MySQL database with connection via the native MySQL protocol
<li>sqlite<b>*</b> file based SQL library at <a href="http://www.hwaci.com/sw/sqlite/">http://www.hwaci.com/sw/sqlite/</a> (already included in moodss rpm)
<li>tclodbc<b>*</b> package (at <a href="http://tclodbc.sourceforge.net/">http://tclodbc.sourceforge.net/</a>) for MySQL, PostgreSQL, DB2, ... with connection via ODBC (Open DataBase Connectivity)
</ul>
<div align=right><b>*</b><i> many thanks to the authors for these great packages</i></div>
<p>The stooop (Simple Tcl Only Object Oriented Programming) library is included in the self contained <i>moomps</i> 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:<ul>
<li>stooop version 4.1 or above
<li>switched version 2.2 or above (included in the stooop distribution)
</ul>
<p>at <a href="http://jfontain.free.fr/">http://jfontain.free.fr/</a>, along with the source code for moodss, also required for development on moomps.
<p>Finally, if you use moodss modules in a language other than Tcl, such as Perl or Python, you will need:
<ul>
<li>tclperl library
<li>tclpython library
</ul>
<p>also at <a href="http://jfontain.free.fr/">http://jfontain.free.fr/</a>.
<h3><a name="architecture"></a>4. Architecture</h3>
<p>Moomps loads configuration files generated by moodss (.moo files created under the <i>File Save</i> 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).
<p>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.
<br>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.
<p>The poll time is kept independent for each configuration file.
<p>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 <i>syslog</i> manual for further information on the processing of importance levels).
<p>Examples of <i>syslog</i> entries:
<table bgcolor="#DFDFDF" width="100%"><tr><td><pre>
Mar 31 13:53:19 localhost moomps[817]: ./moomps 1.4 starting...
Mar 31 14:09:39 localhost moomps[878]: (info) "random: Bill xedit disk" = "380" (triggered "up" threshold "4")
Mar 31 13:52:53 localhost moomps[817]: ./moomps exiting...
</pre></td><tr></table>
<p>The application periodically checks loaded files for their modification time (also see the <i>-p</i> (<i>--poll-files-time</i>) option).
<br>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.
<br>Note that only the files loaded at startup time are checked.
<br>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.
<br>Whenever a configuration file is reloaded, a corresponding informational message is generated in the log.
<h4><a name="architecture.errors"></a>4.1. Error handling</h4>
<p>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.
<br><i><b>Note</b>: before moomps version 2.15, such errors would result in the core being halted.</i>
<h3><a name="installation"></a>5. Installation</h3>
<p><i><b>Note</b>: if you are upgrading from a moomps version before and including 2.1, make sure to read the <a href="#upgrading">upgrading</a> section.</i>
<p>Trivial if you are on a Red Hat system: install the <i>moomps</i> rpm (more information can be found in the INSTALL file).
<br>If you are on another UNIX compatible system, first install <i>moodss</i> (follow the INSTALL file instructions) and make sure that it runs properly.
<br><i><b>Note</b>: at this time, moomps does not run on Windows systems.</i>
<p>Then copy the <b>.moo</b> files (configuration files generated by moodss) that contain the thresholds and/or data cells to monitor, that you are interested in, into the <b>/etc/moomps/</b> directory (symbolic links also do the job).
<br>You may directly edit those files in place from moodss using the <i>File Open</i> menu.
<br><i><b>Note</b>: since the configuration files are in XML format, you may also (carefully) edit them by hand using any textual editor.</i>
<p>Then you should create global preferences (read <a href="#upgrading">this</a> if you are upgrading from a moomps version before and including 2.1), unless the following hard-coded default values suit you:<ul>
<li>thresholds email <b>From</b> address: current user name (generally <i>root</i> for a daemon)
<li>SMTP servers for outgoing messages: <i>localhost</i> only
</ul>
<p>In order to create a preferences file for moomps, launch the moodss application and edit the preferences, <i>daemon</i> section first, where you will choose the location of the moomps preferences file (<i>/etc/moomps/rc</i> by default).
<br>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.
<br><i><b>Note</b>: if you choose not to use the default for the moomps preferences file, make sure to use the <b>-r</b> option in the command line used to start moomps.</i>
<br><i><b>Note</b>: since the preferences file is in XML format, you may also (carefully) edit it by hand using any textual editor.</i>
<p>Then, from the moodss preferences, thresholds section, set the emails from address and the SMTP servers used to send the outgoing thresholds email messages.
<br><i><b>Note</b>: testing that the <b>from</b> account actually works for sending email is recommended prior to the first moomps launch. You may use the moomps <b>-m</b> command line option for that purpose.</i>
<p>Last, from the moodss preferences, optionally fill the database section, if you want to use that feature in moomps (see the <a href="database.htm#configuration">database configuration</a> section.).
<p><i><b>Note</b>: more help can also be obtained using the help button from the moodss preferences dialog box.</i>
<h4><a name="upgrading"></a>5.1. Upgrading</h4>
<p>After and including moodss version 16.8, all preferences and configuration files are saved in XML format.
<p>Moomps is backward compatible with old (non XML) format configuration (<b>.moo</b>) files.
<br><i><b>Note</b>: 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...</i>
<p><b>Important</b>:
<br>Unfortunately, as far the as the moomps <b>preferences</b> 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).
<h3><a name="usage"></a>6. Usage</h3>
<p>If you are on a Red Hat system and you installed the rpm, start the moomps daemon as any other service. For example:
<table bgcolor="#DFDFDF" width="100%"><tr><td><pre>
# service moomps start
</pre></td><tr></table>
<p>Related information, warning and errors messages are traditionally visible in <b>/var/log/messages</b>, under the <b>[moomps]</b> header.
<p>If you are on another UNIX system, just launch moomps using the command line switches for now.
<p>You can also start moomps from a terminal using the following options:
<table bgcolor="#DFDFDF" width="100%"><tr><td><pre>
$ 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
</pre></td><tr></table>
<p>After the options described above, specify any number of moodss generated configuration files (.moo files) or directories. For a directory, moomps will load all <i>.moo</i> files in that directory as if they were directly passed on the command line.
<p>The <i>-p</i> (<i>--poll-files-time</i>) 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.
<br>By default, files are checked every 60 seconds.
<br>Note that that time is also used to periodically set the modification time of the process identifier file (as in the UNIX <i>touch</i> command): see the <a href="#ha">high availability</a> section for an application.
<p>The <i>-m</i> (<i>--mailto</i>) 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.
<p>The <i>-r</i> option is used to specify a preferences (also known as resources) file other than the <i>/etc/moomps/rc</i> default. This can be useful if the moomps preferences file location is changed in the moodss preferences interface, daemon section.
<h3><a name="ha"></a>7. High availability</h3>
<p>The moomps daemon can stop, fail or hang for several reasons:<ul>
<li>a loaded module is hung in a system call (for example trying to access a remote resource), thereby hanging the daemon
<li>the moomps daemon itself is buggy: crashes or hangs (please make sure to report the problem in such a case)
<li>a loaded module contains a fatal bug and crashes, thereby crashing the daemon, although such cases should only result in a critical error reported in the log for the faulty module (<i>from moomps version 2.15</i>)
</ul>
<p>Using the UNIX <i>cron</i> 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):
<p><table bgcolor="#DFDFDF" width="100%"><tr><td><pre>
*/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 \;
</pre></td><tr></table>
<h3><a name="faq"></a>8. Frequently Asked Questions</h3>
<h4>Q: How do I make the moomps daemon store some data cells history in the database?</h4>
<p><b>A</b>: Here is the road map from start to finish:<ul>
<li>allow access to the database by properly filling the preferences <a href="#preferences.database">database</a> section (note that as a database user, you must have write access to the moodss database (contact your database administrator if in doubt)).
<li>try your configuration by using the file database <a href="#menus.file.database.load">load</a> menu: that should give you no errors provided the <i>moodss</i> database exists and your database user is valid, else contact your database administrator and restart the procedure until it works.
<li>in the preferences <a href="#preferences.moomps">daemon (moomps)</a> section, choose the configuration file that the moomps daemon will use (of course you must have write access to that file) and validate: the database configuration is then saved for moomps to use when saving data cells histories (all see the moomps <a href="moomps.htm">documentation</a>).
<li>use an existing configuration (save) file, or load modules, ..., use the edit <a href="#menus.edit.database">database</a> menu and drop data cells in the dialog box that opens.
<li>save the configuration (file <a href="#menus.file.save">save</a> menu) in the moomps directory for configuration files (<i>/etc/moomps/rc</i> by default, of course you must have write access to it).
<li>start or restart the moomps daemon (you may also dynamically modify configuration files already loaded by a running moomps daemon: the modifications will be taken into account shortly thereafter)
<li>after a while, check that the data is actually stored from the file database <a href="#menus.file.database.load">load</a> menu.
</ul>
<h4>Q: What happens if files are changed, deleted, added, ... in the directory that the moomps daemon is using for its configuration files?</h4>
<p><b>A</b>: If a configuration file that is monitored by moomps (see configuration files and directory parameters in the <a href="#usage">usage</a> section), is:<ul>
<li><b>changed</b>: it is reloaded as soon as the daemon becomes aware of its recent modification time (depending on the monitoring poll time of the configuration files, as described in the <a href="#usage">usage</a> section).
<li><b>deleted</b>: nothing happens (the moomps daemon does not unload the file, it needs to be restarted to take the change into account).
<li><b>added</b> to the monitored directories: nothing happens for security reasons (the moomps daemon does not load the file, it needs to be restarted to take the change into account).
</ul>
<h4>Q: What happens when, in the moodss GUI edit database dialog box, some data cells state is changed, and the moomps daemon is running?</h4>
<p><b>A</b>: 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 <a href="#usage">usage</a> section).
<br>Thus such changes are taken into account quickly (depending of course on the monitoring poll time of the configuration files, as described in the <a href="#usage">usage</a> section).
<h3><a name="misc"></a>9. Miscellaneous information</h3>
<p>Please report bugs to <a href="news:comp.lang.tcl">comp.lang.tcl</a> or <a href="mailto:jfontain@free.fr">jfontain@free.fr</a>.
</body>
</html>
|
