[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

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

reply via email to

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