Xymon Mailing List Archive search

Generating alerts by non-xymon shell scripts

5 messages in this thread

list Deepak Deore · Mon, 22 Sep 2014 15:04:42 -0700 ·
Hi,

I have one shell script which generates apache allow,deny host file weekly,
tests the syntaxt by "apachectl -t", sends email if syntax errors.

If no syntax errors then push the file and to apache graceful restart and
then send success email.

Is there a way I can generate xymon alert instead of sending emails. Upon
success xymon status will be green and failure will generate red/ yellow.

I can do this by xymon scripts but wanted to check if there is simple way
to generate xymon alerts based on normal shell scripts which will avoid
emails and everything would be centralized to xymon.

Thanks,
Deepak
list Ryan Novosielski · Mon, 22 Sep 2014 19:23:28 -0400 ·
Sure. All custom tests basically do this by sending the correct line of text over to the Xymon server. Take a look at one. You also probably want to send a status lifetime to keep the test from turning purple in between executions (otherwise by default, the message is stale at 30m).

--
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS      |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | user-46c89e614701@xymon.invalid<mailto:user-46c89e614701@xymon.invalid>- 973/972.0922 (2x0922)
||  \\  Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
quoted from Deepak Deore
    `'

On Sep 22, 2014, at 18:05, deepak deore <user-7b03b2a1ee70@xymon.invalid<mailto:user-7b03b2a1ee70@xymon.invalid>> wrote:

Hi,

I have one shell script which generates apache allow,deny host file weekly, tests the syntaxt by "apachectl -t", sends email if syntax errors.

If no syntax errors then push the file and to apache graceful restart and then send success email.

Is there a way I can generate xymon alert instead of sending emails. Upon success xymon status will be green and failure will generate red/ yellow.

I can do this by xymon scripts but wanted to check if there is simple way to generate xymon alerts based on normal shell scripts which will avoid emails and everything would be centralized to xymon.

Thanks,
Deepak
list Deepak Deore · Mon, 22 Sep 2014 20:34:10 -0700 ·
Do we need to source xymonclient.cfg into normal shell scripts so that $BB
$BBDISP $MACHINE etc. variables will work?

On Mon, Sep 22, 2014 at 4:23 PM, Novosielski, Ryan <user-6e4f7a3bb37f@xymon.invalid>
quoted from Ryan Novosielski
wrote:
Sure. All custom tests basically do this by sending the correct line of
text over to the Xymon server. Take a look at one. You also probably want
to send a status lifetime to keep the test from turning purple in between
executions (otherwise by default, the message is stale at 30m).

--
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS      |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist

|| \\ and Health | user-46c89e614701@xymon.invalid- 973/972.0922 (2x0922)
quoted from Ryan Novosielski
||  \\  Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
    `'

On Sep 22, 2014, at 18:05, deepak deore <user-7b03b2a1ee70@xymon.invalid> wrote:

Hi,

I have one shell script which generates apache allow,deny host file
weekly, tests the syntaxt by "apachectl -t", sends email if syntax errors.

If no syntax errors then push the file and to apache graceful restart and
then send success email.

Is there a way I can generate xymon alert instead of sending emails. Upon
success xymon status will be green and failure will generate red/ yellow.

I can do this by xymon scripts but wanted to check if there is simple way
to generate xymon alerts based on normal shell scripts which will avoid
emails and everything would be centralized to xymon.

Thanks,
Deepak

list Jeremy Laidman · Tue, 23 Sep 2014 16:47:41 +1000 ·
quoted from Deepak Deore
On 23 September 2014 13:34, deepak deore <user-7b03b2a1ee70@xymon.invalid> wrote:
Do we need to source xymonclient.cfg into normal shell scripts so that $BB
$BBDISP $MACHINE etc. variables will work?

Not absolutely required, but depending on how clever you want to be, they
can be helpful.

To give you an idea, this might do what you want, without setting any
variables:

#!/bin/sh

cp /path/to/access-file /path/to/access-file.backup
printf "allow him\ndeny her\nallow from all\n" > /path/to/access-file
if apachectl -t >/dev/null; then
    # is OK
    apachectl graceful
    /usr/lib/xymon/client/bin/xymon 10.1.2.3 "status `uname -n`.apachecheck
green `date` everything's fine with apache"
else
    # is failed
    cp /path/to/access-file /path/to/access-file.bad
    cp /path/to/access-file.backup /path/to/access-file
     /usr/lib/xymon/client/bin/xymon 10.1.2.3 "status `uname
-n`.apachecheck red `date` something's not right with apache"
fi

Now the problem arises when you add a second Xymon server, or if you change
IP addresses of the Xymon server.  The 10.1.2.3 is no longer suitable.  So
that's when you want to define $XYMSERVERS="10.1.2.3 10.4.5.6" and then
specify 0.0.0.0 as the server instead of 10.1.2.3, and then the xymon
client will post messages to both servers as listed in the $XYMSERVERS
environment variable.

Then let's say you want to run the script on another Apache server, but it
has its Xymon client installed in a different location.  So you need to
have two versions of the script, one using /usr/lib/xymon/client/bin/xymon
and another using /usr/local/xymon/client/bin/hobbit.

etc

The easiest way to do this is to make use of the variables, and then either
the script within a xymoncmd wrapper (which sets all of the variables you
need) or from tasks.cfg (which can also set the variables you need).  You
end up with something like this:

     $XYMON $XYMSRV "status $MACHINE.apachecheck red `date` something's not
right with apache"

This works on any of your Xymon clients, no matter how they're setup.

Here's another idea.  You can have your script create a log entry using
"logger" and then have Xymon's log watching code detect the anomaly and
warn accordingly.

J
list Deepak Deore · Tue, 23 Sep 2014 10:31:33 -0700 ·
Thanks for the ideas Jeremy (as always :-) ), will check with the first
option.

On Mon, Sep 22, 2014 at 11:47 PM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
quoted from Jeremy Laidman
wrote:
On 23 September 2014 13:34, deepak deore <user-7b03b2a1ee70@xymon.invalid>
wrote:
Do we need to source xymonclient.cfg into normal shell scripts so that
$BB $BBDISP $MACHINE etc. variables will work?

Not absolutely required, but depending on how clever you want to be, they
can be helpful.

To give you an idea, this might do what you want, without setting any
variables:

#!/bin/sh

cp /path/to/access-file /path/to/access-file.backup
printf "allow him\ndeny her\nallow from all\n" > /path/to/access-file
if apachectl -t >/dev/null; then
    # is OK
    apachectl graceful
    /usr/lib/xymon/client/bin/xymon 10.1.2.3 "status `uname
-n`.apachecheck green `date` everything's fine with apache"
else
    # is failed
    cp /path/to/access-file /path/to/access-file.bad
    cp /path/to/access-file.backup /path/to/access-file
     /usr/lib/xymon/client/bin/xymon 10.1.2.3 "status `uname
-n`.apachecheck red `date` something's not right with apache"
fi

Now the problem arises when you add a second Xymon server, or if you
change IP addresses of the Xymon server.  The 10.1.2.3 is no longer
suitable.  So that's when you want to define $XYMSERVERS="10.1.2.3
10.4.5.6" and then specify 0.0.0.0 as the server instead of 10.1.2.3, and
then the xymon client will post messages to both servers as listed in the
$XYMSERVERS environment variable.

Then let's say you want to run the script on another Apache server, but it
has its Xymon client installed in a different location.  So you need to
have two versions of the script, one using /usr/lib/xymon/client/bin/xymon
and another using /usr/local/xymon/client/bin/hobbit.

etc

The easiest way to do this is to make use of the variables, and then
either the script within a xymoncmd wrapper (which sets all of the
variables you need) or from tasks.cfg (which can also set the variables you
need).  You end up with something like this:

     $XYMON $XYMSRV "status $MACHINE.apachecheck red `date` something's
not right with apache"

This works on any of your Xymon clients, no matter how they're setup.

Here's another idea.  You can have your script create a log entry using
"logger" and then have Xymon's log watching code detect the anomaly and
warn accordingly.

J