On 12.09.2012 19:19, Steven Schwartz wrote: > Can you point me to the error in how I'm handling the > submit_check_result/send_nsca part of the installation? Because I *thought* I > was following the documentation correctly,
which docs exactly? those? http://docs.icinga.org/latest/en/distributed.html > and therefore I shouldn't be seeing this error; the macro fills in just fine > in other cases; the same check, submitting a passive result, sometimes shows > up fine, other times shows up with $SERVICEDESC$ instead of the actual > description. > > My default icinga.cfg points to the same command for both; should I then be > editing the icinga.cfg to have a separate submit_host_check_result and a > submit_service_check_result? yep. only use macros where they are valid. see the matrix here - http://docs.icinga.org/latest/en/macrolist.html so probably the easiest solution would be to add your very own host check result handler script (partly copy the existing script). the documentation on the link above mentions that a bit, but probably could be more telling about the different ohcp_command as well as script example used. See "Performing Host Checks" section. kind regards, Michael > > > > From misccommands.cfg > > define command{ > command_name submit_check_result > command_line /usr/local/icinga/libexec/submit_check_result > $HOSTNAME$ ' > $SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$' > } > > And > > Libexec/submit_check_result: > > #!/bin/sh > > # Arguments: > # $1 = host_name (Short name of host that the service is > # associated with) > # $2 = svc_description (Description of the service) > # $3 = state_string (A string representing the status of > # the given service - "OK", "WARNING", "CRITICAL" > # or "UNKNOWN") > # $4 = plugin_output (A text string that should be used > # as the plugin output for the service checks) > # > > # Convert the state string to the corresponding return code > return_code=-1 > > case "$3" in > OK) > return_code=0 > ;; > WARNING) > return_code=1 > ;; > CRITICAL) > return_code=2 > ;; > UNKNOWN) > return_code=-1 > ;; > esac > > # pipe the service check info into the send_nsca program, which > # in turn transmits the data to the nsca daemon on the central > # monitoring server > echo "Submitted hostname: $1 svc desc $2 state_string $3 return code > $return_cod > e plugin output $4 to send_ncsa">> /tmp/nscalog > /usr/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | > /usr/local/ic > inga/bin/send_nsca -H icinga-2 -c /usr/local/icinga/etc/send_nsca.cfg > > Thank you for your help, > > Steven Schwartz > > > > > -----Original Message----- > From: Michael Friedrich [mailto:michael.friedr...@gmail.com] > Sent: Wednesday, September 12, 2012 12:03 AM > To: icinga-users@lists.sourceforge.net > Subject: Re: [icinga-users] Odd problem > > On 11.09.2012 21:46, Steven Schwartz wrote: >> >> So, I'm trying to use send_nsca to have a failover server. The problem >> is that while some checks work, producing output like this: >> >> [1347392555] EXTERNAL COMMAND: >> PROCESS_SERVICE_CHECK_RESULT;tulip8-pcfp11;discovery;0;0:discovery >> enabled >> >> Sometimes, I get: >> >> [1347392540] EXTERNAL COMMAND: >> PROCESS_SERVICE_CHECK_RESULT;s3-afp-1-t1c1s8;$SERVICEDESC$;-1;$SERVICE >> OUTPUT$ >> >> [1347392540] Warning: Passive check result was received for service >> '$SERVICEDESC$' on host 's3-afp-1-t1c1s8', but the service could not >> be found! >> >> I have a log program running within the standard submit_check_result, >> and for a good service check I see: >> >> Submitted hostname: db-emmidprod-1 svc desc PING state_string OK >> return code 0 plugin output 0:Host alive to send_ncsa >> >> While on bad checks I get: >> >> Submitted hostname: trackid-gnstest-1 svc desc $SERVICEDESC$ >> state_string $ return code -1 plugin output $SERVICEOUTPUT$ to >> send_ncsa >> >> The line I'm using in submit_check_result is this: >> >> echo "Submitted hostname: $1 svc desc $2 state_string $3 return code >> $return_code plugin output $4 to send_ncsa">> /tmp/nscalog >> >> So - the values being passed to submit_check_result from >> obsess_over_services is, when it goes wrong: >> >> <hostname> $SERVICEDESC$ $ -1 $SERVICEOUTPUT$ >> >> Anyone have an idea why it would be doing that? The checks appear to >> be working in the local web interface. >> > > you should make sure that macros are grabbed / resolved correctly. the > current core behaviour on unknown macros is to leave them as is on the > output. that of course is rather irritating, and will cause scripts and > notifications to actually interpret those values. > > we will change that behaviour in 1.8 and only log a warning on unknown > macros, cleaning them from the output. > https://dev.icinga.org/issues/2291 > > in your case, you should put a check onto your submitted arguments, > validating that they are not macros, until 1.8 is out. > > other than that, you are probably calling that script in the wrong way - i > guess, this script is also called when you actually send host check results, > where the service macros do not fit. > > kind regards, > michael > >> Steven Schwartz >> >> Gracenote, Inc. >> >> >> >> ---------------------------------------------------------------------- >> -------- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and the >> latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> _______________________________________________ >> icinga-users mailing list >> icinga-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/icinga-users > > > -- > DI (FH) Michael Friedrich > > Lead Icinga Core Developer > https://www.icinga.org > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > icinga-users mailing list > icinga-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/icinga-users > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > icinga-users mailing list > icinga-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/icinga-users -- DI (FH) Michael Friedrich mail: michael.friedr...@gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmi...@jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
