[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: monit and xmpp notifications
From: |
Jan-Henrik Haukeland |
Subject: |
Re: monit and xmpp notifications |
Date: |
Wed, 1 Dec 2004 18:47:56 +0100 |
On Dec 1, 2004, at 4:40 PM, Dirk-Jan C. Binnema wrote:
On Wed, Dec 01, 2004 at 15:57 (+0100), Jan-Henrik Haukeland wrote:
Well, the 'exec' above is ok, but it seems you can have only one
statement after 'then' (is that true?). So, I would need to do the
whole
thing again (not sure about the exact syntax)
if c1 then exec "echo \"restarting bla\" | sendxmmp -s warning
address@hidden"
if c1 then restart
This seems a bit funny, esp. as c1 may change between the two tests.
I'm not so worried about changes in c1 though but yeah it's funny in a
bad way. It is true that only one statement is allowed after "then"
which is meaningful since the available statements don't mix easily.
BTW, you cannot use pipe in the exec statement, it's not a shell but a
plain exec(3). It's equal to the exec command you have in your shell.
In this particular case you could maybe write something like
exec "sendxmmp -s 'warning $MONIT_EVENT address@hidden'"
I.e. a way to write a small C-stub to delegate the alert
functionality.
Not sure how this interface will look in practice but I think the idea
is interesting since there are lots of other alert transport
mechanisms
than SMTP today. I'm interested to know what others think about such
an
idea. What should be the input and output parameters to such a stub
etc?
You mean loading external code into monit?
Sort of, kind of like an extension ala filters in apache if you are
familiar with that technology.
Today this is possible for protocol tests in monit. You could write a
function to test a protocol not supported by monit and compile monit to
use this function. If you look in the sub-directory protocols/ and read
the NOTES file it is explained there. The "interface" is not as easy as
it should be but never the less it is used. In fact many of the
protocol tests available with monit are contributed by users of monit.
To write your own protocol test function you must use a fixed signature
for the function which looks like this "int(*check)(Socket_T)". What I
was proposing was to add a interface so you could write your own
alert-function. The function could take a general Message_T object
which it utilize to send the alert message over whatever protocol. I.e.
the signature would look something like this: int(*alert)(Message_T).
The bottom line is that you could then write in monit's control file
stuff like:
set alert handler smtp and xmpp and snmp
so whenever monit issue an alert message it calls each of the defined
alert handlers with the same Message object. So if you write this in
monit's control file
if foo then alert
monit will send a SMTP mail, call xmpp (whatever that is:) and emit a
snmp event message. It should also be possible to specify a certain
alert handler in any if-test such as
if foo then alert over snmp
or in your case
if foo then alert xmpp [blablabla]
Anyway this is just an idea from the top of my head and I admit that I
haven't really thought it through..
That would certainly be
useful, but also a bit scary for the stability. Specialized blurbs of
C-code may not have enough users to iron out the bugs quickly.
Of course, the exec-thing can be dangerous to (I don't see a timeout
defined for the external program).
Timeout is not a problem for monit since it forks for each exec and
then continue right away with whatever it does.
Nevertheless, maybe globally alerter1="", alerter2="", etc. could be
defined (similar
to exec), which will all be run whenever monit wants to sends an alert,
and some interesting arguments in env vars.
Right! Lets see what the others think about it first. Feedback anyone?
--
Jan-Henrik Haukeland