Re: monit SMTP

[Michael Shigorin]

On Sat, Feb 14, 2004 at 02:08:18PM +0100, Jan-Henrik Haukeland wrote:
> > 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

Well either "exec" wasn't the case in 3.x (3.2?), or I was
completely ignorant even then -- but had to piggyback by means of
start.

And frankly, it seems to me that it's { messaging } that makes
sense being generalized, not putting in a pile of exec's.  IOW if
we have some more sophisiticated mechanisms like "AND ALERT ON
COMEBACK" (tm), would be nice to be able to define *what's* that
ALERT "macro", and what message to emit -- since doing it by
hand we'll mostly find ourselves copying-and-pasting exec lines.

That's quite bad if delivery address/number/whatever changes, or
you move the rc to another host and modify it accordingly.  And
in general. :)

> (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)

Uhh... Jan, but it *is* a kludge.

What if "alert" would expand to some programmable chain of events
being triggered?  "(exec that && mail this) || exec this2"? ;-)

Maybe better yet, 

set alert-target admin1 {
        mail {
                mailto: root@
                subject: [monit] -- $PROGRAM $EVENT on $HOST at $DATE
                message:
        } || $transport {
                $hook_from_another_transport: $value
                ...
        } ...
}

...and then "alert admin1"?

(that can be sectionized further but no point here until there's
a bunch of reasonable and generic transports, if it ever is)

> > 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/

Generally "to setup" and "to package" are somewhat different.
There may be a lot of pain to package something up (the brightest
example known is OpenOffice.org), but setting up both tarball and
ready package can be a breeze.

> > - 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.

Ugh.  Igor told me once upon a time that it was scheduled for 4.x
when I bugged him regarding exaclt apache IIRC :-)

> 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).
> http://mail.nongnu.org/archive/html/monit-dev/2004-01/msg00004.html

Great; will try to look into.  But isn't it actually worth it to
get _separate_ per-service parts as the default approach?

Then you can put them in examples/ so that even with hand-made
installations people can just pick out and copy in place needed
files and not macro#ize all the unneeded records while
uncommenting the precious ones :)

Actually, we can try this proposed scheme in ALT's build of monit
(I bet we'll negotiate that with Igor :) and come back with field
results.

> > - 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.

BTW regarding plugins: tests are something that cries for that.
That's the way we can "eat" quite expensive tests (better
implemented with "expensive" libraries) and have it lean.

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

Well then OK :-)

PS: sorry for long turnarounds, things are busy here, too.

-- 
 ---- WBR, Michael Shigorin <address@hidden>
  ------ Linux.Kiev http://www.linux.kiev.ua/

pgpI5iIMZfcvT.pgp
Description: PGP signature