[xymon] Feature? svcs

[Vernon Everett]

Looks good.
I will try it on our systems tomorrow, when I get back to the office.

Thanks.

Regards
    Vernon


On Thu, Jul 29, 2010 at 6:49 PM, Ward, Martin <Martin.Ward at colt.net> wrote:

>  It's done: http://xymonton.trantor.org/doku.php/monitors:smf.sh
>
>
>
> I hope I got the syntax right, it all looks good to me.
>
>
>
> |\/|
>
> --
>
> Martin Ward
>
> *Manager, Technical Services*
>
>
>
> DDI:+44 (0) 20 7863 5218 / Fax: +44 (0)20 7863 9999 /  www.colt.net
>
> Colt Technology Services, Unit 12, Powergate Business Park, Volt Avenue,
> Park Royal, London, NW10 6PW, UK.
>
>
>
> Help reduce your carbon footprint | Think before you print. Registered in
> England and Wales, registered number 02452736, VAT number GB 645 4205 50
>
>
>
> *From:* Vernon Everett [mailto:everett.vernon at gmail.com]
> *Sent:* 29 July 2010 01:49
> *To:* xymon at xymon.com
> *Subject:* Re: [xymon] Feature? svcs
>
>
>
> Funny that. About a year ago I discussed using that method with a
> colleague.
> We never got that far, and I forgot all about it.
>
> And excellent way to do it.
>
> Have you considered posting your script on Xymonton?
> Here http://xymonton.trantor.org/doku.php/monitors
>
> Cheers
>     Vernon
>
>
>  On Wed, Jul 28, 2010 at 4:30 PM, Ward, Martin <Martin.Ward at colt.net>
> wrote:
>
> I have a script that is one step further than yours, the main difference
> being that I have defined the services to be monitored in the
> client-local.cfg file as you want:
>
> In client-local.cfg for example:
>
> [nmc-dhcp1]
> log:/var/adm/messages:10240
> svc:/network/ssh:default|svc:/site/network/dhcpd:default
>
> Data from this file is sent to the client (in this case a server called
> nmc-dhcp1) and stored in $BBTMP/logfetch.$MACHINEDOTS.cfg, so in the
> client-side script I have:
>
> SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`
>
> I was being lazy so have separated the services with the | symbol in
> client-local.cfg, this means I can then use the following code with no
> pre-processing:
>
> svcs -a | ${EGREP} "${SVCS}" > $SVCFILE
>
> The reason I store the 'svcs -a' output is because I include it in the
> data sent back to Xymon.
>
> Service states are checked using the following code:
>
> cat $SVCFILE | while read SVC
> do
>        STATE=`echo ${SVC} | ${AWK} '{print $1}'`
>
>        case "${STATE}" in
> 'uninitialized'|'offline'|'degraded')
>                if [ "${COLOUR}" != "RED" ]
>                then
>                        COLOUR="YELLOW"
>                fi
>                ;;
> 'maintenance'|'disabled')
>                COLOUR="RED"
>                ;;
>        esac
>        echo ${COLOUR} > $COLOURFILE
> done
>
> COLOUR=`cat ${COLOURFILE}`
>
> To be honest I don't know why I am storing the colour in a file and then
> re-reading it outside the loop, the value shouldn't change at the end of
> the while loop. This script was thrown together so it's likely I
> intended to remove it but forgot.
>
> Anyway, after that loop I call $BB and pass it all the parameters.
>
> It doesn't have the options that you want, but it does allow for
> different return colours depending on the return state. I coded it to
> return RED if a service is in a disabled state since I want to monitor
> specific services rather than all of them.
>
> The final code is here:
>
> ----
> #!/bin/sh
>
> # A Hobbit script to examine specific Solaris 10 services.
>
> # Author: Martin Ward 19 Feb 2008.
> # Version: 1.0 - Initial version.
> # V1.1  Script now takes the list of services to monitor from the server
> #       via the logfetch file.
>
> # SVCS is a list of services to examine the status of. Each name must be
> # specific enough to make it unique in the output from the 'svcs -a'
> command.
> # Separate each service with a | so that we can use ${EGREP} to search
> for them.
> # The services themselves are configured on the Hobbit server in the
> # ~hobbit/server/etc/client-local.cfg file. The line will look something
> like:
> # svc:/network/ssh:default|svc:/site/tftpd:default
>
> # Verify existence of the config file
> if [ ! -f $BBTMP/logfetch.$MACHINEDOTS.cfg ]
> then
>        echo "Unable to retrieve services descriptions."
>        exit 1
> fi
>
> SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`
>
> # The name of the column in Hobbit
> COLUMN=smf
>
> # COLOUR defaults to green
> COLOUR=GREEN
>
> # When you modify a variable inside a while loop its value is local to
> that
> # loop. This means that when you reach the end of the loop the variable
> will
> # be the same value that it was before the loop was entered. For this
> reason
> # we have to store the services and colour in temporary files.
> SVCFILE=/tmp/svcs.$$
> COLOURFILE=/tmp/svcs.colour.$$
>
> # Set up the initial colour
> echo "WHITE" > $COLOURFILE
>
> # Get the svcs header line first
> MSGH=`svcs -a | head -1`
>
> # Scan through the svcs -a list. Use -a to ensure we get everything.
> svcs -a | ${EGREP} "${SVCS}" > $SVCFILE
>
> cat $SVCFILE | while read SVC
> do
>        STATE=`echo ${SVC} | ${AWK} '{print $1}'`
>
>        case "${STATE}" in
> 'uninitialized'|'offline'|'degraded')
>                if [ "${COLOUR}" != "RED" ]
>                then
>                        COLOUR="YELLOW"
>                fi
>                ;;
> 'maintenance'|'disabled')
>                COLOUR="RED"
>                ;;
>        esac
>        echo ${COLOUR} > $COLOURFILE
> done
>
> COLOUR=`cat ${COLOURFILE}`
>
> # Tell Hobbit about it
> $BB $BBDISP "status $MACHINE.$COLUMN $COLOUR `date`
>
> ${MSGH}
> `cat ${SVCFILE}`
> "
>
> rm -f ${SVCFILE} ${COLOURFILE}
>
> exit 0
> ----
>
>
> |\/|artin
>
> [Colt Disclaimer]
> The message is intended for the named addressee only and may not be
> disclosed
> to or used by anyone else, nor may it be copied in any way. The contents of
> this message and its attachments are confidential and may also be subject
> to
> legal privilege. If you are not the named addressee and/or have received
> this
> message in error, please advise us by e-mailing abuse at colt.net and delete
> the
> message and any attachments without retaining any copies. Internet
> communications are not secure and Colt does not accept responsibility for
> this
> message, its contents nor responsibility for any viruses. No contracts can
> be
> created or varied on behalf of Colt Technology Services, its subsidiaries,
> group companies or affiliates ("Colt") and any other party by email
> communications unless expressly agreed in writing with such other party.
> Please note that incoming emails will be automatically scanned to eliminate
> potential viruses and unsolicited promotional emails. For more information
> refer to www.colt.net or contact us on +44(0)20 7390 3900
>
>
>
> To unsubscribe from the xymon list, send an e-mail to
> xymon-unsubscribe at xymon.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20100729/2f820ead/attachment.html>