monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit SMTP


From: Jan-Henrik Haukeland
Subject: Re: monit SMTP
Date: Sat, 14 Feb 2004 14:08:18 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Reasonable Discussion, linux)

Michael Shigorin <address@hidden> writes:

> But it's one of the things that was surprising: emphasizing on
> e-mail and having no hooks for other transports.

Email is simple to do, besides since you can call whatever you want in
a start, stop or exec statement you _do_ have the option to call an
external notification program as illustrated here:
  http://www.tildeslash.com/monit/presentation/img12.html
(So if you don't want monit to send mail on error, just remove the
alert statement in monitrc and handle this yourself by calling an
external program, e.g. a SMS gateway in an exec statement)

>> In other words the current SMTP agent in monit is good enough.
>
> OK, agreed.  *If* it's just another "transport" which can be
> talked to in some simple and consistent manner. :)

It is.

>> Finally, an interesting point is that m/monit is sailing up to
>> become a good alternative to take over many of the more
>> enterprise issues, such as reporting and statistics and so on.
>
> Ummm... well when talking on enterprise issues/focus, we're
> definitely not down to "configure && make && sudo make install"
> but rather to distributions.

There is that, but I think you will be suprised how easy m/monit will
be to setup. Check out the preliminary version at
http://www.tildeslash.com/monit/mmonit/

> Supporting some packages in ALT Linux for some two+ years
> (http://altlinux.org/?module=sisyphus&packager=mike).

That was a lot of packages :)

> I'd like to propose these items for your considerations:
>
> - general "modularization", just along the way with m/monit:
>   alert transports should be seperated to allow (all in
>   reasonably consistent manner):

See above.

>   * adding new ones;
>   * reconfiguring existing (e.g. builtin/wrapped SMTP modules);
>   * using several transports to get the message out

See above.

> - modular/SysV-style config file -- e.g. /etc/monitrc.d/
>   where you can drop files from respective packages like apache.

A good idea! We (Rory) have thought about something like this a long
time ago but it got lost on the way. But with Christians new and
improved changes to the parser, with the ability to read in external
files this should now be supported (or to tweak it). See
 http://mail.nongnu.org/archive/html/monit-dev/2004-01/msg00004.html

> - maybe it's worth communicating with colleagues focusing on
>   networked monitoring (nagios, moodss) to find whether
>   cooperation and mutual support is feasible.

Well, with the new upcomming XML (and snmp) support it should at least
be easier for someone who would want to write a monit pluggin for
e.g. nagios.

> If it doesn't sound too absurd then would be glad to continue
> such architectural/integrational ranting ;-)

It's always good to have people with ideas around and you are most
welcome to keep on "ranting".

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]