obsess.README

nagios.cfg:
===========

obsess_over_services=1
ocsp_command=ocsp2out
obsess_over_hosts=1
ochp_command=ochp2out


commands:
=========

define command {
  command_name  ocsp2out
  command_line  echo >>/tmp/nagixsc.spool/new/$TIMET$ LASTSERVICECHECK::$LASTSERVICECHECK$ HOSTNAME::\'$HOSTNAME$\' SERVICEDESC::\'$SERVICEDESC$\' SERVICESTATEID::$SERVICESTATEID$ SERVICEOUTPUT::\'$SERVICEOUTPUT$\' LONGSERVICEOUTPUT::\'$LONGSERVICEOUTPUT$\'
}

define command {
  command_name  ochp2out
  command_line  echo >>/tmp/nagixsc.spool/new/$TIMET$ LASTHOSTCHECK::$LASTHOSTCHECK$ HOSTNAME::\'$HOSTNAME$\' HOSTSTATEID::$HOSTSTATEID$ HOSTOUTPUT::\'$HOSTOUTPUT$\' LONGHOSTOUTPUT::\'$LONGHOSTOUTPUT$\'
}


Advantages/benefits:
====================

- Do NOT start a shell to analyse the return-code and then format a string
  using "printf" as documented in the original documentation.
- Block the Nagios process for a minimum amount of time. The original script
  calls "send_nsca" directly, thus blocking Nagios until the NSCA network
  packet has been sent (which might include a timeout in case the server is
  unreachable). Here, we only write a single spool-file from the shell started
  by Nagios.
- Send multiple check results at once. Nagios writes multiple check results
  basically at the same time. While NSCA uses one network connection for every
  single one of those (which requires a TCP handshake, etc. for each of them),
  Nag(ix)SC creates a single XML file from all entries in the spool file.
- A separate, stand-alone process ("obsess_daemon.py") takes care of sending
  the XML file.


Caveats:
========

- "obsess_daeon.py" is not a real daemon yet. Start it in a terminal (and
  watch the debugging output).
- Watch what's going on:
  % cd /tmp/nagixsc.spool
  % watch -n2 "cat */*[0-9] | wc -l; (for F in xmlout/*; do
      ~/src/nagixsc/nagixsc_read_xml.py -f \$F; done) | grep -c RetCode"