I think maybe we can save some configuration file size and make it
more clear, if we'll use syntaz as following:
check ...
# method definition section
method start "/etc/init.d/apache start" exec on { start }
method stop "/etc/init.d/apache start" exec on { stop }
method reload "kill -HUP $MONIT_PROGRAM_PID"
method shutdown "/sbin/shutdown -t 1 bye, bye"
method foo "/bin/xzz -option 1 ... -option N argument1.. argumentN"
method bar "/bin/xyz -option 1 ... -option N argument1.. argumentN"
exec on {
timeout, restart, checksum, resource }
# tests definition section
if timestamp /usr/local/apache/conf/httpd.conf was changed then exec
reload
if cpu usage > 80% then exec foo
if cpu usage > 99% then exec shutdown
It separates method definition and allows to use different methods for
different condition "levels" of events (see last two lines of above
example). You can then make different actions for the same event
appropriate to situation.
It could be usefull for example in device checks - if the space usage
is growing and is above for example 80% watermark, you can call method
to purge some temporary or not important files (cores, etc.) or to
compress/move them (it can be done on regular basis by cron, but monit
could be used as fast reaction system for unusual situations such,
where the filesystem is fullfiled and cron job is planned to
midnigth). However if first method didn't helped, space usage grows
and stop method could be called in the case that it exceedes 99% to
gracefully stop services and defend catastrophal situation. This is
just example for device checks - another cases are usefull for other
monit tests (timestamp, etc.)
I didn't though about implementation, so it probably could be lot of
work (redesigning present start/stop program system). I thing it isn't
needed in such case to change present alert statement (exec could be
standalone list).
What about it?
Cheers,
Martin
Jan-Henrik Haukeland wrote:
Hi
I'm working with the external command function. It's a bit complicated
to integrate this. You may rememeber that we originally planned to
first include this in an alert statement like: alert `/bin/xyzzy .. `
After hacking around in the monit code I think it is a better idea to
create a standalone statement for this. This statement can then also
be combined with other statements as a regular action.
The new statement can be called 'exec' and will look much like the
alert statement in standalone form. Here's the syntax:
EXEC program [{events}]
An example in free-form would look like:
check ...
exec "/bin/xyzzy -option 1 ... -option N argument1.. argumentN" on {
timeout, restart, checksum, resource, stop, timestamp }
Coupled with on of the "if" tests it would look like (notice that
[{events}] will not be a part in this context):
if timestamp /usr/local/apache/conf/httpd.conf was changed then exec
"/bin/xyzzy -option 1 ... -option N argument1.. argumentN"
if cpu usage > 99% then exec "/sbin/shutdown -t 1 bye, bye"
ACTIONS:
-------
1) Implementing this will make use of all the calls to smtp_alert_xxx
and
the smtp_alert(Service_T s, int event, char *optmsg, va_list ap)
function that now dispatch alerts will have a test equal to the
maillist test for execs as in this function skeleton:
static void smtp_alert(Service_T s, int event, char *optmsg, va_list
ap) {
ASSERT(s);
if(s->maillist) {
for(all objects in s->maillist)
if(event == maillist[i].events) then
do smtp alerts }
NEW:
if(s->execlist) {
for(all objects in s->execlist)
if(event == execlist[i].events) then
do spawn program
}
}
2) Since alert.c will be used in a more general term I suggest that we
change the function names from smtp_alert_xxx to simply alert_xxxx
3) Change the Mail_T object and extract the events into a standalone
object so they can be reused in the new Exec_T object. Changes:
/** Defines a mailinglist object */
typedef struct mymail {
char *to; /**< Mail address for alert
notification */
char *from; /**< The mail from
address */
char *subject; /**< The mail
subject */
char *message; /**< The mail
message */
char *opt_message; /**< An optional message used in
alerts */
int alert_on_timeout; /**< If TRUE, alert user when service
timeout */
int alert_on_restart; /**< If TRUE, alert user when the service
restarts */
int alert_on_checksum; /**< If TRUE, alert user when the
checksum fail */
int alert_on_resource; /**< If TRUE, alert user when resources
exceed */
int alert_on_stop; /**< If TRUE, alert user when service
stopped */
int alert_on_timestamp; /**< If TRUE, alert user when the
timestamp fail */
/** For internal use */
struct mymail *next; /**< next recipient in
chain */
} *Mail_T;
is changed to:
/** Defines an alert object */
typedef struct myalert {
int alert_on_timeout; /**< If TRUE, alert user when service
timeout */
int alert_on_restart; /**< If TRUE, alert user when the service
restarts */
int alert_on_checksum; /**< If TRUE, alert user when the
checksum fail */
int alert_on_resource; /**< If TRUE, alert user when resources
exceed */
int alert_on_stop; /**< If TRUE, alert user when service
stopped */
int alert_on_timestamp; /**< If TRUE, alert user when the
timestamp fail */
} Alert_T;
/** Defines a mailinglist object */
typedef struct mymail {
char *to; /**< Mail address for alert
notification */
char *from; /**< The mail from
address */
char *subject; /**< The mail
subject */
char *message; /**< The mail
message */
char *opt_message; /**< An optional message used in
alerts */
Alert_T alerts; /*< Alerts defined for this mail
object */
/** For internal use */
struct mymail *next; /**< next recipient in
chain */
} *Mail_T;
And here is the new preliminary exec object:
/** Defines an alien program to execute upon alert or an action. */
typedef struct myexec {
Alert_T events; /**< Events triggering this program to be
executed */
Command_T program; /**< The external program
to call */
/** For internal use */
struct myexec *next; /**< next external program in
chain */
} *Exec_T;
4)
All this requires changes "all over the place" and if you have
anything to checkin please let me know now.
5) If someone feels for it a cleanup of monit.pod would be nice and also
adding a GRAMMAR SECTION defining the grammar would maybe also be nice
or what do you think?
Opinions on this plan, anyone?
_______________________________________________
monit-dev mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/monit-dev