I just realized I don't have to use NSCA to do this at all. I rewrote my script
to simply push the information it gets from Nagios back to Nagios. In case
anyone needs to configure something similar, below is my setup:
SCRIPT
---------------------------------------------
#!/bin/bash
########################################################################################
#Script requires 2 parameters to function with a 2 optional ones. From the
information
#parameters, only STATUS and OUTPUT are necessary to function. HOST/SERVICE are
for logs
########################################################################################
#Log info variables
SCRIPTNAME=$0
LOGDIR=
LOGFILE=${LOGDIR}/${SCRIPTNAME}/${SCRIPTNAME}_`date '+%m%d%Y'`.log"
SCRIPTDIR=
#Information parameters
HOST=$1
SERVICE=$2
STATUS=$3
OUTPUT=$4
#Check if log file exists. If it doesn't, create it and give everyone
permissions
#the last part is necessary so other users calling this script can log commands
also
if [ ! -e $LOGFILE ]; then
echo
"###########################################################################################"
>> $LOGFILE
echo "# script (${SCRIPTDIR}) log file for `date '+%m/%d/%Y'`" >> $LOGFILE
echo -e
"###########################################################################################\n\n"
>> $LOGFILE
chmod a+w $LOGFILE
fi
#Log the values passed for parameters
echo $(date) >> $LOGFILE
echo -e "$HOST\t$SERVICE\t$STATUS\t$OUTPUT\n" >> $LOGFILE
#Send the output back to Nagios via echo command and exit with the specified
STATUS
echo "$OUTPUT"
exit $STATUS
--------------------------------------------------
COMMAND DEFINITION
--------------------------------------------------
# run this for EOD checks that need to reset state
define command{
command_name reset_state
command_line /app/edeliver/nagiosTEST/libexec/reset_state $HOSTNAME$
$SERVICEDESC$ -1 "Reset...`date`"
}
--------------------------------------------------
SERVICE DEFINITION
--------------------------------------------------
I then have the service template with a check_period set to a specific
timeperiod. That period is set to run (in my case) Monday to Friday between
11:54-11:59PM (enough time for all my checks to go through). Just so a service
wouldn't run it's command twice, I set the check_intervals to 5 minutes which
would pass the alloted timeperiod for this check command to run.
--------------------------------------------------
So basically the command runs and returns the status/output specified by that
service check command back to that service.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sapon, Dimitry
Sent: Wednesday, June 06, 2007 9:56 AM
To: nagios-users@lists.sourceforge.net
Subject: [Nagios-users] Scheduled service state resets
Hi there,
I have an interesting requirement to fulfill. I have about 100 passive only
service checks that need to be reset (currently to Unknown state) at a
specified time of day (currently midnight). The reason they need this done is
to be able to easily tell if the passive checks have occured on that day
(because they return either one of the three other possible states).
I came up with two possibilities of doing this: crontab or enable active
service checks 5 minute before midnight for those services, and use a command
that sends a notification to the service using send_nsca. Here are the ups and
downs of each approach:
Crontab
Pros
* Simple to setup scheduling
* Can run multiple scripts easily
* Control over the entire reset state process (once crond gets the script
going)
Cons
* Cumbersome to configure which services need to be notified (need to
implement my own config file separate from Nagios, create logic in bash to read
it, update it everytime there is a change etc.)
Nagios Command through active checks
Pros
* Simple to setup scheduling
* Logic for which services to reset is easily configurable through
service template definitions used for those services. Changes in the future are
easily made and done in one place as opposed to two with the crontab version.
Cons
* By having Nagios send out parameters to a script that runs a send_nsca
command via an "active check" method, Nagios expects the check to return
information back to it. The "active check" basically returns an OK (Hard) state
with the output being the commands I passed to my script. A few seconds later,
Nagios processes the send_nsca command and changes to the new state (Unknown in
this case). So as you see, Nagios goes through 2 hard state changes and two
possible notifications. Now I will disable notifications on unknown but I do
have it setup to notify on recovery as people need to get emails when a passive
check returns an OK state. So with this method they'll get a notification at
midnight for every service setup like that basically because it's been reset.
Even if I could get away with not having to send any notifications other than
the two other hard non-OK states, it still doesn't make sense to bombard Nagios
with an extra state change for every service setup. Just spells bad news if
this ever needs to be scaled imo.
Conclusion
I was very happy with setup 2 until I discovered that major con. That's the
rason I stated that with the crontab I have full control over the entire
process (other than what's handled by the other daemons necessary for crontab
to work). I really don't feel like setting up a separate process, script, and
config files, causing multiple locations to be updated to handling something so
simple. I'm hoping I overlooked some easier solution that you guys can
recommend.
Waiting to hear back from you...
Regards,
Dimitry
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in
error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender
does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits
et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il
contient par une personne autre que le (les) destinataire(s) désigné(s) est
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par
retour de courriel ou par un autre moyen.
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in
error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender
does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits
et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il
contient par une personne autre que le (les) destinataire(s) désigné(s) est
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par
retour de courriel ou par un autre moyen.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null