--- /dev/null
+#!/usr/bin/perl
+
+# $Id$
+# $URL$
+
+use strict;
+use 5.10.0;
+use warnings;
+
+use FindBin;
+use Data::Dumper;
+use File::Find;
+use File::Spec;
+use File::Spec::Functions;
+use Cwd 'abs_path';
+
+BEGIN {
+ {
+ my $libdir = catfile( $FindBin::Bin, '..', 'lib' );
+ if ( -d $libdir ) {
+ $libdir = abs_path($libdir);
+ unshift @INC, $libdir;
+ }
+ }
+}
+
+$Data::Dumper::Indent = 1;
+$Data::Dumper::Sortkeys = 1;
+
+$| = 1;
+
+my $Revisn = <<'ENDE';
+ $Revision$
+ENDE
+$Revisn =~ s/^.*:\s*(\S+)\s*\$.*/$1/s;
+our $VERSION = "0.1." . $Revisn;
+
+#print "Includes: " . Dumper( \@INC );
+
+
+
+
+# vim: fileencoding=utf-8 syntax=perl ts=4 noai
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+import sys
+from nagios.config import NagiosConfig, NagiosConfigError
+
+#print "Modul-Suchpfade:"
+#for p in sys.path:
+# print " -", p
+
+#print "Namen aus dem NagiosConfig-Objekt:"
+#for name in dir(NagiosConfig):
+# print " -", name
+#print ""
+
+try:
+ nagios_conf = NagiosConfig()
+ nagios_conf.read()
+except NagiosConfigError as e:
+ print >> sys.stderr, e
+ sys.exit(2)
+
+
+#print "Nagios-Objekt: " + repr( nagios_conf )
+
+print nagios_conf.dump_config()
+nagios_conf.read_objects()
+
+# vim: fileencoding=utf-8 filetype=python ts=4 expandtab
--- /dev/null
+#!/usr/bin/python
+
+
+# vim: fileencoding=utf-8 filetype=python ts=4
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+import os
+import re
+import sys
+import warnings
+import logging
+import nagios.object.host
+
+class NagiosConfigError(Exception):
+ """Base class for exceptions in this module."""
+ pass
+
+class NagiosConfig(object):
+ """Klasse zur Kapselung aller Dinge der Nagios-Konfiguration."""
+
+ # Konfigurationsverzeichnis von Nagios
+ conf_dir = os.sep + os.path.join('etc', 'nagios')
+
+ # Basename der Nagios-Konfigurationsdatei
+ file_base = 'nagios.cfg'
+
+ # Kompletter Pfad der Nagios-Konfigurationsdatei
+ file_name = os.path.join(conf_dir, file_base)
+
+ # Inhalt der Konfiguration
+ conf = {}
+
+ # Die Objekte aus der Konfiguration oder dem Cache im Rohformat
+ objects = {}
+
+ # Die überprüften Objekte aus der Konfiguration
+ config_objects = {}
+
+ #------------------------------------------------------
+ def __repr__( self ):
+ "Dumper seiner selbst"
+
+ dump = {}
+ dump['conf_dir'] = self.conf_dir
+ dump['file_base'] = self.file_base
+ dump['file_name'] = self.file_name
+ dump['conf'] = repr(self.conf)
+ dump['objects'] = repr(self.objects)
+
+ return repr(dump)
+
+ #------------------------------------------------------
+ def __init__( self, new_file = file_name ):
+ "Konstruktor."
+ self.file_name = self.canonize_file(new_file)
+ self.conf = {}
+ self.objects = {}
+ self.config_objects = {}
+
+ # Logging-Setup
+ self.logger = logging.getLogger('nagiosConfig')
+ self.logger.setLevel(logging.DEBUG)
+
+ ch = logging.StreamHandler()
+ ch.setLevel(logging.DEBUG)
+
+ formatter = logging.Formatter("%(name)s - %(funcName)s(%(lineno)d) - %(levelname)s - %(message)s")
+ ch.setFormatter(formatter)
+
+ self.logger.addHandler(ch)
+
+ #------------------------------------------------------
+ def __del__( self ):
+ "Destruktor"
+
+ self.logger.debug( "Hilfe - ich werde zerstört!!" )
+
+ #------------------------------------------------------
+ def canonize_file( self, f ):
+ """Kanonisiert den übergebenen Dateinamen, indem er nicht-absoluten Dateinamen verabsolutiert"""
+ f = os.path.abspath(f);
+ f = self.search_conf(f)
+ return f
+
+ #------------------------------------------------------
+ def file( self, new_file = None ):
+ "Gibt den aktuellen Konfigurationsdateiname zururück bzw. setzt ihn."
+ old_name = self.file_name
+ if new_file is not None:
+ self.file_name = os.path.abspath(new_file)
+ return old_name
+
+ #------------------------------------------------------
+ def search_conf( self, f = None ):
+ "Sucht die Nagios-Konfigurationsdatei und speichert diese in self.file_name bzw. stirbt, wenn nicht gefunden."
+
+ if f is None: f = self.file_name
+ if os.path.exists(f):
+ if os.path.isfile(f):
+ f = os.path.realpath(f)
+ self.file_name = f
+ return f
+ else:
+ raise NagiosConfigError( "Pfad '" + f + "' ist keine normale Datei." )
+
+ search_dirs = ( os.path.dirname(self.file_name), self.conf_dir, \
+ os.sep + os.path.join( 'etc', 'nagios3'), \
+ os.sep + os.path.join( 'etc', 'nagios'), \
+ os.sep + os.path.join( 'usr', 'local', 'nagios', 'etc' ), \
+ os.sep + os.path.join( 'usr', 'local', 'etc', 'nagios' ) )
+ used_dirs = {}
+ #print repr(search_dirs)
+
+ for path in search_dirs:
+ if not ( os.path.exists(path) and os.path.isdir(path) ):
+ continue
+ if path in used_dirs: continue
+ used_dirs[path] = 1
+ print "Suche Konfig in Verzeichnis '" + path + "' ..."
+ my_file = os.path.join( path, 'nagios.cfg' )
+ if os.path.exists(my_file) and os.path.isfile(my_file):
+ my_file = os.path.realpath(my_file)
+ self.file_name = my_file
+ return my_file
+
+ raise NagiosConfigError( "Nagios-Konfigurationsdatei nicht gefunden." )
+ return None
+
+ #------------------------------------------------------
+ def read( self ):
+ "Liest die in self.file_name hinterlegte Konfigurationsdatei ein und legt das Gelesene in self.conf ab"
+
+ try:
+ file = open( self.file_name, 'rU' )
+ except IOError as e:
+ raise NagiosConfigError( e )
+
+ self.conf = {}
+
+ try:
+ for line in file:
+ self.perform_line( line )
+ finally:
+ file.close()
+
+ #------------------------------------------------------
+ def perform_line( self, line ):
+ "Verarbeitet eine Konfigurationszeile und legt diese in self.conf ab."
+
+ pattern_comment = re.compile( r'^\s*#.*', re.MULTILINE );
+
+ line = re.sub( r'^\s+', '', line, 0 )
+ line = re.sub( r'\s+$', '', line, 0 )
+
+ if pattern_comment.search( line ):
+ return
+
+ match = re.search( r'\s*(\w+)\s*=\s*(.*)', line )
+ if match is not None:
+ key = match.group(1)
+ value = match.group(2)
+ #print "Gefunden - key: " + repr(key) + ", value: " + repr(value)
+ if key in self.conf:
+ #print "Eintrag Gefunden: " + repr( self.conf[key] )
+ #print "Typ von self.conf[", key, "]: ", type( self.conf[key] )
+ if not isinstance( self.conf[key], list ):
+ oldval = self.conf[key]
+ self.conf[key] = [ oldval ]
+ #print "Eintrag Umgewandelt: " + repr( self.conf[key] )
+ self.conf[key].append(value)
+ else:
+ self.conf[key] = value
+ #print key + ": " + repr( self.conf[key] )
+
+ return
+
+ #------------------------------------------------------
+ def param( self, key ):
+ "Gibt den Inhalt der entsprechenden Konfiguration aus bzw. None, wenn nicht vorhanden."
+
+ if not key in self.conf:
+ return None
+
+ return self.conf[key]
+
+ #------------------------------------------------------
+ def dump_config( self ):
+ "Gibt den Inhalt der Konfiguration in gedumpter Form zurück."
+
+ res = '{\n'
+ for key in sorted( self.conf.keys(), None, str.lower ):
+ res = res + " '" + key + "': "
+ if isinstance( self.conf[key], list ):
+ valdump = "[\n "
+ valdump = valdump + ",\n ".join( map( repr, self.conf[key] ) )
+ valdump = valdump + "\n ],"
+ else:
+ valdump = repr( self.conf[key] )
+ res = res + valdump + ",\n"
+
+
+ res = res + "}"
+
+ return res
+
+ #------------------------------------------------------
+ def read_objects( self ):
+ "Liest die in der Konfiguration engegebenen Objekt-Kofigurations-Dateien ein"
+
+ self.objects = {}
+ files = set([])
+ dirs = set([])
+
+ # cfg_file auswerten
+ if 'cfg_file' in self.conf:
+ if isinstance( self.conf['cfg_file'], list ):
+ for item in self.conf['cfg_file']:
+ approved_file = self.check_cfg_file_syntax(item)
+ if approved_file: files.add(approved_file)
+ else:
+ approved_file = self.check_cfg_file_syntax( self.conf['cfg_file'] )
+ if approved_file: files.add(approved_file)
+
+ # cfg_dir auswerten
+ if 'cfg_dir' in self.conf:
+ if isinstance( self.conf['cfg_dir'], list ):
+ for item in self.conf['cfg_dir']:
+ approved_dir = self.check_cfg_file_syntax( item, True )
+ if approved_dir: dirs.add(approved_dir)
+ else:
+ approved_dir = self.check_cfg_file_syntax( self.conf['cfg_dir'], True )
+ if approved_dir: dirs.add(approved_dir)
+
+ # Verzeichnisse rekursiv durchsteigen ...
+ for dir in dirs:
+ for root, found_dirs, found_files in os.walk( dir, followlinks = True):
+ for file in found_files:
+ file_absolute = os.path.join( root, file )
+ if not os.path.exists(file_absolute) or not os.path.isfile(file_absolute):
+ continue
+ if not re.search( r'\.cfg$', file, re.IGNORECASE ):
+ continue
+ file_absolute = os.path.realpath(file_absolute)
+ files.add(file_absolute)
+
+ #print repr(files)
+ for file_name in files:
+ self.read_objectfile(file_name)
+
+ self.logger.debug( "Gelesene Objekte: {0!r}".format( self.objects ) )
+
+ return
+
+ #------------------------------------------------------
+ def read_objectfile( self, file_name ):
+ "Liest eine Datei mit Objektdefinitionen ein und legt diese unter self.objects ab."
+
+ try:
+ file = open( file_name, 'rU' )
+ except IOError as e:
+ raise NagiosConfigError( e )
+
+ cur_object = {}
+ in_block = False
+ object_type = None
+ pattern_comment = re.compile( r'^\s*#.*', re.MULTILINE );
+ row_num = 0
+
+ try:
+ for line in file:
+
+ row_num = row_num + 1
+ line = re.sub( r'^\s+', '', line, 0 )
+ line = re.sub( r'\s+$', '', line, 0 )
+ if line == '': continue
+ #self.logger.debug( "Untersuche Zeile {0} in {1}: {2!r}".format( row_num, file_name, line ) )
+ if pattern_comment.search( line ): continue
+ line = re.sub( r'\s*;(?:[^"]*(?:"[^"]*")?)*', '', line, 0 )
+ if line == '': continue
+ #self.logger.debug( "Untersuche Zeile {0} in {1}: {2!r}".format( row_num, file_name, line ) )
+
+ if in_block:
+
+ if line == '}':
+ in_block = False
+ if not object_type in self.objects:
+ self.objects[object_type] = []
+ self.objects[object_type].append( cur_object )
+ cur_object = {}
+ self.logger.debug( "Zeile {0} in {1}: Beende Block vom Type {2!r}".format( row_num, file_name, object_type ) )
+
+ else:
+
+ ( key, value ) = self.check_object_file_entry( line, object_type, file_name, row_num )
+ if ( key == None ):
+ self.logger.debug( "Nichts gefunden." )
+ else:
+ self.logger.debug( "Gefunden: key: {0!r}, value: {1!r}".format( key, value ) )
+ if key in cur_object:
+ self.logger.warn( "Doppelter Eintrag für Eigenschaft {0!r} von {1!r} in {2}({3}).".format(
+ key, object_type, file_name, row_num )
+ else:
+ cur_object[key] = ( value, file, row_num )
+
+ else:
+
+ match = re.search( r'^define\s+(\w+)\s*{$', line, re.IGNORECASE )
+ if match is not None:
+ in_block = True
+ cur_object = {}
+ object_type = match.group(1).lower()
+ cur_object['__object_definition__'] = ( file, row_num )
+ self.logger.debug( "Zeile {0} in {1}: Beginne Block vom Type {2!r}".format( row_num, file_name, object_type ) )
+ continue
+
+ self.logger.debug( "Ungültige Zeile {0} in {1} gefunden: {2!r}".format( row_num, file_name, line ) )
+
+ finally:
+ file.close()
+
+ #------------------------------------------------------
+ def verify_objects( self, as_cache_objects = False ):
+ "Überprüft die Syntax der eingelesenen Konfiguration"
+
+ verify_success = True
+ self.config_objects = {}
+
+ for object_type in self.objects:
+
+ for definition in self.objects[object_type]:
+
+ if object_type == 'host':
+
+ ( identifier, struct ) = nagios.object.host.verify( definition, self.logger )
+
+ if identifier is None:
+ verify_success = False
+ continue
+
+ if as_cache_objects:
+ if not 'host' in self.cache_objects:
+ self.cache_objects['host'] = {}
+ else:
+ if not 'host' in self.config_objects:
+ self.config_objects['host'] = {}
+
+ if identifier in self.config_objects['host']:
+ ( file_name, rownum ) = definition['__object_definition__']
+ msg = "Host-Objekt {0!r} ist bereits vorhanden, ".format( identifier )
+ msg = msg + "neue Definition in {0}({1}) wird nicht beachtet.".format( file_name, rownum )
+ self.logger.warn( msg )
+ continue
+
+ if as_cache_objects:
+ self.cache_objects['host'][identifier] = struct
+ else:
+ self.config_objects['host'][identifier] = struct
+
+ if not verify_success:
+ raise NagiosConfigError( "Objektstruktur konnte nicht verifiziert werden." )
+
+ return True
+
+ #------------------------------------------------------
+ def check_object_file_entry( self, line, object_type, file_name, row_num ):
+
+ line = re.sub( r'\s*;(?!.*").*$', '', line, 0 )
+ if line == '': return ( None, None )
+
+ key = 'key{0!s}'.format( row_num )
+ value = line
+
+ match = re.search( r'^\s*(\w+)(?:\s+(.*))?', line )
+ if match is None:
+ self.logger.error( "Konnte Zeile {0} in {1} nicht auswerten: {2!r}.".format( row_num, file_name, line ) )
+ return ( None, None )
+
+ key = match.group(1)
+ value = match.group(2)
+
+ return ( key, value )
+
+ #------------------------------------------------------
+ def check_cfg_file_syntax( self, file, as_dir = False ):
+ "Checkt absolute Angabe und Vorhandensein der übergebenen Datei bzw. Verzeichnis"
+
+ directive = 'cfg_file'
+ file_type = 'Datei'
+ if as_dir:
+ directive = 'cfg_dir'
+ file_type = 'Verzeichnis'
+
+ if not os.path.isabs(file):
+ self.logger.error( "Keine absolute Pfadangabe in {0}={1}".format( directive, file ) )
+ return None
+
+ if not os.path.exists(file):
+ self.logger.error( "{0} {1} existiert nicht.".format( file_type, file ) )
+ return None
+
+ if as_dir:
+ if not os.path.isdir(file):
+ self.logger.error( "Verzeichnis {0} ist keine normales Verzeichnis.".format(file) )
+ return None
+ else:
+ if not os.path.isfile(file):
+ self.logger.error( "Datei {0} ist keine normale Datei.".format(file) )
+ return None
+
+ return os.path.realpath(file)
+
+
+# vim: fileencoding=utf-8 filetype=python ts=4 expandtab
--- /dev/null
+#!/usr/bin/python
+
+
+# vim: fileencoding=utf-8 filetype=python ts=4
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+import re
+
+def verfify( definition, logger )
+"Verifiziert einen übergebenen Definitionsblock als Nagios-Host."
+
+ res = {}
+ identifier = None
+
+"""
+define host{
+ *host_name host_name
+ *alias alias
+ display_name display_name
+ *address address
+ parents host_names
+ hostgroups hostgroup_names
+ check_command command_name
+ initial_state [o,d,u]
+ *max_check_attempts #
+ check_interval #
+ retry_interval #
+ active_checks_enabled [0/1]
+ passive_checks_enabled [0/1]
+ *check_period timeperiod_name
+ obsess_over_host [0/1]
+ check_freshness [0/1]
+ freshness_threshold #
+ event_handler command_name
+ event_handler_enabled [0/1]
+ low_flap_threshold #
+ high_flap_threshold #
+ flap_detection_enabled [0/1]
+ flap_detection_options [o,d,u]
+ process_perf_data [0/1]
+ retain_status_information [0/1]
+ retain_nonstatus_information [0/1]
+ *contacts contacts
+ *contact_groups contact_groups
+ *notification_interval #
+ first_notification_delay #
+ *notification_period timeperiod_name
+ notification_options [d,u,r,f,s]
+ notifications_enabled [0/1]
+ stalking_options [o,d,u]
+ notes note_string
+ notes_url url
+ action_url url
+ icon_image image_file
+ icon_image_alt alt_string
+ vrml_image image_file
+ statusmap_image image_file
+ 2d_coords x_coord,y_coord
+ 3d_coords x_coord,y_coord,z_coord
+}
+"""
+
+ valid_keys = set(
+ 'host_name', 'alias', 'display_name', 'address', 'parents', 'hostgroups', 'check_command', 'initial_state',
+ 'max_check_attempts', 'check_interval', 'retry_interval', 'active_checks_enabled', 'passive_checks_enabled',
+ 'check_period', 'obsess_over_host', 'check_freshness', 'freshness_threshold', 'event_handler', 'event_handler_enabled',
+ 'low_flap_threshold', 'high_flap_threshold', 'flap_detection_enabled', 'flap_detection_options', 'process_perf_data',
+ 'retain_status_information', 'retain_nonstatus_information', 'contacts', 'contact_groups', 'notification_interval',
+ 'first_notification_delay', 'notification_period', 'notification_options', 'notifications_enabled', 'stalking_options',
+ 'notes', 'notes_url', 'action_url', 'icon_image', 'icon_image_alt', 'vrml_image', 'statusmap_image',
+ '2d_coords', '3d_coords'
+ )
+
+ for key in definition:
+ if not key in valid_keys:
+ logger.warn( "Ungültige Eigenschaft {0!r} für Hostdefinition in {1}({2}).".format(
+ key, definition[key][1], definition[key][2] )
+
+ if 'host_name' in definition:
+ identifier = definition['host_name'][0]
+ res['host_name'] = definition['host_name'][0]
+ else
+ logger.warn( "Kein Hostname in Hostdefinition gegeben." )
+
+ # Einfache String-Eigenschaften
+ for key in ( 'alias', 'address', 'display_name', 'check_period', 'event_handler', 'notification_period',
+ 'notes', 'notes_url', 'action_url', 'icon_image', 'icon_image_alt', 'vrml_image', 'statusmap_image' ):
+ if key in definition:
+ res[key] = definition[key][0]
+
+ # Array-String-Eigenschaften
+ for key in ( 'parents', 'hostgroups', 'contacts', 'contact_groups' ):
+ if key in definition:
+ array = re.split( r',+', definition[key][0]
+ res[key] = array[]
+
+ if 'initial_state' in definition:
+ array = re.split( r',+', definition['initial_state'][0]
+ for value in array:
+ if value not in ( 'o', 'd', 'u' ):
+ logger.warn( "Ungültiger Wert für 'initial_state' in {0}({1}) gegeben.".format(
+ definition['initial_state'][1], definition['initial_state'][2] )
+
+ return ( identifier, res )
+
+# vim: fileencoding=utf-8 filetype=python ts=4 expandtab
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>About Nagios</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Trademark { font-family: verdana,arial,serif; font-size: 7pt; }
+
+
+
+ .Disclaimer { font-family: verdana,arial,serif; font-size: 7pt; font-style: italic; text-align: center; }
+
+
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">About Nagios</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guides</a>
+
+</p>
+
+<p>
+
+<a name="overview"></a>
+
+<strong><u>Nagios Overview</u></strong>
+
+</p>
+
+<p>
+More information about Nagios - including features, case studies, and technical specifications can be found online at <a href="http://www.nagios.org/about/" target="_blank"><b>www.nagios.org/about/</b></a>.
+</p>
+
+<p>
+
+<a name="whatis"></a>
+
+<strong><u>What Is Nagios?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios® is a system and network monitoring application. It watches hosts and services that you specify, alerting you when things go bad and when they get better.
+
+</p>
+
+<p>
+
+Nagios was originally designed to run under <a href="http://www.linux.com">Linux</a>, although it should work under most other unices as well.
+
+</p>
+
+<p>
+
+Some of the many features of Nagios include:
+
+</p>
+
+<ul>
+
+<li>Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)
+
+<li>Monitoring of host resources (processor load, disk usage, etc.)
+
+<li>Simple plugin design that allows users to easily develop their own service checks
+
+<li>Parallelized service checks
+
+<li>Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable
+
+<li>Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)
+
+<li>Ability to define event handlers to be run during service or host events for proactive problem resolution
+
+<li>Automatic log file rotation
+
+<li>Support for implementing redundant monitoring hosts
+
+<li>Optional web interface for viewing current network status, notification and problem history, log file, etc.
+
+</ul>
+
+
+
+
+
+<p>
+
+<a name="requirements"></a>
+
+<strong><u>System Requirements</u></strong>
+
+</p>
+
+<p>
+
+<i>The only requirement of running Nagios is a machine running Linux (or UNIX variant) and a C compiler.</i> You will probably also want to have TCP/IP configured, as most service checks will be performed over the network.
+
+</p>
+
+<p>
+
+You are <i>not required</i> to use the CGIs included with Nagios. However, if you do decide to use them, you will need to have the following software installed...
+
+</p>
+
+
+
+<ol>
+
+<li>A web server (preferrably <a href="http://www.apache.org" target="_top">Apache</a>)
+
+<li>Thomas Boutell's <a href="http://www.boutell.com/gd">gd library</a> version 1.6.3 or higher (required by the <a href="cgis.html#statusmap_cgi">statusmap</a> and <a href="cgis.html#trends_cgi">trends</a> CGIs)
+
+</ol>
+
+
+
+<p>
+
+<a name="licensing"></a>
+
+<strong><u>Licensing</u></strong>
+
+</p>
+
+<p class="SectionBody">
+
+Nagios is licensed under the terms of the <a href="http://www.gnu.org/copyleft/gpl.html">GNU General Public License</a> Version 2 as published by the <a href="http://www.fsf.org">Free Software Foundation</a>. This gives you legal permission to copy, distribute and/or modify Nagios under certain conditions. Read the 'LICENSE' file in the Nagios distribution or read the <a href="http://www.gnu.org/copyleft/gpl.html">online version of the license</a> for more details.
+
+</p>
+
+
+
+<p>
+
+Nagios is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE WARRANTY OF DESIGN, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE.
+
+</p>
+
+
+
+<p>
+
+<a name="acknowledgements"></a>
+
+<strong><u>Acknowledgements</u></strong>
+
+</p>
+
+<p>
+
+Several people have contributed to Nagios by either reporting bugs, suggesting improvements, writing plugins, etc. A list of some of the many contributors to the development of Nagios can be found in the THANKS file in the root of the Nagios distribution.
+
+</p>
+
+
+
+<p>
+
+<a name="downloading"></a>
+
+<strong><u>Downloading The Latest Version</u></strong>
+
+</p>
+
+<p>
+
+You can check for new versions of Nagios at <a href="http://www.nagios.org" target="_top">http://www.nagios.org</a>.
+
+</p>
+
+
+
+<hr>
+
+
+
+<br clear="all">
+
+<div class="Disclaimer">
+
+Nagios and the Nagios logo are trademarks of <a href="http://www.nagios.com/" target="_blank">Nagios Enterprises, LLC</a>. All other trademarks, servicemarks, registered trademarks, and registered servicemarks may be the property of their respective owner(s).
+
+</div>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Active Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Active Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="passivechecks.html">Passive Checks</a>, <a href="plugins.html">Plugins</a>, <a href="servicechecks.html">Service Checks</a>, <a href="hostchecks.html">Host Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios is capable of monitoring hosts and services in two ways: actively and passively. Passive checks are described <a href="passivechecks.html">elsewhere</a>, so we'll focus on active checks here. Active checks are the most common method for monitoring hosts and services. The main features of actives checks as as follows:
+
+</p>
+
+
+
+<ul>
+
+<li>Active checks are initiated by the Nagios process</li>
+
+<li>Active checks are run on a regularly scheduled basis</li>
+
+</ul>
+
+
+
+<img src="images/activechecks.png" border="0" style="float: right;" alt="Active Checks">
+
+
+
+<p>
+
+<strong><u>How Are Active Checks Performed?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Active checks are initiated by the check logic in the Nagios daemon. When Nagios needs to check the status of a host or service it will execute a plugin and pass it information about what needs to be checked. The plugin will then check the operational state of the host or service and report the results back to the Nagios daemon. Nagios will process the results of the host or service check and take appropriate action as necessary (e.g. send notifications, run event handlers, etc).
+
+</p>
+
+
+
+<p>
+
+More information on how plugins work can be found <a href="plugins.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>When Are Active Checks Executed?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Active check are executed:
+
+</p>
+
+<ul>
+
+<li>At regular intervals, as defined by the <i>check_interval</i> and <i>retry_interval</i> options in your host and service definitions</li>
+
+<li>On-demand as needed</li>
+
+</ul>
+
+
+
+<p>
+
+Regularly scheduled checks occur at intervals equaling either the <i>check_interval</i> or the <i>retry_interval</i> in your host or service definitions, depending on what <a href="statetypes.html">type of state</a> the host or service is in. If a host or service is in a HARD state, it will be actively checked at intervals equal to the <i>check_interval</i> option. If it is in a SOFT state, it will be checked at intervals equal to the <i>retry_interval</i> option.
+
+</p>
+
+
+
+<p>
+
+On-demand checks are performed whenever Nagios sees a need to obtain the latest status information about a particular host or service. For example, when Nagios is determining the <a href="networkreachability.html">reachability</a> of a host, it will often perform on-demand checks of parent and child hosts to accurately determine the status of a particular network segment. On-demand checks also occur in the <a href="dependencychecks.html">predictive dependency check</a> logic in order to ensure Nagios has the most accurate status information.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Adaptive Monitoring</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Adaptive Monitoring</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="extcommands.html">External Commands</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios allows you to change certain commands and host and service check attributes during runtime. I'll refer to this feature as "adaptive monitoring". Please note that the adaptive monitoring features found in Nagios will probably not be of much use to 99% of users, but they do allow you to do some neat things.
+
+</p>
+
+
+
+<p>
+
+<strong><u>What Can Be Changed?</u></strong>
+
+</p>
+
+
+
+<p>
+
+The following service check attributes can be changed during runtime:
+
+</p>
+
+
+
+<ul class="Default">
+
+<li>Check command (and command arguments)</li>
+
+<li>Check interval</li>
+
+<li>Max check attempts</li>
+
+<li>Check timeperiod</li>
+
+<li>Event handler command (and command arguments)</li>
+
+</ul>
+
+
+
+<p>
+
+The following host check attributes can be changed during runtime:
+
+</p>
+
+
+
+<ul class="Default">
+
+<li>Check command (and command arguments)</li>
+
+<li>Check interval</li>
+
+<li>Max check attempts</li>
+
+<li>Check timeperiod</li>
+
+<li>Event handler command (and command arguments)</li>
+
+</ul>
+
+
+
+<p>
+
+The following global attributes can be changed during runtime:
+
+</p>
+
+
+
+<ul class="Default">
+
+<li>Global host event handler command (and command arguments)</li>
+
+<li>Global service event handler command (and command arguments)</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>External Commands For Adaptive Monitoring</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order to change global or host- or service-specific attributes during runtime, you must submit the appropriate <a href="extcommands.html">external command</a> to Nagios via the <a href="configmain.html#command_file">external command file</a>. The table below lists the different attributes that may be changed during runtime, along with the external command to accomplish the job.
+
+</p>
+
+
+
+<p>
+
+A full listing of external commands that can be used for adaptive monitoring (along with examples of how to use them) can be found online at the following URL: <a href="http://www.nagios.org/developerinfo/externalcommands/" target="_blank">http://www.nagios.org/developerinfo/externalcommands/</a>
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Notes:
+
+</p>
+
+
+
+<ul>
+
+<li>When changing check commands, check timeperiods, or event handler commands, it is important to note that the new values for these options must have been defined before Nagios was started. Any request to change a command or timeperiod to one which had not been defined when Nagios was started is ignored.<br><br></li>
+
+<li>You can specify command arguments along with the actual command name - just seperate individual arguments from the command name (and from each other) using bang (!) characters. More information on how arguments in command definitions are processed during runtime can be found in the documentation on <a href="macros.html">macros</a>.</li>
+
+</ul>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Nagios Addons</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Nagios Addons</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+</p>
+
+
+
+<p><strong><u>Introduction</u></strong></p>
+
+
+
+<p>
+
+There are a lot of "addon" software packages that are available for Nagios. Addons can be used to extend Nagios' functionality or integrate Nagios with other applications.
+
+</p>
+
+
+
+<p>
+
+Addons are available for:
+
+</p>
+
+
+
+<ul>
+
+<li>Managing the config files through a web interface
+
+<li>Monitoring remote hosts (*NIX, Windows, etc.)
+
+<li>Submitting passive checks from remote hosts
+
+<li>Simplifying/extending the notification logic
+
+<li>...and much more
+
+</ul>
+
+
+
+<p>
+
+You can find many addons for Nagios by visiting:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="http://www.nagios.org/">Nagios.org</a></li>
+
+<li><a href="http://www.sourceforge.net">SourceForge.net</a></li>
+
+<li><a href="http://www.nagiosexchange.org">NagiosExchange.org</a></li>
+
+</ul>
+
+
+
+<p>
+
+I'll give a brief introduction to a few of the addons that I've developed for Nagios...
+
+</p>
+
+
+
+
+
+
+
+<a name="nrpe"></a>
+
+<p><strong><u>NRPE</u></strong></p>
+
+
+
+<p>
+
+<img src="images/nrpe.png" border="0" alt="NRPE" title="NRPE" style="float: right; padding: 0 0 0 10px;">
+
+</p>
+
+
+
+<p>
+
+NRPE is an addon that allows you to execute <a href="plugins.html">plugins</a> on remote Linux/Unix hosts. This is useful if you need to monitor local resources/attributes like disk usage, CPU load, memory usage, etc. on a remote host. Similiar functionality can be accomplished by using the <i>check_by_ssh</i> plugin, although it can impose a higher CPU load on the monitoring machine - especially if you are monitoring hundreds or thousands of hosts.
+
+</p>
+
+
+
+<p>
+
+The NRPE addon and documentation can be found at <a href="http://www.nagios.org/">http://www.nagios.org/</a>.
+
+</p>
+<br clear="all">
+
+
+
+
+<a name="nsca"></a>
+
+<p><strong><u>NSCA</u></strong></p>
+
+
+
+<p>
+
+<img src="images/nsca.png" border="0" alt="NSCA" title="NSCA" style="float: right; padding: 0 0 0 10px;">
+
+</p>
+
+
+
+<p>
+
+NSCA is an addon that allows you to send <a href="passivechecks.html">passive check</a> results from remote Linux/Unix hosts to the Nagios daemon running on the monitoring server. This is very useful in <a href="distributed.html">distributed</a> and <a href="redundancy.html">redundant/failover</a> monitoring setups.
+
+</p>
+
+
+
+<p>
+
+The NSCA addon can be found at <a href="http://www.nagios.org/">http://www.nagios.org/</a>.
+
+</p>
+
+
+
+<br clear="all">
+
+
+
+<a name="ndoutils"></a>
+
+<p><strong><u>NDOUtils</u></strong></p>
+
+
+
+<p>
+
+<img src="images/ndoutils.png" border="0" alt="NDOUtils" title="NDOUtils" style="float: right; padding: 0 0 0 10px;">
+
+</p>
+
+
+
+<p>
+
+NDOUtils is an addon that allows you to store all status information from Nagios in a MySQL database. Multiple instances of Nagios can all store their information in a central database for centralized reporting. This will likely serve as the basis for a new PHP-based web interface for Nagios in the future.
+
+</p>
+
+
+
+<p>
+
+The NDOUtils addon and documentation can be found at <a href="http://www.nagios.org/">http://www.nagios.org/</a>.
+
+</p>
+
+
+
+<br clear="all">
+
+<a name="others"></a>
+
+<p><strong><u>Nagios Exchange - Hundreds of Other Addons</u></strong></p>
+
+
+
+<p>
+
+<a href="http://exchange.nagios.org/" target="_blank"><img src="images/nagiosexchange.png" border="0" alt="Nagios Exchange" title="Nagios Exchange" style="float: right; padding: 0 0 0 10px;"></a>
+
+</p>
+
+<p>
+Hundreds of community-developed Nagios addons can be found on the Nagios Exchange website at <a href="http://exchange.nagios.org" target="_blank">exchange.nagios.org</a>.
+</p>
+
+<br clear="all">
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Advice for Beginners</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Advice for Beginners</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guide</a>
+
+</p>
+
+
+
+
+
+<p>
+
+Congratulations on choosing Nagios! Nagios is quite powerful and flexible, but it can take a lot of work to get it configured just the way you'd like. Once you become familiar with how it works and what it can do for you, you'll never want to be without it. :-) Here are some important things to keep in mind for first-time Nagios users:
+
+</p>
+
+
+
+<ol>
+
+
+
+<li><strong>Relax - it's going to take some time.</strong> Don't expect to be able to get things working exactly the way you want them right off the bat. it's not that easy. Setting up Nagios can involve a bit of work - partly because of the options that Nagios offers, partly because you need to know what to monitor on your network (and how best to do it).<br><br>
+
+
+
+<li><strong>Use the quickstart instructions.</strong> The <a href="quickstart.html">quickstart installation guide</a> is designed to get most new users up and running with a basic Nagios setup fairly quickly. Within 20 minutes you can have Nagios installed and monitoring your local system. Once that's complete, you can move on to learning how to configure Nagios to do more.<br><br>
+
+
+
+<li><strong>Read the documentation.</strong> Nagios can be tricky to configure when you've got a good grasp of what's going on, and nearly impossible if you don't. Make sure you read the documentation (particularly the sections on "Configuring Nagios" and "The Basics"). Save the advanced topics for when you've got a good understanding of the basics.<br><br>
+
+
+
+<li><strong>Seek the help of others.</strong> If you've read the documentation, reviewed the sample config files, and are still having problems, send an email message describing your problems to the <i>nagios-users</i> mailing list. Due to the amount of work that I have to do for this project, I am unable to answer most of the questions that get sent directly to me, so your best source of help is going to be the mailing list. If you've done some background reading and you provide a good problem description, odds are that someone will give you some pointers on getting things working properly. More information on subscribing to the mailing lists or searching the list archives can be found at <a href="http://www.nagios.org/support/">http://www.nagios.org/support/</a>.
+
+</ol>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Cached Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Cached Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="hostchecks.html">Host Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="dependencychecks.html">Predictive Dependency Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/cachedchecks1.png" border="0" style="float: right;" alt="Cached Checks" title="Cached Checks">
+
+
+
+<p>
+
+The performance of Nagios' monitoring logic can be significantly improved by implementing the use of cached checks. Cached checks allow Nagios to forgo executing a host or service check command if it determines a relatively recent check result will do instead.
+
+</p>
+
+
+
+<p>
+
+<strong><u>For On-Demand Checks Only</u></strong>
+
+</p>
+
+
+
+<p>
+
+Regularly scheduled host and service checks will not see a performance improvement with use of cached checks. Cached checks are only useful for improving the performance of on-demand host and service checks. Scheduled checks help to ensure that host and service states are updated regularly, which may result in a greater possibility their results can be used as cached checks in the future.
+
+</p>
+
+
+
+<p>
+
+For reference, on-demand host checks occur...
+
+</p>
+
+
+
+<ul>
+
+<li>When a service associated with the host changes state.</li>
+
+<li>As needed as part of the <a href="networkreachability.html">host reachability</a> logic.</li>
+
+<li>As needed for <a href="dependencychecks.html">predictive host dependency checks</a>.</li>
+
+</ul>
+
+
+
+<p>
+
+And on-demand service checks occur...
+
+</p>
+
+
+
+<ul>
+
+<li>As needed for <a href="dependencychecks.html">predictive service dependency checks</a>.</li>
+
+</ul>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Unless you make use of service dependencies, Nagios will not be able to use cached check results to improve the performance of service checks. Don't worry about that - its normal. Cached host checks are where the big performance improvements lie, and everyone should see a benefit there.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>How Caching Works</u></strong>
+
+</p>
+
+
+
+<img src="images/cachedchecks.png" border="0" style="float: right; clear: both;" alt="Cached Check Logic" title="Cached Check Logic">
+
+
+
+<p>
+
+When Nagios needs to perform an on-demand host or service check, it will make a determination as to whether it can used a cached check result or if it needs to perform an actual check by executing a plugin. It does this by checking to see if the last check of the host or service occured within the last X minutes, where X is the cached host or service check horizon.
+
+</p>
+
+
+
+<p>
+
+If the last check was performed within the timeframe specified by the cached check horizon variable, Nagios will use the result of the last host or service check and will <i>not</i> execute a new check. If the host or service has not yet been checked, or if the last check falls outside of the cached check horizon timeframe, Nagios will execute a new host or service check by running a plugin.
+
+</p>
+
+
+
+<p>
+
+<strong><u>What This Really Means</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios performs on-demand checks because it need to know the current state of a host or service <i>at that exact moment</i> in time. Utilizing cached checks allows you to make Nagios think that recent check results are "good enough" for determining the current state of hosts, and that it doesn't need to go out and actually re-check the status of that host or service.
+
+</p>
+
+
+
+<p>
+
+The cached check horizon tells Nagios how recent check results must be in order to reliably reflect the current state of a host or service. For example, with a cached check horizon of 30 seconds, you are telling Nagios that if a host's state was checked sometime in the last 30 seconds, the result of that check should still be considered the current state of the host.
+
+</p>
+
+
+
+<p>
+
+The number of cached check results that Nagios can use versus the number of on-demand checks it has to actually execute can be considered the cached check "hit" rate. By increasing the cached check horizon to equal the regular check interval of a host, you could theoretically achieve a cache hit rate of 100%. In that case all on-demand checks of that host would use cached check results. What a performance improvement! But is it really? Probably not.
+
+</p>
+
+
+
+<p>
+
+The reliability of cached check result information decreases over time. Higher cache hit rates require that previous check results are considered "valid" for longer periods of time. Things can change quickly in any network scenario, and there's no guarantee that a server that was functioning properly 30 seconds ago isn't on fire right now. There's the tradeoff - reliability versus speed. If you have a large cached check horizon, you risk having unreliable check result values being used in the monitoring logic.
+
+</p>
+
+
+
+<p>
+
+Nagios will eventually determine the correct state of all hosts and services, so even if cached check results prove to unreliably represent their true value, Nagios will only work with incorrect information for a short period of time. Even short periods of unreliable status information can prove to be a nuisance for admins, as they may receive notifications about problems which no longer exist.
+
+</p>
+
+
+
+<p>
+
+There is no standard cached check horizon or cache hit rate that will be acceptable to every Nagios users. Some people will want a short horizon timeframe and a low cache hit rate, while others will want a larger horizon timeframe and a larger cache hit rate (with a low reliability rate). Some users may even want to disable cached checks altogether to obtain a 100% reliability rate. Testing different horizon timeframes, and their effect on the reliability of status information, is the only want that an individual user will find the "right" value for their situation. More information on this is discussed below.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Configuration Variables</u></strong>
+
+</p>
+
+
+
+<p>
+
+The following variables determine the timeframes in which a previous host or service check result may be used as a cached host or service check result:
+
+</p>
+
+
+
+<ul>
+
+<li>The <a href="configmain.html#cached_host_check_horizon">cached_host_check_horizon</a> variable controls cached host checks.</li>
+
+<li>The <a href="configmain.html#cached_service_check_horizon">cached_service_check_horizon</a> variable controls cached service checks.</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Optimizing Cache Effectiveness</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order to make the most effective use of cached checks, you should:
+
+</p>
+
+
+
+<ul>
+
+<li>Schedule regular checks of your hosts</li>
+
+<li>Use MRTG to graph statistics for 1) on-demand checks and 2) cached checks</li>
+
+<li>Adjust cached check horizon variables to fit your needs</li>
+
+</ul>
+
+
+
+<p>
+
+You can schedule regular checks of your hosts by specifying a value greater than 0 for <i>check_interval</i> option in your <a href="objectdefinitions.html#host">host definitions</a>. If you do this, make sure that you set the <i>max_check_attempts</i> option to a value greater than 1, or it will cause a big performance hit. This potential performance hit is describe in detail <a href="hostchecks.html">here</a>.
+
+</p>
+
+
+
+<img src="images/cachedcheckgraphs.png" border="0" style="float: right; clear: both;" alt="Cached Checks Graph" title="Cached Checks Graph">
+
+
+
+<p>
+
+A good way to determine the proper value for the cached check horizon options is to compare how many on-demand checks Nagios has to actually run versus how may it can use cached values for. The <a href="nagiostats.html">nagiostats</a> utility can produce information on cached checks, which can then be <a href="mrtggraphs.html">graphed with MRTG</a>. Example MRTG graphs that show cached vs. actual on-demand checks are shown to the right.
+
+</p>
+
+
+
+<p>
+
+The monitoring installation which produced the graphs above had:
+
+</p>
+
+
+
+<ul>
+
+<li>A total of 44 hosts, all of which were checked at regular intervals</li>
+
+<li>An average (regularly scheduled) host check interval of 5 minutes</li>
+
+<li>A <a href="configmain.html#cached_host_check_horizon">cached_host_check_horizon</a> of 15 seconds</li>
+
+</ul>
+
+
+
+<p>
+
+The first MRTG graph shows how many regularly scheduled host checks compared to how many cached host checks have occured. In this example, an average of 53 host checks occur every five minutes. 9 of these (17%) are on-demand checks.
+
+</p>
+
+
+
+<p>
+
+The second MRTG graph shows how many cached host checks have occurred over time. In this example an average of 2 cached host checks occurs every five minutes.
+
+</p>
+
+
+
+<p>
+
+Remember, cached checks are only available for on-demand checks. Based on the 5 minute averages from the graphs, we see that Nagios is able to used cached host check results every 2 out of 9 times an on-demand check has to be run. That may not seem much, but these graphs represent a small monitoring environment. Consider that 2 out of 9 is 22% and you can start to see how this could significantly help improve host check performance in large environments. That percentage could be higher if the cached host check horizon variable value was increased, but that would reduce the reliability of the cached host state information.
+
+</p>
+
+
+
+<p>
+
+Once you've had a few hours or days worth of MRTG graphs, you should see how many host and service checks were done by executing plugins versus those that used cached check results. Use that information to adjust the cached check horizon variables appropriately for your situation. Continue to monitor the MRTG graphs over time to see how changing the horizon variables affected cached check statistics. Rinse and repeat as necessary.
+
+</p>
+
+
+
+<br clear="all">
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Authentication And Authorization In The CGIs</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Authentication And Authorization In The CGIs</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="configcgi.html">CGI Configuration File Options</a>, <a href="cgis.html">Information on the CGIs</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This documentation describes how the Nagios CGIs decide who has access to view monitoring and configuration information, and who can submit commands to the Nagios daemon through the web interface.
+
+</p>
+
+
+
+
+
+<a name="definitions"></a>
+
+<p>
+
+<strong><u>Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before continuing, it is important that you understand the meaning of and difference between authenticated users and authenticated contacts:
+
+</p>
+
+
+
+<ul>
+
+<li>An <b>authenticated user</b> is an someone who has authenticated to the web server with a username and password and has been granted access to the Nagios web interface.
+
+<li>An <b>authenticated contact</b> is an authenticated user whose username matches the short name of a <a href="objectdefinitions.html#contact">contact definition</a>.
+
+</ul>
+
+
+
+
+
+<p>
+
+<a name="config_web_users"></a>
+
+<strong><u>Setting Up Authenticated Users</u></strong>
+
+</p>
+
+
+
+<p>
+
+Assuming you configured your web server as described in the <a href="quickstart.html">quickstart guide</a>, it should require that you authenticate before accessing the Nagios CGIs. You should also have one user account (<i>nagiosadmin</i>) that can access the CGIs.
+
+</p>
+
+
+
+<p>
+
+As you define more <a href="objectdefinitions.html#contact">contacts</a> for receiving host and service notifications, you'll most likely want to let them access the Nagios web interface. You can use the following command to add additional users who can authenticate to the CGIs. Replace <username> with the actual username you want to add. In most cases, the username should match the short name of a <a href="objectdefinitions.html#contact">contact</a> that has been defined.
+
+</p>
+
+
+
+<pre>
+
+htpasswd /usr/local/nagios/etc/htpasswd.users <username>
+
+</pre>
+
+
+
+<p>
+
+<a name="enable_cgi_auth"></a>
+
+<strong><u>Enabling Authentication/Authorization Functionality In The CGIs</u></strong>
+
+</p>
+
+
+
+<p>
+
+The next thing you need to do is make sure that the CGIs are configured to use the authentication and authorization functionality in determining what information and/or commands users have access to. This is done be setting the <a href="configcgi.html#use_authentication">use_authentication</a> variable in the <a href="configcgi.html">CGI configuration file</a> to a non-zero value. Example:
+
+</p>
+
+
+
+<pre>
+
+use_authentication=1
+
+</pre>
+
+
+
+<p>
+
+Okay, you're now done with setting up basic authentication/authorization functionality in the CGIs.
+
+</p>
+
+
+
+
+
+<p>
+
+<a name="default_rights"></a>
+
+<strong><u>Default Permissions To CGI Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+So what default permissions do users have in the CGIs by default when the authentication/authorization functionality is enabled?
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr bgcolor="#cbcbcb">
+
+<td>CGI Data</td>
+
+<td>Authenticated Contacts<sup><a href="#definitions">*</a></sup></td>
+
+<td>Other Authenticated Users<sup><a href="#definitions">*</a></sup></td>
+
+</tr>
+
+<tr>
+
+<td>Host Status Information</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Host Configuration Information</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Host History</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Host Notifications</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Host Commands</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Service Status Information</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Service Configuration Information</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Service History</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Service Notifications</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>Service Commands</td>
+
+<td bgcolor="#00FF00">Yes</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>All Configuration Information</td>
+
+<td>No</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>System/Process Information</td>
+
+<td>No</td>
+
+<td>No</td>
+
+</tr>
+
+<tr>
+
+<td>System/Process Commands</td>
+
+<td>No</td>
+
+<td>No</td>
+
+</tr>
+
+</table>
+
+
+
+<br>
+
+
+
+<p>
+
+<i>Authenticated contacts<sup><a href="#definitions">*</a></sup></i> are granted the following permissions for each <b>service</b> for which they are contacts (but not for services for which they are not contacts)...
+
+</p>
+
+<ul>
+
+<li>Authorization to view service status information
+
+<li>Authorization to view service configuration information
+
+<li>Authorization to view history and notifications for the service
+
+<li>Authorization to issue service commands
+
+</ul>
+
+
+
+<p>
+
+<i>Authenticated contacts<sup><a href="#definitions">*</a></sup></i> are granted the following permissions for each <b>host</b> for which they are contacts (but not for hosts for which they are not contacts)...
+
+</p>
+
+<ul>
+
+<li>Authorization to view host status information
+
+<li>Authorization to view host configuration information
+
+<li>Authorization to view history and notifications for the host
+
+<li>Authorization to issue host commands
+
+<li>Authorization to view status information for all services on the host
+
+<li>Authorization to view configuration information for all services on the host
+
+<li>Authorization to view history and notification information for all services on the host
+
+<li>Authorization to issue commands for all services on the host
+
+</ul>
+
+
+
+<p>
+
+It is important to note that by default <b>no one</b> is authorized for the following...
+
+</p>
+
+<ul>
+
+<li>Viewing the raw log file via the <a href="cgis.html#showlog_cgi">showlog CGI</a>
+
+<li>Viewing Nagios process information via the <a href="cgis.html#extinfo_cgi">extended information CGI</a>
+
+<li>Issuing Nagios process commands via the <a href="cgis.html#cmd_cgi">command CGI</a>
+
+<li>Viewing host group, contact, contact group, time period, and command definitions via the <a href="cgis.html#config_cgi">configuration CGI</a>
+
+</ul>
+
+
+
+<p>
+
+You will undoubtably want to access this information, so you'll have to assign additional rights for yourself (and possibly other users) as described below...
+
+</p>
+
+
+
+<p>
+
+<a name="additional_rights"></a>
+
+<strong><u>Granting Additional Permissions To CGI Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can grant <i>authenticated contacts</i> or other <i>authenticated users</i> permission to additional information in the CGIs by adding them to various authorization variables in the <a href="configcgi.html">CGI configuration file</a>. I realize that the available options don't allow for getting really specific about particular permissions, but its better than nothing..
+
+</p>
+
+
+
+<p>
+
+Additional authorization can be given to users by adding them to the following variables in the CGI configuration file...
+
+</p>
+
+<ul>
+
+<li><a href="configcgi.html#authorized_for_system_information">authorized_for_system_information</a>
+
+<li><a href="configcgi.html#authorized_for_system_commands">authorized_for_system_commands</a>
+
+<li><a href="configcgi.html#authorized_for_configuration_information">authorized_for_configuration_information</a>
+
+<li><a href="configcgi.html#authorized_for_all_hosts">authorized_for_all_hosts</a>
+
+<li><a href="configcgi.html#authorized_for_all_host_commands">authorized_for_all_host_commands</a>
+
+<li><a href="configcgi.html#authorized_for_all_services">authorized_for_all_services</a>
+
+<li><a href="configcgi.html#authorized_for_all_service_commands">authorized_for_all_service_commands</a>
+
+</ul>
+
+
+
+<p>
+
+<a name="cgi_auth_requirements"></a>
+
+<strong><u>CGI Authorization Requirements</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you are confused about the authorization needed to access various information in the CGIs, read the <i><b>Authorization Requirements</b></i> section for each CGI as described <a href="cgis.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<a name="secure_web_servers"></a>
+
+<strong><u>Authentication On Secured Web Servers</u></strong>
+
+</p>
+
+
+
+<p>
+
+If your web server is located in a secure domain (i.e., behind a firewall) or if you are using SSL, you can define a default username that can be used to access the CGIs. This is done by defining the <a href="configcgi.html#default_user_name">default_user_name</a> option in the <a href="configcgi.html">CGI configuration file</a>. By defining a default username that can access the CGIs, you can allow users to access the CGIs without necessarily having to authenticate to the web server. You may want to use this to avoid having to use basic web authentication, as basic authentication transmits passwords in clear text over the Internet.
+
+</p>
+
+<p>
+
+<strong>Important:</strong> Do <i>not</i> define a default username unless you are running a secure web server and are sure that everyone who has access to the CGIs has been authenticated in some manner. If you define this variable, anyone who has not authenticated to the web server will inherit all rights you assign to this user!
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Custom CGI Headers and Footers</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Custom CGI Headers and Footers</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="cgis.html">Information on the CGIs</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you're doing custom installs of Nagios for clients, you may want to have a custom header and/or footer displayed in the output of the <a href="cgis.html">CGIs</a>. This is particularly useful for displaying support contact information, etc. to the end user.
+
+</p>
+
+
+
+<p>
+
+It is important to note that, unless they are executable, custom header and footer files are not pre-processed in any way before they are displayed. The contents of the header and footer include files are simply read and displayed in the CGI output. That means they can only contain information a web browser can understand (HTML, JavaScript, etc.).
+
+</p>
+
+
+
+<p>
+
+If the custom header and footer files are executable, then the files are executed and their output returned to the user, so they should output valid HTML. Using this you can run your own custom designed CGI to insert data into the nagios display. This has been used to insert graphs from rrdtool using ddraw and command menus into the nagios display pane. The execuable customer header and footer files are run with the same CGI environment as the main nagios CGI, so your files can parse the query information, authenticated user information, etc. to produce appropriate output.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>How Does It Work?</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can include custom headers and footers in the output of the CGIs by dropping some appropriately named HTML files in the <i>ssi/</i> subdirectory of the Nagios HTML directory (i.e. <i>/usr/local/nagios/share/ssi</i>).
+
+</p>
+
+
+
+<p>
+
+Custom headers are included immediately after the <BODY>> tag in the CGI output, while custom footers are included immediately before the closing </BODY> tag.
+
+</p>
+
+
+
+<p>There are two types of customer headers and footers:
+
+</p>
+
+
+
+<ul>
+
+<li>Global headers/footers. These files should be named <i>common-header.ssi</i> and <i>common-footer.ssi</i>, respectively. If these files exist, they will be included in the output of all CGIs.<br><br>
+
+<li>CGI-specific headers/footers. These files should be named in the format <i>CGINAME-header.ssi</i> and <i>CGINAME-footer.ssi</i>, where <i>CGINAME</i> is the physical name of the CGI without the .cgi extension. For example, the header and footer files for the <a href="cgis.html#summary_cgi">alert summary CGI</a> (summary.cgi) would be named <i>summary-header.ssi</i> and <i>summary-footer.ssi</i>, respectively.
+
+</ul>
+
+
+
+<p>
+
+You are not required to use any custom headers or footers. You can use only a global header if you wish. You can use only CGI-specific headers and a global footer if you wish. Whatever you want. Really.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Information On The CGIs</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Information On The CGIs</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="configcgi.html">CGI Configuration File Options</a>, <a href="cgiauth.html">Authentication And Authorization In The CGIs</a>, <a href="cgiincludes.html">CGI Footers and Headers</a>, <a href="cgisecurity.html">CGI Security</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+The various CGIs distributed with Nagios are described here, along with the authorization requirements for accessing and using each CGI. By default the CGIs require that you have authenticated to the web server and are authorized to view any information you are requesting. More information on configuring authorization can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Index</u></strong>
+
+</p>
+
+<p>
+
+<a href="#status_cgi">Status CGI</a><br>
+
+<a href="#statusmap_cgi">Status map CGI</a><br>
+
+<a href="#statuswml_cgi">WAP interface CGI</a><br>
+
+<a href="#statuswrl_cgi">Status world CGI (VRML)</a><br>
+
+<a href="#tac_cgi">Tactical overview CGI</a><br>
+
+<a href="#outages_cgi">Network outages CGI</a><br>
+
+<a href="#config_cgi">Configuration CGI</a><br>
+
+<a href="#cmd_cgi">Command CGI</a><br>
+
+<a href="#extinfo_cgi">Extended information CGI</a><br>
+
+<a href="#showlog_cgi">Event log CGI</a><br>
+
+<a href="#history_cgi">Alert history CGI</a><br>
+
+<a href="#notifications_cgi">Notifications CGI</a><br>
+
+<a href="#trends_cgi">Trends CGI</a><br>
+
+<a href="#avail_cgi">Availability reporting CGI</a><br>
+
+<a href="#histogram_cgi">Alert histogram CGI</a><br>
+
+<a href="#summary_cgi">Alert summary CGI</a><br>
+
+</p>
+
+
+
+
+
+<a name="status_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb" ><strong>Status CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-status-a.png" border=0 alt="Status CGI - Details"></td>
+
+<td align=left><img src="images/cgi-status-b.png" border=0 alt="Status CGI - Overview"></td>
+
+<td align=left><img src="images/cgi-status-c.png" border=0 alt="Status CGI - Summary"></td>
+
+<td align=left><img src="images/cgi-status-d.png" border=0 alt="Status CGI - Grid"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>status.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This is the most important CGI included with Nagios. It allows you to view the current status of all hosts and services that are being monitored. The status CGI can produce two main types of output - a status overview of all host groups (or a particular host group) and a detailed view of all services (or those associated with a particular host).
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view all services.
+
+<li>If you are an <i>authenticated contact</i> you can view all hosts and services for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="statusmap_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Status Map CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-statusmap.png" border=0 alt="Status Map CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>statusmap.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI creates a map of all hosts that you have defined on your network. The CGI uses Thomas Boutell's <a href="http://www.boutell.com/gd/">gd</a> library (version 1.6.3 or higher) to create a PNG image of your network layout. The coordinates used when drawing each host (along with the optional pretty icons) are taken from <a href="objectdefinitions.html#host">host</a> definitions. If you'd prefer to let the CGI automatically generate drawing coordinates for you, use the <a href="configcgi.html#default_statusmap_layout">default_statusmap_layout</a> directive to specify a layout algorithm that should be used.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view all hosts.
+
+<li>If you are an <i>authenticated contact</i> you can view hosts for which you are a contact.
+
+</ul>
+
+<br>
+
+Note: Users who are not authorized to view specific hosts will see <i>unknown</i> nodes in those positions. I realize that they really shouldn't see <i>anything</i> there, but it doesn't make sense to even generate the map if you can't see all the host dependencies...
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="statuswml_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>WAP Interface CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-statuswml.png" border=0 alt="WAP Interface CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>statuswml.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI serves as a WAP interface to network status information. If you have a WAP-enabled device (i.e. an Internet-ready cellphone), you can view status information while you're on the go. Different status views include hostgroup summary, hostgroup overview, host detail, service detail, all problems, and unhandled problems. In addition to viewing status information, you can also disable notifications and checks and acknowledge problems from your cellphone. Pretty cool, huh?
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_system_information"><i>authorized for system information</i></a> you can view Nagios process information.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view status data for all hosts <b>and</b> services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view status data for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view status data for all hosts and services for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="statuswrl_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Status World CGI (VRML)</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-statuswrl.png" border=0 alt="3-D Status Map CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>statuswrl.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI creates a 3-D VRML model of all hosts that you have defined on your network. Coordinates used when drawing the hosts (as well as pretty texture maps) are taken from <a href="objectdefinitions.html#host">host</a> definitions. If you'd prefer to let the CGI automatically generate drawing coordinates for you, use the <a href="configcgi.html#default_statuswrl_layout">default_statuswrl_layout</a> directive to specify a layout algorithm that should be used. You'll need a VRML browser (like <a href="http://www.parallelgraphics.com/cortona/">Cortona</a>, <a href="http://www.cosmosoftware.com">Cosmo Player</a> or <a href="http://www.intervista.com">WorldView</a>) installed on your system before you can actually view the generated model.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view all hosts.
+
+<li>If you are an <i>authenticated contact</i> you can view hosts for which you are a contact.
+
+</ul>
+
+<br>
+
+Note: Users who are not authorized to view specific hosts will see <i>unknown</i> nodes in those positions. I realize that they really shouldn't see <i>anything</i> there, but it doesn't make sense to even generate the map if you can't see all the host dependencies...
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="tac_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb" ><strong>Tactical Overview CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-tac.png" border=0 alt="Tactical Overview CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>tac.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI is designed to server as a "birds-eye view" of all network monitoring activity. It allows you to quickly see network outages, host status, and service status. It distinguishes between problems that have been "handled" in some way (i.e. been acknowledged, had notifications disabled, etc.) and those which have not been handled, and thus need attention. Very useful if you've got a lot of hosts/services you're monitoring and you need to keep a single screen up to alert you of problems.
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view all services.
+
+<li>If you are an <i>authenticated contact</i> you can view all hosts and services for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="outages_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Network Outages CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-outages.png" border=0 alt="Network Outages CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>outages.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI will produce a listing of "problem" hosts on your network that are causing network outages. This can be particularly useful if you have a large network and want to quickly identify the source of the problem. Hosts are sorted based on the severity of the outage they are causing.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view all hosts.
+
+<li>If you are an <i>authenticated contact</i> you can view hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<a name="config_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Configuration CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-config.png" border=0 alt="Configuration CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>config.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI allows you to view objects (i.e. hosts, host groups, contacts, contact groups, time periods, services, etc.) that you have defined in your <a href="configobject.html">object configuration file(s)</a>.
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>You must be <a href="configcgi.html#authorized_for_configuration_information"><i>authorized for configuration information</i></a> in order to any kind of configuration information.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<a name="cmd_cgi"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Command CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-cmd.png" border=0 alt="Command CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>cmd.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI allows you to send commands to the Nagios process. Although this CGI has several arguments, you would be better to leave them alone. Most will change between different revisions of Nagios. Use the <a href="#extinfo_cgi">extended information CGI</a> as a starting point for issuing commands.
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>You must be <a href="configcgi.html#authorized_for_system_commands"><i>authorized for system commands</i></a> in order to issue commands that affect the Nagios process (restarts, shutdowns, mode changes, etc.).
+
+<li>If you are <a href="configcgi.html#authorized_for_all_host_commands"><i>authorized for all host commands</i></a> you can issue commands for all hosts <b>and</b> services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_service_commands"><i>authorized for all service commands</i></a> you can issue commands for all services.
+
+<li>If you are an <i>authenticated contact</i> you can issue commands for all hosts and services for which you are a contact.
+
+</ul>
+
+<strong>Notes:</strong>
+
+<ul>
+
+<li>If you have chosen not to <a href="configcgi.html#use_authentication">use authentication</a> with the CGIs, this CGI will <i>not</i> allow anyone to issue commands to Nagios. This is done for your own protection. I would suggest removing this CGI altogether if you decide not to use authentication with the CGIs.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<a name="extinfo_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Extended Information CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-extinfo-a.png" border=0 alt="Extended Information CGI - Process Information"></td>
+
+<td align=left><img src="images/cgi-extinfo-b.png" border=0 alt="Extended Information CGI - Performance Information"></td>
+
+<td align=left><img src="images/cgi-extinfo-c.png" border=0 alt="Extended Information CGI - Host Information"></td>
+
+<td align=left><img src="images/cgi-extinfo-d.png" border=0 alt="Extended Information CGI - Service Information"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>extinfo.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI allows you to view Nagios process information, host and service state statistics, host and service comments, and more. It also serves as a launching point for sending commands to Nagios via the <a href="#cmd_cgi">command CGI</a>. Although this CGI has several arguments, you would be better to leave them alone - they are likely to change between different releases of Nagios. You can access this CGI by clicking on the 'Network Health' and 'Process Information' links on the side navigation bar, or by clicking on a host or service link in the output of the <a href="#status_cgi">status CGI</a>.
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>You must be <a href="configcgi.html#authorized_for_system_information"><i>authorized for system information</i></a> in order to view Nagios process information.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view extended information for all hosts <b>and</b> services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view extended information for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view extended information for all hosts and services for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<a name="showlog_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Event Log CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-showlog.png" border=0 alt="Event Log CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>showlog.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI will display the <a href="configmain.html#log_file">log file</a>. If you have <a href="configmain.html#log_rotation_method">log rotation</a> enabled, you can browse notifications present in archived log files by using the navigational links near the top of the page.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>You must be <a href="configcgi.html#authorized_for_system_information"><i>authorized for system information</i></a> in order to view the log file.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<a name="history_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Alert History CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-history.png" border=0 alt="Alert History CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>history.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI is used to display the history of problems with either a particular host or all hosts. The output is basically a subset of the information that is displayed by the <a href="#showlog_cgi">log file CGI</a>. You have the ability to filter the output to display only the specific types of problems you wish to see (i.e. hard and/or soft alerts, various types of service and host alerts, all types of alerts, etc.). If you have <a href="configmain.html#log_rotation_method">log rotation</a> enabled, you can browse history information present in archived log files by using the navigational links near the top of the page.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view history information for all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view history information for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view history information for all services and hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<a name="notifications_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Notifications CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-notifications.png" border=0 alt="Notifications CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>notifications.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI is used to display host and service notifications that have been sent to various contacts. The output is basically a subset of the information that is displayed by the <a href="#showlog_cgi">log file CGI</a>. You have the ability to filter the output to display only the specific types of notifications you wish to see (i.e. service notifications, host notifications, notifications sent to specific contacts, etc). If you have <a href="configmain.html#log_rotation_method">log rotation</a> enabled, you can browse notifications present in archived log files by using the navigational links near the top of the page.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view notifications for all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view notifications for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view notifications for all services and hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="trends_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Trends CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-trends.png" border=0 alt="Trends CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>trends.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI is used to create a graph of host or service states over an arbitrary period of time. In order for this CGI to be of much use, you should enable <a href="configmain.html#log_rotation_method">log rotation</a> and keep archived logs in the path specified by the <a href="configmain.html#log_archive_path">log_archive_path</a> directive. The CGI uses Thomas Boutell's <a href="http://www.boutell.com/gd/">gd</a> library (version 1.6.3 or higher) to create the trends image.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view trends for all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view trends for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view trends for all services and hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<a name="avail_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Availability Reporting CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-avail-a.png" border=0 alt="Availability CGI - Hostgroup"></td>
+
+<td align=left><img src="images/cgi-avail-b.png" border=0 alt="Availability CGI - Host"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>avail.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI is used to report on the availability of hosts and services over a user-specified period of time. In order for this CGI to be of much use, you should enable <a href="configmain.html#log_rotation_method">log rotation</a> and keep archived logs in the path specified by the <a href="configmain.html#log_archive_path">log_archive_path</a> directive.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view availability data for all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view availability data for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view availability data for all services and hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<a name="histogram_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Alert Histogram CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-histogram.png" border=0 alt="Alert Histogram CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>histogram.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI is used to report on the availability of hosts and services over a user-specified period of time. In order for this CGI to be of much use, you should enable <a href="configmain.html#log_rotation_method">log rotation</a> and keep archived logs in the path specified by the <a href="configmain.html#log_archive_path">log_archive_path</a> directive. The CGI uses Thomas Boutell's <a href="http://www.boutell.com/gd/">gd</a> library (version 1.6.3 or higher) to create the histogram image.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view histograms for all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view histograms for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view histograms for all services and hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<a name="summary_cgi"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Alert Summary CGI</strong></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td align=left><img src="images/cgi-summary.png" border=0 alt="Alert Summary CGI"></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>File Name:</td>
+
+<td><font color="red"><strong>summary.cgi</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td align=left valign=top width="50%">
+
+<p>
+
+<strong>Description:</strong><br>
+
+This CGI provides some generic reports about host and service alert data, including alert totals, top alert producers, etc.
+
+</p>
+
+<p>
+
+<strong>Authorization Requirements:</strong><br>
+
+<ul class="Default">
+
+<li>If you are <a href="configcgi.html#authorized_for_all_hosts"><i>authorized for all hosts</i></a> you can view summary information for all hosts <b>and</b> all services.
+
+<li>If you are <a href="configcgi.html#authorized_for_all_services"><i>authorized for all services</i></a> you can view summary information for all services.
+
+<li>If you are an <i>authenticated contact</i> you can view summary information for all services and hosts for which you are a contact.
+
+</ul>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Enhanced CGI Security and Authentication</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+ .Code { font-family: "Courier New" Courier monospace;}
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Enhanced CGI Security and Authentication</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="security.html">Security Considerations</a>, <a href="config.html">Configuration Overview</a>
+
+</p>
+
+
+
+<p>
+
+<a name="intro"></a>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/security.png" border="0" style="float: right; clear: both;" alt="Security" title="Security">
+
+
+
+<p>
+
+This is intended to be an introduction for implementation of stronger authentication and server security focused around the CGI web interface.
+
+</p>
+
+
+
+<p>
+
+There are many ways to enhance the security of your monitoring server and Nagios environment. This should not be taken as the end all approach to security. Instead, think of it as an introduction to some of the techniques you can use to tighten the security of your system. As always, you should do your research and use the best techniques available. Treat your monitoring server as it were the most important server in your network and you shall be rewarded.
+
+</p>
+
+
+
+<br />
+
+<p>
+
+<a name="additionaltechniques"></a>
+
+<strong><u>Additional Techniques</u></strong>
+
+</p>
+
+
+
+<ul>
+
+<li><strong>Stronger Authentication using Digest Authentication</strong>. If you have followed the <a href="quickstart.html">quickstart guides</a>, chances are that you are using Apache's <a href="http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html">Basic Authentication</a>. Basic Authentication will send your username and password in "clear text" with every http request. Consider using a more secure method of authentication such as <a href="http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html">Digest Authentication</a> which creates a MD5 Hash of your username and password to send with each request.<br /><br /></li>
+
+
+
+<li><strong>Forcing TLS/SSL for all Web Communication</strong>. Apache provides <a href="http://en.wikipedia.org/wiki/Transport_Layer_Security">TLS/SSL</a> through the <a href="http://httpd.apache.org/docs/2.2/mod/mod_ssl.html">mod_ssl</a> module. TLS/SSL provides a secure tunnel between the client and server that prevents eavesdropping and tampering using strong publickey/privatekey cryptography.<br /><br /></li>
+
+
+
+<li><strong>Locking Down Apache Using Access Controls</strong>. Consider locking down access to the Nagios box to your IP address, IP address range, or IP subnet. If you require access outside your network you could use VPN or SSH Tunnels. This is a easy and strong to limit access to HTTP/HTTPS on your system.</li>
+
+</ul>
+
+
+
+
+
+<br />
+
+<p>
+
+<a name="implementation-digest"></a>
+
+<strong><u>Implementing Digest Authentication</u></strong>
+
+</p>
+
+
+
+<p>
+
+The implementation of Digest Authentication is simple. You will have to create the new type of password file using the <a href="http://httpd.apache.org/docs/2.2/programs/htdigest.html">'htdigest'</a> tool, then modify the Apache configuration for nagios (typically /etc/httpd/conf.d/nagios.conf).
+
+</p>
+
+
+
+<p>
+
+Create a new passwords file using the <a href="http://httpd.apache.org/docs/2.2/programs/htdigest.html">'htdigest'</a> tool. The difference that you will notice if you are familiar with <a href="http://httpd.apache.org/docs/2.2/programs/htpasswd.html">'htpasswd'</a> tools is the requirement to supply a 'realm' argument. Where 'realm' in this case refers to the value of the 'AuthName' directive in the Apache configuration.
+
+</p>
+
+
+
+<pre>
+
+htdigest -c /usr/local/nagios/etc/.digest_pw "Nagios Access" nagiosadmin
+
+</pre>
+
+
+
+<p>
+
+Next, edit the Apache configuration file for Nagios (typically /etc/httpd/conf.d/nagios.conf) using the following example.
+
+</p>
+
+
+
+<pre>
+
+## BEGIN APACHE CONFIG SNIPPET - NAGIOS.CONF
+
+ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"
+
+<Directory "/usr/local/nagios/sbin">
+
+ Options ExecCGI
+
+ AllowOverride None
+
+ Order allow,deny
+
+ Allow from all
+
+ AuthType Digest
+
+ AuthName "Nagios Access"
+
+ AuthUserFile /usr/local/nagios/etc/.digest_pw
+
+ Require valid-user
+
+</Directory>
+
+
+
+Alias /nagios "/usr/local/nagios/share"
+
+<Directory "/usr/local/nagios/share">
+
+ Options None
+
+ AllowOverride None
+
+ Order allow,deny
+
+ Allow from all
+
+ AuthType Digest
+
+ AuthName "Nagios Access"
+
+ AuthUserFile /usr/local/nagios/etc/.digest_pw
+
+ Require valid-user
+
+</Directory>
+
+## END APACHE CONFIG SNIPPETS
+
+</pre>
+
+
+
+<p>
+
+Then, restart the Apache service so the new settings can take effect.
+
+</p>
+
+
+
+<pre>
+
+/etc/init.d/httpd restart
+
+</pre>
+
+
+
+
+
+
+
+<br />
+
+<p>
+
+<a name="implementation-ssl"></a>
+
+<strong><u>Implementing Forced TLS/SSL</u></strong>
+
+</p>
+
+
+
+<p>
+
+Make sure you've installed Apache and OpenSSL. By default you should have <a href="http://httpd.apache.org/docs/2.2/mod/mod_ssl.html">mod_ssl</a> support if you are still having trouble you may find help reading Apache's <a href="http://httpd.apache.org/docs/2.0/ssl">TLS/SSL Encryption Documentation</a>.
+
+</p>
+
+
+
+</p>
+
+Next, verify that TLS/SSL support is working by visiting your Nagios Web Interface using HTTPS (https://your.domain/nagios). If it is working you can continue on to the next steps that will force using HTTPS and block all HTTP requests for the Nagios Web Interface. If you are having trouble visit Apache's <a href="http://httpd.apache.org/docs/2.0/ssl">TLS/SSL Encryption Documentation</a> and <a href="http://www.google.com">Google</a> for troubleshooting your specific Apache installation.
+
+<p>
+
+
+
+<p>
+
+Next, edit the Apache configuration file for Nagios (typically /etc/httpd/conf.d/nagios.conf) by adding the 'SSLRequireSSL' directive to both the 'sbin' and 'share' directories.
+
+</p>
+
+
+
+<pre>
+
+## BEGIN APACHE CONFIG SNIPPET - NAGIOS.CONF
+
+ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"
+
+<Directory "/usr/local/nagios/sbin">
+
+ ...
+
+ SSLRequireSSL
+
+ ...
+
+</Directory>
+
+
+
+Alias /nagios "/usr/local/nagios/share"
+
+<Directory "/usr/local/nagios/share">
+
+ ...
+
+ SSLRequireSSL
+
+ ...
+
+</Directory>
+
+## END APACHE CONFIG SNIPPETS
+
+</pre>
+
+
+
+<p>
+
+Restart the Apache service so the new settings can take effect.
+
+</p>
+
+
+
+<pre>
+
+/etc/init.d/httpd restart
+
+</pre>
+
+
+
+
+
+
+
+<br />
+
+<p>
+
+<a name="implementation-lockdown"></a>
+
+<strong><u>Implementing IP subnet lockdown</u></strong>
+
+</p>
+
+
+
+<p>
+
+The following example will show how to lock down Nagios CGIs to a specific IP address, IP address range, or IP subnet using Apache's <a href="http://httpd.apache.org/docs/2.2/howto/access.html">access controls</a>.
+
+</p>
+
+
+
+<p>
+
+Edit the Apache configuration file for Nagios (typically /etc/httpd/conf.d/nagios.conf) by using the 'Allow', 'Deny', and 'Order' directives using the following as an example.
+
+</p>
+
+
+
+<pre>
+
+## BEGIN APACHE CONFIG SNIPPET - NAGIOS.CONF
+
+ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"
+
+<Directory "/usr/local/nagios/sbin">
+
+ ...
+
+ AllowOverride None
+
+ Order deny,allow
+
+ Deny from all
+
+ Allow from 127.0.0.1 10.0.0.25 # Allow single IP addresses
+
+ Allow from 10.0.0.0/255.255.255.0 # Allow network/netmask pair
+
+ Allow from 10.0.0.0/24 # Allow network/nnn CIDR spec
+
+ ...
+
+</Directory>
+
+
+
+Alias /nagios "/usr/local/nagios/share"
+
+<Directory "/usr/local/nagios/share">
+
+ ...
+
+ AllowOverride None
+
+ Order deny,allow
+
+ Deny from all
+
+ Allow from 127.0.0.1 10.0.0.25 # Allow single IP addresses
+
+ Allow from 10.0.0.0/255.255.255.0 # Allow network/netmask pair
+
+ Allow from 10.0.0.0/24 # Allow network/nnn CIDR spec
+
+ ...
+
+</Directory>
+
+## END APACHE CONFIG SNIPPET
+
+</pre>
+
+
+
+
+
+<br />
+
+<p>
+
+<a name="importantnotes"></a>
+
+<strong><u>Important Notes</u></strong>
+
+</p>
+
+
+
+<ul>
+
+<li><strong>Digest Authentication sends data in the clear but not your username and password</strong>.<br /><br /></li>
+
+
+
+<li><strong>Digest Authentication is not as universally supported as Basic Authentication</strong>.<br /><br /></li>
+
+
+
+<li><strong>TLS/SSL has potential for "<a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle attacks</a>"</strong>. MITM attacks are vulnerable if an attacker is able to insert itself between the server and client such as in a Phishing attack, ISP monitoring, or corporate LAN firewall certificate resigning. So read up on certificate verification! <br /><br /></li>
+
+
+
+<li><strong>Apache access controls only protect the HTTP/HTTPS protocols</strong>. Look into <a href="http://www.netfilter.org/projects/iptables/index.html">IPtables</a> for strong system wide firewall control.<br /><br /></li>
+
+
+
+<li><strong>Most importantly, Security is a moving target so stay informed and do research</strong>! Perhaps by listening to a Podcast such as "<a href="http://www.grc.com/securitynow.htm">Security Now!</a>".<br /><br /></li>
+
+
+
+</ul>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Service and Host Check Scheduling</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Service and Host Check Scheduling</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="activechecks.html">Active Checks</a>
+
+</p>
+
+
+
+
+
+<a name="service_inter_check_delay"></a>
+
+<a name="service_interleaving"></a>
+
+<a name="max_concurrent_checks"></a>
+
+<a name="host_inter_check_delay"></a>
+
+
+
+<p>
+
+<strong><u>TODO</u></strong>
+
+</p>
+
+
+
+<p>
+
+This documentation is being rewritten for Nagios 3. Stay tuned for more information in a later beta release...
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Service and Host Clusters</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Service and Host Clusters</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="activechecks.html">Active Checks</a>, <a href="macros.html">Macros</a>
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Several people have asked how to go about monitoring clusters of hosts or services, so I decided to write up a little documentation on how to do this. Its fairly straightforward, so hopefully you find things easy to understand...
+
+</p>
+
+
+
+<p>
+
+First off, we need to define what we mean by a "cluster". The simplest way to understand this is with an example. Let's say that your organization has five hosts which provide redundant DNS services to your organization. If one of them fails, its not a major catastrophe because the remaining servers will continue to provide name resolution services. If you're concerned with monitoring the availability of DNS service to your organization, you will want to monitor five DNS servers. This is what I consider to be a <i>service</i> cluster. The service cluster consists of five separate DNS services that you are monitoring. Although you do want to monitor each individual service, your main concern is with the overall status of the DNS service cluster, rather than the availability of any one particular service.
+
+</p>
+
+
+
+<p>
+
+If your organization has a group of hosts that provide a high-availability (clustering) solution, I would consider those to be a <i>host</i> cluster. If one particular host fails, another will step in to take over all the duties of the failed server. As a side note, check out the <a href="http://www.linux-ha.org">High-Availability Linux Project</a> for information on providing host and service redundancy with Linux.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Plan of Attack</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are several ways you could potentially monitor service or host clusters. I'll describe the method that I believe to be the easiest. Monitoring service or host clusters involves two things:
+
+</p>
+
+
+
+<ul>
+
+<li>Monitoring individual cluster elements
+
+<li>Monitoring the cluster as a collective entity
+
+</ul>
+
+
+
+<p>
+
+Monitoring individual host or service cluster elements is easier than you think. In fact, you're probably already doing it. For service clusters, just make sure that you are monitoring each service element of the cluster. If you've got a cluster of five DNS servers, make sure you have five separate service definitions (probably using the <i>check_dns</i> plugin). For host clusters, make sure you have configured appropriate host definitions for each member of the cluster (you'll also have to define at least one service to be monitored for each of the hosts). <b>Important:</b> You're going to want to disable notifications for the individual cluster elements (host or service definitions). Even though no notifications will be sent about the individual elements, you'll still get a visual display of the individual host or service status in the <a href="cgis.html#status_cgi">status CGI</a>. This will be useful for pinpointing the source of problems within the cluster in the future.
+
+</p>
+
+
+
+<p>
+
+Monitoring the overall cluster can be done by using the previously cached results of cluster elements. Although you could re-check all elements of the cluster to determine the cluster's status, why waste bandwidth and resources when you already have the results cached? Where are the results cached? Cached results for cluster elements can be found in the <a href="configmain.html#status_file">status file</a> (assuming you are monitoring each element). The <i>check_cluster</i> plugin is designed specifically for checking cached host and service states in the status file. <b>Important:</b> Although you didn't enable notifications for individual elements of the cluster, you will want them enabled for the overall cluster status check.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Using the <i>check_cluster</i> Plugin</u></strong>
+
+</p>
+
+
+
+<p>
+
+The check_cluster plugin is designed to report the overall status of a host or service cluster by checking the status information of each individual host or service cluster elements.
+
+</p>
+
+
+
+<p>
+
+More to come... The <i>check_cluster</i> plugin can be found in the contrib directory of the Nagios Plugins release at <a
+
+href="http://sourceforge.net/projects/nagiosplug/">http://sourceforge.net/projects/nagiosplug/</a>.
+
+
+
+</p>
+
+
+
+<p>
+
+<strong><u>Monitoring Service Clusters</u></strong>
+
+</p>
+
+
+
+<p>
+
+Let's say you have three DNS servers that provide redundant services on your network. First off, you need to be monitoring each of these DNS servers seperately before you can monitor them as a cluster. I'll assume that you already have three seperate services (all called "DNS Service") associated with your DNS hosts (called "host1", "host2" and "host3").
+
+</p>
+
+
+
+<p>
+
+In order to monitor the services as a cluster, you'll need to create a new "cluster" service. However, before you do that, make sure you have a service cluster check command configured. Let's assume that you have a command called <i>check_service_cluster</i> defined as follows:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_service_cluster
+
+ command_line /usr/local/nagios/libexec/check_cluster --service -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now you'll need to create the "cluster" service and use the <i>check_service_cluster</i> command you just created as the cluster's check command. The example below gives an example of how to do this. The example below will generate a CRITICAL alert if 2 or more services in the cluster are in a non-OK state, and a WARNING alert if only 1 of the services is in a non-OK state. If all the individual service members of the cluster are OK, the cluster check will return an OK state as well.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ ...
+
+ check_command check_service_cluster!"DNS Cluster"!1!2!$SERVICESTATEID:host1:DNS Service$,$SERVICESTATEID:host2:DNS Service$,$SERVICESTATEID:host3:DNS Service$
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+It is important to notice that we are passing a comma-delimited list of <i>on-demand</i> service state <a href="macros.html">macros</a> to the $ARG4$ macro in the cluster check command. That's important! Nagios will fill those on-demand macros in with the current service state IDs (numerical values, rather than text strings) of the individual members of the cluster.
+
+</p>
+
+
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring Host Clusters</u></strong>
+
+</p>
+
+
+
+<p>
+
+Monitoring host clusters is very similiar to monitoring service clusters. Obviously, the main difference is that the cluster members are hosts and not services. In order to monitor the status of a host cluster, you must define a service that uses the <i>check_cluster</i> plugin. The service should <i>not</i> be associated with any of the hosts in the cluster, as this will cause problems with notifications for the cluster if that host goes down. A good idea might be to associate the service with the host that Nagios is running on. After all, if the host that Nagios is running on goes down, then Nagios isn't running anymore, so there isn't anything you can do as far as monitoring (unless you've setup <a href="redundancy.html">redundant monitoring hosts</a>)...
+
+</p>
+
+
+
+<p>
+
+Anyway, let's assume that you have a <i>check_host_cluster</i> command defined as follows:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_host_cluster
+
+ command_line /usr/local/nagios/libexec/check_cluster --host -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Let's say you have three hosts (named "host1", "host2" and "host3") in the host cluster. If you want Nagios to generate a warning alert if one host in the cluster is not UP or a critical alert if two or more hosts are not UP, the the service you define to monitor the host cluster might look something like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ ...
+
+ check_command check_host_cluster!"Super Host Cluster"!1!2!$HOSTSTATEID:host1$,$HOSTSTATEID:host2$,$HOSTSTATEID:host3$
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+It is important to notice that we are passing a comma-delimited list of <i>on-demand</i> host state <a href="macros.html">macros</a> to the $ARG4$ macro in the cluster check command. That's important! Nagios will fill those on-demand macros in with the current host state IDs (numerical values, rather than text strings) of the individual members of the cluster.
+
+</p>
+
+
+
+<p>
+
+That's it! Nagios will periodically check the status of the host cluster and send notifications to you when its status is degraded (assuming you've enabled notification for the service). Note that for thehost definitions of each cluster member, you will most likely want to disable notifications when the host goes down . Remeber that you don't care as much about the status of any individual host as you do the overall status of the cluster. Depending on your network layout and what you're trying to accomplish, you may wish to leave notifications for unreachable states enabled for the host definitions.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Configuration Overview</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Configuration Overview</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="configmain.html">Main Configuration File</a>, <a href="configobject.html">Object Configuration Overview</a>, <a href="configcgi.html">CGI Configuration File</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are several different configuration files that you're going to need to create or edit before you start monitoring anything. Be patient! Configuring Nagios can take quite a while, especially if you're first-time user. Once you figure out how things work, it'll all be well worth your time. :-)
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Sample configuration files are installed in the <i>/usr/local/nagios/etc/</i> directory when you follow the <a href="quickstart.html">quickstart installation guide</a>.
+
+</p>
+
+
+
+<img src="images/configoverview.png" border="0" style="float: right" alt="Config Overview" title="Config Overview">
+
+
+
+<p>
+
+<strong><u>Main Configuration File</u></strong>
+
+</p>
+
+
+
+<p>
+
+The main configuration file contains a number of directives that affect how the Nagios daemon operates. This config file is read by both the Nagios daemon and the CGIs. This is where you're going to want to get started in your configuration adventures.
+
+</p>
+
+
+
+<p>
+
+Documentation for the main configuration file can be found <a href="configmain.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Resource File(s)</u></strong>
+
+</p>
+
+
+
+<p>
+
+Resource files can be used to store user-defined macros. The main point of having resource files is to use them to store sensitive configuration information (like passwords), without making them available to the CGIs.
+
+</p>
+
+
+
+<p>
+
+You can specify one or more optional resource files by using the <a href="configmain.html#resource_file">resource_file</a> directive in your main configuration file.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Object Definition Files</u></strong>
+
+</p>
+
+
+
+<p>
+
+Object definition files are used to define hosts, services, hostgroups, contacts, contactgroups, commands, etc. This is where you define all the things you want monitor and how you want to monitor them.
+
+</p>
+
+
+
+<p>
+
+You can specify one or more object definition files by using the <a href="configmain.html#cfg_file">cfg_file</a> and/or <a href="configmain.html#cfg_dir">cfg_dir</a> directives in your main configuration file.
+
+</p>
+
+
+
+<p>
+
+An introduction to object definitions, and how they relate to each other, can be found <a href="configobject.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>CGI Configuration File</u></strong>
+
+</p>
+
+
+
+<p>
+
+The CGI configuration file contains a number of directives that affect the operation of the <a href="cgis.html">CGIs</a>. It also contains a reference the main configuration file, so the CGIs know how you've configured Nagios and where your object defintions are stored.
+
+</p>
+
+
+
+<p>
+
+Documentation for the CGI configuration file can be found <a href="configcgi.html">here</a>.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>CGI Configuration File Options</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">CGI Configuration File Options</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="config.html">Configuration Overview</a>, <a href="cgis.html">Information on the CGIs</a>, <a href="cgiauth.html">Authentication And Authorization In The CGIs</a>, <a href="cgiincludes.html">CGI Footers and Headers</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Notes</u></strong>
+
+</p>
+
+<p>
+
+When creating and/or editing configuration files, keep the following in mind:
+
+</p>
+
+<ol>
+
+<li>Lines that start with a '#' character are taken to be comments and are not processed
+
+<li>Variables names must begin at the start of the line - no white space is allowed before the name
+
+<li>Variable names are case-sensitive
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Sample Configuration</u></strong>
+
+</p>
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: A sample CGI configuration file (<i>/usr/local/nagios/etc/cgi.cfg</i>) is installed for you when you follow the <a href="quickstart.html">quickstart installation guide</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Config File Location</u></strong>
+
+</p>
+
+<p>
+
+By default, Nagios expects the CGI configuration file to be named <b>cgi.cfg</b> and located in the config file directory along with the <a href="configmain.html">main config file</a>. If you need to change the name of the file or its location, you can configure Apache to pass an environment variable named NAGIOS_CGI_CONFIG (which points to the correct location) to the CGIs. See the Apache documentation for information on how to do this.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Configuration File Variables</u></strong>
+
+</p>
+
+
+
+<p>
+
+Below you will find descriptions of each main Nagios configuration file option...
+
+</p>
+
+
+
+
+
+<a name="main_cfg_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Main Configuration File Location</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>main_config_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>main_config_file=/usr/local/nagios/etc/nagios.cfg</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This specifies the location of your <a href="configmain.html">main configuration file</a>. The CGIs need to know where to find this file in order to get information about configuration information, current host and service status, etc.
+
+</p>
+
+
+
+<a name="physical_html_path"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Physical HTML Path</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>physical_html_path=<path></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>physical_html_path=/usr/local/nagios/share</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the <i>physical</i> path where the HTML files for Nagios are kept on your workstation or server. Nagios
+
+assumes that the documentation and images files (used by the CGIs) are stored in subdirectories called <i>docs/</i> and <i>images/</i>, respectively.
+
+</p>
+
+
+
+
+
+<a name="url_html_path"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>URL HTML Path</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>url_html_path=<path></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>url_html_path=/nagios</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+If, when accessing Nagios via a web browser, you point to an URL like <b>http://www.myhost.com/nagios</b>, this value
+
+should be <i>/nagios</i>. Basically, its the path portion of the URL that is used to access the Nagios HTML pages.
+
+</p>
+
+
+
+
+
+<a name="use_authentication"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Authentication Usage</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>use_authentication=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>use_authentication=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option controls whether or not the CGIs will use the authentication and authorization functionality when determining what information and commands users have access to. I would strongly suggest that you use the authentication functionality for the CGIs. If you decide not to use authentication, make sure to remove the <a href="cgis.html#cmd_cgi">command CGI</a> to prevent unauthorized users from issuing commands to Nagios. The CGI will not issue commands to Nagios if authentication is disabled, but I would suggest removing it altogether just to be on the safe side. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use authentication functionality
+
+<li>1 = Use authentication and authorization functionality (default)
+
+</ul>
+
+
+
+
+
+<a name="default_user_name"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Default User Name</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>default_user_name=<username></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>default_user_name=guest</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+Setting this variable will define a default username that can access the CGIs. This allows people within a secure domain (i.e., behind a firewall) to access the CGIs without necessarily having to authenticate to the web server. You may want to use this to avoid having to use basic authentication if you are not using a secure server, as basic authentication transmits passwords in clear text over the Internet.
+
+</p>
+
+<p>
+
+<strong>Important:</strong> Do <i>not</i> define a default username unless you are running a secure web server and are sure that everyone who has access to the CGIs has been authenticated in some manner! If you define this variable, anyone who has not authenticated to the web server will inherit all rights you assign to this user!
+
+</p>
+
+
+
+<a name="authorized_for_system_information"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>System/Process Information Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_system_information=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_system_information=nagiosadmin,theboss</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can view system/process information in the <a href="cgis.html#extinfo_cgi">extended information CGI</a>. Users in this list are <i>not</i> automatically authorized to issue system/process commands. If you want users to be able to issue system/process commands as well, you must add them to the <a href="#authorized_for_system_commands">authorized_for_system_commands</a> variable. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_system_commands"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>System/Process Command Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_system_commands=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_system_commands=nagiosadmin</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can issue system/process commands via the <a href="cgis.html#cmd_cgi">command CGI</a>. Users in this list are <i>not</i> automatically authorized to view system/process information. If you want users to be able to view system/process information as well, you must add them to the <a href="#authorized_for_system_information">authorized_for_system_information</a> variable. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_configuration_information"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Configuration Information Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_configuration_information=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_configuration_information=nagiosadmin</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can view configuration information in the <a href="cgis.html#config_cgi">configuration CGI</a>. Users in this list can view information on all configured hosts, host groups, services, contacts, contact groups, time periods, and commands. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_all_hosts"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Global Host Information Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_all_hosts=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_all_hosts=nagiosadmin,theboss</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can view status and configuration information for all hosts. Users in this list are also automatically authorized to view information for all services. Users in this list are <i>not</i> automatically authorized to issue commands for all hosts or services. If you want users able to issue commands for all hosts and services as well, you must add them to the <a href="#authorized_for_all_host_commands">authorized_for_all_host_commands</a> variable. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_all_host_commands"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Global Host Command Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_all_host_commands=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_all_host_commands=nagiosadmin</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can issue commands for all hosts via the <a href="cgis.html#cmd_cgi">command CGI</a>. Users in this list are also automatically authorized to issue commands for all services. Users in this list are <i>not</i> automatically authorized to view status or configuration information for all hosts or services. If you want users able to view status and configuration information for all hosts and services as well, you must add them to the <a href="#authorized_for_all_hosts">authorized_for_all_hosts</a> variable. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_all_services"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Global Service Information Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_all_services=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_all_services=nagiosadmin,theboss</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can view status and configuration information for all services. Users in this list are <i>not</i> automatically authorized to view information for all hosts. Users in this list are <i>not</i> automatically authorized to issue commands for all services. If you want users able to issue commands for all services as well, you must add them to the <a href="#authorized_for_all_service_commands">authorized_for_all_service_commands</a> variable. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_all_service_commands"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Global Service Command Access</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_all_service_commands=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_all_service_commands=nagiosadmin</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a comma-delimited list of names of <i>authenticated users</i> who can issue commands for all services via the <a href="cgis.html#cmd_cgi">command CGI</a>. Users in this list are <i>not</i> automatically authorized to issue commands for all hosts. Users in this list are <i>not</i> automatically authorized to view status or configuration information for all hosts. If you want users able to view status and configuration information for all services as well, you must add them to the <a href="#authorized_for_all_services">authorized_for_all_services</a> variable. More information on how to setup authentication and configure authorization for the CGIs can be found <a href="cgiauth.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="authorized_for_read_only"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Read-Only Users</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>authorized_for_read_only=<user1>,<user2>,<user3>,...<user<i>n</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>authorized_for_read_only=john,mark</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+A comma-delimited list of usernames that have read-only rights in the CGIs. This will block any service or host commands normally shown on the extinfo CGI pages. It will also block comments from being shown to read-only users.
+
+</p>
+
+
+
+
+
+
+
+
+<a name="lock_author_names"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Lock Author Names</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>lock_author_names=[0/1]</strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>lock_author_names=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to restrict users from changing the author name when submitting comments, acknowledgements, and scheduled downtime from the web interface. If this option is enabled, users will be unable to change the author name associated with the command request.
+
+</p>
+
+<ul>
+
+<li>0 = Allow users to change author names when submitting commands
+
+<li>1 = Prevent users from changing author names (default)
+
+</ul>
+
+
+
+
+
+<a name="statusmap_background_image"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Statusmap CGI Background Image</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>statusmap_background_image=<image_file></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>statusmap_background_image=smbackground.gd2</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify an image to be used as a background in the <a href="cgis.html#statusmap_cgi">statusmap CGI</a> if you use the user-supplied coordinates layout method. The background image is not be available in any other layout methods. It is assumed that the image resides in the HTML images path (i.e. /usr/local/nagios/share/images). This path is automatically determined by appending "/images" to the path specified by the <a href="#physical_html_path">physical_html_path</a> directive. Note: The image file can be in GIF, JPEG, PNG, or GD2 format. However, GD2 format (preferably in uncompressed format) is recommended, as it will reduce the CPU load when the CGI generates the map image.
+
+</p>
+
+
+
+
+
+
+
+<a name="color_transparency_index"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Statusmap CGI Color Transparency Indexes</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+<table border="0" class="Default">
+<tr>
+<td valign=top>Format:</td>
+<td><strong>
+color_transparency_index_r=<0-255><br>
+color_transparency_index_g=<0-255><br>
+color_transparency_index_b=<0-255><br>
+</strong></td>
+</tr>
+<tr>
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>
+color_transparency_index_r=255<br>
+color_transparency_index_g=255<br>
+color_transparency_index_b=255<br>
+</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+These options set the r,g,b values of the background color used the statusmap CGI,
+so normal browsers that can't show real png transparency set the desired color as a background color instead (to make it look pretty). Defaults to white: (R,G,B) = (255,255,255).
+</p>
+<br>
+
+<a name="default_statusmap_layout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Default Statusmap Layout Method</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>default_statusmap_layout=<layout_number></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>default_statusmap_layout=4</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify the default layout method used by the <a href="cgis.html#statusmap_cgi">statusmap CGI</a>. Valid options are:
+
+</p>
+
+
+
+<table border=1 cellspacing=0 cellpadding=5 class="Default">
+
+<tr><th><layout_number> Value</th><th>Layout Method</th></tr>
+
+<tr><td>0</td><td>User-defined coordinates</td></tr>
+
+<tr><td>1</td><td>Depth layers</td></tr>
+
+<tr><td>2</td><td>Collapsed tree</td></tr>
+
+<tr><td>3</td><td>Balanced tree</td></tr>
+
+<tr><td>4</td><td>Circular</td></tr>
+
+<tr><td>5</td><td>Circular (Marked Up)</td></tr>
+
+<tr><td>6</td><td>Circular (Balloon)</td></tr>
+
+</table>
+
+
+
+
+
+<a name="statuswrl_include"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Statuswrl CGI Include World</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>statuswrl_include=<vrml_file></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>statuswrl_include=myworld.wrl</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to include your own objects in the generated VRML world. It is assumed that the file resides in the path specified by the <a href="#physical_html_path">physical_html_path</a> directive. Note: This file must be a fully qualified VRML world (i.e. you can view it by itself in a VRML browser).
+
+</p>
+
+
+
+
+
+
+
+<a name="default_statuswrl_layout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Default Statuswrl Layout Method</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>default_statuswrl_layout=<layout_number></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>default_statuswrl_layout=4</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify the default layout method used by the <a href="cgis.html#statuswrl_cgi">statuswrl CGI</a>. Valid options are:
+
+</p>
+
+
+
+<table border=1 cellspacing=0 cellpadding=5 class="Default">
+
+<tr><th><layout_number> Value</th><th>Layout Method</th></tr>
+
+<tr><td>0</td><td>User-defined coordinates</td></tr>
+
+<tr><td>2</td><td>Collapsed tree</td></tr>
+
+<tr><td>3</td><td>Balanced tree</td></tr>
+
+<tr><td>4</td><td>Circular</td></tr>
+
+</table>
+
+
+
+
+
+<a name="refresh_rate"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>CGI Refresh Rate</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>refresh_rate=<rate_in_seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>refresh_rate=90</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify the number of seconds between page refreshes for the <a href="cgis.html#status_cgi">status</a>, <a href="cgis.html#statusmap_cgi">statusmap</a>, and <a href="cgis.html#extinfo_cgi">extinfo</a> CGIs.
+
+</p>
+
+
+
+
+
+<a name="audio_alerts"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Audio Alerts</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Formats:</td>
+
+<td>
+
+<strong>host_unreachable_sound=<sound_file></strong><br>
+
+<strong>host_down_sound=<sound_file></strong><br>
+
+<strong>service_critical_sound=<sound_file></strong><br>
+
+<strong>service_warning_sound=<sound_file></strong><br>
+
+<strong>service_unknown_sound=<sound_file></strong><br>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Examples:</td>
+
+<td>
+
+<font color="red"><strong>host_unreachable_sound=hostu.wav</strong></font><br>
+
+<font color="red"><strong>host_down_sound=hostd.wav</strong></font><br>
+
+<font color="red"><strong>service_critical_sound=critical.wav</strong></font><br>
+
+<font color="red"><strong>service_warning_sound=warning.wav</strong></font><br>
+
+<font color="red"><strong>service_unknown_sound=unknown.wav</strong></font><br>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+These options allow you to specify an audio file that should be played in your browser if there are problems when you are viewing the <a href="cgis.html#status_cgi">status CGI</a>. If there are problems, the audio file for the most critical type of problem will be played. The most critical type of problem is on or more unreachable hosts, while the least critical is one or more services in an unknown state (see the order in the example above). Audio files are assumed to be in the <b>media/</b> subdirectory in your HTML directory (i.e. <i>/usr/local/nagios/share/media</i>).
+
+</p>
+
+
+
+<a name="ping_syntax"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Ping Syntax</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>ping_syntax=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>ping_syntax=/bin/ping -n -U -c 5 $HOSTADDRESS$</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines what syntax should be used when attempting to ping a host from the WAP interface (using
+
+the <a href="cgis.html#statuswml_cgi">statuswml CGI</a>. You must include the full path to the ping binary, along with all required options. The $HOSTADDRESS$ macro is substituted with the address of the host before the command is executed.
+
+</p>
+
+
+
+
+
+<a name="escape_html_tags"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Escape HTML Tags Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>escape_html_tags=[0/1]</strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>escape_html_tags=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not HTML tags in host and service (plugin) output is escaped in the CGIs. If you enable this option, your plugin output will not be able to contain clickable hyperlinks.
+
+</p>
+
+
+
+
+
+<a name="notes_url_target"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Notes URL Target</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>notes_url_target=[target]</strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>notes_url_target=_blank</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the name of the frame target that notes URLs should be displayed in. Valid options include <i>_blank</i>, <i>_self</i>, <i>_top</i>, <i>_parent</i>, or any other valid target name.
+
+</p>
+
+
+
+
+
+<a name="action_url_target"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Action URL Target</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>action_url_target=[target]</strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>action_url_target=_blank</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the name of the frame target that action URLs should be displayed in. Valid options include <i>_blank</i>, <i>_self</i>, <i>_top</i>, <i>_parent</i>, or any other valid target name.
+
+</p>
+
+
+
+
+
+<a name="enable_splunk_integration"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Splunk Integration Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>enable_splunk_integration=[0/1]</strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>enable_splunk_integration=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether integration functionality with Splunk is enabled in the web interface. If enabled, you'll be presented with "Splunk It" links in various places in the CGIs (log file, alert history, host/service detail, etc). Useful if you're trying to research why a particular problem occurred. For more information on Splunk, visit <a href="http://www.splunk.com/" target="_blank">http://www.splunk.com/</a>.
+
+</p>
+
+
+
+<a name="splunk_url"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Splunk URL</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign=top>Format:</td>
+
+<td><strong>splunk_url=<path></strong></td>
+
+</tr>
+
+<tr>
+
+<td valign=top>Example:</td>
+
+<td><font color="red"><strong>splunk_url=http://127.0.0.1:8000/</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option is used to define the base URL to your Splunk interface. This URL is used by the CGIs when creating links if the <a href="#enable_splunk_integration">enable_splunk_integration</a> option is enabled.
+
+</p>
+<br>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Main Configuration File Options</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Main Configuration File Options</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Notes</u></strong>
+
+</p>
+
+<p>
+
+When creating and/or editing configuration files, keep the following in mind:
+
+</p>
+
+<ol>
+
+<li>Lines that start with a '#' character are taken to be comments and are not processed
+
+<li>Variables names must begin at the start of the line - no white space is allowed before the name
+
+<li>Variable names are case-sensitive
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Sample Configuration File</u></strong>
+
+</p>
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: A sample main configuration file (<i>/usr/local/nagios/etc/nagios.cfg</i>) is installed for you when you follow the <a href="quickstart.html">quickstart installation guide</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Config File Location</u></strong>
+
+</p>
+
+
+
+<p>
+
+The main configuration file is usually named <i>nagios.cfg</i> and located in the <i>/usr/local/nagios/etc/</i> directory.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Configuration File Variables</u></strong>
+
+</p>
+
+
+
+
+
+
+
+<p>
+
+Below you will find descriptions of each main Nagios configuration file option...
+
+</p>
+
+
+
+
+
+<a name="log_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Log File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_file=/usr/local/nagios/var/nagios.log</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable specifies where Nagios should create its main log file. This should be the first
+
+variable that you define in your configuration file, as Nagios will try to write errors that it
+
+finds in the rest of your configuration data to this file. If you have <a href="#log_rotation_method">log rotation</a> enabled, this file will automatically be rotated every hour, day, week, or month.
+
+</p>
+
+
+
+
+
+<a name="cfg_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Object Configuration File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>cfg_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>cfg_file=/usr/local/nagios/etc/hosts.cfg</strong></font><br>
+
+<font color="red"><strong>cfg_file=/usr/local/nagios/etc/services.cfg</strong></font><br>
+
+<font color="red"><strong>cfg_file=/usr/local/nagios/etc/commands.cfg</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This directive is used to specify an <a href="configobject.html">object configuration file</a> containing object definitions that Nagios should use for monitoring. Object configuration files contain definitions for hosts, host groups, contacts, contact groups, services, commands, etc. You can seperate your configuration information into several files and specify multiple <i>cfg_file=</i> statements to have each of them processed.
+
+</p>
+
+
+
+
+
+<a name="cfg_dir"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Object Configuration Directory</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>cfg_dir=<directory_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>cfg_dir=/usr/local/nagios/etc/commands</strong></font><br>
+
+<font color="red"><strong>cfg_dir=/usr/local/nagios/etc/services</strong></font><br>
+
+<font color="red"><strong>cfg_dir=/usr/local/nagios/etc/hosts</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This directive is used to specify a directory which contains <a href="configobject.html">object configuration files</a> that Nagios should use for monitoring. All files in the directory with a <i>.cfg</i> extension are processed as object config files. Additionally, Nagios will recursively process all config files in subdirectories of the directory you specify here. You can seperate your configuration files into different directories and specify multiple <i>cfg_dir=</i> statements to have all config files in each directory processed.
+
+</p>
+
+
+
+
+
+
+
+<a name="object_cache_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Object Cache File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>object_cache_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>object_cache_file=/usr/local/nagios/var/objects.cache</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This directive is used to specify a file in which a cached copy of <a href="configobject.html">object definitions</a> should be stored. The cache file is (re)created every time Nagios is (re)started and is used by the CGIs. It is intended to speed up config file caching in the CGIs and allow you to edit the source <a href="#cfg_file">object config files</a> while Nagios is running without affecting the output displayed in the CGIs.
+
+</p>
+
+
+
+
+
+<a name="precached_object_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Precached Object File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>precached_object_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>precached_object_file=/usr/local/nagios/var/objects.precache</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This directive is used to specify a file in which a pre-processed, pre-cached copy of <a href="configobject.html">object definitions</a> should be stored. This file can be used to drastically improve startup times in large/complex Nagios installations. Read more information on how to speed up start times <a href="faststartup.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="resource_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Resource File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>resource_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>resource_file=/usr/local/nagios/etc/resource.cfg</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is used to specify an optional resource file that can contain $USERn$ <a href="macros.html">macro</a> definitions. $USERn$ macros are useful for storing usernames, passwords, and items commonly used in command definitions (like directory paths). The CGIs will <i>not</i> attempt to read resource files, so you can set restrictive permissions (600 or 660) on them to protect sensitive information. You can include multiple resource files by adding multiple resource_file statements to the main config file - Nagios will process them all. See the sample resource.cfg file in the <i>sample-config/</i> subdirectory of the Nagios distribution for an example of how to define $USERn$ macros.
+
+</p>
+
+
+
+
+
+<a name="temp_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Temp File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>temp_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>temp_file=/usr/local/nagios/var/nagios.tmp</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a temporary file that Nagios periodically creates to use when updating comment data, status data, etc. The file is deleted when it is no longer needed.
+
+</p>
+
+
+
+<a name="temp_path"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Temp Path</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>temp_path=<dir_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>temp_path=/tmp</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is a directory that Nagios can use as scratch space for creating temporary files used during the monitoring process. You should run <i>tmpwatch</i>, or a similiar utility, on this directory occassionally to delete files older than 24 hours.
+
+</p>
+
+
+
+<a name="status_file"></a>
+
+<a name="status_log"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Status File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>status_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>status_file=/usr/local/nagios/var/status.dat</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the file that Nagios uses to store the current status, comment, and downtime information. This file is used by the CGIs so that current monitoring status can be reported via a web interface. The CGIs must have read access to this file in order to function properly. This file is deleted every time Nagios stops and recreated when it starts.
+
+</p>
+
+
+
+
+
+<a name="status_update_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Status File Update Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>status_update_interval=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>status_update_interval=15</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines how often (in seconds) that Nagios will update status data in the <a href="#status_file">status file</a>. The minimum update interval is 1 second.
+
+</p>
+
+
+
+
+
+<a name="nagios_user"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Nagios User</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>nagios_user=<username/UID></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>nagios_user=nagios</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is used to set the effective user that the Nagios process should run as. After initial program startup and before starting to monitor anything, Nagios will drop its effective privileges and run as this user. You may specify either a username or a UID.
+
+</p>
+
+
+
+
+
+<a name="nagios_group"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Nagios Group</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>nagios_group=<groupname/GID></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>nagios_group=nagios</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is used to set the effective group that the Nagios process should run as. After initial program startup and before starting to monitor anything, Nagios will drop its effective privileges and run as this group. You may specify either a groupname or a GID.
+
+</p>
+
+
+
+
+
+<a name="enable_notifications"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Notifications Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_notifications=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_notifications=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will send out <a href="notifications.html">notifications</a> when it initially (re)starts. If this option is disabled, Nagios will not send out notifications for any host or service. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Disable notifications
+
+<li>1 = Enable notifications (default)
+
+</ul>
+
+
+
+
+
+<a name="execute_service_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Check Execution Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>execute_service_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>execute_service_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will execute service checks when it initially (re)starts. If this option is disabled, Nagios will not actively execute any service checks and will remain in a sort of "sleep" mode (it can still accept <a href="passivechecks.html">passive checks</a> unless you've <a href="#accept_passive_service_checks">disabled them</a>). This option is most often used when configuring backup monitoring servers, as described in the documentation on <a href="redundancy.html">redundancy</a>, or when setting up a <a href="distributed.html">distributed</a> monitoring environment. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Don't execute service checks
+
+<li>1 = Execute service checks (default)
+
+</ul>
+
+
+
+
+
+<a name="accept_passive_service_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Passive Service Check Acceptance Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>accept_passive_service_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>accept_passive_service_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will accept <a href="passivechecks.html">passive service checks</a> when it initially (re)starts. If this option is disabled, Nagios will not accept any passive service checks. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Don't accept passive service checks
+
+<li>1 = Accept passive service checks (default)
+
+</ul>
+
+
+
+
+
+<a name="execute_host_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Check Execution Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>execute_host_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>execute_host_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will execute on-demand and regularly scheduled host checks when it initially (re)starts. If this option is disabled, Nagios will not actively execute any host checks, although it can still accept <a href="passivechecks.html">passive host checks</a> unless you've <a href="#accept_passive_host_checks">disabled them</a>). This option is most often used when configuring backup monitoring servers, as described in the documentation on <a href="redundancy.html">redundancy</a>, or when setting up a <a href="distributed.html">distributed</a> monitoring environment. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Don't execute host checks
+
+<li>1 = Execute host checks (default)
+
+</ul>
+
+
+
+
+
+<a name="accept_passive_host_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Passive Host Check Acceptance Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>accept_passive_host_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>accept_passive_host_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will accept <a href="passivechecks.html">passive host checks</a> when it initially (re)starts. If this option is disabled, Nagios will not accept any passive host checks. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Don't accept passive host checks
+
+<li>1 = Accept passive host checks (default)
+
+</ul>
+
+
+
+
+
+<a name="enable_event_handlers"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Event Handler Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_event_handlers=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_event_handlers=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will run <a href="eventhandlers.html">event handlers</a> when it initially (re)starts. If this option is disabled, Nagios will not run any host or service event handlers. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Disable event handlers
+
+<li>1 = Enable event handlers (default)
+
+</ul>
+
+
+
+
+
+<a name="log_rotation_method"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Log Rotation Method</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_rotation_method=<n/h/d/w/m></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_rotation_method=d</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the rotation method that you would like Nagios to use for your log file. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>n = None (don't rotate the log - this is the default)
+
+<li>h = Hourly (rotate the log at the top of each hour)
+
+<li>d = Daily (rotate the log at midnight each day)
+
+<li>w = Weekly (rotate the log at midnight on Saturday)
+
+<li>m = Monthly (rotate the log at midnight on the last day of the month)
+
+</ul>
+
+
+
+
+
+<a name="log_archive_path"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Log Archive Path</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_archive_path=<path></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_archive_path=/usr/local/nagios/var/archives/</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the directory where Nagios should place log files that have been rotated. This option is ignored if you choose to not use the <a href="#log_rotation_method">log rotation</a> functionality.
+
+</p>
+
+
+
+
+
+<a name="check_external_commands"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>External Command Check Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_external_commands=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_external_commands=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will check the <a href="#command_file">command file</a> for commands that should be executed. This option must be enabled if you plan on using the <a href="cgis.html#cmd_cgi">command CGI</a> to issue commands via the web interface. More information on external commands can be found <a href="extcommands.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't check external commands
+
+<li>1 = Check external commands (default)
+
+</ul>
+
+
+
+
+
+<a name="command_check_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>External Command Check Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>command_check_interval=<xxx>[s]</strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>command_check_interval=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+If you specify a number with an "s" appended to it (i.e. 30s), this is the number of <i>seconds</i> to wait between external command checks. If you leave off the "s", this is the number of "time units" to wait between external command checks. Unless you've changed the <a href="#interval_length">interval_length</a> value (as defined below) from the default value of 60, this number will mean minutes.
+
+</p>
+
+
+
+<p>
+
+Note: By setting this value to <b>-1</b>, Nagios will check for external commands as often as possible. Each time Nagios checks for external commands it will read and process all commands present in the <a href="#command_file">command file</a> before continuing on with its other duties. More information on external commands can be found <a href="extcommands.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="command_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>External Command File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>command_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>command_file=/usr/local/nagios/var/rw/nagios.cmd</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the file that Nagios will check for external commands to process. The <a href="cgis.html#cmd_cgi">command CGI</a> writes commands to this file. The external command file is implemented as a named pipe (FIFO), which is created when Nagios starts and removed when it shuts down. If the file exists when Nagios starts, the Nagios process will terminate with an error message. More information on external commands can be found <a href="extcommands.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="external_command_buffer_slots"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>External Command Buffer Slots</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>external_command_buffer_slots=<#></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>external_command_buffer_slots=512</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+Note: This is an advanced feature. This option determines how many buffer slots Nagios will reserve for caching external commands that have been read from the external command file by a worker thread, but have not yet been processed by the main thread of the Nagios deamon. Each slot can hold one external command, so this option essentially determines how many commands can be buffered. For installations where you process a large number of passive checks (e.g. <a href="distributed.html">distributed setups</a>), you may need to increase this number. You should consider using MRTG to graph Nagios' usage of external command buffers. You can read more on how to configure graphing <a href="mrtggraphs.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="check_for_updates"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Update Checks</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_for_updates=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_for_updates=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether Nagios will automatically check to see if new updates (releases) are available. It is recommend that you enable this option to ensure that you stay on top of the latest critical patches to Nagios. Nagios is critical to you - make sure you keep it in good shape. Nagios will check once a day for new updates. Data collected by Nagios Enterprises from the update check is processed in accordance with our privacy policy - see <a href="http://api.nagios.org">http://api.nagios.org</a> for details.
+
+</p>
+
+
+
+
+
+<a name="bare_update_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Bare Update Checks</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>bare_update_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>bare_update_checks</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option deterines what data Nagios will send to api.nagios.org when it checks for updates. By default, Nagios will send information on the current version of Nagios you have installed, as well as an indicator as to whether this was a new installation or not. Nagios Enterprises uses this data to determine the number of users running specific version of Nagios. Enable this option if you do not wish for this information to be sent.
+
+</p>
+
+
+
+
+
+<a name="lock_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Lock File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>lock_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>lock_file=/tmp/nagios.lock</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option specifies the location of the lock file that Nagios should create when it runs as a daemon (when started with the -d command line argument). This file contains the process id (PID) number of the running Nagios process.
+
+</p>
+
+
+
+
+
+<a name="retain_state_information"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>State Retention Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>retain_state_information=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>retain_state_information=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will retain state information for hosts and services between program restarts. If you enable this option, you should supply a value for the <a href="#state_retention_file">state_retention_file</a> variable. When enabled, Nagios will save all state information for hosts and service before it shuts down (or restarts) and will read in previously saved state information when it starts up again.
+
+</p>
+
+<ul>
+
+<li>0 = Don't retain state information
+
+<li>1 = Retain state information (default)
+
+</ul>
+
+
+
+
+
+<a name="state_retention_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>State Retention File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>state_retention_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>state_retention_file=/usr/local/nagios/var/retention.dat</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the file that Nagios will use for storing status, downtime, and comment information before it shuts down. When Nagios is restarted it will use the information stored in this file for setting the initial states of services and hosts before it starts monitoring anything. In order to make Nagios retain state information between program restarts, you must enable the <a href="#retain_state_information">retain_state_information</a> option.
+
+</p>
+
+
+
+
+
+<a name="retention_update_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Automatic State Retention Update Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>retention_update_interval=<minutes></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>retention_update_interval=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines how often (in minutes) that Nagios will automatically save retention data during normal operation. If you set this value to 0, Nagios will not save retention data at regular intervals, but it will still save retention data before shutting down or restarting. If you have disabled state retention (with the <a href="#retain_state_information">retain_state_information</a> option), this option has no effect.
+
+</p>
+
+
+
+
+
+<a name="use_retained_program_state"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Use Retained Program State Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_retained_program_state=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_retained_program_state=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines whether or not Nagios will set various program-wide state variables based on the values saved in the retention file. Some of these program-wide state variables that are normally saved across program restarts if state retention is enabled include the <a href="#enable_notifications">enable_notifications</a>, <a href="#enable_flap_detection">enable_flap_detection</a>, <a href="#enable_event_handlers">enable_event_handlers</a>, <a href="#execute_service_checks">execute_service_checks</a>, and <a href="#accept_passive_service_checks">accept_passive_service_checks</a> options. If you do not have <a href="#retain_state_information">state retention</a> enabled, this option has no effect.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use retained program state
+
+<li>1 = Use retained program state (default)
+
+</ul>
+
+
+
+
+
+<a name="use_retained_scheduling_info"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Use Retained Scheduling Info Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_retained_scheduling_info=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_retained_scheduling_info=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines whether or not Nagios will retain scheduling info (next check times) for hosts and services when it restarts. If you are adding a large number (or percentage) of hosts and services, I would recommend disabling this option when you first restart Nagios, as it can adversely skew the spread of initial checks. Otherwise you will probably want to leave it enabled.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use retained scheduling info
+
+<li>1 = Use retained scheduling info (default)
+
+</ul>
+
+
+
+
+
+<a name="retained_host_attribute_mask"></a>
+
+<a name="retained_service_attribute_mask"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Retained Host and Service Attribute Masks</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td>
+
+<strong>retained_host_attribute_mask=<number></strong><br>
+
+<strong>retained_service_attribute_mask=<number></strong>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>retained_host_attribute_mask=0</strong></font><br>
+
+<font color="red"><strong>retained_service_attribute_mask=0</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+WARNING: This is an advanced feature. You'll need to read the Nagios source code to use this option effectively.
+
+</p>
+
+<p>
+
+These options determine which host or service attributes are NOT retained across program restarts. The values for these options are a bitwise AND of values specified by the "MODATTR_" definitions in the include/common.h source code file. By default, all host and service attributes are retained.
+
+</p>
+
+
+
+
+
+<a name="retained_process_host_attribute_mask"></a>
+
+<a name="retained_process_service_attribute_mask"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Retained Process Attribute Masks</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td>
+
+<strong>retained_process_host_attribute_mask=<number></strong><br>
+
+<strong>retained_process_service_attribute_mask=<number></strong>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>retained_process_host_attribute_mask=0</strong></font><br>
+
+<font color="red"><strong>retained_process_service_attribute_mask=0</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+WARNING: This is an advanced feature. You'll need to read the Nagios source code to use this option effectively.
+
+</p>
+
+<p>
+
+These options determine which process attributes are NOT retained across program restarts. There are two masks because there are often separate host and service process attributes that can be changed. For example, host checks can be disabled at the program level, while service checks are still enabled. The values for these options are a bitwise AND of values specified by the "MODATTR_" definitions in the include/common.h source code file. By default, all process attributes are retained.
+
+</p>
+
+
+
+
+
+<a name="retained_contact_host_attribute_mask"></a>
+
+<a name="retained_contact_service_attribute_mask"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Retained Contact Attribute Masks</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td>
+
+<strong>retained_contact_host_attribute_mask=<number></strong><br>
+
+<strong>retained_contact_service_attribute_mask=<number></strong>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td>
+
+<font color="red"><strong>retained_contact_host_attribute_mask=0</strong></font><br>
+
+<font color="red"><strong>retained_contact_service_attribute_mask=0</strong></font>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+WARNING: This is an advanced feature. You'll need to read the Nagios source code to use this option effectively.
+
+</p>
+
+<p>
+
+These options determine which contact attributes are NOT retained across program restarts. There are two masks because there are often separate host and service contact attributes that can be changed. The values for these options are a bitwise AND of values specified by the "MODATTR_" definitions in the include/common.h source code file. By default, all process attributes are retained.
+
+</p>
+
+
+
+
+
+<a name="use_syslog"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Syslog Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_syslog=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_syslog=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether messages are logged to the syslog facility on your local host. Values
+
+are as follows:
+
+</p>
+
+<ul>
+
+<li>0 = Don't use syslog facility
+
+<li>1 = Use syslog facility
+
+</ul>
+
+
+
+
+
+<a name="log_notifications"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Notification Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_notifications=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_notifications=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not notification messages are logged. If you have a lot of contacts
+
+or regular service failures your log file will grow relatively quickly. Use this option to keep contact
+
+notifications from being logged.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log notifications
+
+<li>1 = Log notifications
+
+</ul>
+
+
+
+
+
+<a name="log_service_retries"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Check Retry Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_service_retries=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_service_retries=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not service check retries are logged. Service check retries occur when a
+
+service check results in a non-OK state, but you have configured Nagios to retry the service more than once before
+
+responding to the error. Services in this situation are considered to be in "soft" states. Logging service check retries
+
+is mostly useful when attempting to debug Nagios or test out service <a href="eventhandlers.html">event handlers</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log service check retries
+
+<li>1 = Log service check retries
+
+</ul>
+
+
+
+
+
+<a name="log_host_retries"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Check Retry Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_host_retries=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_host_retries=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not host check retries are logged. Logging host check retries
+
+is mostly useful when attempting to debug Nagios or test out host <a href="eventhandlers.html">event handlers</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log host check retries
+
+<li>1 = Log host check retries
+
+</ul>
+
+
+
+
+
+<a name="log_event_handlers"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Event Handler Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_event_handlers=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_event_handlers=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not service and host <a href="eventhandlers.html">event handlers</a> are logged.
+
+Event handlers are optional commands that can be run whenever a service or hosts changes state. Logging event handlers
+
+is most useful when debugging Nagios or first trying out your event handler scripts.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log event handlers
+
+<li>1 = Log event handlers
+
+</ul>
+
+
+
+
+
+<a name="log_initial_states"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Initial States Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_initial_states=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_initial_states=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not Nagios will force all initial host and service states to be logged, even if they result in an OK state. Initial service and host states are normally only logged when there is a problem on the first check. Enabling this option is useful if you are using an application that scans the log file to determine long-term state statistics for services and hosts.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log initial states (default)
+
+<li>1 = Log initial states
+
+</ul>
+
+
+
+
+
+
+
+<a name="log_external_commands"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>External Command Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_external_commands=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_external_commands=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not Nagios will log <a href="extcommands.html">external commands</a> that it receives from the <a href="#command_file">external command file</a>. Note: This option does not control whether or not <a href="passivechecks.html">passive service checks</a> (which are a type of external command) get logged. To enable or disable logging of passive checks, use the <a href="#log_passive_checks">log_passive_checks</a> option.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log external commands
+
+<li>1 = Log external commands (default)
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="log_passive_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Passive Check Logging Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>log_passive_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>log_passive_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines whether or not Nagios will log <a href="passivechecks.html">passive host and service checks</a> that it receives from the <a href="#command_file">external command file</a>. If you are setting up a <a href="distributed.html">distributed monitoring environment</a> or plan on handling a large number of passive checks on a regular basis, you may wish to disable this option so your log file doesn't get too large.
+
+</p>
+
+<ul>
+
+<li>0 = Don't log passive checks
+
+<li>1 = Log passive checks (default)
+
+</ul>
+
+
+
+
+
+
+
+<a name="global_host_event_handler"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Global Host Event Handler Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>global_host_event_handler=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>global_host_event_handler=log-host-event-to-db</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a host event handler command that is to be run for every host state change. The global event handler is executed immediately prior to the event handler that you have optionally specified in each host definition. The <i>command</i> argument is the short name of a command that you define in your <a href="configobject.html">object configuration file</a>. The maximum amount of time that this command can run is controlled by the <a href="#event_handler_timeout">event_handler_timeout</a> option. More information on event handlers can be found <a href="eventhandlers.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="global_service_event_handler"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Global Service Event Handler Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>global_service_event_handler=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>global_service_event_handler=log-service-event-to-db</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a service event handler command that is to be run for every service state change. The global event handler is executed immediately prior to the event handler that you have optionally specified in each service definition. The <i>command</i> argument is the short name of a command that you define in your <a href="configobject.html">object configuration file</a>. The maximum amount of time that this command can run is controlled by the <a href="#event_handler_timeout">event_handler_timeout</a> option. More information on event handlers can be found <a href="eventhandlers.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="sleep_time"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Inter-Check Sleep Time</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>sleep_time=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>sleep_time=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the number of seconds that Nagios will sleep before checking to see if the next service or host check in the scheduling queue should be executed. Note that Nagios will only sleep after it "catches up" with queued service checks that have fallen behind.
+
+</p>
+
+
+
+
+
+<a name="service_inter_check_delay_method"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Inter-Check Delay Method</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_inter_check_delay_method=<n/d/s/x.xx></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_inter_check_delay_method=s</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to control how service checks are initially "spread out" in the event queue. Using a "smart" delay calculation (the default) will cause Nagios to calculate an average check interval and spread initial checks of all services out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally <i>not</i> recommended, as it will cause all service checks to be scheduled for execution at the same time. This means that you will generally have large CPU spikes when the services are all executed in parallel. More information on how to estimate how the inter-check delay affects service check scheduling can be found <a href="checkscheduling.html#service_inter_check_delay">here</a>. Values are as follows:
+
+</p>
+
+<ul>
+
+<li>n = Don't use any delay - schedule all service checks to run immediately (i.e. at the same time!)
+
+<li>d = Use a "dumb" delay of 1 second between service checks
+
+<li>s = Use a "smart" delay calculation to spread service checks out evenly (default)
+
+<li>x.xx = Use a user-supplied inter-check delay of x.xx seconds
+
+</ul>
+
+
+
+
+
+<a name="max_service_check_spread"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Maximum Service Check Spread</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>max_service_check_spread=<minutes></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>max_service_check_spread=30</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the maximum number of minutes from when Nagios starts that all services (that are scheduled to be regularly checked) are checked. This option will automatically adjust the <a href="#service_inter_check_delay_method">service inter-check delay method</a> (if necessary) to ensure that the initial checks of all services occur within the timeframe you specify. In general, this option will not have an affect on service check scheduling if scheduling information is being retained using the <a href="#use_retained_scheduling_info">use_retained_scheduling_info</a> option. Default value is <b>30</b> (minutes).
+
+</p>
+
+
+
+
+
+<a name="service_interleave_factor"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Interleave Factor</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_interleave_factor=<s|<i>x</i>></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_interleave_factor=s</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This variable determines how service checks are interleaved. Interleaving allows for a more even distribution of service checks, reduced load on remote hosts, and faster overall detection of host problems. Setting this value to 1 is equivalent to not interleaving the service checks (this is how versions of Nagios previous to 0.0.5 worked). Set this value to <b>s</b> (smart) for automatic calculation of the interleave factor unless you have a specific reason to change it. The best way to understand how interleaving works is to watch the <a href="cgis.html#status_cgi">status CGI</a> (detailed view) when Nagios is just starting. You should see that the service check results are spread out as they begin to appear. More information on how interleaving works can be found <a href="checkscheduling.html#service_interleaving">here</a>.
+
+<ul>
+
+<li><i>x</i> = A number greater than or equal to 1 that specifies the interleave factor to use. An interleave factor of 1 is equivalent to not interleaving the service checks.
+
+<li>s = Use a "smart" interleave factor calculation (default)
+
+</ul>
+
+
+
+
+
+<a name="max_concurrent_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Maximum Concurrent Service Checks</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>max_concurrent_checks=<max_checks></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>max_concurrent_checks=20</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify the maximum number of service checks that can be run in parallel at any given time. Specifying a value of 1 for this variable essentially prevents any service checks from being run in parallel. Specifying a value of 0 (the default) does not place any restrictions on the number of concurrent checks. You'll have to modify this value based on the system resources you have available on the machine that runs Nagios, as it directly affects the maximum load that will be imposed on the system (processor utilization, memory, etc.). More information on how to estimate how many concurrent checks you should allow can be found <a href="checkscheduling.html#max_concurrent_checks">here</a>.
+
+</p>
+
+
+
+
+
+<a name="check_result_reaper_frequency"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Check Result Reaper Frequency</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_result_reaper_frequency=<frequency_in_seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_result_reaper_frequency=5</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to control the frequency <i>in seconds</i> of check result "reaper" events. "Reaper" events process the results from host and service checks that have finished executing. These events consitute the core of the monitoring logic in Nagios.
+
+</p>
+
+
+
+
+
+
+
+<a name="max_check_result_reaper_time"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Maximum Check Result Reaper Time</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>max_check_result_reaper_time=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>max_check_result_reaper_time=30</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to control the maximum amount of time <i>in seconds</i> that host and service check result "reaper" events are allowed to run. "Reaper" events process the results from host and service checks that have finished executing. If there are a lot of results to process, reaper events may take a long time to finish, which might delay timely execution of new host and service checks. This variable allows you to limit the amount of time that an individual reaper event will run before it hands control back over to Nagios for other portions of the monitoring logic.
+
+</p>
+
+
+
+
+
+
+
+<a name="check_result_path"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Check Result Path</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_result_path=<path></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_result_path=/var/spool/nagios/checkresults</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This options determines which directory Nagios will use to temporarily store host and service check results before they are processed. This directory should not be used to store any other files, as Nagios will periodically clean this directory of old file (see the <a href="#max_check_result_file_age">max_check_result_file_age</a> option for more information).
+
+</p>
+
+
+
+<p>
+
+Note: Make sure that only a single instance of Nagios has access to the check result path. If multiple instances of Nagios have their check result path set to the same directory, you will run into problems with check results being processed (incorrectly) by the wrong instance of Nagios!
+
+</p>
+
+
+
+
+
+<a name="max_check_result_file_age"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Max Check Result File Age</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>max_check_result_file_age=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>max_check_result_file_age=3600</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This options determines the maximum age in seconds that Nagios will consider check result files found in the <a href="#check_result_path">check_result_path</a> directory to be valid. Check result files that are older that this threshold will be deleted by Nagios and the check results they contain will not be processed. By using a value of zero (0) with this option, Nagios will process all check result files - even if they're older than your hardware :-).
+
+</p>
+
+
+
+<a name="host_inter_check_delay_method"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Inter-Check Delay Method</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_inter_check_delay_method=<n/d/s/x.xx></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_inter_check_delay_method=s</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to control how host checks <i>that are scheduled to be checked on a regular basis</i> are initially "spread out" in the event queue. Using a "smart" delay calculation (the default) will cause Nagios to calculate an average check interval and spread initial checks of all hosts out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally <i>not</i> recommended. Using no delay will cause all host checks to be scheduled for execution at the same time. More information on how to estimate how the inter-check delay affects host check scheduling can be found <a href="checkscheduling.html#host_inter_check_delay">here</a>.Values are as follows:
+
+</p>
+
+<ul>
+
+<li>n = Don't use any delay - schedule all host checks to run immediately (i.e. at the same time!)
+
+<li>d = Use a "dumb" delay of 1 second between host checks
+
+<li>s = Use a "smart" delay calculation to spread host checks out evenly (default)
+
+<li>x.xx = Use a user-supplied inter-check delay of x.xx seconds
+
+</ul>
+
+
+
+
+
+<a name="max_host_check_spread"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Maximum Host Check Spread</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>max_host_check_spread=<minutes></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>max_host_check_spread=30</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the maximum number of minutes from when Nagios starts that all hosts (that are scheduled to be regularly checked) are checked. This option will automatically adjust the <a href="#host_inter_check_delay_method">host inter-check delay method</a> (if necessary) to ensure that the initial checks of all hosts occur within the timeframe you specify. In general, this option will not have an affect on host check scheduling if scheduling information is being retained using the <a href="#use_retained_scheduling_info">use_retained_scheduling_info</a> option. Default value is <b>30</b> (minutes).
+
+</p>
+
+
+
+
+
+<a name="interval_length"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Timing Interval Length</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>interval_length=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>interval_length=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the number of seconds per "unit interval" used for timing in the scheduling queue, re-notifications, etc. "Units intervals" are used in the object configuration file to determine how often to run a service check, how often to re-notify a contact, etc.
+
+</p>
+
+<p>
+
+<strong>Important:</strong> The default value for this is set to 60, which means that a "unit value" of 1 in the object configuration file will mean 60 seconds (1 minute). I have not really tested other values for this variable, so proceed at your own risk if you decide to do so!
+
+</p>
+
+
+
+
+
+<a name="auto_reschedule_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Auto-Rescheduling Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>auto_reschedule_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>auto_reschedule_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will attempt to automatically reschedule active host and service checks to
+
+ "smooth" them out over time. This can help to balance the load on the monitoring server, as it will attempt to keep the time between consecutive checks consistent, at the expense of executing checks on a more rigid schedule.
+
+</p>
+
+<p>
+
+<strong>WARNING:</strong> THIS IS AN EXPERIMENTAL FEATURE AND MAY BE REMOVED IN FUTURE VERSIONS. ENABLING THIS OPTION CAN DEGRADE PERFORMANCE - RATHER THAN INCREASE IT - IF USED IMPROPERLY!
+
+</p>
+
+
+
+
+
+<a name="auto_rescheduling_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Auto-Rescheduling Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>auto_rescheduling_interval=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>auto_rescheduling_interval=30</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines how often (in seconds) Nagios will attempt to automatically reschedule checks. This option only has an effect if the <a href="#auto_reschedule_checks">auto_reschedule_checks</a> option is enabled. Default is 30 seconds.
+
+</p>
+
+<p>
+
+<strong>WARNING:</strong> THIS IS AN EXPERIMENTAL FEATURE AND MAY BE REMOVED IN FUTURE VERSIONS. ENABLING THE AUTO-RESCHEDULING OPTION CAN DEGRADE PERFORMANCE - RATHER THAN INCREASE IT - IF USED IMPROPERLY!
+
+</p>
+
+
+
+
+
+<a name="auto_rescheduling_window"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Auto-Rescheduling Window</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>auto_rescheduling_window=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>auto_rescheduling_window=180</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the "window" of time (in seconds) that Nagios will look at when automatically rescheduling checks. Only host and service checks that occur in the next X seconds (determined by this variable) will be rescheduled. This option only has an effect if the <a href="#auto_reschedule_checks">auto_reschedule_checks</a> option is enabled. Default is 180 seconds (3 minutes).
+
+</p>
+
+<p>
+
+<strong>WARNING:</strong> THIS IS AN EXPERIMENTAL FEATURE AND MAY BE REMOVED IN FUTURE VERSIONS. ENABLING THE AUTO-RESCHEDULING OPTION CAN DEGRADE PERFORMANCE - RATHER THAN INCREASE IT - IF USED IMPROPERLY!
+
+</p>
+
+
+
+
+
+<a name="use_agressive_host_checking"></a>
+
+<a name="use_aggressive_host_checking"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Aggressive Host Checking Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_aggressive_host_checking=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_aggressive_host_checking=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+Nagios tries to be smart about how and when it checks the status of hosts. In general, disabling this option will allow Nagios to make some smarter decisions and check hosts a bit faster. Enabling this option will increase the amount of time required to check hosts, but may improve reliability a bit. Unless you have problems with Nagios not recognizing that a host recovered, I would suggest <b>not</b> enabling this option.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use aggressive host checking (default)
+
+<li>1 = Use aggressive host checking
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="translate_passive_host_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Translate Passive Host Checks Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>translate_passive_host_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>translate_passive_host_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will translate DOWN/UNREACHABLE passive host check results to their "correct" state from the viewpoint of the local Nagios instance. This can be very useful in distributed and failover monitoring installations. More information on passive check state translation can be found <a href="passivestatetranslation.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Disable check translation (default)
+
+<li>1 = Enable check translation
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="passive_host_checks_are_soft"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Passive Host Checks Are SOFT Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>passive_host_checks_are_soft=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>passive_host_checks_are_soft=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will treat <a href="passivechecks.html">passive host checks</a> as HARD states or SOFT states. By default, a passive host check result will put a host into a <a href="statetypes.html">HARD state type</a>. You can change this behavior by enabling this option.
+
+</p>
+
+<ul>
+
+<li>0 = Passive host checks are HARD (default)
+
+<li>1 = Passive host checks are SOFT
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="enable_predictive_host_dependency_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Predictive Host Dependency Checks Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_predictive_host_dependency_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_predictive_host_dependency_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will execute predictive checks of hosts that are being depended upon (as defined in <a href="objectdefinitions.html#hostdependency">host dependencies</a>) for a particular host when it changes state. Predictive checks help ensure that the dependency logic is as accurate as possible. More information on how predictive checks work can be found <a href="dependencychecks.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Disable predictive checks
+
+<li>1 = Enable predictive checks (default)
+
+</ul>
+
+
+
+
+
+
+
+<a name="enable_predictive_service_dependency_checks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Predictive Service Dependency Checks Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_predictive_service_dependency_checks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_predictive_service_dependency_checks=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will execute predictive checks of services that are being depended upon (as defined in <a href="objectdefinitions.html#servicedependency">service dependencies</a>) for a particular service when it changes state. Predictive checks help ensure that the dependency logic is as accurate as possible. More information on how predictive checks work can be found <a href="dependencychecks.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Disable predictive checks
+
+<li>1 = Enable predictive checks (default)
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="cached_host_check_horizon"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Cached Host Check Horizon</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>cached_host_check_horizon=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>cached_host_check_horizon=15</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the maximum amount of time (in seconds) that the state of a previous host check is considered current. Cached host states (from host checks that were performed more recently than the time specified by this value) can improve host check performance immensely. Too high of a value for this option may result in (temporarily) inaccurate host states, while a low value may result in a performance hit for host checks. Use a value of 0 if you want to disable host check caching. More information on cached checks can be found <a href="cachedchecks.html">here</a>.
+
+</p>
+
+
+
+
+
+
+
+
+
+<a name="cached_service_check_horizon"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Cached Service Check Horizon</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>cached_service_check_horizon=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>cached_service_check_horizon=15</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the maximum amount of time (in seconds) that the state of a previous service check is considered current. Cached service states (from service checks that were performed more recently than the time specified by this value) can improve service check performance when a lot of <a href="objectdefinitions.html#servicedependency">service dependencies</a> are used. Too high of a value for this option may result in inaccuracies in the service dependency logic. Use a value of 0 if you want to disable service check caching. More information on cached checks can be found <a href="cachedchecks.html">here</a>.
+
+</p>
+
+
+
+
+
+
+
+
+
+<a name="use_large_installation_tweaks"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Large Installation Tweaks Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_large_installation_tweaks=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_large_installation_tweaks=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not the Nagios daemon will take several shortcuts to improve performance. These shortcuts result in the loss of a few features, but larger installations will likely see a lot of benefit from doing so. More information on what optimizations are taken when you enable this option can be found <a href="largeinstalltweaks.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use tweaks (default)
+
+<li>1 = Use tweaks
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="free_child_process_memory"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Child Process Memory Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>free_child_process_memory=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>free_child_process_memory=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will free memory in child processes when they are fork()ed off from the main process. By default, Nagios frees memory. However, if the <a href="#use_large_installation_tweaks">use_large_installation_tweaks</a> option is enabled, it will not. By defining this option in your configuration file, you are able to override things to get the behavior you want.
+
+</p>
+
+<ul>
+
+<li>0 = Don't free memory
+
+<li>1 = Free memory
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="child_processes_fork_twice"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Child Processes Fork Twice</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>child_processes_fork_twice=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>child_processes_fork_twice=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will fork() child processes twice when it executes host and service checks. By default, Nagios fork()s twice. However, if the <a href="#use_large_installation_tweaks">use_large_installation_tweaks</a> option is enabled, it will only fork() once. By defining this option in your configuration file, you are able to override things to get the behavior you want.
+
+</p>
+
+<ul>
+
+<li>0 = Fork() just once
+
+<li>1 = Fork() twice
+
+</ul>
+
+
+
+
+
+
+
+<a name="enable_environment_macros"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Environment Macros Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_environment_macros=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_environment_macros=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not the Nagios daemon will make all standard <a href="macrolist.html">macros</a> available as environment variables to your check, notification, event hander, etc. commands. In large Nagios installations this can be problematic because it takes additional memory and (more importantly) CPU to compute the values of all macros and make them available to the environment.
+
+</p>
+
+<ul>
+
+<li>0 = Don't make macros available as environment variables
+
+<li>1 = Make macros available as environment variables (default)
+
+</ul>
+
+
+
+
+
+
+
+
+
+<a name="enable_flap_detection"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Flap Detection Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_flap_detection=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_flap_detection=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will try and detect hosts and services that are "flapping". Flapping occurs when a host or service changes between states too frequently, resulting in a barrage of notifications being sent out. When Nagios detects that a host or service is flapping, it will temporarily suppress notifications for that host/service until it stops flapping. Flap detection is very experimental at this point, so use this feature with caution! More information on how flap detection and handling works can be found <a href="flapping.html">here</a>. Note: If you have <a href="#retain_state_information">state retention</a> enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the <a href="#state_retention_file">state retention file</a>), <i>unless</i> you disable the <a href="#use_retained_program_state">use_retained_program_state</a> option. If you want to change this option when state retention is active (and the <a href="#use_retained_program_state">use_retained_program_state</a> is enabled), you'll have to use the appropriate <a href="extcommands.html">external command</a> or change it via the web interface.
+
+</p>
+
+<ul>
+
+<li>0 = Don't enable flap detection (default)
+
+<li>1 = Enable flap detection
+
+</ul>
+
+
+
+
+
+<a name="low_service_flap_threshold"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Low Service Flap Threshold</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>low_service_flap_threshold=<percent></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>low_service_flap_threshold=25.0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option is used to set the low threshold for detection of service flapping. For more information on how flap detection and handling works (and how this option affects things) read <a href="flapping.html">this</a>.
+
+</p>
+
+
+
+
+
+<a name="high_service_flap_threshold"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>High Service Flap Threshold</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>high_service_flap_threshold=<percent></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>high_service_flap_threshold=50.0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option is used to set the high threshold for detection of service flapping. For more information on how flap detection and handling works (and how this option affects things) read <a href="flapping.html">this</a>.
+
+</p>
+
+
+
+
+
+<a name="low_host_flap_threshold"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Low Host Flap Threshold</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>low_host_flap_threshold=<percent></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>low_host_flap_threshold=25.0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option is used to set the low threshold for detection of host flapping. For more information on how flap detection and handling works (and how this option affects things) read <a href="flapping.html">this</a>.
+
+</p>
+
+
+
+
+
+<a name="high_host_flap_threshold"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>High Host Flap Threshold</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>high_host_flap_threshold=<percent></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>high_host_flap_threshold=50.0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option is used to set the high threshold for detection of host flapping. For more information on how flap detection and handling works (and how this option affects things) read <a href="flapping.html">this</a>.
+
+</p>
+
+
+
+
+
+<a name="soft_state_dependencies"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Soft State Dependencies Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>soft_state_dependencies=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>soft_state_dependencies=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will use soft state information when checking <a href="dependencies.html">host and service dependencies</a>. Normally Nagios will only use the latest hard host or service state when checking dependencies. If you want it to use the latest state (regardless of whether its a soft or hard <a href="statetypes.html">state type</a>), enable this option.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use soft state dependencies (default)
+
+<li>1 = Use soft state dependencies
+
+</ul>
+
+
+
+
+
+<a name="service_check_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Check Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_check_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_check_timeout=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow service checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned. A timeout error will also be logged.
+
+</p>
+
+<p>
+
+There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each service check normally finishes executing within this time limit. If a service check runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
+
+</p>
+
+
+
+
+
+<a name="host_check_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Check Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_check_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_check_timeout=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow host checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned and the host will be assumed to be DOWN. A timeout error will also be logged.
+
+</p>
+
+<p>
+
+There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each host check normally finishes executing within this time limit. If a host check runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
+
+</p>
+
+
+
+
+
+<a name="event_handler_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Event Handler Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>event_handler_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>event_handler_timeout=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow <a href="eventhandlers.html">event handlers</a> to be run. If an event handler exceeds this time limit it will be killed and a warning will be logged.
+
+</p>
+
+<p>
+
+There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off commands which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each event handler command normally finishes executing within this time limit. If an event handler runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
+
+</p>
+
+
+
+
+
+<a name="notification_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Notification Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>notification_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>notification_timeout=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow notification commands to be run. If a notification command exceeds this time limit it will be killed and a warning will be logged.
+
+</p>
+
+<p>
+
+There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off commands which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each notification command finishes executing within this time limit. If a notification command runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
+
+</p>
+
+
+
+
+
+<a name="ocsp_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Obsessive Compulsive Service Processor Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>ocsp_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>ocsp_timeout=5</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow an <a href="#ocsp_command">obsessive compulsive service processor command</a> to be run. If a command exceeds this time limit it will be killed and a warning will be logged.
+
+</p>
+
+
+
+
+
+<a name="ochp_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Obsessive Compulsive Host Processor Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>ochp_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>ochp_timeout=5</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow an <a href="#ochp_command">obsessive compulsive host processor command</a> to be run. If a command exceeds this time limit it will be killed and a warning will be logged.
+
+</p>
+
+
+
+
+
+<a name="perfdata_timeout"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Performance Data Processor Command Timeout</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>perfdata_timeout=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>perfdata_timeout=5</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the maximum number of seconds that Nagios will allow a <a href="#host_perfdata_command">host performance data processor command</a> or <a href="#service_perfdata_command">service performance data processor command</a> to be run. If a command exceeds this time limit it will be killed and a warning will be logged.
+
+</p>
+
+
+
+
+
+<a name="obsess_over_services"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Obsess Over Services Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>obsess_over_services=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>obsess_over_services=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This value determines whether or not Nagios will "obsess" over service checks results and run the <a href="#ocsp_command">obsessive compulsive service processor command</a> you define. I know - funny name, but it was all I could think of. This option is useful for performing <a href="distributed.html">distributed monitoring</a>. If you're not doing distributed monitoring, don't enable this option.
+
+</p>
+
+<ul>
+
+<li>0 = Don't obsess over services (default)
+
+<li>1 = Obsess over services
+
+</ul>
+
+
+
+
+
+<a name="ocsp_command"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Obsessive Compulsive Service Processor Command</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>ocsp_command=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>ocsp_command=obsessive_service_handler</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a command to be run after <i>every</i> service check, which can be useful in <a href="distributed.html">distributed monitoring</a>. This command is executed after any <a href="eventhandlers.html">event handler</a> or <a href="notifications.html">notification</a> commands. The <i>command</i> argument is the short name of a <a href="objectdefinitions.html#command">command definition</a> that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the <a href="#ocsp_timeout">ocsp_timeout</a> option. More information on distributed monitoring can be found <a href="distributed.html">here</a>. This command is only executed if the <a href="#obsess_over_services">obsess_over_services</a> option is enabled globally and if the <i>obsess_over_service</i> directive in the <a href="objectdefinitions.html#service">service definition</a> is enabled.
+
+</p>
+
+
+
+
+
+<a name="obsess_over_hosts"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Obsess Over Hosts Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>obsess_over_hosts=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>obsess_over_hosts=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This value determines whether or not Nagios will "obsess" over host checks results and run the <a href="#ochp_command">obsessive compulsive host processor command</a> you define. I know - funny name, but it was all I could think of. This option is useful for performing <a href="distributed.html">distributed monitoring</a>. If you're not doing distributed monitoring, don't enable this option.
+
+</p>
+
+<ul>
+
+<li>0 = Don't obsess over hosts (default)
+
+<li>1 = Obsess over hosts
+
+</ul>
+
+
+
+
+
+<a name="ochp_command"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Obsessive Compulsive Host Processor Command</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>ochp_command=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>ochp_command=obsessive_host_handler</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a command to be run after <i>every</i> host check, which can be useful in <a href="distributed.html">distributed monitoring</a>. This command is executed after any <a href="eventhandlers.html">event handler</a> or <a href="notifications.html">notification</a> commands. The <i>command</i> argument is the short name of a <a href="objectdefinitions.html#command">command definition</a> that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the <a href="#ochp_timeout">ochp_timeout</a> option. More information on distributed monitoring can be found <a href="distributed.html">here</a>. This command is only executed if the <a href="#obsess_over_hosts">obsess_over_hosts</a> option is enabled globally and if the <i>obsess_over_host</i> directive in the <a href="objectdefinitions.html#host">host definition</a> is enabled.
+
+</p>
+
+
+
+
+
+<a name="process_performance_data"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Performance Data Processing Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>process_performance_data=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>process_performance_data=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This value determines whether or not Nagios will process host and service check <a href="perfdata.html">performance data</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't process performance data (default)
+
+<li>1 = Process performance data
+
+</ul>
+
+
+
+
+
+<a name="host_perfdata_command"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Performance Data Processing Command</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_perfdata_command=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_perfdata_command=process-host-perfdata</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a command to be run after <i>every</i> host check to process host <a href="perfdata.html">performance data</a> that may be returned from the check. The <i>command</i> argument is the short name of a <a href="objectdefinitions.html#command">command definition</a> that you define in your object configuration file. This command is only executed if the <a href="#process_performance_data">process_performance_data</a> option is enabled globally and if the <i>process_perf_data</i> directive in the <a href="objectdefinitions.html#host">host definition</a> is enabled.
+
+</p>
+
+
+
+
+
+<a name="service_perfdata_command"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Performance Data Processing Command</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_perfdata_command=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_perfdata_command=process-service-perfdata</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a command to be run after <i>every</i> service check to process service <a href="perfdata.html">performance data</a> that may be returned from the check. The <i>command</i> argument is the short name of a <a href="objectdefinitions.html#command">command definition</a> that you define in your object configuration file. This command is only executed if the <a href="#process_performance_data">process_performance_data</a> option is enabled globally and if the <i>process_perf_data</i> directive in the <a href="objectdefinitions.html#service">service definition</a> is enabled.
+
+</p>
+
+
+
+
+
+<a name="host_perfdata_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Performance Data File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_perfdata_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_perfdata_file=/usr/local/nagios/var/host-perfdata.dat</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a file to which host <a href="perfdata.html">performance data</a> will be written after every host check. Data will be written to the performance file as specified by the <a href="#host_perfdata_file_template">host_perfdata_file_template</a> option. Performance data is only written to this file if the <a href="#process_performance_data">process_performance_data</a> option is enabled globally and if the <i>process_perf_data</i> directive in the <a href="objectdefinitions.html#host">host definition</a> is enabled.
+
+</p>
+
+
+
+
+
+<a name="service_perfdata_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Performance Data File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_perfdata_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_perfdata_file=/usr/local/nagios/var/service-perfdata.dat</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify a file to which service <a href="perfdata.html">performance data</a> will be written after every service check. Data will be written to the performance file as specified by the <a href="#service_perfdata_file_template">service_perfdata_file_template</a> option. Performance data is only written to this file if the <a href="#process_performance_data">process_performance_data</a> option is enabled globally and if the <i>process_perf_data</i> directive in the <a href="objectdefinitions.html#service">service definition</a> is enabled.
+
+</p>
+
+
+
+
+
+<a name="host_perfdata_file_template"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Performance Data File Template</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_perfdata_file_template=<template></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_perfdata_file_template=[HOSTPERFDATA]\t$TIMET$\t$HOSTNAME$\t$HOSTEXECUTIONTIME$\t$HOSTOUTPUT$\t$HOSTPERFDATA$</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines what (and how) data is written to the <a href="#host_perfdata_file">host performance data file</a>. The template may contain <a href="macros.html">macros</a>, special characters (\t for tab, \r for carriage return, \n for newline) and plain text. A newline is automatically added after each write to the performance data file.
+
+</p>
+
+
+
+
+
+<a name="service_perfdata_file_template"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Performance Data File Template</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_perfdata_file_template=<template></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_perfdata_file_template=[SERVICEPERFDATA]\t$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines what (and how) data is written to the <a href="#service_perfdata_file">service performance data file</a>. The template may contain <a href="macros.html">macros</a>, special characters (\t for tab, \r for carriage return, \n for newline) and plain text. A newline is automatically added after each write to the performance data file.
+
+</p>
+
+
+
+
+
+<a name="host_perfdata_file_mode"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Performance Data File Mode</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_perfdata_file_mode=<mode></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_perfdata_file_mode=a</strong></font></td>
+
+</tr>
+
+</table>
+
+<p>
+
+This option determines how the <a href="#host_perfdata_file">host performance data file</a> is opened. Unless the file is a named pipe you'll probably want to use the default mode of append.
+
+</p>
+
+<ul>
+
+<li>a = Open file in append mode (default)
+
+<li>w = Open file in write mode
+
+<li>p = Open in non-blocking read/write mode (useful when writing to pipes)
+
+</ul>
+
+
+
+
+
+<a name="service_perfdata_file_mode"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Performance Data File Mode</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_perfdata_file_mode=<mode></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_perfdata_file_mode=a</strong></font></td>
+
+</tr>
+
+</table>
+
+<p>
+
+This option determines how the <a href="#service_perfdata_file">service performance data file</a> is opened. Unless the file is a named pipe you'll probably want to use the default mode of append.
+
+</p>
+
+<ul>
+
+<li>a = Open file in append mode (default)
+
+<li>w = Open file in write mode
+
+<li>p = Open in non-blocking read/write mode (useful when writing to pipes)
+
+</ul>
+
+
+
+
+
+<a name="host_perfdata_file_processing_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Performance Data File Processing Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_perfdata_file_processing_interval=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_perfdata_file_processing_interval=0</strong></font></td>
+
+</tr>
+
+</table>
+
+<p>
+
+This option allows you to specify the interval (in seconds) at which the <a href="#host_perfdata_file">host performance data file</a> is processed using the <a href="#host_perfdata_file_processing_command">host performance data file processing command</a>. A value of 0 indicates that the performance data file should not be processed at regular intervals.
+
+</p>
+
+
+
+
+
+<a name="service_perfdata_file_processing_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Performance Data File Processing Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_perfdata_file_processing_interval=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_perfdata_file_processing_interval=0</strong></font></td>
+
+</tr>
+
+</table>
+
+<p>
+
+This option allows you to specify the interval (in seconds) at which the <a href="#service_perfdata_file">service performance data file</a> is processed using the <a href="#service_perfdata_file_processing_command">service performance data file processing command</a>. A value of 0 indicates that the performance data file should not be processed at regular intervals.
+
+</p>
+
+
+
+
+
+<a name="host_perfdata_file_processing_command"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Performance Data File Processing Command</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_perfdata_file_processing_command=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_perfdata_file_processing_command=process-host-perfdata-file</strong></font></td>
+
+</tr>
+
+</table>
+
+<p>
+
+This option allows you to specify the command that should be executed to process the <a href="#host_perfdata_file">host performance data file</a>. The <i>command</i> argument is the short name of a <a href="objectdefinitions.html#command">command definition</a> that you define in your object configuration file. The interval at which this command is executed is determined by the <a href="#host_perfdata_file_processing_interval">host_perfdata_file_processing_interval</a> directive.
+
+</p>
+
+
+
+
+
+<a name="service_perfdata_file_processing_command"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Performance Data File Processing Command</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_perfdata_file_processing_command=<command></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_perfdata_file_processing_command=process-service-perfdata-file</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify the command that should be executed to process the <a href="#service_perfdata_file">service performance data file</a>. The <i>command</i> argument is the short name of a <a href="objectdefinitions.html#command">command definition</a> that you define in your object configuration file. The interval at which this command is executed is determined by the <a href="#service_perfdata_file_processing_interval">service_perfdata_file_processing_interval</a> directive.
+
+</p>
+
+
+
+
+
+<a name="check_for_orphaned_services"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Orphaned Service Check Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_for_orphaned_services=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_for_orphaned_services=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to enable or disable checks for orphaned service checks. Orphaned service checks are checks which have been executed and have been removed from the event queue, but have not had any results reported in a long time. Since no results have come back in for the service, it is not rescheduled in the event queue. This can cause service checks to stop being executed. Normally it is very rare for this to happen - it might happen if an external user or process killed off the process that was being used to execute a service check. If this option is enabled and Nagios finds that results for a particular service check have not come back, it will log an error message and reschedule the service check. If you start seeing service checks that never seem to get rescheduled, enable this option and see if you notice any log messages about orphaned services.
+
+</p>
+
+<ul>
+
+<li>0 = Don't check for orphaned service checks
+
+<li>1 = Check for orphaned service checks (default)
+
+</ul>
+
+
+
+
+
+<a name="check_for_orphaned_hosts"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Orphaned Host Check Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_for_orphaned_hosts=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_for_orphaned_hosts=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to enable or disable checks for orphaned hoste checks. Orphaned host checks are checks which have been executed and have been removed from the event queue, but have not had any results reported in a long time. Since no results have come back in for the host, it is not rescheduled in the event queue. This can cause host checks to stop being executed. Normally it is very rare for this to happen - it might happen if an external user or process killed off the process that was being used to execute a host check. If this option is enabled and Nagios finds that results for a particular host check have not come back, it will log an error message and reschedule the host check. If you start seeing host checks that never seem to get rescheduled, enable this option and see if you notice any log messages about orphaned hosts.
+
+</p>
+
+<ul>
+
+<li>0 = Don't check for orphaned host checks
+
+<li>1 = Check for orphaned host checks (default)
+
+</ul>
+
+
+
+
+
+<a name="check_service_freshness"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Freshness Checking Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_service_freshness=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_service_freshness=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will periodically check the "freshness" of service checks. Enabling this option is useful for helping to ensure that <a href="passivechecks.html">passive service checks</a> are received in a timely manner. More information on freshness checking can be found <a href="freshness.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't check service freshness
+
+<li>1 = Check service freshness (default)
+
+</ul>
+
+
+
+
+
+<a name="service_freshness_check_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Service Freshness Check Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>service_freshness_check_interval=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>service_freshness_check_interval=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines how often (in seconds) Nagios will periodically check the "freshness" of service check results. If you have disabled service freshness checking (with the <a href="#check_service_freshness">check_service_freshness</a> option), this option has no effect. More information on freshness checking can be found <a href="freshness.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="check_host_freshness"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Freshness Checking Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>check_host_freshness=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>check_host_freshness=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not Nagios will periodically check the "freshness" of host checks. Enabling this option is useful for helping to ensure that <a href="passivechecks.html">passive host checks</a> are received in a timely manner. More information on freshness checking can be found <a href="freshness.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't check host freshness
+
+<li>1 = Check host freshness (default)
+
+</ul>
+
+
+
+
+
+<a name="host_freshness_check_interval"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Host Freshness Check Interval</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>host_freshness_check_interval=<seconds></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>host_freshness_check_interval=60</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines how often (in seconds) Nagios will periodically check the "freshness" of host check results. If you have disabled host freshness checking (with the <a href="#check_host_freshness">check_host_freshness</a> option), this option has no effect. More information on freshness checking can be found <a href="freshness.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="additional_freshness_latency"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Additional Freshness Threshold Latency Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>additional_freshness_latency=<#></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>additional_freshness_latency=15</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the number of seconds Nagios will add to any host or services freshness threshold it automatically calculates (e.g. those not specified explicity by the user). More information on freshness checking can be found <a href="freshness.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="enable_embedded_perl"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Embedded Perl Interpreter Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>enable_embedded_perl=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>enable_embedded_perl=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines whether or not the embedded Perl interpreter is enabled on a program-wide basis. Nagios must be compiled with support for embedded Perl for this option to have an effect. More information on the embedded Perl interpreter can be found <a href="embeddedperl.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="use_embedded_perl_implicitly"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Embedded Perl Implicit Use Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_embedded_perl_implicitly=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_embedded_perl_implicitly=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This setting determines whether or not the embedded Perl interpreter should be used for Perl plugins/scripts that do not explicitly enable/disable it. Nagios must be compiled with support for embedded Perl for this option to have an effect. More information on the embedded Perl interpreter and the effect of this setting can be found <a href="embeddedperl.html">here</a>.
+
+</p>
+
+
+
+
+
+<a name="date_format"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Date Format</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>date_format=<option></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>date_format=us</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify what kind of date/time format Nagios should use in the web interface and date/time <a href="macros.html">macros</a>. Possible options (along with example output) include:
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Option</th><th>Output Format</th><th>Sample Output</th></tr>
+
+<tr><td>us</td><td>MM/DD/YYYY HH:MM:SS</td><td>06/30/2002 03:15:00</td></tr>
+
+<tr><td>euro</td><td>DD/MM/YYYY HH:MM:SS</td><td>30/06/2002 03:15:00</td></tr>
+
+<tr><td>iso8601</td><td>YYYY-MM-DD HH:MM:SS</td><td>2002-06-30 03:15:00</td></tr>
+
+<tr><td>strict-iso8601</td><td>YYYY-MM-DDTHH:MM:SS</td><td>2002-06-30T03:15:00</td></tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<a name="use_timezone"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Timezone Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_timezone=<tz></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_timezone=US/Mountain</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to override the default timezone that this instance of Nagios runs in. Useful if you have multiple instances of Nagios that need to run from the same server, but have different local times associated with them. If not specified, Nagios will use the system configured timezone.
+
+</p>
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: If you use this option to specify a custom timezone, you will also need to alter the Apache configuration directives for the CGIs to specify the timezone you want. Example:
+
+</p>
+
+<div style="margin: 0 0 0 15px;">
+
+<Directory "/usr/local/nagios/sbin/"><br>
+
+SetEnv TZ "US/Mountain"<br>
+
+...<br>
+
+</Directory>
+
+</div>
+
+<br>
+
+
+
+
+
+<a name="illegal_object_name_chars"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Illegal Object Name Characters</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>illegal_object_name_chars=<chars...></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>illegal_object_name_chars=`~!$%^&*"|'<>?,()=</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify illegal characters that cannot be used in host names, service descriptions, or names of other object types. Nagios will allow you to use most characters in object definitions, but I recommend not using the characters shown in the example above. Doing may give you problems in the web interface, notification commands, etc.
+
+</p>
+
+
+
+
+
+<a name="illegal_macro_output_chars"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Illegal Macro Output Characters</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>illegal_macro_output_chars=<chars...></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>illegal_macro_output_chars=`~$^&"|'<></strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option allows you to specify illegal characters that should be stripped from <a href="macros.html">macros</a> before being used in notifications, event handlers, and other commands. This DOES NOT affect macros used in service or host check commands. You can choose to not strip out the characters shown in the example above, but I recommend you do not do this. Some of these characters are interpreted by the shell (i.e. the backtick) and can lead to security problems. The following macros are stripped of the characters you specify:
+
+</p>
+
+<p>
+
+<b>$HOSTOUTPUT$</b>, <b>$HOSTPERFDATA$</b>, <b>$HOSTACKAUTHOR$</b>, <b>$HOSTACKCOMMENT$</b>, <b>$SERVICEOUTPUT$</b>, <b>$SERVICEPERFDATA$</b>, <b>$SERVICEACKAUTHOR$</b>, and <b>$SERVICEACKCOMMENT$</b>
+
+</p>
+
+
+
+
+
+<a name="use_regexp_matching"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Regular Expression Matching Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_regexp_matching=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_regexp_matching=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines whether or not various directives in your <a href="configobject.html">object definitions</a> will be processed as regular expressions. More information on how this works can be found <a href="objecttricks.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use regular expression matching (default)
+
+<li>1 = Use regular expression matching
+
+</ul>
+
+
+
+
+
+<a name="use_true_regexp_matching"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>True Regular Expression Matching Option</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>use_true_regexp_matching=<0/1></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>use_true_regexp_matching=0</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+If you've enabled regular expression matching of various object directives using the <a href="#use_regexp_matching">use_regexp_matching</a> option, this option will determine when object directives are treated as regular expressions. If this option is disabled (the default), directives will only be treated as regular expressions if they contain <b>*</b>, <b>?</b>, <b>+</b>, or <b>\.</b>. If this option is enabled, all appropriate directives will be treated as regular expression - be careful when enabling this! More information on how this works can be found <a href="objecttricks.html">here</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Don't use true regular expression matching (default)
+
+<li>1 = Use true regular expression matching
+
+</ul>
+
+
+
+
+
+<a name="admin_email"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Administrator Email Address</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>admin_email=<email_address></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>admin_email=root@localhost.localdomain</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the email address for the administrator of the local machine (i.e. the one that Nagios is running on).
+
+This value can be used in notification commands by using the <b>$ADMINEMAIL$</b> <a href="macros.html">macro</a>.
+
+</p>
+
+
+
+
+
+<a name="admin_pager"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Administrator Pager</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>admin_pager=<pager_number_or_pager_email_gateway></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>admin_pager=pageroot@localhost.localdomain</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This is the pager number (or pager email gateway) for the administrator of the local machine (i.e. the one that Nagios is running on). The pager number/address can be used in notification commands by using the <b>$ADMINPAGER$</b> <a href="macros.html">macro</a>.
+
+</p>
+
+
+
+
+
+<a name="event_broker_options"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Event Broker Options</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>event_broker_options=<#></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>event_broker_options=-1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option controls what (if any) data gets sent to the event broker and, in turn, to any loaded event broker modules. This is an advanced option. When in doubt, either broker nothing (if not using event broker modules) or broker everything (if using event broker modules). Possible values are shown below.
+
+</p>
+
+<ul>
+
+<li>0 = Broker nothing
+
+<li>-1 = Broker everything
+
+<li># = See BROKER_* definitions in source code (include/broker.h) for other values that can be OR'ed together
+
+</ul>
+
+
+
+
+
+
+
+<a name="broker_module"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Event Broker Modules</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>broker_module=<modulepath> [moduleargs]</strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>broker_module=/usr/local/nagios/bin/ndomod.o cfg_file=/usr/local/nagios/etc/ndomod.cfg</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This directive is used to specify an event broker module that should by loaded by Nagios at startup. Use multiple directives if you want to load more than one module. Arguments that should be passed to the module at startup are seperated from the module path by a space.
+
+</p>
+
+<p>
+
+!!! WARNING !!!
+
+</p>
+
+<p>
+
+Do NOT overwrite modules while they are being used by Nagios or Nagios will crash in a fiery display of SEGFAULT glory. This is a bug/limitation either in dlopen(), the kernel, and/or the filesystem. And maybe Nagios...
+
+</p>
+
+<p>
+
+The correct/safe way of updating a module is by using one of these methods:
+
+</p>
+
+<ol>
+
+<li>Shutdown Nagios, replace the module file, restart Nagios</li>
+
+<li>While Nagios is running... delete the original module file, move the new module file into place, restart Nagios</li>
+
+</ol>
+
+
+
+
+
+<a name="debug_file"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Debug File</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>debug_file=<file_name></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>debug_file=/usr/local/nagios/var/nagios.debug</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines where Nagios should write debugging information. What (if any) information is written is determined by the <a href="#debug_level">debug_level</a> and <a href="#debug_verbosity">debug_verbosity</a> options. You can have Nagios automaticaly rotate the debug file when it reaches a certain size by using the <a href="#max_debug_file_size">max_debug_file_size</a> option.
+
+</p>
+
+
+
+
+
+<a name="debug_level"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Debug Level</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>debug_level=<#></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>debug_level=24</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines what type of information Nagios should write to the <a href="#debug_file">debug_file</a>. This value is a logical OR of the values below.
+
+</p>
+
+<ul>
+
+<li>-1 = Log everything
+
+<li>0 = Log nothing (default)
+
+<li>1 = Function enter/exit information
+
+<li>2 = Config information
+
+<li>4 = Process information
+
+<li>8 = Scheduled event information
+
+<li>16 = Host/service check information
+
+<li>32 = Notification information
+
+<li>64 = Event broker information
+
+</ul>
+
+
+
+<a name="debug_verbosity"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Debug Verbosity</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>debug_verbosity=<#></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>debug_verbosity=1</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines how much debugging information Nagios should write to the <a href="#debug_file">debug_file</a>.
+
+</p>
+
+<ul>
+
+<li>0 = Basic information
+
+<li>1 = More detailed information (default)
+
+<li>2 = Highly detailed information
+
+</ul>
+
+
+
+
+
+<a name="max_debug_file_size"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Maximum Debug File Size</strong></td>
+
+</tr>
+
+</table>
+
+<br>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>Format:</td>
+
+<td><strong>max_debug_file_size=<#></strong></td>
+
+</tr>
+
+<tr>
+
+<td>Example:</td>
+
+<td><font color="red"><strong>max_debug_file_size=1000000</strong></font></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+This option determines the maximum size (in bytes) of the <a href="#debug_file">debug file</a>. If the file grows larger than this size, it will be renamed with a .old extension. If a file already exists with a .old extension it will automatically be deleted. This helps ensure your disk space usage doesn't get out of control when debugging Nagios.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Object Configuration Overview</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Object Configuration Overview</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="config.html">Configuration Overview</a>, <a href="objectdefinitions.html">Object Definitions</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>What Are Objects?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Objects are all the elements that are involved in the monitoring and notification logic. Types of objects include:
+
+</p>
+
+
+
+<ul>
+
+<li>Services
+
+<li>Service Groups
+
+<li>Hosts
+
+<li>Host Groups
+
+<li>Contacts
+
+<li>Contact Groups
+
+<li>Commands
+
+<li>Time Periods
+
+<li>Notification Escalations
+
+<li>Notification and Execution Dependencies
+
+</ul>
+
+
+
+<p>
+
+More information on what objects are and how they relate to each other can be found below.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Where Are Objects Defined?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Objects can be defined in one or more configuration files and/or directories that you specify using the <a href="configmain.html#cfg_file">cfg_file</a> and/or <a href="configmain.html#cfg_dir">cfg_dir</a> directives in the main configuration file.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: When you follow <a href="quickstart.html">quickstart installation guide</a>, several sample object configuration files are placed in <i>/usr/local/nagios/etc/objects/</i>. You can use these sample files to see how object inheritance works and learn how to define your own object definitions.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Are Objects Defined?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Objects are defined in a flexible template format, which can make it much easier to manage your Nagios configuration in the long term. Basic information on how to define objects in your configuration files can be found <a href="objectdefinitions.html">here</a>.
+
+</p>
+
+<p>
+
+Once you get familiar with the basics of how to define objects, you should read up on <a href="objectinheritance.html">object inheritance</a>, as it will make your configuration more robust for the future. Seasoned users can exploit some advanced features of object definitions as described in the documentation on <a href="objecttricks.html">object tricks</a>.
+
+</p>
+
+
+
+<a name="objectoverview"></a>
+
+<p>
+
+<strong><u>Objects Explained</u></strong>
+
+</p>
+
+
+
+<p>
+
+Some of the main object types are explained in greater detail below...
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<a href="objectdefinitions.html#host"><b>Hosts</b></a> are one of the central objects in the monitoring logic. Important attributes of hosts are as follows:
+
+</p>
+
+<ul>
+
+<li>Hosts are usually physical devices on your network (servers, workstations, routers, switches, printers, etc).</li>
+
+<li>Hosts have an address of some kind (e.g. an IP or MAC address).</li>
+
+<li>Hosts have one or more more services associated with them.</li>
+
+<li>Hosts can have parent/child relationships with other hosts, often representing real-world network connections, which is used in the <a href="networkreachability.html">network reachability</a> logic.</li>
+
+</ul>
+
+<p>
+
+<a href="objectdefinitions.html#hostgroup"><b>Host Groups</b></a> are groups of one or more hosts. Host groups can make it easier to (1) view the status of related hosts in the Nagios web interface and (2) simplify your configuration through the use of <a href="objecttricks.html">object tricks</a>.
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<img src="images/objects-hosts.png" border="0" alt="Hosts">
+
+</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<a href="objectdefinitions.html#service"><b>Services</b></a> are one of the central objects in the monitoring logic. Services are associated with hosts and can be:
+
+</p>
+
+<ul>
+
+<li>Attributes of a host (CPU load, disk usage, uptime, etc.)</li>
+
+<li>Services provided by the host (HTTP, POP3, FTP, SSH, etc.)</li>
+
+<li>Other things associated with the host (DNS records, etc.)</li>
+
+</ul>
+
+<p>
+
+<a href="objectdefinitions.html#servicegroup"><b>Service Groups</b></a> are groups of one or more services. Service groups can make it easier to (1) view the status of related services in the Nagios web interface and (2) simplify your configuration through the use of <a href="objecttricks.html">object tricks</a>.
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<img src="images/objects-services.png" border="0" alt="Services">
+
+</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<a href="objectdefinitions.html#contact"><b>Contacts</b></a> are people involved in the notification process:
+
+</p>
+
+<ul>
+
+<li>Contacts have one or more notification methods (cellphone, pager, email, instant messaging, etc.)</li>
+
+<li>Contacts receive notifications for hosts and service they are responsible for</li>
+
+</ul>
+
+<p>
+
+<a href="objectdefinitions.html#contactgroup"><b>Contact Groups</b></a> are groups of one or more contacts. Contact groups can make it easier to define all the people who get notified when certain host or service problems occur.
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<img src="images/objects-contacts.png" border="0" alt="Contacts">
+
+</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<a href="objectdefinitions.html#timeperiod"><b>Timeperiods</b></a> are are used to control:
+
+</p>
+
+<ul>
+
+<li>When hosts and services can be monitored</li>
+
+<li>When contacts can receive notifications</li>
+
+</ul>
+
+<p>
+
+Information on how timeperiods work can be found <a href="timeperiods.html">here</a>.
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<img src="images/objects-timeperiods.png" border="0" alt="Timeperiods">
+
+</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<table border="0" class="Default">
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<a href="objectdefinitions.html#command"><b>Commands</b></a> are used to tell Nagios what programs, scripts, etc. it should execute to perform:
+
+</p>
+
+<ul>
+
+<li>Host and service checks</li>
+
+<li>Notifications</li>
+
+<li>Event handlers</li>
+
+<li>and more...</li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/objects-commands.png" border="0" alt="Commands">
+
+</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Custom Object Variables</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Custom Object Variables</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="objectdefinitions.html">Object Configuration</a>, <a href="objectinheritance.html">Object Inheritance</a>, <a href="macros.html">Macros</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Users often request that new variables be added to host, service, and contact definitions. These include variables for SNMP community, MAC address, AIM username, Skype number, and street address. The list is endless. The problem that I see with doing this is that it makes Nagios less generic and more infrastructure-specific. Nagios was intended to be flexible, which meant things needed to be designed in a generic manner. Host definitions in Nagios, for example, have a generic "address" variable that can contain anything from an IP address to human-readable driving directions - whatever is appropriate for the user's setup.
+
+</p>
+
+<p>
+
+Still, there needs to be a method for admins to store information about their infrastructure components in their Nagios configuration without imposing a set of specific variables on others. Nagios attempts to solve this problem by allowing users to define custom variables in their object definitions. Custom variables allow users to define additional properties in their host, service, and contact definitions, and use their values in notifications, event handlers, and host and service checks.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Custom Variable Basics</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are a few important things that you should note about custom variables:
+
+</p>
+
+
+
+<ul>
+
+<li>Custom variable names must begin with an underscore (_) to prevent name collision with standard variables
+
+<li>Custom variable names are converted to all uppercase before use
+
+<li>Custom variables are <a href="objectinheritance.html">inherited</a> from object templates like normal variables
+
+<li>Scripts can reference custom variable values with <a href="macros.html">macros and environment variables</a>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Examples</u></strong>
+
+</p>
+
+
+
+<p>
+
+Here's an example of how custom variables can be defined in different types of object definitions:
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ host_name linuxserver
+
+ _mac_address 00:06:5B:A6:AD:AA ; <-- Custom MAC_ADDRESS variable
+
+ _rack_number R32 ; <-- Custom RACK_NUMBER variable
+
+ ...
+
+ }
+
+
+
+define service{
+
+ host_name linuxserver
+
+ description Memory Usage
+
+ _SNMP_community public ; <-- Custom SNMP_COMMUNITY variable
+
+ _TechContact Jane Doe ; <-- Custom TECHCONTACT variable
+
+ ....
+
+ }
+
+
+
+define contact{
+
+ contact_name john
+
+ _AIM_username john16 ; <-- Custom AIM_USERNAME variable
+
+ _YahooID john32 ; <-- Custom YAHOOID variable
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Custom Variables As Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+Custom variable values can be referenced in scripts and executables that Nagios runs for checks, notifications, etc. by using <a href="macros.html">macros</a> or environment variables.
+
+</p>
+
+<p>
+
+In order to prevent name collision among custom variables from different object types, Nagios prepends "_HOST", "_SERVICE", or "_CONTACT" to the beginning of custom host, service, or contact variables, respectively, in macro and environment variable names. The table below shows the corresponding macro and environment variable names for the custom variables that were defined in the example above.
+
+</p>
+
+
+
+<p>
+
+<table border="1" class="Default">
+
+<tr><th>Object Type</th><th>Variable Name</th><th>Macro Name</th><th>Environment Variable</th></tr>
+
+<tr><td>Host</td><td>MAC_ADDRESS</td><td>$_HOSTMAC_ADDRESS$</td><td>NAGIOS__HOSTMAC_ADDRESS</td></tr>
+
+<tr><td>Host</td><td>RACK_NUMBER</td><td>$_HOSTRACK_NUMBER$</td><td>NAGIOS__HOSTRACK_NUMBER</td></tr>
+
+<tr><td>Service</td><td>SNMP_COMMUNITY</td><td>$_SERVICESNMP_COMMUNITY$</td><td>NAGIOS__SERVICESNMP_COMMUNITY</td></tr>
+
+<tr><td>Service</td><td>TECHCONTACT</td><td>$_SERVICETECHCONTACT$</td><td>NAGIOS__SERVICETECHCONTACT</td></tr>
+
+<tr><td>Contact</td><td>AIM_USERNAME</td><td>$_CONTACTAIM_USERNAME$</td><td>NAGIOS__CONTACTAIM_USERNAME</td></tr>
+
+<tr><td>Contact</td><td>YAHOOID</td><td>$_CONTACTYAHOOID$</td><td>NAGIOS__CONTACTYAHOOID</td></tr>
+
+</table>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Custom Variables And Inheritance</u></strong>
+
+</p>
+
+
+
+<p>
+
+Custom object variables are <a href="objectinheritance.html">inherited</a> just like standard host, service, or contact variables.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Host and Service Dependencies</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Host and Service Dependencies</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="dependencychecks.html">Predictive Dependency Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="hostchecks.html">Host Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Service and host dependencies are an advanced feature of Nagios that allow you to control the behavior of hosts and services based on the status of one or more other hosts or services. I'll explain how dependencies work, along with the differences between host and service dependencies.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Service Dependencies Overview</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are a few things you should know about service dependencies:
+
+</p>
+
+<ol>
+
+<li>A service can be dependent on one or more other services
+
+<li>A service can be dependent on services which are not associated with the same host
+
+<li>Service dependencies are not inherited (unless specifically configured to)
+
+<li>Service dependencies can be used to cause service check execution and service notifications to be suppressed under different circumstances (OK, WARNING, UNKNOWN, and/or CRITICAL states)
+
+<li>Service dependencies might only be valid during specific <a href="timeperiods.html">timeperiods</a></li>
+
+</ol>
+
+
+
+
+
+<p>
+
+<strong><u>Defining Service Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+First, the basics. You create service dependencies by adding <a href="objectdefinitions.html#servicedependency">service dependency definitions</a> in your <a href="configobject.html">object config file(s)</a>. In each definition you specify the <i>dependent</i> service, the service you are <i>depending on</i>, and the criteria (if any) that cause the execution and notification dependencies to fail (these are described later).
+
+</p>
+
+
+
+<p>
+
+You can create several dependencies for a given service, but you must add a separate service dependency definition for each dependency you create.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Example Service Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+The image below shows an example logical layout of service notification and execution dependencies. Different services are dependent on other services for notifications and check execution.
+
+</p>
+
+
+
+<img src="images/service-dependencies.png" alt="Service Dependencies">
+
+
+
+<p>
+
+In this example, the dependency definitions for <i>Service F</i> on <i>Host C</i> would be defined as follows:
+
+</p>
+
+
+
+<pre>
+
+define servicedependency{
+
+ host_name Host B
+
+ service_description Service D
+
+ dependent_host_name Host C
+
+ dependent_service_description Service F
+
+ execution_failure_criteria o
+
+ notification_failure_criteria w,u
+
+ }
+
+
+
+define servicedependency{
+
+ host_name Host B
+
+ service_description Service E
+
+ dependent_host_name Host C
+
+ dependent_service_description Service F
+
+ execution_failure_criteria n
+
+ notification_failure_criteria w,u,c
+
+ }
+
+
+
+define servicedependency{
+
+ host_name Host B
+
+ service_description Service C
+
+ dependent_host_name Host C
+
+ dependent_service_description Service F
+
+ execution_failure_criteria w
+
+ notification_failure_criteria c
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+The other dependency definitions shown in the image above would be defined as follows:
+
+</p>
+
+
+
+<pre>
+
+define servicedependency{
+
+ host_name Host A
+
+ service_description Service A
+
+ dependent_host_name Host B
+
+ dependent_service_description Service D
+
+ execution_failure_criteria u
+
+ notification_failure_criteria n
+
+ }
+
+
+
+define servicedependency{
+
+ host_name Host A
+
+ service_description Service B
+
+ dependent_host_name Host B
+
+ dependent_service_description Service E
+
+ execution_failure_criteria w,u
+
+ notification_failure_criteria c
+
+ }
+
+
+
+define servicedependency{
+
+ host_name Host B
+
+ service_description Service C
+
+ dependent_host_name Host B
+
+ dependent_service_description Service E
+
+ execution_failure_criteria n
+
+ notification_failure_criteria w,u,c
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>How Service Dependencies Are Tested</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before Nagios executes a service check or sends notifications out for a service, it will check to see if the service has any dependencies. If it doesn't have any dependencies, the check is executed or the notification is sent out as it normally would be. If the service <i>does</i> have one or more dependencies, Nagios will check each dependency entry as follows:
+
+</p>
+
+
+
+<ol>
+
+<li>Nagios gets the current status<sup><a href="#hard_dependencies">*</a></sup> of the service that is being <i>depended upon</i>.
+
+<li>Nagios compares the current status of the service that is being <i>depended upon</i> against either the execution or notification failure options in the dependency definition (whichever one is relevant at the time).
+
+<li>If the current status of the service that is being <i>depended upon</i> matches one of the failure options, the dependency is said to have failed and Nagios will break out of the dependency check loop.
+
+<li>If the current state of the service that is being <i>depended upon</i> does not match any of the failure options for the dependency entry, the dependency is said to have passed and Nagios will go on and check the next dependency entry. </ol>
+
+
+
+<p>
+
+This cycle continues until either all dependencies for the service have been checked or until one dependency check fails.
+
+</p>
+
+
+
+<p>
+
+<a name="hard_dependencies"></a>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: <sup>*</sup>One important thing to note is that by default, Nagios will use the most current <a href="statetypes.html">hard state</a> of the service(s) that is/are being depended upon when it does the dependeny checks. If you want Nagios to use the most current state of the services (regardless of whether its a soft or hard state), enable the <a href="configmain.html#soft_state_dependencies">soft_state_dependencies</a> option.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Execution Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+Execution dependencies are used to restrict when <a href="activechecks.html">active checks</a> of a service can be performed. <a href="passivechecks.html">Passive checks</a> are not restricted by execution dependencies.
+
+</p>
+
+
+
+<p>
+
+If <i>all</i> of the execution dependency tests for the service <i>passed</i>, Nagios will execute the check of the service as it normally would. If even just one of the execution dependencies for a service fails, Nagios will temporarily prevent the execution of checks for that (dependent) service. At some point in the future the execution dependency tests for the service may all pass. If this happens, Nagios will start checking the service again as it normally would. More information on the check scheduling logic can be found <a href="checkscheduling.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+In the example above, <b>Service E</b> would have failed execution dependencies if <b>Service B</b> is in a WARNING or UNKNOWN state. If this was the case, the service check would not be performed and the check would be scheduled for (potential) execution at a later time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Notification Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+If <i>all</i> of the notification dependency tests for the service <i>passed</i>, Nagios will send notifications out for the service as it normally would. If even just one of the notification dependencies for a service fails, Nagios will temporarily repress notifications for that (dependent) service. At some point in the future the notification dependency tests for the service may all pass. If this happens, Nagios will start sending out notifications again as it normally would for the service. More information on the notification logic can be found <a href="notifications.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+In the example above, <b>Service F</b> would have failed notification dependencies if <b>Service C</b> is in a CRITICAL state, <i>and/or</i> <b>Service D</b> is in a WARNING or UNKNOWN state, <i>and/or</i> if <b>Service E</b> is in a WARNING, UNKNOWN, or CRITICAL state. If this were the case, notifications for the service would not be sent out.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Dependency Inheritance</u></strong>
+
+</p>
+
+
+
+<p>
+
+As mentioned before, service dependencies are <i>not</i> inherited by default. In the example above you can see that Service F is dependent on Service E. However, it does not automatically inherit Service E's dependencies on Service B and Service C. In order to make Service F dependent on Service C we had to add another service dependency definition. There is no dependency definition for Service B, so Service F is <i>not</i> dependent on Service B.
+
+</p>
+
+
+
+<p>
+
+If you <i>do</i> wish to make service dependencies inheritable, you must use the <i>inherits_parent</i> directive in the <a href="objectdefinitions.html#servicedependency">service dependency</a> definition. When this directive is enabled, it indicates that the dependency inherits dependencies of the service <i>that is being depended upon</i> (also referred to as the master service). In other words, if the master service is dependent upon other services and any one of those dependencies fail, this dependency will also fail.
+
+</p>
+
+
+
+<p>
+
+In the example above, imagine that you want to add a new dependency for service F to make it dependent on service A. You could create a new dependency definition that specified service F as the <i>dependent</i> service and service A as being the <i>master</i> service (i.e. the service <i>that is being dependend on</i>). You could alternatively modify the dependency definition for services D and F to look like this:
+
+</p>
+
+
+
+<pre>
+
+define servicedependency{
+
+ host_name Host B
+
+ service_description Service D
+
+ dependent_host_name Host C
+
+ dependent_service_description Service F
+
+ execution_failure_criteria o
+
+ notification_failure_criteria n
+
+ inherits_parent 1
+
+ }
+
+
+
+</pre>
+
+
+
+<p>
+
+Since the <i>inherits_parent</i> directive is enabled, the dependency between services A and D will be tested when the dependency between services F and D are being tested.
+
+</p>
+
+
+
+<p>
+
+Dependencies can have multiple levels of inheritence. If the dependency definition between A and D had its <i>inherits_parent</i> directive enable and service A was dependent on some other service (let's call it service G), the service F would be dependent on services D, A, and G (each with potentially different criteria).
+
+</p>
+
+
+
+<p>
+
+<strong><u>Host Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+As you'd probably expect, host dependencies work in a similiar fashion to service dependencies. The difference is that they're for hosts, not services.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: Do not confuse host dependencies with parent/child host relationships. You should be using parent/child host relationships (defined with the <i>parents</i> directive in <a href="objectdefinitions.html#host">host</a> definitions) for most cases, rather than host dependencies. A description of how parent/child host relationships work can be found in the documentation on <a href="networkreachability.html">network reachability</a>.
+
+</p>
+
+
+
+<p>
+
+Here are the basics about host dependencies:
+
+</p>
+
+<ol>
+
+<li>A host can be dependent on one or more other host
+
+<li>Host dependencies are not inherited (unless specifically configured to)
+
+<li>Host dependencies can be used to cause host check execution and host notifications to be suppressed under different circumstances (UP, DOWN, and/or UNREACHABLE states)
+
+<li>Host dependencies might only be valid during specific <a href="timeperiods.html">timeperiods</a></li>
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Example Host Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+The image below shows an example of the logical layout of host notification dependencies. Different hosts are dependent on other hosts for notifications.
+
+</p>
+
+
+
+<img src="images/host-dependencies.png" alt="Host Dependencies">
+
+
+
+<p>
+
+In the example above, the dependency definitions for <i>Host C</i> would be defined as follows:
+
+</p>
+
+
+
+<pre>
+
+define hostdependency{
+
+ host_name Host A
+
+ dependent_host_name Host C
+
+ notification_failure_criteria d
+
+ }
+
+
+
+define hostdependency{
+
+ host_name Host B
+
+ dependent_host_name Host C
+
+ notification_failure_criteria d,u
+
+ }
+
+</pre>
+
+
+
+<p>
+
+As with service dependencies, host dependencies are not inherited. In the example image you can see that Host C does not inherit the host dependencies of Host B. In order for Host C to be dependent on Host A, a new host dependency definition must be defined.
+
+</p>
+
+
+
+<p>
+
+Host notification dependencies work in a similiar manner to service notification dependencies. If <i>all</i> of the notification dependency tests for the host <i>pass</i>, Nagios will send notifications out for the host as it normally would. If even just one of the notification dependencies for a host fails, Nagios will temporarily repress notifications for that (dependent) host. At some point in the future the notification dependency tests for the host may all pass. If this happens, Nagios will start sending out notifications again as it normally would for the host. More information on the notification logic can be found <a href="notifications.html">here</a>.
+
+</p>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Predictive Dependency Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Predictive Dependency Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="dependencies.html">Dependencies</a>, <a href="servicechecks.html">Service Checks</a>, <a href="hostchecks.html">Host Checks</a>, <a href="cachedchecks.html">Cached Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Host and service <a href="dependencies.html">dependencies</a> can be defined to allow you greater control over when checks are executed and when notifications are sent out. As dependencies are used to control basic aspects of the monitoring process, it is crucial to ensure that status information used in the dependency logic is as up to date as possible.
+
+</p>
+
+
+
+<p>
+
+Nagios allows you to enable predictive dependency checks for hosts and services to ensure that the dependency logic will have the most up-to-date status information when it comes to making decisions about whether to send out notifications or allow active checks of a host or service.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Do Predictive Checks Work?</u></strong>
+
+</p>
+
+
+
+<p>
+
+The image below shows a basic diagram of hosts that are being monitored by Nagios, along with their parent/child relationships and dependencies.
+
+</p>
+
+<p>
+
+The <i>Switch2</i> host in this example has just changed state from an UP state to a problem state. Nagios needs to determine whether the host is DOWN or UNREACHABLE, so it will launch parallel checks of <i>Switch2</i>'s immediate parents (<i>Firewall1</i>) and children (<i>Comp1</i>, <i>Comp2</i>, and <i>Switch3</i>). This is a normal function of the <a href="networkreachability.html">host reachability</a> logic.
+
+</p>
+
+<p>
+
+You will also notice that <i>Switch2</i> is depending on <i>Monitor1</i> and <i>File1</i> for either notifications or check execution (which one is unimportant in this example). If predictive host dependency checks are enabled, Nagios will launch parallel checks of <i>Monitor1</i> and <i>File1</i> at the same time it launches checks of <i>Switch2</i>'s immediate parents and children. Nagios does this because it knows that it will have to test the dependency logic in the near future (e.g. for purposes of notification) and it wants to make sure it has the most current status information for the hosts that take part in the dependency.
+
+</p>
+
+
+
+<p>
+
+<img src="images/predictive-dependency-checks.png" border="0" alt="Predictive Dependency Checks" title="Predictive Dependency Checks">
+
+</p>
+
+
+
+<p>
+
+That's how predictive dependency checks work. Simple, eh?
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Predictive service dependency checks work in a similiar manner to what is described above. Except, of course, they deal with services instead of hosts.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Enabling Predictive Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+Predictive dependency checks involve rather little overhead, so I would recommend that you enable them. In most cases, the benefits of having accurate information for the dependency logic outweighs the extra overhead imposed by these checks.
+
+</p>
+
+
+
+<p>
+
+Enabling predictive dependency checks is easy:
+
+</p>
+
+
+
+<ul>
+
+<li>Predictive host dependency checks are controlled by the <a href="configmain.html#enable_predictive_host_dependency_checks">enable_predictive_host_dependency_checks</a> option.</li>
+
+<li>Predictive service dependency checks are controlled by the <a href="configmain.html#enable_predictive_service_dependency_checks">enable_predictive_service_dependency_checks</a> option.</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Cached Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+Predictive dependency checks are on-demand checks and are therefore subject to the rules of <a href="cachedchecks.html">cached checks</a>. Cached checks can provide you with performance improvements by allowing Nagios to forgo running an actual host or service check if it can use a relatively recent check result instead. More information on cached checks can be found <a href="cachedchecks.html">here</a>.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Distributed Monitoring</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<h1 class="PageTitle">Distributed Monitoring</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios can be configured to support distributed monitoring of network services and resources. I'll try to briefly explan how this can be accomplished...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Goals</u></strong>
+
+</p>
+
+
+
+<p>
+
+The goal in the distributed monitoring environment that I will describe is to offload the overhead (CPU usage, etc.) of performing service checks from a "central" server onto one or more "distributed" servers. Most small to medium sized shops will not have a real need for setting up such an environment. However, when you want to start monitoring hundreds or even thousands of <i>hosts</i> (and several times that many services) using Nagios, this becomes quite important.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Reference Diagram</u></strong>
+
+</p>
+
+
+
+<p>
+
+The diagram below should help give you a general idea of how distributed monitoring works with Nagios. I'll be referring to the items shown in the diagram as I explain things...
+
+</p>
+
+
+
+<p>
+
+<a href="images/distributed.png"><img src="images/distributed.png" border=1 width="200" height="250"></a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Central Server vs. Distributed Servers</u></strong>
+
+</p>
+
+
+
+<p>
+
+When setting up a distributed monitoring environment with Nagios, there are differences in the way the central and distributed servers are configured. I'll show you how to configure both types of servers and explain what effects the changes being made have on the overall monitoring. For starters, lets describe the purpose of the different types of servers...
+
+</p>
+
+
+
+<p>
+
+The function of a <i>distributed server</i> is to actively perform checks all the services you define for a "cluster" of hosts. I use the term "cluster" loosely - it basically just mean an arbitrary group of hosts on your network. Depending on your network layout, you may have several cluters at one physical location, or each cluster may be separated by a WAN, its own firewall, etc. The important thing to remember to that for each cluster of hosts (however you define that), there is one distributed server that runs Nagios and monitors the services on the hosts in the cluster. A distributed server is usually a bare-bones installation of Nagios. It doesn't have to have the web interface installed, send out notifications, run event handler scripts, or do anything other than execute service checks if you don't want it to. More detailed information on configuring a distributed server comes later...
+
+</p>
+
+
+
+<p>
+
+The purpose of the <i>central server</i> is to simply listen for service check results from one or more distributed servers. Even though services are occassionally actively checked from the central server, the active checks are only performed in dire circumstances, so lets just say that the central server only accepts passive check for now. Since the central server is obtaining <a href="passivechecks.html">passive service check</a> results from one or more distributed servers, it serves as the focal point for all monitoring logic (i.e. it sends out notifications, runs event handler scripts, determines host states, has the web interface installed, etc).
+
+</p>
+
+
+
+<p>
+
+<strong><u>Obtaining Service Check Information From Distributed Monitors</u></strong>
+
+</p>
+
+
+
+<p>
+
+Okay, before we go jumping into configuration detail we need to know how to send the service check results from the distributed servers to the central server. I've already discussed how to submit passive check results to Nagios from same host that Nagios is running on (as described in the documentation on <a href="passivechecks.html">passive checks</a>), but I haven't given any info on how to submit passive check results from other hosts.
+
+</p>
+
+
+
+<p>
+
+In order to facilitate the submission of passive check results to a remote host, I've written the <a href="addons.html#nsca">nsca addon</a>. The addon consists of two pieces. The first is a client program (send_nsca) which is run from a remote host and is used to send the service check results to another server. The second piece is the nsca daemon (nsca) which either runs as a standalone daemon or under inetd and listens for connections from client programs. Upon receiving service check information from a client, the daemon will sumbit the check information to Nagios (on the central server) by inserting a <i>PROCESS_SVC_CHECK_RESULT</i> command into the <a href="configmain.html#command_file">external command file</a>, along with the check results. The next time Nagios checks for <a href="extcommands.html">external commands</a>, it will find the passive service check information that was sent from the distributed server and process it. Easy, huh?
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Distributed Server Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+So how exactly is Nagios configured on a distributed server? Basically, its just a bare-bones installation. You don't need to install the web interface or have notifications sent out from the server, as this will all be handled by the central server.
+
+</p>
+
+
+
+<p>
+
+Key configuration changes:
+
+</p>
+
+
+
+<ul>
+
+<li>Only those services and hosts which are being monitored directly by the distributed server are defined in the <a href="configobject.html">object configuration file</a>.
+
+<li>The distributed server has its <a href="configmain.html#enable_notifications">enable_notifications</a> directive set to 0. This will prevent any notifications from being sent out by the server.
+
+<li>The distributed server is configured to <a href="configmain.html#obsess_over_services">obsess over services</a>.
+
+<li>The distributed server has an <a href="configmain.html#ocsp_command">ocsp command</a> defined (as described below).
+
+</ul>
+
+
+
+<p>
+
+In order to make everything come together and work properly, we want the distributed server to report the results of <i>all</i> service checks to Nagios. We could use <a href="eventhandlers.html">event handlers</a> to report <i>changes</i> in the state of a service, but that just doesn't cut it. In order to force the distributed server to report all service check results, you must enabled the <a href="configmain.html#obsess_over_services">obsess_over_services</a> option in the main configuration file and provide a <a href="configmain.html#ocsp_command">ocsp_command</a> to be run after every service check. We will use the ocsp command to send the results of all service checks to the central server, making use of the send_nsca client and nsca daemon (as described above) to handle the tranmission.
+
+</p>
+
+
+
+<p>
+
+In order to accomplish this, you'll need to define an ocsp command like this:
+
+</p>
+
+
+
+<p>
+
+<strong><font color="red">ocsp_command=submit_check_result</font></strong>
+
+</p>
+
+
+
+<p>
+
+The command definition for the <i>submit_check_result</i> command looks something like this:
+
+</p>
+
+
+
+<p>
+
+<strong>
+
+<font color="red">
+
+<pre>
+
+define command{
+
+ command_name submit_check_result
+
+ command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
+
+ }
+
+</pre>
+
+</font>
+
+</strong>
+
+</p>
+
+
+
+<p>
+
+The <i>submit_check_result</i> shell scripts looks something like this (replace <i>central_server</i> with the IP address of the central server):
+
+</p>
+
+
+
+<pre>
+
+ #!/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
+
+
+
+ /bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | /usr/local/nagios/bin/send_nsca -H <i>central_server</i> -c /usr/local/nagios/etc/send_nsca.cfg
+
+</pre>
+
+
+
+<p>
+
+The script above assumes that you have the send_nsca program and it configuration file (send_nsca.cfg) located in the <i>/usr/local/nagios/bin/</i> and <i>/usr/local/nagios/etc/</i> directories, respectively.
+
+</p>
+
+
+
+<p>
+
+That's it! We've sucessfully configured a remote host running Nagios to act as a distributed monitoring server. Let's go over exactly what happens with the distributed server and how it sends service check results to Nagios (the steps outlined below correspond to the numbers in the reference diagram above):
+
+</p>
+
+
+
+<ol>
+
+<li>After the distributed server finishes executing a service check, it executes the command you defined by the <a href="configmain.html#ocsp_command">ocsp_command</a> variable. In our example, this is the <i>/usr/local/nagios/libexec/eventhandlers/submit_check_result</i> script. Note that the definition for the <i>submit_check_result</i> command passed four pieces of information to the script: the name of the host the service is associated with, the service description, the return code from the service check, and the plugin output from the service check.
+
+<li>The <i>submit_check_result</i> script pipes the service check information (host name, description, return code, and output) to the <i>send_nsca</i> client program.
+
+<li>The <i>send_nsca</i> program transmits the service check information to the <i>nsca</i> daemon on the central monitoring server.
+
+<li>The <i>nsca</i> daemon on the central server takes the service check information and writes it to the external command file for later pickup by Nagios.
+
+<li>The Nagios process on the central server reads the external command file and processes the passive service check information that originated from the distributed monitoring server.
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Central Server Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+We've looked at how distributed monitoring servers should be configured, so let's turn to the central server. For all intensive purposes, the central is configured as you would normally configure a standalone server. It is setup as follows:
+
+</p>
+
+
+
+<ul>
+
+<li>The central server has the web interface installed (optional, but recommended)
+
+<li>The central server has its <a href="configmain.html#enable_notifications">enable_notifications</a> directive set to 1. This will enable notifications. (optional, but recommended)
+
+<li>The central server has <a href="configmain.html#execute_service_checks">active service checks</a> disabled (optional, but recommended - see notes below)
+
+<li>The central server has <a href="configmain.html#check_external_commands">external command checks</a> enabled (required)
+
+<li>The central server has <a href="configmain.html#accept_passive_service_checks">passive service checks</a> enabled (required)
+
+</ul>
+
+
+
+<p>
+
+There are three other very important things that you need to keep in mind when configuring the central server:
+
+</p>
+
+
+
+<ul>
+
+<li>The central server must have service definitions for <i>all services</i> that are being monitored by all the distributed servers. Nagios will ignore passive check results if they do not correspond to a service that has been defined.
+
+<li>If you're only using the central server to process services whose results are going to be provided by distributed hosts, you can simply disable all active service checks on a program-wide basis by setting the <a href="configmain.html#execute_service_checks">execute_service_checks</a> directive to 0. If you're using the central server to actively monitor a few services on its own (without the aid of distributed servers), the <i>enable_active_checks</i> option of the defintions for service being monitored by distributed servers should be set to 0. This will prevent Nagios from actively checking those services.
+
+</ul>
+
+
+
+<p>
+
+It is important that you either disable all service checks on a program-wide basis or disable the <i>enable_active_checks</i> option in the definitions for each service that is monitored by a distributed server. This will ensure that active service checks are never executed under normal circumstances. The services will keep getting rescheduled at their normal check intervals (3 minutes, 5 minutes, etc...), but the won't actually be executed. This rescheduling loop will just continue all the while Nagios is running. I'll explain why this is done in a bit...
+
+</p>
+
+
+
+<p>
+
+That's it! Easy, huh?
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Problems With Passive Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+For all intensive purposes we can say that the central server is relying solely on passive checks for monitoring. The main problem with relying completely on passive checks for monitoring is the fact that Nagios must rely on something else to provide the monitoring data. What if the remote host that is sending in passive check results goes down or becomes unreachable? If Nagios isn't actively checking the services on the host, how will it know that there is a problem?
+
+</p>
+
+
+
+<p>
+
+Fortunately, there is a way we can handle these types of problems...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Freshness Checking</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios supports a feature that does "freshness" checking on the results of service checks. More information freshness checking can be found <a href="freshness.html">here</a>. This features gives some protection against situations where remote hosts may stop sending passive service checks into the central monitoring server. The purpose of "freshness" checking is to ensure that service checks are either being provided passively by distributed servers on a regular basis or performed actively by the central server if the need arises. If the service check results provided by the distributed servers get "stale", Nagios can be configured to force active checks of the service from the central monitoring host.
+
+</p>
+
+
+
+<p>
+
+So how do you do this? On the central monitoring server you need to configure services that are being monitoring by distributed servers as follows...
+
+</p>
+
+
+
+<ul>
+
+<li>The <i>check_freshness</i> option in the service definitions should be set to 1. This enables "freshness" checking for the services.
+
+<li>The <i>freshness_threshold</i> option in the service definitions should be set to a value (in seconds) which reflects how "fresh" the results for the services (provided by the distributed servers) should be.
+
+<li>The <i>check_command</i> option in the service definitions should reflect valid commands that can be used to actively check the service from the central monitoring server.
+
+</ul>
+
+
+
+<p>
+
+Nagios periodically checks the "freshness" of the results for all services that have freshness checking enabled. The <i>freshness_threshold</i> option in each service definition is used to determine how "fresh" the results for each service should be. For example, if you set this value to 300 for one of your services, Nagios will consider the service results to be "stale" if they're older than 5 minutes (300 seconds). If you do not specify a value for the <i>freshness_threshold</i> option, Nagios will automatically calculate a "freshness" threshold by looking at either the <i>normal_check_interval</i> or <i>retry_check_interval</i> options (depending on what <a href="statetypes.html">type of state</a> the service is in). If the service results are found to be "stale", Nagios will run the service check command specified by the <i>check_command</i> option in the service definition, thereby actively checking the service.
+
+</p>
+
+
+
+<p>
+
+Remember that you have to specify a <i>check_command</i> option in the service definitions that can be used to actively check the status of the service from the central monitoring server. Under normal circumstances, this check command is never executed (because active checks were disabled on a program-wide basis or for the specific services). When freshness checking is enabled, Nagios will run this command to actively check the status of the service <i>even if active checks are disabled on a program-wide or service-specific basis</i>.
+
+</p>
+
+
+
+<p>
+
+If you are unable to define commands to actively check a service from the central monitoring host (or if turns out to be a major pain), you could simply define all your services with the <i>check_command</i> option set to run a dummy script that returns a critical status. Here's an example... Let's assume you define a command called 'service-is-stale' and use that command name in the <i>check_command</i> option of your services. Here's what the definition would look like...
+
+</p>
+
+
+
+<p>
+
+<strong>
+
+<font color="red">
+
+<pre>
+
+define command{
+
+ command_name service-is-stale
+
+ command_line /usr/local/nagios/libexec/check_dummy 2 "CRITICAL: Service results are stale"
+
+ }
+
+</pre>
+
+</font>
+
+</strong>
+
+</p>
+
+
+
+
+
+<p>
+
+When Nagios detects that the service results are stale and runs the <b>service-is-stale</b> command, the <i>check_dummy</i> plugin is executed and the service will go into a critical state. This would likely cause notifications to be sent out, so you'll know that there's a problem.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Performing Host Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+At this point you know how to obtain service check results passivly from distributed servers. This means that the central server is not actively checking services on its own. But what about host checks? You still need to do them, so how?
+
+</p>
+
+
+
+<p>
+
+Since host checks usually compromise a small part of monitoring activity (they aren't done unless absolutely necessary), I'd recommend that you perform host checks actively from the central server. That means that you define host checks on the central server the same way that you do on the distributed servers (and the same way you would in a normal, non-distributed setup).
+
+</p>
+
+
+
+<p>
+
+Passive host checks are available (read <a href="passivechecks.html">here</a>), so you could use them in your distributed monitoring setup, but they suffer from a few problems. The biggest problem is that Nagios does not translate passive host check problem states (DOWN and UNREACHABLE) when they are processed. This means that if your monitoring servers have a different parent/child host structure (and they will, if you monitoring servers are in different locations), the central monitoring server will have an inaccurate view of host states.
+
+</p>
+
+
+
+<p>
+
+If you do want to send passive host checks to a central server in your distributed monitoring setup, make sure:
+
+</p>
+
+
+
+<ul>
+
+<li>The central server has <a href="configmain.html#accept_passive_host_checks">passive host checks</a> enabled (required)
+
+<li>The distributed server is configured to <a href="configmain.html#obsess_over_hosts">obsess over hosts</a>.
+
+<li>The distributed server has an <a href="configmain.html#ochp_command">ochp command</a> defined.
+
+</ul>
+
+
+
+<p>
+
+The ochp command, which is used for processing host check results, works in a similiar manner to the ocsp command, which is used for processing service check results (see documentation above). In order to make sure passive host check results are up to date, you'll want to enable <a href="freshness.html">freshness checking</a> for hosts (similiar to what is described above for services).
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Scheduled Downtime</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Scheduled Downtime</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="notifications.html">Notifications</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios allows you to schedule periods of planned downtime for hosts and service that you're monitoring. This is useful in the event that you actually know you're going to be taking a server down for an upgrade, etc.
+
+</p>
+
+
+
+<img src="images/downtime.png" border="0" style="float: right;" alt="Scheduled Downtime" title="Scheduled Downtime">
+
+
+
+
+
+<p>
+
+<strong><u>Scheduling Downtime</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can schedule downtime for hosts and service through the <a href="cgis.html#extinfo_cgi">extinfo CGI</a> (either when viewing host or service information). Click in the "Schedule downtime for this host/service" link to actually schedule the downtime.
+
+</p>
+
+
+
+<p>
+
+Once you schedule downtime for a host or service, Nagios will add a comment to that host/service indicating that it is scheduled for downtime during the period of time you indicated. When that period of downtime passes, Nagios will automatically delete the comment that it added. Nice, huh?
+
+</p>
+
+
+
+<p>
+
+<strong><u>Fixed vs. Flexible Downtime</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you schedule downtime for a host or service through the web interface you'll be asked if the downtime is fixed or flexible. Here's an explanation of how "fixed" and "flexible" downtime differs:
+
+</p>
+
+
+
+<p>
+
+"Fixed" downtime starts and stops at the exact start and end times that you specify when you schedule it. Okay, that was easy enough...
+
+</p>
+
+
+
+<p>
+
+"Flexible" downtime is intended for times when you know that a host or service is going to be down for X minutes (or hours), but you don't know exactly when that'll start. When you schedule flexible downtime, Nagios will start the scheduled downtime sometime between the start and end times you specified. The downtime will last for as long as the duration you specified when you scheduled the downtime. This assumes that the host or service for which you scheduled flexible downtime either goes down (or becomes unreachable) or goes into a non-OK state sometime between the start and end times you specified. The time at which a host or service transitions to a problem state determines the time at which Nagios actually starts the downtime. The downtime will then last for the duration you specified, even if the host or service recovers before the downtime expires. This is done for a very good reason. As we all know, you might think you've got a problem fixed, but then have to restart a server ten times before it actually works right. Smart, eh?
+
+</p>
+
+
+
+<p>
+
+<strong><u>Triggered Downtime</u></strong>
+
+</p>
+
+
+
+<p>
+
+When scheduling host or service downtime you have the option of making it "triggered" downtime. What is triggered downtime, you ask? With triggered downtime the start of the downtime is triggered by the start of some other scheduled host or service downtime. This is extremely useful if you're scheduling downtime for a large number or hosts or services and the start time of the downtime period depends on the start time of another downtime entry. For instance, if you schedule flexible downtime for a particular host (because its going down for maintenance), you might want to schedule triggered downtime for all of that hosts's "children".
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>How Scheduled Downtime Affects Notifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+When a host or service is in a period of scheduled downtime, Nagios will not allow normal notifications to be sent out for the host or service. However, a "DOWNTIMESTART" notification will get sent out for the host or service, which will serve to put any admins on notice that they won't receive upcoming problem alerts.
+
+</p>
+
+<p>
+
+When the scheduled downtime is over, Nagios will allow normal notifications to be sent out for the host or service again. A "DOWNTIMEEND" notification will get sent out notifying admins that the scheduled downtime is over, and they will start receiving normal alerts again.
+
+</p>
+
+<p>
+
+If the scheduled downtime is cancelled prematurely (before it expires), a "DOWNTIMECANCELLED" notification will get sent out to the appropriate admins.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Overlapping Scheduled Downtime</u></strong>
+
+</p>
+
+
+
+<p>
+
+I like to refer to this as the "Oh crap, its not working" syndrome. You know what I'm talking about. You take a server down to perform a "routine" hardware upgrade, only to later realize that the OS drivers aren't working, the RAID array blew up, or the drive imaging failed and left your original disks useless to the world. Moral of the story is that any routine work on a server is quite likely to take three or four times as long as you had originally planned...
+
+</p>
+
+
+
+<p>
+
+Let's take the following scenario:
+
+</p>
+
+
+
+<ol>
+
+<li>You schedule downtime for host A from 7:30pm-9:30pm on a Monday
+
+<li>You bring the server down about 7:45pm Monday evening to start a hard drive upgrade
+
+<li>After wasting an hour and a half battling with SCSI errors and driver incompatabilities, you finally get the machine to boot up
+
+<li>At 9:15 you realize that one of your partitions is either hosed or doesn't seem to exist anywhere on the drive
+
+<li>Knowing you're in for a long night, you go back and schedule additional downtime for host A from 9:20pm Monday evening to 1:30am Tuesday Morning.
+
+</ol>
+
+
+
+<p>
+
+If you schedule overlapping periods of downtime for a host or service (in this case the periods were 7:40pm-9:30pm and 9:20pm-1:30am), Nagios will wait until the last period of scheduled downtime is over before it allows notifications to be sent out for that host or service. In this example notifications would be suppressed for host A until 1:30am Tuesday morning.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Using The Embedded Perl Interpreter</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Using The Embedded Perl Interpreter</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="epnplugins.html">Developing Plugins For Use With Embedded Perl</a>
+
+</p>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios can be compiled with support for an embedded Perl interpreter. This allows Nagios to execute Perl plugins much more efficiently that it otherwise would, so it may be of interest to you if you rely heavily on plugins written in Perl.
+
+</p>
+
+
+
+<p>
+
+Without the embedded Perl interpreter, Nagios executes Perl (and non-Perl) plugins by forking and executing the plugins as an external command. When the embedded Perl interpreter is used, Nagios can execute Perl plugins by simply making a library call.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: The embedded Perl interpreter works with all Perl scripts that Nagios executes - not just plugins. This documentation discusses the embedded Perl interpreter in relation to plugins used for host and service checks, but it applies just the same to other types of Perl scripts you may be using for other types of commands (e.g. notification scripts, event handler scripts, etc.).
+
+</p>
+
+
+
+
+
+<p>
+
+Stephen Davies contributed the original embedded Perl interpreter code several years back. Stanley Hopcroft has been the primary person helping to improve the embedded Perl interpreter code quite a bit and has commented on the advantages/disadvanges of using it. He has also given several helpful hints on creating Perl plugins that work properly with the embedded interpreter.
+
+</p>
+
+
+
+<p>
+
+It should be noted that "ePN", as used in this documentation, refers to embedded Perl Nagios, or if you prefer, Nagios compiled with an embedded Perl interpreter.
+
+</p>
+
+</td>
+
+<td valign="top"><img src="images/epn.png" border="0" alt="Embedded Perl Interpreter" title="Embedded Perl Interpreter"></td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+<strong><u>Advantages</u></strong>
+
+</p>
+
+
+
+<p>
+
+Some advantages of ePN (embedded Perl Nagios) include:
+
+</p>
+
+
+
+<ul>
+
+
+
+<li>Nagios will spend much less time running your Perl plugins because it no longer forks to execute the plugin (each time loading the Perl interpreter). Instead, it executes your plugin by making a library call.<br><br>
+
+
+
+<li>It greatly reduces the system impact of Perl plugins and/or allows you to run more checks with Perl plugin than you otherwise would be able to. In other words, you have less incentive to write plugins in other languages such as C/C++, or Expect/TCL, that are generally recognised to have development times at least an order of magnitude slower than Perl (although they do run about ten times faster also - TCL being an exception).<br><br>
+
+
+
+<li>If you are not a C programmer, then you can still get a huge amount of mileage out of Nagios by letting Perl do all the heavy lifting without having Nagios slow right down. Note however, that the ePN will not speed up your plugin (apart from eliminating the interpreter load time). If you want fast plugins then consider Perl XSUBs (XS), or C <i>after</i> you are sure that your Perl is tuned and that you have a suitable algorithm (Benchmark.pm is <i>invaluable</i> for comparing the performance of Perl language elements).<br><br>
+
+
+
+<li>Using the ePN is an excellent opportunity to learn more about Perl.<br><br>
+
+
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Disadvantages</u></strong>
+
+</p>
+
+
+
+<p>
+
+The disadvantages of ePN (embedded Perl Nagios) are much the same as Apache mod_perl (i.e. Apache with an embedded interpreter) compared to a plain Apache:
+
+</p>
+
+
+
+<ul>
+
+
+
+<li>A Perl program that works <i>fine</i> with plain Nagios may <i>not</i> work with the ePN. You may have to modify your plugins to get them to work.<br><br>
+
+
+
+<li>Perl plugins are harder to debug under an ePN than under a plain Nagios.<br><br>
+
+
+
+<li>Your ePN will have a larger SIZE (memory footprint) than a plain Nagios.<br><br>
+
+
+
+<li>Some Perl constructs cannot be used or may behave differently than what you would expect.<br><br>
+
+
+
+<li>You may have to be aware of 'more than one way to do it' and choose a way that seems less attractive or obvious.<br><br>
+
+
+
+<li>You will need greater Perl knowledge (but nothing very esoteric or stuff about Perl internals - unless your plugin uses XSUBS).<br><br>
+
+
+
+</ul>
+
+
+
+
+
+<p>
+
+<strong><u>Using The Embedded Perl Interpreter</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you want to use the embedded Perl interpreter to run your Perl plugins and scripts, here's what you'll need to do:
+
+</p>
+
+
+
+<ol>
+
+<li>Compile Nagios with support for the embedded Perl interpreter (see instructions below).<br><br></li>
+
+<li>Enable the <a href="configmain.html#enable_embedded_perl">enable_embedded_perl</a> option in the main configuration file.<br><br></li>
+
+<li>Set the <a href="configmain.html#use_embedded_perl_implicitly">use_embedded_perl_implicitly</a> option to fit your needs. This option determines whether or not the Perl interpreter should be used by default for individual Perl plugins and scripts.<br><br></li>
+
+<li>Optionally enable or disable certain Perl plugins and scripts from being run using the embedded Perl interpreter. This can be useful if certain Perl scripts have problems being running under the Perl interpreter. See instructions below for more information on doing this.<br><br></li>
+
+</ol>
+
+
+
+
+
+<p>
+
+<strong><u>Compiling Nagios With Embedded Perl</u></strong>
+
+</p>
+
+
+
+
+
+<p>
+
+If you want to use the embedded Perl interpreter, you'll first need to compile Nagios with support for it.
+
+To do this, simply run the configure script with the addition of the <font color="red"><i>--enable-embedded-perl</i></font> option. If you want the embedded interpreter to cache internally compiled scripts, add the <font color="red"><i>--with-perlcache</i></font> option as well. Example:
+
+</p>
+
+
+
+<pre>
+
+ ./configure --enable-embedded-perl --with-perlcache <i>otheroptions...</i>
+
+</pre>
+
+
+
+<p>
+
+Once you've rerun the configure script with the new options, make sure to recompile Nagios.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Plugin-Specific Use of the Perl Interpreter</u></strong>
+
+</p>
+
+
+
+<p>
+
+Beginning with Nagios 3, you can specify which Perl plugins or scripts should or should not be run under the embedded Perl interpreter. This is particularly useful if you have troublesome Perl scripts which do not work well with the Perl interpreter.
+
+</p>
+
+
+
+<p>
+
+To <i>explicitly</i> tell Nagios whether or not to use the embedded Perl interpreter for a particular perl script, add one of the following entries to your Perl script/plugin...
+
+</p>
+
+
+
+<p>
+
+To tell Nagios to use the Perl interpreter for a particular script, add this line to the Perl script:
+
+</p>
+
+
+
+<pre>
+
+# nagios: +epn
+
+</pre>
+
+
+
+<p>
+
+To tell Nagios to NOT use the embedded Perl interpreter for a particular script, add this line to the Perl script:
+
+</p>
+
+
+
+<pre>
+
+# nagios: -epn
+
+</pre>
+
+
+
+
+
+<p>
+
+Either line must be located within the first 10 lines of a script for Nagios to detect it.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: If you do not <i>explicitly</i> use the method above to tell Nagios whether an individual plugin can be run under the Perl interpreter, Nagios will make will a decision for you. This decision process is controlled by the <a href="configmain.html#use_embedded_perl_implicitly">use_embedded_perl_implicitly</a> variable. If the value is set to 1, all Perl plugins/scripts (that do not explicitly enable/disable the ePN) will be run under the Perl interpreter. If the value is 0, they will NOT be run under the Perl interpreter.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Developing Plugins For Use With Embedded Perl</u></strong>
+
+</p>
+
+
+
+<p>
+
+Information on developing plugins for use with the embedded Perl interpreter can be found <a href="epnplugins.html">here</a>.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Developing Plugins For Use With Embedded Perl</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Developing Plugins For Use With Embedded Perl</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="embeddedperl.html">Embedded Perl Interpreter Overview</a>, <a href="pluginapi.html">Plugin API</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Stanley Hopcroft has worked with the embedded Perl interpreter quite a bit and has commented on the advantages/disadvanges of using it. He has also given several helpful hints on creating Perl plugins that work properly with the embedded interpreter. The majority of this documentation comes from his comments.
+
+</p>
+
+<p>
+
+It should be noted that "ePN", as used in this documentation, refers to embedded Perl Nagios, or if you prefer, Nagios compiled with an embedded Perl interpreter.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Target Audience</u></strong>
+
+</p>
+
+
+
+<ul>
+
+
+
+<li>Average Perl developers; those with an appreciation of the languages powerful features without knowledge of internals or an in depth knowledge of those features.<br><br>
+
+
+
+<li>Those with a utilitarian appreciation rather than a great depth of understanding.<br><br>
+
+
+
+<li>If you are happy with Perl objects, name management, data structures, and the debugger, that's probably sufficient.<br><br>
+
+
+
+</ul>
+
+
+
+
+
+<p>
+
+<strong><u>Things you should do when developing a Perl Plugin (ePN or not)</u></strong>
+
+</p>
+
+
+
+<ul>
+
+
+
+<li>Always always generate some output<br><br>
+
+
+
+<li>Use 'use utils' and import the stuff it exports ($TIMEOUT %ERRORS &print_revision &support)<br><br>
+
+
+
+<li>Have a look at how the standard Perl plugins do their stuff e.g.<br><br>
+
+
+
+<ul>
+
+<li>Always exit with $ERRORS{CRITICAL}, $ERRORS{OK}, etc.
+
+<li>Use getopt to read command line arguments
+
+<li>Manage timeouts
+
+<li>Call print_usage (supplied by you) when there are no command line arguments
+
+<li>Use standard switch names (eg H 'host', V 'version')
+
+</ul>
+
+
+
+</ul>
+
+
+
+
+
+<p>
+
+<strong><u>Things you must do to develop a Perl plugin for ePN</u></strong>
+
+</p>
+
+
+
+<ol>
+
+
+
+
+
+<li><DATA> can not be used; use here documents instead e.g.<br><br>
+
+<pre>
+
+my $data = <<DATA;
+
+portmapper 100000
+
+portmap 100000
+
+sunrpc 100000
+
+rpcbind 100000
+
+rstatd 100001
+
+rstat 100001
+
+rup 100001
+
+..
+
+DATA
+
+
+
+%prognum = map { my($a, $b) = split; ($a, $b) } split(/\n/, $data) ;
+
+</pre>
+
+
+
+<li>BEGIN blocks will not work as you expect. May be best to avoid.<br><br>
+
+
+
+<li>Ensure that it is squeaky clean at compile time i.e.<br><br>
+
+<ul>
+
+<li>use strict
+
+<li>use perl -w (other switches [T notably] may not help)
+
+<li>use perl -c
+
+</ul>
+
+
+
+<br><br>
+
+
+
+<li>Avoid lexical variables (my) with global scope as a means of passing __variable__ data into subroutines. In fact this is __fatal__ if the subroutine is called by the plugin more than once when the check is run. Such subroutines act as 'closures' that lock the global lexicals first value into subsequent calls of the subroutine. If however, your global
+
+is read-only (a complicated structure for example) this is not a problem. What Bekman <a href="http://perl.apache.org/docs/1.0/guide/">recommends you do instead</a>, is any of the following:<br><br>
+
+
+
+<ul>
+
+<li>make the subroutine anonymous and call it via a code ref e.g.<br><br>
+
+<pre>
+
+turn this into
+
+
+
+my $x = 1 ; my $x = 1 ;
+
+sub a { .. Process $x ... } $a_cr = sub { ... Process $x ... } ;
+
+. .
+
+. .
+
+a ; &$a_cr ;
+
+$x = 2 $x = 2 ;
+
+a ; &$a_cr ;
+
+
+
+# anon closures __always__ rebind the current lexical value
+
+</pre>
+
+
+
+<li>put the global lexical and the subroutine using it in their own package (as an object or a module)
+
+
+
+<li>pass info to subs as references or aliases (\$lex_var or $_[n])
+
+
+
+<li>replace lexicals with package globals and exclude them from 'use strict' objections with 'use vars qw(global1 global2 ..)'
+
+</ul>
+
+
+
+<br>
+
+
+
+<li>Be aware of where you can get more information.<br><br>
+
+
+
+<p>
+
+Useful information can be had from the usual suspects (the O'Reilly books, plus Damien Conways "Object Oriented Perl") but for the really useful stuff in the right context start at Stas Bekman's mod_perl guide at <a href="http://perl.apache.org/guide/">http://perl.apache.org/guide/</a>.
+
+</p>
+
+<p>
+
+This wonderful book sized document has nothing whatsoever about Nagios, but all about writing Perl programs for the embedded Perl interpreter in Apache (ie Doug MacEacherns mod_perl).
+
+</p>
+
+<p>
+
+The perlembed manpage is essential for context and encouragement.
+
+</p>
+
+<p>
+
+On the basis that Lincoln Stein and Doug MacEachern know a thing or two about Perl and embedding Perl, their book 'Writing Apache Modules with Perl and C' is almost certainly worth looking at.
+
+</p>
+
+
+
+<li>Be aware that your plugin may return strange values with an ePN and that this is likely to be caused by the problem in item #4 above<br><br>
+
+
+
+
+
+<li>Be prepared to debug via:<br><br>
+
+<ul>
+
+<li>having a test ePN and
+
+<li>adding print statements to your plugin to display variable values to STDERR (can't use STDOUT)
+
+<li>adding print statements to p1.pl to display what ePN thinks your plugin is before it tries to run it (vi)
+
+<li>running the ePN in foreground mode (probably in conjunction with the former recommendations)
+
+<li>use the 'Deparse' module on your plugin to see how the parser has optimised it and what the interpreter will actually get. (see 'Constants in Perl' by Sean M. Burke, The Perl Journal, Fall 2001)
+
+</ul>
+
+
+
+<br>
+
+
+
+<pre>
+
+perl -MO::Deparse <your_program>
+
+</pre>
+
+
+
+<br>
+
+
+
+<li>Be aware of what ePN is transforming your plugin too, and if all else fails try and debug the transformed version.<br><br>
+
+
+
+<p>
+
+As you can see below p1.pl rewrites your plugin as a subroutine called 'hndlr' in the package named 'Embed::<something_related_to_your_plugin_file_name>'.
+
+</p>
+
+<p>
+
+Your plugin may be expecting command line arguments in @ARGV so pl.pl also assigns @_ to @ARGV.
+
+</p>
+
+<p>
+
+This in turn gets 'eval' ed and if the eval raises an error (any parse error and run error), the plugin gets chucked out.
+
+</p>
+
+<p>
+
+The following output shows how a test ePN transformed the <i>check_rpc</i> plugin before attempting to execute it. Most of the code from the actual plugin is not shown, as we are interested in only the transformations that the ePN has made to the plugin). For clarity, transformations are shown in red:
+
+</p>
+
+
+
+<pre>
+
+<font color="red">
+
+ package main;
+
+ use subs 'CORE::GLOBAL::exit';
+
+ sub CORE::GLOBAL::exit { die "ExitTrap: $_[0]
+
+(Embed::check_5frpc)"; }
+
+ package Embed::check_5frpc; sub hndlr { shift(@_);
+
+@ARGV=@_;</font>
+
+#! /usr/bin/perl -w
+
+#
+
+# check_rpc plugin for Nagios
+
+#
+
+# usage:
+
+# check_rpc host service
+
+#
+
+# Check if an rpc serice is registered and running
+
+# using rpcinfo - $proto $host $prognum 2>&1 |";
+
+#
+
+# Use these hosts.cfg entries as examples
+
+#
+
+# command[check_nfs]=/some/path/libexec/check_rpc $HOSTADDRESS$ nfs
+
+# service[check_nfs]=NFS;24x7;3;5;5;unix-admin;60;24x7;1;1;1;;check_rpc
+
+#
+
+# initial version: 3 May 2000 by Truongchinh Nguyen and Karl DeBisschop
+
+# current status: $Revision$
+
+#
+
+# Copyright Notice: GPL
+
+#
+
+<i>... rest of plugin code goes here (it was removed for brevity) ...</i>
+
+<font color="red">}</font>
+
+</pre>
+
+
+
+
+
+<br>
+
+
+
+<li>Don't use 'use diagnostics' in a plugin run by your production ePN. I think it causes__all__ the Perl plugins to return CRITICAL.<br><br>
+
+
+
+<li>Consider using a mini embedded Perl C program to check your plugin. This is not sufficient to guarantee your plugin will perform Ok with an ePN but if the plugin fails this test it will certainly fail with your ePN. <font color="red">[ A sample mini ePN is included in the <i>contrib/</i> directory of the Nagios distribution for use in testing Perl plugins. Change to the contrib/ directory and type 'make mini_epn' to compile it. It must be executed from the same directory that the p1.pl file resides in (this file is distributed with Nagios). ]</font> <br><br>
+
+
+
+
+
+</ol>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Notification Escalations</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Notification Escalations</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="notifications.html">Notifications</a>, <a href="timeperiods.html">Time Periods</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/objects-contacts.png" border="0" style="float: right;" alt="Contacts" title="Contacts">
+
+
+
+<p>
+
+Nagios supports optional escalation of contact notifications for hosts and services. Escalation of host and service notifications is accomplished by defining <a href="objectdefinitions.html#hostescalation">host escalations</a> and <a href="objectdefinitions.html#serviceescalation">service escalations</a> in your <a href="configobject.html">object configuration file(s)</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: The examples I provide below all make use of service escalation definitions, but host escalations work the same way. Except, of course, that they're for hosts instead of services. :-)
+
+</p>
+
+
+
+<p>
+
+<strong><u>When Are Notifications Escalated?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Notifications are escalated <i>if and only if</i> one or more escalation definitions matches the current notification that is being sent out. If a host or service notification <i>does not</i> have any valid escalation definitions that applies to it, the contact group(s) specified in either the host group or service definition will be used for the notification. Look at the example below:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 90
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 6
+
+ last_notification 10
+
+ notification_interval 60
+
+ contact_groups nt-admins,managers,everyone
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Notice that there are "holes" in the notification escalation definitions. In particular, notifications 1 and 2 are not handled by the escalations, nor are any notifications beyond 10. For the first and second notification, as well as all notifications beyond the tenth one, the <i>default</i> contact groups specified in the service definition are used. For all the examples I'll be using, I'll be assuming that the default contact groups for the service definition is called <i>nt-admins</i>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Contact Groups</u></strong>
+
+</p>
+
+
+
+<p>
+
+When defining notification escalations, it is important to keep in mind that any contact groups that were members of "lower" escalations (i.e. those with lower notification number ranges) should also be included in "higher" escalation definitions. This should be done to ensure that anyone who gets notified of a problem <i>continues</i> to get notified as the problem is escalated. Example:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 90
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 6
+
+ last_notification 0
+
+ notification_interval 60
+
+ contact_groups nt-admins,managers,everyone
+
+ }
+
+</pre>
+
+
+
+<p>
+
+The first (or "lowest") escalation level includes both the <i>nt-admins</i> and <i>managers</i> contact groups. The last (or "highest") escalation level includes the <i>nt-admins</i>, <i>managers</i>, and <i>everyone</i> contact groups. Notice that the <i>nt-admins</i> contact group is included in both escalation definitions. This is done so that they continue to get paged if there are still problems after the first two service notifications are sent out. The <i>managers</i> contact group first appears in the "lower" escalation definition - they are first notified when the third problem notification gets sent out. We want the <i>managers</i> group to continue to be notified if the problem continues past five notifications, so they are also included in the "higher" escalation definition.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Overlapping Escalation Ranges</u></strong>
+
+</p>
+
+
+
+<p>
+
+Notification escalation definitions can have notification ranges that overlap. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 20
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 4
+
+ last_notification 0
+
+ notification_interval 30
+
+ contact_groups on-call-support
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In the example above:
+
+</p>
+
+
+
+<ul>
+
+<li>The <i>nt-admins</i> and <i>managers</i> contact groups get notified on the third notification
+
+<li>All three contact groups get notified on the fourth and fifth notifications
+
+<li>Only the <i>on-call-support</i> contact group gets notified on the sixth (or higher) notification
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Recovery Notifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+Recovery notifications are slightly different than problem notifications when it comes to escalations. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 20
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 4
+
+ last_notification 0
+
+ notification_interval 30
+
+ contact_groups on-call-support
+
+ }
+
+</pre>
+
+
+
+<p>
+
+If, after three problem notifications, a recovery notification is sent out for the service, who gets notified? The recovery is actually the fourth notification that gets sent out. However, the escalation code is smart enough to realize that only those people who were notified about the problem on the third notification should be notified about the recovery. In this case, the <i>nt-admins</i> and <i>managers</i> contact groups would be notified of the recovery.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Notification Intervals</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can change the frequency at which escalated notifications are sent out for a particular host or service by using the <i>notification_interval</i> option of the hostgroup or service escalation definition. Example:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 45
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 6
+
+ last_notification 0
+
+ notification_interval 60
+
+ contact_groups nt-admins,managers,everyone
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In this example we see that the default notification interval for the services is 240 minutes (this is the value in the service definition). When the service notification is escalated on the 3rd, 4th, and 5th notifications, an interval of 45 minutes will be used between notifications. On the 6th and subsequent notifications, the notification interval will be 60 minutes, as specified in the second escalation definition.
+
+</p>
+
+
+
+<p>
+
+Since it is possible to have overlapping escalation definitions for a particular hostgroup or service, and the fact that a host can be a member of multiple hostgroups, Nagios has to make a decision on what to do as far as the notification interval is concerned when escalation definitions overlap. In any case where there are multiple valid escalation definitions for a particular notification, Nagios will choose the smallest notification interval. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 45
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 4
+
+ last_notification 0
+
+ notification_interval 60
+
+ contact_groups nt-admins,managers,everyone
+
+ }
+
+</pre>
+
+
+
+<p>
+
+We see that the two escalation definitions overlap on the 4th and 5th notifications. For these notifications, Nagios will use a notification interval of 45 minutes, since it is the smallest interval present in any valid escalation definitions for those notifications.
+
+</p>
+
+
+
+<p>
+
+One last note about notification intervals deals with intervals of 0. An interval of 0 means that Nagios should only sent a notification out for the first valid notification during that escalation definition. All subsequent notifications for the hostgroup or service will be suppressed. Take this example:
+
+</p>
+
+
+
+<pre>
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 3
+
+ last_notification 5
+
+ notification_interval 45
+
+ contact_groups nt-admins,managers
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 4
+
+ last_notification 6
+
+ notification_interval 0
+
+ contact_groups nt-admins,managers,everyone
+
+ }
+
+
+
+define serviceescalation{
+
+ host_name webserver
+
+ service_description HTTP
+
+ first_notification 7
+
+ last_notification 0
+
+ notification_interval 30
+
+ contact_groups nt-admins,managers
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In the example above, the maximum number of problem notifications that could be sent out about the service would be four. This is because the notification interval of 0 in the second escalation definition indicates that only one notification should be sent out (starting with and including the 4th notification) and all subsequent notifications should be repressed. Because of this, the third service escalation definition has no effect whatsoever, as there will never be more than four notifications.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Time Period Restrictions</u></strong>
+
+</p>
+
+
+
+<p>
+
+Under normal circumstances, escalations can be used at any time that a notification could normally be sent out for the host or service. This "notification time window" is determined by the <i>notification_period</i> directive in the <a href="objectdefinitions.html#host">host</a> or <a href="objectdefinitions.html#service">service</a> definition.
+
+</p>
+
+
+
+<p>
+
+You can optionally restrict escalations so that they are only used during specific time periods by using the <i>escalation_period</i> directive in the host or service escalation definition. If you use the <i>escalation_period</i> directive to specify a <a href="timeperiods.html">timeperiod</a> during which the escalation can be used, the escalation will only be used during that time. If you do not specify any <i>escalation_period</i> directive, the escalation can be used at any time within the "notification time window" for the host or service.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Escalated notifications are still subject to the normal time restrictions imposed by the <i>notification_period</i> directive in a host or service definition, so the timeperiod you specify in an escalation definition should be a subset of that larger "notification time window".
+
+</p>
+
+
+
+<p>
+
+<strong><u>State Restrictions</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you would like to restrict the escalation definition so that it is only used when the host or service is in a particular state, you can use the <i>escalation_options</i> directive in the host or service escalation definition. If you do not use the <i>escalation_options</i> directive, the escalation can be used when the host or service is in any state.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Event Handlers</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Event Handlers</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="statetypes.html">State Types</a>, <a href="hostchecks.html">Host Checks</a>, <a href="servicechecks.html">Service Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/eventhandlers.png" border="0" style="float: right;" alt="Event Handlers" title="Event Handlers">
+
+
+
+<p>
+
+Event handlers are optional system commands (scripts or executables) that are run whenever a host or service state change occurs.
+
+</p>
+
+
+
+<p>
+
+An obvious use for event handlers is the ability for Nagios to proactively fix problems before anyone is notified. Some other uses for event handlers include:
+
+</p>
+
+
+
+<ul>
+
+<li>Restarting a failed service</li>
+
+<li>Entering a trouble ticket into a helpdesk system</li>
+
+<li>Logging event information to a database</li>
+
+<li>Cycling power on a host*</li>
+
+<li>etc.</li>
+
+</ul>
+
+
+
+<p>
+
+* Cycling power on a host that is experiencing problems with an auomated script should not be implemented lightly. Consider the consequences of this carefully before implementing automatic reboots. :-)
+
+</p>
+
+
+
+<p>
+
+<strong><u>When Are Event Handlers Executed?</u></strong>
+
+</p>
+
+<p>
+
+Event handlers are executed when a service or host:
+
+</p>
+
+<ul>
+
+<li>Is in a SOFT problem state
+
+<li>Initially goes into a HARD problem state
+
+<li>Initially recovers from a SOFT or HARD problem state
+
+</ul>
+
+<p>
+
+SOFT and HARD states are described in detail <a href="statetypes.html">here</a> .
+
+</p>
+
+
+
+<p>
+
+<strong><u>Event Handler Types</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are different types of optional event handlers that you can define to handle host and state changes:
+
+</p>
+
+
+
+<ul>
+
+<li>Global host event handler</li>
+
+<li>Global service event handler</li>
+
+<li>Host-specific event handlers</li>
+
+<li>Service-specific event handlers</li>
+
+</ul>
+
+
+
+<p>
+
+Global host and service event handlers are run for <i>every</i> host or service state change that occurs, immediately prior to any host- or service-specific event handler that may be run. You can specify global event handler commands by using the <a href="configmain.html#global_host_event_handler">global_host_event_handler</a> and <a href="configmain.html#global_service_event_handler">global_service_event_handler</a> options in your main configuration file.
+
+</p>
+
+
+
+<p>
+
+Individual hosts and services can have their own event handler command that should be run to handle state changes. You can specify an event handler that should be run by using the <i>event_handler</i> directive in your <a href="objectdefinitions.html#host">host</a> and <a href="objectdefinitions.html#service">service</a> definitions. These host- and service-specific event handlers are executed immediately after the (optional) global host or service event handler is executed.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Enabling Event Handlers</u></strong>
+
+</p>
+
+
+
+<p>
+
+Event handlers can be enabled or disabled on a program-wide basis by using the <a href="configmain.html#enable_event_handlers">enable_event_handlers</a> in your main configuration file.
+
+</p>
+
+
+
+<p>
+
+Host- and service-specific event handlers can be enabled or disabled by using the <i>event_handler_enabled</i> directive in your <a href="objectdefinitions.html#host">host</a> and <a href="objectdefinitions.html#service">service</a> definitions. Host- and service-specific event handlers will not be executed if the global <a href="configmain.html#enable_event_handlers">enable_event_handlers</a> option is disabled.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Event Handler Execution Order</u></strong>
+
+</p>
+
+
+
+<p>
+
+As already mentioned, global host and service event handlers are executed immediately before host- or service-specific event handlers.
+
+</p>
+
+
+
+<p>
+
+Event handlers are executed for HARD problem and recovery states immediately after notifications are sent out.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Writing Event Handler Commands</u></strong>
+
+</p>
+
+<p>
+
+Event handler commands will likely be shell or perl scripts, but they can be any type of executable that can run from a command prompt. At a minimum, the scripts should take the following <a href="macros.html">macros</a> as arguments:
+
+</p>
+
+<p>
+
+For Services: <a href="macrolist.html#servicestate"><b>$SERVICESTATE$</b></a>, <a href="macrolist.html#servicestatetype"><b>$SERVICESTATETYPE$</b></a>, <a href="macrolist.html#serviceattempt"><b>$SERVICEATTEMPT$</b></a><br>
+
+For Hosts: <a href="macrolist.html#hoststate"><b>$HOSTSTATE$</b></a>, <a href="macrolist.html#hoststatetype"><b>$HOSTSTATETYPE$</b></a>, <a href="macrolist.html#hostattempt"><b>$HOSTATTEMPT$</b></a>
+
+</p>
+
+<p>
+
+The scripts should examine the values of the arguments passed to it and take any necessary action based upon those values. The best way to understand how event handlers work is to see an example. Lucky for you, one is provided <a href="#example">below</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: Additional sample event handler scripts can be found in the <i>contrib/eventhandlers/</i> subdirectory of the Nagios distribution. Some of these sample scripts demonstrate the use of <a href="extcommands.html">external commands</a> to implement a <a href="redundancy.html">redundant</a> and <a href="distributed.html">distributed</a> monitoring environments.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Permissions For Event Handler Commands</u></strong>
+
+</p>
+
+<p>
+
+Event handler commands will normally execute with the same permissions as the user under which
+
+Nagios is running on your machine. This can present a problem if you want to write an event handler that restarts system
+
+services, as root privileges are generally required to do these sorts of tasks.
+
+</p>
+
+<p>
+
+Ideally you should evaluate the types of event handlers you will be implementing and grant just enough permissions
+
+to the Nagios user for executing the necessary system commands. You might want to try using <a href="http://www.courtesan.com/sudo/sudo.html">sudo</a> to accomplish this.
+
+</p>
+
+
+
+<a name="example"></a>
+
+<p>
+
+<strong><u>Service Event Handler Example</u></strong>
+
+</p>
+
+<p>
+
+The example below assumes that you are monitoring the HTTP server on the local machine and have specified <i>restart-httpd</i> as the event handler command for the HTTP service definition. Also, I will be assuming that you have set the <i>max_check_attempts</i> option for the service to be a value of 4 or greater (i.e. the service is checked 4 times before it is considered to have a real problem). An abbreviated example service definition might look like this...
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ host_name somehost
+
+ service_description HTTP
+
+ max_check_attempts 4
+
+ event_handler restart-httpd
+
+ ...
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+Once the service has been defined with an event handler, we must define that event handler as a command. An example command definition for <i>restart-httpd</i> is shown below. Notice the macros in the command line that I am passing to the event handler script - these are important!
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name restart-httpd
+
+ command_line /usr/local/nagios/libexec/eventhandlers/restart-httpd $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now, let's actually write the event handler script (this is the <i>/usr/local/nagios/libexec/eventhandlers/restart-httpd</i> script).
+
+</p>
+
+
+
+<br><br>
+
+
+
+<pre>
+
+#!/bin/sh
+
+#
+
+# Event handler script for restarting the web server on the local machine
+
+#
+
+# Note: This script will only restart the web server if the service is
+
+# retried 3 times (in a "soft" state) or if the web service somehow
+
+# manages to fall into a "hard" error state.
+
+#
+
+
+
+
+
+# What state is the HTTP service in?
+
+case "$1" in
+
+OK)
+
+ # The service just came back up, so don't do anything...
+
+ ;;
+
+WARNING)
+
+ # We don't really care about warning states, since the service is probably still running...
+
+ ;;
+
+UNKNOWN)
+
+ # We don't know what might be causing an unknown error, so don't do anything...
+
+ ;;
+
+CRITICAL)
+
+ # Aha! The HTTP service appears to have a problem - perhaps we should restart the server...
+
+
+
+ # Is this a "soft" or a "hard" state?
+
+ case "$2" in
+
+
+
+ # We're in a "soft" state, meaning that Nagios is in the middle of retrying the
+
+ # check before it turns into a "hard" state and contacts get notified...
+
+ SOFT)
+
+
+
+ # What check attempt are we on? We don't want to restart the web server on the first
+
+ # check, because it may just be a fluke!
+
+ case "$3" in
+
+
+
+ # Wait until the check has been tried 3 times before restarting the web server.
+
+ # If the check fails on the 4th time (after we restart the web server), the state
+
+ # type will turn to "hard" and contacts will be notified of the problem.
+
+ # Hopefully this will restart the web server successfully, so the 4th check will
+
+ # result in a "soft" recovery. If that happens no one gets notified because we
+
+ # fixed the problem!
+
+ 3)
+
+ echo -n "Restarting HTTP service (3rd soft critical state)..."
+
+ # Call the init script to restart the HTTPD server
+
+ /etc/rc.d/init.d/httpd restart
+
+ ;;
+
+ esac
+
+ ;;
+
+
+
+ # The HTTP service somehow managed to turn into a hard error without getting fixed.
+
+ # It should have been restarted by the code above, but for some reason it didn't.
+
+ # Let's give it one last try, shall we?
+
+ # Note: Contacts have already been notified of a problem with the service at this
+
+ # point (unless you disabled notifications for this service)
+
+ HARD)
+
+ echo -n "Restarting HTTP service..."
+
+ # Call the init script to restart the HTTPD server
+
+ /etc/rc.d/init.d/httpd restart
+
+ ;;
+
+ esac
+
+ ;;
+
+esac
+
+exit 0
+
+</pre>
+
+
+
+<br><br>
+
+
+
+<p>
+
+The sample script provided above will attempt to restart the web server on the local machine in two different instances:
+
+</p>
+
+
+
+<ul>
+
+<li>After the service has been rechecked for the 3rd time and is in a SOFT CRITICAL state</li>
+
+<li>After the service first goes into a HARD CRITICAL state</li>
+
+</ul>
+
+
+
+<p>
+
+The script should theoretically restart and web server and fix the problem before the service goes into a HARD problem state, but we include a fallback case in the event it doesn't work the first time. It should be noted that the event handler will only be executed the first time that the service falls into a HARD problem state. This prevents Nagios from continuously executing the script to restart the web server if the service remains in a HARD problem state. You don't want that. :-)
+
+</p>
+
+
+
+<p>
+
+That's all there is to it! Event handlers are pretty simple to write and implement, so give it a try and see what you can do.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>External Commands</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">External Commands</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="passivechecks.html">Passive Checks</a>, <a href="adaptive.html">Adaptive Monitoring</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios can process commands from external applications (including the CGIs) and alter various aspects of its monitoring functions based on the commands it receives. External applications can submit commands by writing to the <a href="configmain.html#command_file">command file</a>, which is periodically processed by the Nagios daemon.
+
+</p>
+
+
+
+<img src="images/externalcommands.png" border="0" style="float: right;" alt="External Commands" title="External Commands">
+
+
+
+<p>
+
+<strong><u>Enabling External Commands</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order to have Nagios process external commands, make sure you do the following:
+
+</p>
+
+
+
+<ul>
+
+<li>Enable external command checking with the <a href="configmain.html#check_external_commands">check_external_commands</a> option.
+
+<li>Set the frequency of command checks with the <a href="configmain.html#command_check_interval">command_check_interval</a> option.
+
+<li>Specify the location of the command file with the <a href="configmain.html#command_file">command_file</a> option.
+
+<li>Setup proper permissions on the directory containing the external command file, as described in the <a href="quickstart.html">quickstart guide</a>.
+
+</ul>
+
+
+
+<p>
+
+<strong><u>When Does Nagios Check For External Commands?</u></strong>
+
+</p>
+
+
+
+<ul>
+
+<li>At regular intervals specified by the <a href="configmain.html#command_check_interval">command_check_interval</a> option in the main configuration file
+
+<li>Immediately after <a href="eventhandlers.html">event handlers</a> are executed. This is in addtion to the regular cycle of external command checks and is done to provide immediate action if an event handler submits commands to Nagios.
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Using External Commands</u></strong>
+
+</p>
+
+
+
+<p>
+
+External commands can be used to accomplish a variety of things while Nagios is running. Example of what can be done include temporarily disabling notifications for services and hosts, temporarily disabling service checks, forcing immediate service checks, adding comments to hosts and services, etc.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Command Format</u></strong>
+
+</p>
+
+
+
+<p>
+
+External commands that are written to the <a href="configmain.html#command_file">command file</a> have the following format...
+
+</p>
+
+
+
+<pre>
+
+[<i>time</i>] <i>command_id</i>;<i>command_arguments</i>
+
+</pre>
+
+
+
+<p>
+
+...where <i>time</i> is the time (in <i>time_t</i> format) that the external application submitted the external command to the command file. The values for the <i>command_id</i> and <i>command_arguments</i> arguments will depend on what command is being submitted to Nagios.
+
+</p>
+
+
+
+<p>
+
+A full listing of external commands that can be used (along with examples of how to use them) can be found online at the following URL:
+
+</p>
+
+<p>
+
+<a href="http://www.nagios.org/developerinfo/externalcommands/" target="_blank">http://www.nagios.org/developerinfo/externalcommands/</a>
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Fast Startup Options</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Fast Startup Options</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="tuning.html">Performance Tuning</a>, <a href="largeinstalltweaks.html">Large Installation Tweaks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are a few things you can do that can decrease the amount of time it take Nagios to startup (or restart). These speedups involve easing some of the burden involved in processing your configuration files.
+
+</p>
+
+
+
+<p>
+
+Using these techniques is particularly useful when you have one or more of the following:
+
+</p>
+
+
+
+<ul>
+
+<li>Large configurations</li>
+
+<li>Complex configurations (heavy use of template features)</li>
+
+<li>Installations where frequest restarts are necessary</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Background</u></strong>
+
+</p>
+
+
+
+<p>
+
+Whenever Nagios starts/restarts it has to process your configuration files before it can get down to the business of monitoring. This configuration startup process involves a number of steps:
+
+</p>
+
+
+
+<ul>
+
+<li>Reading the config files</li>
+
+<li>Resolving template definitions</li>
+
+<li>"Recombobulating" your objects (my term for the various types of work that occurs)</li>
+
+<li>Duplicating object definitions</li>
+
+<li>Inheriting object properties</li>
+
+<li>Sorting your object definitions</li>
+
+<li>Verifying object relationship integrity</li>
+
+<li>Checking for circular paths</li>
+
+<li>and more...</li>
+
+</ul>
+
+
+
+<p>
+
+Some of these steps can be quite time-consuming when you have large or complex configurations. Is there a way to speed any of these steps up? Yes!
+
+</p>
+
+
+
+<p>
+
+<strong><u>Evaluating Startup Times</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before we get on to making things faster, we need to see what's possible and whether or not we should even bother with the whole thing. This is easy to do - simply start nagios with the <b>-s</b> command line switch to get timing and scheduling information.
+
+</p>
+
+
+
+<p>
+
+An example of the output (abbreviated to only show relevant portions) is shown below. For this example, I'm using a Nagios config that has 25 hosts defined and just over 10,000 services.
+
+</p>
+
+
+
+<pre style="padding: 0 0 0 50px;">
+
+/usr/local/nagios/bin/nagios -s /usr/local/nagios/etc/nagios.cfg
+
+
+
+Nagios 3.0-prealpha
+
+Copyright (c) 1999-2007 Ethan Galstad (http://www.nagios.org)
+
+Last Modified: 01-27-2007
+
+License: GPL
+
+
+
+Timing information on object configuration processing is listed
+
+below. You can use this information to see if precaching your
+
+object configuration would be useful.
+
+
+
+Object Config Source: Config files (uncached)
+
+
+
+OBJECT CONFIG PROCESSING TIMES (* = Potential for precache savings with -u option)
+
+----------------------------------
+
+Read: 0.486780 sec
+
+Resolve: 0.004106 sec *
+
+Recomb Contactgroups: 0.000077 sec *
+
+Recomb Hostgroups: 0.000172 sec *
+
+Dup Services: 0.028801 sec *
+
+Recomb Servicegroups: 0.010358 sec *
+
+Duplicate: 5.666932 sec *
+
+Inherit: 0.003770 sec *
+
+Recomb Contacts: 0.030085 sec *
+
+Sort: 2.648863 sec *
+
+Register: 2.654628 sec
+
+Free: 0.021347 sec
+
+ ============
+
+TOTAL: 11.555925 sec * = 8.393170 sec (72.63%) estimated savings
+
+
+
+
+
+Timing information on configuration verification is listed below.
+
+
+
+CONFIG VERIFICATION TIMES (* = Potential for speedup with -x option)
+
+----------------------------------
+
+Object Relationships: 1.400807 sec
+
+Circular Paths: 54.676622 sec *
+
+Misc: 0.006924 sec
+
+ ============
+
+TOTAL: 56.084353 sec * = 54.676622 sec (97.5%) estimated savings
+
+</pre>
+
+
+
+<p>
+
+Okay, lets see what happened. Looking at the totals, it took roughly <b>11.6</b> seconds to process the configuration files and another <b>56</b> seconds to verify the config. That means that every time I start or restart Nagios with this configuration, it will take nearly <b>68 seconds</b> of startup work before it can monitor anything! That's not acceptable if I have to restart Nagios on a semi-regular basis.
+
+</p>
+
+
+
+<p>
+
+What can I do about this? Take another look at the output and you'll see that Nagios estimates that I could save about <b>8.4</b> seconds off the configuration processing time and another <b>54.7</b> off the verification times. In total, Nagios thinks I could save <b>63 seconds</b> of the normal startup time if some optimizations were taken.
+
+</p>
+
+
+
+<p>
+
+Whoa! From <b>68 seconds</b> to just <b>5 seconds</b>? Yep, read on for how to do it.
+
+</p>
+
+
+
+
+
+
+
+<p>
+
+<strong><u>Pre-Caching Object Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios can spend quite a bit of time parsing your config files, especially if you make use of the template features such as inheritance, etc. In order to reduce the time it takes to parse your config, you can have Nagios pre-process and pre-cache your config files for future use.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+When you run nagios with the <b>-p</b> command line option, Nagios will read your config files in, process them, and save them to a pre-cached object config file (specified by the <a href="configmain.html#precached_object_file">precached_object_file</a> directive). This pre-cached config file will contain pre-processed configuration entries that are easier/faster for Nagios to process in the future.
+
+</p>
+
+
+
+<p>
+
+You must use the <b>-p</b> command line option along with either the <b>-v</b> or <b>-s</b> command line options, as shown below. This ensures that your configuration is verified before the precached file is created.
+
+</p>
+
+
+
+<pre style="padding: 0 0 0 50px;">
+
+/usr/local/nagios/bin/nagios -pv /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+The size of your precached config file will most likely be significantly larger than the sum of the sizes of your object config files. This is normal and by design.
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<div style="float: right; clear: right; padding: 0 0 25px 25px;">
+
+<img src="images/fast-startup1.png" alt="Pre-Caching Object Config Files" title="Pre-Caching Object Config Files" border="0">
+
+</div>
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+Once the precached object configuration file have been created, you can start Nagios and tell it to use the precached config file instead of your object config file(s) by using the <b>-u</b> command line option.
+
+</p>
+
+
+
+<pre style="padding: 0 0 0 50px;">
+
+/usr/local/nagios/bin/nagios -ud /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p><img src="images/important.gif" border="0" align="bottom" alt="Important" title="Important"> If you modify your configuration files, you will need to re-verify and re-cache your configuration files before restarting Nagios. If you don't re-generate the precached object file, Nagios will continue to use your old configuration because it is now reading from the precached file, rather than your source configuration files.
+
+</p>
+
+
+
+</td>
+
+<td valign="top">
+
+<div style="float: right; padding: 0 0 0 25px;">
+
+<img src="images/fast-startup2.png" alt="Pre-Caching Object Config Files" title="Pre-Caching Object Config Files" border="0">
+
+</div>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+<strong><u>Skipping Circular Path Tests</u></strong>
+
+</p>
+
+
+
+<p>
+
+The second (and most time-intensive) portion of the configuration startup phase is the circular path check. In the example above, it took nearly a minute to perform this step of the configuration verification.
+
+</p>
+
+
+
+<p>
+
+What is the circular path check and why does it take so long? The circular patch check is designed to ensure that you don't define any circular paths in your host, host dependency, or service dependency definitions. If a circular path existed in your config files, Nagios could end up in a deadlock situation. The most likely reason for the check taking so long is that I'm not using an efficient algorithm. A much more efficient algorithm for detecting circular paths would be most welcomed. Hint: That means all you CompSci graduate students who have been emailing me about doing your thesis on Nagios can contribute some code back. :-)
+
+</p>
+
+
+
+<p>
+
+If you want to skip the circular path check when Nagios starts, you can add the -x command line option like this:
+
+</p>
+
+
+
+<pre style="padding: 0 0 0 50px;">
+
+/usr/local/nagios/bin/nagios -xd /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p><img src="images/important.gif" border="0" align="bottom" alt="Important" title="Important"> It is of utmost importance that you verify your configuration before starting/restarting Nagios when skipping circular path checks. Failure to do so could lead to deadlocks in the Nagios logic. You have been warned.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Putting It All Together</u></strong>
+
+</p>
+
+
+
+<p>
+
+Follow these steps if you want to make use of potential speedups from pre-caching your configuration and skipping circular path checks.
+
+</p>
+
+
+
+<p>
+
+1. Verify your configuration and create the precache file with the following command:
+
+</p>
+
+
+
+<pre style="padding: 0 0 0 50px;">
+
+/usr/local/nagios/bin/nagios -vp /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+2. Stop Nagios if it is currently running.
+
+</p>
+
+
+
+<p>
+
+3. Start Nagios like so to use the precached config file and skip circular path checks:
+
+</p>
+
+
+
+<pre style="padding: 0 0 0 50px;">
+
+/usr/local/nagios/bin/nagios -uxd /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+
+
+<p>
+
+4. When you modify your original configuration files in the future and need to restart Nagios to make those changes take place, repeat step 1 to re-verify your config and regenerate your cached config file. Once that is done you can restart Nagios through the web interface or by sending a SIGHUP signal. If you don't re-generate the precached object file, Nagios will continue to use your old confguration because it is now reading from the precached file, rather than your source configuration files.
+
+</p>
+
+
+
+<p>
+
+5. That's it! Enjoy the increased startup speed.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Detection and Handling of State Flapping</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Detection and Handling of State Flapping</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="statetypes.html">State Types</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios supports optional detection of hosts and services that are "flapping". Flapping occurs when a service or host changes state too frequently, resulting in a storm of problem and recovery notifications. Flapping can be indicative of configuration problems (i.e. thresholds set too low), troublesome services, or real network problems.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>How Flap Detection Works</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before I get into this, let me say that flapping detection has been a little difficult to implement. How exactly does one determine what "too frequently" means in regards to state changes for a particular host or service? When I first started thinking about implementing flap detection I tried to find some information on how flapping could/should be detected. I couldn't find any information about what others were using (where they using any?), so I decided to settle with what seemed to me to be a reasonable solution...
+
+</p>
+
+
+
+<p>
+
+Whenever Nagios checks the status of a host or service, it will check to see if it has started or stopped flapping. It does this by:
+
+</p>
+
+
+
+<ul>
+
+<li>Storing the results of the last 21 checks of the host or service
+
+<li>Analyzing the historical check results and determine where state changes/transitions occur
+
+<li>Using the state transitions to determine a percent state change value (a measure of change) for the host or service
+
+<li>Comparing the percent state change value against low and high flapping thresholds
+
+</ul>
+
+
+
+<p>
+
+A host or service is determined to have <i>started</i> flapping when its percent state change first exceeds a <i>high</i> flapping threshold.
+
+</p>
+
+
+
+<p>
+
+A host or service is determined to have <i>stopped</i> flapping when its percent state goes below a <i>low</i> flapping threshold (assuming that is was previously flapping).
+
+</p>
+
+
+
+<p>
+
+<strong><u>Example</u></strong>
+
+</p>
+
+
+
+<p>
+
+Let's describe in more detail how flap detection works with services...
+
+</p>
+
+
+
+<p>
+
+The image below shows a chronological history of service states from the most recent 21 service checks. OK states are shown in green, WARNING states in yellow, CRITICAL states in red, and UNKNOWN states in orange.
+
+</p>
+
+
+
+<p>
+
+<a href="images/statetransitions.png"><img src="images/statetransitions.png" border=0 alt="Service State Transitions"></a>
+
+</p>
+
+
+
+<p>
+
+The historical service check results are examined to determine where state changes/transitions occur. State changes occur when an archived state is different from the archived state that immediately precedes it chronologically. Since we keep the results of the last 21 service checks in the array, there is a possibility of having at most 20 state changes. In this example there are 7 state changes, indicated by blue arrows in the image above.
+
+</p>
+
+
+
+<p>
+
+The flap detection logic uses the state changes to determine an overall percent state change for the service. This is a measure of volatility/change for the service. Services that never change state will have a 0% state change value, while services that change state each time they're checked will have 100% state change. Most services will have a percent state change somewhere in between.
+
+</p>
+
+
+
+<p>
+
+When calculating the percent state change for the service, the flap detection algorithm will give more weight to new state changes compare to older ones. Specfically, the flap detection routines are currently designed to make the newest possible state change carry 50% more weight than the oldest possible state change. The image below shows how recent state changes are given more weight than older state changes when calculating the overall or total percent state change for a particular service.
+
+</p>
+
+
+
+<p>
+
+<a href="images/statetransitions2.png"><img src="images/statetransitions2.png" border=0 alt="Weighted Service State Transitions"></a>
+
+</p>
+
+
+
+<p>
+
+Using the images above, lets do a calculation of percent state change for the service. You will notice that there are a total of 7 state changes (at t<sub>3</sub>, t<sub>4</sub>, t<sub>5</sub>, t<sub>9</sub>, t<sub>12</sub>, t<sub>16</sub>, and t<sub>19</sub>). Without any weighting of the state changes over time, this would give us a total state change of 35%:
+
+</p>
+
+<p>
+
+(7 observed state changes / possible 20 state changes) * 100 = 35 %
+
+</p>
+
+<p>
+
+Since the flap detection logic will give newer state changes a higher rate than older state changes, the actual calculated percent state change will be slightly less than 35% in this example. Let's say that the weighted percent of state change turned out to be 31%...
+
+</p>
+
+
+
+<p>
+
+The calculated percent state change for the service (31%) will then be compared against flapping thresholds to see what should happen:
+
+</p>
+
+
+
+<ul>
+
+<li>If the service was <i>not</i> previously flapping and 31% is <i>equal to or greater than</i> the high flap threshold, Nagios considers the service to have just started flapping.
+
+<li>If the service <i>was</i> previously flapping and 31% is <i>less than</i> the low flap threshold, Nagios considers the service to have just stopped flapping.
+
+</ul>
+
+<p>
+
+If neither of those two conditions are met, the flap detection logic won't do anything else with the service, since it is either not currently flapping or it is still flapping.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Flap Detection for Services</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios checks to see if a service is flapping whenever the service is checked (either actively or passively).
+
+</p>
+
+<p>
+
+The flap detection logic for services works as described in the example above.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Flap Detection for Hosts</u></strong>
+
+</p>
+
+
+
+<p>
+
+Host flap detection works in a similiar manner to service flap detection, with one important difference: Nagios will attempt to check to see if a host is flapping whenever:
+
+</p>
+
+
+
+<ul>
+
+<li>The host is checked (actively or passively)
+
+<li>Sometimes when a service associated with that host is checked. More specifically, when at least <i>x</i> amount of time has passed since the flap detection was last performed, where <i>x</i> is equal to the average check interval of all services associated with the host.
+
+</ul>
+
+
+
+<p>
+
+Why is this done? With services we know that the minimum amount of time between consecutive flap detection routines is going to be equal to the service check interval. However, you might not be monitoring hosts on a regular basis, so there might not be a host check interval that can be used in the flap detection logic. Also, it makes sense that checking a service should count towards the detection of host flapping. Services are attributes of or things associated with host after all... At any rate, that's the best method I could come up with for determining how often flap detection could be performed on a host, so there you have it.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Flap Detection Thresholds</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios uses several variables to determine the percent state change thresholds is uses for flap detection. For both hosts and services, there are <i>global</i> high and low thresholds and <i>host-</i> or <i>service-specific</i> thresholds that you can configure. Nagios will use the global thresholds for flap detection if you to not specify host- or service- specific thresholds.
+
+</p>
+
+
+
+<p>
+
+The table below shows the global and host- or service-specific variables that control the various thresholds used in flap detection.
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Object Type</th><th>Global Variables</th><th>Object-Specific Variables</th></tr>
+
+<tr>
+
+<td>Host</td>
+
+<td>
+
+<a href="configmain.html#low_host_flap_threshold">low_host_flap_threshold</a><br>
+
+<a href="configmain.html#high_host_flap_threshold">high_host_flap_threshold</a>
+
+</td>
+
+<td>
+
+<a href="objectdefinitions.html#host">low_flap_threshold</a><br>
+
+<a href="objectdefinitions.html#host">high_flap_threshold</a><br>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td>Service</td>
+
+<td>
+
+<a href="configmain.html#low_service_flap_threshold">low_service_flap_threshold</a><br>
+
+<a href="configmain.html#high_service_flap_threshold">high_service_flap_threshold</a>
+
+</td>
+
+<td>
+
+<a href="objectdefinitions.html#service">low_flap_threshold</a><br>
+
+<a href="objectdefinitions.html#service">high_flap_threshold</a><br>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+<strong><u>States Used For Flap Detection</u></strong>
+
+</p>
+
+
+
+<p>
+
+Normally Nagios will track the results of the last 21 checks of a host or service, regardless of the check result (host/service state), for use in the flap detection logic.
+
+</p>
+
+
+
+<p><img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: You can exclude certain host or service states from use in flap detection logic by using the <i>flap_detection_options</i> directive in your host or service definitions. This directive allows you to specify what host or service states (i.e. "UP, "DOWN", "OK, "CRITICAL") you want to use for flap detection. If you don't use this directive, all host or service states are used in flap detection.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Flap Handling</u></strong>
+
+</p>
+
+
+
+<p>
+
+When a service or host is first detected as flapping, Nagios will:
+
+</p>
+
+
+
+<ol>
+
+<li>Log a message indicating that the service or host is flapping.
+
+<li>Add a non-persistent comment to the host or service indicating that it is flapping.
+
+<li>Send a "flapping start" notification for the host or service to appropriate contacts.
+
+<li>Suppress other notifications for the service or host (this is one of the filters in the <a href="notifications.html">notification logic</a>).
+
+</ol>
+
+
+
+
+
+<p>
+
+When a service or host stops flapping, Nagios will:
+
+</p>
+
+
+
+<ol>
+
+<li>Log a message indicating that the service or host has stopped flapping.
+
+<li>Delete the comment that was originally added to the service or host when it started flapping.
+
+<li>Send a "flapping stop" notification for the host or service to appropriate contacts.
+
+<li>Remove the block on notifications for the service or host (notifications will still be bound to the normal <a href="notifications.html">notification logic</a>).
+
+</ol>
+
+
+
+
+
+<p>
+
+<strong><u>Enabling Flap Detection</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order to enable the flap detection features in Nagios, you'll need to:
+
+</p>
+
+
+
+<ul>
+
+<li>Set <a href="configmain.html#enable_flap_detection">enable_flap_detection</a> directive is set to 1.</li>
+
+<li>Set the <i>flap_detection_enabled</i> directive in your host and service definitions is set to 1.</li>
+
+</ul>
+
+
+
+<p>
+
+If you want to disable flap detection on a global basis, set the <a href="configmain.html#enable_flap_detection">enable_flap_detection</a> directive to 0.
+
+</p>
+
+
+
+<p>
+
+If you would like to disable flap detection for just a few hosts or services, use the <i>flap_detection_enabled</i> directive in the host and/or service definitions to do so.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Service and Host Freshness Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Service and Host Freshness Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="passivechecks.html">Passive Checks</a>, <a href="distributed.html">Distributed Monitoring</a>, <a href="redundancy.html">Redundant and Failover Monitoring</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios supports a feature that does "freshness" checking on the results of host and service checks. The purpose of freshness checking is to ensure that host and service checks are being provided passively by external applications on a regular basis.
+
+</p>
+
+
+
+<p>
+
+Freshness checking is useful when you want to ensure that <a href="passivechecks.html">passive checks</a> are being received as frequently as you want. This can be very useful in <a href="distributed.html">distributed</a> and <a href="redundancy.html">failover</a> monitoring environments.
+
+</p>
+
+
+
+<img src="images/freshness.png" border="0" style="float: right;" alt="Minty Fresh" title="Minty Fresh">
+
+
+
+<p>
+
+<strong><u>How Does Freshness Checking Work?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios periodically checks the freshness of the results for all hosts services that have freshness checking enabled.
+
+</p>
+
+
+
+<ul>
+
+<li>A freshness threshold is calculated for each host or service.
+
+<li>For each host/service, the age of its last check result is compared with the freshness threshold.
+
+<li>If the age of the last check result is greater than the freshness threshold, the check result is considered "stale".
+
+<li>If the check results is found to be stale, Nagios will force an <a href="activechecks.html">active check</a> of the host or service by executing the command specified by in the host or service definition.
+
+</ul>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: An active check is executed even if active checks are disabled on a program-wide or host- or service-specific basis.
+
+</p>
+
+
+
+<p>
+
+For example, if you have a freshness threshold of 60 for one of your services, Nagios will consider that service to be stale if its last check result is older than 60 seconds.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Enabling Freshness Checking</u></strong>
+
+</p>
+
+
+
+<p>
+
+Here's what you need to do to enable freshness checking...
+
+</p>
+
+
+
+<ul>
+
+<li>Enable freshness checking on a program-wide basis with the <a href="configmain.html#check_service_freshness">check_service_freshness</a> and <a href="configmain.html#check_host_freshness">check_host_freshness</a> directives.</li>
+
+<li>Use <a href="configmain.html#service_freshness_check_interval">service_freshness_check_interval</a> and <a href="configmain.html#host_freshness_check_interval">host_freshness_check_interval</a> options to tell Nagios how often in should check the freshness of service and host results.</li>
+
+<li>Enable freshness checking on a host- and service-specific basis by setting the <i>check_freshness</i> option in your host and service definitions to a value of 1.</li>
+
+<li>Configure freshness thresholds by setting the <i>freshness_threshold</i> option in your host and service definitions.</li>
+
+<li>Configure the <i>check_command</i> option in your host or service definitions to reflect a valid command that should be used to actively check the host or service when it is detected as stale.</li>
+
+<li>The <i>check_period</i> option in your host and service definitions is used when Nagios determines when a host or service can be checked for freshness, so make sure it is set to a valid timeperiod.</li>
+
+</ul>
+
+
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: If you do not specify a host- or service-specific <i>freshness_threshold</i> value (or you set it to zero), Nagios will automatically calculate a threshold automatically, based on a how often you monitor that particular host or service. I would recommended that you explicitly specify a freshness threshold, rather than let Nagios pick one for you.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Example</u></strong>
+
+</p>
+
+
+
+<p>
+
+An example of a service that might require freshness checking might be one that reports the status of your nightly backup jobs. Perhaps you have a external script that submit the results of the backup job to Nagios once the backup is completed. In this case, all of the checks/results for the service are provided by an external application using passive checks. In order to ensure that the status of the backup job gets reported every day, you may want to enable freshness checking for the service. If the external script doesn't submit the results of the backup job, you can have Nagios fake a critical result by doing something like this...
+
+</p>
+
+
+
+<p>
+
+Here's what the definition for the service might look like (some required options are omitted)...
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ host_name backup-server
+
+ service_description ArcServe Backup Job
+
+ active_checks_enabled 0 ; active checks are NOT enabled
+
+ passive_checks_enabled 1 ; passive checks are enabled (this is how results are reported)
+
+ check_freshness 1
+
+ freshness_threshold 93600 ; 26 hour threshold, since backups may not always finish at the same time
+
+ check_command no-backup-report ; this command is run only if the service results are "stale"
+
+ ...other options...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Notice that active checks are disabled for the service. This is because the results for the service are only made by an external application using passive checks. Freshness checking is enabled and the freshness threshold has been set to 26 hours. This is a bit longer than 24 hours because backup jobs sometimes run late from day to day (depending on how much data there is to backup, how much network traffic is present, etc.). The <i>no-backup-report</i> command is executed only if the results of the service are determined to be stale. The definition of the <i>no-backup-report</i> command might look like this...
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name no-backup-report
+
+ command_line /usr/local/nagios/libexec/check_dummy 2 "CRITICAL: Results of backup job were not reported!"
+
+ }
+
+</pre>
+
+
+
+<p>
+
+If Nagios detects that the service results are stale, it will run the <i>no-backup-report</i> command as an active service check. This causes the <i>check_dummy</i> plugin to be executed, which returns a critical state to Nagios. The service will then go into to a critical state (if it isn't already there) and someone will probably get notified of the problem.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Neat Hacks and Tricks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<h1 class="PageTitle">Neat Hacks and Tricks</h1>
+
+</div>
+
+<hr>
+
+
+
+<p>
+
+Other than the standard monitoring stuff, Nagios can be used to do some pretty cool things. Instead of spending your free time playing <a href="http://www.idsoftware.com/quake/">Quake</a>, why don't you take some time and read about them at <a href="http://www.nagios.org/docs/hacks/">http://www.nagios.org/docs/hacks</a>...
+
+</p>
+
+
+
+<hr>
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Host Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Host Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="networkreachability.html">Network Reachability</a>, <a href="activechecks.html">Active Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="checkscheduling.html">Check Scheduling</a>, <a href="dependencychecks.html">Predictive Dependency Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+The basic workings of host checks are described here...
+
+</p>
+
+
+
+<p>
+
+<strong><u>When Are Host Checks Performed?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Hosts are checked by the Nagios daemon:
+
+</p>
+
+
+
+<ul>
+
+<li>At regular intervals, as defined by the <i>check_interval</i> and <i>retry_interval</i> options in your <a href="objectdefinitions.html#host">host definitions</a>.</li>
+
+<li>On-demand when a service associated with the host changes state.</li>
+
+<li>On-demand as needed as part of the <a href="networkreachability.html">host reachability</a> logic.</li>
+
+<li>On-demand as needed for <a href="dependencychecks.html">predictive host dependency checks</a>.</li>
+
+</ul>
+
+
+
+<p>
+
+Regularly scheduled host checks are optional. If you set the <i>check_interval</i> option in your host definition to zero (0), Nagios will not perform checks of the hosts on a regular basis. It will, however, still perform on-demand checks of the host as needed for other parts of the monitoring logic.
+
+</p>
+
+
+
+<p>
+
+On-demand checks are made when a service associated with the host changes state because Nagios needs to know whether the host has also changed state. Services that change state are often an indicator that the host may have also changed state. For example, if Nagios detects that the HTTP service associated with a host just changed from a CRITICAL to an OK state, it may indicate that the host just recovered from a reboot and is now back up and running.
+
+</p>
+
+
+
+<p>
+
+On-demand checks of hosts are also made as part of the <a href="networkreachability.html">host reachability</a> logic. Nagios is designed to detect network outages as quickly as possible, and distinguish between DOWN and UNREACHABLE host states. These are very different states and can help an admin quickly locate the cause of a network outage.
+
+</p>
+
+
+
+<p>
+
+On-demand checks are also performed as part of the <a href="dependencychecks.html">predictive host dependency check</a> logic. These checks help ensure that the dependency logic is as accurate as possible.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Cached Host Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+The performance of on-demand host checks can be significantly improved by implementing the use of cached checks, which allow Nagios to forgo executing a host check if it determines a relatively recent check result will do instead. More information on cached checks can be found <a href="cachedchecks.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Dependencies and Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can define <a href="objectdefinitions.html#hostdependency">host execution dependencies</a> that prevent Nagios from checking the status of a host depending on the state of one or more other hosts. More information on dependencies can be found <a href="dependencies.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Parallelization of Host Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+Scheduled host checks are run in parallel. When Nagios needs to run a scheduled host check, it will initiate the host check and then return to doing other work (running service checks, etc). The host check runs in a child process that was fork()ed from the main Nagios daemon. When the host check has completed, the child process will inform the main Nagios process (its parent) of the check results. The main Nagios process then handles the check results and takes appropriate action (running event handlers, sending notifications, etc.).
+
+</p>
+
+
+
+<p>
+
+On-demand host checks are also run in parallel if needed. As mentioned earlier, Nagios can forgo the actual execution of an on-demand host check if it can use the cached results from a relatively recent host check.
+
+</p>
+
+
+
+<p>
+
+When Nagios processes the results of scheduled and on-demand host checks, it may initiate (secondary) checks of other hosts. These checks can be initated for two reasons: <a href="dependencychecks.html">predictive dependency checks</a> and to determining the status of the host using the <a href="networkreachability.html">network reachability</a> logic. The secondary checks that are initiated are usually run in parallel. However, there is one big exception that you should be aware of, as it can have negative effect on performance...
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Hosts which have their <i>max_check_attempts</i> value set to <b>1</b> can cause serious performance problems. The reason? If Nagios needs to determine their true state using the <a href="networkreachability.html">network reachability</a> logic (to see if they're DOWN or UNREACHABLE), it will have to launch <b>serial</b> checks of all of the host's immediate parents. Just to reiterate, those checks are run <i>serially</i>, rather than in parallel, so it can cause a big performance hit. For this reason, I would recommend that you always use a value greater than 1 for the <i>max_check_attempts</i> directives in your host definitions.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Host States</u></strong>
+
+</p>
+
+
+
+<p>
+
+Hosts that are checked can be in one of three different states:
+
+</p>
+
+
+
+<ul>
+
+<li>UP</li>
+
+<li>DOWN</li>
+
+<li>UNREACHABLE</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Host State Determination</u></strong>
+
+</p>
+
+
+
+<p>
+
+Host checks are performed by <a href="plugins.html">plugins</a>, which can return a state of OK, WARNING, UNKNOWN, or CRITICAL. How does Nagios translate these plugin return codes into host states of UP, DOWN, or UNREACHABLE? Lets see...
+
+</p>
+
+
+
+<p>
+
+The table below shows how plugin return codes correspond with preliminary host states. Some post-processing (which is described later) is done which may then alter the final host state.
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Plugin Result</th><th>Preliminary Host State</th></tr>
+
+<tr><td>OK</td><td>UP</td></tr>
+
+<tr><td>WARNING</td><td>UP or DOWN<sup>*</sup></td></tr>
+
+<tr><td>UNKNOWN</td><td>DOWN</td></tr>
+
+<tr><td>CRITICAL</td><td>DOWN</td></tr>
+
+</table>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: WARNING results usually means the host is UP. However, WARNING results are interpreted to mean the host is DOWN if the <a href="configmain.html#use_aggressive_host_checking">use_aggressive_host_checking</a> option is enabled.
+
+</p>
+
+
+
+<p>
+
+If the preliminary host state is DOWN, Nagios will attempt to see if the host is really DOWN or if it is UNREACHABLE. The distinction between DOWN and UNREACHABLE host states is important, as it allows admins to determine root cause of network outages faster. The following table shows how Nagios makes a final state determination based on the state of the hosts parent(s). A host's parents are defined in the <i>parents</i> directive in host definition.
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Preliminary Host State</th><th>Parent Host State</th><th>Final Host State</th></tr>
+
+<tr><td>DOWN</td><td>At least one parent is UP</td><td>DOWN</td></tr>
+
+<tr><td>DOWN</td><td>All parents are either DOWN or UNREACHABLE</td><td>UNREACHABLE</td></tr>
+
+</table>
+
+
+
+<p>
+
+More information on how Nagios distinguishes between DOWN and UNREACHABLE states can be found <a href="networkreachability.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Host State Changes</u></strong>
+
+</p>
+
+
+
+<p>
+
+As you are probably well aware, hosts don't always stay in one state. Things break, patches get applied, and servers need to be rebooted. When Nagios checks the status of hosts, it will be able to detect when a host changes between UP, DOWN, and UNREACHABLE states and take appropriate action. These state changes result in different <a href="statetypes.html">state types</a> (HARD or SOFT), which can trigger <a href="eventhandlers.html">event handlers</a> to be run and <a href="notifications.html">notifications</a> to be sent out. Detecting and dealing with state changes is what Nagios is all about.
+
+</p>
+
+
+
+<p>
+
+When hosts change state too frequently they are considered to be "flapping". A good example of a flapping host would be server that keeps spontaneously rebooting as soon as the operating system loads. That's always a fun scenario to have to deal with. Nagios can detect when hosts start flapping, and can suppress notifications until flapping stops and the host's state stabilizes. More information on the flap detection logic can be found <a href="flapping.html">here</a>.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<HTML>
+
+<HEAD>
+
+<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
+
+<TITLE>Nagios Core Documentation</TITLE>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; text-align: center;}
+
+
+
+ .Trademark { font-family: verdana,arial,serif; font-size: 7ptl; }
+
+ .Copyright { font-family: verdana,arial,serif; font-size: 8pt; text-align: center; margin: 0 0 25px 0;}
+
+ .LastUpdate { font-family: verdana,arial,serif; font-size: 10pt; text-align: center; }
+
+ .HomePageLink { font-family: verdana,arial,serif; font-size: 10pt; text-align: center; font-weight: bold; }
+
+
+
+ .DocLink { font-family: verdana,arial,serif; font-size: 10pt; font-weight: bold; text-align: center; }
+
+
+
+ .Disclaimer { text-align: center; font-family: verdana,arial,serif; font-size: 7pt; font-style: italic; }
+
+
+
+-->
+
+</STYLE>
+
+
+
+</HEAD>
+
+<body bgcolor="#FFFFFF" text="black" CLASS="Default">
+
+
+
+<div align="center">
+
+<img src="images/logofullsize.png" border=0 alt="Nagios">
+
+</div>
+
+
+
+<h1 class="PageTitle">
+
+Nagios Core Version 3.x Documentation
+
+</h1>
+
+
+
+<p class="HomePageLink">
+
+<a href="http://www.nagios.org/" target="_blank">http://www.nagios.org</a>
+
+</p>
+
+
+
+<div class="Copyright">
+
+Copyright © 2009 Nagios Core Development Team and Community Contributors.<br>
+Copyright © 1999-2009 Ethan Galstad.<br><br>
+
+Portions copyright by Nagios Community members. See the THANKS file for more information.
+
+</div>
+
+<div class="LastUpdate">
+
+Last Updated: 06-16-2009
+
+</div>
+
+
+
+
+
+
+
+<br><br>
+
+
+
+<div class="DocLink">
+
+[ <a href="toc.html">Table of Contents</a> ]
+
+</div>
+
+
+
+<br><br><br><br>
+
+
+
+<p class="Disclaimer">
+
+Nagios, Nagios Core, NRPE, NSCA, and the Nagios logo are trademarks, servicemarks, registered servicemarks or registered trademarks of <a href="http://www.nagios.com/" target="_blank">Nagios Enterprises</a>. All other trademarks, servicemarks, registered trademarks, and registered servicemarks mentioned herein may be the property of their respective owner(s). The information contained herein is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE WARRANTY OF DESIGN, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE.
+
+</p>
+
+
+
+</BODY>
+
+</HTML>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>SNMP Trap Integration</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">SNMP Trap Integration</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="integration.html">Integration Overview</a>, <a href="extcommands.html">External Commands</a>, <a href="passivechecks.html">Passive Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Nagios is not designed to be a replacement for a full-blown SNMP management application like HP OpenView or <a href="http://www.opennms.org/">OpenNMS</a>. However, you can set things up so that SNMP traps received by a host on your network can generate alerts in Nagios.
+
+</p>
+
+
+
+<p>
+
+As if designed to make the Gods of Hypocrisy die of laughter, SNMP is anything but simple. Translating SNMP traps and getting them into Nagios (as passive check results) can be a bit tedious. To make this task easier, I suggest you check out Alex Burger's SNMP Trap Translator project located at <a href="http://www.snmptt.org">http://www.snmptt.org</a>. When combined with Net-SNMP, SNMPTT provides an enhanced trap handling system that can be integrated with Nagios.
+
+</p>
+
+
+
+<p>
+
+Yep, that's all.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>TCP Wrapper Integration</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">TCP Wrapper Integration</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="integration.html">Integration Overview</a>, <a href="extcommands.html">External Commands</a>, <a href="passivechecks.html">Passive Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/tcpwrappers.png" border="0" style="float: right;" alt="TCP Wrappers" title="TCP Wrappers">
+
+
+
+<p>
+
+This document explains how to easily generate alerts in Nagios for connection attempts that are rejected by TCP wrappers. For example, if an unauthorized host attempts to connect to your SSH server, you can receive an alert in Nagios that contains the name of the host that was rejected. If you implement this on your Linux/Unix boxes, you'll be surprised how many port scans you can detect across your network.
+
+</p>
+
+
+
+<p>
+
+These directions assume:
+
+</p>
+
+
+
+<ol>
+
+<li>You are already familiar with <a href="passivechecks.html">passive checks</a> and how they work.</li>
+
+<li>You are already familiar with <a href="volatileservices.html">volatile services</a> and how they work.</li>
+
+<li>The host which you are generating alerts for (i.e. the host you are using TCP wrappers on) is a remote host (called <i>firestorm</i> in this example). If you want to generate alerts on the same host that Nagios is running you will need to make a few modifications to the examples I provide.</li>
+
+<li>You have installed the <a href="addons.html#nsca">NSCA daemon</a> on your monitoring server and the NSCA client (<i>send_nsca</i>) on the remote machine that you are generating TCP wrapper alerts from.</li>
+
+</ol>
+
+
+
+<br clear="all">
+
+
+
+<p>
+
+<strong><u>Defining A Service</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you haven't done so already, create a <a href="objectdefinitions.html#">host definition</a> for the remote host (<i>firestorm</i>).
+
+</p>
+
+
+
+<p>
+
+Next, define a service in one of your <a href="configobject.html">object configuration files</a> for the TCP wrapper alerts on host <i>firestorm</i>. The service definition might look something like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ host_name firestorm
+
+ service_description TCP Wrappers
+
+ is_volatile 1
+
+ active_checks_enabled 0
+
+ passive_checks_enabled 1
+
+ max_check_attempts 1
+
+ check_command check_none
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+There are some important things to note about the above service definition:
+
+</p>
+
+
+
+<ol>
+
+<li>The <i>volatile</i> option enabled. We want this option enabled because we want a notification to be generated for every alert that comes in.</li>
+
+<li>Active checks of the service as disabled, while passive checks are enabled. This means that the service will never be actively checked by Nagios - all alert information will have to be received passively from an external source.</li>
+
+<li>The <i>max_check_attempts</i> value is set to 1. This guarantees you will get a notification when the first alert is generated.</li>
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Configuring TCP Wrappers</u></strong>
+
+</p>
+
+
+
+<p>
+
+Now you're going to have to modify the <i>/etc/hosts.deny</i> file on <i>firestorm</i>. In order to have the TCP wrappers send an alert to the monitoring host whenever a connection attempt is denied, you'll have to add a line similiar to the following:
+
+</p>
+
+
+
+<pre>
+
+ALL: ALL: RFC931: twist (/usr/local/nagios/libexec/eventhandlers/handle_tcp_wrapper %h %d) &
+
+</pre>
+
+
+
+<p>
+
+This line assumes that there is a script called <i>handle_tcp_wrapper</i> in the <i>/usr/local/nagios/libexec/eventhandlers/</i> directory on <i>firestorm</i>. We'll write that script next.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Writing The Script</u></strong>
+
+</p>
+
+
+
+<p>
+
+The last thing you need to do is write the <i>handle_tcp_wrapper</i> script on <i>firestorm</i> that will send the alert back to the Nagios server. It might look something like this:
+
+</p>
+
+
+
+<pre>
+
+#!/bin/sh
+
+
+
+/usr/local/nagios/libexec/eventhandlers/submit_check_result firestorm "TCP Wrappers" 2 "Denied $2-$1" > /dev/null 2> /dev/null
+
+</pre>
+
+
+
+<p>
+
+Notice that the <i>handle_tcp_wrapper</i> script calls the <i>submit_check_result</i> script to actually send the alert back to the monitoring host. Assuming your Nagios server is called <i>monitor</i>, the <i>submit check_result</i> script might look like this:
+
+</p>
+
+
+
+<pre>
+
+#!/bin/sh
+
+# Arguments
+
+# $1 = name of host in service definition
+
+# $2 = name/description of service in service definition
+
+# $3 = return code
+
+# $4 = output
+
+
+
+/bin/echo -e "$1\t$2\t$3\t$4\n" | /usr/local/nagios/bin/send_nsca monitor -c /usr/local/nagios/etc/send_nsca.cfg
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Finishing Up</u></strong>
+
+</p>
+
+
+
+<p>
+
+You've now configured everything you need to, so all you have to do is restart the <i>inetd</i> process on <i>firestorm</i> and restart Nagios on your monitoring server. That's it! When the TCP wrappers on <i>firestorm</i> deny a connection attempt, you should be getting alerts in Nagios. The plugin output for the alert will look something like the following:
+
+</p>
+
+
+
+<pre>
+
+Denied sshd2-sdn-ar-002mnminnP321.dialsprint.net
+
+</pre>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Integration Overview</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Integration Overview</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="extcommands.html">External Commands</a>, <a href="passivechecks.html">Passive Checks</a>, <a href="eventhandlers.html">Event Handlers</a>, <a href="plugins.html">Plugins</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+One of the reasons that Nagios is such a popular monitoring application is the fact that it can be easily integrated in your existing infrastructure. There are several methods of integrating Nagios with the management software you're already using and you can monitor almost any type of new or custom hardware, service, or application that you might have.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Integration Points</u></strong>
+
+</p>
+
+
+
+<img src="images/integrationoverview.png" border="0" style="float: right;" alt="Integration Overview" title="Integration Overview">
+
+
+
+<p>
+
+To monitor new hardware, services, or applications, check out the docs on:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="plugins.html">Plugins</a></li>
+
+<li><a href="pluginapi.html">Plugin API</a></li>
+
+<li><a href="passivechecks.html">Passive Checks</a></li>
+
+<li><a href="eventhandlers.html">Event Handlers</a></li>
+
+</ul>
+
+
+
+<p>
+
+To get data into Nagios from external applications, check out the docs on:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="passivechecks.html">Passive Checks</a></li>
+
+<li><a href="extcommands.html">External Commands</a></li>
+
+</ul>
+
+
+
+<p>
+
+To send status, performance, or notification information from Nagios to external applications, check out the docs on:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="eventhandlers.html">Event Handlers</a></li>
+
+<li><a href="configmain.html#ocsp_command">OCSP</a> and <a href="configmain.html#ochp_command">OCHP</a> Commands</li>
+
+<li><a href="perfdata.html">Performance Data</a></li>
+
+<li><a href="notifications.html">Notifications</a></li>
+
+</ul>
+
+
+
+<br clear="all">
+
+
+
+
+
+<p>
+
+<strong><u>Integration Examples</u></strong>
+
+</p>
+
+
+
+<p>
+
+I've documented some examples on how to integrate Nagios with external applications:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="int-tcpwrappers.html">TCP Wrappers</a> (security alerts)</li>
+
+<li><a href="int-snmptrap.html">SNMP Traps</a> (Arcserve backup job status)</li>
+
+</ul>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Known Issues</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<h1 class="PageTitle">Known Issues</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="whatsnew.html">What's New</a>
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Known Issues</u></strong>
+
+</p>
+
+
+
+<ol>
+
+
+
+<li><font color="red"><b>Timeperiods</b></font>:<br>
+
+ <ul>
+
+ <li><b>Exclusions and Host/Service Checks</b> - There is a bug in the service/host check scheduling logic that rears its head when you use timeperiod definitions that use the <i>exclude</i> directive. The problem occurs when Nagios Core tries to re-schedule the next check. In this case, the scheduling logic may incorrectly schedule the next check further out in the future than it should. In essence, it skips over the (missing) logic where it could determine an earlier possible time using the exception times. Imperfect Solution: Don't use timeperiod definitions that exclude other timeperods for your host/service check periods. A fix is being worked on, and will hopefully make it into a 3.4.x release.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+</ol>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Large Installation Tweaks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Large Installation Tweaks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="tuning.html">Performance Tuning</a>, <a href="faststartup.html">Fast Startup Options</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Users with large Nagios installations may benefit from the <a href="configmain.html#use_large_installation_tweaks">use_large_installation_tweaks</a> configuration option. Enabling this option allows the Nagios daemon to take certain shortcuts which result in lower system load and better performance.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Effects</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you enable the <a href="configmain.html#use_large_installation_tweaks">use_large_installation_tweaks</a> option in your main Nagios config file, several changes are made to the way the Nagios daemon operates:
+
+</p>
+
+
+
+<ol>
+
+
+
+<li><b>No Summary Macros In Environment Variables</b> - The <a href="macrolist.html#summary_macros">summary macros</a> will not be available to you as environment variables. Calculating the values of these macros can be quite time-intensive in large configurations, so they are not available as environment variables when use this option. Summary macros will still be available as regular macros if you pass them to to your scripts as arguments.<br><br></li>
+
+
+
+<li><b>Different Memory Cleanup</b> - Normally Nagios will free all allocated memory in child processes before they exit. This is probably best practice, but is likely unnecessary in most installations, as most OSes will take care of freeing allocated memory when processes exit. The OS tends to free allocated memory faster than can be done within Nagios itself, so Nagios won't attempt to free memory in child processes if you enable this option.<br><br></li>
+
+
+
+<li><b>Checks fork() Less</b> - Normally Nagios will fork() twice when it executes host and service checks. This is done to (1) ensure a high level of resistance against plugins that go awry and segfault and (2) make the OS deal with cleaning up the grandchild process once it exits. The extra fork() is not really necessary, so it is skipped when you enable this option. As a result, Nagios will itself clean up child processes that exit (instead of leaving that job to the OS). This feature should result in significant load savings on your Nagios installation.<br><br></li>
+
+
+
+</ol>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Standard Macros in Nagios</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+
+
+ TH.Macros { font-family: verdana,arial,serif; font-size: 9pt; font-weight: bold; background-color: #cbcbcb; }
+
+ .MacroName { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold;}
+
+ .MacroDescription { font-family: verdana,arial,serif; font-size: 7pt; }
+
+ .MacroNo { font-family: verdana,arial,serif; font-size: 8pt; background-color: white; }
+
+ .MacroYes { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold; background-color: #00ff00; }
+
+ .MacroType { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold; background-color: #cbcbcb; }
+
+
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Standard Macros in Nagios</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="macros.html">How Macros Work</a>
+
+</p>
+
+
+
+<p>
+
+Standard macros that are available in Nagios are listed here. On-demand macros and macros for custom variables are described <a href="macros.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Macro Validity</u></strong>
+
+</p>
+
+
+
+<p>
+
+Although macros can be used in all commands you define, not all macros may be "valid" in a particular type of command. For example, some macros may only be valid during service notification commands, whereas other may only be valid during host check commands. There are ten types of commands that Nagios recognizes and treats differently. They are as follows:
+
+</p>
+
+<ol>
+
+<li>Service checks
+
+<li>Service notifications
+
+<li>Host checks
+
+<li>Host notifications
+
+<li>Service <a href="eventhandlers.html">event handlers</a> and/or a global service event handler
+
+<li>Host <a href="eventhandlers.html">event handlers</a> and/or a global host event handler
+
+<li><a href="configmain.html#ocsp_command">OCSP</a> command
+
+<li><a href="configmain.html#ochp_command">OCHP</a> command
+
+<li>Service <a href="perfdata.html">performance data</a> commands
+
+<li>Host <a href="perfdata.html">performance data</a> commands
+
+</ol>
+
+
+
+<p>
+
+The tables below list all macros currently available in Nagios, along with a brief description of each and the types of commands in which they are valid. If a macro is used in a command in which it is invalid, it is replaced with an empty string. It should be noted that macros consist of all uppercase characters and are enclosed in <b>$</b> characters.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Macro Availability Chart</u></strong>
+
+</p>
+
+
+
+<b>Legend:</b><br>
+
+<table border="1" cellspacing="0" cellpadding="5" class="Default">
+
+<tr><td class="MacroNo">No</td><td>The macro is not available</td></tr>
+
+<tr><td class="MacroYes">Yes</td><td>The macro is available</td></tr>
+
+</table>
+
+
+
+<br>
+
+
+
+<div align="center">
+
+<table border="1" cellspacing="0" cellpadding="5">
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Host Macros: <a href="#note3"><sup>3</sup></a></td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostname">$HOSTNAME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostdisplayname">$HOSTDISPLAYNAME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostalias">$HOSTALIAS$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostaddress">$HOSTADDRESS$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hoststate">$HOSTSTATE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hoststateid">$HOSTSTATEID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthoststate">$LASTHOSTSTATE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthoststateid">$LASTHOSTSTATEID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hoststatetype">$HOSTSTATETYPE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostattempt">$HOSTATTEMPT$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#maxhostattempts">$MAXHOSTATTEMPTS$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hosteventid">$HOSTEVENTID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthosteventid">$LASTHOSTEVENTID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostproblemid">$HOSTPROBLEMID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthostproblemid">$LASTHOSTPROBLEMID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostlatency">$HOSTLATENCY$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostexecutiontime">$HOSTEXECUTIONTIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostduration">$HOSTDURATION$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostdurationsec">$HOSTDURATIONSEC$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostdowntime">$HOSTDOWNTIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostpercentchange">$HOSTPERCENTCHANGE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupname">$HOSTGROUPNAME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupnames">$HOSTGROUPNAMES$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthostcheck">$LASTHOSTCHECK$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthoststatechange">$LASTHOSTSTATECHANGE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthostup">$LASTHOSTUP$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthostdown">$LASTHOSTDOWN$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lasthostunreachable">$LASTHOSTUNREACHABLE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostoutput">$HOSTOUTPUT$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#longhostoutput">$LONGHOSTOUTPUT$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostperfdata">$HOSTPERFDATA$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note1"><sup>1</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostcheckcommand">$HOSTCHECKCOMMAND$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostackauthor">$HOSTACKAUTHOR$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostackauthorname">$HOSTACKAUTHORNAME$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostackauthoralias">$HOSTACKAUTHORALIAS$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostackcomment">$HOSTACKCOMMENT$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostactionurl">$HOSTACTIONURL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostnotesurl">$HOSTNOTESURL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostnotes">$HOSTNOTES$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostservices">$TOTALHOSTSERVICES$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostservicesok">$TOTALHOSTSERVICESOK$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostserviceswarning">$TOTALHOSTSERVICESWARNING$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostservicesunknown">$TOTALHOSTSERVICESUNKNOWN$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostservicescritical">$TOTALHOSTSERVICESCRITICAL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Host Group Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupalias">$HOSTGROUPALIAS$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupmembers">$HOSTGROUPMEMBERS$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupnotes">$HOSTGROUPNOTES$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupnotesurl">$HOSTGROUPNOTESURL$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostgroupactionurl">$HOSTGROUPACTIONURL$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Service Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicedesc">$SERVICEDESC$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicedisplayname">$SERVICEDISPLAYNAME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicestate">$SERVICESTATE$</a></td>
+
+<td class="MacroYes">Yes <a href="#note2"><sup>2</sup></a></td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicestateid">$SERVICESTATEID$</a></td>
+
+<td class="MacroYes">Yes <a href="#note2"><sup>2</sup></a></td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastservicestate">$LASTSERVICESTATE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastservicestateid">$LASTSERVICESTATEID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicestatetype">$SERVICESTATETYPE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceattempt">$SERVICEATTEMPT$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#maxserviceattempts">$MAXSERVICEATTEMPTS$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceisvolatile">$SERVICEISVOLATILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceeventid">$SERVICEEVENTID$</a></td>
+
+<td class="MacroYes">Yes </td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastserviceeventid">$LASTSERVICEEVENTID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceproblemid">$SERVICEPROBLEMID$</a></td>
+
+<td class="MacroYes">Yes </td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastserviceproblemid">$LASTSERVICEPROBLEMID$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicelatency">$SERVICELATENCY$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceexecutiontime">$SERVICEEXECUTIONTIME$</a></td>
+
+<td class="MacroYes">Yes <a href="#note2"><sup>2</sup></a></td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceduration">$SERVICEDURATION$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicedurationsec">$SERVICEDURATIONSEC$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicedowntime">$SERVICEDOWNTIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicepercentchange">$SERVICEPERCENTCHANGE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupname">$SERVICEGROUPNAME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupnames">$SERVICEGROUPNAMES$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastservicecheck">$LASTSERVICECHECK$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastservicestatechange">$LASTSERVICESTATECHANGE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastserviceok">$LASTSERVICEOK$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastservicewarning">$LASTSERVICEWARNING$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastserviceunknown">$LASTSERVICEUNKNOWN$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#lastservicecritical">$LASTSERVICECRITICAL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceoutput">$SERVICEOUTPUT$</a></td>
+
+<td class="MacroYes">Yes <a href="#note2"><sup>2</sup></a></td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#longserviceoutput">$LONGSERVICEOUTPUT$</a></td>
+
+<td class="MacroYes">Yes <a href="#note2"><sup>2</sup></a></td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceperfdata">$SERVICEPERFDATA$</a></td>
+
+<td class="MacroYes">Yes <a href="#note2"><sup>2</sup></a></td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicecheckcommand">$SERVICECHECKCOMMAND$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceackauthor">$SERVICEACKAUTHOR$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceackauthorname">$SERVICEACKAUTHORNAME$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceackauthoralias">$SERVICEACKAUTHORALIAS$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceackcomment">$SERVICEACKCOMMENT$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceactionurl">$SERVICEACTIONURL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicenotesurl">$SERVICENOTESURL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicenotes">$SERVICENOTES$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Service Group Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupalias">$SERVICEGROUPALIAS$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupmembers">$SERVICEGROUPMEMBERS$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupnotes">$SERVICEGROUPNOTES$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupnotesurl">$SERVICEGROUPNOTESURL$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicegroupactionurl">$SERVICEGROUPACTIONURL$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Contact Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactname">$CONTACTNAME$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactalias">$CONTACTALIAS$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactemail">$CONTACTEMAIL$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactpager">$CONTACTPAGER$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactaddress">$CONTACTADDRESSn$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Contact Group Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactgroupalias">$CONTACTGROUPALIAS$</a> <a href="#note7"><sup>7</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#contactgroupmembers">$CONTACTGROUPMEMBERS$</a> <a href="#note7"><sup>7</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'><a name="summary_macros"></a>Summary Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostsup">$TOTALHOSTSUP$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostsdown">$TOTALHOSTSDOWN$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostsunreachable">$TOTALHOSTSUNREACHABLE$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostsdownunhandled">$TOTALHOSTSDOWNUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostsunreachableunhandled">$TOTALHOSTSUNREACHABLEUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostproblems">$TOTALHOSTPROBLEMS$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalhostproblemsunhandled">$TOTALHOSTPROBLEMSUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalservicesok">$TOTALSERVICESOK$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalserviceswarning">$TOTALSERVICESWARNING$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalservicescritical">$TOTALSERVICESCRITICAL$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalservicesunknown">$TOTALSERVICESUNKNOWN$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalserviceswarningunhandled">$TOTALSERVICESWARNINGUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalservicescriticalunhandled">$TOTALSERVICESCRITICALUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalservicesunknownunhandled">$TOTALSERVICESUNKNOWNUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalserviceproblems">$TOTALSERVICEPROBLEMS$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#totalserviceproblemsunhandled">$TOTALSERVICEPROBLEMSUNHANDLED$</a> <a href="#note10"><sup>10</sup></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes <a href="#note4"><sup>4</sup></a></td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Notification Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationtype">$NOTIFICATIONTYPE$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationrecipients">$NOTIFICATIONRECIPIENTS$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationisescalated">$NOTIFICATIONISESCALATED$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationauthor">$NOTIFICATIONAUTHOR$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationauthorname">$NOTIFICATIONAUTHORNAME$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationauthoralias">$NOTIFICATIONAUTHORALIAS$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#notificationcomment">$NOTIFICATIONCOMMENT$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostnotificationnumber">$HOSTNOTIFICATIONNUMBER$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostnotificationid">$HOSTNOTIFICATIONID$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicenotificationnumber">$SERVICENOTIFICATIONNUMBER$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#servicenotificationid">$SERVICENOTIFICATIONID$</a></td>
+
+<td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroYes">Yes</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td><td class="MacroNo">No</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Date/Time Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#longdatetime">$LONGDATETIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#shortdatetime">$SHORTDATETIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#date">$DATE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#time">$TIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#timet">$TIMET$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#isvalidtime">$ISVALIDTIME:$</a> <a href="#note9"><sup>9</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#nextvalidtime">$NEXTVALIDTIME:$</a> <a href="#note9"><sup>9</sup></a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>File Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#mainconfigfile">$MAINCONFIGFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#statusdatafile">$STATUSDATAFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#commentdatafile">$COMMENTDATAFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes< <a href="#note5"><sup>5</sup></a>/td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#downtimedatafile">$DOWNTIMEDATAFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#retentiondatafile">$RETENTIONDATAFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#objectcachefile">$OBJECTCACHEFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#tempfile">$TEMPFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#temppath">$TEMPPATH$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#logfile">$LOGFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#resourcefile">$RESOURCEFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#commandfile">$COMMANDFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#hostperfdatafile">$HOSTPERFDATAFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#serviceperfdatafile">$SERVICEPERFDATAFILE$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+<tr><td colspan='9'><br></td></tr>
+
+<tr class="Macros">
+
+<th class="Macros">Macro Name</th>
+
+<th class="Macros">Service Checks</th>
+
+<th class="Macros">Service Notifications</th>
+
+<th class="Macros">Host Checks</th>
+
+<th class="Macros">Host Notifications</th>
+
+<th class="Macros">Service Event Handlers and <a href="configmain.html#ocsp_command">OCSP</a></th>
+
+<th class="Macros">Host Event Handlers and <a href="configmain.html#ochp_command">OCHP</a></th>
+
+<th class="Macros">Service Perf Data</th>
+
+<th class="Macros">Host Perf Data</th>
+
+</tr>
+
+<tr>
+
+<td colspan='9' class='MacroType'>Misc Macros:</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#processstarttime">$PROCESSSTARTTIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#eventstarttime">$EVENTSTARTTIME$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#adminemail">$ADMINEMAIL$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#adminpager">$ADMINPAGER$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#arg">$ARGn$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+<tr>
+
+<td class='MacroName'><a href="#user">$USERn$</a></td>
+
+<td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td><td class="MacroYes">Yes</td>
+
+</tr>
+
+
+
+</table>
+
+</div>
+
+
+
+<br>
+
+
+
+
+
+<p>
+
+<strong><u>Macro Descriptions</u></strong>
+
+</p>
+
+
+
+<table border="1" cellspacing="0" cellpadding="5">
+
+
+
+<tr>
+
+<td colspan='2' class='MacroType'>Host Macros: <a href="#note3"><sup>3</sup></a></td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostname">$HOSTNAME$</a></td>
+
+<td class="MacroDescription">Short name for the host (i.e. "biglinuxbox"). This value is taken from the <i>host_name</i> directive in the <a href="objectdefinitions.html#host">host definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostdisplayname">$HOSTDISPLAYNAME$</a></td>
+
+<td class="MacroDescription">An alternate display name for the host. This value is taken from the <i>display_name</i> directive in the <a href="objectdefinitions.html#host">host definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostalias">$HOSTALIAS$</a></td>
+
+<td class="MacroDescription">Long name/description for the host. This value is taken from the <i>alias</i> directive in the <a href="objectdefinitions.html#host">host definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostaddress">$HOSTADDRESS$</a></td>
+
+<td class="MacroDescription">Address of the host. This value is taken from the <i>address</i> directive in the <a href="objectdefinitions.html#host">host definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hoststate">$HOSTSTATE$</a></td>
+
+<td class="MacroDescription">A string indicating the current state of the host ("UP", "DOWN", or "UNREACHABLE").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hoststateid">$HOSTSTATEID$</a></td>
+
+<td class="MacroDescription">A number that corresponds to the current state of the host: 0=UP, 1=DOWN, 2=UNREACHABLE.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthoststate">$LASTHOSTSTATE$</a></td>
+
+<td class="MacroDescription">A string indicating the last state of the host ("UP", "DOWN", or "UNREACHABLE").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthoststateid">$LASTHOSTSTATEID$</a></td>
+
+<td class="MacroDescription">A number that corresponds to the last state of the host: 0=UP, 1=DOWN, 2=UNREACHABLE.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hoststatetype">$HOSTSTATETYPE$</a></td>
+
+<td class="MacroDescription">A string indicating the <a href="statetypes.html">state type</a> for the current host check ("HARD" or "SOFT"). Soft states occur when host checks return a non-OK (non-UP) state and are in the process of being retried. Hard states result when host checks have been checked a specified maximum number of times.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostattempt">$HOSTATTEMPT$</a></td>
+
+<td class="MacroDescription">The number of the current host check retry. For instance, if this is the second time that the host is being rechecked, this will be the number two. Current attempt number is really only useful when writing host event handlers for "soft" states that take a specific action based on the host retry number.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="maxhostattempts">$MAXHOSTATTEMPTS$</a></td>
+
+<td class="MacroDescription">The max check attempts as defined for the current host. Useful when writing host event handlers for "soft" states that take a specific action based on the host retry number.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hosteventid">$HOSTEVENTID$</a></td>
+
+<td class="MacroDescription">A globally unique number associated with the host's current state. Every time a host (or service) experiences a state change, a global event ID number is incremented by one (1). If a host has experienced no state changes, this macro will be set to zero (0).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthosteventid">$LASTHOSTEVENTID$</a></td>
+
+<td class="MacroDescription">The previous (globally unique) event number that was given to the host.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostproblemid">$HOSTPROBLEMID$</a></td>
+
+<td class="MacroDescription">A globally unique number associated with the host's current problem state. Every time a host (or service) transitions from an UP or OK state to a problem state, a global problem ID number is incremented by one (1). This macro will be non-zero if the host is currently a non-UP state. State transitions between non-UP states (e.g. DOWN to UNREACHABLE) do not cause this problem id to increase. If the host is currently in an UP state, this macro will be set to zero (0). Combined with event handlers, this macro could be used to automatically open trouble tickets when hosts first enter a problem state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthostproblemid">$LASTHOSTPROBLEMID$</a></td>
+
+<td class="MacroDescription">The previous (globally unique) problem number that was given to the host. Combined with event handlers, this macro could be used for automatically closing trouble tickets, etc. when a host recovers to an UP state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostlatency">$HOSTLATENCY$</a></td>
+
+<td class="MacroDescription">A (floating point) number indicating the number of seconds that a <i>scheduled</i> host check lagged behind its scheduled check time. For instance, if a check was scheduled for 03:14:15 and it didn't get executed until 03:14:17, there would be a check latency of 2.0 seconds. On-demand host checks have a latency of zero seconds.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostexecutiontime">$HOSTEXECUTIONTIME$</a></td>
+
+<td class="MacroDescription">A (floating point) number indicating the number of seconds that the host check took to execute (i.e. the amount of time the check was executing).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostduration">$HOSTDURATION$</a></td>
+
+<td class="MacroDescription">A string indicating the amount of time that the host has spent in its current state. Format is "XXh YYm ZZs", indicating hours, minutes and seconds.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostdurationsec">$HOSTDURATIONSEC$</a></td>
+
+<td class="MacroDescription">A number indicating the number of seconds that the host has spent in its current state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostdowntime">$HOSTDOWNTIME$</a></td>
+
+<td class="MacroDescription">A number indicating the current "downtime depth" for the host. If this host is currently in a period of <a href="downtime.html">scheduled downtime</a>, the value will be greater than zero. If the host is not currently in a period of downtime, this value will be zero.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostpercentchange">$HOSTPERCENTCHANGE$</a></td>
+
+<td class="MacroDescription">A (floating point) number indicating the percent state change the host has undergone. Percent state change is used by the <a href="flapping.html">flap detection</a> algorithm.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupname">$HOSTGROUPNAME$</a></td>
+
+<td class="MacroDescription">The short name of the hostgroup that this host belongs to. This value is taken from the <i>hostgroup_name</i> directive in the <a href="objectdefinitions.html#hostgroup">hostgroup definition</a>. If the host belongs to more than one hostgroup this macro will contain the name of just one of them.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupnames">$HOSTGROUPNAMES$</a></td>
+
+<td class="MacroDescription">A comma separated list of the short names of all the hostgroups that this host belongs to.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthostcheck">$LASTHOSTCHECK$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which a check of the host was last performed.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthoststatechange">$LASTHOSTSTATECHANGE$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time the host last changed state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthostup">$LASTHOSTUP$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the host was last detected as being in an UP state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthostdown">$LASTHOSTDOWN$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the host was last detected as being in a DOWN state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lasthostunreachable">$LASTHOSTUNREACHABLE$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the host was last detected as being in an UNREACHABLE state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostoutput">$HOSTOUTPUT$</a></td>
+
+<td class="MacroDescription">The first line of text output from the last host check (i.e. "Ping OK").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="longhostoutput">$LONGHOSTOUTPUT$</a></td>
+
+<td class="MacroDescription">The full text output (aside from the first line) from the last host check.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostperfdata">$HOSTPERFDATA$</a></td>
+
+<td class="MacroDescription">This macro contains any <a href="perfdata.html">performance data</a> that may have been returned by the last host check.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostcheckcommand">$HOSTCHECKCOMMAND$</a></td>
+
+<td class="MacroDescription">This macro contains the name of the command (along with any arguments passed to it) used to perform the host check.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostackauthor">$HOSTACKAUTHOR$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the name of the user who acknowledged the host problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostackauthorname">$HOSTACKAUTHORNAME$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the short name of the contact (if applicable) who acknowledged the host problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostackauthoralias">$HOSTACKAUTHORALIAS$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the alias of the contact (if applicable) who acknowledged the host problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostackcomment">$HOSTACKCOMMENT$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the acknowledgement comment that was entered by the user who acknowledged the host problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostactionurl">$HOSTACTIONURL$</a></td>
+
+<td class="MacroDescription">Action URL for the host. This macro may contain other macros (e.g. $HOSTNAME$), which can be useful when you want to pass the host name to a web page.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostnotesurl">$HOSTNOTESURL$</a></td>
+
+<td class="MacroDescription">Notes URL for the host. This macro may contain other macros (e.g. $HOSTNAME$), which can be useful when you want to pass the host name to a web page.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostnotes">$HOSTNOTES$</a></td>
+
+<td class="MacroDescription">Notes for the host. This macro may contain other macros (e.g. $HOSTNAME$), which can be useful when you want to host-specific status information, etc. in the description.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostservices">$TOTALHOSTSERVICES$</a></td>
+
+<td class="MacroDescription">The total number of services associated with the host.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostservicesok">$TOTALHOSTSERVICESOK$</a></td>
+
+<td class="MacroDescription">The total number of services associated with the host that are in an OK state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostserviceswarning">$TOTALHOSTSERVICESWARNING$</a></td>
+
+<td class="MacroDescription">The total number of services associated with the host that are in a WARNING state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostservicesunknown">$TOTALHOSTSERVICESUNKNOWN$</a></td>
+
+<td class="MacroDescription">The total number of services associated with the host that are in an UNKNOWN state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostservicescritical">$TOTALHOSTSERVICESCRITICAL$</a></td>
+
+<td class="MacroDescription">The total number of services associated with the host that are in a CRITICAL state.</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Host Group Macros: <a href="#note5"><sup>5</sup></a></td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupalias">$HOSTGROUPALIAS$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroDescription">The long name / alias of either 1) the hostgroup name passed as an on-demand macro argument or 2) the primary hostgroup associated with the current host (if not used in the context of an on-demand macro). This value is taken from the <i>alias</i> directive in the <a href="objectdefinitions.html#hostgroup">hostgroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupmembers">$HOSTGROUPMEMBERS$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroDescription">A comma-separated list of all hosts that belong to either 1) the hostgroup name passed as an on-demand macro argument or 2) the primary hostgroup associated with the current host (if not used in the context of an on-demand macro).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupnotes">$HOSTGROUPNOTES$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroDescription">The notes associated with either 1) the hostgroup name passed as an on-demand macro argument or 2) the primary hostgroup associated with the current host (if not used in the context of an on-demand macro). This value is taken from the <i>notes</i> directive in the <a href="objectdefinitions.html#hostgroup">hostgroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupnotesurl">$HOSTGROUPNOTESURL$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroDescription">The notes URL associated with either 1) the hostgroup name passed as an on-demand macro argument or 2) the primary hostgroup associated with the current host (if not used in the context of an on-demand macro). This value is taken from the <i>notes_url</i> directive in the <a href="objectdefinitions.html#hostgroup">hostgroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostgroupactionurl">$HOSTGROUPACTIONURL$</a> <a href="#note5"><sup>5</sup></a></td>
+
+<td class="MacroDescription">The action URL associated with either 1) the hostgroup name passed as an on-demand macro argument or 2) the primary hostgroup associated with the current host (if not used in the context of an on-demand macro). This value is taken from the <i>action_url</i> directive in the <a href="objectdefinitions.html#hostgroup">hostgroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Service Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicedesc">$SERVICEDESC$</a></td>
+
+<td class="MacroDescription">The long name/description of the service (i.e. "Main Website"). This value is taken from the <i>service_description</i> directive of the <a href="objectdefinitions.html#service">service definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicedisplayname">$SERVICEDISPLAYNAME$</a></td>
+
+<td class="MacroDescription">An alternate display name for the service. This value is taken from the <i>display_name</i> directive in the <a href="objectdefinitions.html#service">service definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicestate">$SERVICESTATE$</a></td>
+
+<td class="MacroDescription">A string indicating the current state of the service ("OK", "WARNING", "UNKNOWN", or "CRITICAL").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicestateid">$SERVICESTATEID$</a></td>
+
+<td class="MacroDescription">A number that corresponds to the current state of the service: 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastservicestate">$LASTSERVICESTATE$</a></td>
+
+<td class="MacroDescription">A string indicating the last state of the service ("OK", "WARNING", "UNKNOWN", or "CRITICAL").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastservicestateid">$LASTSERVICESTATEID$</a></td>
+
+<td class="MacroDescription">A number that corresponds to the last state of the service: 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicestatetype">$SERVICESTATETYPE$</a></td>
+
+<td class="MacroDescription">A string indicating the <a href="statetypes.html">state type</a> for the current service check ("HARD" or "SOFT"). Soft states occur when service checks return a non-OK state and are in the process of being retried. Hard states result when service checks have been checked a specified maximum number of times.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceattempt">$SERVICEATTEMPT$</a></td>
+
+<td class="MacroDescription">The number of the current service check retry. For instance, if this is the second time that the service is being rechecked, this will be the number two. Current attempt number is really only useful when writing service event handlers for "soft" states that take a specific action based on the service retry number.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="maxserviceattempts">$MAXSERVICEATTEMPTS$</a></td>
+
+<td class="MacroDescription">The max check attempts as defined for the current service. Useful when writing host event handlers for "soft" states that take a specific action based on the service retry number.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceisvolatile">$SERVICEISVOLATILE$</a></td>
+
+<td class="MacroDescription">Indicates whether the service is marked as being volatile or not: 0 = not volatile, 1 = volatile.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceeventid">$SERVICEEVENTID$</a></td>
+
+<td class="MacroDescription">A globally unique number associated with the service's current state. Every time a a service (or host) experiences a state change, a global event ID number is incremented by one (1). If a service has experienced no state changes, this macro will be set to zero (0).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastserviceeventid">$LASTSERVICEEVENTID$</a></td>
+
+<td class="MacroDescription">The previous (globally unique) event number that given to the service.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceproblemid">$SERVICEPROBLEMID$</a></td>
+
+<td class="MacroDescription">A globally unique number associated with the service's current problem state. Every time a service (or host) transitions from an OK or UP state to a problem state, a global problem ID number is incremented by one (1). This macro will be non-zero if the service is currently a non-OK state. State transitions between non-OK states (e.g. WARNING to CRITICAL) do not cause this problem id to increase. If the service is currently in an OK state, this macro will be set to zero (0). Combined with event handlers, this macro could be used to automatically open trouble tickets when services first enter a problem state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastserviceproblemid">$LASTSERVICEPROBLEMID$</a></td>
+
+<td class="MacroDescription">The previous (globally unique) problem number that was given to the service. Combined with event handlers, this macro could be used for automatically closing trouble tickets, etc. when a service recovers to an OK state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicelatency">$SERVICELATENCY$</a></td>
+
+<td class="MacroDescription">A (floating point) number indicating the number of seconds that a scheduled service check lagged behind its scheduled check time. For instance, if a check was scheduled for 03:14:15 and it didn't get executed until 03:14:17, there would be a check latency of 2.0 seconds.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceexecutiontime">$SERVICEEXECUTIONTIME$</a></td>
+
+<td class="MacroDescription">A (floating point) number indicating the number of seconds that the service check took to execute (i.e. the amount of time the check was executing).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceduration">$SERVICEDURATION$</a></td>
+
+<td class="MacroDescription">A string indicating the amount of time that the service has spent in its current state. Format is "XXh YYm ZZs", indicating hours, minutes and seconds.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicedurationsec">$SERVICEDURATIONSEC$</a></td>
+
+<td class="MacroDescription">A number indicating the number of seconds that the service has spent in its current state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicedowntime">$SERVICEDOWNTIME$</a></td>
+
+<td class="MacroDescription">A number indicating the current "downtime depth" for the service. If this service is currently in a period of <a href="downtime.html">scheduled downtime</a>, the value will be greater than zero. If the service is not currently in a period of downtime, this value will be zero.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicepercentchange">$SERVICEPERCENTCHANGE$</a></td>
+
+<td class="MacroDescription">A (floating point) number indicating the percent state change the service has undergone. Percent state change is used by the <a href="flapping.html">flap detection</a> algorithm.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupname">$SERVICEGROUPNAME$</a></td>
+
+<td class="MacroDescription">The short name of the servicegroup that this service belongs to. This value is taken from the <i>servicegroup_name</i> directive in the <a href="objectdefinitions.html#servicegroup">servicegroup</a> definition. If the service belongs to more than one servicegroup this macro will contain the name of just one of them.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupnames">$SERVICEGROUPNAMES$</a></td>
+
+<td class="MacroDescription">A comma separated list of the short names of all the servicegroups that this service belongs to.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastservicecheck">$LASTSERVICECHECK$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which a check of the service was last performed.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastservicestatechange">$LASTSERVICESTATECHANGE$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time the service last changed state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastserviceok">$LASTSERVICEOK$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the service was last detected as being in an OK state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastservicewarning">$LASTSERVICEWARNING$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the service was last detected as being in a WARNING state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastserviceunknown">$LASTSERVICEUNKNOWN$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the service was last detected as being in an UNKNOWN state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="lastservicecritical">$LASTSERVICECRITICAL$</a></td>
+
+<td class="MacroDescription">This is a timestamp in time_t format (seconds since the UNIX epoch) indicating the time at which the service was last detected as being in a CRITICAL state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceoutput">$SERVICEOUTPUT$</a></td>
+
+<td class="MacroDescription">The first line of text output from the last service check (i.e. "Ping OK").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="longserviceoutput">$LONGSERVICEOUTPUT$</a></td>
+
+<td class="MacroDescription">The full text output (aside from the first line) from the last service check.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceperfdata">$SERVICEPERFDATA$</a></td>
+
+<td class="MacroDescription">This macro contains any <a href="perfdata.html">performance data</a> that may have been returned by the last service check.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicecheckcommand">$SERVICECHECKCOMMAND$</a></td>
+
+<td class="MacroDescription">This macro contains the name of the command (along with any arguments passed to it) used to perform the service check.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceackauthor">$SERVICEACKAUTHOR$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the name of the user who acknowledged the service problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceackauthorname">$SERVICEACKAUTHORNAME$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the short name of the contact (if applicable) who acknowledged the service problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceackauthoralias">$SERVICEACKAUTHORALIAS$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the alias of the contact (if applicable) who acknowledged the service problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceackcomment">$SERVICEACKCOMMENT$</a> <a href="#note8"><sup>8</sup></a></td>
+
+<td class="MacroDescription">A string containing the acknowledgement comment that was entered by the user who acknowledged the service problem. This macro is only valid in notifications where the $NOTIFICATIONTYPE$ macro is set to "ACKNOWLEDGEMENT".</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceactionurl">$SERVICEACTIONURL$</a></td>
+
+<td class="MacroDescription">Action URL for the service. This macro may contain other macros (e.g. $HOSTNAME$ or $SERVICEDESC$), which can be useful when you want to pass the service name to a web page.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicenotesurl">$SERVICENOTESURL$</a></td>
+
+<td class="MacroDescription">Notes URL for the service. This macro may contain other macros (e.g. $HOSTNAME$ or $SERVICEDESC$), which can be useful when you want to pass the service name to a web page.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicenotes">$SERVICENOTES$</a></td>
+
+<td class="MacroDescription">Notes for the service. This macro may contain other macros (e.g. $HOSTNAME$ or $SERVICESTATE$), which can be useful when you want to service-specific status information, etc. in the description</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Service Group Macros: <a href="#note6"><sup>6</sup></a></td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupalias">$SERVICEGROUPALIAS$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroDescription">The long name / alias of either 1) the servicegroup name passed as an on-demand macro argument or 2) the primary servicegroup associated with the current service (if not used in the context of an on-demand macro). This value is taken from the <i>alias</i> directive in the <a href="objectdefinitions.html#servicegroup">servicegroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupmembers">$SERVICEGROUPMEMBERS$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroDescription">A comma-separated list of all services that belong to either 1) the servicegroup name passed as an on-demand macro argument or 2) the primary servicegroup associated with the current service (if not used in the context of an on-demand macro).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupnotes">$SERVICEGROUPNOTES$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroDescription">The notes associated with either 1) the servicegroup name passed as an on-demand macro argument or 2) the primary servicegroup associated with the current service (if not used in the context of an on-demand macro). This value is taken from the <i>notes</i> directive in the <a href="objectdefinitions.html#servicegroup">servicegroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupnotesurl">$SERVICEGROUPNOTESURL$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroDescription">The notes URL associated with either 1) the servicegroup name passed as an on-demand macro argument or 2) the primary servicegroup associated with the current service (if not used in the context of an on-demand macro). This value is taken from the <i>notes_url</i> directive in the <a href="objectdefinitions.html#servicegroup">servicegroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicegroupactionurl">$SERVICEGROUPNOTES$</a> <a href="#note6"><sup>6</sup></a></td>
+
+<td class="MacroDescription">The action URL associated with either 1) the servicegroup name passed as an on-demand macro argument or 2) the primary servicegroup associated with the current service (if not used in the context of an on-demand macro). This value is taken from the <i>action_url</i> directive in the <a href="objectdefinitions.html#servicegroup">servicegroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Contact Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactname">$CONTACTNAME$</a></td>
+
+<td class="MacroDescription">Short name for the contact (i.e. "jdoe") that is being notified of a host or service problem. This value is taken from the <i>contact_name</i> directive in the <a href="objectdefinitions.html#contact">contact definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactalias">$CONTACTALIAS$</a></td>
+
+<td class="MacroDescription">Long name/description for the contact (i.e. "John Doe") being notified. This value is taken from the <i>alias</i> directive in the <a href="objectdefinitions.html#contact">contact definition</a>.</td></tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactemail">$CONTACTEMAIL$</a></td>
+
+<td class="MacroDescription">Email address of the contact being notified. This value is taken from the <i>email</i> directive in the <a href="objectdefinitions.html#contact">contact definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactpager">$CONTACTPAGER$</a></td>
+
+<td class="MacroDescription">Pager number/address of the contact being notified. This value is taken from the <i>pager</i> directive in the <a href="objectdefinitions.html#contact">contact definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactaddress">$CONTACTADDRESSn$</a></td>
+
+<td class="MacroDescription">Address of the contact being notified. Each contact can have six different addresses (in addition to email address and pager number). The macros for these addresses are $CONTACTADDRESS1$ - $CONTACTADDRESS6$. This value is taken from the <i>addressx</i> directive in the <a href="objectdefinitions.html#contact">contact definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactgroupname">$CONTACTGROUPNAME$</a></td>
+
+<td class="MacroDescription">The short name of the contactgroup that this contact is a member of. This value is taken from the <i>contactgroup_name</i> directive in the <a href="objectdefinitions.html#contactgroup">contactgroup</a> definition. If the contact belongs to more than one contactgroup this macro will contain the name of just one of them.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactgroupnames">$CONTACTGROUPNAMES$</a></td>
+
+<td class="MacroDescription">A comma separated list of the short names of all the contactgroups that this contact is a member of.</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Contact Group Macros: <a href="#note5"><sup>5</sup></a></td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactgroupalias">$CONTACTGROUPALIAS$</a> <a href="#note7"><sup>7</sup></a></td>
+
+<td class="MacroDescription">The long name / alias of either 1) the contactgroup name passed as an on-demand macro argument or 2) the primary contactgroup associated with the current contact (if not used in the context of an on-demand macro). This value is taken from the <i>alias</i> directive in the <a href="objectdefinitions.html#contactgroup">contactgroup definition</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="contactgroupmembers">$CONTACTGROUPMEMBERS$</a> <a href="#note7"><sup>7</sup></a></td>
+
+<td class="MacroDescription">A comma-separated list of all contacts that belong to either 1) the contactgroup name passed as an on-demand macro argument or 2) the primary contactgroup associated with the current contact (if not used in the context of an on-demand macro).</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>SUMMARY Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostsup">$TOTALHOSTSUP$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently in an UP state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostsdown">$TOTALHOSTSDOWN$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently in a DOWN state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostsunreachable">$TOTALHOSTSUNREACHABLE$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently in an UNREACHABLE state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostsdownunhandled">$TOTALHOSTSDOWNUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently in a DOWN state that are not currently being "handled". Unhandled host problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostsunreachableunhandled">$TOTALHOSTSUNREACHABLEUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently in an UNREACHABLE state that are not currently being "handled". Unhandled host problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostproblems">$TOTALHOSTPROBLEMS$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently either in a DOWN or an UNREACHABLE state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalhostproblemsunhandled">$TOTALHOSTPROBLEMSUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of hosts that are currently either in a DOWN or an UNREACHABLE state that are not currently being "handled". Unhandled host problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalservicesok">$TOTALSERVICESOK$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in an OK state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalserviceswarning">$TOTALSERVICESWARNING$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in a WARNING state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalservicescritical">$TOTALSERVICESCRITICAL$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in a CRITICAL state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalservicesunknown">$TOTALSERVICESUNKNOWN$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in an UNKNOWN state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalserviceswarningunhandled">$TOTALSERVICESWARNINGUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in a WARNING state that are not currently being "handled". Unhandled services problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalservicescriticalunhandled">$TOTALSERVICESCRITICALUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in a CRITICAL state that are not currently being "handled". Unhandled services problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalservicesunknownunhandled">$TOTALSERVICESUNKNOWNUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently in an UNKNOWN state that are not currently being "handled". Unhandled services problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalserviceproblems">$TOTALSERVICEPROBLEMS$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently either in a WARNING, CRITICAL, or UNKNOWN state.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="totalserviceproblemsunhandled">$TOTALSERVICEPROBLEMSUNHANDLED$</a></td>
+
+<td class="MacroDescription">This macro reflects the total number of services that are currently either in a WARNING, CRITICAL, or UNKNOWN state that are not currently being "handled". Unhandled services problems are those that are not acknowledged, are not currently in scheduled downtime, and for which checks are currently enabled.</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Notification Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationtype">$NOTIFICATIONTYPE$</a></td>
+
+<td class="MacroDescription">A string identifying the type of notification that is being sent ("PROBLEM", "RECOVERY", "ACKNOWLEDGEMENT", "FLAPPINGSTART", "FLAPPINGSTOP", "FLAPPINGDISABLED", "DOWNTIMESTART", "DOWNTIMEEND", or "DOWNTIMECANCELLED").</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationrecipients">$NOTIFICATIONRECIPIENTS$</a></td>
+
+<td class="MacroDescription">A comma-separated list of the short names of all contacts that are being notified about the host or service.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationisescalated">$NOTIFICATIONISESCALATED$</a></td>
+
+<td class="MacroDescription">An integer indicating whether this was sent to normal contacts for the host or service or if it was escalated. 0 = Normal (non-escalated) notification , 1 = Escalated notification.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationauthor">$NOTIFICATIONAUTHOR$</a></td>
+
+<td class="MacroDescription">A string containing the name of the user who authored the notification. If the $NOTIFICATIONTYPE$ macro is set to "DOWNTIMESTART" or "DOWNTIMEEND", this will be the name of the user who scheduled downtime for the host or service. If the $NOTIFICATIONTYPE$ macro is "ACKNOWLEDGEMENT", this will be the name of the user who acknowledged the host or service problem. If the $NOTIFICATIONTYPE$ macro is "CUSTOM", this will be name of the user who initated the custom host or service notification.
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationauthorname">$NOTIFICATIONAUTHORNAME$</a></td>
+
+<td class="MacroDescription">A string containing the short name of the contact (if applicable) specified in the $NOTIFICATIONAUTHOR$ macro.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationauthoralias">$NOTIFICATIONAUTHORALIAS$</a></td>
+
+<td class="MacroDescription">A string containing the alias of the contact (if applicable) specified in the $NOTIFICATIONAUTHOR$ macro.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="notificationcomment">$NOTIFICATIONCOMMENT$</a></td>
+
+<td class="MacroDescription">A string containing the comment that was entered by the notification author. If the $NOTIFICATIONTYPE$ macro is set to "DOWNTIMESTART" or "DOWNTIMEEND", this will be the comment entered by the user who scheduled downtime for the host or service. If the $NOTIFICATIONTYPE$ macro is "ACKNOWLEDGEMENT", this will be the comment entered by the user who acknowledged the host or service problem. If the $NOTIFICATIONTYPE$ macro is "CUSTOM", this will be comment entered by the user who initated the custom host or service notification.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostnotificationnumber">$HOSTNOTIFICATIONNUMBER$</a></td>
+
+<td class="MacroDescription">The current notification number for the host. The notification number increases by one (1) each time a new notification is sent out for the host (except for acknowledgements). The notification number is reset to 0 when the host recovers (<i>after</i> the recovery notification has gone out). Acknowledgements do not cause the notification number to increase, nor do notifications dealing with flap detection or scheduled downtime.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostnotificationid">$HOSTNOTIFICATIONID$</a></td>
+
+<td class="MacroDescription">A unique number identifying a host notification. Notification ID numbers are unique across both hosts and service notifications, so you could potentially use this unique number as a primary key in a notification database. Notification ID numbers should remain unique across restarts of the Nagios process, so long as you have state retention enabled. The notification ID number is incremented by one (1) each time a new host notification is sent out, and regardless of how many contacts are notified.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicenotificationnumber">$SERVICENOTIFICATIONNUMBER$</a></td>
+
+<td class="MacroDescription">The current notification number for the service. The notification number increases by one (1) each time a new notification is sent out for the service (except for acknowledgements). The notification number is reset to 0 when the service recovers (<i>after</i> the recovery notification has gone out). Acknowledgements do not cause the notification number to increase, nor do notifications dealing with flap detection or scheduled downtime.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="servicenotificationid">$SERVICENOTIFICATIONID$</a></td>
+
+<td class="MacroDescription">A unique number identifying a service notification. Notification ID numbers are unique across both hosts and service notifications, so you could potentially use this unique number as a primary key in a notification database. Notification ID numbers should remain unique across restarts of the Nagios process, so long as you have state retention enabled. The notification ID number is incremented by one (1) each time a new service notification is sent out, and regardless of how many contacts are notified.</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Date/Time Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="longdatetime">$LONGDATETIME$</a></td>
+
+<td class="MacroDescription">Current date/time stamp (i.e. <i>Fri Oct 13 00:30:28 CDT 2000</i>). Format of date is determined by <a href="configmain.html#date_format">date_format</a> directive.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="shortdatetime">$SHORTDATETIME$</a></td>
+
+<td class="MacroDescription">Current date/time stamp (i.e. <i>10-13-2000 00:30:28</i>). Format of date is determined by <a href="configmain.html#date_format">date_format</a> directive.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="date">$DATE$</a></td>
+
+<td class="MacroDescription">Date stamp (i.e. <i>10-13-2000</i>). Format of date is determined by <a href="configmain.html#date_format">date_format</a> directive.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="time">$TIME$</a></td>
+
+<td class="MacroDescription">Current time stamp (i.e. <i>00:30:28</i>).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="timet">$TIMET$</a></td>
+
+<td class="MacroDescription">Current time stamp in time_t format (seconds since the UNIX epoch).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="isvalidtime">$ISVALIDTIME:$</a> <a href="#note9"><sup>9</sup></a></td>
+
+<td class="MacroDescription">
+
+<p>
+
+This is a special on-demand macro that returns a 1 or 0 depending on whether or not a particular time is valid within a specified timeperiod. There are two ways of using this macro:
+
+</p>
+
+<ol>
+
+<li><strong>$ISVALIDTIME:24x7$</strong> will be set to "1" if the current time is valid within the "24x7" timeperiod. If not, it will be set to "0".</li>
+
+<li><strong>$ISVALIDTIME:24x7:<i>timestamp</i>$</strong> will be set to "1" if the time specified by the "timestamp" argument (which must be in time_t format) is valid within the "24x7" timeperiod. If not, it will be set to "0".</li>
+
+</ol>
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="nextvalidtime">$NEXTVALIDTIME:$</a> <a href="#note9"><sup>9</sup></a></td>
+
+<td class="MacroDescription">
+
+<p>
+
+This is a special on-demand macro that returns the next valid time (in time_t format) for a specified timeperiod. There are two ways of using this macro:
+
+</p>
+
+<ol>
+
+<li><strong>$NEXTVALIDTIME:24x7$</strong> will return the next valid time - from and including the current time - in the "24x7" timeperiod.</li>
+
+<li><strong>$NEXTVALIDTIME:24x7:<i>timestamp</i>$</strong> will return the next valid time - from and including the time specified by the "timestamp" argument (which must be specified in time_t format) - in the "24x7" timeperiod.</li>
+
+</ol>
+
+<p>
+
+If a next valid time cannot be found in the specified timeperiod, the macro will be set to "0".
+
+</p>
+
+</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>File Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="mainconfigfile">$MAINCONFIGFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html">main config file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="statusdatafile">$STATUSDATAFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#status_file">status data file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="commentdatafile">$COMMENTDATAFILE$</a></td>
+
+<td class="MacroDescription">The location of the comment data file.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="downtimedatafile">$DOWNTIMEDATAFILE$</a></td>
+
+<td class="MacroDescription">The location of the downtime data file.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="retentiondatafile">$RETENTIONDATAFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#state_retention_file">retention data file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="objectcachefile">$OBJECTCACHEFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#object_cache_file">object cache file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="tempfile">$TEMPFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#temp_file">temp file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="temppath">$TEMPPATH$</a></td>
+
+<td class="MacroDescription">The directory specified by the <a href="configmain.html#temp_path">temp path</a> variable.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="logfile">$LOGFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#log_file">log file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="resourcefile">$RESOURCEFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#resource_file">resource file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="commandfile">$COMMANDFILE$</a></td>
+
+<td class="MacroDescription">The location of the <a href="configmain.html#command_file">command file</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="hostperfdatafile">$HOSTPERFDATAFILE$</a></td>
+
+<td class="MacroDescription">The location of the host performance data file (if defined).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="serviceperfdatafile">$SERVICEPERFDATAFILE$</a></td>
+
+<td class="MacroDescription">The location of the service performance data file (if defined).</td>
+
+</tr>
+
+
+
+<tr><td colspan='2'><br></td></tr>
+
+<tr>
+
+<td colspan='2' class='MacroType'>Misc Macros:</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="processstarttime">$PROCESSSTARTTIME$</a></td>
+
+<td class="MacroDescription">Time stamp in time_t format (seconds since the UNIX epoch) indicating when the Nagios process was last (re)started. You can determine the number of seconds that Nagios has been running (since it was last restarted) by subtracting $PROCESSSTARTTIME$ from <a href="#timet">$TIMET$</a>.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="eventstarttime">$EVENTSTARTTIME$</a></td>
+
+<td class="MacroDescription">Time stamp in time_t format (seconds since the UNIX epoch) indicating when the Nagios process starting process events (checks, etc.). You can determine the number of seconds that it took for Nagios to startup by subtracting $PROCESSSTARTTIME$ from $EVENTSTARTTIME$.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="adminemail">$ADMINEMAIL$</a></td>
+
+<td class="MacroDescription">Global administrative email address. This value is taken from the <a href="configmain.html#admin_email">admin_email</a> directive.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="adminpager">$ADMINPAGER$</a></td>
+
+<td class="MacroDescription">Global administrative pager number/address. This value is taken from the <a href="configmain.html#admin_pager">admin_pager</a> directive.</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="arg">$ARGn$</a></td>
+
+<td class="MacroDescription">The <i>n</i>th argument passed to the command (notification, event handler, service check, etc.). Nagios supports up to 32 argument macros ($ARG1$ through $ARG32$).</td>
+
+</tr>
+
+
+
+<tr>
+
+<td class="MacroName"><a name="user">$USERn$</a></td>
+
+<td class="MacroDescription">The <i>n</i>th user-definable macro. User macros can be defined in one or more <a href="configmain.html#resource_file">resource files</a>. Nagios supports up to 32 user macros ($USER1$ through $USER32$).</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<strong><u>Notes</u></strong>
+
+</p>
+
+
+
+<a name="note1"></a>
+
+<p>
+
+<sup><b>1</b></sup> These macros are not valid for the host they are associated with when that host is being checked (i.e. they make no sense, as they haven't been determined yet).
+
+</p>
+
+
+
+<a name="note2"></a>
+
+<p>
+
+<sup><b>2</b></sup> These macros are not valid for the service they are associated with when that service is being checked (i.e. they make no sense, as they haven't been determined yet).
+
+</p>
+
+
+
+<a name="note3"></a>
+
+<p>
+
+<sup><b>3</b></sup> When host macros are used in service-related commands (i.e. service notifications, event handlers, etc) they refer to they host that they service is associated with.
+
+</p>
+
+
+
+<a name="note4"></a>
+
+<p>
+
+<sup><b>4</b></sup> When host and service summary macros are used in notification commands, the totals are filtered to reflect only those hosts and services for which the contact is authorized (i.e. hosts and services they are configured to receive notifications for).
+
+</p>
+
+
+
+<a name="note5"></a>
+
+<p>
+
+<sup><b>5</b></sup> These macros are normally associated with the first/primary hostgroup associated with the current host. They could therefore be considered host macros in many cases. However, these macros are not available as on-demand host macros. Instead, they can be used as on-demand hostgroup macros when you pass the name of a hostgroup to the macro. For example: $HOSTGROUPMEMBERS:hg1$ would return a comma-delimited list of all (host) members of the hostgroup <i>hg1</i>.
+
+</p>
+
+
+
+<a name="note6"></a>
+
+<p>
+
+<sup><b>6</b></sup> These macros are normally associated with the first/primary servicegroup associated with the current service. They could therefore be considered service macros in many cases. However, these macros are not available as on-demand service macros. Instead, they can be used as on-demand servicegroup macros when you pass the name of a servicegroup to the macro. For example: $SERVICEGROUPMEMBERS:sg1$ would return a comma-delimited list of all (service) members of the servicegroup <i>sg1</i>.
+
+</p>
+
+
+
+<a name="note7"></a>
+
+<p>
+
+<sup><b>7</b></sup> These macros are normally associated with the first/primary contactgroup associated with the current contact. They could therefore be considered contact macros in many cases. However, these macros are not available as on-demand contact macros. Instead, they can be used as on-demand contactgroup macros when you pass the name of a contactgroup to the macro. For example: $CONTACTGROUPMEMBERS:cg1$ would return a comma-delimited list of all (contact) members of the contactgroup <i>cg1</i>.
+
+</p>
+
+
+
+<a name="note8"></a>
+
+<p>
+
+<sup><b>8</b></sup> These acknowledgement macros are deprecated. Use the more generic $NOTIFICATIONAUTHOR$, $NOTIFICATIONAUTHORNAME$, $NOTIFICATIONAUTHORALIAS$ or $NOTIFICATIONAUTHORCOMMENT$ macros instead.
+
+</p>
+
+
+
+<a name="note9"></a>
+
+<p>
+
+<sup><b>9</b></sup> These macro are only available as on-demand macros - e.g. you must supply an additional argument with them in order to use them. These macros are not available as environment variables.
+
+</p>
+
+
+
+<a name="note10"></a>
+
+<p>
+
+<sup><b>10</b></sup> Summary macros are not available as environment variables if the <a href="configmain.html#use_large_installation_tweaks">use_large_installation_tweaks</a> option is enabled, as they are quite CPU-intensive to calculate.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Understanding Macros and How They Work</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+
+
+ TH.Macros { font-family: verdana,arial,serif; font-size: 9pt; font-weight: bold; background-color: #cbcbcb; }
+
+ .MacroName { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold; }
+
+ .MacroDescription { font-family: verdana,arial,serif; font-size: 7pt; }
+
+ .MacroNo { font-family: verdana,arial,serif; font-size: 8pt; background-color: white; }
+
+ .MacroYes { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold; background-color: #00ff00; }
+
+ .MacroType { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold; background-color: #cbcbcb; }
+
+
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Understanding Macros and How They Work</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="macrolist.html">List of Available Macros</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+One of the main features that make Nagios so flexible is the ability to use macros in command defintions. Macros allow you to reference information from hosts, services, and other sources in your commands.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Macro Substitution - How Macros Work</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before Nagios executes a command, it will replace any macros it finds in the command definition with their corresponding values. This macro substitution occurs for all types of commands that Nagios executes - host and service checks, notifications, event handlers, etc.
+
+</p>
+
+
+
+<p>
+
+Certain macros may themselves contain other macros. These include the $HOSTNOTES$, $HOSTNOTESURL$, $HOSTACTIONURL$, $SERVICENOTES$, $SERVICENOTESURL$, and $SERVICEACTIONURL$ macros.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Example 1: Host Address Macro</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you use host and service macros in command definitions, they refer to values for the host or service for which the command is being run. Let's try an example. Assuming we are using a host definition and a <i>check_ping</i> command defined like this:
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ host_name linuxbox
+
+ address <font color="red">192.168.1.2</font>
+
+ check_command check_ping
+
+ ...
+
+ }
+
+
+
+define command{
+
+ command_name check_ping
+
+ command_line /usr/local/nagios/libexec/check_ping -H <font color="red">$HOSTADDRESS$</font> -w 100.0,90% -c 200.0,60%
+
+ }
+
+</pre>
+
+
+
+<p>
+
+the expanded/final command line to be executed for the host's check command would look like this:
+
+</p>
+
+
+
+<pre>
+
+ /usr/local/nagios/libexec/check_ping -H <font color="red">192.168.1.2</font> -w 100.0,90% -c 200.0,60%
+
+</pre>
+
+
+
+<p>
+
+Pretty simple, right? The beauty in this is that you can use a single command definition to check an unlimited number of hosts. Each host can be checked with the same command definition because each host's address is automatically substituted in the command line before execution.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Example 2: Command Argument Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can pass arguments to commands as well, which is quite handy if you'd like to keep your command definitions rather generic. Arguments are specified in the object (i.e. host or service) definition, by separating them from the command name with exclamation points (!) like so:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ host_name linuxbox
+
+ service_description PING
+
+ check_command check_ping!<font color="red">200.0,80%</font>!<font color="red">400.0,40%</font>
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In the example above, the service check command has two arguments (which can be referenced with <a href="macrolist.html#arg">$ARGn$</a> macros). The $ARG1$ macro will be "<font color="red">200.0,80%</font>" and $ARG2$ will be "<font color="red">400.0,40%</font>" (both without quotes). Assuming we are using the host definition given earlier and a <i>check_ping</i> command defined like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_ping
+
+ command_line /usr/local/nagios/libexec/check_ping -H <font color="red">$HOSTADDRESS$</font> -w <font color="red">$ARG1$</font> -c <font color="red">$ARG2$</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+the expanded/final command line to be executed for the service's check command would look like this:
+
+</p>
+
+
+
+<pre>
+
+ /usr/local/nagios/libexec/check_ping -H <font color="red">192.168.1.2</font> -w <font color="red">200.0,80%</font> -c <font color="red">400.0,40%</font>
+
+</pre>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="middle" alt="Tip" title="Tip">Tip: If you need to pass bang (!) characters in your command arguments, you can do so by escaping them with a backslash (\). If you need to include backslashes in your command arguments, they should also be escaped with a backslash.
+
+</p>
+
+
+
+<p>
+
+<strong><u>On-Demand Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+Normally when you use host and service macros in command definitions, they refer to values for the host or service for which the command is being run. For instance, if a host check command is being executed for a host named "linuxbox", all the <a href="macrolist.html">standard host macros</a> will refer to values for that host ("linuxbox").
+
+</p>
+
+
+
+<p>
+
+If you would like to reference values for another host or service in a command (for which the command is not being run), you can use what are called "on-demand" macros. On-demand macros look like normal macros, except for the fact that they contain an identifier for the host or service from which they should get their value. Here's the basic format for on-demand macros:
+
+</p>
+
+
+
+<ul>
+
+<li>$<i>HOSTMACRONAME</i>:<i>host_name</i>$</li>
+
+<li>$<i>SERVICEMACRONAME</i>:<i>host_name</i>:<i>service_description</i>$</li>
+
+</ul>
+
+
+
+<p>
+
+Replace <i>HOSTMACRONAME</i> and <i>SERVICEMACRONAME</i> with the name of one of the standard host of service macros found <a href="macrolist.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+Note that the macro name is separated from the host or service identifier by a colon (:). For on-demand service macros, the service identifier consists of both a host name and a service description - these are separated by a colon (:) as well.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="middle" alt="Tip" title="Tip"> Tip: On-demand service macros can contain an empty host name field. In this case the name of the host associated with the service will automatically be used.
+
+</p>
+
+
+
+<p>
+
+Examples of on-demand host and service macros follow:
+
+</p>
+
+
+
+<pre>
+
+$HOSTDOWNTIME:myhost$ <--- On-demand host macro
+
+$SERVICESTATEID:novellserver:DS Database$ <--- On-demand service macro
+
+$SERVICESTATEID::CPU Load$ <--- On-demand service macro with blank host name field
+
+</pre>
+
+
+
+<p>
+
+On-demand macros are also available for hostgroup, servicegroup, contact, and contactgroup macros. For example:
+
+</p>
+
+
+
+<pre>
+
+$CONTACTEMAIL:john$ <--- On-demand contact macro
+
+$CONTACTGROUPMEMBERS:linux-admins$ <--- On-demand contactgroup macro
+
+$HOSTGROUPALIAS:linux-servers$ <--- On-demand hostgroup macro
+
+$SERVICEGROUPALIAS:DNS-Cluster$ <--- On-demand servicegroup macro
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>On-Demand Group Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can obtain the values of a macro across all contacts, hosts, or services in a specific group by using a special format for your on-demand macro declaration. You do this by referencing a specific host group, service group, or contact group name in an on-demand macro, like so:
+
+</p>
+
+
+
+<ul>
+
+<li>$<i>HOSTMACRONAME</i>:<i>hostgroup_name</i>:<i>delimiter</i>$</li>
+
+<li>$<i>SERVICEMACRONAME</i>:<i>servicegroup_name</i>:<i>delimiter</i>$</li>
+
+<li>$<i>CONTACTMACRONAME</i>:<i>contactgroup_name</i>:<i>delimiter</i>$</li>
+
+</ul>
+
+
+
+<p>
+
+Replace <i>HOSTMACRONAME</i>, <i>SERVICEMACRONAME</i>, and <i>CONTACTMACRONAME</i> with the name of one of the standard host, service, or contact macros found <a href="macrolist.html">here</a>. The delimiter you specify is used to separate macro values for each group member.
+
+</p>
+
+
+
+<p>
+
+For example, the following macro will return a comma-separated list of host state ids for hosts that are members of the <i>hg1</i> hostgroup:
+
+</p>
+
+
+
+<pre>
+
+$HOSTSTATEID:hg1:,$
+
+</pre>
+
+
+
+<p>
+
+This macro definition will return something that looks like this:
+
+</p>
+
+
+
+<pre>
+
+0,2,1,1,0,0,2
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Custom Variable Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+Any <a href="customobjectvars.html">custom object variables</a> that you define in host, service, or contact definitions are also available as macros. Custom variable macros are named as follows:
+
+</p>
+
+
+
+<ul>
+
+<li>$_HOST<i>varname</i>$</li>
+
+<li>$_SERVICE<i>varname</i>$</li>
+
+<li>$_CONTACT<i>varname</i>$</li>
+
+</ul>
+
+
+
+<p>
+
+Take the following host definition with a custom variable called "_MACADDRESS"...
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ host_name linuxbox
+
+ address 192.168.1.1
+
+ <font color="red">_MACADDRESS 00:01:02:03:04:05</font>
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+The _MACADDRESS custom variable would be available in a macro called <font color="red">$_HOSTMACADDRESS$</font>. More information on custom object variables and how they can be used in macros can be found <a href="customobjectvars.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Macro Cleansing</u></strong>
+
+</p>
+
+
+
+<p>
+
+Some macros are stripped of potentially dangerous shell metacharacters before being substituted into commands to be executed. Which characters are stripped from the macros depends on the setting of the <a href="configmain.html#illegal_macro_output_chars">illegal_macro_output_chars</a> directive. The following macros are stripped of potentially dangerous characters:
+
+</p>
+
+
+
+<ol>
+
+<li><a href="macrolist.html#hostoutput">$HOSTOUTPUT$</a>
+
+<li><a href="macrolist.html#longhostoutput">$LONGHOSTOUTPUT$</a>
+
+<li><a href="macrolist.html#hostperfdata">$HOSTPERFDATA$</a>
+
+<li><a href="macrolist.html#hostackauthor">$HOSTACKAUTHOR$</a>
+
+<li><a href="macrolist.html#hostackcomment">$HOSTACKCOMMENT$</a>
+
+<li><a href="macrolist.html#serviceoutput">$SERVICEOUTPUT$</a>
+
+<li><a href="macrolist.html#longserviceoutput">$LONGSERVICEOUTPUT$</a>
+
+<li><a href="macrolist.html#serviceperfdata">$SERVICEPERFDATA$</a>
+
+<li><a href="macrolist.html#serviceackauthor">$SERVICEACKAUTHOR$</a>
+
+<li><a href="macrolist.html#serviceackcomment">$SERVICEACKCOMMENT$</a>
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Macros as Environment Variables</u></strong>
+
+</p>
+
+
+
+<p>
+
+Most macros are made available as environment variables for easy reference by scripts or commands that are executed by Nagios. For purposes of security and sanity, <a href="macrolist.html#user">$USERn$</a> and "on-demand" host and service macros are <u>not</u> made available as environment variables.
+
+</p>
+
+<p>
+
+Environment variables that contain standard macros are named the same as their corresponding macro names (listed <a href="macrolist.html">here</a>), with "NAGIOS_" prepended to their names. For example, the <a href="macrolist.html#hostname">$HOSTNAME$</a> macro would be available as an environment variable named "NAGIOS_HOSTNAME".
+
+</p>
+
+
+
+<p>
+
+<strong><u>Available Macros</u></strong>
+
+</p>
+
+
+
+<p>
+
+A list of all the macros that are available in Nagios, as well as a chart of when they can be used, can be found <a href="macrolist.html">here</a>.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Linux/Unix Machines</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Linux/Unix Machines</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guide</a>, <a href="monitoring-publicservices.html">Monitoring Publicly Available Services</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This document describes how you can monitor "private" services and attributes of Linux/UNIX servers, such as:
+
+</p>
+
+
+
+<ul>
+
+<li>CPU load</li>
+
+<li>Memory usage</li>
+
+<li>Disk usage</li>
+
+<li>Logged in users</li>
+
+<li>Running processes</li>
+
+<li>etc.</li>
+
+</ul>
+
+
+
+<p>
+
+Publicly available services that are provided by Linux servers (HTTP, FTP, SSH, SMTP, etc.) can be monitored easily by following the documentation on <a href="monitoring-publicservices.html">monitoring publicly available services</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: These instructions assume that you've installed Nagios according to the <a href="quickstart.html">quickstart guide</a>. The sample configuration entries below reference objects that are defined in the sample config files (<i>commands.cfg</i>, <i>templates.cfg</i>, etc.) that are installed if you follow the quickstart.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Overview</u></strong>
+
+</p>
+
+
+
+<p>
+
+[Note: This document has not been completed. I would recommend you read the documentation on the <a href="addons.html#nrpe">NRPE addon</a> for instructions on how to monitor a remote Linux/Unix server.]
+
+</p>
+
+
+
+<p>
+
+There are several different ways to monitor attributes or remote Linux/Unix servers. One is by using shared SSH keys and the <i>check_by_ssh</i> plugin to execute plugins on remote servers. This method will not be covered here, but can result in high load on your monitoring server if you are monitoring hundreds or thousands of services. The overhead of setting up/destroying SSH connections is the cause of this.
+
+</p>
+
+
+
+<img src="images/nrpe.png" border="0" alt="NRPE" title="NRPE" style="float: right; clear: both;">
+
+
+
+<p>
+
+Another common method of monitoring remote Linux/Unix hosts is to use the <a href="addons.html#nrpe">NRPE addon</a>. NRPE allows you to execute plugins on remote Linux/Unix hosts. This is useful if you need to monitor local resources/attributes like disk usage, CPU load, memory usage, etc. on a remote host.
+
+</p>
+
+
+
+<br clear="all">
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Netware Servers</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Netware Servers</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guide</a>, <a href="monitoring-publicservices.html">Monitoring Publicly Available Services</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This document provides information on how you can monitor Novell Netware servers.
+
+</p>
+
+
+
+<p>
+
+<strong><u>External Resources</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can find documentation on monitoring Netware servers with Nagios at Novell's <a href="http://www.novell.com/coolsolutions/">Cool Solutions</a> site, including:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="http://developer.novell.com/wiki/index.php/MRTGEXT">MRTGEXT: NLM module for MRTG and Nagios</a></li>
+
+<li><a href="http://www.novell.com/coolsolutions/feature/16723.html">Nagios: Host and Service Monitoring Tool</a></li>
+
+<li><a href="http://www.novell.com/coolsolutions/appnote/17494.html">Nagios and NetWare: SNMP-based Monitoring</a></li>
+
+<li><a href="http://www.novell.com/coolsolutions/tools/17255.html">Monitor DirXML/IDM Driver States with Nagios</a></li>
+
+<li><a href="http://www.novell.com/coolsolutions/tools/17038.html">Check NDS Login ability with Nagios</a></li>
+
+<li><a href="http://www.novell.com/coolsolutions/tools/17580.html">NDPS/iPrint Print Queue Monitoring by Nagios</a></li>
+
+<li><a href="http://www.novell.com/coolsolutions/tools/16935.html">check_gwiaRL Plugin for Nagios 2.0</a></li>
+
+</ul>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: When you visit Novell's <a href="http://www.novell.com/coolsolutions/">Cool Solutions</a> site, search for "Nagios" to find more articles and software components related to monitoring.
+
+</p>
+
+
+
+<p>
+
+Thanks to <a href="http://www.novell.com/coolsolutions/author/1301.html">Christian Mies</a>, <a href="http://www.novell.com/coolsolutions/author/1525.html">Rainer Brunold</a>, and others for contributing Nagios and Netware documentation, addons, etc. on the Novell site!
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Network Printers</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Network Printers</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="monitoring-publicservices.html">Monitoring Publicly Available Services</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/printer.png" border="0" style="float: right" alt="Printer">
+
+
+
+<p>
+
+This document describes how you can monitor the status of networked printers. Specifically, HP printers that have internal/external JetDirect cards/devices, or other print servers (like the Troy PocketPro 100S or the Netgear PS101) that support the JetDirect protocol.
+
+</p>
+
+
+
+<p>
+
+The <i>check_hpjd</i> plugin (which is part of the standard Nagios plugins distribution) allows you to monitor the status of JetDirect-capable printers which have SNMP enabled. The plugin is capable of detecting the following printer states:
+
+</p>
+
+
+
+<ul>
+
+<li>Paper Jam</li>
+
+<li>Out of Paper</li>
+
+<li>Printer Offline</li>
+
+<li>Intervention Required</li>
+
+<li>Toner Low</li>
+
+<li>Insufficient Memory</li>
+
+<li>Open Door</li>
+
+<li>Output Tray is Full</li>
+
+<li>and more...</li>
+
+</ul>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: These instructions assume that you've installed Nagios according to the <a href="quickstart.html">quickstart guide</a>. The sample configuration entries below reference objects that are defined in the sample config files (<i>commands.cfg</i>, <i>templates.cfg</i>, etc.) that are installed if you follow the quickstart.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Overview</u></strong>
+
+</p>
+
+
+
+<img src="images/monitoring-printers.png" border="0" alt="Monitoring a Network Printer" title="Monitoring a Network Printer" style="float: right;">
+
+
+
+<p>
+
+Monitoring the status of a networked printer is pretty simple. JetDirect-enabled printers usually have SNMP enabled, which allows Nagios to monitor their status using the <i>check_hpjd</i> plugin.
+
+</p>
+
+
+
+<p>
+
+The <i>check_hpjd</i> plugin will only get compiled and installed if you have the net-snmp and net-snmp-utils packages installed on your system. Make sure the plugin exists in <i>/usr/local/nagios/libexec</i> before you continue. If it doesn't, install net-snmp and net-snmp-utils and recompile/reinstall the Nagios plugins.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Steps</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are several steps you'll need to follow in order to monitor a new network printer. They are:
+
+</p>
+
+
+
+<ol>
+
+<li>Perform first-time prerequisites</li>
+
+<li>Create new host and service definitions for monitoring the printer</li>
+
+<li>Restart the Nagios daemon</li>
+
+</ol>
+
+
+
+
+
+<p>
+
+<strong><u>What's Already Done For You</u></strong>
+
+</p>
+
+
+
+<p>
+
+To make your life a bit easier, a few configuration tasks have already been done for you:
+
+</p>
+
+
+
+<ul>
+
+<li>A <i>check_hpjd</i> command definition has been added to the <i>commands.cfg</i> file. This allows you to use the <i>check_hpjd</i> plugin to monitor network printers.</li>
+
+<li>A printer host template (called <i>generic-printer</i>) has already been created in the <i>templates.cfg</i> file. This allows you to add new printer host definitions in a simple manner.</li>
+
+</ul>
+
+
+
+<p>
+
+The above-mentioned config files can be found in the <i>/usr/local/nagios/etc/objects/</i> directory. You can modify the definitions in these and other definitions to suit your needs better if you'd like. However, I'd recommend waiting until you're more familiar with configuring Nagios before doing so. For the time being, just follow the directions outlined below and you'll be monitoring your network printers in no time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Prerequisites</u></strong>
+
+</p>
+
+
+
+<p>
+
+The first time you configure Nagios to monitor a network printer, you'll need to do a bit of extra work. Remember, you only need to do this for the *first* printer you monitor.
+
+</p>
+
+
+
+<p>
+
+Edit the main Nagios config file.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+Remove the leading pound (#) sign from the following line in the main configuration file:
+
+</p>
+
+
+
+<pre>
+
+#cfg_file=/usr/local/nagios/etc/objects/printer.cfg
+
+</pre>
+
+
+
+<p>
+
+Save the file and exit.
+
+</p>
+
+
+
+<p>
+
+What did you just do? You told Nagios to look to the <i>/usr/local/nagios/etc/objects/printer.cfg</i> to find additional object definitions. That's where you'll be adding host and service definitions for the printer. That configuration file already contains some sample host, hostgroup, and service definitions. For the *first* printer you monitor, you can simply modify the sample host and service definitions in that file, rather than creating new ones.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Configuring Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+You'll need to create some <a href="objectdefinitions.html">object definitions</a> in order to monitor a new printer.
+
+</p>
+
+
+
+<p>
+
+Open the <i>printer.cfg</i> file for editing.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/printer.cfg
+
+</pre>
+
+
+
+<p>
+
+Add a new <a href="objectdefinitions.html#host">host</a> definition for the networked printer that you're going to monitor. If this is the *first* printer you're monitoring, you can simply modify the sample host definition in <i>printer.cfg</i>. Change the <i>host_name</i>, <i>alias</i>, and <i>address</i> fields to appropriate values for the printer.
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ use generic-printer ; Inherit default values from a template
+
+ host_name hplj2605dn ; The name we're giving to this printer
+
+ alias HP LaserJet 2605dn ; A longer name associated with the printer
+
+ address 192.168.1.30 ; IP address of the printer
+
+ hostgroups allhosts ; Host groups this printer is associated with
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now you can add some service definitions (to the same configuration file) to monitor different aspects of the printer. If this is the *first* printer you're monitoring, you can simply modify the sample service definition in <i>printer.cfg</i>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Replace "<i>hplj2605dn</i>" in the example definitions below with the name you specified in the <i>host_name</i> directive of the host definition you just added.
+
+</p>
+
+
+
+<p>
+
+Add the following service definition to check the status of the printer. The service uses the <i>check_hpjd</i> plugin to check the status of the printer every 10 minutes by default. The SNMP community string used to query the printer is "public" in this example.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit values from a template
+
+ host_name hplj2605dn ; The name of the host the service is associated with
+
+ service_description Printer Status ; The service description
+
+ check_command check_hpjd!-C public ; The command used to monitor the service
+
+ normal_check_interval 10 ; Check the service every 10 minutes under normal conditions
+
+ retry_check_interval 1 ; Re-check the service every minute until its final/hard state is determined
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Add the following service definition to ping the printer every 10 minutes by default. This is useful for monitoring RTA, packet loss, and general network connectivity.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name hplj2605dn
+
+ service_description PING
+
+ check_command check_ping!3000.0,80%!5000.0,100%
+
+ normal_check_interval 10
+
+ retry_check_interval 1
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Save the file.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Restarting Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Once you've added the new host and service definitions to the <i>printer.cfg</i> file, you're ready to start monitoring the printer. To do this, you'll need to <a href="verifyconfig.html">verify your configuration</a> and <a href="startstop.html">restart Nagios</a>.
+
+</p>
+
+
+
+<p>
+
+If the verification process produces any errors messages, fix your configuration file before continuing. Make sure that you don't (re)start Nagios until the verification process completes without any errors!
+
+</p>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Publicly Available Services</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Publicly Available Services</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guide</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This document describes how you can monitor publicly available services, applications and protocols. By "public" I mean services that are accessible across the network - either the local network or the greater Internet. Examples of public services include HTTP, POP3, IMAP, FTP, and SSH. There are many more public services that you probably use on a daily basis. These services and applications, as well as their underlying protocols, can usually be monitored by Nagios without any special access requirements.
+
+</p>
+
+
+
+<p>
+
+Private services, in contrast, cannot be monitored with Nagios without an intermediary agent of some kind. Examples of private services associated with hosts are things like CPU load, memory usage, disk usage, current user count, process information, etc. These private services or attributes of hosts are not usually exposed to external clients. This situation requires that an intermediary monitoring agent be installed on any host that you need to monitor such information on. More information on monitoring private services on different types of hosts can be found in the documentation on:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="monitoring-windows.html">Monitoring Windows machines</a></li>
+
+<li><a href="monitoring-netware.html">Monitoring Netware servers</a></li>
+
+<li><a href="monitoring-linux.html">Monitoring Linux/Unix machines</a></li>
+
+</ul>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: Occassionally you will find that information on private services and applications can be monitored with SNMP. The SNMP agent allows you to remotely monitor otherwise private (and inaccessible) information about the host. For more information about monitoring services using SNMP, check out the documentation on <a href="monitoring-routers.html">monitoring switches and routers</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: These instructions assume that you've installed Nagios according to the <a href="quickstart.html">quickstart guide</a>. The sample configuration entries below reference objects that are defined in the sample <i>commands.cfg</i> and <i>localhost.cfg</i> config files.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Plugins For Monitoring Services</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you find yourself needing to monitor a particular application, service, or protocol, chances are good that a <a href="plugins.html">plugin</a> exists to monitor it. The official Nagios plugins distribution comes with plugins that can be used to monitor a variety of services and protocols. There are also a large number of contributed plugins that can be found in the <i>contrib/</i> subdirectory of the plugin distribution. The <a href="http://www.nagiosexchange.org">NagiosExchange.org</a> website hosts a number of additional plugins that have been written by users, so check it out when you have a chance.
+
+</p>
+
+
+
+<p>
+
+If you don't happen to find an appropriate plugin for monitoring what you need, you can always write your own. Plugins are easy to write, so don't let this thought scare you off. Read the documentation on <a href="pluginapi.html">developing plugins</a> for more information.
+
+</p>
+
+
+
+<p>
+
+I'll walk you through monitoring some basic services that you'll probably use sooner or later. Each of these services can be monitored using one of the plugins that gets installed as part of the Nagios plugins distribution. Let's get started...
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Creating A Host Definition</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before you can monitor a service, you first need to define a <a href="objectdefinitions.html#host">host</a> that is associated with the service. You can place host definitions in any object configuration file specified by a <a href="configmain.html#cfg_file">cfg_file</a> directive or placed in a directory specified by a <a href="configmain.html#cfg_dir">cfg_dir</a> directive. If you have already created a host definition, you can skip this step.
+
+</p>
+
+
+
+<p>
+
+For this example, lets say you want to monitor a variety of services on a remote host. Let's call that host <i>remotehost</i>. The host definition can be placed in its own file or added to an already exiting object configuration file. Here's what the host definition for <i>remotehost</i> might look like:
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ use generic-host ; Inherit default values from a template
+
+ host_name remotehost ; The name we're giving to this host
+
+ alias Some Remote Host ; A longer name associated with the host
+
+ address 192.168.1.50 ; IP address of the host
+
+ hostgroups allhosts ; Host groups this host is associated with
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now that a definition has been added for the host that will be monitored, we can start defining services that should be monitored. As with host definitions, service definitions can be placed in any object configuration file.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Creating Service Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+For each service you want to monitor, you need to define a <a href="objectdefinitions.html#service">service</a> in Nagios that is associated with the host definition you just created. You can place service definitions in any object configuration file specified by a <a href="configmain.html#cfg_file">cfg_file</a> directive or placed in a directory specified by a <a href="configmain.html#cfg_dir">cfg_dir</a> directive.
+
+</p>
+
+
+
+<p>
+
+Some example service definitions for monitoring common public service (HTTP, FTP, etc.) are given below.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Monitoring HTTP</u></strong>
+
+</p>
+
+
+
+<p>
+
+Chances are you're going to want to monitor web servers at some point - either yours or someone else's. The <i>check_http</i> plugin is designed to do just that. It understands the HTTP protocol and can monitor response time, error codes, strings in the returned HTML, server certificates, and much more.
+
+</p>
+
+
+
+<p>
+
+The <i>commands.cfg</i> file contains a command definition for using the <i>check_http</i> plugin. It looks like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ name check_http
+
+ command_name check_http
+
+ command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+A simple service definition for monitoring the HTTP service on the <i>remotehost</i> machine might look like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description HTTP
+
+ check_command check_http
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This simple service definition will monitor the HTTP service running on <i>remotehost</i>. It will produce alerts if the web server doesn't respond within 10 seconds or if it returns HTTP errors codes (403, 404, etc.). That's all you need for basic monitoring. Pretty simple, huh?
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: For more advanced monitoring, run the <i>check_http</i> plugin manually with <i>--help</i> as a command-line argument to see all the options you can give the plugin. This <i>--help</i> syntax works with all of the plugins I'll cover in this document.
+
+</p>
+
+
+
+<p>
+
+A more advanced definition for monitoring the HTTP service is shown below. This service definition will check to see if the /download/index.php URI contains the string "latest-version.tar.gz". It will produce an error if the string isn't found, the URI isn't valid, or the web server takes longer than 5 seconds to respond.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description Product Download Link
+
+ check_command check_http!-u /download/index.php -t 5 -s "latest-version.tar.gz"
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring FTP</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you need to monitor FTP servers, you can use the <i>check_ftp</i> plugin. The <i>commands.cfg</i> file contains a command definition for using the <i>check_ftp</i> plugin, which looks like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_ftp
+
+ command_line $USER1$/check_ftp -H $HOSTADDRESS$ $ARG1$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+A simple service definition for monitoring the FTP server on <i>remotehost</i> would look like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description FTP
+
+ check_command check_ftp
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This service definition will monitor the FTP service and generate alerts if the FTP server doesn't respond within 10 seconds.
+
+</p>
+
+
+
+<p>
+
+A more advanced service definition is shown below. This service will check the FTP server running on port 1023 on <i>remotehost</i>. It will generate an alert if the server doesn't respond within 5 seconds or if the server response doesn't contain the string "Pure-FTPd [TLS]".
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description Special FTP
+
+ check_command check_ftp!-p 1023 -t 5 -e "Pure-FTPd [TLS]"
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring SSH</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you need to monitor SSH servers, you can use the <i>check_ssh</i> plugin. The <i>commands.cfg</i> file contains a command definition for using the <i>check_ssh</i> plugin, which looks like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_ssh
+
+ command_line $USER1$/check_ssh $ARG1$ $HOSTADDRESS$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+A simple service definition for monitoring the SSH server on <i>remotehost</i> would look like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description SSH
+
+ check_command check_ssh
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This service definition will monitor the SSH service and generate alerts if the SSH server doesn't respond within 10 seconds.
+
+</p>
+
+
+
+<p>
+
+A more advanced service definition is shown below. This service will check the SSH server and generate an alert if the server doesn't respond within 5 seconds or if the server version string string doesn't match "OpenSSH_4.2".
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description SSH Version Check
+
+ check_command check_ssh!-t 5 -r "OpenSSH_4.2"
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring SMTP</u></strong>
+
+</p>
+
+
+
+<p>
+
+The <i>check_smtp</i> plugin can be using for monitoring your email servers. The <i>commands.cfg</i> file contains a command definition for using the <i>check_smtp</i> plugin, which looks like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_smtp
+
+ command_line $USER1$/check_smtp -H $HOSTADDRESS$ $ARG1$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+A simple service definition for monitoring the SMTP server on <i>remotehost</i> would look like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description SMTP
+
+ check_command check_smtp
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This service definition will monitor the SMTP service and generate alerts if the SMTP server doesn't respond within 10 seconds.
+
+</p>
+
+
+
+<p>
+
+A more advanced service definition is shown below. This service will check the SMTP server and generate an alert if the server doesn't respond within 5 seconds or if the response from the server doesn't contain "mygreatmailserver.com".
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description SMTP Response Check
+
+ check_command check_smtp!-t 5 -e "mygreatmailserver.com"
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring POP3</u></strong>
+
+</p>
+
+
+
+<p>
+
+The <i>check_pop</i> plugin can be using for monitoring the POP3 service on your email servers. The <i>commands.cfg</i> file contains a command definition for using the <i>check_pop</i> plugin, which looks like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_pop
+
+ command_line $USER1$/check_pop -H $HOSTADDRESS$ $ARG1$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+A simple service definition for monitoring the POP3 service on <i>remotehost</i> would look like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description POP3
+
+ check_command check_pop
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This service definition will monitor the POP3 service and generate alerts if the POP3 server doesn't respond within 10 seconds.
+
+</p>
+
+
+
+<p>
+
+A more advanced service definition is shown below. This service will check the POP3 service and generate an alert if the server doesn't respond within 5 seconds or if the response from the server doesn't contain "mygreatmailserver.com".
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description POP3 Response Check
+
+ check_command check_pop!-t 5 -e "mygreatmailserver.com"
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring IMAP</u></strong>
+
+</p>
+
+
+
+<p>
+
+The <i>check_imap</i> plugin can be using for monitoring IMAP4 service on your email servers. The <i>commands.cfg</i> file contains a command definition for using the <i>check_imap</i> plugin, which looks like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_imap
+
+ command_line $USER1$/check_imap -H $HOSTADDRESS$ $ARG1$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+A simple service definition for monitoring the IMAP4 service on <i>remotehost</i> would look like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description IMAP
+
+ check_command check_imap
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This service definition will monitor the IMAP4 service and generate alerts if the IMAP server doesn't respond within 10 seconds.
+
+</p>
+
+
+
+<p>
+
+A more advanced service definition is shown below. This service will check the IMAP4 service and generate an alert if the server doesn't respond within 5 seconds or if the response from the server doesn't contain "mygreatmailserver.com".
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit default values from a template
+
+ host_name remotehost
+
+ service_description IMAP4 Response Check
+
+ check_command check_imap!-t 5 -e "mygreatmailserver.com"
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>Restarting Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Once you've added the new host and service definitions to your object configuration file(s), you're ready to start monitoring them. To do this, you'll need to <a href="verifyconfig.html">verify your configuration</a> and <a href="startstop.html">restart Nagios</a>.
+
+</p>
+
+
+
+<p>
+
+If the verification process produces any errors messages, fix your configuration file before continuing. Make sure that you don't (re)start Nagios until the verification process completes without any errors!
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Routers and Switches</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Routers and Switches</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="monitoring-publicservices.html">Monitoring Publicly Available Services</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/switch.png" border="0" style="float: right" alt="Switch">
+
+
+
+<p>
+
+This document describes how you can monitor the status of network switches and routers. Some cheaper "unmanaged" switches and hubs don't have IP addresses and are essentially invisible on your network, so there's not any way to monitor them. More expensive switches and routers have addresses assigned to them and can be monitored by pinging them or using SNMP to query status information.
+
+</p>
+
+
+
+<p>
+
+I'll describe how you can monitor the following things on managed switches, hubs, and routers:
+
+</p>
+
+
+
+<ul>
+
+<li>Packet loss, round trip average</li>
+
+<li>SNMP status information</li>
+
+<li>Bandwidth / traffic rate</li>
+
+</ul>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: These instructions assume that you've installed Nagios according to the <a href="quickstart.html">quickstart guide</a>. The sample configuration entries below reference objects that are defined in the sample config files (<i>commands.cfg</i>, <i>templates.cfg</i>, etc.) that are installed when you follow the quickstart.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Overview</u></strong>
+
+</p>
+
+
+
+<img src="images/monitoring-routers.png" border="0" alt="Monitoring a Router or Switch" title="Monitoring a Router or Switch" style="float: right;">
+
+
+
+<p>
+
+Monitoring switches and routers can either be easy or more involved - depending on what equipment you have and what you want to monitor. As they are critical infrastructure components, you'll no doubt want to monitor them in at least some basic manner.
+
+</p>
+
+
+
+<p>
+
+Switches and routers can be monitored easily by "pinging" them to determine packet loss, RTA, etc. If your switch supports SNMP, you can monitor port status, etc. with the <i>check_snmp</i> plugin and bandwidth (if you're using MRTG) with the <i>check_mrtgtraf</i> plugin.
+
+</p>
+
+
+
+<p>
+
+The <i>check_snmp</i> plugin will only get compiled and installed if you have the net-snmp and net-snmp-utils packages installed on your system. Make sure the plugin exists in <i>/usr/local/nagios/libexec</i> before you continue. If it doesn't, install net-snmp and net-snmp-utils and recompile/reinstall the Nagios plugins.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Steps</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are several steps you'll need to follow in order to monitor a new router or switch. They are:
+
+</p>
+
+
+
+<ol>
+
+<li>Perform first-time prerequisites</li>
+
+<li>Create new host and service definitions for monitoring the device</li>
+
+<li>Restart the Nagios daemon</li>
+
+</ol>
+
+
+
+
+
+<p>
+
+<strong><u>What's Already Done For You</u></strong>
+
+</p>
+
+
+
+<p>
+
+To make your life a bit easier, a few configuration tasks have already been done for you:
+
+</p>
+
+
+
+<ul>
+
+<li>Two command definitions (<i>check_snmp</i> and <i>check_local_mrtgtraf</i>) have been added to the <i>commands.cfg</i> file. These allows you to use the <i>check_snmp</i> and <i>check_mrtgtraf</i> plugins to monitor network routers.</li>
+
+<li>A switch host template (called <i>generic-switch</i>) has already been created in the <i>templates.cfg</i> file. This allows you to add new router/switch host definitions in a simple manner.</li>
+
+</ul>
+
+
+
+<p>
+
+The above-mentioned config files can be found in the <i>/usr/local/nagios/etc/objects/</i> directory. You can modify the definitions in these and other definitions to suit your needs better if you'd like. However, I'd recommend waiting until you're more familiar with configuring Nagios before doing so. For the time being, just follow the directions outlined below and you'll be monitoring your network routers/switches in no time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Prerequisites</u></strong>
+
+</p>
+
+
+
+<p>
+
+The first time you configure Nagios to monitor a network switch, you'll need to do a bit of extra work. Remember, you only need to do this for the *first* switch you monitor.
+
+</p>
+
+
+
+<p>
+
+Edit the main Nagios config file.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+Remove the leading pound (#) sign from the following line in the main configuration file:
+
+</p>
+
+
+
+<pre>
+
+#cfg_file=/usr/local/nagios/etc/objects/switch.cfg
+
+</pre>
+
+
+
+<p>
+
+Save the file and exit.
+
+</p>
+
+
+
+<p>
+
+What did you just do? You told Nagios to look to the <i>/usr/local/nagios/etc/objects/switch.cfg</i> to find additional object definitions. That's where you'll be adding host and service definitions for routers and switches. That configuration file already contains some sample host, hostgroup, and service definitions. For the *first* router/switch you monitor, you can simply modify the sample host and service definitions in that file, rather than creating new ones.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Configuring Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+You'll need to create some <a href="objectdefinitions.html">object definitions</a> in order to monitor a new router/switch. </p>
+
+
+
+<p>
+
+Open the <i>switch.cfg</i> file for editing.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/switch.cfg
+
+</pre>
+
+
+
+<p>
+
+Add a new <a href="objectdefinitions.html#host">host</a> definition for the switch that you're going to monitor. If this is the *first* switch you're monitoring, you can simply modify the sample host definition in <i>switch.cfg</i>. Change the <i>host_name</i>, <i>alias</i>, and <i>address</i> fields to appropriate values for the switch.
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ use generic-switch ; Inherit default values from a template
+
+ host_name linksys-srw224p ; The name we're giving to this switch
+
+ alias Linksys SRW224P Switch ; A longer name associated with the switch
+
+ address 192.168.1.253 ; IP address of the switch
+
+ hostgroups allhosts,switches ; Host groups this switch is associated with
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Monitoring Services</u></strong>
+
+</p>
+
+
+
+<p>
+
+Now you can add some service definitions (to the same configuration file) to monitor different aspects of the switch. If this is the *first* switch you're monitoring, you can simply modify the sample service definition in <i>switch.cfg</i>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Replace "<i>linksys-srw224p</i>" in the example definitions below with the name you specified in the <i>host_name</i> directive of the host definition you just added.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Monitoring Packet Loss and RTA</u></strong>
+
+</p>
+
+
+
+<p>
+
+Add the following service definition in order to monitor packet loss and round trip average between the Nagios host and the switch every 5 minutes under normal conditions.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit values from a template
+
+ host_name linksys-srw224p ; The name of the host the service is associated with
+
+ service_description PING ; The service description
+
+ check_command check_ping!200.0,20%!600.0,60% ; The command used to monitor the service
+
+ normal_check_interval 5 ; Check the service every 5 minutes under normal conditions
+
+ retry_check_interval 1 ; Re-check the service every minute until its final/hard state is determined
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This service will be:
+
+</p>
+
+
+
+<ul>
+
+<li>CRITICAL if the round trip average (RTA) is greater than 600 milliseconds or the packet loss is 60% or more</li>
+
+<li>WARNING if the RTA is greater than 200 ms or the packet loss is 20% or more</li>
+
+<li>OK if the RTA is less than 200 ms and the packet loss is less than 20%</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Monitoring SNMP Status Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+If your switch or router supports SNMP, you can monitor a lot of information by using the <i>check_snmp</i> plugin. If it doesn't, skip this section.
+
+</p>
+
+
+
+<p>
+
+Add the following service definition to monitor the uptime of the switch.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit values from a template
+
+ host_name linksys-srw224p
+
+ service_description Uptime
+
+ check_command check_snmp!-C public -o sysUpTime.0
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In the <i>check_command</i> directive of the service definition above, the "-C public" tells the plugin that the SNMP community name to be used is "public" and the "-o sysUpTime.0" indicates which OID should be checked.
+
+</p>
+
+
+
+<p>
+
+If you want to ensure that a specific port/interface on the switch is in an up state, you could add a service definition like this:
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit values from a template
+
+ host_name linksys-srw224p
+
+ service_description Port 1 Link Status
+
+ check_command check_snmp!-C public -o ifOperStatus.1 -r 1 -m RFC1213-MIB
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In the example above, the "-o ifOperStatus.1" refers to the OID for the operational status of port 1 on the switch. The "-r 1" option tells the <i>check_snmp</i> plugin to return an OK state if "1" is found in the SNMP result (1 indicates an "up" state on the port) and CRITICAL if it isn't found. The "-m RFC1213-MIB" is optional and tells the <i>check_snmp</i> plugin to only load the "RFC1213-MIB" instead of every single MIB that's installed on your system, which can help speed things up.
+
+</p>
+
+
+
+<p>
+
+That's it for the SNMP monitoring example. There are a million things that can be monitored via SNMP, so its up to you to decide what you need and want to monitor. Good luck!
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: You can usually find the OIDs that can be monitored on a switch by running the following command (replace <i>192.168.1.253</i> with the IP address of the switch):
+
+<i>snmpwalk -v1 -c public 192.168.1.253 -m ALL .1</i>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Monitoring Bandwidth / Traffic Rate</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you're monitoring bandwidth usage on your switches or routers using <a href="http://oss.oetiker.ch/mrtg/">MRTG</a>, you can have Nagios alert you when traffic rates exceed thresholds you specify. The <i>check_mrtgtraf</i> plugin (which is included in the Nagios plugins distribution) allows you to do this.
+
+</p>
+
+
+
+<p>
+
+You'll need to let the <i>check_mrtgtraf</i> plugin know what log file the MRTG data is being stored in, along with thresholds, etc. In my example, I'm monitoring one of the ports on a Linksys switch. The MRTG log file is stored in <i>/var/lib/mrtg/192.168.1.253_1.log</i>. Here's the service definition I use to monitor the bandwidth data that's stored in the log file...
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service ; Inherit values from a template
+
+ host_name linksys-srw224p
+
+ service_description Port 1 Bandwidth Usage
+
+ check_command check_local_mrtgtraf!/var/lib/mrtg/192.168.1.253_1.log!AVG!1000000,2000000!5000000,5000000!10
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In the example above, the "/var/lib/mrtg/192.168.1.253_1.log" option that gets passed to the <i>check_local_mrtgtraf</i> command tells the plugin which MRTG log file to read from. The "AVG" option tells it that it should use average bandwidth statistics. The "1000000,2000000" options are the warning thresholds (in bytes) for incoming traffic rates. The "5000000,5000000" are critical thresholds (in bytes) for outgoing traffic rates. The "10" option causes the plugin to return a CRITICAL state if the MRTG log file is older than 10 minutes (it should be updated every 5 minutes).
+
+</p>
+
+
+
+
+
+<p>
+
+Save the file.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Restarting Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Once you've added the new host and service definitions to the <i>switch.cfg</i> file, you're ready to start monitoring the router/switch. To do this, you'll need to <a href="verifyconfig.html">verify your configuration</a> and <a href="startstop.html">restart Nagios</a>.
+
+</p>
+
+
+
+<p>
+
+If the verification process produces any errors messages, fix your configuration file before continuing. Make sure that you don't (re)start Nagios until the verification process completes without any errors!
+
+</p>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Monitoring Windows Machines</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Monitoring Windows Machines</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guide</a>, <a href="monitoring-publicservices.html">Monitoring Publicly Available Services</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This document describes how you can monitor "private" services and attributes of Windows machines, such as:
+
+</p>
+
+
+
+<ul>
+
+<li>Memory usage</li>
+
+<li>CPU load</li>
+
+<li>Disk usage</li>
+
+<li>Service states</li>
+
+<li>Running processes</li>
+
+<li>etc.</li>
+
+</ul>
+
+
+
+<p>
+
+Publicly available services that are provided by Windows machines (HTTP, FTP, POP3, etc.) can be monitored easily by following the documentation on <a href="monitoring-publicservices.html">monitoring publicly available services</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: These instructions assume that you've installed Nagios according to the <a href="quickstart.html">quickstart guide</a>. The sample configuration entries below reference objects that are defined in the sample config files (<i>commands.cfg</i>, <i>templates.cfg</i>, etc.) that are installed if you follow the quickstart.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Overview</u></strong>
+
+</p>
+
+
+
+<img src="images/monitoring-windows.png" border="0" alt="Monitoring a Windows Machine" title="Monitoring a Windows Machine" style="float: right;">
+
+
+
+<p>
+
+Monitoring private services or attributes of a Windows machine requires that you install an agent on it. This agent acts as a proxy between the Nagios plugin that does the monitoring and the actual service or attribute of the Windows machine. Without installing an agent on the Windows box, Nagios would be unable to monitor private services or attributes of the Windows box.
+
+</p>
+
+
+
+<p>
+
+For this example, we will be installing the <a href="http://sourceforge.net/projects/nscplus">NSClient++</a> addon on the Windows machine and using the <i>check_nt</i> plugin to communicate with the NSClient++ addon. The <i>check_nt</i> plugin should already be installed on the Nagios server if you followed the quickstart guide.
+
+</p>
+
+
+
+<p>
+
+Other Windows agents (like <a href="http://sourceforge.net/projects/nc-net">NC_Net</a>) could be used instead of NSClient++ if you wish - provided you change command and service definitions, etc. a bit. For the sake of simplicity I will only cover using the NSClient++ addon in these instructions.
+
+</p>
+
+
+
+
+
+
+
+<p>
+
+<strong><u>Steps</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are several steps you'll need to follow in order to monitor a new Windows machine. They are:
+
+</p>
+
+
+
+<ol>
+
+<li>Perform first-time prerequisites</li>
+
+<li>Install a monitoring agent on the Windows machine</li>
+
+<li>Create new host and service definitions for monitoring the Windows machine</li>
+
+<li>Restart the Nagios daemon</li>
+
+</ol>
+
+
+
+<p>
+
+<strong><u>What's Already Done For You</u></strong>
+
+</p>
+
+
+
+<p>
+
+To make your life a bit easier, a few configuration tasks have already been done for you:
+
+</p>
+
+
+
+<ul>
+
+<li>A <i>check_nt</i> command definition has been added to the <i>commands.cfg</i> file. This allows you to use the <i>check_nt</i> plugin to monitor Window services.</li>
+
+<li>A Windows server host template (called <i>windows-server</i>) has already been created in the <i>templates.cfg</i> file. This allows you to add new Windows host definitions in a simple manner.</li>
+
+</ul>
+
+
+
+<p>
+
+The above-mentioned config files can be found in the <i>/usr/local/nagios/etc/objects/</i> directory. You can modify the definitions in these and other definitions to suit your needs better if you'd like. However, I'd recommend waiting until you're more familiar with configuring Nagios before doing so. For the time being, just follow the directions outlined below and you'll be monitoring your Windows boxes in no time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Prerequisites</u></strong>
+
+</p>
+
+
+
+<p>
+
+The first time you configure Nagios to monitor a Windows machine, you'll need to do a bit of extra work. Remember, you only need to do this for the *first* Windows machine you monitor.
+
+</p>
+
+
+
+<p>
+
+Edit the main Nagios config file.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+Remove the leading pound (#) sign from the following line in the main configuration file:
+
+</p>
+
+
+
+<pre>
+
+#cfg_file=/usr/local/nagios/etc/objects/windows.cfg
+
+</pre>
+
+
+
+<p>
+
+Save the file and exit.
+
+</p>
+
+
+
+<p>
+
+What did you just do? You told Nagios to look to the <i>/usr/local/nagios/etc/objects/windows.cfg</i> to find additional object definitions. That's where you'll be adding Windows host and service definitions. That configuration file already contains some sample host, hostgroup, and service definitions. For the *first* Windows machine you monitor, you can simply modify the sample host and service definitions in that file, rather than creating new ones.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Installing the Windows Agent</u></strong>
+
+</p>
+
+
+
+<p>
+
+Before you can begin monitoring private services and attributes of Windows machines, you'll need to install an agent on those machines. I recommend using the NSClient++ addon, which can be found at <a href="http://sourceforge.net/projects/nscplus">http://sourceforge.net/projects/nscplus</a>. These instructions will take you through a basic installation of the NSClient++ addon, as well as the configuration of Nagios for monitoring the Windows machine.
+
+</p>
+
+
+
+<p>
+
+1. Download the latest stable version of the NSClient++ addon from <a href="http://sourceforge.net/projects/nscplus">http://sourceforge.net/projects/nscplus</a>
+
+</p>
+
+
+
+<p>
+
+2. Unzip the NSClient++ files into a new C:\NSClient++ directory
+
+</p>
+
+
+
+<p>
+
+3. Open a command prompt and change to the C:\NSClient++ directory
+
+</p>
+
+
+
+<p>
+
+4. Register the NSClient++ system service with the following command:
+
+</p>
+
+
+
+<pre>
+
+ nsclient++ /install
+
+</pre>
+
+
+
+<p>
+
+5. Install the NSClient++ systray with the following command ('SysTray' is case-sensitive):
+
+</p>
+
+
+
+<pre>
+
+ nsclient++ SysTray
+
+</pre>
+
+
+
+<p>
+
+6. Open the services manager and make sure the NSClientpp service is allowed to interact with the desktop (see the 'Log On' tab of the services manager). If it isn't already allowed to interact with the desktop, check the box to allow it to.
+
+</p>
+
+
+
+<p>
+
+<img src="images/nscpp.png" border="0" alt="NSClientpp">
+
+</p>
+
+
+
+<p>
+
+7. Edit the NSC.INI file (located in the C:\NSClient++ directory) and make the following changes:
+
+</p>
+
+
+
+<ul>
+
+<li>Uncomment all the modules listed in the [modules] section, except for CheckWMI.dll and RemoteConfiguration.dll</li>
+
+<li>Optionally require a password for clients by changing the 'password' option in the [Settings] section.</li>
+
+<li>Uncomment the 'allowed_hosts' option in the [Settings] section. Add the IP address of the Nagios server to this line, or leave it blank to allow all hosts to connect.</li>
+
+<li>Make sure the 'port' option in the [NSClient] section is uncommented and set to '12489' (the default port).</li>
+
+</ul>
+
+
+
+
+
+<p>
+
+8. Start the NSClient++ service with the following command:
+
+</p>
+
+
+
+<pre>
+
+ nsclient++ /start
+
+</pre>
+
+
+
+<p>
+
+9. If installed properly, a new icon should appear in your system tray. It will be a yellow circle with a black 'M' inside.
+
+</p>
+
+
+
+<p>
+
+10. Success! The Windows server can now be added to the Nagios monitoring configuration...
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Configuring Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Now it's time to define some <a href="objectdefinitions.html">object definitions</a> in your Nagios configuration files in order to monitor the new Windows machine.
+
+</p>
+
+
+
+<p>
+
+Open the <i>windows.cfg</i> file for editing.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/windows.cfg
+
+</pre>
+
+
+
+<p>
+
+Add a new <a href="objectdefinitions.html#host">host</a> definition for the Windows machine that you're going to monitor. If this is the *first* Windows machine you're monitoring, you can simply modify the sample host definition in <i>windows.cfg</i>. Change the <i>host_name</i>, <i>alias</i>, and <i>address</i> fields to appropriate values for the Windows box.
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ use windows-server ; Inherit default values from a Windows server template (make sure you keep this line!)
+
+ host_name winserver
+
+ alias My Windows Server
+
+ address 192.168.1.2
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Good. Now you can add some service definitions (to the same configuration file) in order to tell Nagios to monitor different aspects of the Windows machine. If this is the *first* Windows machine you're monitoring, you can simply modify the sample service definitions in <i>windows.cfg</i>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Replace "<i>winserver</i>" in the example definitions below with the name you specified in the <i>host_name</i> directive of the host definition you just added.
+
+</p>
+
+
+
+<p>
+
+Add the following service definition to monitor the version of the NSClient++ addon that is running on the Windows server. This is useful when it comes time to upgrade your Windows servers to a newer version of the addon, as you'll be able to tell which Windows machines still need to be upgraded to the latest version of NSClient++.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description NSClient++ Version
+
+ check_command check_nt!CLIENTVERSION
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Add the following service definition to monitor the uptime of the Windows server.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description Uptime
+
+ check_command check_nt!UPTIME
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+Add the following service definition to monitor the CPU utilization on the Windows server and generate a CRITICAL alert if the 5-minute CPU load is 90% or more or a WARNING alert if the 5-minute load is 80% or greater.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description CPU Load
+
+ check_command check_nt!CPULOAD!-l 5,80,90
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+Add the following service definition to monitor memory usage on the Windows server and generate a CRITICAL alert if memory usage is 90% or more or a WARNING alert if memory usage is 80% or greater.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description Memory Usage
+
+ check_command check_nt!MEMUSE!-w 80 -c 90
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+Add the following service definition to monitor usage of the C:\ drive on the Windows server and generate a CRITICAL alert if disk usage is 90% or more or a WARNING alert if disk usage is 80% or greater.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description C:\ Drive Space
+
+ check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+Add the following service definition to monitor the W3SVC service state on the Windows machine and generate a CRITICAL alert if the service is stopped.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description W3SVC
+
+ check_command check_nt!SERVICESTATE!-d SHOWALL -l W3SVC
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+Add the following service definition to monitor the Explorer.exe process on the Windows machine and generate a CRITICAL alert if the process is not running.
+
+</p>
+
+
+
+<pre>
+
+define service{
+
+ use generic-service
+
+ host_name winserver
+
+ service_description Explorer
+
+ check_command check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe
+
+ }
+
+</pre>
+
+
+
+<p>
+
+That's it for now. You've added some basic services that should be monitored on the Windows box. Save the configuration file.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Password Protection</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you specified a password in the NSClient++ configuration file on the Windows machine, you'll need to modify the <i>check_nt</i> command definition to include the password. Open the <i>commands.cfg</i> file for editing.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/commands.cfg
+
+</pre>
+
+
+
+<p>
+
+Change the definition of the <i>check_nt</i> command to include the "-s <PASSWORD>" argument (where PASSWORD is the password you specified on the Windows machine) like this:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name check_nt
+
+ command_line $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -s PASSWORD -v $ARG1$ $ARG2$
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Save the file.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Restarting Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+You're done with modifying the Nagios configuration, so you'll need to <a href="verifyconfig.html">verify your configuration files</a> and <a href="startstop.html">restart Nagios</a>.
+
+</p>
+
+
+
+<p>
+
+If the verification process produces any errors messages, fix your configuration file before continuing. Make sure that you don't (re)start Nagios until the verification process completes without any errors!
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Graphing Performance Info With MRTG</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Graphing Performance Info With MRTG</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="nagiostats.html">Nagiostats Utility</a>, <a href="tuning.html">Performance Tuning</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+The <a href="nagiostats.html">nagiostats</a> utility allows you to graph various Nagios performance statistics over time using <a href="http://oss.oetiker.ch/mrtg/">MRTG</a>. This is important because it can help you:
+
+</p>
+
+
+
+<ul>
+
+<li>Ensure Nagios is operating efficiently</li>
+
+<li>Locate problem areas in the monitoring process</li>
+
+<li>Observe the performance impacts of changes in your Nagios configuration</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Sample MRTG Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Sample MRTG configuration file snippets for graphing various Nagios performance statistics can be found in the <i>mrtg.cfg</i> file located in the <i>sample-config/</i> subdirectory of the Nagios distribution. You can create graphs of other performance information if you'd like - the samples just provide you with a good starting point.
+
+</p>
+
+<p>
+
+Once you copy these sample entries into your MRTG config file (/etc/mrtg/mrtg.cfg) you should have some new graphs the next time MRTG runs.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Example Graphs</u></strong>
+
+</p>
+
+
+
+<p>
+
+I'll describe what a few of the sample MRTG graphs mean and what they can be used for...
+
+</p>
+
+
+
+<table border="0" class="Default" cellpadding="10">
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Active Host Checks</b> - This graph shows how may active host checks (regularly scheduled and on-demand) have occurred over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="hostchecks.html">Host checks</a></li>
+
+<li><a href="dependencychecks.html">Predictive host dependency checks</a></li>
+
+<li><a href="cachedchecks.html">Cached checks</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-activehostchecks.png" border="0" alt="Active Host Checks">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Active Service Checks</b> - This graph shows how may active service checks (reguarly scheduled and on-demand) have occurred over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="servicechecks.html">Service checks</a></li>
+
+<li><a href="dependencychecks.html">Predictive service dependency checks</a></li>
+
+<li><a href="cachedchecks.html">Cached checks</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-activeservicechecks.png" border="0" alt="Active Service Checks">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Cached Host and Service Checks</b> - This graph shows how may cached host and service checks have occurred over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="cachedchecks.html">Cached checks</a></li>
+
+<li><a href="dependencychecks.html">Predictive host and service dependency checks</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-cachedchecks.png" border="0" alt="Cached Host and Service Checks">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Passive Host and Service Checks</b> - This graph shows how may passive host and service checks have occurred over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="passivechecks.html">Passive checks</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-passivechecks.png" border="0" alt="Passive Host and Service Checks">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Hosts/Services Actively Checked</b> - This graph shows how many (of the total number of) hosts and services were <i>last</i> checked actively over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="activechecks.html">Active checks</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-activelychecked.png" border="0" alt="Hosts/Services Actively Checked">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Hosts/Services Passively Checked</b> - This graph shows how many (of the total number of) hosts and services were <i>last</i> checked passively over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="passivechecks.html">Passive checks</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-passivelychecked.png" border="0" alt="Hosts/Services Passively Checked">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Average Service Check Latency and Execution Time</b> - This graph shows average service check latency and execution times over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="servicechecks.html">Service checks</a></li>
+
+<li><a href="tuning.html">Performance tuning</a></li>
+
+</ul>
+
+<p>
+
+Consistently high latencies can be an indication that one of more of the following variables need tweaking:
+
+</p>
+
+<ul>
+
+<li><a href="configmain.html#max_concurrent_checks">max_concurrent_checks</a></li>
+
+<li><a href="configmain.html#check_result_reaper_frequency">check_result_reaper_frequency</a></li>
+
+<li><a href="configmain.html#max_check_result_reaper_time">max_check_result_reaper_time</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-serviceperfstats.png" border="0" alt="Average Service Check Latency and Execution Time">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Average Service State Change</b> - This graph shows the average percent state change (a measure of volatility) for services over time, broken down by services that were last checked either actively or passively. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="flapping.html">Flap detection</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-servicestatechange.png" border="0" alt="Average Service State Change">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Average Host Check Latency and Execution Time</b> - This graph shows average host check latency and execution times over time. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="hostchecks.html">Host checks</a></li>
+
+<li><a href="tuning.html">Performance tuning</a></li>
+
+</ul>
+
+<p>
+
+Consistently high latencies can be an indication that one of more of the following variables need tweaking:
+
+</p>
+
+<ul>
+
+<li><a href="configmain.html#max_concurrent_checks">max_concurrent_checks</a></li>
+
+<li><a href="configmain.html#check_result_reaper_frequency">check_result_reaper_frequency</a></li>
+
+<li><a href="configmain.html#max_check_result_reaper_time">max_check_result_reaper_time</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-hostperfstats.png" border="0" alt="Average Host Check Latency and Execution Time">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>Average Host State Change</b> - This graph shows the average percent state change (a measure of volatility) for hosts over time, broken down by hosts that were last checked either actively or passively. Useful for understanding:
+
+</p>
+
+<ul>
+
+<li><a href="flapping.html">Flap detection</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-hoststatechange.png" border="0" alt="Average Host State Change">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>External Commands</b> - This graph shows how may external commands have been processed by the Nagios daemon over time. Unless you're processing a large number of external commands (as in the case with distributed monitoring setups), this graph may appear mostly empty. Monitoring external commands can be useful for understanding the impacts of:
+
+</p>
+
+<ul>
+
+<li><a href="passivechecks.html">Passive checks</a></li>
+
+<li><a href="distributed.html">Distributed monitoring</a></li>
+
+<li><a href="redundancy.html">Redundant/failover monitoring</a></li>
+
+</ul>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-externalcommands.png" border="0" alt="External Commands">
+
+</td>
+
+</tr>
+
+
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+<b>External Command Buffers</b> - This graph shows how may external command buffer slots are in use over time. If the number of used buffers is near the number of available buffers on a regular basis, it is likely you need to increase the available <a href="configmain.html#external_command_buffer_slots">external command buffer slots</a>. Each buffer slot can hold one external command. Buffers are used for temporarily holding external commands from the time they are read from the <a href="configmain.html#command_file">external command file</a> to the time they are processed by the Nagios daemon.
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<img src="images/mrtg-commandbuffers.png" border="0" alt="External Command Buffers">
+
+</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Using The Nagiostats Utility</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Using The Nagiostats Utility</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="mrtggraphs.html">Graphing Performance Info</a>, <a href="tuning.html">Performance Tuning</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+A utility called <b>nagiostats</b> is included in the Nagios distribution. It is compiled and installed along with the main Nagios daemon. The nagiostats utility allows you to obtain various information about a running Nagios process that can be very helpful in <a href="tuning.html">tuning performance</a>. You can obtain information either in human-readable or MRTG-compatible format.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Usage Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can run the <i>nagiostats</i> utility with the <b>--help</b> option to get usage information.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Human-Readable Output</u></strong>
+
+</p>
+
+
+
+<p>
+
+To obtain human-readable information on the performance of a running Nagios process, run the <i>nagiostats</i> utility with the <b>-c</b> command line argument to specify your main configuration file location like such:
+
+</p>
+
+
+
+
+
+<pre>
+
+[nagios@lanman ~]# /usr/local/nagios/bin/nagiostats -c /usr/local/nagios/etc/nagios.cfg
+
+
+
+
+
+Nagios Stats 3.0prealpha-05202006
+
+Copyright (c) 2003-2007 Ethan Galstad (www.nagios.org)
+
+Last Modified: 05-20-2006
+
+License: GPL
+
+
+
+CURRENT STATUS DATA
+
+------------------------------------------------------
+
+Status File: /usr/local/nagios/var/status.dat
+
+Status File Age: 0d 0h 0m 9s
+
+Status File Version: 3.0prealpha-05202006
+
+
+
+Program Running Time: 0d 5h 20m 39s
+
+Nagios PID: 10119
+
+Used/High/Total Command Buffers: 0 / 0 / 64
+
+Used/High/Total Check Result Buffers: 0 / 7 / 512
+
+
+
+Total Services: 95
+
+Services Checked: 94
+
+Services Scheduled: 91
+
+Services Actively Checked: 94
+
+Services Passively Checked: 1
+
+Total Service State Change: 0.000 / 78.950 / 1.026 %
+
+Active Service Latency: 0.000 / 4.272 / 0.561 sec
+
+Active Service Execution Time: 0.000 / 60.007 / 2.066 sec
+
+Active Service State Change: 0.000 / 78.950 / 1.037 %
+
+Active Services Last 1/5/15/60 min: 4 / 68 / 91 / 91
+
+Passive Service State Change: 0.000 / 0.000 / 0.000 %
+
+Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
+
+Services Ok/Warn/Unk/Crit: 58 / 16 / 0 / 21
+
+Services Flapping: 1
+
+Services In Downtime: 0
+
+
+
+Total Hosts: 24
+
+Hosts Checked: 24
+
+Hosts Scheduled: 24
+
+Hosts Actively Checked: 24
+
+Host Passively Checked: 0
+
+Total Host State Change: 0.000 / 9.210 / 0.384 %
+
+Active Host Latency: 0.000 / 0.446 / 0.219 sec
+
+Active Host Execution Time: 1.019 / 10.034 / 2.764 sec
+
+Active Host State Change: 0.000 / 9.210 / 0.384 %
+
+Active Hosts Last 1/5/15/60 min: 5 / 22 / 24 / 24
+
+Passive Host State Change: 0.000 / 0.000 / 0.000 %
+
+Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
+
+Hosts Up/Down/Unreach: 18 / 4 / 2
+
+Hosts Flapping: 0
+
+Hosts In Downtime: 0
+
+
+
+Active Host Checks Last 1/5/15 min: 9 / 52 / 164
+
+ Scheduled: 4 / 23 / 75
+
+ On-demand: 3 / 23 / 69
+
+ Cached: 2 / 6 / 20
+
+Passive Host Checks Last 1/5/15 min: 0 / 0 / 0
+
+Active Service Checks Last 1/5/15 min: 9 / 80 / 244
+
+ Scheduled: 9 / 80 / 244
+
+ On-demand: 0 / 0 / 0
+
+ Cached: 0 / 0 / 0
+
+Passive Service Checks Last 1/5/15 min: 0 / 0 / 0
+
+
+
+External Commands Last 1/5/15 min: 0 / 0 / 0
+
+
+
+[nagios@lanman ~]#
+
+</pre>
+
+
+
+<p>
+
+As you can see, the utility displays a number of different metrics pertaining to the Nagios process. Metrics which have multiple values are (unless otherwise specified) min, max and average values for that particular metric.
+
+</p>
+
+
+
+<p>
+
+<strong><u>MRTG Integration</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can use the <i>nagiostats</i> utility to display various Nagios metrics using MRTG (or other compatible program). To do so, run the <i>nagiostats</i> utility using the <b>--mrtg</b> and <b>--data</b> arguments. The <b>--data</b> argument is used to specify what statistics should be graphed. Possible values for the <b>--data</b> argument can be found by running the <i>nagiostats</i> utility with the <b>--help</b> option.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Information on using the <i>nagiostats</i> utility to generate MRTG graphs for Nagios performance statistics can be found <a href="mrtggraphs.html">here</a>.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<HTML>
+
+<HEAD>
+
+<TITLE>Determining Status and Reachability of Network Hosts</TITLE>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</HEAD>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Determining Status and Reachability of Network Hosts</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="hostchecks.html">Host Checks</a>, <a href="passivestatetranslation.html">Passive Host State Translation</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you've ever work in tech support, you've undoubtably had users tell you "the Internet is down". As a techie, you're pretty sure that no one pulled the power cord from the Internet. Something must be going wrong somewhere between the user's chair and the Internet.
+
+</p>
+
+
+
+<p>
+
+Assuming its a technical problem, you begin to search for the problem. Perhaps the user's computer is turned off, maybe their network cable is unplugged, or perhaps your organization's core router just took a dive. Whatever the problem might be, one thing is most certain - the Internet isn't down. It just happens to be unreachable for that user.
+
+</p>
+
+
+
+<p>
+
+Nagios is able to determine whether the hosts you're monitoring are in a DOWN or UNREACHABLE state. These are very different (although related) states and can help you quickly determine the root cause of network problems. Here's how the reachability logic works to distinguish between these two states...
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Example Network</u></strong>
+
+</p>
+
+
+
+<p>
+
+Take a look at the simple network diagram below. For this example, lets assume you're monitoring all the hosts (server, routers, switches, etc) that are pictured. Nagios is installed and running on the <i>Nagios</i> host.
+
+</p>
+
+
+
+<p>
+
+<img src="images/reachability1.png" border="0" alt="Example Network" title="Example Network">
+
+</p>
+
+
+
+<p>
+
+<strong><u>Defining Parent/Child Relationships</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order for Nagios to be able to distinguish between DOWN and UNREACHABLE states for the hosts that are being monitored, you'll need to tell Nagios how those hosts are connected to each other - from the standpoint of the Nagios daemon. To do this, trace the path that a data packet would take from the Nagios daemon to each individual host. Each switch, router, and server the packet encounters or passes through is considered a "hop" and will require that you define a parent/child host relationship in Nagios. Here's what the host parent/child relationships look like from the viewpoint of Nagios:
+
+</p>
+
+
+
+<p>
+
+<img src="images/reachability2.png" border="0" alt="Parent/Child Relationships" title="Parent/Child Relationships">
+
+</p>
+
+
+
+
+
+<p>
+
+Now that you know what the parent/child relationships look like for hosts that are being monitored, how do you configure Nagios to reflect them? The <i>parents</i> directive in your <a href="objectdefinitions.html#host">host definitions</a> allows you to do this. Here's what the (abbreviated) host definitions with parent/child relationships would look like for this example:
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ host_name Nagios ; <-- The local host has no parent - it is the topmost host
+
+ }
+
+
+
+define host{
+
+ host_name Switch1
+
+ parents Nagios
+
+ }
+
+
+
+define host{
+
+ host_name Web
+
+ parents Switch1
+
+ }
+
+
+
+define host{
+
+ host_name FTP
+
+ parents Switch1
+
+ }
+
+
+
+define host{
+
+ host_name Router1
+
+ parents Switch1
+
+ }
+
+
+
+define host{
+
+ host_name Switch2
+
+ parents Router1
+
+ }
+
+
+
+define host{
+
+ host_name Wkstn1
+
+ parents Switch2
+
+ }
+
+
+
+define host{
+
+ host_name HPLJ2605
+
+ parents Switch2
+
+ }
+
+
+
+define host{
+
+ host_name Router2
+
+ parents Router1
+
+ }
+
+
+
+define host{
+
+ host_name somewebsite.com
+
+ parents Router2
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Reachability Logic in Action</u></strong>
+
+</p>
+
+
+
+<p>
+
+Now that you're configured Nagios with the proper parent/child relationships for your hosts, let's see what happen when problems arise. Assume that two hosts - <i>Web</i> and <i>Router1</i> - go offline...
+
+</p>
+
+
+
+<p>
+
+<img src="images/reachability3.png" border="0" alt="Reachability Example" title="Reachability Example">
+
+</p>
+
+
+
+<p>
+
+When hosts change state (i.e. from UP to DOWN), the host reachability logic in Nagios kicks in. The reachability logic will initiate parallel checks of the parents and children of whatever hosts change state. This allows Nagios to quickly determine the current status of your network infrastructure when changes occur.
+
+</p>
+
+
+
+<p>
+
+<img src="images/reachability4.png" border="0" alt="Reachability Logic" title="Reachability Logic">
+
+</p>
+
+
+
+<p>
+
+In this example, Nagios will determine that <i>Web</i> and <i>Router1</i> are both in DOWN states because the "path" to those hosts is not being blocked.
+
+</p>
+
+
+
+<p>
+
+Nagios will determine that all the hosts "beneath" <i>Router1</i> are all in an UNREACHABLE state because Nagios can't reach them. <i>Router1</i> is DOWN and is blocking the path to those other hosts. Those hosts might be running fine, or they might be offline - Nagios doesn't know because it can't reach them. Hence Nagios considers them to be UNREACHABLE instead of DOWN.
+
+</p>
+
+
+
+<p>
+
+<strong><u>UNREACHABLE States and Notifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+By default, Nagios will notify contacts about both DOWN and UNREACHABLE host states. As an admin/tech, you might not want to get notifications about hosts that are UNREACHABLE. You know your network structure, and if Nagios notifies you that your router/firewall is down, you know that everything behind it is unreachable.
+
+</p>
+
+
+
+<p>
+
+If you want to spare yourself from a flood of UNREACHABLE notifications during network outages, you can exclude the unreachable (u) option from the <i>notification_options</i> directive in your <a href="objectdefinitions.html#host">host</a> definitions and/or the <i>host_notification_options</i> directive in your <a href="objectdefinitions.html#contact">contact</a> definitions.
+
+</p>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Notifications</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Notifications</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="escalations.html">Escalations</a>, <a href="timeperiods.html">Timeperiods</a>, <a href="oncallrotation.html">On-Call Rotations</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/objects-contacts.png" border="0" style="float: right;" alt="Contacts" title="Contacts">
+
+
+
+<p>
+
+I've had a lot of questions as to exactly how notifications work. This will attempt to explain exactly when and how host and service notifications are sent out, as well as who receives them.
+
+</p>
+
+
+
+<p>
+
+Notification escalations are explained <a href="escalations.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>When Do Notifications Occur?</u></strong>
+
+</p>
+
+
+
+<p>
+
+The decision to send out notifications is made in the service check and host check logic. Host and service notifications occur in the following instances...
+
+</p>
+
+
+
+<ul>
+
+<li>When a hard state change occurs. More information on state types and hard state changes can be found <a href="statetypes.html">here</a>.
+
+<li>When a host or service remains in a hard non-OK state and the time specified by the <<i>notification_interval</i>> option in the host or service definition has passed since the last notification was sent out (for that specified host or service).
+
+</ul>
+
+
+
+
+
+<p>
+
+<strong><u>Who Gets Notified?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Each host and service definition has a <<i>contact_groups</i>> option that specifies what contact groups receive notifications for that particular host or service. Contact groups can contain one or more individual contacts.
+
+</p>
+
+<p>
+
+When Nagios sends out a host or service notification, it will notify each contact that is a member of any contact groups specified in the <<i>contactgroups</i>> option of the service definition. Nagios realizes that a contact may be a member of more than one contact group, so it removes duplicate contact notifications before it does anything.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>What Filters Must Be Passed In Order For Notifications To Be Sent?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Just because there is a need to send out a host or service notification doesn't mean that any contacts are going to get notified. There are several filters that potential notifications must pass before they are deemed worthy enough to be sent out. Even then, specific contacts may not be notified if their notification filters do not allow for the notification to be sent to them. Let's go into the filters that have to be passed in more detail...
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Program-Wide Filter:</u></strong>
+
+</p>
+
+<p>
+
+The first filter that notifications must pass is a test of whether or not notifications are enabled on a program-wide basis. This is initially determined by the <a href="configmain.html#enable_notifications">enable_notifications</a> directive in the main config file, but may be changed during runtime from the web interface. If notifications are disabled on a program-wide basis, no host or service notifications can be sent out - period. If they are enabled on a program-wide basis, there are still other tests that must be passed...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Service and Host Filters:</u></strong>
+
+</p>
+
+
+
+<p>
+
+The first filter for host or service notifications is a check to see if the host or service is in a period of <a href="downtime.html">scheduled downtime</a>. If it is in a scheduled downtime, <b>no one gets notified</b>. If it isn't in a period of downtime, it gets passed on to the next filter. As a side note, notifications for services are suppressed if the host they're associated with is in a period of scheduled downtime.
+
+</p>
+
+
+
+<p>
+
+The second filter for host or service notification is a check to see if the host or service is <a href="flapping.html">flapping</a> (if you enabled flap detection). If the service or host is currently flapping, <b>no one gets notified</b>. Otherwise it gets passed to the next filter.
+
+</p>
+
+
+
+<p>
+
+The third host or service filter that must be passed is the host- or service-specific notification options. Each service definition contains options that determine whether or not notifications can be sent out for warning states, critical states, and recoveries. Similiarly, each host definition contains options that determine whether or not notifications can be sent out when the host goes down, becomes unreachable, or recovers. If the host or service notification does not pass these options, <b>no one gets notified</b>. If it does pass these options, the notification gets passed to the next filter... Note: Notifications about host or service recoveries are only sent out if a notification was sent out for the original problem. It doesn't make sense to get a recovery notification for something you never knew was a problem.
+
+</p>
+
+
+
+<p>
+
+The fourth host or service filter that must be passed is the time period test. Each host and service definition has a <<i>notification_period</i>> option that specifies which time period contains valid notification times for the host or service. If the time that the notification is being made does not fall within a valid time range in the specified time period, <b>no one gets contacted</b>. If it falls within a valid time range, the notification gets passed to the next filter... Note: If the time period filter is not passed, Nagios will reschedule the next notification for the host or service (if its in a non-OK state) for the next valid time present in the time period. This helps ensure that contacts are notified of problems as soon as possible when the next valid time in time period arrives.
+
+</p>
+
+
+
+<p>
+
+The last set of host or service filters is conditional upon two things: (1) a notification was already sent out about a problem with the host or service at some point in the past and (2) the host or service has remained in the same non-OK state that it was when the last notification went out. If these two criteria are met, then Nagios will check and make sure the time that has passed since the last notification went out either meets or exceeds the value specified by the <<i>notification_interval</i>> option in the host or service definition. If not enough time has passed since the last notification, <b>no one gets contacted</b>. If either enough time has passed since the last notification or the two criteria for this filter were not met, the notification will be sent out! Whether or not it actually is sent to individual contacts is up to another set of filters...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Contact Filters:</u></strong>
+
+</p>
+
+<p>
+
+At this point the notification has passed the program mode filter and all host or service filters and Nagios starts to notify <a href="objectdefinitions.html#contact">all the people it should</a>. Does this mean that each contact is going to receive the notification? No! Each contact has their own set of filters that the notification must pass before they receive it. Note: Contact filters are specific to each contact and do not affect whether or not other contacts receive notifications.
+
+</p>
+
+
+
+<p>
+
+The first filter that must be passed for each contact are the notification options. Each contact definition contains options that determine whether or not service notifications can be sent out for warning states, critical states, and recoveries. Each contact definition also contains options that determine whether or not host notifications can be sent out when the host goes down, becomes unreachable, or recovers. If the host or service notification does not pass these options, <b>the contact will not be notified</b>. If it does pass these options, the notification gets passed to the next filter... Note: Notifications about host or service recoveries are only sent out if a notification was sent out for the original problem. It doesn't make sense to get a recovery notification for something you never knew was a problem...
+
+</p>
+
+
+
+<p>
+
+The last filter that must be passed for each contact is the time period test. Each contact definition has a <<i>notification_period</i>> option that specifies which time period contains valid notification times for the contact. If the time that the notification is being made does not fall within a valid time range in the specified time period, <b>the contact will not be notified</b>. If it falls within a valid time range, the contact gets notified!
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Notification Methods</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can have Nagios notify you of problems and recoveries pretty much anyway you want: pager, cellphone, email, instant message, audio alert, electric shocker, etc. How notifications are sent depend on the <a href="objectdefinitions.html#command">notification commands</a> that are defined in your <a href="config.html">object definition files</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: If you install Nagios according to the <a href="quickstart.html">quickstart guide</a>, it should be configured to send email notifications. You can see the email notification commands that are used by viewing the contents of the following file: <i>/usr/local/nagios/etc/objects/commands.cfg</i>.
+
+</p>
+
+
+
+<p>
+
+Specific notification methods (paging, etc.) are not directly incorporated into the Nagios code as it just doesn't make much sense. The "core" of Nagios is not designed to be an all-in-one application. If service checks were embedded in Nagios' core it would be very difficult for users to add new check methods, modify existing checks, etc. Notifications work in a similiar manner. There are a thousand different ways to do notifications and there are already a lot of packages out there that handle the dirty work, so why re-invent the wheel and limit yourself to a bike tire? Its much easier to let an external entity (i.e. a simple script or a full-blown messaging system) do the messy stuff. Some messaging packages that can handle notifications for pagers and cellphones are listed below in the resource section.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Notification Type Macro</u></strong>
+
+</p>
+
+
+
+<p>
+
+When crafting your notification commands, you need to take into account what type of notification is occurring. The <a href="macrolist.html#notificationtype">$NOTIFICATIONTYPE$</a> macro contains a string that identifies exactly that. The table below lists the possible values for the macro and their respective descriptions:
+
+</p>
+
+
+
+<table class="Default" border="1">
+
+<tr><th>Value</th><th>Description</th></tr>
+
+<tr><td>PROBLEM</td><td>A service or host has just entered (or is still in) a problem state. If this is a service notification, it means the service is either in a WARNING, UNKNOWN or CRITICAL state. If this is a host notification, it means the host is in a DOWN or UNREACHABLE state.</td></tr>
+
+<tr><td>RECOVERY</td><td>A service or host recovery has occurred. If this is a service notification, it means the service has just returned to an OK state. If it is a host notification, it means the host has just returned to an UP state.</td></tr>
+
+<tr><td>ACKNOWLEDGEMENT</td><td>This notification is an acknowledgement notification for a host or service problem. Acknowledgement notifications are initiated via the web interface by contacts for the particular host or service.</td></tr>
+
+<tr><td>FLAPPINGSTART</td><td>The host or service has just started <a href="flapping.html">flapping</a>.</td></tr>
+
+<tr><td>FLAPPINGSTOP</td><td>The host or service has just stopped <a href="flapping.html">flapping</a>.</td></tr>
+
+<tr><td>FLAPPINGDISABLED</td><td>The host or service has just stopped <a href="flapping.html">flapping</a> because flap detection was disabled..</td></tr>
+
+<tr><td>DOWNTIMESTART</td><td>The host or service has just entered a period of <a href="downtime.html">scheduled downtime</a>. Future notifications will be supressed.</td></tr>
+
+<tr><td>DOWNTIMESTOP</td><td>The host or service has just exited from a period of <a href="downtime.html">scheduled downtime</a>. Notifications about problems can now resume.</td></tr>
+
+<tr><td>DOWNTIMECANCELLED</td><td>The period of <a href="downtime.html">scheduled downtime</a> for the host or service was just cancelled. Notifications about problems can now resume.</td></tr>
+
+</table>
+
+
+
+<p>
+
+<strong><u>Helpful Resources</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are many ways you could configure Nagios to send notifications out. Its up to you to decide which method(s) you want to use. Once you do that you'll have to install any necessary software and configure notification commands in your config files before you can use them. Here are just a few possible notification methods:
+
+</p>
+
+
+
+<ul>
+
+<li>Email
+
+<li>Pager
+
+<li>Phone (SMS)
+
+<li>WinPopup message
+
+<li>Yahoo, ICQ, or MSN instant message
+
+<li>Audio alerts
+
+<li>etc...
+
+</ul>
+
+
+
+<p>
+
+Basically anything you can do from a command line can be tailored for use as a notification command.
+
+</p>
+
+
+
+<p>
+
+If you're looking for an alternative to using email for sending messages to your pager or cellphone, check out these packages. They could be used in conjuction with Nagios to send out a notification via a modem when a problem
+
+arises. That way you don't have to rely on email to send notifications out (remember, email may *not* work if
+
+there are network problems). I haven't actually tried these packages myself, but others have reported success
+
+using them...
+
+</p>
+
+<ul>
+
+<li><a href="http://www.gnokii.org/">Gnokii</a> (SMS software for contacting Nokia phones via GSM network)
+
+<li><a href="http://www.qpage.org/" target="_top">QuickPage</a> (alphanumeric pager software)
+
+<li><a href="http://www.sendpage.org/" target="_top">Sendpage</a> (paging software)
+
+<li><a href="http://www.smsclient.org/" target="_top">SMS Client</a> (command line utility for
+
+sending messages to pagers and mobile phones)
+
+</ul>
+
+
+
+<p>
+
+If you want to try out a non-traditional method of notification, you might want to mess around with audio alerts. If you want to have audio alerts played on the monitoring server (with synthesized speech), check out <a href="http://www.cstr.ed.ac.uk/projects/festival/">Festival</a>. If you'd rather leave the monitoring box alone and have audio alerts played on another box, check out the <a href="http://radscan.com/nas.html">Network Audio System (NAS)</a> and <a href="http://rplay.doit.org/">rplay</a> projects.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Object Definitions</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+
+
+ .SectionHeader { font-family: verdana,arial,serif; font-size: 10pt; font-weight: bold; background-color: #cbcbcb; }
+
+ .SectionTitle { font-family: verdana,arial,serif; font-size: 8pt; font-weight: bold; text-decoration: underline; }
+
+ .Definition { font-family: verdana,arial,serif; font-size: 7pt; text-align: left; color: #3333cc;}
+
+ .Required { font-family: verdana,arial,serif; font-size: 7pt; text-align: left; color: red; }
+
+ .Optional { font-family: verdana,arial,serif; font-size: 7pt; text-align: left; }
+
+
+
+ .RetentionNotes { font-family: verdana,rial,serif; font-size: 10pt; text-align: left; color: red; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Object Definitions</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="configobject.html">Object Configuration Overview</a>, <a href="objecttricks.html">Object Tricks</a>, <a href="objectinheritance.html">Object Inheritance</a>, <a href="customobjectvars.html">Custom Object Variables</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+One of the features of Nagios' object configuration format is that you can create object definitions that inherit properties from other object definitions. An explanation of how object inheritence works can be found <a href="objectinheritance.html">here</a>. I strongly suggest that you familiarize yourself with object inheritence once you read over the documentation presented below, as it will make the job of creating and maintaining object definitions much easier than it otherwise would be. Also, read up on the <a href="objecttricks.html">object tricks</a> that offer shortcuts for otherwise tedious configuration tasks.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note">When creating and/or editing configuration files, keep the following in mind:
+
+</p>
+
+<ol>
+
+<li>Lines that start with a '#' character are taken to be comments and are not processed
+
+<li>Directive names are case-sensitive
+
+<li>Characters that appear after a semicolon (;) in configuration lines are treated as comments and are not processed
+
+</ol>
+
+
+
+<a name="retention_notes"></a>
+
+<p>
+
+<strong><u>Retention Notes</u></strong>
+
+</p>
+
+
+
+<p>
+
+It is important to point out that several directives in host, service, and contact definitions may not be picked up by Nagios when you change them in your configuration files. Object directives that can exhibit this behavior are marked with an asterisk (<a href="#retention_notes" class="RetentionNotes">*</a>). The reason for this behavior is due to the fact that Nagios chooses to honor values stored in the <a href="#state_retention_file">state retention file</a> over values found in the config files, assuming you have <a href="#retain_state_information">state retention</a> enabled on a program-wide basis <i>and</i> the value of the directive is changed during runtime with an <a href="configmain.html#check_external_commands">external command</a>.
+
+</p>
+
+
+
+<p>
+
+One way to get around this problem is to disable the retention of non-status information using the <i>retain_nonstatus_information</i> directive in the host, service, and contact definitions. Disabling this directive will cause Nagios to take the initial values for these directives from your config files, rather than from the state retention file when it (re)starts.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Sample Configuration Files</u></strong>
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Sample object configuration files are installed in the <i>/usr/local/nagios/etc/</i> directory when you follow the <a href="quickstart.html">quickstart installation guide</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Object Types</u></strong>
+
+</p>
+
+<p>
+
+<a href="#host">Host definitions</a><br>
+
+<a href="#hostgroup">Host group definitions</a><br>
+
+<a href="#service">Service definitions</a><br>
+
+<a href="#servicegroup">Service group definitions</a><br>
+
+<a href="#contact">Contact definitions</a><br>
+
+<a href="#contactgroup">Contact group definitions</a><br>
+
+<a href="#timeperiod">Time period definitions</a><br>
+
+<a href="#command">Command definitions</a><br>
+
+<a href="#servicedependency">Service dependency definitions</a><br>
+
+<a href="#serviceescalation">Service escalation definitions</a><br>
+
+<a href="#hostdependency">Host dependency definitions</a><br>
+
+<a href="#hostescalation">Host escalation definitions</a><br>
+
+<a href="#hostextinfo">Extended host information definitions</a><br>
+
+<a href="#serviceextinfo">Extended service information definitions</a><br>
+
+</p>
+
+
+
+<p>
+
+<a name="host"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Host Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A host definition is used to define a physical server, workstation, device, etc. that resides on your network.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define host{</td></tr>
+
+
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Required">alias</td><td class="Required"><i>alias</i></td></tr>
+
+<tr><td></td><td class="Optional">display_name</td><td class="Optional"><i>display_name</i></td></tr>
+
+<tr><td></td><td class="Required">address</td><td class="Required"><i>address</i></td></tr>
+
+<tr><td></td><td class="Optional">parents</td><td class="Optional"><i>host_names</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroups</td><td class="Optional"><i>hostgroup_names</i></td></tr>
+
+<tr><td></td><td class="Optional">check_command</td><td class="Optional"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Optional">initial_state</td><td class="Optional">[o,d,u]</td></tr>
+
+<tr><td></td><td class="Required">max_check_attempts</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Optional">check_interval</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">retry_interval</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">active_checks_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">passive_checks_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">check_period</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Optional">obsess_over_host</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">check_freshness</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">freshness_threshold</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">event_handler</td><td class="Optional"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Optional">event_handler_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">low_flap_threshold</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">high_flap_threshold</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">flap_detection_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">flap_detection_options</td><td class="Optional">[o,d,u]</td></tr>
+
+<!--<tr><td></td><td class="Optional">failure_prediction_enabled</td><td class="Optional">[0/1]</td></tr>//-->
+
+<tr><td></td><td class="Optional">process_perf_data</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">retain_status_information</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">retain_nonstatus_information</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">contacts</td><td class="Required"><i>contacts</i></td></tr>
+
+<tr><td></td><td class="Required">contact_groups</td><td class="Required"><i>contact_groups</i></td></tr>
+
+<tr><td></td><td class="Required">notification_interval</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Optional">first_notification_delay</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Required">notification_period</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Optional">notification_options</td><td class="Optional">[d,u,r,f,s]</td></tr>
+
+<tr><td></td><td class="Optional">notifications_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">stalking_options</td><td class="Optional">[o,d,u]</td></tr>
+
+<tr><td></td><td class="Optional">notes</td><td class="Optional"><i>note_string</i></td></tr>
+
+<tr><td></td><td class="Optional">notes_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">action_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image_alt</td><td class="Optional"><i>alt_string</i></td></tr>
+
+<tr><td></td><td class="Optional">vrml_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">statusmap_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">2d_coords</td><td class="Optional"><i>x_coord,y_coord</i></td></tr>
+
+<tr><td></td><td class="Optional">3d_coords</td><td class="Optional"><i>x_coord,y_coord,z_coord</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define host{
+
+ host_name bogus-router
+
+ alias Bogus Router #1
+
+ address 192.168.1.254
+
+ parents server-backbone
+
+ check_command check-host-alive
+
+ check_interval 5
+
+ retry_interval 1
+
+ max_check_attempts 5
+
+ check_period 24x7
+
+ process_perf_data 0
+
+ retain_nonstatus_information 0
+
+ contact_groups router-admins
+
+ notification_interval 30
+
+ notification_period 24x7
+
+ notification_options d,u,r
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to define a short name used to identify the host. It is used in host group and service definitions to reference this particular host. Hosts can have multiple services (which are monitored) associated with them. When used properly, the $HOSTNAME$ <a href="macros.html">macro</a> will contain this short name.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>alias</strong>:</td>
+
+<td>
+
+This directive is used to define a longer name or description used to identify the host. It is provided in order to allow you to more easily identify a particular host. When used properly, the $HOSTALIAS$ <a href="macros.html">macro</a> will contain this alias/description.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>address</strong>:</td>
+
+<td>
+
+This directive is used to define the address of the host. Normally, this is an IP address, although it could really be anything you want (so long as it can be used to check the status of the host). You can use a FQDN to identify the host instead of an IP address, but if DNS services are not 3333cc
\0le this could cause problems. When used properly, the $HOSTADDRESS$ <a href="macros.html">macro</a> will contain this address. <b>Note:</b> If you do not specify an address directive in a host definition, the name of the host will be used as its address. A word of caution about doing this, however - if DNS fails, most of your service checks will fail because the plugins will be unable to resolve the host name.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>display_name</strong>:</td>
+
+<td>
+
+This directive is used to define an alternate name that should be displayed in the web interface for this host. If not specified, this defaults to the value you specify for the <i>host_name</i> directive. Note: The current CGIs do not use this option, although future versions of the web interface will.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>parents</strong>:</td>
+
+<td>
+
+This directive is used to define a comma-delimited list of short names of the "parent" hosts for this particular host. Parent hosts are typically routers, switches, firewalls, etc. that lie between the monitoring host and a remote hosts. A router, switch, etc. which is closest to the remote host is considered to be that host's "parent". Read the "Determining Status and Reachability of Network Hosts" document located <a href="networkreachability.html">here</a> for more information. If this host is on the same network segment as the host doing the monitoring (without any intermediate routers, etc.) the host is considered to be on the local network and will not have a parent host. Leave this value blank if the host does not have a parent host (i.e. it is on the same segment as the Nagios host). The order in which you specify parent hosts has no effect on how things are monitored.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroups</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#hostgroup">hostgroup(s)</a> that the host belongs to. Multiple hostgroups should be separated by commas. This directive may be used as an alternative to (or in addition to) using the <i>members</i> directive in <a href="#hostgroup">hostgroup</a> definitions.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_command</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name</i> of the <a href="#command">command</a> that should be used to check if the host is up or down. Typically, this command would try and ping the host to see if it is "alive". The command must return a status of OK (0) or Nagios will assume the host is down. If you leave this argument blank, the host will <i>not</i> be actively checked. Thus, Nagios will likely always assume the host is up (it may show up as being in a "PENDING" state in the web interface). This is useful if you are monitoring printers or other devices that are frequently turned off. The maximum amount of time that the notification command can run is controlled by the <a href="configmain.html#host_check_timeout">host_check_timeout</a> option.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>initial_state</strong>:</td>
+
+<td>
+
+By default Nagios will assume that all hosts are in UP states when it starts. You can override the initial state for a host by using this directive. Valid options are: <b>o</b> = UP, <b>d</b> = DOWN, and <b>u</b> = UNREACHABLE.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>max_check_attempts</strong>:</td>
+
+<td>
+
+This directive is used to define the number of times that Nagios will retry the host check command if it returns any state other than an OK state. Setting this value to 1 will cause Nagios to generate an alert without retrying the host check. Note: If you do not want to check the status of the host, you must still set this to a minimum value of 1. To bypass the host check, just leave the <i>check_command</i> option blank.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_interval</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" between regularly scheduled checks of the host. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. More information on this value can be found in the <a href="checkscheduling.html">check scheduling</a> documentation.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retry_interval</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before scheduling a re-check of the hosts. Hosts are rescheduled at the retry interval when they have changed to a non-UP state. Once the host has been retried <b>max_check_attempts</b> times without a change in its status, it will revert to being scheduled at its "normal" rate as defined by the <b>check_interval</b> value. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. More information on this value can be found in the <a href="checkscheduling.html">check scheduling</a> documentation.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>active_checks_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not active checks (either regularly scheduled or on-demand) of this host are enabled. Values: 0 = disable active host checks, 1 = enable active host checks (default).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>passive_checks_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not passive checks are enabled for this host. Values: 0 = disable passive host checks, 1 = enable passive host checks (default).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which active checks of this host can be made.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>obsess_over_host <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive determines whether or not checks for the host will be "obsessed" over using the <a href="configmain.html#ochp_command">ochp_command</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_freshness <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not <a href="freshness.html">freshness checks</a> are enabled for this host. Values: 0 = disable freshness checks, 1 = enable freshness checks (default).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>freshness_threshold</strong>:</td>
+
+<td>
+
+This directive is used to specify the freshness threshold (in seconds) for this host. If you set this directive to a value of 0, Nagios will determine a freshness threshold to use automatically.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>event_handler</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name</i> of the <a href="#command">command</a> that should be run whenever a change in the state of the host is detected (i.e. whenever it goes down or recovers). Read the documentation on
+
+<a href="eventhandlers.html">event handlers</a> for a more detailed explanation of how to write scripts for handling events. The maximum amount of time that the event handler command can run is controlled by the <a href="configmain.html#event_handler_timeout">event_handler_timeout</a> option.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>event_handler_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the event handler for this host is enabled. Values: 0 = disable host event handler, 1 = enable host event handler.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>low_flap_threshold</strong>:</td>
+
+<td>
+
+This directive is used to specify the low state change threshold used in flap detection for this host. More information on flap detection can be found <a href="flapping.html">here</a>. If you set this directive to a value of 0, the program-wide value specified by the <a href="configmain.html#low_host_flap_threshold">low_host_flap_threshold</a> directive will be used.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>high_flap_threshold</strong>:</td>
+
+<td>
+
+This directive is used to specify the high state change threshold used in flap detection for this host. More information on flap detection can be found <a href="flapping.html">here</a>. If you set this directive to a value of 0, the program-wide value specified by the <a href="configmain.html#high_host_flap_threshold">high_host_flap_threshold</a> directive will be used.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>flap_detection_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not flap detection is enabled for this host. More information on flap detection can be found <a href="flapping.html">here</a>. Values: 0 = disable host flap detection, 1 = enable host flap detection.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>flap_detection_options</strong>:</td>
+
+<td>
+
+This directive is used to determine what host states the <a href="flapping.html">flap detection logic</a> will use for this host. Valid options are a combination of one or more of the following: <b>o</b> = UP states, <b>d</b> = DOWN states, <b>u</b> = UNREACHABLE states.
+
+</td>
+
+</tr>
+
+<!--
+
+<tr>
+
+<td valign="top"><strong>failure_prediction_enabled</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not failure prediction is enabled for this host. Values: 0 = disable host failure prediction, 1 = enable host failure prediction.
+
+</td>
+
+</tr>
+
+//-->
+
+<tr>
+
+<td valign="top"><strong>process_perf_data <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the processing of performance data is enabled for this host. Values: 0 = disable performance data processing, 1 = enable performance data processing.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retain_status_information</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not status-related information about the host is retained across program restarts. This is only useful if you have enabled state retention using the <a href="configmain.html#retain_state_information">retain_state_information</a> directive. Value: 0 = disable status information retention, 1 = enable status information retention.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retain_nonstatus_information</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not non-status information about the host is retained across program restarts. This is only useful if you have enabled state retention using the <a href="configmain.html#retain_state_information">retain_state_information</a> directive. Value: 0 = disable non-status information retention, 1 = enable non-status information retention.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contacts</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of the <a href="#contact">contacts</a> that should be notified whenever there are problems (or recoveries) with this host. Multiple contacts should be separated by commas. Useful if you want notifications to go to just a few people and don't want to configure <a href="#contactgroup">contact groups</a>. You must specify at least one contact or contact group in each host definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contact_groups</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of the <a href="#contactgroup">contact groups</a> that should be notified whenever there are problems (or recoveries) with this host. Multiple contact groups should be separated by commas. You must specify at least one contact or contact group in each host definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_interval</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before re-notifying a contact that this service is <i>still</i> down or unreachable. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. If you set this value to 0, Nagios will <i>not</i> re-notify contacts about problems for this host - only one problem notification will be sent out.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>first_notification_delay</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before sending out the first problem notification when this host enters a non-UP state. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. If you set this value to 0, Nagios will start sending out notifications immediately.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which notifications of events for this host can be sent out to contacts. If a host goes down, becomes unreachable, or recoveries during a time which is not covered by the time period, no notifications will be sent out.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_options</strong>:</td>
+
+<td>
+
+This directive is used to determine when notifications for the host should be sent out. Valid options are a combination of one or more of the following: <b>d</b> = send notifications on a DOWN state, <b>u</b> = send notifications on an UNREACHABLE state, <b>r</b> = send notifications on recoveries (OK state), <b>f</b> = send notifications when the host starts and stops <a href="flapping.html">flapping</a>, and <b>s</b> = send notifications when <a href="downtime.html">scheduled downtime</a> starts and ends. If you specify <b>n</b> (none) as an option, no host notifications will be sent out. If you do not specify any notification options, Nagios will assume that you want notifications to be sent out for all possible states. Example: If you specify <b>d,r</b> in this field, notifications will only be sent out when the host goes DOWN and when it recovers from a DOWN state.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notifications_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not notifications for this host are enabled. Values: 0 = disable host notifications, 1 = enable host notifications.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>stalking_options</strong>:</td>
+
+<td>
+
+This directive determines which host states "stalking" is enabled for. Valid options are a combination of one or more of the following: <b>o</b> = stalk on UP states, <b>d</b> = stalk on DOWN states, and <b>u</b> = stalk on UNREACHABLE states. More information on state stalking can be found <a href="stalking.html">here</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes</strong>:</td>
+
+<td>
+
+This directive is used to define an optional string of notes pertaining to the host. If you specify a note here, you will see the it in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified host).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes_url</strong>:</td>
+
+<td>
+
+This variable is used to define an optional URL that can be used to provide more information about the host. If you specify an URL, you will see a red folder icon in the CGIs (when you are viewing host information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>). This can be very useful if you want to make detailed information on the host, emergency contact methods, etc. available to other support staff.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>action_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more actions to be performed on the host. If you specify an URL, you will see a red "splat" icon in the CGIs (when you are viewing host information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of a GIF, PNG, or JPG image that should be associated with this host. This image will be displayed in the various places in the CGIs. The image will look best if it is 40x40 pixels in size. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image_alt</strong>:</td>
+
+<td>
+
+This variable is used to define an optional string that is used in the ALT tag of the image specified by the <i><icon_image></i> argument.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>vrml_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of a GIF, PNG, or JPG image that should be associated with this host. This image will be used as the texture map for the specified host in the <a href="cgis.html#statuswrl_cgi">statuswrl</a> CGI. Unlike the image you use for the <i><icon_image></i> variable, this one should probably <i>not</i> have any transparency. If it does, the host object will look a bit wierd. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>statusmap_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of an image that should be associated with this host in the <a href="cgis.html#statusmap_cgi">statusmap</a> CGI. You can specify a JPEG, PNG, and GIF image if you want, although I would strongly suggest using a GD2 format image, as other image formats will result in a lot of wasted CPU time when the statusmap image is generated. GD2 images can be created from PNG images by using the <b>pngtogd2</b> utility supplied with Thomas Boutell's <a href="http://www.boutell.com/gd/">gd library</a>. The GD2 images should be created in <i>uncompressed</i> format in order to minimize CPU load when the statusmap CGI is generating the network map image. The image will look best if it is 40x40 pixels in size. You can leave these option blank if you are not using the statusmap CGI. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>2d_coords</strong>:</td>
+
+<td>
+
+This variable is used to define coordinates to use when drawing the host in the <a href="cgis.html#statusmap_cgi">statusmap</a> CGI. Coordinates should be given in positive integers, as they correspond to physical pixels in the generated image. The origin for drawing (0,0) is in the upper left hand corner of the image and extends in the positive x direction (to the right) along the top of the image and in the positive y direction (down) along the left hand side of the image. For reference, the size of the icons drawn is usually about 40x40 pixels (text takes a little extra space). The coordinates you specify here are for the upper left hand corner of the host icon that is drawn. Note: Don't worry about what the maximum x and y coordinates that you can use are. The CGI will automatically calculate the maximum dimensions of the image it creates based on the largest x and y coordinates you specify.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>3d_coords</strong>:</td>
+
+<td>
+
+This variable is used to define coordinates to use when drawing the host in the <a href="cgis.html#statuswrl_cgi">statuswrl</a> CGI. Coordinates can be positive or negative real numbers. The origin for drawing is (0.0,0.0,0.0). For reference, the size of the host cubes drawn is 0.5 units on each side (text takes a little more space). The coordinates you specify here are used as the center of the host cube.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<p>
+
+<a name="hostgroup"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Host Group Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A host group definition is used to group one or more hosts together for simplifying configuration with <a href="objecttricks.html">object tricks</a> or display purposes in the <a href="cgis.html">CGIs</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define hostgroup{</td></tr>
+
+
+
+<tr><td></td><td class="Required">hostgroup_name</td><td class="Required"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">alias</td><td class="Required"><i>alias</i></td></tr>
+
+<tr><td></td><td class="Optional">members</td><td class="Optional"><i>hosts</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroup_members</td><td class="Optional"><i>hostgroups</i></td></tr>
+
+<tr><td></td><td class="Optional">notes</td><td class="Optional"><i>note_string</i></td></tr>
+
+<tr><td></td><td class="Optional">notes_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">action_url</td><td class="Optional"><i>url</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define hostgroup{
+
+ hostgroup_name novell-servers
+
+ alias Novell Servers
+
+ members netware1,netware2,netware3,netware4
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to define a short name used to identify the host group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>alias</strong>:</td>
+
+<td>
+
+This directive is used to define is a longer name or description used to identify the host group. It is provided in order to allow you to more easily identify a particular host group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>members</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of <a href="#host">hosts</a> that should be included in this group. Multiple host names should be separated by commas. This directive may be used as an alternative to (or in addition to) the <i>hostgroups</i> directive in <a href="#host">host definitions</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroup_members</strong>:</td>
+
+<td>
+
+This optional directive can be used to include hosts from other "sub" host groups in this host group. Specify a comma-delimited list of short names of other host groups whose members should be included in this group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes</strong>:</td>
+
+<td>
+
+This directive is used to define an optional string of notes pertaining to the host. If you specify a note here, you will see the it in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified host).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes_url</strong>:</td>
+
+<td>
+
+This variable is used to define an optional URL that can be used to provide more information about the host group. If you specify an URL, you will see a red folder icon in the CGIs (when you are viewing hostgroup information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>). This can be very useful if you want to make detailed information on the host group, emergency contact methods, etc. available to other support staff.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>action_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more actions to be performed on the host group. If you specify an URL, you will see a red "splat" icon in the CGIs (when you are viewing hostgroup information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>).
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<p>
+
+<a name="service"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Service Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A service definition is used to identify a "service" that runs on a host. The term "service" is used very loosely. It can mean an actual service that runs on the host (POP, SMTP, HTTP, etc.) or some other type of metric associated with the host (response to a ping, number of logged in users, free disk space, etc.). The different arguments to a service definition are outlined below.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define service{</td></tr>
+
+
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">service_description</td><td class="Required"><i>service_description</i></td></tr>
+
+<tr><td></td><td class="Optional">display_name</td><td class="Optional"><i>display_name</i></td></tr>
+
+<tr><td></td><td class="Optional">servicegroups</td><td class="Optional">servicegroup_names</td></tr>
+
+<tr><td></td><td class="Optional">is_volatile</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">check_command</td><td class="Required"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Optional">initial_state</td><td class="Optional">[o,w,u,c]</td></tr>
+
+<tr><td></td><td class="Required">max_check_attempts</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Required">check_interval</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Required">retry_interval</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Optional">active_checks_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">passive_checks_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">check_period</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Optional">obsess_over_service</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">check_freshness</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">freshness_threshold</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">event_handler</td><td class="Optional"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Optional">event_handler_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">low_flap_threshold</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">high_flap_threshold</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Optional">flap_detection_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">flap_detection_options</td><td class="Optional">[o,w,c,u]</td></tr>
+
+<!--<tr><td></td><td class="Optional">failure_prediction_enabled</td><td class="Optional">[0/1]</td></tr>//-->
+
+<tr><td></td><td class="Optional">process_perf_data</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">retain_status_information</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">retain_nonstatus_information</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">notification_interval</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Optional">first_notification_delay</td><td class="Optional">#</td></tr>
+
+<tr><td></td><td class="Required">notification_period</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Optional">notification_options</td><td class="Optional">[w,u,c,r,f,s]</td></tr>
+
+<tr><td></td><td class="Optional">notifications_enabled</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">contacts</td><td class="Required"><i>contacts</i></td></tr>
+
+<tr><td></td><td class="Required">contact_groups</td><td class="Required"><i>contact_groups</i></td></tr>
+
+<tr><td></td><td class="Optional">stalking_options</td><td class="Optional">[o,w,u,c]</td></tr>
+
+<tr><td></td><td class="Optional">notes</td><td class="Optional"><i>note_string</i></td></tr>
+
+<tr><td></td><td class="Optional">notes_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">action_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image_alt</td><td class="Optional"><i>alt_string</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define service{
+
+ host_name linux-server
+
+ service_description check-disk-sda1
+
+ check_command check-disk!/dev/sda1
+
+ max_check_attempts 5
+
+ check_interval 5
+
+ retry_interval 3
+
+ check_period 24x7
+
+ notification_interval 30
+
+ notification_period 24x7
+
+ notification_options w,c,r
+
+ contact_groups linux-admins
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name(s)</i> of the <a href="#host">host(s)</a> that the service "runs" on or is associated with. Multiple hosts should be separated by commas.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name(s)</i> of the <a href="#hostgroup">hostgroup(s)</a> that the service "runs" on or is associated with. Multiple hostgroups should be separated by commas. The hostgroup_name may be used instead of, or in addition to, the host_name directive.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_description;</strong>:</td>
+
+<td>
+
+This directive is used to define the description of the service, which may contain spaces, dashes, and colons (semicolons, apostrophes, and quotation marks should be avoided). No two services associated with the same host can have the same description. Services are uniquely identified with their <i>host_name</i> and <i>service_description</i> directives.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>display_name</strong>:</td>
+
+<td>
+
+This directive is used to define an alternate name that should be displayed in the web interface for this service. If not specified, this defaults to the value you specify for the <i>service_description</i> directive. Note: The current CGIs do not use this option, although future versions of the web interface will.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>servicegroups</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#servicegroup">servicegroup(s)</a> that the service belongs to. Multiple servicegroups should be separated by commas. This directive may be used as an alternative to using the <i>members</i> directive in <a href="#servicegroup">servicegroup</a> definitions.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>is_volatile</strong>:</td>
+
+<td>
+
+This directive is used to denote whether the service is "volatile". Services are normally <i>not</i> volatile. More information on volatile service and how they differ from normal services can be found <a href="volatileservices.html">here</a>. Value: 0 = service is not volatile, 1 = service is volatile.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_command</strong>:</td>
+
+<td>
+
+<p>
+
+This directive is used to specify the <i>short name</i> of the <a href="#command">command</a> that Nagios will run in order to check the status of the service. The maximum amount of time that the service check command can run is controlled by the <a href="configmain.html#service_check_timeout">service_check_timeout</a> option.</p>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>initial_state</strong>:</td>
+
+<td>
+
+By default Nagios will assume that all services are in OK states when it starts. You can override the initial state for a service by using this directive. Valid options are: <b>o</b> = OK, <b>w</b> = WARNING, <b>u</b> = UNKNOWN, and <b>c</b> = CRITICAL.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>max_check_attempts</strong>:</td>
+
+<td>
+
+This directive is used to define the number of times that Nagios will retry the service check command if it returns any state other than an OK state. Setting this value to 1 will cause Nagios to generate an alert without retrying the service check again.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_interval</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before scheduling the next "regular" check of the service. "Regular" checks are those that occur when the service is in an OK state or when the service is in a non-OK state, but has already been rechecked <b>max_check_attempts</b> number of times. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. More information on this value can be found in the <a href="checkscheduling.html">check scheduling</a> documentation.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retry_interval</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before scheduling a re-check of the service. Services are rescheduled at the retry interval when they have changed to a non-OK state. Once the service has been retried <b>max_check_attempts</b> times without a change in its status, it will revert to being scheduled at its "normal" rate as defined by the <b>check_interval</b> value. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. More information on this value can be found in the <a href="checkscheduling.html">check scheduling</a> documentation.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>active_checks_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not active checks of this service are enabled. Values: 0 = disable active service checks, 1 = enable active service checks (default).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>passive_checks_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not passive checks of this service are enabled. Values: 0 = disable passive service checks, 1 = enable passive service checks (default).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which active checks of this service can be made.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>obsess_over_service <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive determines whether or not checks for the service will be "obsessed" over using the <a href="configmain.html#ocsp_command">ocsp_command</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>check_freshness <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not <a href="freshness.html">freshness checks</a> are enabled for this service. Values: 0 = disable freshness checks, 1 = enable freshness checks (default).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>freshness_threshold</strong>:</td>
+
+<td>
+
+This directive is used to specify the freshness threshold (in seconds) for this service. If you set this directive to a value of 0, Nagios will determine a freshness threshold to use automatically.
+
+</td>
+
+</tr>
+
+<td valign="top"><strong>event_handler</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name</i> of the <a href="#command">command</a> that should be run whenever a change in the state of the service is detected (i.e. whenever it goes down or recovers). Read the documentation on
+
+<a href="eventhandlers.html">event handlers</a> for a more detailed explanation of how to write scripts for handling events. The maximum amount of time that the event handler command can run is controlled by the <a href="configmain.html#event_handler_timeout">event_handler_timeout</a> option.
+
+</td>
+
+<tr>
+
+<td valign="top"><strong>event_handler_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the event handler for this service is enabled. Values: 0 = disable service event handler, 1 = enable service event handler.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>low_flap_threshold</strong>:</td>
+
+<td>
+
+This directive is used to specify the low state change threshold used in flap detection for this service. More information on flap detection can be found <a href="flapping.html">here</a>. If you set this directive to a value of 0, the program-wide value specified by the <a href="configmain.html#low_service_flap_threshold">low_service_flap_threshold</a> directive will be used.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>high_flap_threshold</strong>:</td>
+
+<td>
+
+This directive is used to specify the high state change threshold used in flap detection for this service. More information on flap detection can be found <a href="flapping.html">here</a>. If you set this directive to a value of 0, the program-wide value specified by the <a href="configmain.html#high_service_flap_threshold">high_service_flap_threshold</a> directive will be used.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>flap_detection_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not flap detection is enabled for this service. More information on flap detection can be found <a href="flapping.html">here</a>. Values: 0 = disable service flap detection, 1 = enable service flap detection.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>flap_detection_options</strong>:</td>
+
+<td>
+
+This directive is used to determine what service states the <a href="flapping.html">flap detection logic</a> will use for this service. Valid options are a combination of one or more of the following: <b>o</b> = OK states, <b>w</b> = WARNING states, <b>c</b> = CRITICAL states, <b>u</b> = UNKNOWN states.
+
+</td>
+
+</tr>
+
+<!--
+
+<tr>
+
+<td valign="top"><strong>failure_prediction_enabled</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not failure prediction is enabled for this service. Values: 0 = disable service failure prediction, 1 = enable service failure prediction.
+
+</td>
+
+</tr>
+
+//-->
+
+<tr>
+
+<td valign="top"><strong>process_perf_data <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the processing of performance data is enabled for this service. Values: 0 = disable performance data processing, 1 = enable performance data processing.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retain_status_information</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not status-related information about the service is retained across program restarts. This is only useful if you have enabled state retention using the <a href="configmain.html#retain_state_information">retain_state_information</a> directive. Value: 0 = disable status information retention, 1 = enable status information retention.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retain_nonstatus_information</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not non-status information about the service is retained across program restarts. This is only useful if you have enabled state retention using the <a href="configmain.html#retain_state_information">retain_state_information</a> directive. Value: 0 = disable non-status information retention, 1 = enable non-status information retention.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_interval</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before re-notifying a contact that this service is <i>still</i> in a non-OK state. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. If you set this value to 0, Nagios will <i>not</i> re-notify contacts about problems for this service - only one problem notification will be sent out.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>first_notification_delay</strong>:</td>
+
+<td>
+
+This directive is used to define the number of "time units" to wait before sending out the first problem notification when this service enters a non-OK state. Unless you've changed the <a href="configmain.html#interval_length">interval_length</a> directive from the default value of 60, this number will mean minutes. If you set this value to 0, Nagios will start sending out notifications immediately.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which notifications of events for this service can be sent out to contacts. No service notifications will be sent out during times which is not covered by the time period.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_options</strong>:</td>
+
+<td>
+
+This directive is used to determine when notifications for the service should be sent out. Valid options are a combination of one or more of the following: <b>w</b> = send notifications on a WARNING state, <b>u</b> = send notifications on an UNKNOWN state, <b>c</b> = send notifications on a CRITICAL state, <b>r</b> = send notifications on recoveries (OK state), <b>f</b> = send notifications when the service starts and stops <a href="flapping.html">flapping</a>, and <b>s</b> = send notifications when <a href="downtime.html">scheduled downtime</a> starts and ends. If you specify <b>n</b> (none) as an option, no service notifications will be sent out. If you do not specify any notification options, Nagios will assume that you want notifications to be sent out for all possible states. Example: If you specify <b>w,r</b> in this field, notifications will only be sent out when the service goes into a WARNING state and when it recovers from a WARNING state.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notifications_enabled <a href="#retention_notes" class="RetentionNotes">*</a></strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not notifications for this service are enabled. Values: 0 = disable service notifications, 1 = enable service notifications.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contacts</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of the <a href="#contact">contacts</a> that should be notified whenever there are problems (or recoveries) with this service. Multiple contacts should be separated by commas. Useful if you want notifications to go to just a few people and don't want to configure <a href="#contactgroup">contact groups</a>. You must specify at least one contact or contact group in each service definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contact_groups</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of the <a href="#contactgroup">contact groups</a> that should be notified whenever there are problems (or recoveries) with this service. Multiple contact groups should be separated by commas. You must specify at least one contact or contact group in each service definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>stalking_options</strong>:</td>
+
+<td>
+
+This directive determines which service states "stalking" is enabled for. Valid options are a combination of one or more of the following: <b>o</b> = stalk on OK states, <b>w</b> = stalk on WARNING states, <b>u</b> = stalk on UNKNOWN states, and <b>c</b> = stalk on CRITICAL states. More information on state stalking can be found <a href="stalking.html">here</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes</strong>:</td>
+
+<td>
+
+This directive is used to define an optional string of notes pertaining to the service. If you specify a note here, you will see the it in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified service).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more information about the service. If you specify an URL, you will see a red folder icon in the CGIs (when you are viewing service information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>). This can be very useful if you want to make detailed information on the service, emergency contact methods, etc. available to other support staff.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>action_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more actions to be performed on the service. If you specify an URL, you will see a red "splat" icon in the CGIs (when you are viewing service information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of a GIF, PNG, or JPG image that should be associated with this service. This image will be displayed in the <a href="cgis.html#status_cgi">status</a> and <a href="cgis.html#extinfo_cgi">extended information</a> CGIs. The image will look best if it is 40x40 pixels in size. Images for services are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image_alt</strong>:</td>
+
+<td>
+
+This variable is used to define an optional string that is used in the ALT tag of the image specified by the <i><icon_image></i> argument. The ALT tag is used in the <a href="cgis.html#status_cgi">status</a>, <a href="cgis.html#extinfo_cgi">extended information</a> and <a href="cgis.html#statusmap_cgi">statusmap</a> CGIs.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+
+
+<p>
+
+<a name="servicegroup"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Service Group Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A service group definition is used to group one or more services together for simplifying configuration with <a href="objecttricks.html">object tricks</a> or display purposes in the <a href="cgis.html">CGIs</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define servicegroup{</td></tr>
+
+
+
+<tr><td></td><td class="Required">servicegroup_name</td><td class="Required"><i>servicegroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">alias</td><td class="Required"><i>alias</i></td></tr>
+
+<tr><td></td><td class="Optional">members</td><td class="Optional"><i>services</i></td></tr>
+
+<tr><td></td><td class="Optional">servicegroup_members</td><td class="Optional"><i>servicegroups</i></td></tr>
+
+<tr><td></td><td class="Optional">notes</td><td class="Optional"><i>note_string</i></td></tr>
+
+<tr><td></td><td class="Optional">notes_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">action_url</td><td class="Optional"><i>url</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define servicegroup{
+
+ servicegroup_name dbservices
+
+ alias Database Services
+
+ members ms1,SQL Server,ms1,SQL Server Agent,ms1,SQL DTC
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>servicegroup_name</strong>:</td>
+
+<td>
+
+This directive is used to define a short name used to identify the service group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>alias</strong>:</td>
+
+<td>
+
+This directive is used to define is a longer name or description used to identify the service group. It is provided in order to allow you to more easily identify a particular service group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>members</strong>:</td>
+
+<td>
+
+<p>
+
+This is a list of the <i>descriptions</i> of <a href="#service">services</a> (and the names of their corresponding hosts) that should be included in this group. Host and service names should be separated by commas. This directive may be used as an alternative to the <i>servicegroups</i> directive in <a href="#service">service definitions</a>. The format of the member directive is as follows (note that a host name must precede a service name/description):
+
+</p>
+
+<p>
+
+members=<host1>,<service1>,<host2>,<service2>,...,<host<i>n</i>>,<service<i>n</i>>
+
+</p>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>servicegroup_members</strong>:</td>
+
+<td>
+
+This optional directive can be used to include services from other "sub" service groups in this service group. Specify a comma-delimited list of short names of other service groups whose members should be included in this group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes</strong>:</td>
+
+<td>
+
+This directive is used to define an optional string of notes pertaining to the service group. If you specify a note here, you will see the it in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified service group).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more information about the service group. If you specify an URL, you will see a red folder icon in the CGIs (when you are viewing service group information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>). This can be very useful if you want to make detailed information on the service group, emergency contact methods, etc. available to other support staff.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>action_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more actions to be performed on the service group. If you specify an URL, you will see a red "splat" icon in the CGIs (when you are viewing service group information) that links to the URL you specify here. Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>).
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+
+
+<p>
+
+<a name="contact"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Contact Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A contact definition is used to identify someone who should be contacted in the event of a problem on your network.
+
+The different arguments to a contact definition are described below.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define contact{</td></tr>
+
+
+
+<tr><td></td><td class="Required">contact_name</td><td class="Required"><i>contact_name</i></td></tr>
+
+<tr><td></td><td class="Optional">alias</td><td class="Optional"><i>alias</i></td></tr>
+
+<tr><td></td><td class="Optional">contactgroups</td><td class="Optional"><i>contactgroup_names</i></td></tr>
+
+<tr><td></td><td class="Required">host_notifications_enabled</td><td class="Required">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">service_notifications_enabled</td><td class="Required">[0/1]</td></tr>
+
+<tr><td></td><td class="Required">host_notification_period</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Required">service_notification_period</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Required">host_notification_options</td><td class="Required">[d,u,r,f,s,n]</td></tr>
+
+<tr><td></td><td class="Required">service_notification_options</td><td class="Required">[w,u,c,r,f,s,n]</td></tr>
+
+<tr><td></td><td class="Required">host_notification_commands</td><td class="Required"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Required">service_notification_commands</td><td class="Required"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Optional">email</td><td class="Optional"><i>email_address</i></td></tr>
+
+<tr><td></td><td class="Optional">pager</td><td class="Optional"><i>pager_number or pager_email_gateway</i></td></tr>
+
+<tr><td></td><td class="Optional">address<i>x</i></td><td class="Optional"><i>additional_contact_address</i></td></tr>
+
+<tr><td></td><td class="Optional">can_submit_commands</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">retain_status_information</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">retain_nonstatus_information</td><td class="Optional">[0/1]</td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define contact{
+
+ contact_name jdoe
+
+ alias John Doe
+
+ host_notifications_enabled 1
+
+ service_notifications_enabled 1
+
+ service_notification_period 24x7
+
+ host_notification_period 24x7
+
+ service_notification_options w,u,c,r
+
+ host_notification_options d,u,r
+
+ service_notification_commands notify-by-email
+
+ host_notification_commands host-notify-by-email
+
+ email jdoe@localhost.localdomain
+
+ pager 555-5555@pagergateway.localhost.localdomain
+
+ address1 xxxxx.xyyy@icq.com
+
+ address2 555-555-5555
+
+ can_submit_commands 1
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>contact_name</strong>:</td>
+
+<td>
+
+This directive is used to define a short name used to identify the contact. It is referenced in <a href="#contactgroup">contact group</a> definitions. Under the right circumstances, the $CONTACTNAME$ <a href="macros.html">macro</a> will contain this
+
+value.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>alias</strong>:</td>
+
+<td>
+
+This directive is used to define a longer name or description for the contact. Under the rights circumstances, the $CONTACTALIAS$ <a href="macros.html">macro</a> will contain this value. If not specified, the <i>contact_name</i> will be used as the alias.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contactgroups</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#contactgroup">contactgroup(s)</a> that the contact belongs to. Multiple contactgroups should be separated by commas. This directive may be used as an alternative to (or in addition to) using the <i>members</i> directive in <a href="#contactgroup">contactgroup</a> definitions.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>host_notifications_enabled</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the contact will receive notifications about host problems and recoveries. Values: 0 = don't send notifications, 1 = send notifications.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_notifications_enabled</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the contact will receive notifications about service problems and recoveries. Values: 0 = don't send notifications, 1 = send notifications.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>host_notification_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which the contact can be notified about host problems or recoveries. You can think of this as an "on call" time for host notifications for the contact. Read the documentation on <a href="timeperiods.html">time periods</a> for more information on how this works and potential problems that may result from improper use.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_notification_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which the contact can be notified about service problems or recoveries. You can think of this as an "on call" time for service notifications for the contact. Read the documentation on <a href="timeperiods.html">time periods</a> for more information on how this works and potential problems that may result from improper use.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>host_notification_commands</strong>:</td>
+
+<td>
+
+This directive is used to define a list of the <i>short names</i> of the <a href="#command">commands</a> used to notify the contact of a <i>host</i> problem or recovery. Multiple notification commands should be separated by commas. All
+
+notification commands are executed when the contact needs to be notified. The maximum amount of time that a notification command can run is controlled by the <a href="configmain.html#notification_timeout">notification_timeout</a> option.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>host_notification_options</strong>:</td>
+
+<td>
+
+This directive is used to define the host states for which notifications can be sent out to this contact. Valid options are a combination of one or more of the following: <b>d</b> = notify on DOWN host states, <b>u</b> = notify on UNREACHABLE host states, <b>r</b> = notify on host recoveries (UP states), <b>f</b> = notify when the host starts and stops <a href="flapping.html">flapping</a>, and <b>s</b> = send notifications when host or service <a href="downtime.html">scheduled downtime</a> starts and ends. If you specify <b>n</b> (none) as an option, the contact will not receive any type of host notifications.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_notification_options</strong>:</td>
+
+<td>
+
+This directive is used to define the service states for which notifications can be sent out to this contact. Valid options are a combination of one or more of the following: <b>w</b> = notify on WARNING service states, <b>u</b> = notify on UNKNOWN service states, <b>c</b> = notify on CRITICAL service states, <b>r</b> = notify on service recoveries (OK states), and <b>f</b> = notify when the service starts and stops <a href="flapping.html">flapping</a>. If you specify <b>n</b> (none) as an option, the contact will not receive any type of service notifications.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_notification_commands</strong>:</td>
+
+<td>
+
+This directive is used to define a list of the <i>short names</i> of the <a href="#command">commands</a> used to notify the contact of a <i>service</i> problem or recovery. Multiple notification commands should be separated by commas. All
+
+notification commands are executed when the contact needs to be notified. The maximum amount of time that a notification command can run is controlled by the <a href="configmain.html#notification_timeout">notification_timeout</a> option.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>email</strong>:</td>
+
+<td>
+
+This directive is used to define an email address for the contact. Depending on how you configure your notification commands, it can be used to send out an alert email to the contact. Under the right circumstances, the $CONTACTEMAIL$
+
+<a href="macros.html">macro</a> will contain this value.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>pager</strong>:</td>
+
+<td>
+
+This directive is used to define a pager number for the contact. It can also be an email address to a pager gateway
+
+(i.e. pagejoe@pagenet.com). Depending on how you configure your notification commands, it can be used to send out an alert page to the contact. Under the right circumstances, the $CONTACTPAGER$ <a href="macros.html">macro</a> will contain this value.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>address<i>x</i></strong>:</td>
+
+<td>
+
+Address directives are used to define additional "addresses" for the contact. These addresses can be anything - cell phone numbers, instant messaging addresses, etc. Depending on how you configure your notification commands, they can be used to send out an alert to the contact. Up to six addresses can be defined using these directives (<i>address1</i> through <i>address6</i>). The $CONTACTADDRESS<i>x</i>$ <a href="macros.html">macro</a> will contain this value.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>can_submit_commands</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not the contact can submit <a href="extcommands.html">external commands</a> to Nagios from the CGIs. Values: 0 = don't allow contact to submit commands, 1 = allow contact to submit commands.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retain_status_information</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not status-related information about the contact is retained across program restarts. This is only useful if you have enabled state retention using the <a href="configmain.html#retain_state_information">retain_state_information</a> directive. Value: 0 = disable status information retention, 1 = enable status information retention.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>retain_nonstatus_information</strong>:</td>
+
+<td>
+
+This directive is used to determine whether or not non-status information about the contact is retained across program restarts. This is only useful if you have enabled state retention using the <a href="configmain.html#retain_state_information">retain_state_information</a> directive. Value: 0 = disable non-status information retention, 1 = enable non-status information retention.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<p>
+
+<a name="contactgroup"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Contact Group Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A contact group definition is used to group one or more <a href="#contact">contacts</a> together for the purpose of sending out alert/recovery <a href="notifications.html">notifications</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define contactgroup{</td></tr>
+
+
+
+<tr><td></td><td class="Required">contactgroup_name</td><td class="Required"><i>contactgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">alias</td><td class="Required"><i>alias</i></td></tr>
+
+<tr><td></td><td class="Optional">members</td><td class="Optional"><i>contacts</i></td></tr>
+
+<tr><td></td><td class="Optional">contactgroup_members</td><td class="Optional"><i>contactgroups</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define contactgroup{
+
+ contactgroup_name novell-admins
+
+ alias Novell Administrators
+
+ members jdoe,rtobert,tzach
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>contactgroup_name</strong>:</td>
+
+<td>
+
+This directive is a short name used to identify the contact group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>alias</strong>:</td>
+
+<td>
+
+This directive is used to define a longer name or description used to identify the contact group.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>members</strong>:</td>
+
+<td>
+
+This optional directive is used to define a list of the <i>short names</i> of <a href="#contact">contacts </a> that should be included in this group. Multiple contact names should be separated by commas. This directive may be used as an alternative to (or in addition to) using the <i>contactgroups</i> directive in <a href="#contact">contact</a> definitions.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contactgroup_members</strong>:</td>
+
+<td>
+
+This optional directive can be used to include contacts from other "sub" contact groups in this contact group. Specify a comma-delimited list of short names of other contact groups whose members should be included in this group.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<a name="timeperiod"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Time Period Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A time period is a list of times during various days that are considered to be "valid" times for notifications and service checks. It consists of time ranges for each day of the week that "rotate" once the week has come to an end. Different types of exceptions to the normal weekly time are supported, including: specific weekdays, days of generic months, days of specific months, and calendar dates.
+
+</p>
+
+
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define timeperiod{</td></tr>
+
+
+
+<tr><td></td><td class="Required">timeperiod_name</td><td class="Required"><i>timeperiod_name</i></td></tr>
+
+<tr><td></td><td class="Required">alias</td><td class="Required"><i>alias</i></td></tr>
+
+<tr><td></td><td class="Optional">[weekday]</td><td class="Optional"><i>timeranges</i></td></tr>
+
+<tr><td></td><td class="Optional">[exception]</td><td class="Optional"><i>timeranges</i></td></tr>
+
+<tr><td></td><td class="Optional">exclude</td><td class="Optional">[<i>timeperiod1,timeperiod2,...,timeperiodn</i>]</td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definitions:</p>
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name nonworkhours
+
+ alias Non-Work Hours
+
+ sunday 00:00-24:00 ; Every Sunday of every week
+
+ monday 00:00-09:00,17:00-24:00 ; Every Monday of every week
+
+ tuesday 00:00-09:00,17:00-24:00 ; Every Tuesday of every week
+
+ wednesday 00:00-09:00,17:00-24:00 ; Every Wednesday of every week
+
+ thursday 00:00-09:00,17:00-24:00 ; Every Thursday of every week
+
+ friday 00:00-09:00,17:00-24:00 ; Every Friday of every week
+
+ saturday 00:00-24:00 ; Every Saturday of every week
+
+ }
+
+
+
+define timeperiod{
+
+ timeperiod_name misc-single-days
+
+ alias Misc Single Days
+
+ 1999-01-28 00:00-24:00 ; January 28th, 1999
+
+ monday 3 00:00-24:00 ; 3rd Monday of every month
+
+ day 2 00:00-24:00 ; 2nd day of every month
+
+ february 10 00:00-24:00 ; February 10th of every year
+
+ february -1 00:00-24:00 ; Last day in February of every year
+
+ friday -2 00:00-24:00 ; 2nd to last Friday of every month
+
+ thursday -1 november 00:00-24:00 ; Last Thursday in November of every year
+
+ }
+
+
+
+define timeperiod{
+
+ timeperiod_name misc-date-ranges
+
+ alias Misc Date Ranges
+
+ 2007-01-01 - 2008-02-01 00:00-24:00 ; January 1st, 2007 to February 1st, 2008
+
+ monday 3 - thursday 4 00:00-24:00 ; 3rd Monday to 4th Thursday of every month
+
+ day 1 - 15 00:00-24:00 ; 1st to 15th day of every month
+
+ day 20 - -1 00:00-24:00 ; 20th to the last day of every month
+
+ july 10 - 15 00:00-24:00 ; July 10th to July 15th of every year
+
+ april 10 - may 15 00:00-24:00 ; April 10th to May 15th of every year
+
+ tuesday 1 april - friday 2 may 00:00-24:00 ; 1st Tuesday in April to 2nd Friday in May of every year
+
+ }
+
+
+
+define timeperiod{
+
+ timeperiod_name misc-skip-ranges
+
+ alias Misc Skip Ranges
+
+ 2007-01-01 - 2008-02-01 / 3 00:00-24:00 ; Every 3 days from January 1st, 2007 to February 1st, 2008
+
+ 2008-04-01 / 7 00:00-24:00 ; Every 7 days from April 1st, 2008 (continuing forever)
+
+ monday 3 - thursday 4 / 2 00:00-24:00 ; Every other day from 3rd Monday to 4th Thursday of every month
+
+ day 1 - 15 / 5 00:00-24:00 ; Every 5 days from the 1st to the 15th day of every month
+
+ july 10 - 15 / 2 00:00-24:00 ; Every other day from July 10th to July 15th of every year
+
+ tuesday 1 april - friday 2 may / 6 00:00-24:00 ; Every 6 days from the 1st Tuesday in April to the 2nd Friday in May of every year
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>timeperiod_name</strong>:</td>
+
+<td>
+
+This directives is the short name used to identify the time period.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>alias</strong>:</td>
+
+<td>
+
+This directive is a longer name or description used to identify the time period.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>[<i>weekday</i>]</strong>:</td>
+
+<td>
+
+The weekday directives ("<i>sunday</i>" through "<i>saturday</i>")are comma-delimited lists of time ranges that are "valid" times for a particular day of the week. Notice that there are seven different days for which you can define time ranges (Sunday through Saturday). Each time range is in the form of <b>HH:MM-HH:MM</b>, where hours are specified on a 24 hour clock. For example, <b>00:15-24:00</b> means 12:15am in the morning for this day until 12:00am midnight (a 23 hour, 45 minute total time range). If you wish to exclude an entire day from the timeperiod, simply do not include it in the timeperiod definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>[<i>exception</i>]</strong>:</td>
+
+<td>
+
+<p>
+
+You can specify several different types of exceptions to the standard rotating weekday schedule. Exceptions can take a number of different forms including single days of a specific or generic month, single weekdays in a month, or single calendar dates. You can also specify a range of days/dates and even specify skip intervals to obtain functionality described by "every 3 days between these dates". Rather than list all the possible formats for exception strings, I'll let you look at the example timeperiod definitions above to see what's possible. :-) Weekdays and different types of exceptions all have different levels of precedence, so its important to understand how they can affect each other. More information on this can be found in the documentation on <a href="timeperiods.html">timeperiods</a>.
+
+</p>
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>exclude</strong>:</td>
+
+<td>
+
+This directive is used to specify the short names of other timeperiod definitions whose time ranges should be excluded from this timeperiod. Multiple timeperiod names should be separated with a comma.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<a name="command"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Command Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+A command definition is just that. It defines a command. Commands that can be defined include service checks, service notifications, service event handlers, host checks, host notifications, and host event handlers. Command definitions can contain <a href="macros.html">macros</a>, but you must make sure that you include only those macros that are "valid" for the circumstances when the command will be used. More information on what macros are available and when they are "valid" can be found <a href="macros.html">here</a>. The different arguments to a command definition are outlined below.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define command{</td></tr>
+
+
+
+<tr><td></td><td class="Required">command_name</td><td class="Required"><i>command_name</i></td></tr>
+
+<tr><td></td><td class="Required">command_line</td><td class="Required"><i>command_line</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define command{
+
+ command_name check_pop
+
+ command_line /usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>command_name</strong>:</td>
+
+<td>
+
+This directive is the short name used to identify the command. It is referenced in <a href="#contact">contact</a>, <a href="#host">host</a>, and <a href="#service">service</a> definitions (in notification, check, and event handler directives), among other places.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>command_line</strong>:</td>
+
+<td>
+
+<p>
+
+This directive is used to define what is actually executed by Nagios when the command is used for service or host checks, notifications, or <a href="eventhandlers.html">event handlers</a>. Before the command line is executed, all valid <a href="macros.html">macros</a> are replaced with their respective values. See the documentation on macros for determining when you can use different macros. Note that the command line is <i>not</i> surrounded in quotes. Also, if you want to pass a dollar sign ($) on the command line, you have to escape it with another dollar sign.
+
+</p>
+
+<p><strong>NOTE</strong>: You may not include a <b>semicolon</b> (;) in the <i>command_line</i> directive, because everything after it will be ignored as a config file comment. You can work around this limitation by setting one of the <a href="macros.html#user"><b>$USER$</b></a> macros in your <a
+
+href="configmain.html#resource_file">resource file</a> to a semicolon and then referencing the appropriate $USER$ macro in the <i>command_line</i> directive in place of the semicolon.
+
+</p>
+
+<p>
+
+If you want to pass arguments to commands during runtime, you can use <a href="macros.html#arg"><b>$ARGn$</b> macros</a> in the <i>command_line</i> directive of the command definition and then separate individual arguments from the command name (and from each other) using bang (!) characters in the object definition directive (host check command, service event handler command, etc) that references the command. More information on how arguments in command definitions are processed during runtime can be found in the documentation on <a href="macros.html">macros</a>.
+
+</p>
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<a name="servicedependency"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Service Dependency Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+Service dependencies are an advanced feature of Nagios that allow you to suppress notifications and active checks of services based on the status of one or more other services. Service dependencies are optional and are mainly targeted at advanced users who have complicated monitoring setups. More information on how service dependencies work (read this!) can be found <a href="dependencies.html">here</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional. However, you must supply at least one type of criteria for the definition to be of much use.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define servicedependency{</td></tr>
+
+
+
+<tr><td></td><td class="Required">dependent_host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">dependent_hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">dependent_service_description</td><td class="Required"><i>service_description</i></td></tr>
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">service_description</td><td class="Required"><i>service_description</i></td></tr>
+
+<tr><td></td><td class="Optional">inherits_parent</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">execution_failure_criteria</td><td class="Optional">[o,w,u,c,p,n]</td></tr>
+
+<tr><td></td><td class="Optional">notification_failure_criteria</td><td class="Optional">[o,w,u,c,p,n]</td></tr>
+
+<tr><td></td><td class="Optional">dependency_period</td><td class="Optional">timeperiod_name</td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define servicedependency{
+
+ host_name WWW1
+
+ service_description Apache Web Server
+
+ dependent_host_name WWW1
+
+ dependent_service_description Main Web Site
+
+ execution_failure_criteria n
+
+ notification_failure_criteria w,u,c
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>dependent_host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#host">host(s)</a> that the <i>dependent</i> service "runs" on or is associated with. Multiple hosts should be separated by commas. Leaving this directive blank can be used to create <a href="objecttricks.html#same_host_dependency">"same host" dependencies</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>dependent_hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name(s)</i> of the <a href="#hostgroup">hostgroup(s)</a> that the <i>dependent</i> service "runs" on or is associated with. Multiple hostgroups should be separated by commas. The dependent_hostgroup may be used instead of, or in addition to, the dependent_host directive.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>dependent_service_description</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>description</i> of the <i>dependent</i> <a href="#service">service</a>.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#host">host(s)</a> that the service <i>that is being depended upon</i> (also referred to as the master service) "runs" on or is associated with. Multiple hosts should be separated by commas.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#host">hostgroup(s)</a> that the service <i>that is being depended upon</i> (also referred to as the master service) "runs" on or is associated with. Multiple hostgroups should be separated by commas. The hostgroup_name may be used instead of, or in addition to, the host_name directive.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_description</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>description</i> of the <a href="#service">service</a> <i>that is being depended upon</i> (also referred to as the master service).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>inherits_parent</strong>:</td>
+
+<td>
+
+This directive indicates whether or not the dependency inherits dependencies of the service <i>that is being depended upon</i> (also referred to as the master service). In other words, if the master service is dependent upon other services and any one of those dependencies fail, this dependency will also fail.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>execution_failure_criteria</strong>:</td>
+
+<td>
+
+This directive is used to specify the criteria that determine when the dependent service should <i>not</i> be actively checked. If the <i>master</i> service is in one of the failure states we specify, the <i>dependent</i> service will not be actively checked. Valid options are a combination of one or more of the following (multiple options are separated with commas): <b>o</b> = fail on an OK state, <b>w</b> = fail on a WARNING state, <b>u</b> = fail on an UNKNOWN state, <b>c</b> = fail on a CRITICAL state, and <b>p</b> = fail on a pending state (e.g. the service has not yet been checked). If you specify <b>n</b> (none) as an option, the execution dependency will never fail and checks of the dependent service will always be actively checked (if other conditions allow for it to be). Example: If you specify <b>o,c,u</b> in this field, the <i>dependent</i> service will not be actively checked if the <i>master</i> service is in either an OK, a CRITICAL, or an UNKNOWN state.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_failure_criteria</strong>:</td>
+
+<td>
+
+This directive is used to define the criteria that determine when notifications for the dependent service should <i>not</i> be sent out. If the <i>master</i> service is in one of the failure states we specify, notifications for the <i>dependent</i> service will not be sent to contacts. Valid options are a combination of one or more of the following: <b>o</b> = fail on an OK state, <b>w</b> = fail on a WARNING state, <b>u</b> = fail on an UNKNOWN state, <b>c</b> = fail on a CRITICAL state, and <b>p</b> = fail on a pending state (e.g. the service has not yet been checked). If you specify <b>n</b> (none) as an option, the notification dependency will never fail and notifications for the dependent service will always be sent out. Example: If you specify <b>w</b> in this field, the notifications for the <i>dependent</i> service will not be sent out if the <i>master</i> service is in a WARNING state.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>dependency_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which this dependency is valid. If this directive is not specified, the dependency is considered to be valid during all times.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<a name="serviceescalation"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Service Escalation Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+Service escalations are <i>completely optional</i> and are used to escalate notifications for a particular service. More information on how notification escalations work can be found <a href="escalations.html">here</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define serviceescalation{</td></tr>
+
+
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">service_description</td><td class="Required"><i>service_description</i></td></tr>
+
+<tr><td></td><td class="Required">contacts</td><td class="Required"><i>contacts</i></td></tr>
+
+<tr><td></td><td class="Required">contact_groups</td><td class="Required"><i>contactgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">first_notification</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Required">last_notification</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Required">notification_interval</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Optional">escalation_period</td><td class="Optional">timeperiod_name</td></tr>
+
+<tr><td></td><td class="Optional">escalation_options</td><td class="Optional">[w,u,c,r]</td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define serviceescalation{
+
+ host_name nt-3
+
+ service_description Processor Load
+
+ first_notification 4
+
+ last_notification 0
+
+ notification_interval 30
+
+ contact_groups all-nt-admins,themanagers
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#host">host(s)</a> that the <a href="#service">service</a> escalation should apply to or is associated with.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to specify the <i>short name(s)</i> of the <a href="#hostgroup">hostgroup(s)</a> that the service escalation should apply to or is associated with. Multiple hostgroups should be separated by commas. The hostgroup_name may be used instead of, or in addition to, the host_name directive.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_description</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>description</i> of the <a href="#service">service</a> the escalation should apply to.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>first_notification</strong>:</td>
+
+<td>
+
+This directive is a number that identifies the <i>first</i> notification for which this escalation is effective. For instance, if you set this value to 3, this escalation will only be used if the service is in a non-OK state long enough for a third notification to go out.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>last_notification</strong>:</td>
+
+<td>
+
+This directive is a number that identifies the <i>last</i> notification for which this escalation is effective. For instance, if you set this value to 5, this escalation will not be used if more than five notifications are sent out for the service. Setting this value to 0 means to keep using this escalation entry forever (no matter how many notifications go out).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contacts</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of the <a href="#contact">contacts</a> that should be notified whenever there are problems (or recoveries) with this service. Multiple contacts should be separated by commas. Useful if you want notifications to go to just a few people and don't want to configure <a href="#contactgroup">contact groups</a>. You must specify at least one contact or contact group in each service escalation definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contact_groups</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name</i> of the <a href="#contactgroup">contact group</a> that should be notified when the service notification is escalated. Multiple contact groups should be separated by commas. You must specify at least one contact or contact group in each service escalation definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_interval</strong>:</td>
+
+<td>
+
+This directive is used to determine the interval at which notifications should be made while this escalation is valid. If you specify a value of 0 for the interval, Nagios will send the first notification when this escalation definition is valid, but will then prevent any more problem notifications from being sent out for the host. Notifications are sent out again until the host recovers. This is useful if you want to stop having notifications sent out after a certain amount of time. Note: If multiple escalation entries for a host overlap for one or more notification ranges, the smallest notification interval from all escalation entries is used.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>escalation_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which this escalation is valid. If this directive is not specified, the escalation is considered to be valid during all times.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>escalation_options</strong>:</td>
+
+<td>
+
+This directive is used to define the criteria that determine when this service escalation is used. The escalation is used only if the service is in one of the states specified in this directive. If this directive is not specified in a service escalation, the escalation is considered to be valid during all service states. Valid options are a combination of one or more of the following: <b>r</b> = escalate on an OK (recovery) state, <b>w</b> = escalate on a WARNING state, <b>u</b> = escalate on an UNKNOWN state, and <b>c</b> = escalate on a CRITICAL state. Example: If you specify <b>w</b> in this field, the escalation will only be used if the service is in a WARNING state.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<p>
+
+<a name="hostdependency"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Host Dependency Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+Host dependencies are an advanced feature of Nagios that allow you to suppress notifications for hosts based on the status of one or more other hosts. Host dependencies are optional and are mainly targeted at advanced users who have complicated monitoring setups. More information on how host dependencies work (read this!) can be found <a href="dependencies.html">here</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define hostdependency{</td></tr>
+
+
+
+<tr><td></td><td class="Required">dependent_host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">dependent_hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Optional">inherits_parent</td><td class="Optional">[0/1]</td></tr>
+
+<tr><td></td><td class="Optional">execution_failure_criteria</td><td class="Optional">[o,d,u,p,n]</td></tr>
+
+<tr><td></td><td class="Optional">notification_failure_criteria</td><td class="Optional">[o,d,u,p,n]</td></tr>
+
+<tr><td></td><td class="Optional">dependency_period</td><td class="Optional">timeperiod_name</td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define hostdependency{
+
+ host_name WWW1
+
+ dependent_host_name DBASE1
+
+ notification_failure_criteria d,u
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>dependent_host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <i>dependent</i> <a href="#host">host(s)</a>. Multiple hosts should be separated by commas.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>dependent_hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <i>dependent</i> <a href="#host">hostgroup(s)</a>. Multiple hostgroups should be separated by commas. The dependent_hostgroup_name may be used instead of, or in addition to, the dependent_host_name directive.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#host">host(s)</a> <i>that is being depended upon</i> (also referred to as the master host). Multiple hosts should be separated by commas.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#host">hostgroup(s)</a> <i>that is being depended upon</i> (also referred to as the master host). Multiple hostgroups should be separated by commas. The hostgroup_name may be used instead of, or in addition to, the host_name directive.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>inherits_parent</strong>:</td>
+
+<td>
+
+This directive indicates whether or not the dependency inherits dependencies of the host <i>that is being depended upon</i> (also referred to as the master host). In other words, if the master host is dependent upon other hosts and any one of those dependencies fail, this dependency will also fail.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>execution_failure_criteria</strong>:</td>
+
+<td>
+
+This directive is used to specify the criteria that determine when the dependent host should <i>not</i> be actively checked. If the <i>master</i> host is in one of the failure states we specify, the <i>dependent</i> host will not be actively checked. Valid options are a combination of one or more of the following (multiple options are separated with commas): <b>o</b> = fail on an UP state, <b>d</b> = fail on a DOWN state, <b>u</b> = fail on an UNREACHABLE state, and <b>p</b> = fail on a pending state (e.g. the host has not yet been checked). If you specify <b>n</b> (none) as an option, the execution dependency will never fail and the dependent host will always be actively checked (if other conditions allow for it to be). Example: If you specify <b>u,d</b> in this field, the <i>dependent</i> host will not be actively checked if the <i>master</i> host is in either an UNREACHABLE or DOWN state.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_failure_criteria</strong>:</td>
+
+<td>
+
+This directive is used to define the criteria that determine when notifications for the dependent host should <i>not</i> be sent out. If the <i>master</i> host is in one of the failure states we specify, notifications for the <i>dependent</i> host will not be sent to contacts. Valid options are a combination of one or more of the following: <b>o</b> = fail on an UP state, <b>d</b> = fail on a DOWN state, <b>u</b> = fail on an UNREACHABLE state, and <b>p</b> = fail on a pending state (e.g. the host has not yet been checked). If you specify <b>n</b> (none) as an option, the notification dependency will never fail and notifications for the dependent host will always be sent out. Example: If you specify <b>d</b> in this field, the notifications for the <i>dependent</i> host will not be sent out if the <i>master</i> host is in a DOWN state.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>dependency_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which this dependency is valid. If this directive is not specified, the dependency is considered to be valid during all times.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<a name="hostescalation"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Host Escalation Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+Host escalations are <i>completely optional</i> and are used to escalate notifications for a particular host. More information on how notification escalations work can be found <a href="escalations.html">here</a>.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Directives in red are required, while those in black are optional.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define hostescalation{</td></tr>
+
+
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">hostgroup_name</td><td class="Optional"><i>hostgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">contacts</td><td class="Required"><i>contacts</i></td></tr>
+
+<tr><td></td><td class="Required">contact_groups</td><td class="Required"><i>contactgroup_name</i></td></tr>
+
+<tr><td></td><td class="Required">first_notification</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Required">last_notification</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Required">notification_interval</td><td class="Required">#</td></tr>
+
+<tr><td></td><td class="Optional">escalation_period</td><td class="Optional">timeperiod_name</td></tr>
+
+<tr><td></td><td class="Optional">escalation_options</td><td class="Optional">[d,u,r]</td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define hostescalation{
+
+ host_name router-34
+
+ first_notification 5
+
+ last_notification 8
+
+ notification_interval 60
+
+ contact_groups all-router-admins
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Directive Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name</i> of the <a href="#host">host</a> that the escalation should apply to.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>hostgroup_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name(s)</i> of the <a href="#hostgroup">hostgroup(s)</a> that the escalation should apply to. Multiple hostgroups should be separated by commas. If this is used, the escalation will apply to all hosts that are members of the specified hostgroup(s).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>first_notification</strong>:</td>
+
+<td>
+
+This directive is a number that identifies the <i>first</i> notification for which this escalation is effective. For instance, if you set this value to 3, this escalation will only be used if the host is down or unreachable long enough for a third notification to go out.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>last_notification</strong>:</td>
+
+<td>
+
+This directive is a number that identifies the <i>last</i> notification for which this escalation is effective. For instance, if you set this value to 5, this escalation will not be used if more than five notifications are sent out for the host. Setting this value to 0 means to keep using this escalation entry forever (no matter how many notifications go out).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contacts</strong>:</td>
+
+<td>
+
+This is a list of the <i>short names</i> of the <a href="#contact">contacts</a> that should be notified whenever there are problems (or recoveries) with this host. Multiple contacts should be separated by commas. Useful if you want notifications to go to just a few people and don't want to configure <a href="#contactgroup">contact groups</a>. You must specify at least one contact or contact group in each host escalation definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>contact_groups</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name</i> of the <a href="#contactgroup">contact group</a> that should be notified when the host notification is escalated. Multiple contact groups should be separated by commas. You must specify at least one contact or contact group in each host escalation definition.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notification_interval</strong>:</td>
+
+<td>
+
+This directive is used to determine the interval at which notifications should be made while this escalation is valid. If you specify a value of 0 for the interval, Nagios will send the first notification when this escalation definition is valid, but will then prevent any more problem notifications from being sent out for the host. Notifications are sent out again until the host recovers. This is useful if you want to stop having notifications sent out after a certain amount of time. Note: If multiple escalation entries for a host overlap for one or more notification ranges, the smallest notification interval from all escalation entries is used.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>escalation_period</strong>:</td>
+
+<td>
+
+This directive is used to specify the short name of the <a href="#timeperiod">time period</a> during which this escalation is valid. If this directive is not specified, the escalation is considered to be valid during all times.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>escalation_options</strong>:</td>
+
+<td>
+
+This directive is used to define the criteria that determine when this host escalation is used. The escalation is used only if the host is in one of the states specified in this directive. If this directive is not specified in a host escalation, the escalation is considered to be valid during all host states. Valid options are a combination of one or more of the following: <b>r</b> = escalate on an UP (recovery) state, <b>d</b> = escalate on a DOWN state, and <b>u</b> = escalate on an UNREACHABLE state. Example: If you specify <b>d</b> in this field, the escalation will only be used if the host is in a DOWN state.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<p>
+
+<a name="hostextinfo"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Extended Host Information Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+Extended host information entries are basically used to make the output from the <a href="cgis.html#status_cgi">status</a>, <a href="cgis.html#statusmap_cgi">statusmap</a>, <a href="cgis.html#statuswrl_cgi">statuswrl</a>, and <a href="cgis.html#extinfo_cgi">extinfo</a> CGIs look pretty. They have no effect on monitoring and are completely optional.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: As of Nagios 3.x, all directives contained in extended host information definitions are also available in <a href="#host">host definitions</a>. Thus, you can choose to define the directives below in your host definitions if it makes your configuration simpler. Separate extended host information definitions will continue to be supported for backward compatability.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Variables in red are required, while those in black are optional. However, you need to supply at least one optional variable in each definition for it to be of much use.
+
+</p>
+
+
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define hostextinfo{</td></tr>
+
+
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Optional">notes</td><td class="Optional"><i>note_string</i></td></tr>
+
+<tr><td></td><td class="Optional">notes_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">action_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image_alt</td><td class="Optional"><i>alt_string</i></td></tr>
+
+<tr><td></td><td class="Optional">vrml_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">statusmap_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">2d_coords</td><td class="Optional"><i>x_coord,y_coord</i></td></tr>
+
+<tr><td></td><td class="Optional">3d_coords</td><td class="Optional"><i>x_coord,y_coord,z_coord</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define hostextinfo{
+
+ host_name netware1
+
+ notes This is the primary Netware file server
+
+ notes_url http://webserver.localhost.localdomain/hostinfo.pl?host=netware1
+
+ icon_image novell40.png
+
+ icon_image_alt IntranetWare 4.11
+
+ vrml_image novell40.png
+
+ statusmap_image novell40.gd2
+
+ 2d_coords 100,250
+
+ 3d_coords 100.0,50.0,75.0
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Variable Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This variable is used to identify the <i>short name</i> of the <a href="#host">host</a> which the data is associated with.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes</strong>:</td>
+
+<td>
+
+This directive is used to define an optional string of notes pertaining to the host. If you specify a note here, you will see the it in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified host).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes_url</strong>:</td>
+
+<td>
+
+This variable is used to define an optional URL that can be used to provide more information about the host. If you specify an URL, you will see a link that says "Extra Host Notes" in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified host). Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>). This can be very useful if you want to make detailed information on the host, emergency contact methods, etc. available to other support staff.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>action_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more actions to be performed on the host. If you specify an URL, you will see a link that says "Extra Host Actions" in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified host). Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of a GIF, PNG, or JPG image that should be associated with this host. This image will be displayed in the <a href="cgis.html#status_cgi">status</a> and <a href="cgis.html#extinfo_cgi">extended information</a> CGIs. The image will look best if it is 40x40 pixels in size. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image_alt</strong>:</td>
+
+<td>
+
+This variable is used to define an optional string that is used in the ALT tag of the image specified by the <i><icon_image></i> argument. The ALT tag is used in the <a href="cgis.html#status_cgi">status</a>, <a href="cgis.html#extinfo_cgi">extended information</a> and <a href="cgis.html#statusmap_cgi">statusmap</a> CGIs.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>vrml_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of a GIF, PNG, or JPG image that should be associated with this host. This image will be used as the texture map for the specified host in the <a href="cgis.html#statuswrl_cgi">statuswrl</a> CGI. Unlike the image you use for the <i><icon_image></i> variable, this one should probably <i>not</i> have any transparency. If it does, the host object will look a bit wierd. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>statusmap_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of an image that should be associated with this host in the <a href="cgis.html#statusmap_cgi">statusmap</a> CGI. You can specify a JPEG, PNG, and GIF image if you want, although I would strongly suggest using a GD2 format image, as other image formats will result in a lot of wasted CPU time when the statusmap image is generated. GD2 images can be created from PNG images by using the <b>pngtogd2</b> utility supplied with Thomas Boutell's <a href="http://www.boutell.com/gd/">gd library</a>. The GD2 images should be created in <i>uncompressed</i> format in order to minimize CPU load when the statusmap CGI is generating the network map image. The image will look best if it is 40x40 pixels in size. You can leave these option blank if you are not using the statusmap CGI. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>2d_coords</strong>:</td>
+
+<td>
+
+This variable is used to define coordinates to use when drawing the host in the <a href="cgis.html#statusmap_cgi">statusmap</a> CGI. Coordinates should be given in positive integers, as they correspond to physical pixels in the generated image. The origin for drawing (0,0) is in the upper left hand corner of the image and extends in the positive x direction (to the right) along the top of the image and in the positive y direction (down) along the left hand side of the image. For reference, the size of the icons drawn is usually about 40x40 pixels (text takes a little extra space). The coordinates you specify here are for the upper left hand corner of the host icon that is drawn. Note: Don't worry about what the maximum x and y coordinates that you can use are. The CGI will automatically calculate the maximum dimensions of the image it creates based on the largest x and y coordinates you specify.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>3d_coords</strong>:</td>
+
+<td>
+
+This variable is used to define coordinates to use when drawing the host in the <a href="cgis.html#statuswrl_cgi">statuswrl</a> CGI. Coordinates can be positive or negative real numbers. The origin for drawing is (0.0,0.0,0.0). For reference, the size of the host cubes drawn is 0.5 units on each side (text takes a little more space). The coordinates you specify here are used as the center of the host cube.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+
+
+<p>
+
+<a name="serviceextinfo"></a>
+
+<table border="0" width="100%">
+
+<tr>
+
+<td class="SectionHeader">Extended Service Information Definition</td>
+
+</tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Description:</p>
+
+<p>
+
+Extended service information entries are basically used to make the output from the <a href="cgis.html#status_cgi">status</a> and <a href="cgis.html#extinfo_cgi">extinfo</a> CGIs look pretty. They have no effect on monitoring and are completely optional.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: As of Nagios 3.x, all directives contained in extended service information definitions are also available in <a href="#service">service definitions</a>. Thus, you can choose to define the directives below in your service definitions if it makes your configuration simpler. Separate extended service information definitions will continue to be supported for backward compatability.
+
+</p>
+
+
+
+<p class="SectionTitle">Definition Format:</p>
+
+<p>
+
+Note: Variables in red are required, while those in black are optional. However, you need to supply at least one optional variable in each definition for it to be of much use.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr><td colspan=3 class="Definition">define serviceextinfo{</td></tr>
+
+
+
+<tr><td></td><td class="Required">host_name</td><td class="Required"><i>host_name</i></td></tr>
+
+<tr><td></td><td class="Required">service_description</td><td class="Required"><i>service_description</i></td></tr>
+
+<tr><td></td><td class="Optional">notes</td><td class="Optional"><i>note_string</i></td></tr>
+
+<tr><td></td><td class="Optional">notes_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">action_url</td><td class="Optional"><i>url</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image</td><td class="Optional"><i>image_file</i></td></tr>
+
+<tr><td></td><td class="Optional">icon_image_alt</td><td class="Optional"><i>alt_string</i></td></tr>
+
+
+
+<tr><td> </td><td colspan=2 class="Definition">}</td></tr>
+
+</table>
+
+
+
+<p class="SectionTitle">Example Definition:</p>
+
+<pre>
+
+define serviceextinfo{
+
+ host_name linux2
+
+ service_description Log Anomalies
+
+ notes Security-related log anomalies on secondary Linux server
+
+ notes_url http://webserver.localhost.localdomain/serviceinfo.pl?host=linux2&service=Log+Anomalies
+
+ icon_image security.png
+
+ icon_image_alt Security-Related Alerts
+
+ }
+
+</pre>
+
+
+
+<p class="SectionTitle">Variable Descriptions:</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top"><strong>host_name</strong>:</td>
+
+<td>
+
+This directive is used to identify the <i>short name</i> of the host that the <a href="#service">service</a> is associated with.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>service_description</strong>:</td>
+
+<td>
+
+This directive is description of the <a href="#service">service</a> which the data is associated with.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes</strong>:</td>
+
+<td>
+
+This directive is used to define an optional string of notes pertaining to the service. If you specify a note here, you will see the it in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified service).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>notes_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more information about the service. If you specify an URL, you will see a link that says "Extra Service Notes" in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified service). Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>). This can be very useful if you want to make detailed information on the service, emergency contact methods, etc. available to other support staff.
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>action_url</strong>:</td>
+
+<td>
+
+This directive is used to define an optional URL that can be used to provide more actions to be performed on the service. If you specify an URL, you will see a link that says "Extra Service Actions" in the <a href="cgis.html#extinfo_cgi">extended information</a> CGI (when you are viewing information about the specified service). Any valid URL can be used. If you plan on using relative paths, the base path will the the same as what is used to access the CGIs (i.e. <i>/cgi-bin/nagios/</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image</strong>:</td>
+
+<td>
+
+This variable is used to define the name of a GIF, PNG, or JPG image that should be associated with this host. This image will be displayed in the <a href="cgis.html#status_cgi">status</a> and <a href="cgis.html#extinfo_cgi">extended information</a> CGIs. The image will look best if it is 40x40 pixels in size. Images for hosts are assumed to be in the <b>logos/</b> subdirectory in your HTML images directory (i.e. <i>/usr/local/nagios/share/images/logos</i>).
+
+</td>
+
+</tr>
+
+<tr>
+
+<td valign="top"><strong>icon_image_alt</strong>:</td>
+
+<td>
+
+This variable is used to define an optional string that is used in the ALT tag of the image specified by the <i><icon_image></i> argument. The ALT tag is used in the <a href="cgis.html#status_cgi">status</a>, <a href="cgis.html#extinfo_cgi">extended information</a> and <a href="cgis.html#statusmap_cgi">statusmap</a> CGIs.
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Object Inheritance</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Object Inheritance</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="objectdefinitions.html">Object Configuration</a>, <a href="objecttricks.html">Object Tricks</a>, <a href="customobjectvars.html">Custom Object Variables</a>, <a href="faststartup.html">Fast Startup Options</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This documentation attempts to explain object inheritance and how it can be used in your <a href="objectdefinitions.html">object definitions</a>.
+
+</p>
+
+
+
+<p>
+
+If you are confused about how recursion and inheritance work after reading this, take a look at the sample object config files provided in the Nagios distribution. If that still doesn't help, drop an email message with a <i>detailed</i> description of your problem to the <i>nagios-users</i> mailing list.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Basics</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are three variables affecting recursion and inheritance that are present in all object definitions. They are indicated in red as follows...
+
+</p>
+
+
+
+<pre>
+
+ define <i>someobjecttype</i>{
+
+ <i>object-specific variables</i> ...
+
+ <font color="red">name <i>template_name</i></font>
+
+ <font color="red">use <i>name_of_template_to_use</i></font>
+
+ <font color="red">register [0/1]</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+The first variable is <i>name</i>. Its just a "template" name that can be referenced in other object definitions so they can inherit the objects properties/variables. Template names must be unique amongst objects of the same type, so you can't have two or more host definitions that have "hosttemplate" as their template name.
+
+</p>
+
+
+
+<p>
+
+The second variable is <i>use</i>. This is where you specify the name of the template object that you want to inherit properties/variables from. The name you specify for this variable must be defined as another object's template named (using the <i>name</i> variable).
+
+</p>
+
+
+
+<p>
+
+The third variable is <i>register</i>. This variable is used to indicate whether or not the object definition should be "registered" with Nagios. By default, all object definitions are registered. If you are using a partial object definition as a template, you would want to prevent it from being registered (an example of this is provided later). Values are as follows: 0 = do NOT register object definition, 1 = register object definition (this is the default). This variable is NOT inherited; every (partial) object definition used as a template must explicitly set the <i>register</i> directive to be <i>0</i>. This prevents the need to override an inherited <i>register</i> directive with a value of <i>1</i> for every object that should be registered.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Local Variables vs. Inherited Variables</u></strong>
+
+</p>
+
+
+
+<p>
+
+One important thing to understand with inheritance is that "local" object variables always take precedence over variables defined in the template object. Take a look at the following example of two host definitions (not all required variables have been supplied):
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost1
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 5
+
+ <font color="red">name hosttemplate1</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost2
+
+ max_check_attempts 3
+
+ <font color="red">use hosttemplate1</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You'll note that the definition for host <i>bighost1</i> has been defined as having <i>hosttemplate1</i> as its template name. The definition for host <i>bighost2</i> is using the definition of <i>bighost1</i> as its template object. Once Nagios processes this data, the resulting definition of host <i>bighost2</i> would be equivalent to this definition:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost2
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 3
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You can see that the <i>check_command</i> and <i>notification_options</i> variables were inherited from the template object (where host <i>bighost1</i> was defined). However, the <i>host_name</i> and <i>max_check_attempts</i> variables were not inherited from the template object because they were defined locally. Remember, locally defined variables override variables that would normally be inherited from a template object. That should be a fairly easy concept to understand.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: If you would like local string variables to be appended to inherited string values, you can do so. Read more about how to accomplish this <a href="#add_string">below</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Inheritance Chaining</u></strong>
+
+</p>
+
+
+
+<p>
+
+Objects can inherit properties/variables from multiple levels of template objects. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost1
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 5
+
+ <font color="red">name hosttemplate1</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost2
+
+ max_check_attempts 3
+
+ <font color="red">use hosttemplate1</font>
+
+ <font color="red">name hosttemplate2</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost3
+
+ <font color="red">use hosttemplate2</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You'll notice that the definition of host <i>bighost3</i> inherits variables from the definition of host <i>bighost2</i>, which in turn inherits variables from the definition of host <i>bighost1</i>. Once Nagios processes this configuration data, the resulting host definitions are equivalent to the following:
+
+</p>
+
+
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost1
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 5
+
+ }
+
+
+
+ define host{
+
+ host_name bighost2
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 3
+
+ }
+
+
+
+ define host{
+
+ host_name bighost3
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 3
+
+ }
+
+</pre>
+
+
+
+<p>
+
+There is no inherent limit on how "deep" inheritance can go, but you'll probably want to limit yourself to at most a few levels in order to maintain sanity.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Using Incomplete Object Definitions as Templates</u></strong>
+
+</p>
+
+
+
+<p>
+
+It is possible to use incomplete object definitions as templates for use by other object definitions. By "incomplete" definition, I mean that all required variables in the object have not been supplied in the object definition. It may sound odd to use incomplete definitions as templates, but it is in fact recommended that you use them. Why? Well, they can serve as a set of defaults for use in all other object definitions. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 5
+
+ <font color="red">name generichosttemplate</font>
+
+ <font color="red">register 0</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost1
+
+ address 192.168.1.3
+
+ <font color="red">use generichosttemplate</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost2
+
+ address 192.168.1.4
+
+ <font color="red">use generichosttemplate</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Notice that the first host definition is incomplete because it is missing the required <i>host_name</i> variable. We don't need to supply a host name because we just want to use this definition as a generic host template. In order to prevent this definition from being registered with Nagios as a normal host, we set the <i>register</i> variable to 0.
+
+</p>
+
+
+
+<p>
+
+The definitions of hosts <i>bighost1</i> and <i>bighost2</i> inherit their values from the generic host definition. The only variable we've chosed to override is the <i>address</i> variable. This means that both hosts will have the exact same properties, except for their <i>host_name</i> and <i>address</i> variables. Once Nagios processes the config data in the example, the resulting host definitions would be equivalent to specifying the following:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost1
+
+ address 192.168.1.3
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 5
+
+ }
+
+
+
+ define host{
+
+ host_name bighost2
+
+ address 192.168.1.4
+
+ check_command check-host-alive
+
+ notification_options d,u,r
+
+ max_check_attempts 5
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+At the very least, using a template definition for default variables will save you a lot of typing. It'll also save you a lot of headaches later if you want to change the default values of variables for a large number of hosts.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Custom Object Variables</u></strong>
+
+</p>
+
+
+
+<p>
+
+Any <a href="customobjectvars.html">custom object variables</a> that you define in your host, service, or contact definition templates will be inherited just like other standard variables. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ _customvar1 somevalue ; <-- Custom host variable
+
+ _snmp_community public ; <-- Custom host variable
+
+ <font color="red">name generichosttemplate</font>
+
+ <font color="red">register 0</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost1
+
+ address 192.168.1.3
+
+ <font color="red">use generichosttemplate</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+The host <i>bighost1</i> will inherit the custom host variables <i>_customvar1</i> and <i>_snmp_community</i>, as well as their respective values, from the <i>generichosttemplate</i> definition. The effective result is a definition for <i>bighost1</i> that looks like this:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost1
+
+ address 192.168.1.3
+
+ _customvar1 somevalue
+
+ _snmp_community public
+
+ }
+
+</pre>
+
+
+
+<a name="cancel_string"></a>
+
+<p>
+
+<strong><u>Cancelling Inheritance of String Values</u></strong>
+
+</p>
+
+
+
+<p>
+
+In some cases you may not want your host, service, or contact definitions to inherit values of string variables from the templates they reference. If this is the case, you can specify "<b>null</b>" (without quotes) as the value of the variable that you do not want to inherit. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ event_handler my-event-handler-command
+
+ <font color="red">name generichosttemplate</font>
+
+ <font color="red">register 0</font>
+
+ }
+
+
+
+ define host{
+
+ host_name bighost1
+
+ address 192.168.1.3
+
+ event_handler null
+
+ <font color="red">use generichosttemplate</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In this case, the host <i>bighost1</i> will not inherit the value of the <i>event_handler</i> variable that is defined in the <i>generichosttemplate</i>. The resulting effective definition of <i>bighost1</i> is the following:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name bighost1
+
+ address 192.168.1.3
+
+ }
+
+</pre>
+
+
+
+<a name="add_string"></a>
+
+<p>
+
+<strong><u>Additive Inheritance of String Values</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios gives preference to local variables instead of values inherited from templates. In most cases local variable values override those that are defined in templates. In some cases it makes sense to allow Nagios to use the values of inherited <i>and</i> local variables together.
+
+</p>
+
+
+
+<p>
+
+This "additive inheritance" can be accomplished by prepending the local variable value with a plus sign (<b>+</b>). This features is only available for standard (non-custom) variables that contain string values. Take the following example:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ hostgroups all-servers
+
+ <font color="red">name generichosttemplate</font>
+
+ <font color="red">register 0</font>
+
+ }
+
+
+
+ define host{
+
+ host_name linuxserver1
+
+ hostgroups +linux-servers,web-servers
+
+ <font color="red">use generichosttemplate</font>
+
+ }
+
+</pre>
+
+
+
+<p>
+
+In this case, the host <i>linuxserver1</i> will append the value of its local <i>hostgroups</i> variable to that from <i>generichosttemplate</i>. The resulting effective definition of <i>linuxserver1</i> is the following:
+
+</p>
+
+
+
+<pre>
+
+ define host{
+
+ host_name linuxserver1
+
+ hostgroups all-servers,linux-servers,web-servers
+
+ }
+
+</pre>
+
+
+
+<a name="implied_inheritance"></a>
+
+<p>
+
+<strong><u>Implied Inheritance</u></strong>
+
+</p>
+
+
+
+<p>
+
+Normally you have to either explicitly specify the value of a required variable in an object definition or inherit it from a template. There are a few exceptions to this rule, where Nagios will assume that you want to use a value that instead comes from a related object. For example, the values of some service variables will be copied from the host the service is associated with if you don't otherwise specify them.
+
+</p>
+
+
+
+<p>
+
+The following table lists the object variables that will be implicitly inherited from related objects if you don't explicitly specify their value in your object definition or inherit them from a template.
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Object Type</th><th>Object Variable</th><th>Implied Source</th></tr>
+
+
+
+<tr>
+
+<td rowspan="3"><b>Services</b></td>
+
+<td><i>contact_groups</i></td>
+
+<td><i>contact_groups</i> in the associated host definition</td>
+
+</tr>
+
+<tr>
+
+<td><i>notification_interval</i></td>
+
+<td><i>notification_interval</i> in the associated host definition</td>
+
+</tr>
+
+<tr>
+
+<td><i>notification_period</i></td>
+
+<td><i>notification_period</i> in the associated host definition</td>
+
+</tr>
+
+
+
+<tr>
+
+<td rowspan="3"><b>Host Escalations</b></td>
+
+<td><i>contact_groups</i></td>
+
+<td><i>contact_groups</i> in the associated host definition</td>
+
+</tr>
+
+<tr>
+
+<td><i>notification_interval</i></td>
+
+<td><i>notification_interval</i> in the associated host definition</td>
+
+</tr>
+
+<tr>
+
+<td><i>escalation_period</i></td>
+
+<td><i>notification_period</i> in the associated host definition</td>
+
+</tr>
+
+
+
+<tr>
+
+<td rowspan="3"><b>Service Escalations</b></td>
+
+<td><i>contact_groups</i></td>
+
+<td><i>contact_groups</i> in the associated service definition</td>
+
+</tr>
+
+<tr>
+
+<td><i>notification_interval</i></td>
+
+<td><i>notification_interval</i> in the associated service definition</td>
+
+</tr>
+
+<tr>
+
+<td><i>escalation_period</i></td>
+
+<td><i>notification_period</i> in the associated service definition</td>
+
+</tr>
+
+
+
+</table>
+
+
+
+<a name="impliedescalations"></a>
+
+<p>
+
+<strong><u>Implied/Additive Inheritance in Escalations</u></strong>
+
+</p>
+
+
+
+<p>
+
+Service and host escalation definitions can make use of a special rule that combines the features of implied and additive inheritance. If escalations 1) do not inherit the values of their <i>contact_groups</i> or <i>contacts</i> directives from another escalation template and 2) their <i>contact_groups</i> or <i>contacts</i> directives begin with a plus sign (+), then the values of their corresponding host or service definition's <i>contact_groups</i> or <i>contacts</i> directives will be used in the additive inheritance logic.
+
+</p>
+
+
+
+<p>
+
+Confused? Here's an example:
+
+</p>
+
+
+
+<pre>
+
+define host{
+
+ name linux-server
+
+ contact_groups linux-admins
+
+ ...
+
+ }
+
+
+
+define hostescalation{
+
+ host_name linux-server
+
+ contact_groups +management
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+This is a much simpler equivalent to:
+
+</p>
+
+
+
+<pre>
+
+define hostescalation{
+
+ host_name linux-server
+
+ contact_groups linux-admins,management
+
+ ...
+
+ }
+
+</pre>
+
+
+
+
+
+<a name="importantvalues"></a>
+<p>
+<strong><u>Important values</u></strong>
+</p>
+
+<p>
+Service templates can make use of a special rule which gives precedence to their check_command value. If the check_command is prefixed with an exclamation mark (!), then the template's check_command is marked as important and will be used over the check_command defined for the service (this is styled after CSS syntax, which uses ! as an important attribute).
+</p>
+
+<p>
+Why is this useful? It is mainly useful when setting a different check_command for distributed systems. You may want to set a freshness threshold and a check_command that forces the service into a failed state, but this doesn't work with the normal templating system. Using this <i>important</i> flag allows the custom check_command to be written, but a general distributed template can be used to overrule the check_command when used on a central Nagios server.
+</p>
+
+<p>
+For instance:
+</p>
+
+<pre>
+# On master
+define service {
+ name service-distributed
+ register 0
+ active_checks_enabled 0
+ check_freshness 1
+ check_command <font color="red">!set_to_stale</font>
+ }
+# On slave
+define service {
+ name service-distributed
+ register 0
+ active_checks_enabled 1
+ }
+# Service definition, used by master and slave
+define service {
+ host_name host1
+ service_description serviceA
+ check_command check_http...
+ use service-distributed
+ ...
+ }
+</pre>
+
+<a name="multiple_templates"></a>
+
+<p>
+
+<strong><u>Multiple Inheritance Sources</u></strong>
+
+</p>
+
+
+
+<p>
+
+Thus far, all examples of inheritance have shown object definitions inheriting variables/values from just a single source. You are also able to inherit variables/values from multiple sources for more complex configurations, as shown below.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td>
+
+<pre>
+
+# Generic host template
+
+define host{
+
+ name <font color="red">generic-host</font>
+
+ active_checks_enabled 1
+
+ check_interval 10
+
+ ...
+
+ register 0
+
+ }
+
+
+
+# Development web server template
+
+define host{
+
+ name <font color="green">development-server</font>
+
+ check_interval 15
+
+ notification_options d,u,r
+
+ ...
+
+ register 0
+
+ }
+
+
+
+# Development web server
+
+define host{
+
+ use <font color="red">generic-host</font>,<font color="green">development-server</font>
+
+ host_name devweb1
+
+ ...
+
+ }
+
+</pre>
+
+</td>
+
+<td valign="top">
+
+<img src="images/multiple-templates1.png" border="0" alt="Multiple Inheritance Sources" title="Multiple Inheritance Sources" style="padding: 0 0 0 25px;">
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<p>
+
+In the example above, <i>devweb1</i> is inheriting variables/values from two sources: <i>generic-host</i> and <i>development-server</i>. You'll notice that a <i>check_interval</i> variable is defined in both sources. Since <i>generic-host</i> was the first template specified in <i>devweb1</i>'s <i>use</i> directive, its value for the <i>check_interval</i> variable is inherited by the <i>devweb1</i> host. After inheritance, the effective definition of <i>devweb1</i> would be as follows:
+
+</p>
+
+
+
+<pre>
+
+# Development web server
+
+define host{
+
+ host_name devweb1
+
+ active_checks_enabled 1
+
+ check_interval 10
+
+ notification_options d,u,r
+
+ ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Precedence With Multiple Inheritance Sources</u></strong>
+
+</p>
+
+
+
+<p>
+
+When you use multiple inheritance sources, it is important to know how Nagios handles variables that are defined in multiple sources. In these cases Nagios will use the variable/value from the first source that is specified in the <i>use</i> directive. Since inheritance sources can themselves inherit variables/values from one or more other sources, it can get tricky to figure out what variable/value pairs take precedence.
+
+</p>
+
+
+
+<table border="0" class="Default">
+
+<tr>
+
+<td valign="top">
+
+<p>
+
+Consider the following host definition that references three templates:
+
+</p>
+
+<pre>
+
+# Development web server
+
+define host{
+
+ use <font color="red">1</font>, <font color="#FF8040">4</font>, <font color="purple">8</font>
+
+ host_name devweb1
+
+ ...
+
+ }
+
+</pre>
+
+<p>
+
+If some of those referenced templates themselves inherit variables/values from one or more other templates, the precendence rules are shown to the right.
+
+</p>
+
+<p>
+
+Testing, trial, and error will help you better understand exactly how things work in complex inheritance situations like this. :-)
+
+</p>
+
+</td>
+
+<td valign="top">
+
+<img src="images/multiple-templates2.png" border="0" alt="Multiple Inheritance Sources" title="Multiple Inheritance Sources" style="padding: 0 0 0 25px;">
+
+</td>
+
+</tr>
+
+</table>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Time-Saving Tricks For Object Definitions</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Time-Saving Tricks For Object Definitions</h1>
+
+or...<br>
+
+<b>"How To Preserve Your Sanity"</b>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="objectdefinitions.html">Object Configuration</a>, <a href="objectinheritance.html">Object Inheritance</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This documentation attempts to explain how you can exploit the (somewhat) hidden features of <a href="objectdefinitions.html">template-based object definitions</a> to save your sanity. How so, you ask? Several types of objects allow you to specify multiple host names and/or hostgroup names in definitions, allowing you to "copy" the object defintion to multiple hosts or services. I'll cover each type of object that supports these features seperately. For starters, the object types which support this time-saving feature are as follows:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="#service">Services</a>
+
+<li><a href="#serviceescalation">Service escalations</a>
+
+<li><a href="#servicedependency">Service dependencies</a>
+
+<li><a href="#hostescalation">Host escalations</a>
+
+<li><a href="#hostdependency">Host dependencies</a>
+
+<li><a href="#hostgroup">Hostgroups</a>
+
+</ul>
+
+
+
+<p>
+
+Object types that are not listed above (i.e. timeperiods, commands, etc.) do not support the features I'm about to describe.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Regular Expression Matching</u></strong>
+
+</p>
+
+
+
+<p>
+
+The examples I give below use "standard" matching of object names
+
+ and <b>*require*</b> <a href="configmain.html#use_regexp_matching">use_regexp_matching</a> to be <b>*disabled*</b>.
+
+ </p>
+
+
+
+<p>
+
+If you wish, you can enable regular expression matching for object names by using the <a href="configmain.html#use_regexp_matching">use_regexp_matching</a> config option. By default, regular expression matching will only be used in object names that contain <b>*</b>, <b>?</b>, <b>+</b>, or <b>\.</b>. If you want regular expression matching to be used on all object names, enable the <a href="configmain.html#use_true_regexp_matching">use_true_regexp_matching</a> config option. Regular expressions can be used in any of the fields used in the examples below (host names, hostgroup names, service names, and servicegroup names).
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Be careful when enabling regular expression matching - you may have to change your config file, since some directives that you might not want to be interpreted as a regular expression just might be! Any problems should become evident once you verify your configuration.
+
+</p>
+
+
+
+<br><br>
+
+
+
+<a name="service"></a>
+
+<p>
+
+<strong><u>Service Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+<b>Multiple Hosts:</b><br> If you want to create identical <a href="objectdefinitions.html#service">services</a> that are assigned to multiple hosts, you can specify multiple hosts in the <i>host_name</i> directive. The definition below would create a service called <i>SOMESERVICE</i> on hosts <i>HOST1</i> through <i>HOSTN</i>. All the instances of the <i>SOMESERVICE</i> service would be identical (i.e. have the same check command, max check attempts, notification period, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>service</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2,HOST3,...,HOSTN</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other service directives</i> ...
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<b>All Hosts In Multiple Hostgroups:</b><br>If you want to create identical services that are assigned to all hosts in one or more hostgroups, you can do so by creating a single service definition. How? The <i>hostgroup_name</i> directive allows you to specify the name of one or more hostgroups that the service should be created for. The definition below would create a service called <i>SOMESERVICE</i> on all hosts that are members of hostgroups <i>HOSTGROUP1</i> through <i>HOSTGROUPN</i>. All the instances of the <i>SOMESERVICE</i> service would be identical (i.e. have the same check command, max check attempts, notification period, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>service</i>{
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other service directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Hosts:</b><br> If you want to create identical services that are assigned to all hosts that are defined in your configuration files, you can use a wildcard in the <i>host_name</i> directive. The definition below would create a service called <i>SOMESERVICE</i> on <b>all hosts</b> that are defined in your configuration files. All the instances of the <i>SOMESERVICE</i> service would be identical (i.e. have the same check command, max check attempts, notification period, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>service</i>{
+
+ <font color="red">host_name <i>*</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other service directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>Excluding Hosts:</b><br>If you want to create identical services on numerous hosts or hostgroups, but would like to exclude some hosts from the definition, this can be accomplished by preceding the host or hostgroup with a ! symbol.
+
+</p>
+
+
+
+<pre>
+
+ define <i>service</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2,!HOST3,!HOST4,...,HOSTN</i></font>
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other service directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<br><br>
+
+
+
+<a name="serviceescalation"></a>
+
+<p>
+
+<strong><u>Service Escalation Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+<b>Multiple Hosts:</b><br> If you want to create <a href="objectdefinitions.html#serviceescalation">service escalations</a> for services of the same name/description that are assigned to multiple hosts, you can specify multiple hosts in the <i>host_name</i> directive. The definition below would create a service escalation for services called <i>SOMESERVICE</i> on hosts <i>HOST1</i> through <i>HOSTN</i>. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2,HOST3,...,HOSTN</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<b>All Hosts In Multiple Hostgroups:</b><br> If you want to create service escalations for services of the same name/description that are assigned to all hosts in in one or more hostgroups, you can do use the <i>hostgroup_name</i> directive. The definition below would create a service escalation for services called <i>SOMESERVICE</i> on all hosts that are members of hostgroups <i>HOSTGROUP1</i> through <i>HOSTGROUPN</i>. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Hosts:</b><br> If you want to create identical service escalations for services of the same name/description that are assigned to all hosts that are defined in your configuration files, you can use a wildcard in the <i>host_name</i> directive. The definition below would create a service escalation for all services called <i>SOMESERVICE</i> on <b>all hosts</b> that are defined in your configuration files. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">host_name <i>*</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>Excluding Hosts:</b><br>If you want to create identical services escalations for services on numerous hosts or hostgroups,
+
+but would like to exclude some hosts from the definition, this can be accomplished by preceding the host or hostgroup with a ! symbol.
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2,!HOST3,!HOST4,...,HOSTN</i></font>
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN</i></font>
+
+ <font color="red">service_description <i>SOMESERVICE</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Services On Same Host:</b><br> If you want to create <a href="objectdefinitions.html#serviceescalation">service escalations</a> for all services assigned to a particular host, you can use a wildcard in the <i>service_description</i> directive. The definition below would create a service escalation for <b>all</b> services on host <i>HOST1</i>. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+<p>
+
+If you feel like being particularly adventurous, you can specify a wildcard in both the <i>host_name</i> and <i>service_description</i> directives. Doing so would create a service escalation for <b>all services</b> that you've defined in your configuration files.
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">host_name <i>HOST1</i></font>
+
+ <font color="red">service_description <i>*</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<b>Multiple Services On Same Host:</b><br> If you want to create <a href="objectdefinitions.html#serviceescalation">service escalations</a> for all multiple services assigned to a particular host, you can use a specify more than one service description in the <i>service_description</i> directive. The definition below would create a service escalation for services <i>SERVICE1</i> through <i>SERVICEN</i> on host <i>HOST1</i>. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">host_name <i>HOST1</i></font>
+
+ <font color="red">service_description <i>SERVICE1,SERVICE2,...,SERVICEN</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Services In Multiple Servicegroups:</b><br> If you want to create service escalations for all services that belong in one or more servicegroups, you can do use the <i>servicegroup_name</i> directive. The definition below would create service escalations for all services that are members of servicegroups <i>SERVICEGROUP1</i> through <i>SERVICEGROUPN</i>. All the instances of the service escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>serviceescalation</i>{
+
+ <font color="red">servicegroup_name <i>SERVICEGROUP1,SERVICEGROUP2,...,SERVICEGROUPN</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<br><br>
+
+
+
+<a name="servicedependency"></a>
+
+<p>
+
+<strong><u>Service Dependency Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+<b>Multiple Hosts:</b><br> If you want to create <a href="objectdefinitions.html#servicedependency">service dependencies</a> for services of the same name/description that are assigned to multiple hosts, you can specify multiple hosts in the <i>host_name</i> and or <i>dependent_host_name</i> directives. In the example below, service <i>SERVICE2</i> on hosts <i>HOST3</i> and <i>HOST4</i> would be dependent on service <i>SERVICE1</i> on hosts <i>HOST1</i> and <i>HOST2</i>. All the instances of the service dependencies would be identical except for the host names (i.e. have the same notification failure criteria, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>servicedependency</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2</i></font>
+
+ <font color="red">service_description <i>SERVICE1</i></font>
+
+ <font color="red">dependent_host_name <i>HOST3,HOST4</i></font>
+
+ <font color="red">dependent_service_description <i>SERVICE2</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Hosts In Multiple Hostgroups:</b><br> If you want to create service dependencies for services of the same name/description that are assigned to all hosts in in one or more hostgroups, you can do use the <i>hostgroup_name</i> and/or <i>dependent_hostgroup_name</i> directives. In the example below, service <i>SERVICE2</i> on all hosts in hostgroups <i>HOSTGROUP3</i> and <i>HOSTGROUP4</i> would be dependent on service <i>SERVICE1</i> on all hosts in hostgroups <i>HOSTGROUP1</i> and <i>HOSTGROUP2</i>. Assuming there were five hosts in each of the hostgroups, this definition would be equivalent to creating 100 single service dependency definitions! All the instances of the service dependency would be identical except for the host names (i.e. have the same notification failure criteria, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>servicedependency</i>{
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2</i></font>
+
+ <font color="red">service_description <i>SERVICE1</i></font>
+
+ <font color="red">dependent_hostgroup_name <i>HOSTGROUP3,HOSTGROUP4</i></font>
+
+ <font color="red">dependent_service_description <i>SERVICE2</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Services On A Host:</b><br> If you want to create service dependencies for all services assigned to a particular host, you can use a wildcard in the <i>service_description</i> and/or <i>dependent_service_description</i> directives. In the example below, <b>all services</b> on host <i>HOST2</i> would be dependent on <b>all services</b> on host <i>HOST1</i>. All the instances of the service dependencies would be identical (i.e. have the same notification failure criteria, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>servicedependency</i>{
+
+ <font color="red">host_name <i>HOST1</i></font>
+
+ <font color="red">service_description <i>*</i></font>
+
+ <font color="red">dependent_host_name <i>HOST2</i></font>
+
+ <font color="red">dependent_service_description <i>*</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>Multiple Services On A Host:</b><br> If you want to create service dependencies for multiple services assigned to a particular host, you can specify more than one service description in the <i>service_description</i> and/or <i>dependent_service_description</i> directives as follows:
+
+</p>
+
+
+
+<pre>
+
+ define <i>servicedependency</i>{
+
+ <font color="red">host_name <i>HOST1</i></font>
+
+ <font color="red">service_description <i>SERVICE1,SERVICE2,...,SERVICEN</i></font>
+
+ <font color="red">dependent_host_name <i>HOST2</i></font>
+
+ <font color="red">dependent_service_description <i>SERVICE1,SERVICE2,...,SERVICEN</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Services In Multiple Servicegroups:</b><br> If you want to create service dependencies for all services that belong in one or more servicegroups, you can do use the <i>servicegroup_name</i> and/or <i>dependent_servicegroup_name</i> directive as follows:
+
+</p>
+
+
+
+<pre>
+
+ define <i>servicedependency</i>{
+
+ <font color="red">servicegroup_name <i>SERVICEGROUP1,SERVICEGROUP2,...,SERVICEGROUPN</i></font>
+
+ <font color="red">dependent_servicegroup_name <i>SERVICEGROUP3,SERVICEGROUP4,...SERVICEGROUPN</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<a name="same_host_dependency"></a>
+
+<p>
+
+<b>Same Host Dependencies:</b><br> If you want to create service dependencies for multiple services that are dependent on services on the same host, leave the <i>dependent_host_name</i> and <i>dependent_hostgroup_name</i> directives empty. The example below assumes that hosts <i>HOST1</i> and <i>HOST2</i> have at least the following four services associated with them: <i>SERVICE1</i>, <i>SERVICE2</i>, <i>SERVICE3</i>, and <i>SERVICE4</i>. In this example, <i>SERVICE3</i> and <i>SERVICE4</i> on <i>HOST1</i> will be dependent on both <i>SERVICE1</i> and <i>SERVICE2</i> on <i>HOST1</i>. Similiarly, <i>SERVICE3</i> and <i>SERVICE4</i> on <i>HOST2</i> will be dependent on both <i>SERVICE1</i> and <i>SERVICE2</i> on <i>HOST2</i>.
+
+</p>
+
+
+
+<pre>
+
+ define <i>servicedependency</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2</i></font>
+
+ <font color="red">service_description <i>SERVICE1,SERVICE2</i></font>
+
+ <font color="red">dependent_service_description <i>SERVICE3,SERVICE4</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<br><br>
+
+
+
+<a name="hostescalation"></a>
+
+<p>
+
+<strong><u>Host Escalation Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+<b>Multiple Hosts:</b><br> If you want to create <a href="objectdefinitions.html#hostescalation">host escalations</a> for multiple hosts, you can specify multiple hosts in the <i>host_name</i> directive. The definition below would create a host escalation for hosts <i>HOST1</i> through <i>HOSTN</i>. All the instances of the host escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostescalation</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2,HOST3,...,HOSTN</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Hosts In Multiple Hostgroups:</b><br> If you want to create host escalations for all hosts in in one or more hostgroups, you can do use the <i>hostgroup_name</i> directive. The definition below would create a host escalation on all hosts that are members of hostgroups <i>HOSTGROUP1</i> through <i>HOSTGROUPN</i>. All the instances of the host escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostescalation</i>{
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2,...,HOSTGROUPN</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Hosts:</b><br> If you want to create identical host escalations for all hosts that are defined in your configuration files, you can use a wildcard in the <i>host_name</i> directive. The definition below would create a hosts escalation for <b>all hosts</b> that are defined in your configuration files. All the instances of the host escalation would be identical (i.e. have the same contact groups, notification interval, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostescalation</i>{
+
+ <font color="red">host_name <i>*</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>Excluding Hosts:</b><br>If you want to create identical host escalations on numerous hosts or hostgroups, but would like to
+
+ exclude some hosts from the definition, this can be accomplished by preceding the host or hostgroup with a ! symbol.
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostescalation</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2,!HOST3,!HOST4,...,HOSTN</i></font>
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2,!HOSTGROUP3,!HOSTGROUP4,...,HOSTGROUPN</i></font>
+
+ <i>other escalation directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<br><br>
+
+
+
+<a name="hostdependency"></a>
+
+<p>
+
+<strong><u>Host Dependency Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+<b>Multiple Hosts:</b><br> If you want to create <a href="objectdefinitions.html#hostdependency">host dependencies</a> for multiple hosts, you can specify multiple hosts in the <i>host_name</i> and/or <i>dependent_host_name</i> directives. The definition below would be equivalent to creating six seperate host dependencies. In the example above, hosts <i>HOST3</i>, <i>HOST4</i> and <i>HOST5</i> would be dependent upon both <i>HOST1</i> and <i>HOST2</i>. All the instances of the host dependencies would be identical except for the host names (i.e. have the same notification failure criteria, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostdependency</i>{
+
+ <font color="red">host_name <i>HOST1,HOST2</i></font>
+
+ <font color="red">dependent_host_name <i>HOST3,HOST4,HOST5</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<b>All Hosts In Multiple Hostgroups:</b><br> If you want to create host escalations for all hosts in in one or more hostgroups, you can do use the <i>hostgroup_name</i> and /or <i>dependent_hostgroup_name</i> directives. In the example below, all hosts in hostgroups <i>HOSTGROUP3</i> and <i>HOSTGROUP4</i> would be dependent on all hosts in hostgroups <i>HOSTGROUP1</i> and <i>HOSTGROUP2</i>. All the instances of the host dependencies would be identical except for host names (i.e. have the same notification failure criteria, etc.).
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostdependency</i>{
+
+ <font color="red">hostgroup_name <i>HOSTGROUP1,HOSTGROUP2</i></font>
+
+ <font color="red">dependent_hostgroup_name <i>HOSTGROUP3,HOSTGROUP4</i></font>
+
+ <i>other dependency directives</i> ...
+
+ }
+
+</pre>
+
+
+
+<br><br>
+
+
+
+<a name="hostgroup"></a>
+
+<p>
+
+<strong><u>Hostgroups</u></strong>
+
+</p>
+
+
+
+<p>
+
+<b>All Hosts:</b><br> If you want to create a hostgroup that has all hosts that are defined in your configuration files as members, you can use a wildcard in the <i>members</i> directive. The definition below would create a hostgroup called <i>HOSTGROUP1</i> that has <b>all hosts</b> that are defined in your configuration files as members.
+
+</p>
+
+
+
+<pre>
+
+ define <i>hostgroup</i>{
+
+ <i>hostgroup_name</i> <i>HOSTGROUP1</i>
+
+ <font color="red">members <i>*</i></font>
+
+ <i>other hostgroup directives</i> ...
+
+ }
+
+</pre>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<HTML>
+
+<HEAD>
+
+<TITLE>On-Call Rotations</TITLE>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</HEAD>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">On-Call Rotations</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="timeperiods.html">Timeperiods</a>, <a href="notifications.html">Notifications</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/objects-contacts.png" border="0" style="float: right; margin: 0 0 0 10px;" alt="Contacts" title="Contacts">
+
+
+
+<img src="images/objects-timeperiods.png" border="0" style="float: right;" alt="Timeperiods" title="Timeperiods">
+
+
+
+<p>
+
+Admins often have to shoulder the burden of answering pagers, cell phone calls, etc. when they least desire them. No one likes to be woken up at 4 am to fix a problem. But its often better to fix the problem in the middle of the night, rather than face the wrath of an unhappy boss when you stroll in at 9 am the next morning.
+
+</p>
+
+
+
+<p>
+
+For those lucky admins who have a team of gurus who can help share the responsibility of answering alerts, on-call rotations are often setup. Multiple admins will often alternate taking notifications on weekends, weeknights, holidays, etc.
+
+</p>
+
+
+
+<p>
+
+I'll show you how you can create <a href="timeperiods.html">timeperiod</a> definitions in a way that can facilitate most on-call notification rotations. These definitions won't handle human issues that will inevitably crop up (admins calling in sick, swapping shifts, or throwing their pagers into the river), but they will allow you to setup a basic structure that should work the majority of the time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Scenario 1: Holidays and Weekends</u></strong>
+
+</p>
+
+
+
+<p>
+
+Two admins - John and Bob - are responsible for responding to Nagios alerts. John receives all notifications for weekdays (with 24 hour days), excluding holidays; Bob handles notifications during the weekends and holidays. Lucky Bob. Here's how you can define this type of rotation using timeperiods...
+
+</p>
+
+
+
+<p>
+
+First, define 3 timeperiods that contains time ranges for holidays, weekdays, and weekends:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ name weekdays
+
+ timeperiod_name weekdays
+
+ monday 00:00-24:00
+
+ tuesday 00:00-24:00
+
+ wednesday 00:00-24:00
+
+ thursday 00:00-24:00
+
+ friday 00:00-24:00
+
+ }
+
+
+
+define timeperiod{
+
+ name weekends
+
+ timeperiod_name weekends
+
+ saturday 00:00-24:00
+
+ sunday 00:00-24:00
+
+ }
+
+
+
+define timeperiod{
+
+ name holidays
+
+ timeperiod_name holidays
+
+ january 1 00:00-24:00 ; New Year's Day
+
+ 2008-03-23 00:00-24:00 ; Easter (2008)
+
+ 2009-04-12 00:00-24:00 ; Easter (2009)
+
+ monday -1 may 00:00-24:00 ; Memorial Day (Last Monday in May)
+
+ july 4 00:00-24:00 ; Independence Day
+
+ monday 1 september 00:00-24:00 ; Labor Day (1st Monday in September)
+
+ thursday 4 november 00:00-24:00 ; Thanksgiving (4th Thursday in November)
+
+ december 25 00:00-24:00 ; Christmas
+
+ december 31 17:00-24:00 ; New Year's Eve (5pm onwards)
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Next, define a timeperiod for John's on-call times that include weekdays, but excludes the dates/times defined in the holidays timeperiod above:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name john-oncall
+
+ use weekdays ; Include weekdays
+
+ exclude holidays ; Exclude holiday dates/times defined elsewhere
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You can now reference this timeperiod in John's contact definition:
+
+</p>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name john
+
+ ...
+
+ host_notification_period john-oncall
+
+ service_notification_period john-oncall
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Define a new timeperiod for Bob's on-call times that include weekends and the dates/times defined in the holidays timeperiod above:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name bob-oncall
+
+ use weekends,holidays ; Include weekend and holiday date/times defined elsewhere
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You can now reference this timeperiod in Bob's contact definition:
+
+</p>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name bob
+
+ ...
+
+ host_notification_period bob-oncall
+
+ service_notification_period bob-oncall
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Scenario 2: Alternating Days</u></strong>
+
+</p>
+
+
+
+<p>
+
+In this scenario John and Bob alternate handling alerts every other day - regardless of whether its a weekend, weekday, or holiday.
+
+</p>
+
+
+
+<p>
+
+Define a timeperiod for when John should receive notifications. Assuming today's date is August 1st, 2007 and John is handling notifications starting today, the definition would look like this:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name john-oncall
+
+ 2007-08-01 / 2 00:00-24:00 ; Every two days, starting August 1st, 2007
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now define a timeperiod for when Bob should receive notifications. Bob gets notifications on the days that John doesn't, so his first on-call day starts tomorrow (August 2nd, 2007).
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name bob-oncall
+
+ 2007-08-02 / 2 00:00-24:00 ; Every two days, starting August 2nd, 2007
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now you need to reference these timeperiod definitions in the contact definitions for John and Bob:
+
+</p>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name john
+
+ ...
+
+ host_notification_period john-oncall
+
+ service_notification_period john-oncall
+
+ }
+
+</pre>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name bob
+
+ ...
+
+ host_notification_period bob-oncall
+
+ service_notification_period bob-oncall
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Scenario 3: Alternating Weeks</u></strong>
+
+</p>
+
+
+
+<p>
+
+In this scenario John and Bob alternate handling alerts every other week. John handles alerts Sunday through Saturday one week, and Bob handles alerts for the following seven days. This continues in perpetuity.
+
+</p>
+
+
+
+<p>
+
+Define a timeperiod for when John should receive notifications. Assuming today's date is Sunday, July 29th, 2007 and John is handling notifications this week (starting today), the definition would look like this:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name john-oncall
+
+ 2007-07-29 / 14 00:00-24:00 ; Every 14 days (two weeks), starting Sunday, July 29th, 2007
+
+ 2007-07-30 / 14 00:00-24:00 ; Every other Monday starting July 30th, 2007
+
+ 2007-07-31 / 14 00:00-24:00 ; Every other Tuesday starting July 31st, 2007
+
+ 2007-08-01 / 14 00:00-24:00 ; Every other Wednesday starting August 1st, 2007
+
+ 2007-08-02 / 14 00:00-24:00 ; Every other Thursday starting August 2nd, 2007
+
+ 2007-08-03 / 14 00:00-24:00 ; Every other Friday starting August 3rd, 2007
+
+ 2007-08-04 / 14 00:00-24:00 ; Every other Saturday starting August 4th, 2007
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now define a timeperiod for when Bob should receive notifications. Bob gets notifications on the weeks that John doesn't, so his first on-call day starts next Sunday (August 5th, 2007).
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name bob-oncall
+
+ 2007-08-05 / 14 00:00-24:00 ; Every 14 days (two weeks), starting Sunday, August 5th, 2007
+
+ 2007-08-06 / 14 00:00-24:00 ; Every other Monday starting August 6th, 2007
+
+ 2007-08-07 / 14 00:00-24:00 ; Every other Tuesday starting August 7th, 2007
+
+ 2007-08-08 / 14 00:00-24:00 ; Every other Wednesday starting August 8th, 2007
+
+ 2007-08-09 / 14 00:00-24:00 ; Every other Thursday starting August 9th, 2007
+
+ 2007-08-10 / 14 00:00-24:00 ; Every other Friday starting August 10th, 2007
+
+ 2007-08-11 / 14 00:00-24:00 ; Every other Saturday starting August 11th, 2007
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Now you need to reference these timeperiod definitions in the contact definitions for John and Bob:
+
+</p>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name john
+
+ ...
+
+ host_notification_period john-oncall
+
+ service_notification_period john-oncall
+
+ }
+
+</pre>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name bob
+
+ ...
+
+ host_notification_period bob-oncall
+
+ service_notification_period bob-oncall
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Scenario 4: Vacation Days</u></strong>
+
+</p>
+
+
+
+<p>
+
+In this scenarios, John handles notifications for all days except those he has off. He has several standing days off each month, as well as some planned vacations. Bob handles notifications when John is on vacation or out of the office.
+
+</p>
+
+
+
+<p>
+
+First, define a timeperiod that contains time ranges for John's vacation days and days off:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ name john-out-of-office
+
+ timeperiod_name john-out-of-office
+
+ day 15 00:00-24:00 ; 15th day of each month
+
+ day -1 00:00-24:00 ; Last day of each month (28th, 29th, 30th, or 31st)
+
+ day -2 00:00-24:00 ; 2nd to last day of each month (27th, 28th, 29th, or 30th)
+
+ january 2 00:00-24:00 ; January 2nd each year
+
+ june 1 - july 5 00:00-24:00 ; Yearly camping trip (June 1st - July 5th)
+
+ 2007-11-01 - 2007-11-10 00:00-24:00 ; Vacation to the US Virgin Islands (November 1st-10th, 2007)
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Next, define a timeperiod for John's on-call times that excludes the dates/times defined in the timeperiod above:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperiod_name john-oncall
+
+ monday 00:00-24:00
+
+ tuesday 00:00-24:00
+
+ wednesday 00:00-24:00
+
+ thursday 00:00-24:00
+
+ friday 00:00-24:00
+
+ exclude john-out-of-office ; Exclude dates/times John is out
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You can now reference this timeperiod in John's contact definition:
+
+</p>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name john
+
+ ...
+
+ host_notification_period john-oncall
+
+ service_notification_period john-oncall
+
+ }
+
+</pre>
+
+
+
+<p>
+
+Define a new timeperiod for Bob's on-call times that include the dates/times that John is out of the office:
+
+</p>
+
+
+
+<pre>
+
+define timeperiod{
+
+ timeperod_name bob-oncall
+
+ use john-out-of-office ; Include holiday date/times that John is out
+
+ }
+
+</pre>
+
+
+
+<p>
+
+You can now reference this timeperiod in Bob's contact definition:
+
+</p>
+
+
+
+<pre>
+
+define contact{
+
+ contact_name bob
+
+ ...
+
+ host_notification_period bob-oncall
+
+ service_notification_period bob-oncall
+
+ }
+
+</pre>
+
+
+
+<p>
+
+<strong><u>Other Scenarios</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are a lot of other on-call notification rotation scenarios that you might have. The date exception directive in <a href="objectdefinitions.html#timeperiod">timeperiod definitions</a> is capable of handling most dates and date ranges that you might need to use, so check out the different formats that you can use. If you make a mistake when creating timeperiod definitions, always err on the side of giving someone else more on-call duty time. :-)
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Passive Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Passive Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="activechecks.html">Active Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="hostchecks.html">Host Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+In most cases you'll use Nagios to monitor your hosts and services using regularly scheduled <a href="activechecks.html">active checks</a>. Active checks can be used to "poll" a device or service for status information every so often. Nagios also supports a way to monitor hosts and services passively instead of actively. They key features of passive checks are as follows:
+
+</p>
+
+
+
+<ul>
+
+<li>Passive checks are initiated and performed external applications/processes</li>
+
+<li>Passive check results are submitted to Nagios for processing</li>
+
+</ul>
+
+
+
+<p>
+
+The major difference between active and passive checks is that active checks are initiated and performed by Nagios, while passive checks are performed by external applications.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Uses For Passive Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+Passive checks are useful for monitoring services that are:
+
+</p>
+
+
+
+<ul>
+
+<li>Asynchronous in nature and cannot be monitored effectively by polling their status on a regularly scheduled basis
+
+<li>Located behind a firewall and cannot be checked actively from the monitoring host
+
+</ul>
+
+
+
+<p>
+
+Examples of asynchronous services that lend themselves to being monitored passively include SNMP traps and security alerts. You never know how many (if any) traps or alerts you'll receive in a given time frame, so it's not feasible to just monitor their status every few minutes.
+
+</p>
+
+
+
+<p>
+
+Passive checks are also used when configuring <a href="distributed.html">distributed</a> or <a href="redundancy.html">redundant</a> monitoring installations.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Passive Checks Work</u></strong>
+
+</p>
+
+
+
+<img src="images/passivechecks.png" border="0" style="float: right; padding: 0 0 10px 10px;" alt="Passive Checks" title="Passive Checks">
+
+
+
+<p>
+
+Here's how passive checks work in more detail...
+
+</p>
+
+
+
+<ol>
+
+<li>An external application checks the status of a host or service.<br><br></li>
+
+<li>The external application writes the results of the check to the <a href="configmain.html#command_file">external command file</a>.<br><br></li>
+
+<li>The next time Nagios reads the external command file it will place the results of all passive checks into a queue for later processing. The same queue that is used for storing results from active checks is also used to store the results from passive checks.<br><br></li>
+
+<li>Nagios will periodically execute a <a href="configmain.html#check_result_reaper_frequency">check result reaper event</a> and scan the check result queue. Each service check result that is found in the queue is processed in the same manner - regardless of whether the check was active or passive. Nagios may send out notifications, log alerts, etc. depending on the check result information.<br><br></li>
+
+</ol>
+
+
+
+<p>
+
+The processing of active and passive check results is essentially identical. This allows for seamless integration of status information from external applications with Nagios.
+
+</p>
+
+
+
+<br clear="all">
+
+
+
+<p>
+
+<strong><u>Enabling Passive Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order to enable passive checks in Nagios, you'll need to do the following:
+
+</p>
+
+
+
+<ul>
+
+<li>Set <a href="configmain.html#accept_passive_service_checks">accept_passive_service_checks</a> directive to 1.</li>
+
+<li>Set the <i>passive_checks_enabled</i> directive in your host and service definitions to 1.</li>
+
+</ul>
+
+
+
+<p>
+
+If you want to disable processing of passive checks on a global basis, set the <a href="configmain.html#accept_passive_service_checks">accept_passive_service_checks</a> directive to 0.
+
+</p>
+
+
+
+<p>
+
+If you would like to disable passive checks for just a few hosts or services, use the <i>passive_checks_enabled</i> directive in the host and/or service definitions to do so.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Submitting Passive Service Check Results</u></strong>
+
+</p>
+
+
+
+<p>
+
+External applications can submit passive service check results to Nagios by writing a PROCESS_SERVICE_CHECK_RESULT <a href="extcommands.html">external command</a> to the external command file.
+
+</p>
+
+
+
+<p>
+
+The format of the command is as follows:
+
+</p>
+
+
+
+<pre>
+
+[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<svc_description>;<return_code>;<plugin_output>
+
+</pre>
+
+
+
+<p>
+
+where...
+
+</p>
+
+
+
+<ul>
+
+<li><i>timestamp</i> is the time in time_t format (seconds since the UNIX epoch) that the service check was perfomed (or submitted). Please note the single space after the right bracket.
+
+<li><i>host_name</i> is the short name of the host associated with the service in the service definition
+
+<li><i>svc_description</i> is the description of the service as specified in the service definition
+
+<li><i>return_code</i> is the return code of the check (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN)
+
+<li><i>plugin_output</i> is the text output of the service check (i.e. the plugin output)
+
+</ul>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note">
+
+Note: A service must be defined in Nagios before you can submit passive check results for it! Nagios will ignore all check results for services that had not been configured before it was last (re)started.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip">
+
+An example shell script of how to submit passive service check results to Nagios can be found in the documentation on <a href="volatileservices.html">volatile services</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Submitting Passive Host Check Results</u></strong>
+
+</p>
+
+
+
+<p>
+
+External applications can submit passive host check results to Nagios by writing a PROCESS_HOST_CHECK_RESULT external command to the external command file.
+
+</p>
+
+
+
+<p>
+
+The format of the command is as follows:
+
+</p>
+
+
+
+<pre>
+
+[<timestamp>] PROCESS_HOST_CHECK_RESULT;<host_name>;<host_status>;<plugin_output>
+
+</pre>
+
+
+
+<p>
+
+where...
+
+</p>
+
+
+
+<ul>
+
+<li><i>timestamp</i> is the time in time_t format (seconds since the UNIX epoch) that the host check was perfomed (or submitted). Please note the single space after the right bracket.
+
+<li><i>host_name</i> is the short name of the host (as defined in the host definition)
+
+<li><i>host_status</i> is the status of the host (0=UP, 1=DOWN, 2=UNREACHABLE)
+
+<li><i>plugin_output</i> is the text output of the host check
+
+</ul>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note">
+
+Note: A host must be defined in Nagios before you can submit passive check results for it! Nagios will ignore all check results for hosts that had not been configured before it was last (re)started.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Passive Checks and Host States</u></strong>
+
+</p>
+
+
+
+<p>
+
+Unlike with active host checks, Nagios does not (by default) attempt to determine whether or host is DOWN or UNREACHABLE with passive checks. Rather, Nagios takes the passive check result to be the actual state the host is in and doesn't try to determine the host's actual state using the <a href="networkreachability.html">reachability logic</a>. This can cause problems if you are submitting passive checks from a remote host or you have a <a href="distributed.html">distributed monitoring setup</a> where the parent/child host relationships are different.
+
+</p>
+
+
+
+<p>
+
+You can tell Nagios to translate DOWN/UNREACHABLE passive check result states to their "proper" state by using the <a href="configmain.html#translate_passive_host_checks">translate_passive_host_checks</a> variable. More information on how this works can be found <a href="passivestatetranslation.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Passive host checks are normally treated as <a href="statetypes.html">HARD states</a>, unless the <a href="configmain.html#passive_host_checks_are_soft">passive_host_checks_are_soft</a> option is enabled.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Submitting Passive Check Results From Remote Hosts</u></strong>
+
+</p>
+
+
+
+<img src="images/nsca.png" border="0" style="float: right; padding: 0 0 10px 10px;" alt="NSCA Addon" title="NSCA Addon">
+
+
+
+<p>
+
+If an application that resides on the same host as Nagios is sending passive host or service check results, it can simply write the results directly to the external command file as outlined above. However, applications on remote hosts can't do this so easily.
+
+</p>
+
+
+
+<p>
+
+In order to allow remote hosts to send passive check results to the monitoring host, I've developed the <a href="addons.html#nsca">NSCA</a> addon. The NSCA addon consists of a daemon that runs on the Nagios hosts and a client that is executed from remote hosts. The daemon will listen for connections from remote clients, perform some basic validation on the results being submitted, and then write the check results directly into the external command file (as described above). More information on the NSCA addon can be found <a href="addons.html#nsca">here</a>.
+
+</p>
+
+
+
+<br clear="all">
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Passive Host State Translation</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Passive Host State Translation</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="hostchecks.html">Host Checks</a>, <a href="networkreachability.html">Network Reachability</a>, <a href="passivechecks.html">Passive Checks</a>, <a href="distributed.html">Distributed Monitoring</a>, <a href="redundancy.html">Redundant/Failover Monitoring</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+When Nagios receives passive host checks from remote sources (i.e other Nagios instances in distributed or failover setups), the host state reported by the remote source may not accurately reflect the state of the host from Nagios' view. As distributed and failover monitoring installations are fairly common, it is important to provide a mechanism for ensuring accurate host states between different instances of Nagios.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Different World Views</u></strong>
+
+</p>
+
+
+
+<p>
+
+The image below shows a simplified view of a failover monitoring setup.
+
+</p>
+
+
+
+<ul>
+
+<li><i>Nagios-A</i> is the primary monitoring server, and is actively monitoring all switches and routers.</li>
+
+<li><i>Nagios-B</i> and <i>Nagios-C</i> are backup monitoring servers, and are receiving passive check results from <i>Nagios-A</i></li>
+
+<li>Both <i>Router-C</i> and <i>Router-D</i> have suffered failures and are offline.</li>
+
+</ul>
+
+
+
+<img src="images/passivehosttranslation.png" border="0" alt="Passive State Translation" title="Passive State Translation">
+
+
+
+<p>
+
+What states are <i>Router-C</i> and <i>Router-D</i> currently in? The answer depends on which Nagios instance you ask.
+
+</p>
+
+
+
+<ul>
+
+<li><i>Nagios-A</i> sees <i>Router-D</i> as DOWN and <i>Router-C</i> as UNREACHABLE
+
+<li><i>Nagios-B</i> should see <i>Router-C</i> as DOWN and <i>Router-D</i> as UNREACHABLE
+
+<li><i>Nagios-C</i> should see both routers as being DOWN.
+
+</ul>
+
+
+
+<p>
+
+Each Nagios instance has a different view of the network. The backup monitoring servers should not blindly accept passive host states from the primary monitoring server, or they will have incorrect information on the current state of the network.
+
+</p>
+
+
+
+<p>
+
+Without translating passive host check results from the primary monitoring server (<i>Nagios-A</i>), <i>Nagios-C</i> would see <i>Router-D</i> as UNREACHABLE, when it is really DOWN based on its viewpoint. Similarly, the DOWN/UNREACHABLE states (from the viewpoint of <i>Nagios-A</i>) for <i>Router-C</i> and <i>Router-D</i> should be flipped from the viewpoint of <i>Nagios-B</i>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: There may be some situations where you do not want Nagios to translate DOWN/UNREACHABLE states from remote sources to their "correct" state from the viewpoint of the local Nagios instance. For example, in distributed monitoring environments you may want the central Nagios instance to know how distributed instances see their respective portions of the network.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Enabling State Translation</u></strong>
+
+</p>
+
+
+
+<p>
+
+By default, Nagios will <i>not</i> automatically translate DOWN/UNREACHABLE states from passive check results. You will need to enable this feature if you need and want it.
+
+</p>
+
+
+
+<p>
+
+The automatic translation of passive host check states is controlled by the <a href="configmain.html#translate_passive_host_checks">translate_passive_host_checks</a> variable. Enable it and Nagios will automatically translate DOWN and UNREACHABLE states from remote sources to their correct state for the local instance of Nagios.
+
+</p>
+
+
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Performance Data</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Performance Data</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="plugins.html">Plugins</a>, <a href="pluginapi.html">Plugin API</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios is designed to allow <a href="plugins.html">plugins</a> to return optional performance data in addition to normal status data, as well as allow you to pass that performance data to external applications for processing. A description of the different types of performance data, as well as information on how to go about processing that data is described below...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Types of Performance Data</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are two basic categories of performance data that can be obtained from Nagios:
+
+</p>
+
+
+
+<ol>
+
+<li>Check performance data
+
+<li>Plugin performance data
+
+</ol>
+
+
+
+<p>
+
+Check performance data is internal data that relates to the actual execution of a host or service check. This might include things like service check latency (i.e. how "late" was the service check from its scheduled execution time) and the number of seconds a host or service check took to execute. This type of performance data is available for all checks that are performed. The <a href="macrolist.html#hostexecutiontime">$HOSTEXECUTIONTIME$</a> and <a href="macrolist.html#serviceexecutiontime">$SERVICEEXECUTIONTIME$</a> <a href="macros.html">macros</a> can be used to determine the number of seconds a host or service check was running and the <a href="macrolist.html#hostlatency">$HOSTLATENCY$</a> and <a href="macrolist.html#servicelatency">$SERVICELATENCY$</a> macros can be used to determine how "late" a regularly-scheduled host or service check was.
+
+</p>
+
+
+
+<p>
+
+Plugin performance data is external data specific to the plugin used to perform the host or service check. Plugin-specific data can include things like percent packet loss, free disk space, processor load, number of current users, etc. - basically any type of metric that the plugin is measuring when it executes. Plugin-specific performance data is optional and may not be supported by all plugins. Plugin-specific performance data (if available) can be obtained by using the <a href="macrolist.html#hostperfdata">$HOSTPERFDATA$</a> and <a href="macrolist.html#serviceperfdata">$SERVICEPERFDATA$</a> <a href="macros.html">macros</a>. Read on for more information on how plugins can return performance data to Nagios for inclusion in the $HOSTPERFDATA$ and $SERVICEPERFDATA$ macros.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Plugin Performance Data</u></strong>
+
+</p>
+
+
+
+<p>
+
+At a minimum, Nagios plugins must return a single line of human-readable text that indicates the status of some type of measurable data. For example, the check_ping plugin might return a line of text like the following:
+
+</p>
+
+
+
+<pre>
+
+PING ok - Packet loss = 0%, RTA = 0.80 ms
+
+</pre>
+
+
+
+<p>
+
+With this simple type of output, the entire line of text is available in the $HOSTOUTPUT$ or $SERVICEOUTPUT$ <a href="macros.html">macros</a> (depending on whether this plugin was used as a host check or service check).
+
+</p>
+
+
+
+<p>
+
+Plugins can return optional performance data in their output by sending the normal, human-readable text string that they usually would, followed by a pipe character (|), and then a string containing one or more performance data metrics. Let's take the check_ping plugin as an example and assume that it has been enhanced to return percent packet loss and average round trip time as performance data metrics. Sample output from the plugin might look like this:
+
+</p>
+
+
+
+<pre>
+
+PING ok - Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80
+
+</pre>
+
+
+
+<p>
+
+When Nagios sees this plugin output format it will split the output into two parts:
+
+</p>
+
+
+
+<ol>
+
+<li>Everything before the pipe character is considered to be the "normal" plugin output and will be stored in either the $HOSTOUTPUT$ or $SERVICEOUTPUT$ macro</li>
+
+<li>Everything after the pipe character is considered to be the plugin-specific performance data and will be stored in the $HOSTPERFDATA$ or $SERVICEPERFDATA$ macro</li>
+
+</ol>
+
+
+
+<p>
+
+In the example above, the $HOSTOUTPUT$ or $SERVICEOUTPUT$ macro would contain "<i>PING ok - Packet loss = 0%, RTA = 0.80 ms</i>" (without quotes) and the $HOSTPERFDATA$ or $SERVICEPERFDATA$ macro would contain "<i>percent_packet_loss=0, rta=0.80</i>" (without quotes).
+
+</p>
+
+
+
+<p>
+
+Multiple lines of performace data (as well as normal text output) can be obtained from plugins, as described in the <a href="pluginapi.html">plugin API documentation</a>.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: The Nagios daemon doesn't directly process plugin performance data, so it doesn't really care what the performance data looks like. There aren't really any inherent limitations on the format or content of the performance data. However, if you are using an external addon to process the performance data (i.e. PerfParse), the addon may be expecting that the plugin returns performance data in a specific format. Check the documentation that comes with the addon for more information.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Processing Performance Data</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you want to process the performance data that is available from Nagios and the plugins, you'll need to do the following:
+
+</p>
+
+
+
+<ol>
+
+<li>Enable the <a href="configmain.html#process_performance_data">process_performance_data</a> option.<br><br>
+
+<li>Configure Nagios so that performance data is either written to files and/or processed by executing commands.
+
+</ol>
+
+
+
+<p>
+
+Read on for information on how to process performance data by writing to files or executing commands.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Processing Performance Data Using Commands</u></strong>
+
+</p>
+
+
+
+<p>
+
+The most flexible way to process performance data is by having Nagios execute commands (that you specify) to process or redirect the data for later processing by external applications. The commands that Nagios executes to process host and service performance data are determined by the <a href="configmain.html#host_perfdata_command">host_perfdata_command</a> and <a href="configmain.html#service_perfdata_command">service_perfdata_command</a> options, respectively.
+
+</p>
+
+
+
+<p>
+
+An example command definition that redirects service check performance data to a text file for later processing by another application is shown below:
+
+</p>
+
+
+
+<pre>
+
+define command{
+
+ command_name store-service-perfdata
+
+ command_line /bin/echo -e "$LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICEATTEMPT$\t$SERVICESTATETYPE$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$" >> /usr/local/nagios/var/service-perfdata.dat
+
+ }
+
+</pre>
+
+
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: This method, while flexible, comes with a relatively high CPU overhead. If you're processing performance data for a large number of hosts and services, you'll probably want Nagios to write performance data to files instead. This method is described in the next section.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Writing Performance Data To Files</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can have Nagios write all host and service performance data directly to text files using the <a href="configmain.html#host_perfdata_file">host_perfdata_file</a> and <a href="configmain.html#service_perfdata_file">service_perfdata_file</a> options. The format in which host and service performance data is written to those files is determined by the <a href="configmain.html#host_perfdata_file_template">host_perfdata_file_template</a> and <a href="configmain.html#service_perfdata_file_template">service_perfdata_file_template</a> options.
+
+</p>
+
+
+
+<p>
+
+An example file format template for service performance data might look like this:
+
+</p>
+
+
+
+<pre>
+
+service_perfdata_file_template=[SERVICEPERFDATA]\t$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$
+
+</pre>
+
+
+
+<p>
+
+By default, the text files will be opened in "append" mode. If you need to change the modes to "write" or "non-blocking read/write" (useful when writing to pipes), you can use the <a href="configmain.html#host_perfdata_file_mode">host_perfdata_file_mode</a> and <a href="configmain.html#service_perfdata_file_mode">service_perfdata_file_mode</a> options.
+
+</p>
+
+
+
+<p>
+
+Additionally, you can have Nagios periodically execute commands to periocially process the performance data files (e.g. rotate them) using the <a href="configmain.html#host_perfdata_file_processing_command">host_perfdata_file_processing_command</a> and <a href="configmain.html#service_perfdata_file_processing_command">service_perfdata_file_processing_command</a> options. The interval at which these commands are executed are governed by the <a href="configmain.html#host_perfdata_file_processing_interval">host_perfdata_file_processing_interval</a> and <a href="configmain.html#service_perfdata_file_processing_interval">service_perfdata_file_processing_interval</a> options, respectively.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Nagios Plugin API</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Nagios Plugin API</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="plugins.html">Plugin Overview</a>, <a href="epnplugins.html">Developing Plugins For Use With Embedded Perl</a>, <a href="perfdata.html">Performance Data</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Other Resources</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you're looking at writing your own plugins for Nagios, please make sure to visit these other resources:
+
+</p>
+
+
+
+<ul>
+
+<li>The official <a href="http://sourceforge.net/projects/nagiosplug/">Nagios plugin project website</a></li>
+
+<li>The official <a href="http://nagiosplug.sourceforge.net/developer-guidelines.html">Nagios plugin development guidelines</a></li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Plugin Overview</u></strong>
+
+</p>
+
+
+
+<p>
+
+Scripts and executables must do two things (at a minimum) in order to function as Nagios plugins:
+
+</p>
+
+
+
+<ul>
+
+<li>Exit with one of several possible return values</li>
+
+<li>Return at least one line of text output to STDOUT</li>
+
+</ul>
+
+
+
+<p>
+
+The inner workings of your plugin are unimportant to Nagios. Your plugin could check the status of a TCP port, run a database query, check disk free space, or do whatever else it needs to check something. The details will depend on what needs to be checked - that's up to you.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Return Code</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios determines the status of a host or service by evaluating the return code from plugins. The following tables shows a list of valid return codes, along with their corresponding service or host states.
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Plugin Return Code</th><th>Service State</th><th>Host State</th></tr>
+
+<tr><td>0</td><td>OK</td><td>UP</td></tr>
+
+<tr><td>1</td><td>WARNING</td><td>UP or DOWN/UNREACHABLE*</td></tr>
+
+<tr><td>2</td><td>CRITICAL</td><td>DOWN/UNREACHABLE</td></tr>
+
+<tr><td>3</td><td>UNKNOWN</td><td>DOWN/UNREACHABLE</td></tr>
+
+</table>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: If the <a href="configmain.html#use_aggressive_host_checking">use_aggressive_host_checking</a> option is enabled, return codes of 1 will result in a host state of DOWN or UNREACHABLE. Otherwise return codes of 1 will result in a host state of UP. The process by which Nagios determines whether or not a host is DOWN or UNREACHABLE is discussed <a href="networkreachability.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Plugin Output Spec</u></strong>
+
+</p>
+
+
+
+<p>
+
+At a minimum, plugins should return at least one of text output. Beginning with Nagios 3, plugins can optionally return multiple lines of output. Plugins may also return optional performance data that can be processed by external applications. The basic format for plugin output is shown below:
+
+</p>
+
+
+
+<p>
+
+<font color="red">TEXT OUTPUT</font> | <font color="#FFA500">OPTIONAL PERFDATA</font><br>
+
+<font color="blue">LONG TEXT LINE 1<br>
+
+LONG TEXT LINE 2<br>
+
+...<br>
+
+LONG TEXT LINE N </font>| <font color="#FFA500">PERFDATA LINE 2</font><br>
+
+<font color="#FFA500">PERFDATA LINE 3<br>
+
+...<br>
+
+PERFDATA LINE N</font>
+
+</p>
+
+
+
+<p>
+
+The performance data (shown in <font color="#FFA500">orange</font>) is optional. If a plugin returns performance data in its output, it must separate the performance data from the other text output using a pipe (|) symbol. Additional lines of long text output (shown in <font color="blue">blue</font>) are also optional.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Plugin Output Examples</u></strong>
+
+</p>
+
+
+
+<p>
+
+Let's see some examples of possible plugin output...
+
+</p>
+
+
+
+<p>
+
+<strong>Case 1: One line of output (text only)</strong><br>
+
+Assume we have a plugin that returns one line of output that looks like this:
+
+</p>
+
+
+
+<div style="padding: 0 0 0 25px;">
+
+<div style="display: inline; color: red;">DISK OK - free space: / 3326 MB (56%);</div>
+
+</div>
+
+
+
+<p>
+
+If this plugin was used to perform a service check, the entire line of output will be stored in the <a href="macrolist.html#serviceoutput">$SERVICEOUTPUT$</a> macro.
+
+</p>
+
+
+
+<p>
+
+<strong>Case 2: One line of output (text and perfdata)</strong><br>
+
+A plugin can return optional performance data for use by external applications. To do this, the performance data must be separated from the text output with a pipe (|) symbol like such:
+
+</p>
+
+
+
+<div style="padding: 0 0 0 25px;">
+
+<div style="display: inline; color: red;">DISK OK - free space: / 3326 MB (56%);</div><div style="display: inline;"> | </div><div style="display: inline; color: orange;">/=2643MB;5948;5958;0;5968</div>
+
+</div>
+
+
+
+<div style="float: left;">If this plugin was used to perform a service check, the</div>
+
+<div style="display: inline; color: red;"> red </div>
+
+<div style="display: inline;">portion of output (left of the pipe separator) will be stored in the <a href="macrolist.html#serviceoutput">$SERVICEOUTPUT$</a> macro and the</div>
+
+<div style="color: orange; display: inline;"> orange </div>
+
+<div style="display: inline;">portion of output (right of the pipe separator) will be stored in the <a href="macrolist.html#serviceperfdata">$SERVICEPERFDATA$</a> macro.</div>
+
+
+
+<p>
+
+<strong>Case 3: Multiple lines of output (text and perfdata)</strong><br>
+
+A plugin optionally return multiple lines of both text output and perfdata, like such:
+
+</p>
+
+
+
+<div style="padding: 0 0 0 25px;">
+
+<font color="red">DISK OK - free space: / 3326 MB (56%);</font> | <font color="#FFA500">/=2643MB;5948;5958;0;5968</font><br>
+
+<font color="blue">/ 15272 MB (77%);</font><br>
+
+<font color="blue">/boot 68 MB (69%);</font><br>
+
+<font color="blue">/home 69357 MB (27%);</font><br>
+
+<font color="blue">/var/log 819 MB (84%);</font> | <font color="#FFA500">/boot=68MB;88;93;0;98</font><br>
+
+<font color="#FFA500">/home=69357MB;253404;253409;0;253414 </font><br>
+
+<font color="#FFA500">/var/log=818MB;970;975;0;980</font><br>
+
+</div>
+
+
+
+<p>
+
+If this plugin was used to perform a service check, the <font color="red">red</font> portion of first line of output (left of the pipe separator) will be stored in the <a href="macrolist.html#serviceoutput">$SERVICEOUTPUT$</a> macro.
+
+The <font color="#FFA500">orange</font> portions of the first and subsequent lines are concatenated (with spaces) are stored in the <a href="macrolist.html#serviceperfdata">$SERVICEPERFDATA$</a> macro. The <font color="blue">blue</font> portions of the 2nd - 5th lines of output will be concatenated (with escaped newlines) and stored in <a href="macrolist.html#longserviceoutput">$LONGSERVICEOUTPUT$</a> the macro.
+
+</p>
+
+
+
+<p>The final contents of each macro are listed below:</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Macro</th><th>Value</th></tr>
+
+<tr><td>$SERVICEOUTPUT$</td><td><font color="red">DISK OK - free space: / 3326 MB (56%);</font></td></tr>
+
+<tr><td>$SERVICEPERFDATA$</td><td><font color="#FFA500">/=2643MB;5948;5958;0;5968 /boot=68MB;88;93;0;98 /home=69357MB;253404;253409;0;253414 /var/log=818MB;970;975;0;980</font></td></tr>
+
+<tr><td>$LONGSERVICEOUTPUT$</td><td><font color="blue">/ 15272 MB (77%);\n/boot 68 MB (69%);\n/var/log 819 MB (84%);</font></td></tr>
+
+</table>
+
+
+
+<p>
+
+With regards to multiple lines of output, you have the following options for returning performance data:
+
+</p>
+
+
+
+<ul>
+
+<li>You can choose to return no performance data whatsoever</li>
+
+<li>You can return performance data on the first line only</li>
+
+<li>You can return performance data only in subsequent lines (after the first)</li>
+
+<li>You can return performance data in both the first line and subsequent lines (as shown above)</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Plugin Output Length Restrictions</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios will only read the first 4 KB of data that a plugin returns. This is done in order to prevent runaway plugins from dumping megs or gigs of data back to Nagios. This 4 KB output limit is fairly easy to change if you need. Simply edit the value of the MAX_PLUGIN_OUTPUT_LENGTH definition in the <i>include/nagios.h.in</i> file of the source code distribution and recompile Nagios. There's nothing else you need to change!
+
+</p>
+
+
+
+<p>
+
+<strong><u>Examples</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you're looking for some example plugins to study, I would recommend that you download the official Nagios plugins and look through the code for various C, Perl, and shell script plugins. Information on obtaining the official Nagios plugins can be found <a href="plugins.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Perl Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios features an optional <a href="embeddedperl.html">embedded Perl interpreter</a> which can speed up the execution of Perl plugins. More information on developing Perl plugins for use with the embedded Perl interpreter can be found <a href="embeddedperl.html">here</a>.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Nagios Plugins</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Nagios Plugins</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="pluginapi.html">Plugin API</a>, <a href="embeddedperl.html">Embedded Perl Interpreter Overview</a>, <a href="activechecks.html">Active Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+<p>
+
+Unlike many other monitoring tools, Nagios does not include any internal mechanisms for checking the status of hosts and services on your network. Instead, Nagios relies on external programs (called plugins) to do all the dirty work.
+
+</p>
+
+
+
+<p>
+
+<strong><u>What Are Plugins?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Plugins are compiled executables or scripts (Perl scripts, shell scripts, etc.) that can be run from a command line to check the status or a host or service. Nagios uses the results from plugins to determine the current status of hosts and services on your network.
+
+</p>
+
+
+
+<p>
+
+Nagios will execute a plugin whenever there is a need to check the status of a service or host. The plugin does <i>something</i> (notice the very general term) to perform the check and then simply returns the results to Nagios. Nagios will process the results that it receives from the plugin and take any necessary actions (running <a href="eventhandlers.html">event handlers</a>, sending out <a href="notifications.html">notifications</a>, etc).
+
+</p>
+
+
+
+<p>
+
+<strong><u>Plugins As An Abstraction Layer</u></strong>
+
+</p>
+
+
+
+<img src="images/plugins.png" border="0" style="float: right; padding: 0 0 0 25px;" alt="Plugins">
+
+
+
+<p>
+
+Plugins act as an abstraction layer between the monitoring logic present in the Nagios daemon and the actual services and hosts that are being monitored.
+
+</p>
+
+
+
+<p>
+
+The upside of this type of plugin architecture is that you can monitor just about anything you can think of. If you can automate the process of checking something, you can monitor it with Nagios. There are already a lot of plugins that have been created in order to monitor basic resources such as processor load, disk usage, ping rates, etc. If you want to monitor something else, take a look at the documentation on <a href="pluginapi.html">writing plugins</a> and roll your own. Its simple!
+
+</p>
+
+
+
+<p>
+
+The downside to this type of plugin architecture is the fact that Nagios has absolutely no idea what it is that you're monitoring. You could be monitoring network traffic statistics, data error rates, room temperate, CPU voltage, fan speed, processor load, disk space, or the ability of your super-fantastic toaster to properly brown your bread in the morning... Nagios doesn't understand the specifics of what's being monitored - it just tracks changes in the <i>state</i> of those resources. Only the plugins themselves know exactly what they're monitoring and how to perform the actual checks.
+
+</p>
+
+
+
+
+
+<div style="clear: both;"></div>
+
+
+
+<p>
+
+<strong><u>What Plugins Are Available?</u></strong>
+
+</p>
+
+
+
+<p>
+
+There are plugins currently available to monitor many different kinds of devices and services, including:
+
+</p>
+
+
+
+<ul>
+
+<li>HTTP, POP3, IMAP, FTP, SSH, DHCP</li>
+
+<li>CPU Load, Disk Usage, Memory Usage, Current Users</li>
+
+<li>Unix/Linux, Windows, and Netware Servers</li>
+
+<li>Routers and Switches</li>
+
+<li>etc.</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Obtaining Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Plugins are not distributed with Nagios, but you can download the official Nagios plugins and many additional plugins created and maintained by Nagios users from the following locations:
+
+</p>
+
+
+
+<ul>
+
+<li>Nagios Plugins Project: <a href="http://nagiosplug.sourceforge.net/">http://nagiosplug.sourceforge.net/</a></li>
+
+<li>Nagios Downloads Page: <a href="http://www.nagios.org/download/">http://www.nagios.org/download/</a></li>
+
+<li>NagiosExchange.org: <a href="http://www.nagiosexchange.org/">http://www.nagiosexchange.org/</a></li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>How Do I Use Plugin <i>X</i>?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Most all plugins will display basic usage information when you execute them using '-h' or '--help' on the command line. For example, if you want to know how the check_http plugin works or what options it accepts, you should try executing the following command:
+
+</p>
+
+
+
+<pre>
+
+./check_http --help
+
+</pre>
+
+
+
+<a name="howto"></a>
+
+<p>
+
+<strong><u>Plugin API</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can find information on the technical aspects of plugins, as well as how to go about creating your own custom plugins <a href="pluginapi.html">here</a>.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Fedora Quickstart</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Fedora Quickstart</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guides</a>, <a href="security.html">Security Considerations</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This guide is intended to provide you with simple instructions on how to install Nagios from source (code) on Fedora and have it monitoring your local machine inside of 20 minutes. No advanced installation options are discussed here - just the basics that will work for 95% of users who want to get started.
+
+</p>
+
+
+
+<p>
+
+These instructions were written based on a standard <b>Fedora Core 6</b> Linux distribution.
+
+</p>
+
+
+
+<p>
+
+<strong><u>What You'll End Up With</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you follow these instructions, here's what you'll end up with:
+
+</p>
+
+
+
+<ul>
+
+<li>Nagios and the plugins will be installed underneath /usr/local/nagios</li>
+
+<li>Nagios will be configured to monitor a few aspects of your local system (CPU load, disk usage, etc.)</li>
+
+<li>The Nagios web interface will be accessible at http://localhost/nagios/</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Prerequisites</u></strong>
+
+</p>
+
+
+
+<p>
+
+During portions of the installation you'll need to have <b>root</b> access to your machine.
+
+</p>
+
+
+
+<p>
+
+Make sure you've installed the following packages on your Fedora installation before continuing.
+
+</p>
+
+
+
+<ul>
+
+<li>Apache</li>
+
+<li>PHP</li>
+
+<li>GCC compiler</li>
+
+<li><a href="http://www.boutell.com/gd/">GD</a> development libraries</li>
+
+</ul>
+
+
+
+<p>
+
+You can use <i>yum</i> to install these packages by running the following commands (as root):
+
+</p>
+
+
+
+<pre>
+
+yum install httpd php
+
+yum install gcc glibc glibc-common
+
+yum install gd gd-devel
+
+</pre>
+
+
+
+<p>
+
+<strong><u>1) Create Account Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+Become the root user.
+
+</p>
+
+
+
+<pre>
+
+su -l
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagios</i> user account and give it a password.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/useradd -m nagios
+
+passwd nagios
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagcmd</i> group for allowing external commands to be submitted through the web interface. Add both the nagios user and the apache user to the group.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/groupadd nagcmd
+
+/usr/sbin/usermod -a -G nagcmd nagios
+
+/usr/sbin/usermod -a -G nagcmd apache
+
+</pre>
+
+
+
+<p>
+
+<strong><u>2) Download Nagios and the Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Create a directory for storing the downloads.
+
+</p>
+
+
+
+<pre>
+
+mkdir ~/downloads
+
+cd ~/downloads
+
+</pre>
+
+
+
+<p>
+
+Download the source code tarballs of both Nagios and the Nagios plugins (visit <a href="http://www.nagios.org/download/">http://www.nagios.org/download/</a> for links to the latest versions). These directions were tested with Nagios 3.1.1 and Nagios Plugins 1.4.11.
+
+</p>
+
+
+
+<pre>
+
+wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz
+
+wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.11.tar.gz
+
+</pre>
+
+
+
+<p>
+
+<strong><u>3) Compile and Install Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Extract the Nagios source code tarball.
+
+</p>
+
+
+
+<pre>
+
+cd ~/downloads
+
+tar xzf nagios-3.2.1.tar.gz
+
+cd nagios-3.2.1
+
+</pre>
+
+
+
+<p>
+
+Run the Nagios configure script, passing the name of the group you created earlier like so:
+
+</p>
+
+
+
+<pre>
+
+./configure --with-command-group=nagcmd
+
+</pre>
+
+
+
+<p>
+
+Compile the Nagios source code.
+
+</p>
+
+
+
+<pre>
+
+make all
+
+</pre>
+
+
+
+<p>
+
+Install binaries, init script, sample config files and set permissions on the external command directory.
+
+</p>
+
+
+
+<pre>
+
+make install
+
+make install-init
+
+make install-config
+
+make install-commandmode
+
+</pre>
+
+
+
+<p>
+
+Don't start Nagios yet - there's still more that needs to be done...
+
+</p>
+
+
+
+<p>
+
+<strong><u>4) Customize Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Sample <a href="config.html">configuration files</a> have now been installed in the <i>/usr/local/nagios/etc</i> directory. These sample files should work fine for getting started with Nagios. You'll need to make just one change before you proceed...
+
+</p>
+
+
+
+<p>
+
+Edit the <i>/usr/local/nagios/etc/objects/contacts.cfg</i> config file with your favorite editor and change the email address associated with the <i>nagiosadmin</i> contact definition to the address you'd like to use for receiving alerts.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/contacts.cfg
+
+</pre>
+
+
+
+<p>
+
+<strong><u>5) Configure the Web Interface</u></strong>
+
+</p>
+
+
+
+<p>
+
+Install the Nagios web config file in the Apache conf.d directory.
+
+</p>
+
+
+
+<pre>
+
+make install-webconf
+
+</pre>
+
+
+
+<p>
+
+Create a <i>nagiosadmin</i> account for logging into the Nagios web interface. Remember the password you assign to this account - you'll need it later.
+
+</p>
+
+
+
+<pre>
+
+htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
+
+</pre>
+
+
+
+<p>
+
+Restart Apache to make the new settings take effect.
+
+</p>
+
+
+
+<pre>
+
+service httpd restart
+
+</pre>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Consider implementing the ehanced CGI security measures described <a href="cgisecurity.html">here</a> to ensure that your web authentication credentials are not compromised.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>6) Compile and Install the Nagios Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Extract the Nagios plugins source code tarball.
+
+</p>
+
+
+
+<pre>
+
+cd ~/downloads
+
+tar xzf nagios-plugins-1.4.11.tar.gz
+
+cd nagios-plugins-1.4.11
+
+</pre>
+
+
+
+<p>
+
+Compile and install the plugins.
+
+</p>
+
+
+
+<pre>
+
+./configure --with-nagios-user=nagios --with-nagios-group=nagios
+
+make
+
+make install
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>7) Start Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Add Nagios to the list of system services and have it automatically start when the system boots.
+
+</p>
+
+
+
+<pre>
+
+chkconfig --add nagios
+
+chkconfig nagios on
+
+</pre>
+
+
+
+<p>
+
+Verify the sample Nagios configuration files.
+
+</p>
+
+
+
+<pre>
+
+/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+If there are no errors, start Nagios.
+
+</p>
+
+
+
+<pre>
+
+service nagios start
+
+</pre>
+
+
+
+<p>
+
+<strong><u>8) Modify SELinux Settings</u></strong>
+
+</p>
+
+
+
+<p>
+
+Fedora ships with SELinux (Security Enhanced Linux) installed and in Enforcing mode by default. This can result in "Internal Server Error" messages when you attempt to access the Nagios CGIs.
+
+</p>
+
+
+
+<p>
+
+See if SELinux is in Enforcing mode.
+
+</p>
+
+
+
+<pre>
+
+getenforce
+
+</pre>
+
+
+
+<p>
+
+Put SELinux into Permissive mode.
+
+</p>
+
+
+
+<pre>
+
+setenforce 0
+
+</pre>
+
+
+
+<p>
+
+To make this change permanent, you'll have to modify the settings in <i>/etc/selinux/config</i> and reboot.
+
+</p>
+
+
+
+<p>
+
+Instead of disabling SELinux or setting it to permissive mode, you can use the following command to run the CGIs under SELinux enforcing/targeted mode:
+
+</p>
+
+
+
+<pre>
+
+chcon -R -t httpd_sys_content_t /usr/local/nagios/sbin/
+
+chcon -R -t httpd_sys_content_t /usr/local/nagios/share/
+
+</pre>
+
+
+
+<p>
+
+For information on running the Nagios CGIs under Enforcing mode with a targeted policy, visit the <a href="http://support.nagios.com" target="_blank">Nagios Support Portal</a> or <a href="http://wiki.nagios.org" target="_blank">Nagios Community Wiki</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>9) Login to the Web Interface</u></strong>
+
+</p>
+
+
+
+<p>
+
+You should now be able to access the Nagios web interface at the URL below. You'll be prompted for the username (<i>nagiosadmin</i>) and password you specified earlier.
+
+</p>
+
+
+
+<pre>
+
+http://localhost/nagios/
+
+</pre>
+
+
+
+<p>
+
+Click on the "Service Detail" navbar link to see details of what's being monitored on your local machine. It will take a few minutes for Nagios to check all the services associated with your machine, as the checks are spread out over time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>10) Other Modifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+Make sure your machine's firewall rules are configured to allow access to the web server if you want to access the Nagios interface remotely.
+
+</p>
+
+
+
+<p>
+
+Configuring email notifications is out of the scope of this documentation. While Nagios is currently configured to send you email notifications, your system may not yet have a mail program properly installed or configured. Refer to your system documentation, search the web, or look to the <a href="http://support.nagios.com" target="_blank">Nagios Support Portal</a> or <a href="http://wiki.nagios.org" target="_blank">Nagios Community Wiki</a> for specific instructions on configuring your system to send email messages to external addresses. More information on notifications can be found <a href="notifications.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>11) You're Done</u></strong>
+
+</p>
+
+
+
+<p>
+
+Congratulations! You sucessfully installed Nagios. Your journey into monitoring is just beginning. You'll no doubt want to monitor more than just your local machine, so check out the following docs...
+
+</p>
+
+
+
+<ul>
+
+<li><a href="monitoring-windows.html">Monitoring Windows machines</a></li>
+
+<li><a href="monitoring-linux.html">Monitoring Linux/Unix machines</a></li>
+
+<li><a href="monitoring-netware.html">Monitoring Netware servers</a></li>
+
+<li><a href="monitoring-routers.html">Monitoring routers/switches</a></li>
+
+<li><a href="monitoring-publicservices.html">Monitoring publicly available services (HTTP, FTP, SSH, etc.)</a></li>
+
+</ul>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>openSUSE Quickstart</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">openSUSE Quickstart</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guides</a>, <a href="security.html">Security Considerations</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This guide is intended to provide you with simple instructions on how to install Nagios from source (code) on openSUSE and have it monitoring your local machine inside of 20 minutes. No advanced installation options are discussed here - just the basics that will work for 95% of users who want to get started.
+
+</p>
+
+
+
+<p>
+
+These instructions were written based on an <b>openSUSE 10.2</b> installation.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Required Packages</u></strong>
+
+</p>
+
+
+
+<p>
+
+Make sure you've installed the following packages on your openSUSE installation before continuing. You can use <i>yast</i> to install packages under openSUSE.
+
+</p>
+
+
+
+<ul>
+
+<li>apache2</li>
+
+<li>C/C++ development libraries</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>1) Create Account Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+Become the root user.
+
+</p>
+
+
+
+<pre>
+
+su -l
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagios</i> user account and give it a password.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/useradd -m nagios
+
+passwd nagios
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagios</i> group. Add the nagios user to the group.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/groupadd nagios
+
+/usr/sbin/usermod -G nagios nagios
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagcmd</i> group for allowing external commands to be submitted through the web interface. Add both the nagios user and the apache user to the group.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/groupadd nagcmd
+
+/usr/sbin/usermod -a -G nagcmd nagios
+
+/usr/sbin/usermod -a -G nagcmd wwwrun
+
+</pre>
+
+
+
+<p>
+
+<strong><u>2) Download Nagios and the Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Create a directory for storing the downloads.
+
+</p>
+
+
+
+<pre>
+
+mkdir ~/downloads
+
+cd ~/downloads
+
+</pre>
+
+
+
+<p>
+
+Download the source code tarballs of both Nagios and the Nagios plugins (visit <a href="http://www.nagios.org/download/">http://www.nagios.org/download/</a> for links to the latest versions). These directions were tested with Nagios 3.1.1 and Nagios Plugins 1.4.11.
+
+</p>
+
+
+
+<pre>
+
+wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz
+
+wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.11.tar.gz
+
+</pre>
+
+
+
+<p>
+
+<strong><u>3) Compile and Install Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Extract the Nagios source code tarball.
+
+</p>
+
+
+
+<pre>
+
+cd ~/downloads
+
+tar xzf nagios-3.2.1.tar.gz
+
+cd nagios-3.2.1
+
+</pre>
+
+
+
+<p>
+
+Run the Nagios configure script, passing the name of the group you created earlier like so:
+
+</p>
+
+
+
+<pre>
+
+./configure --with-command-group=nagcmd
+
+</pre>
+
+
+
+<p>
+
+Compile the Nagios source code.
+
+</p>
+
+
+
+<pre>
+
+make all
+
+</pre>
+
+
+
+<p>
+
+Install binaries, init script, sample config files and set permissions on the external command directory.
+
+</p>
+
+
+
+<pre>
+
+make install
+
+make install-init
+
+make install-config
+
+make install-commandmode
+
+</pre>
+
+
+
+<p>
+
+Don't start Nagios yet - there's still more that needs to be done...
+
+</p>
+
+
+
+<p>
+
+<strong><u>4) Customize Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Sample <a href="config.html">configuration files</a> have now been installed in the <i>/usr/local/nagios/etc</i> directory. These sample files should work fine for getting started with Nagios. You'll need to make just one change before you proceed...
+
+</p>
+
+
+
+<p>
+
+Edit the <i>/usr/local/nagios/etc/objects/contacts.cfg</i> config file with your favorite editor and change the email address associated with the <i>nagiosadmin</i> contact definition to the address you'd like to use for receiving alerts.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/contacts.cfg
+
+</pre>
+
+
+
+<p>
+
+<strong><u>5) Configure the Web Interface</u></strong>
+
+</p>
+
+
+
+<p>
+
+Install the Nagios web config file in the Apache conf.d directory.
+
+</p>
+
+
+
+<pre>
+
+make install-webconf
+
+</pre>
+
+
+
+<p>
+
+Create a <i>nagiosadmin</i> account for logging into the Nagios web interface. Remember the password you assign to this account - you'll need it later.
+
+</p>
+
+
+
+<pre>
+
+htpasswd2 -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
+
+</pre>
+
+
+
+<p>
+
+Restart Apache to make the new settings take effect.
+
+</p>
+
+
+
+<pre>
+
+service apache2 restart
+
+</pre>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Consider implementing the ehanced CGI security measures described <a href="cgisecurity.html">here</a> to ensure that your web authentication credentials are not compromised.
+
+</p>
+
+
+
+<p>
+
+<strong><u>6) Compile and Install the Nagios Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Extract the Nagios plugins source code tarball.
+
+</p>
+
+
+
+<pre>
+
+cd ~/downloads
+
+tar xzf nagios-plugins-1.4.11.tar.gz
+
+cd nagios-plugins-1.4.11
+
+</pre>
+
+
+
+<p>
+
+Compile and install the plugins.
+
+</p>
+
+
+
+<pre>
+
+./configure --with-nagios-user=nagios --with-nagios-group=nagios
+
+make
+
+make install
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>7) Start Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Add Nagios to the list of system services and have it automatically start when the system boots.
+
+</p>
+
+
+
+<pre>
+
+chkconfig --add nagios
+
+chkconfig nagios on
+
+</pre>
+
+
+
+<p>
+
+Verify the sample Nagios configuration files.
+
+</p>
+
+
+
+<pre>
+
+/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+If there are no errors, start Nagios.
+
+</p>
+
+
+
+<pre>
+
+service nagios start
+
+</pre>
+
+
+
+<p>
+
+<strong><u>8) Login to the Web Interface</u></strong>
+
+</p>
+
+
+
+<p>
+
+You should now be able to access the Nagios web interface at the URL below. You'll be prompted for the username (<i>nagiosadmin</i>) and password you specified earlier.
+
+</p>
+
+
+
+<pre>
+
+http://localhost/nagios/
+
+</pre>
+
+
+
+<p>
+
+Click on the "Service Detail" navbar link to see details of what's being monitored on your local machine. It will take a few minutes for Nagios to check all the services associated with your machine, as the checks are spread out over time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>9) Other Modifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+Make sure your machine's firewall rules are configured to allow access to the web server if you want to access the Nagios interface remotely.
+
+</p>
+
+
+
+<p>
+
+You can do this by:
+
+</p>
+
+
+
+<ul>
+
+<li>Opening the control center</li>
+
+<li>Select 'Open Administrator Settings' to open the YaST administrator control center</li>
+
+<li>Select 'Firewall' from the 'Security and Users' category</li>
+
+<li>Click the 'Allowed Services' option in the Firewall Configuration window
+
+<li>Add 'HTTP Server' to the allowed services list for the 'External Zone'</li>
+
+<li>Click 'Next' and 'Accept' to activate the new firewall settings</li>
+
+</ul>
+
+
+
+<p>
+
+Configuring email notifications is outside the scope of this documentation. Refer to your system documentation, search the web, or look to the <a href="http://support.nagios.com" target="_blank">Nagios Support Portal</a> or <a href="http://wiki.nagios.org" target="_blank">Nagios Community Wiki</a> for specific instructions on configuring your openSUSE system to send email messages to external addresses.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Ubuntu Quickstart</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Ubuntu Quickstart</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guides</a>, <a href="security.html">Security Considerations</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This guide is intended to provide you with simple instructions on how to install Nagios from source (code) on Ubuntu and have it monitoring your local machine inside of 20 minutes. No advanced installation options are discussed here - just the basics that will work for 95% of users who want to get started.
+
+</p>
+
+
+
+<p>
+
+These instructions were written based on an <b>Ubuntu 6.10</b> (desktop) installation. They should work for an <b>Ubuntu 7.10</b> install as well.
+
+</p>
+
+
+
+<p>
+
+<strong><u>What You'll End Up With</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you follow these instructions, here's what you'll end up with:
+
+</p>
+
+
+
+<ul>
+
+<li>Nagios and the plugins will be installed underneath /usr/local/nagios</li>
+
+<li>Nagios will be configured to monitor a few aspects of your local system (CPU load, disk usage, etc.)</li>
+
+<li>The Nagios web interface will be accessible at http://localhost/nagios/</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Required Packages</u></strong>
+
+</p>
+
+
+
+<p>
+
+Make sure you've installed the following packages on your Ubuntu installation before continuing.
+
+</p>
+
+
+
+<ul>
+
+<li>Apache 2</li>
+
+<li>PHP</li>
+
+<li>GCC compiler and development libraries</li>
+
+<li>GD development libraries</li>
+
+</ul>
+
+
+
+<p>
+
+You can use <i>apt-get</i> to install these packages by running the following commands:
+
+</p>
+
+
+
+<pre>
+
+sudo apt-get install apache2
+
+sudo apt-get install libapache2-mod-php5
+
+sudo apt-get install build-essential
+
+</pre>
+
+
+
+<p>
+
+With Ubuntu 6.10, install the gd2 library with this command:
+
+</p>
+
+
+
+<pre>
+
+sudo apt-get install libgd2-dev
+
+</pre>
+
+<p>
+
+With Ubuntu 7.10, the gd2 library name has changed, so you'll need to use the following:
+
+</p>
+
+
+
+<pre>
+
+sudo apt-get install libgd2-xpm-dev
+
+</pre>
+
+
+
+<p>
+
+<strong><u>1) Create Account Information</u></strong>
+
+</p>
+
+
+
+<p>
+
+Become the root user.
+
+</p>
+
+
+
+<pre>
+
+sudo -s
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagios</i> user account and give it a password.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/useradd -m -s /bin/bash nagios
+
+passwd nagios
+
+</pre>
+
+
+<p>
+
+On older Ubuntu server editions (6.01 and earlier), you will need to also add a <i>nagios</i> group (it's not created by default). You should be able to skip this step on desktop, or newer server editions of Ubuntu.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/groupadd nagios
+
+/usr/sbin/usermod -G nagios nagios
+
+</pre>
+
+
+
+<p>
+
+Create a new <i>nagcmd</i> group for allowing external commands to be submitted through the web interface. Add both the nagios user and the apache user to the group.
+
+</p>
+
+
+
+<pre>
+
+/usr/sbin/groupadd nagcmd
+
+/usr/sbin/usermod -a -G nagcmd nagios
+
+/usr/sbin/usermod -a -G nagcmd www-data
+
+</pre>
+
+
+
+<p>
+
+<strong><u>2) Download Nagios and the Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Create a directory for storing the downloads.
+
+</p>
+
+
+
+<pre>
+
+mkdir ~/downloads
+
+cd ~/downloads
+
+</pre>
+
+
+
+<p>
+
+Download the source code tarballs of both Nagios and the Nagios plugins (visit <a href="http://www.nagios.org/download/">http://www.nagios.org/download/</a> for links to the latest versions). These directions were tested with Nagios 3.1.1 and Nagios Plugins 1.4.11.
+
+</p>
+
+
+
+<pre>
+
+wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz
+
+wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.11.tar.gz
+
+</pre>
+
+
+
+<p>
+
+<strong><u>3) Compile and Install Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Extract the Nagios source code tarball.
+
+</p>
+
+
+
+<pre>
+
+cd ~/downloads
+
+tar xzf nagios-3.2.1.tar.gz
+
+cd nagios-3.2.1
+
+</pre>
+
+
+
+<p>
+
+Run the Nagios configure script, passing the name of the group you created earlier like so:
+
+</p>
+
+
+
+<pre>
+
+./configure --with-command-group=nagcmd
+
+</pre>
+
+
+
+<p>
+
+Compile the Nagios source code.
+
+</p>
+
+
+
+<pre>
+
+make all
+
+</pre>
+
+
+
+<p>
+
+Install binaries, init script, sample config files and set permissions on the external command directory.
+
+</p>
+
+
+
+<pre>
+
+make install
+
+make install-init
+
+make install-config
+
+make install-commandmode
+
+</pre>
+
+
+
+<p>
+
+Don't start Nagios yet - there's still more that needs to be done...
+
+</p>
+
+
+
+<p>
+
+<strong><u>4) Customize Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Sample <a href="config.html">configuration files</a> have now been installed in the <i>/usr/local/nagios/etc</i> directory. These sample files should work fine for getting started with Nagios. You'll need to make just one change before you proceed...
+
+</p>
+
+
+
+<p>
+
+Edit the <i>/usr/local/nagios/etc/objects/contacts.cfg</i> config file with your favorite editor and change the email address associated with the <i>nagiosadmin</i> contact definition to the address you'd like to use for receiving alerts.
+
+</p>
+
+
+
+<pre>
+
+vi /usr/local/nagios/etc/objects/contacts.cfg
+
+</pre>
+
+
+
+<p>
+
+<strong><u>5) Configure the Web Interface</u></strong>
+
+</p>
+
+
+
+<p>
+
+Install the Nagios web config file in the Apache conf.d directory.
+
+</p>
+
+
+
+<pre>
+
+make install-webconf
+
+</pre>
+
+
+
+<p>
+
+Create a <i>nagiosadmin</i> account for logging into the Nagios web interface. Remember the password you assign to this account - you'll need it later.
+
+</p>
+
+
+
+<pre>
+
+htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
+
+</pre>
+
+
+
+<p>
+
+Restart Apache to make the new settings take effect.
+
+</p>
+
+
+
+<pre>
+
+/etc/init.d/apache2 reload
+
+</pre>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: Consider implementing the ehanced CGI security measures described <a href="cgisecurity.html">here</a> to ensure that your web authentication credentials are not compromised.
+
+</p>
+
+
+
+<p>
+
+<strong><u>6) Compile and Install the Nagios Plugins</u></strong>
+
+</p>
+
+
+
+<p>
+
+Extract the Nagios plugins source code tarball.
+
+</p>
+
+
+
+<pre>
+
+cd ~/downloads
+
+tar xzf nagios-plugins-1.4.11.tar.gz
+
+cd nagios-plugins-1.4.11
+
+</pre>
+
+
+
+<p>
+
+Compile and install the plugins.
+
+</p>
+
+
+
+<pre>
+
+./configure --with-nagios-user=nagios --with-nagios-group=nagios
+
+make
+
+make install
+
+</pre>
+
+
+
+
+
+<p>
+
+<strong><u>7) Start Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Configure Nagios to automatically start when the system boots.
+
+</p>
+
+
+
+<pre>
+
+ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios
+
+</pre>
+
+
+
+<p>
+
+Verify the sample Nagios configuration files.
+
+</p>
+
+
+
+<pre>
+
+/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+If there are no errors, start Nagios.
+
+</p>
+
+
+
+<pre>
+
+/etc/init.d/nagios start
+
+</pre>
+
+
+
+<p>
+
+<strong><u>8) Login to the Web Interface</u></strong>
+
+</p>
+
+
+
+<p>
+
+You should now be able to access the Nagios web interface at the URL below. You'll be prompted for the username (<i>nagiosadmin</i>) and password you specified earlier.
+
+</p>
+
+
+
+<pre>
+
+http://localhost/nagios/
+
+</pre>
+
+
+
+<p>
+
+Click on the "Service Detail" navbar link to see details of what's being monitored on your local machine. It will take a few minutes for Nagios to check all the services associated with your machine, as the checks are spread out over time.
+
+</p>
+
+
+
+<p>
+
+<strong><u>9) Other Modifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you want to receive email notifications for Nagios alerts, you need to install the mailx (Postfix) package.
+
+</p>
+
+
+
+<pre>
+
+sudo apt-get install mailx
+
+sudo apt-get install postfix
+
+</pre>
+
+
+
+<p>
+
+You'll have to edit the Nagios email notification commands found in <i>/usr/local/nagios/etc/objects/commands.cfg</i> and change any '/bin/mail' references to '/usr/bin/mail'. Once you do that you'll need to restart Nagios to make the configuration changes live.
+
+</p>
+
+
+
+<pre>
+
+sudo /etc/init.d/nagios restart
+
+</pre>
+
+
+
+<p>
+
+Configuring email notifications is outside the scope of this documentation. Refer to your system documentation, search the web, or look to the <a href="http://support.nagios.com" target="_blank">Nagios Support Portal</a> or <a href="http://wiki.nagios.org" target="_blank">Nagios Community Wiki</a> for specific instructions on configuring your Ubuntu system to send email messages to external addresses.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Nagios Quickstart Installation Guides</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Nagios Quickstart Installation Guides</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="upgrading.html">Upgrading Nagios</a>, <a href="config.html">Configuration Overview</a>, <a href="security.html">Security Considerations</a>
+
+</p>
+
+<p>
+
+<strong><u>About Nagios</u></strong>
+
+</p>
+
+<p>
+Visit <a href="http://www.nagios.org/about/" target="_blank">www.nagios.org/about/</a> for more information on Nagios - including features, capabilities, and technical specifications.
+</p>
+
+
+
+<p>
+
+<strong><u>Installation Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+These quickstart guides are intended to provide you with simple instructions on how to install Nagios from source (code) and have it monitoring your local machine inside of 20 minutes. No advanced installation options are discussed here - just the basics that will work for 95% of users who want to get started.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Installation Guides</u></strong>
+
+</p>
+
+
+
+<p>
+
+Quickstart installation guides are currently available for the following Linux distributions:
+
+</p>
+
+
+
+<ul>
+
+<li><a href="quickstart-fedora.html">Fedora Quickstart</a></li>
+
+<li><a href="quickstart-opensuse.html">openSUSE Quickstart</a></li>
+
+<li><a href="quickstart-ubuntu.html">Ubuntu Quickstart</a></li>
+
+</ul>
+
+
+
+<p>
+
+You can also find additional quickstart guides on the <a href="http://wiki.nagios.org/">Nagios Community Wiki</a>. Can't find a quickstart for your particular OS? Write one and post it to the wiki for others!
+
+</p>
+
+
+
+<p>
+
+If you are installing Nagios on an operating system or Linux distribution that isn't listed above, read the <a href="quickstart-fedora.html">Fedora quickstart</a> for an overview of what you'll need to do. Command names, paths, etc. vary widely across different OSes/distributions, so you'll likely need to tweak the installation docs a bit to work for your particular case.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Post-Installation Modifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+Once you get Nagios installed and running properly, you'll no doubt want to start monitoring more than just your local machine. Check out the following docs for how to go about monitoring other things...
+
+</p>
+
+
+
+<ul>
+
+<li><a href="monitoring-windows.html">Monitoring Windows machines</a></li>
+
+<li><a href="monitoring-linux.html">Monitoring Linux/Unix machines</a></li>
+
+<li><a href="monitoring-netware.html">Monitoring Netware servers</a></li>
+
+<li><a href="monitoring-routers.html">Monitoring routers/switches</a></li>
+
+<li><a href="monitoring-printers.html">Monitoring network printers</a></li>
+
+<li><a href="monitoring-publicservices.html">Monitoring publicly available services (HTTP, FTP, SSH, etc.)</a></li>
+
+</ul>
+
+<p><strong><u>Enhance Nagios With Community Addons</u></strong></p>
+
+
+
+<p>
+
+<a href="http://exchange.nagios.org/" target="_blank"><img src="images/nagiosexchange.png" border="0" alt="Nagios Exchange" title="Nagios Exchange" style="float: left; padding: 10px 10px 0 10px;"></a>
+
+</p>
+
+<p>
+Hundreds of community-developed addons provide additional GUIs and reporting, monitoring, and notification functionalities for Nagios. Visit the Nagios Exchange website at <a href="http://exchange.nagios.org" target="_blank">exchange.nagios.org</a> to see some really cool things you can use to trick out your Nagios installation.
+</p>
+
+<br clear="all">
+
+
+<p><strong><u>Nagios Support Portal</u></strong></p>
+
+
+
+<p>
+
+<a href="http://support.nagios.com/" target="_blank"><img src="images/nagiossupport.png" border="0" alt="Nagios Support" title="Nagios Support" style="float: left; padding: 10px 10px 0 10px;"></a>
+
+</p>
+
+<p>
+Visit the Nagios Support portal at <a href="http://support.nagios.com" target="_blank">support.nagios.com</a> for additional documentation, FAQs, and professional Nagios support plans.
+</p>
+
+<br clear="all">
+
+<hr>
+
+<p class="Disclaimer">
+
+Nagios and the Nagios logo are trademarks, servicemarks, registered servicemarks or registered trademarks of <a href="http://www.nagios.com/" target="_blank">Nagios Enterprises</a>.
+
+</p>
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Redundant and Failover Network Monitoring</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<h1 class="PageTitle">Redundant and Failover Network Monitoring</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This section describes a few scenarios for implementing redundant monitoring hosts an various types of network layouts. With redundant hosts, you can maintain the ability to monitor your network when the primary host that runs Nagios fails or when portions of your network become unreachable.
+
+</p>
+
+
+
+<p>
+
+<font color="red"><strong>Note:</strong></font> If you are just learning how to use Nagios, I would suggest not trying to implement redudancy until you have becoming familiar with the <a href="#prerequisites">prerequisites</a> I've laid out. Redundancy is a relatively complicated issue to understand, and even more difficult to implement properly.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Index</u></strong>
+
+</p>
+
+
+
+<p>
+
+<a href="#prerequisites">Prerequisites</a><br>
+
+<a href="#samples">Sample scripts</a><br>
+
+<a href="#scenario_1">Scenario 1 - Redundant monitoring</a><br>
+
+<a href="#scenario_2">Scenario 2 - Failover monitoring</a><br>
+
+</p>
+
+
+
+<p>
+
+<a name="prerequisites"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Prerequisites</strong></td>
+
+</tr>
+
+</table>
+
+</p>
+
+
+
+<p>
+
+Before you can even think about implementing redundancy with Nagios, you need to be familiar with the following...
+
+</p>
+
+<ul>
+
+<li>Implementing <a href="eventhandlers.html">event handlers</a> for hosts and services
+
+<li>Issuing <a href="extcommands.html">external commands</a> to Nagios via shell scripts
+
+<li>Executing plugins on remote hosts using either the <a href="addons.html#nrpe">NRPE addon</a> or some other method
+
+<li>Checking the status of the Nagios process with the <i>check_nagios</i> plugin
+
+</ul>
+
+
+
+<p>
+
+<a name="samples"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Sample Scripts</strong></td>
+
+</tr>
+
+</table>
+
+</p>
+
+
+
+<p>
+
+All of the sample scripts that I use in this documentation can be found in the <i>eventhandlers/</i> subdirectory of the Nagios distribution. You'll probably need to modify them to work on your system...
+
+</p>
+
+
+
+<p>
+
+<a name="scenario_1"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Scenario 1 - Redundant Monitoring</strong></td>
+
+</tr>
+
+</table>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+This is an easy (and naive) method of implementing redundant monitoring hosts on your network and it will only protect against a limited number of failures. More complex setups are necessary in order to provide smarter redundancy, better redundancy across different network segments, etc.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Goals</u></strong>
+
+</p>
+
+
+
+<p>
+
+The goal of this type of redundancy implementation is simple. Both the "master" and "slave" hosts monitor the same hosts and service on the network. Under normal circumstances only the "master" host will be sending out notifications to contacts about problems. We want the "slave" host running Nagios to take over the job of notifying contacts about problems if:
+
+</p>
+
+<ol>
+
+<li>The "master" host that runs Nagios is down or..
+
+<li>The Nagios process on the "master" host stops running for some reason
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Network Layout Diagram</u></strong>
+
+</p>
+
+
+
+<p>
+
+The diagram below shows a very simple network setup. For this scenario I will be assuming that hosts A and E are both running Nagios and are monitoring all the hosts shown. Host A will be considered the "master" host and host E will be considered the "slave" host.
+
+</p>
+
+
+
+<p>
+
+<table border="1" class="Default">
+
+<tr>
+
+<td><img src="images/redundancy.png" border=0></td>
+
+</tr>
+
+</table>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Initial Program Settings</u></strong>
+
+</p>
+
+
+
+<p>
+
+The slave host (host E) has its initial <a href="configmain.html#enable_notifications">enable_notifications</a> directive disabled, thereby preventing it from sending out any host or service notifications. You also want to make sure that the slave host has its <a href="configmain.html#check_external_commands">check_external_commands</a> directive enabled. That was easy enough...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Initial Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Next we need to consider the differences between the <a href="configobject.html">object configuration file(s)</a> on the master and slave hosts...
+
+</p>
+
+
+
+<p>
+
+I will assume that you have the master host (host A) setup to monitor services on all hosts shown in the diagram above. The slave host (host E) should be setup to monitor the same services and hosts, with the following additions in the configuration file...
+
+</p>
+
+
+
+<ul>
+
+<li>The host definition for host A (in the host E configuration file) should have a host <a href="eventhandlers.html">event handler</a> defined. Lets say the name of the host event handler is <font color="red">handle-master-host-event</font>.
+
+<li>The configuration file on host E should have a service defined to check the status of the Nagios process on host A. Lets assume that you define this service check to run the <i>check_nagios</i> plugin on host A. This can be done by using one of the methods described in <b>this FAQ</b> (update this!).
+
+<li>The service definition for the Nagios process check on host A should have an <a href="eventhandlers.html">event handler</a> defined. Lets say the name of the service event handler is <font color="red">handle-master-proc-event</font>.
+
+</ul>
+
+
+
+<p>
+
+It is important to note that host A (the master host) has no knowledge of host E (the slave host). In this scenario it simply doesn't need to. Of course you may be monitoring services on host E from host A, but that has nothing to do with the implementation of redundancy...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Event Handler Command Definitions</u></strong>
+
+</p>
+
+
+
+<p>
+
+We need to stop for a minute and describe what the command definitions for the event handlers on the slave host look like. Here is an example...
+
+</p>
+
+
+
+<p>
+
+<strong>
+
+<font color="red">
+
+<pre>
+
+define command{
+
+ command_name handle-master-host-event
+
+ command_line /usr/local/nagios/libexec/eventhandlers/handle-master-host-event $HOSTSTATE$ $HOSTSTATETYPE$
+
+ }
+
+
+
+define command{
+
+ command_name handle-master-proc-event
+
+ command_line /usr/local/nagios/libexec/eventhandlers/handle-master-proc-event $SERVICESTATE$ $SERVICESTATETYPE$
+
+ }
+
+</pre>
+
+</font>
+
+</strong>
+
+</p>
+
+
+
+<p>
+
+This assumes that you have placed the event handler scripts in the <i>/usr/local/nagios/libexec/eventhandlers</i> directory. You may place them anywhere you wish, but you'll need to modify the examples I've given here.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Event Handler Scripts</u></strong>
+
+</p>
+
+
+
+<p>
+
+Okay, now lets take a look at what the event handler scripts look like...
+
+</p>
+
+
+
+<p>
+
+Host Event Handler (<font color="red">handle-master-host-event</font>):
+
+</p>
+
+<pre>
+
+#!/bin/sh
+
+
+
+# Only take action on hard host states...
+
+case "$2" in
+
+HARD)
+
+ case "$1" in
+
+ DOWN)
+
+ # The master host has gone down!
+
+ # We should now become the master host and take
+
+ # over the responsibilities of monitoring the
+
+ # network, so enable notifications...
+
+ /usr/local/nagios/libexec/eventhandlers/enable_notifications
+
+ ;;
+
+ UP)
+
+ # The master host has recovered!
+
+ # We should go back to being the slave host and
+
+ # let the master host do the monitoring, so
+
+ # disable notifications...
+
+ /usr/local/nagios/libexec/eventhandlers/disable_notifications
+
+ ;;
+
+ esac
+
+ ;;
+
+esac
+
+exit 0
+
+</pre>
+
+
+
+<p>
+
+Service Event Handler (<font color="red">handle-master-proc-event</font>):
+
+</p>
+
+
+
+<pre>
+
+#!/bin/sh
+
+
+
+# Only take action on hard service states...
+
+case "$2" in
+
+HARD)
+
+ case "$1" in
+
+ CRITICAL)
+
+ # The master Nagios process is not running!
+
+ # We should now become the master host and
+
+ # take over the responsibility of monitoring
+
+ # the network, so enable notifications...
+
+ /usr/local/nagios/libexec/eventhandlers/enable_notifications
+
+ ;;
+
+ WARNING)
+
+ UNKNOWN)
+
+ # The master Nagios process may or may not
+
+ # be running.. We won't do anything here, but
+
+ # to be on the safe side you may decide you
+
+ # want the slave host to become the master in
+
+ # these situations...
+
+ ;;
+
+ OK)
+
+ # The master Nagios process running again!
+
+ # We should go back to being the slave host,
+
+ # so disable notifications...
+
+ /usr/local/nagios/libexec/eventhandlers/disable_notifications
+
+ ;;
+
+ esac
+
+ ;;
+
+esac
+
+exit 0
+
+</pre>
+
+
+
+<p>
+
+<strong><u>What This Does For Us</u></strong>
+
+</p>
+
+
+
+<p>
+
+The slave host (host E) initially has notifications disabled, so it won't send out any host or service notifications while the Nagios process on the master host (host A) is still running.
+
+</p>
+
+
+
+<p>
+
+The Nagios process on the slave host (host E) becomes the master host when...
+
+</p>
+
+<ul>
+
+<li>The master host (host A) goes down and the <i><font color="red">handle-master-host-event</font></i> host event handler is executed.
+
+<li>The Nagios process on the master host (host A) stops running and the <i><font color="red">handle-master-proc-event</font></i> service event handler is executed.
+
+</ul>
+
+
+
+<p>
+
+When the Nagios process on the slave host (host E) has notifications enabled, it will be able to send out notifications about any service or host problems or recoveries. At this point host E has effectively taken over the responsibility of notifying contacts of host and service problems!
+
+</p>
+
+
+
+<p>
+
+The Nagios process on host E returns to being the slave host when...
+
+</p>
+
+<ul>
+
+<li>Host A recovers and the <i><font color="red">handle-master-host-event</font></i> host event handler is executed.
+
+<li>The Nagios process on host A recovers and the <i><font color="red">handle-master-proc-event</font></i> service event handler is executed.
+
+</ul>
+
+
+
+<p>
+
+When the Nagios process on host E has notifications disabled, it will not send out notifications about any service or host problems or recoveries. At this point host E has handed over the responsibilities of notifying contacts of problems to the Nagios process on host A. Everything is now as it was when we first started!
+
+</p>
+
+
+
+<p>
+
+<strong><u>Time Lags</u></strong>
+
+</p>
+
+
+
+<p>
+
+Redundancy in Nagios is by no means perfect. One of the more obvious problems is the lag time between the master host failing and the slave host taking over. This is affected by the following...
+
+</p>
+
+
+
+<ul>
+
+<li>The time between a failure of the master host and the first time the slave host detects a problem
+
+<li>The time needed to verify that the master host really does have a problem (using service or host check retries on the slave host)
+
+<li>The time between the execution of the event handler and the next time that Nagios checks for external commands
+
+</ul>
+
+
+
+<p>
+
+You can minimize this lag by...
+
+</p>
+
+<ul>
+
+<li>Ensuring that the Nagios process on host E (re)checks one or more services at a high frequency. This is done by using the <i>check_interval</i> and <i>retry_interval</i> arguments in each service definition.
+
+<li>Ensuring that the number of host rechecks for host A (on host E) allow for fast detection of host problems. This is done by using the <i>max_check_attempts</i> argument in the host definition.
+
+<li>Increase the frequency of <a href="extcommands.html">external command</a> checks on host E. This is done by modifying the <a href="configmain.html#command_check_interval">command_check_interval</a> option in the main configuration file.
+
+</ul>
+
+
+
+<p>
+
+When Nagios recovers on the host A, there is also some lag time before host E returns to being a slave host. This is affected by the following...
+
+</p>
+
+
+
+<ul>
+
+<li>The time between a recovery of host A and the time the Nagios process on host E detects the recovery
+
+<li>The time between the execution of the event handler on host B and the next time the Nagios process on host E checks for external commands
+
+</ul>
+
+
+
+<p>
+
+The exact lag times between the transfer of monitoring responsibilities will vary depending on how many services you have defined, the interval at which services are checked, and a lot of pure chance. At any rate, its definitely better than nothing.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Special Cases</u></strong>
+
+</p>
+
+
+
+<p>
+
+Here is one thing you should be aware of... If host A goes down, host E will have notifications enabled and take over the responsibilities of notifying contacts of problems. When host A recovers, host E will have notifications disabled. If - when host A recovers - the Nagios process on host A does not start up properly, there will be a period of time when neither host is notifying contacts of problems! Fortunately, the service check logic in Nagios accounts for this. The next time the Nagios process on host E checks the status of the Nagios process on host A, it will find that it is not running. Host E will then have notifications enabled again and take over all responsibilities of notifying contacts of problems.
+
+</p>
+
+
+
+<p>
+
+The exact amount of time that neither host is monitoring the network is hard to determine. Obviously, this period can be minimized by increasing the frequency of service checks (on host E) of the Nagios process on host A. The rest is up to pure chance, but the total "blackout" time shouldn't be too bad.
+
+</p>
+
+
+
+<p>
+
+<a name="scenario_2"></a>
+
+<table border="0" width="100%" class="Default">
+
+<tr>
+
+<td bgcolor="#cbcbcb"><strong>Scenario 2 - Failover Monitoring</strong></td>
+
+</tr>
+
+</table>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Failover monitoring is similiar to, but slightly different than redundant monitoring (as discussed above in <a href="#scenario_1">scenario 1</a>).
+
+</p>
+
+
+
+<p>
+
+<strong><u>Goals</u></strong>
+
+</p>
+
+
+
+<p>
+
+The basic goal of failover monitoring is to have the Nagios process on the slave host sit idle while the Nagios process on the master host is running. If the process on the master host stops running (or if the host goes down), the Nagios process on the slave host starts monitoring everything.
+
+</p>
+
+
+
+<p>
+
+While the method described in <a href="#scenario_1">scenario 1</a> will allow you to continue receive notifications if the master monitoring hosts goes down, it does have some pitfalls. The biggest problem is that the slave host is monitoring the same hosts and servers as the master <i>at the same time as the master</i>! This can cause problems with excessive traffic and load on the machines being monitored if you have a lot of services defined. Here's how you can get around that problem...
+
+</p>
+
+
+
+<p>
+
+<strong><u>Initial Program Settings</u></strong>
+
+</p>
+
+
+
+<p>
+
+Disable active service checks and notifications on the slave host using the <a href="configmain.html#execute_service_checks">execute_service_checks</a> and <a href="configmain.html#enable_notifications">enable_notifications</a> directives. This will prevent the slave host from monitoring hosts and services and sending out notifications while the Nagios process on the master host is still up and running. Make sure you also have the <a href="configmain.html#check_external_commands">check_external_commands</a> directive enabled on the slave host.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Master Process Check</u></strong>
+
+</p>
+
+
+
+<p>
+
+Set up a cron job on the slave host that periodically (say every minute) runs a script that checks the staus of the Nagios process on the master host (using the <i>check_nrpe</i> plugin on the slave host and the <a href="addons.html#nrpe">nrpe daemon</a> and <i>check_nagios</i> plugin on the master host). The script should check the return code of the <i>check_nrpe plugin</i> . If it returns a non-OK state, the script should send the appropriate commands to the <a href="configmain.html#command_file">external command file</a> to enable both notifications and active service checks. If the plugin returns an OK state, the script should send commands to the external command file to disable both notifications and active checks.
+
+</p>
+
+
+
+<p>
+
+By doing this you end up with only one process monitoring hosts and services at a time, which is much more efficient that monitoring everything twice.
+
+</p>
+
+
+
+<p>
+
+Also of note, you <i>don't</i> need to define host and service handlers as mentioned in <a href="#scenario_1">scenario 1</a> because things are handled differently.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Additional Issues</u></strong>
+
+</p>
+
+
+
+<p>
+
+At this point, you have implemented a very basic failover monitoring setup. However, there is one more thing you should consider doing to make things work smoother.
+
+</p>
+
+
+
+<p>
+
+The big problem with the way things have been setup thus far is the fact that the slave host doesn't have the current status of any services or hosts at the time it takes over the job of monitoring. One way to solve this problem is to enable the <a href="configmain.html#ocsp_command">ocsp command</a> on the master host and have it send all service check results to the slave host using the <a href="addons.html#nsca">nsca addon</a>. The slave host will then have up-to-date status information for all services at the time it takes over the job of monitoring things. Since active service checks are not enabled on the slave host, it will not actively run any service checks. However, it will execute host checks if necessary. This means that both the master and slave hosts will be executing host checks as needed, which is not really a big deal since the majority of monitoring deals with service checks.
+
+</p>
+
+
+
+<p>
+
+That's pretty much it as far as setup goes.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+User-agent: *
+Disallow: /
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Security Considerations</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Security Considerations</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="cgisecurity.html">CGI Security</a>
+
+</p>
+
+
+
+<p>
+
+<a name="intro"></a>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/security.png" border="0" style="float: right; clear: both;" alt="Security" title="Security">
+
+
+
+<p>
+
+This is intended to be a brief overview of some things you should keep in mind when installing Nagios, so as set it up in a secure manner.
+
+</p>
+
+
+
+<p>
+
+Your monitoring box should be viewed as a backdoor into your other systems. In many cases, the Nagios server might be allowed access through firewalls in order to monitor remote servers. In most all cases, it is allowed to query those remote servers for various information. Monitoring servers are always given a certain level of trust in order to query remote systems. This presents a potential attacker with an attractive backdoor to your systems. An attacker might have an easier time getting into your other systems if they compromise the monitoring server first. This is particularly true if you are making use of shared SSH keys in order to monitor remote systems.
+
+</p>
+
+
+
+<p>
+
+If an intruder has the ability to submit check results or external commands to the Nagios daemon, they have the potential to submit bogus monitoring data, drive you nuts you with bogus notifications, or cause event handler scripts to be triggered. If you have event handler scripts that restart services, cycle power, etc. this could be particularly problematic.
+
+</p>
+
+
+
+<p>
+
+Another area of concern is the ability for intruders to sniff monitoring data (status information) as it comes across the wire. If communication channels are not encrypted, attackers can gain valuable information by watching your monitoring information. Take as an example the following situation: An attacker captures monitoring data on the wire over a period of time and analyzes the typical CPU and disk load usage of your systems, along with the number of users that are typically logged into them. The attacker is then able to determine the best time to compromise a system and use its resources (CPU, etc.) without being noticed.
+
+</p>
+
+
+
+<p>
+
+Here are some tips to help ensure that you keep your systems secure when implementing a Nagios-based monitoring solution...
+
+</p>
+
+
+
+
+
+<p>
+
+<a name="bestpractices"></a>
+
+<strong><u>Best Practices</u></strong>
+
+</p>
+
+
+
+<ol>
+
+<li><strong>Use a Dedicated Monitoring Box</strong>. I would recommend that you install Nagios on a server that is dedicated to monitoring (and possibly other admin tasks). Protect your monitoring server as if it were one of the most important servers on your network. Keep running services to a minimum and lock down access to it via TCP wrappers, firewalls, etc. Since the Nagios server is allowed to talk to your servers and may be able to poke through your firewalls, allowing users access to your monitoring server can be a security risk. Remember, its always easier to gain root access through a system security hole if you have a local account on a box.<br><br><img src="images/security3.png" border="0" style="float: left; clear: both;" alt="Monitoring Box" title="Monitoring Box"><br clear="all"><br></li>
+
+
+
+<li><strong>Don't Run Nagios As Root</strong>. Nagios doesn't need to run as root, so don't do it. You can tell Nagios to drop privileges after startup and run as another user/group by using the <a href="configmain.html#nagios_user">nagios_user</a> and <a href="configmain.html#nagios_group">nagios_group</a> directives in the main config file. If you need to execute event handlers or plugins which require root access, you might want to try using <a href="http://www.courtesan.com/sudo/sudo.html">sudo</a>.<br><br></li>
+
+
+
+<li><strong>Lock Down The Check Result Directory</strong>. Make sure that only the <i>nagios</i> user is able to read/write in the <a href="configmain.html#check_result_path">check result path</a>. If users other than <i>nagios</i> (or <i>root</i>) are able to write to this directory, they could send fake host/service check results to the Nagios daemon. This could result in annoyances (bogus notifications) or security problems (event handlers being kicked off).<br><br></li>
+
+
+
+<li><strong>Lock Down The External Command File</strong>. If you enable <a href="extcommands.html">external commands</a>, make sure you set proper permissions on the <i>/usr/local/nagios/var/rw</i> directory. You only want the Nagios user (usually <i>nagios</i>) and the web server user (usually <i>nobody</i>, <i>httpd</i>, <i>apache2</i>, or <i>www-data</i>) to have permissions to write to the command file. If you've installed Nagios on a machine that is dedicated to monitoring and admin tasks and is not used for public accounts, that should be fine. If you've installed it on a public or multi-user machine (not recommended), allowing the web server user to have write access to the command file can be a security problem. After all, you don't want just any user on your system controlling Nagios through the external command file. In this case, I would suggest only granting write access on the command file to the <i>nagios</i> user and using something like <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a> to run the CGIs as the <i>nagios</i> user instead of <i>nobody</i>.<br><br></li>
+
+
+
+<li><strong>Require Authentication In The CGIs</strong>. I would strongly suggest requiring authentication for accessing the CGIs. Once you do that, read the documentation on the default rights that authenticated contacts have, and only authorize specific contacts for additional rights as necessary. Instructions on setting up authentication and configuring authorization rights can be found <a href="cgiauth.html">here</a>. If you disable the CGI authentication features using the <a href="configcgi.html#use_authentication">use_authentication</a> directive in the CGI config file, the <a href="cgis.html#cmd_cgi">command CGI</a> will refuse to write any commands to the <a href="configmain.html#command_file">external command file</a>. After all, you don't want the world to be able to control Nagios do you?<br><br></li>
+
+
+
+<li><strong>Implement Enhanced CGI Security Measures</strong>. I would strongly suggest that you consider implementing enhanced security measures for the CGIs as described <a href="cgisecurity.html">here</a>. These measures can help ensure that the username/password you use to access the Nagios web interface are not intercepted by third parties.<br><br></li>
+
+
+
+<li><strong>Use Full Paths In Command Definitions</strong>. When you define commands, make sure you specify the <i>full path</i> (not a relative one) to any scripts or binaries you're executing.<br><br></li>
+
+
+
+<li><strong>Hide Sensitive Information With $USERn$ Macros</strong>. The CGIs read the <a href="configmain.html">main config file</a> and <a href="configobject.html">object config file(s)</a>, so you don't want to keep any sensitive information (usernames, passwords, etc) in there. If you need to specify a username and/or password in a command definition use a $USERn$ <a href="macros.html">macro</a> to hide it. $USERn$ macros are defined in one or more <a href="configmain.html#resource_file">resource files</a>. The CGIs will not attempt to read the contents of resource files, so you can set more restrictive permissions (600 or 660) on them. See the sample <i>resource.cfg</i> file in the base of the Nagios distribution for an example of how to define $USERn$ macros.<br><br></li>
+
+
+
+<li><strong>Strip Dangerous Characters From Macros</strong>. Use the <a href="configmain.html#illegal_macro_output_chars">illegal_macro_output_chars</a> directive to strip dangerous characters from the $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$, and $SERVICEPERFDATA$ macros before they're used in notifications, etc. Dangerous characters can be anything that might be interpreted by the shell, thereby opening a security hole. An example of this is the presence of backtick (`) characters in the $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$, and/or $SERVICEPERFDATA$ macros, which could allow an attacker to execute an arbitrary command as the nagios user (one good reason not to run Nagios as the root user).<br><br></li>
+
+
+
+<li><strong>Secure Access to Remote Agents</strong>. Make sure you lock down access to agents (NRPE, NSClient, SNMP, etc.) on remote systems using firewalls, access lists, etc. You don't want everyone to be able to query your systems for status information. This information could be used by an attacker to execute remote event handler scripts or to determine the best times to go unnoticed.<br><br><img src="images/security1.png" border="0" style="float: left; clear: both;" alt="Remote Agents" title="Remote Agents"><br clear="all"><br></li>
+
+
+
+<li><strong>Secure Communication Channels</strong>. Make sure you encrypt communication channels between different Nagios installations and between your Nagios servers and your monitoring agents whenever possible. You don't want someone to be able to sniff status information going across your network. This information could be used by an attacker to determine the best times to go unnoticed.<br><br><img src="images/security2.png" border="0" style="float: left; clear: both;" alt="Communication Channels" title="Communication Channels"><br clear="all"><br></li>
+
+
+
+</ol>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Service Checks</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Service Checks</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="activechecks.html">Active Checks</a>, <a href="hostchecks.html">Host Checks</a>, <a href="checkscheduling.html">Check Scheduling</a>, <a href="dependencychecks.html">Predictive Dependency Checks</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+The basic workings of service checks are described here...
+
+</p>
+
+
+
+<p>
+
+<strong><u>When Are Service Checks Performed?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Services are checked by the Nagios daemon:
+
+</p>
+
+
+
+<ul>
+
+<li>At regular intervals, as defined by the <i>check_interval</i> and <i>retry_interval</i> options in your <a href="objectdefinitions.html#service">service definitions</a>.</li>
+
+<li>On-demand as needed for <a href="dependencychecks.html">predictive service dependency checks</a>.</li>
+
+</ul>
+
+
+
+<p>
+
+On-demand checks are performed as part of the <a href="dependencychecks.html">predictive service dependency check</a> logic. These checks help ensure that the dependency logic is as accurate as possible. If you don't make use of <a href="objectdefinitions.html#servicedependency">service dependencies</a>, Nagios won't perform any on-demand service checks.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Cached Service Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+The performance of on-demand service checks can be significantly improved by implementing the use of cached checks, which allow Nagios to forgo executing a service check if it determines a relatively recent check result will do instead. Cached checks will only provide a performance increase if you are making use of <a href="objectdefinitions.html#servicedependency">service dependencies</a>. More information on cached checks can be found <a href="cachedchecks.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Dependencies and Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can define <a href="objectdefinitions.html#servicedependency">service execution dependencies</a> that prevent Nagios from checking the status of a service depending on the state of one or more other services. More information on dependencies can be found <a href="dependencies.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Parallelization of Service Checks</u></strong>
+
+</p>
+
+
+
+<p>
+
+Scheduled service checks are run in parallel. When Nagios needs to run a scheduled service check, it will initiate the service check and then return to doing other work (running host checks, etc). The service check runs in a child process that was fork()ed from the main Nagios daemon. When the service check has completed, the child process will inform the main Nagios process (its parent) of the check results. The main Nagios process then handles the check results and takes appropriate action (running event handlers, sending notifications, etc.).
+
+</p>
+
+
+
+<p>
+
+On-demand service checks are also run in parallel if needed. As mentioned earlier, Nagios can forgo the actual execution of an on-demand service check if it can use the cached results from a relatively recent service check.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Service States</u></strong>
+
+</p>
+
+
+
+<p>
+
+Services that are checked can be in one of four different states:
+
+</p>
+
+
+
+<ul>
+
+<li>OK</li>
+
+<li>WARNING</li>
+
+<li>UNKNOWN</li>
+
+<li>CRITICAL</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Service State Determination</u></strong>
+
+</p>
+
+
+
+<p>
+
+Service checks are performed by <a href="plugins.html">plugins</a>, which can return a state of OK, WARNING, UNKNOWN, or CRITICAL. These plugin states directly translate to service states. For example, a plugin which returns a WARNING state will cause a service to have a WARNING state.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Services State Changes</u></strong>
+
+</p>
+
+
+
+<p>
+
+When Nagios checks the status of services, it will be able to detect when a service changes between OK, WARNING, UNKNOWN, and CRITICAL states and take appropriate action. These state changes result in different <a href="statetypes.html">state types</a> (HARD or SOFT), which can trigger <a href="eventhandlers.html">event handlers</a> to be run and <a href="notifications.html">notifications</a> to be sent out. Service state changes can also trigger on-demand <a href="hostchecks.html">host checks</a>. Detecting and dealing with state changes is what Nagios is all about.
+
+</p>
+
+
+
+<p>
+
+When services change state too frequently they are considered to be "flapping". Nagios can detect when services start flapping, and can suppress notifications until flapping stops and the service's state stabilizes. More information on the flap detection logic can be found <a href="flapping.html">here</a>.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>State Stalking</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">State Stalking</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="volatileservices.html">Volatile Services</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+State "stalking" is a feature which is probably not going to used by most users. When enabled, it allows you to log changes in the output service and host checks even if the state of the host or service does not change. When stalking is enabled for a particular host or service, Nagios will watch that host or service very carefully and log any changes it sees in the output of check results. As you'll see, it can be very helpful to you in later analysis of the log files.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Does It Work?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Under normal circumstances, the result of a host or service check is only logged if the host or service has changed state since it was last checked. There are a few exceptions to this, but for the most part, that's the rule.
+
+</p>
+
+
+
+<p>
+
+If you enable stalking for one or more states of a particular host or service, Nagios will log the results of the host or service check if the output from the check differs from the output from the previous check. Take the following example of eight consecutive checks of a service:
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Service Check #:</th><th>Service State:</th><th>Service Check Output:</th><th>Logged Normally</th><th>Logged With Stalking</th></tr>
+
+<tr><td>x</td><td>OK</td><td>RAID array optimal</td><td>-</td><td>-</td></tr>
+
+<tr><td>x+1</td><td>OK</td><td>RAID array optimal</td><td>-</td><td>-</td></tr>
+
+<tr><td>x+2</td><td>WARNING</td><td>RAID array degraded (1 drive bad, 1 hot spare rebuilding)</td><td><img src="images/checkmark.png" alt="Yes"></td><td><img src="images/checkmark.png" alt="Yes"></td></tr>
+
+<tr><td>x+3</td><td>CRITICAL</td><td>RAID array degraded (2 drives bad, 1 host spare online, 1 hot spare rebuilding)</td><td><img src="images/checkmark.png" alt="Yes"></td><td><img src="images/checkmark.png" alt="Yes"></td></tr>
+
+<tr><td>x+4</td><td>CRITICAL</td><td>RAID array degraded (3 drives bad, 2 hot spares online)</td><td>-</td><td><img src="images/checkmark.png" alt="Yes"></td></tr>
+
+<tr><td>x+5</td><td>CRITICAL</td><td>RAID array failed</td><td>-</td><td><img src="images/checkmark.png" alt="Yes"></td></tr>
+
+<tr><td>x+6</td><td>CRITICAL</td><td>RAID array failed</td><td>-</td><td>-</td></tr>
+
+<tr><td>x+7</td><td>CRITICAL</td><td>RAID array failed</td><td>-</td><td>-</td></tr>
+
+</table>
+
+
+
+<p>
+
+Given this sequence of checks, you would normally only see two log entries for this catastrophe. The first one would occur at service check x+2 when the service changed from an OK state to a WARNING state. The second log entry would occur at service check x+3 when the service changed from a WARNING state to a CRITICAL state.
+
+</p>
+
+
+
+<p>
+
+For whatever reason, you may like to have the complete history of this catastrophe in your log files. Perhaps to help explain to your manager how quickly the situation got out of control, perhaps just to laugh at it over a couple of drinks at the local pub...
+
+</p>
+
+
+
+<p>
+
+Well, if you had enabled stalking of this service for CRITICAL states, you would have events at x+4 and x+5 logged in addition to the events at x+2 and x+3. Why is this? With state stalking enabled, Nagios would have examined the output from each service check to see if it differed from the output of the previous check. If the output differed and the state of the service didn't change between the two checks, the result of the newer service check would get logged.
+
+</p>
+
+
+
+<p>
+
+A similiar example of stalking might be on a service that checks your web server. If the check_http plugin first returns a WARNING state because of a 404 error and on subsequent checks returns a WARNING state because of a particular pattern not being found, you might want to know that. If you didn't enable state stalking for WARNING states of the service, only the first WARNING state event (the 404 error) would be logged and you wouldn't have any idea (looking back in the archived logs) that future WARNING states were not due to a 404, but rather some text pattern that could not be found in the returned web page.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Should I Enable Stalking?</u></strong>
+
+</p>
+
+
+
+<p>
+
+First, you must decide if you have a real need to analyze archived log data to find the exact cause of a problem. You may decide you need this feature for some hosts or services, but not for all. You may also find that you only have a need to enable stalking for some host or service states, rather than all of them. For example, you may decide to enable stalking for WARNING and CRITICAL states of a service, but not for OK and UNKNOWN states.
+
+</p>
+
+
+
+<p>
+
+The decision to to enable state stalking for a particular host or service will also depend on the plugin that you use to check that host or service. If the plugin always returns the same text output for a particular state, there is no reason to enable stalking for that state.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Do I Enable Stalking?</u></strong>
+
+</p>
+
+
+
+<p>
+
+You can enable state stalking for hosts and services by using the <i>stalking_options</i> directive in <a href="configobject.html">host and service definitions</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>How Does Stalking Differ From Volatile Services?</u></strong>
+
+</p>
+
+
+
+<p>
+
+<a href="volatileservices.html">Volatile services</a> are similar, but will cause notifications and event handlers to run. Stalking is purely for logging purposes.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Caveats</u></strong>
+
+</p>
+
+
+
+<p>
+
+You should be aware that there are some potential pitfalls with enabling stalking. These all relate to the reporting functions found in various <a href="cgis.html">CGIs</a> (histogram, alert summary, etc.). Because state stalking will cause additional alert entries to be logged, the data produced by the reports will show evidence of inflated numbers of alerts.
+
+</p>
+
+
+
+<p>
+
+As a general rule, I would suggest that you <i>not</i> enable stalking for hosts and services without thinking things through. Still, it's there if you need and want it.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Starting and Stopping Nagios</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Starting and Stopping Nagios</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="verifyconfig.html">Verifying Your Configuration</a>
+
+</p>
+
+
+
+<p>
+
+There's more than one way to start, stop, and restart Nagios. Here are some of the more common ones...
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: Always make sure you <a href="verifyconfig.html">verify your configuration</a> before you (re)start Nagios.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Starting Nagios</u></strong>
+
+</p>
+
+
+
+<ol>
+
+<li><b>Init Script:</b> The easiest way to start the Nagios daemon is by using the init script like so:
+
+<pre>
+
+/etc/rc.d/init.d/nagios start
+
+</pre>
+
+</li>
+
+<li><b>Manually:</b> You can start the Nagios daemon manually with the <b>-d</b> command line option like so:
+
+<pre>
+
+/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+</li>
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Restarting Nagios</u></strong>
+
+</p>
+
+
+
+<p>
+
+Restarting/reloading is nececessary when you modify your configuration files and want those changes to take effect.
+
+</p>
+
+
+
+<ol>
+
+<li><b>Init Script:</b> The easiest way to restart the Nagios daemon is by using the init script like so:
+
+<pre>
+
+/etc/rc.d/init.d/nagios reload
+
+</pre>
+
+</li>
+
+<li><b>Web Interface:</b> You can restart the Nagios through the web interface by clicking the "Process Info" navigation link and selecting "Restart the Nagios process":<br><br>
+
+<img src="images/stoprestart.png" border="0" alt="Restart the Nagios process"><br><br>
+
+</li>
+
+<li><b>Manually:</b> You can restart the Nagios process by sending it a SIGHUP signal like so:
+
+<pre>
+
+kill -HUP <nagios_pid>
+
+</pre>
+
+</ol>
+
+
+
+<p>
+
+<strong><u>Stopping Nagios</u></strong>
+
+</p>
+
+
+
+<ol>
+
+<li><b>Init Script:</b> The easiest way to stop the Nagios daemon is by using the init script like so:
+
+<pre>
+
+/etc/rc.d/init.d/nagios stop
+
+</pre>
+
+</li>
+
+<li><b>Web Interface:</b> You can stop the Nagios through the web interface by clicking the "Process Info" navigation link and selecting "Shutdown the Nagios process":<br><br>
+
+<img src="images/stoprestart.png" border="0" alt="Shutdown the Nagios process"><br><br>
+
+</li>
+
+<li><b>Manually:</b> You can stop the Nagios process by sending it a SIGTERM signal like so:
+
+<pre>
+
+kill <nagios_pid>
+
+</pre>
+
+</li>
+
+</ol>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>State Types</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">State Types</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="hostchecks.html">Host Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="eventhandlers.html">Event Handlers</a>, <a href="notifications.html">Notifications</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+<p>
+
+The current state of monitored services and hosts is determined by two components:
+
+</p>
+
+
+
+<ul>
+
+<li>The status of the service or host (i.e. OK, WARNING, UP, DOWN, etc.)</li>
+
+<li>Tye <i>type</i> of state the service or host is in</li>
+
+</ul>
+
+
+
+
+
+<p>
+
+There are two state types in Nagios - SOFT states and HARD states. These state types are a crucial part of the monitoring logic, as they are used to determine when <a href="eventhandlers.html">event handlers</a> are executed and when <a href="notifications.html">notifications</a> are initially sent out.
+
+</p>
+
+
+
+<p>
+
+This document describes the difference between SOFT and HARD states, how they occur, and what happens when they occur.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Service and Host Check Retries</u></strong>
+
+</p>
+
+
+
+<p>
+
+In order to prevent false alarms from transient problems, Nagios allows you to define how many times a service or host should be (re)checked before it is considered to have a "real" problem. This is controlled by the <i>max_check_attempts</i> option in the host and service definitions. Understanding how hosts and services are (re)checked in order to determine if a real problem exists is important in understanding how state types work.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Soft States</u></strong>
+
+</p>
+
+
+
+<p>
+
+Soft states occur in the following situations...
+
+</p>
+
+
+
+<ul>
+
+<li>When a service or host check results in a non-OK or non-UP state and the service check has not yet been (re)checked the number of times specified by the <i>max_check_attempts</i> directive in the service or host definition. This is called a soft error.
+
+<li>When a service or host recovers from a soft error. This is considered a soft recovery.
+
+</ul>
+
+
+
+<p>
+
+The following things occur when hosts or services experience SOFT state changes:
+
+</p>
+
+
+
+<ul>
+
+<li>The SOFT state is logged.
+
+<li>Event handlers are executed to handle the SOFT state.
+
+</ul>
+
+
+
+<p>
+
+SOFT states are only logged if you enabled the <a href="configmain.html#log_service_retries">log_service_retries</a> or <a href="configmain.html#log_host_retries">log_host_retries</a> options in your main configuration file.
+
+</p>
+
+
+
+<p>
+
+The only important thing that really happens during a soft state is the execution of event handlers. Using event handlers can be particularly useful if you want to try and proactively fix a problem before it turns into a HARD state.
+
+The <a href="macrolist.html#hoststatetype">$HOSTSTATETYPE$</a> or <a href="macrolist.html#servicestatetype">$SERVICESTATETYPE$</a> macros will have a value of "<i>SOFT</i>" when event handlers are executed, which allows your event handler scripts to know when they should take corrective action. More information on event handlers can be found <a href="eventhandlers.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>Hard States</u></strong>
+
+</p>
+
+
+
+<p>
+
+Hard states occur for hosts and services in the following situations:
+
+</p>
+
+
+
+<ul>
+
+<li>When a host or service check results in a non-UP or non-OK state and it has been (re)checked the number of times specified by the <i>max_check_attempts</i> option in the host or service definition. This is a hard error state.
+
+<li>When a host or service transitions from one hard error state to another error state (e.g. WARNING to CRITICAL).</li>
+
+<li>When a service check results in a non-OK state and its corresponding host is either DOWN or UNREACHABLE.
+
+<li>When a host or service recovers from a hard error state. This is considered to be a hard recovery.
+
+<li>When a <a href="passivechecks.html">passive host check</a> is received. Passive host checks are treated as HARD unless the <a href="configmain.html#passive_host_checks_are_soft">passive_host_checks_are_soft</a> option is enabled.</li>
+
+</ul>
+
+
+
+<p>
+
+The following things occur when hosts or services experience HARD state changes:
+
+</p>
+
+
+
+<ul>
+
+<li>The HARD state is logged.
+
+<li>Event handlers are executed to handle the HARD state.
+
+<li>Contacts are notifified of the host or service problem or recovery.
+
+</ul>
+
+
+
+<p>
+
+The <a href="macrolist.html#hoststatetype">$HOSTSTATETYPE$</a> or <a href="macrolist.html#servicestatetype">$SERVICESTATETYPE$</a> macros will have a value of "<i>HARD</i>" when event handlers are executed, which allows your event handler scripts to know when they should take corrective action. More information on event handlers can be found <a href="eventhandlers.html">here</a>.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Example</u></strong>
+
+</p>
+
+
+
+<p>
+
+Here's an example of how state types are determined, when state changes occur, and when event handlers and notifications are sent out. The table below shows consecutive checks of a service over time. The service has a <i>max_check_attempts</i> value of 3.
+
+</p>
+
+
+
+<table border="1" class="Default">
+
+<tr><th>Time</th><th>Check #</th><th>State</th><th>State Type</th><th>State Change</th><th>Notes</th></tr>
+
+<tr><td>0</td><td>1</td><td>OK</td><td>HARD</td><td>No</td><td>Initial state of the service</td></tr>
+
+<tr><td>1</td><td>1</td><td>CRITICAL</td><td>SOFT</td><td>Yes</td><td>First detection of a non-OK state. Event handlers execute.</td></tr>
+
+<tr><td>2</td><td>2</td><td>WARNING</td><td>SOFT</td><td>Yes</td><td>Service continues to be in a non-OK state. Event handlers execute.</td></tr>
+
+<tr><td>3</td><td>3</td><td>CRITICAL</td><td>HARD</td><td>Yes</td><td>Max check attempts has been reached, so service goes into a HARD state. Event handlers execute and a problem notification is sent out. Check # is reset to 1 immediately after this happens.</td></tr>
+
+<tr><td>4</td><td>1</td><td>WARNING</td><td>HARD</td><td>Yes</td><td>Service changes to a HARD WARNING state. Event handlers execute and a problem notification is sent out.</td></tr>
+
+<tr><td>5</td><td>1</td><td>WARNING</td><td>HARD</td><td>No</td><td>Service stabilizes in a HARD problem state. Depending on what the notification interval for the service is, another notification might be sent out.</td></tr>
+
+<tr><td>6</td><td>1</td><td>OK</td><td>HARD</td><td>Yes</td><td>Service experiences a HARD recovery. Event handlers execute and a recovery notification is sent out.</td></tr>
+
+<tr><td>7</td><td>1</td><td>OK</td><td>HARD</td><td>No</td><td>Service is still OK.</td></tr>
+
+<tr><td>8</td><td>1</td><td>UNKNOWN</td><td>SOFT</td><td>Yes</td><td>Service is detected as changing to a SOFT non-OK state. Event handlers execute.</td></tr>
+
+<tr><td>9</td><td>2</td><td>OK</td><td>SOFT</td><td>Yes</td><td>Service experiences a SOFT recovery. Event handlers execute, but notification are not sent, as this wasn't a "real" problem. State type is set HARD and check # is reset to 1 immediately after this happens.</td></tr>
+
+<tr><td>10</td><td>1</td><td>OK</td><td>HARD</td><td>No</td><td>Service stabilizes in an OK state.</td></tr>
+
+</table>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<HTML>
+
+<HEAD>
+
+<TITLE>Time Periods</TITLE>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</HEAD>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Time Periods</h1>
+
+or...<br>
+
+<b>"Is This a Good Time?"</b>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="oncallrotation.html">On-Call Rotations</a>, <a href="hostchecks.html">Host Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="notifications.html">Notifications</a>, <a href="escalations.html">Notification Escalations</a>, <a href="dependencies.html">Dependencies</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/objects-timeperiods.png" border="0" style="float: right;" alt="Timeperiods" title="Timeperiods">
+
+
+
+<p>
+
+<a href="objectdefinitions.html#timeperiod">Timeperiod</a> definitions allow you to control when various aspects of the monitoring and alerting logic can operate. For instance, you can restrict:
+
+</p>
+
+
+
+<ul>
+
+<li>When regularly scheduled host and service checks can be performed</li>
+
+<li>When notifications can be sent out</li>
+
+<li>When notification escalations can be used</li>
+
+<li>When dependencies are valid</li>
+
+</ul>
+
+
+
+<p>
+
+<strong><u>Precedence in Time Periods</u></strong>
+
+</p>
+
+
+
+<p>
+
+Timeperod <a href="objectdefinitions.html#timeperiod">definitions</a> may contain multiple types of directives, including weekdays, days of the month, and calendar dates. Different types of directives have different precendence levels and may override other directives in your timeperiod definitions. The order of precedence for different types of directives (in descending order) is as follows:
+
+</p>
+
+
+
+<ul>
+
+<li>Calendar date (2008-01-01)</li>
+
+<li>Specific month date (January 1st)</li>
+
+<li>Generic month date (Day 15)</li>
+
+<li>Offset weekday of specific month (2nd Tuesday in December)</li>
+
+<li>Offset weekday (3rd Monday)</li>
+
+<li>Normal weekday (Tuesday)</li>
+
+</ul>
+
+
+
+<p>
+
+Examples of different timeperiod directives can be found <a href="objectdefinitions.html#timeperiod">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Time Periods Work With Host and Service Checks</u></strong>
+
+</p>
+
+
+
+
+
+<p>
+
+Host and service definitions have an optional <i>check_period</i> directive that allows you to specify a timeperiod that should be used to restrict when regularly scheduled, active checks of the host or service can be made.
+
+</p>
+
+
+
+<p>
+
+If you do not use the <i>check_period</i> directive to specify a timeperiod, Nagios will be able to schedule active checks of the host or service anytime it needs to. This is essentially a 24x7 monitoring scenario.
+
+</p>
+
+
+
+<p>
+
+Specifying a timeperiod in the <i>check_period</i> directive allows you to restrict the time that Nagios perform regularly scheduled, active checks of the host or service. When Nagios attempts to reschedule a host or service check, it will make sure that the next check falls within a valid time range within the defined timeperiod. If it doesn't, Nagios will adjust the next check time to coincide with the next "valid" time in the specified timeperiod. This means that the host or service may not get checked again for another hour, day, or week, etc.
+
+</p>
+
+
+
+<p>
+
+<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: On-demand checks and passive checks are not restricted by the timeperiod you specify in the <i>check_period</i> directive. Only regularly scheduled active checks are restricted.
+
+</p>
+
+
+
+<p>
+
+Unless you have a good reason not to do so, I would recommend that you monitor all your hosts and services using timeperiods that cover a 24x7 time range. If you don't do this, you can run into some problems during "blackout" times (times that are not valid in the timeperiod definition):
+
+</p>
+
+
+
+<ol>
+
+<li>The status of the host or service will appear unchanged during the blackout time.
+
+<li>Contacts will mostly likely not get re-notified of problems with a host or service during blackout times.
+
+<li>If a host or service recovers during a blackout time, contacts will not be immediately notified of the recovery.
+
+</ol>
+
+<br>
+
+
+
+<p>
+
+<strong><u>How Time Periods Work With Contact Notifications</u></strong>
+
+</p>
+
+
+
+<p>
+
+By specifying a timeperiod in the <i>notification_period</i> directive of a host or service definition, you can control when Nagios is allowed to send notifications out regarding problems or recoveries for that host or service. When a host notification is about to get sent out, Nagios will make sure that the current time is within a valid range in the <i>notification_period</i> timeperiod. If it is a valid time, then Nagios will attempt to notify each contact of the problem or recovery.
+
+</p>
+
+
+
+<p>
+
+You can also use timeperiods to control when notifications can be sent out to individual contacts. By using the <i>service_notification_period</i> and <i>host_notification_period</i> directives in <a href="objectdefinitions.html#contact">contact definitions</a>, you're able to essentially define an "on call" period for each contact. Contacts will only receive host and service notifications during the times you specify in the notification period directives.
+
+</p>
+
+
+
+<p>
+
+Examples of how to create timeperiod definitions for use for on-call rotations can be found <a href="oncallrotation.html">here</a>.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Time Periods Work With Notification Escalations</u></strong>
+
+</p>
+
+
+
+<p>
+
+Service and host <a href="escalations.html">notification escalations</a> have an optional <i>escalation_period</i> directive that allows you to specify a timeperiod when the escalation is valid and can be used. If you do not use the <i>escalation_period</i> directive in an escalation definition, the escalation is considered valid at all times. If you specify a timeperiod in the <i>escalation_period</i> directive, Nagios will only use the escalation definition during times that are valid in the timeperiod definition.
+
+</p>
+
+
+
+<p>
+
+<strong><u>How Time Periods Work With Dependencies</u></strong>
+
+</p>
+
+
+
+<p>
+
+Service and host <a href="dependencies.html">dependencies</a> have an optional <i>dependency_period</i> directive that allows you to specify a timeperiod when the dependendies are valid and can be used. If you do not use the <i>dependency_period</i> directive in a dependency definition, the dependency can be used at any time. If you specify a timeperiod in the <i>dependency_period</i> directive, Nagios will only use the dependency definition during times that are valid in the timeperiod definition.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<HTML>
+
+<HEAD>
+
+<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
+
+<TITLE>Table Of Contents</TITLE>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; text-align: center; }
+
+
+
+ .Title { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; text-align: center;}
+
+
+
+-->
+
+</STYLE>
+
+
+
+</HEAD>
+
+<body bgcolor="#FFFFFF" text="black" CLASS='Default'>
+
+
+
+
+
+<div align="center">
+
+<a href="http://www.nagios.org"><img src="images/logofullsize.png" border=0 alt="Nagios"></a>
+
+</div>
+
+<P class="Title">
+
+Nagios Core 3.x Documentation
+
+</p>
+
+<h1 class="PageTitle">
+
+Table of Contents
+
+</h1>
+
+
+
+<hr>
+
+
+
+
+
+<dl>
+
+<dt><strong>About</strong><br><br></dt>
+
+<dd><a href="about.html#whatis"><strong>What is Nagios?</strong></a>
+
+<dd><a href="about.html#requirements"><strong>System requirements</strong></a>
+
+<dd><a href="about.html#licensing"><strong>Licensing</strong></a>
+
+<dd><a href="about.html#downloading"><strong>Downloading the latest version</strong></a><br><br>
+
+
+
+<dt><strong>Release Notes</strong><br><br></dt>
+
+<dd><a href="whatsnew.html"><font color="red"><strong>What's new in this version</strong></font></a>
+
+<dd><a href="knownissues.html"><strong>Known issues</strong></a>
+<br><br>
+
+
+
+<dt><strong>Support</strong><br><br></dt>
+
+<dd><a href="http://support.nagios.com" target="_blank"><strong>Nagios Support Portal</strong></a>
+
+<dd><a href="http://wiki.nagios.org" target="_blank"><strong>Nagios Community Wiki</strong></a><br><br>
+
+
+
+<dt><strong>Getting Started</strong><br><br></dt>
+
+<dd><a href="beginners.html"><strong>Advice for beginners</strong></a><br><br>
+
+
+
+<dd><a href="quickstart.html"><font color="red"><strong>Quickstart installation guide</strong></font></a><br><br>
+
+
+
+<dd><a href="upgrading.html"><strong>Upgrading from previous versions</strong></a><br><br>
+
+
+
+<dd><a href="monitoring-windows.html"><strong>How to monitor a Windows machine</strong></a>
+
+<dd><a href="monitoring-linux.html"><strong>How to monitor a Linux/Unix machine</strong></a>
+
+<dd><a href="monitoring-netware.html"><strong>How to monitor a Netware server</strong></a>
+
+<dd><a href="monitoring-printers.html"><strong>How to monitor a network printer</strong></a>
+
+<dd><a href="monitoring-routers.html"><strong>How to monitor a router/switch</strong></a>
+
+<dd><a href="monitoring-publicservices.html"><strong>How to monitor a publicly available service (HTTP, FTP, SSH, etc.)</strong></a><br><br>
+
+
+
+<dt><strong>Configuring Nagios</strong><br><br></dt>
+
+<dd><a href="config.html"><strong>Configuration overview</strong></a>
+
+<dd><a href="configmain.html"><strong>Main configuration file options</strong></a>
+
+<dd><a href="configobject.html"><strong>Object configuration overview</strong></a>
+
+<dd><a href="objectdefinitions.html"><strong>Object definitions</strong></a>
+
+<dd><a href="configcgi.html"><strong>CGI configuration file options</strong></a>
+
+<dd><a href="cgiauth.html"><strong>Configuring authorization for the CGIs</strong></a><br><br>
+
+
+
+<dt><strong>Running Nagios</strong><br><br></dt>
+
+<dd><a href="verifyconfig.html"><strong>Verifying your configuration</strong></a>
+
+<dd><a href="startstop.html"><strong>Starting and stopping Nagios</strong></a><br><br>
+
+
+
+<dt><strong>The Basics</strong><br><br></dt>
+
+<dd><a href="plugins.html"><strong>Plugins</strong></a>
+
+<dd><a href="macros.html"><strong>Macros and how they work</strong></a>
+
+<dd><a href="macrolist.html"><strong>Standard macros available in Nagios</strong></a>
+
+<dd><a href="hostchecks.html"><strong>Host checks</strong></a>
+
+<dd><a href="servicechecks.html"><strong>Service checks</strong></a>
+
+<dd><a href="activechecks.html"><strong>Active checks</strong></a>
+
+<dd><a href="passivechecks.html"><strong>Passive checks</strong></a>
+
+<dd><a href="statetypes.html"><strong>State types</strong></a>
+
+<dd><a href="timeperiods.html"><strong>Time periods</strong></a>
+
+<dd><a href="networkreachability.html"><strong>Determining status and reachability of network hosts</strong></a>
+
+<dd><a href="notifications.html"><strong>Notifications</strong></a>
+
+<dd><a href="cgis.html"><strong>Information on the CGIs</strong></a><br><br>
+
+
+
+<dt><strong>Advanced Topics</strong><br><br></dt>
+
+<dd><a href="extcommands.html"><strong>External commands</strong></a>
+
+<dd><a href="eventhandlers.html"><strong>Event handlers</strong></a>
+
+<dd><a href="volatileservices.html"><strong>Volatile services</strong></a>
+
+<dd><a href="freshness.html"><strong>Service and host result freshness checks</strong></a>
+
+<dd><a href="distributed.html"><strong>Distributed monitoring</strong></a>
+
+<dd><a href="redundancy.html"><strong>Redundant and failover monitoring</strong></a>
+
+<dd><a href="flapping.html"><strong>Detection and handling of state flapping</strong></a>
+
+<dd><a href="escalations.html"><strong>Notification escalations</strong></a>
+
+<dd><a href="oncallrotation.html"><strong>On-call notification rotations</strong></a>
+
+<dd><a href="clusters.html"><strong>Monitoring service and host clusters</strong></a>
+
+<dd><a href="dependencies.html"><strong>Host and service dependencies</strong></a>
+
+<dd><a href="stalking.html"><strong>State stalking</strong></a>
+
+<dd><a href="perfdata.html"><strong>Performance data</strong></a>
+
+<dd><a href="downtime.html"><strong>Scheduled host and service downtime</strong></a>
+
+<dd><a href="embeddedperl.html"><strong>Using the embedded Perl interpreter</strong></a>
+
+<dd><a href="adaptive.html"><strong>Adaptive monitoring</strong></a>
+
+<dd><a href="dependencychecks.html"><strong>Predictive dependency checks</strong></a>
+
+<dd><a href="cachedchecks.html"><strong>Cached checks</strong></a>
+
+<dd><a href="passivestatetranslation.html"><strong>Passive host state translation</strong></a>
+
+<dd><a href="checkscheduling.html"><strong>Check scheduling</strong></a>
+
+<dd><a href="cgiincludes.html"><strong>Custom CGI headers and footers</strong></a><br><br>
+
+
+
+<dd><a href="objectinheritance.html"><strong>Object inheritance</strong></a>
+
+<dd><a href="objecttricks.html"><strong>Time-saving tips for object definitions</strong></a><br><br>
+
+
+
+
+
+<dt><strong>Security and Performance Tuning</strong><br><br></dt>
+
+<dd><a href="security.html"><strong>Security considerations</strong></a>
+
+<dd><a href="cgisecurity.html"><strong>Enhanced CGI security and authentication</strong></a>
+
+<dd><a href="tuning.html"><strong>Tuning Nagios for maximum performance</strong></a>
+
+<dd><a href="faststartup.html"><strong>Fast startup options</strong></a>
+
+<dd><a href="largeinstalltweaks.html"><strong>Large installation tweaks</strong></a>
+
+<dd><a href="nagiostats.html"><strong>Using the nagiostats utility</strong></a>
+
+<dd><a href="mrtggraphs.html"><strong>Graphing Nagios performance statistics</strong></a><br><br>
+
+
+
+
+
+<dt><strong>Integration With Other Software</strong><br><br></dt>
+
+<dd><a href="integration.html"><strong>Integration Overview</strong></a>
+
+<dd><a href="int-snmptrap.html"><strong>SNMP Traps</strong></a>
+
+<dd><a href="int-tcpwrappers.html"><strong>TCP Wrappers</strong></a><br><br>
+
+
+
+
+
+<dt><strong>Nagios Addons</strong><br><br></dt>
+
+<dd><a href="addons.html#nrpe"><strong>NRPE</strong></a>
+
+<dd><a href="addons.html#nsca"><strong>NSCA</strong></a>
+
+<dd><a href="addons.html#ndoutils"><strong>NDOUtils</strong></a>
+
+<dd><a href="addons.html#others"><strong>Other addons</strong></a>
+
+<dd><a href="http://exchange.nagios.org/" target="_blank"><strong>Nagios Exchange</strong></a><br><br>
+
+
+
+
+
+<dt><strong>Development</strong><br><br></dt>
+
+<dd><a href="pluginapi.html"><strong>Plugin API</strong></a>
+
+<dd><a href="epnplugins.html"><strong>Developing Plugins For Use With Embedded Perl</strong></a><br><br>
+
+
+
+</dl>
+
+
+
+<br>
+
+
+
+
+
+<hr>
+
+
+
+</BODY>
+
+</HTML>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Tuning Nagios For Maximum Performance</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Tuning Nagios For Maximum Performance</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="largeinstalltweaks.html">Large Installation Tweaks</a>, <a href="faststartup.html">Fast Startup Options</a>, <a href="mrtggraphs.html">Graphing Performance Info</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<img src="images/tuning.png" border="0" style="float: right; clear: both;" alt="Tuning" title="Tuning">
+
+
+
+<p>
+
+So you've finally got Nagios up and running and you want to know how you can tweak it a bit. Tuning Nagios to increase performance can be necessary when you start monitoring a large number (> 1,000) of hosts and services. Here are a few things to look at for optimizing Nagios...
+
+</p>
+
+
+
+<br clear="all">
+
+
+
+<p>
+
+<strong><u>Optimization Tips:</u></strong>
+
+</p>
+
+
+
+<ol>
+
+
+
+<li><b>Graph performance statistics with MRTG</b>. In order to keep track of how well your Nagios installation handles load over time and how your configuration changes affect it, you should be graphing several important statistics with MRTG. This is really, really, really useful when it comes to tuning the performance of a Nagios installation. Really. Information on how to do this can be found <a href="mrtggraphs.html">here</a>.<br><br></li>
+
+
+
+<li><b>Use large installation tweaks</b>. Enabling the <a href="configmain.html#use_large_installation_tweaks">use_large_installation_tweaks</a> option may provide you with better performance. Read more about what this option does <a href="largeinstalltweaks.html">here</a>.<br><br></li>
+
+
+
+<li><b>Disable environment macros</b>. Macros are normally made available to check, notification, event handler, etc. commands as environment variables. This can be a problem in a large Nagios installation, as it consumes some additional memory and (more importantly) more CPU. If your scripts don't need to access the macros as environment variables (e.g. you pass all necessary macros on the command line), you don't need this feature. You can prevent macros from being made available as environment variables by using the <a href="configmain.html#enable_environment_macros">enable_environment_macros</a> option.<br><br></li>
+
+
+
+<li><b>Check Result Reaper Frequency</b>. The <a href="configmain.html#check_result_reaper_frequency">check_result_reaper_frequency</a> variable determines how often Nagios should check for host and service check results that need to be processed. The maximum amount of time it can spend processing those results is determined by the max reaper time (see below). If your reaper frequency is too high (too infrequent), you might see high latencies for host and service checks.<br><br></li>
+
+
+
+<li><b>Max Reaper Time</b>. The <a href="configmain.html#max_check_result_reaper_time">max_check_result_reaper_time</a> variables determines the maximum amount of time the Nagios daemon can spend processing the results of host and service checks before moving on to other things - like executing new host and service checks. Too high of a value can result in large latencies for your host and service checks. Too low of a value can have the same effect. If you're experiencing high latencies, adjust this variable and see what effect it has. Again, you should be <a href="mrtggraphs.html">graphing statistics</a> in order to make this determination.<br><br></li>
+
+
+
+<li><b>Adjust buffer slots</b>. You may need to adjust the value of the <a href="configmain.html#external_command_buffer_slots">external_command_buffer_slots</a> option. Graphing buffer slot statistics with <a href="mrtggraphs.html">MRTG</a> (see above) is critical in determining what values you should use for this option.<br><br></li>
+
+
+
+<li><b>Check service latencies to determine best value for maximum concurrent checks</b>. Nagios can restrict the number of maximum concurrently executing service checks to the value you specify with the <a href="configmain.html#max_concurrent_checks">max_concurrent_checks</a> option. This is good because it gives you some control over how much load Nagios will impose on your monitoring host, but it can also slow things down. If you are seeing high latency values (> 10 or 15 seconds) for the majority of your service checks (via the <a href="cgis.html#extinfo_cgi">extinfo CGI</a>), you are probably starving Nagios of the checks it needs. That's not Nagios's fault - its yours. Under ideal conditions, all service checks would have a latency of 0, meaning they were executed at the exact time that they were scheduled to be executed. However, it is normal for some checks to have small latency values. I would recommend taking the minimum number of maximum concurrent checks reported when running Nagios with the <b>-s</b> command line argument and doubling it. Keep increasing it until the average check latency for your services is fairly low. More information on service check scheduling can be found <a href="checkscheduling.html">here</a>.<br><br></li>
+
+
+
+<li><b>Use passive checks when possible</b>. The overhead needed to process the results of <a href="passivechecks.html">passive service checks</a> is much lower than that of "normal" active checks, so make use of that piece of info if you're monitoring a slew of services. It should be noted that passive service checks are only really useful if you have some external application doing some type of monitoring or reporting, so if you're having Nagios do all the work, this won't help things.<br><br></li>
+
+
+
+<li><b>Avoid using interpreted plugins</b>. One thing that will significantly reduce the load on your monitoring host is the use of compiled (C/C++, etc.) plugins rather than interpreted script (Perl, etc) plugins. While Perl scripts and such are easy to write and work well, the fact that they are compiled/interpreted at every execution instance can significantly increase the load on your monitoring host if you have a lot of service checks. If you want to use Perl plugins, consider compiling them into true executables using perlcc(1) (a utility which is part of the standard Perl distribution) or compiling Nagios with an embedded Perl interpreter (see below).<br><br></li>
+
+
+
+<li><b>Use the embedded Perl interpreter</b>. If you're using a lot of Perl scripts for service checks, etc., you will probably find that compiling the <a href="embeddedperl.html">embedded Perl interpreter</a> into the Nagios binary will speed things up.<br><br></li>
+
+
+
+<li><b>Optimize host check commands</b>. If you're checking host states using the check_ping plugin you'll find that host checks will be performed much faster if you break up the checks. Instead of specifying a <i>max_attempts</i> value of 1 in the host definition and having the check_ping plugin send 10 ICMP packets to the host, it would be much faster to set the <i>max_attempts</i> value to 10 and only send out 1 ICMP packet each time. This is due to the fact that Nagios can often determine the status of a host after executing the plugin once, so you want to make the first check as fast as possible. This method does have its pitfalls in some situations (i.e. hosts that are slow to respond may be assumed to be down), but you'll see faster host checks if you use it. Another option would be to use a faster plugin (i.e. check_fping) as the <i>host_check_command</i> instead of check_ping.<br><br></li>
+
+
+
+<li><b>Schedule regular host checks</b>. Scheduling regular checks of hosts can actually help performance in Nagios. This is due to the way the <a href="cachedchecks.html">cached check logic</a> works (see below). Prior to Nagios 3, regularly scheduled host checks used to result in a big performance hit. This is no longer the case, as host checks are run in parallel - just like service checks. To schedule regular checks of a host, set the <i>check_interval</i> directive in the <a href="objectdefinitions.html#host">host definition</a> to something greater than 0.<br><br></li>
+
+
+
+<li><b>Enable cached host checks</b>. Beginning in Nagios 3, on-demand host checks can benefit from caching. On-demand host checks are performed whenever Nagios detects a service state change. These on-demand checks are executed because Nagios wants to know if the host associated with the service changed state. By enabling cached host checks, you can optimize performance. In some cases, Nagios may be able to used the old/cached state of the host, rather than actually executing a host check command. This can speed things up and reduce load on monitoring server. In order for cached checks to be effective, you need to schedule regular checks of your hosts (see above). More information on cached checks can be found <a href="cachedchecks.html">here</a>.<br><br></li>
+
+
+
+<li><b>Don't use agressive host checking</b>. Unless you're having problems with Nagios recognizing host recoveries, I would recommend not enabling the <a href="configmain.html#use_agressive_host_checking">use_aggressive_host_checking</a> option. With this option turned off host checks will execute much faster, resulting in speedier processing of service check results. However, host recoveries can be missed under certain circumstances when this it turned off. For example, if a host recovers and all of the services associated with that host stay in non-OK states (and don't "wobble" between different non-OK states), Nagios may miss the fact that the host has recovered. A few people may need to enable this option, but the majority don't and I would recommendnot using it unless you find it necessary...<br><br></li>
+
+
+
+<li><b>External command optimizations</b>. If you're processing a lot of external commands (i.e. passive checks in a <a href="distributed.html">distributed setup</a>, you'll probably want to set the <a href="configmain.html#command_check_interval">command_check_interval</a> variable to <b>-1</b>. This will cause Nagios to check for external commands as often as possible. You should also consider increasing the number of available <a href="configmain.html#external_command_buffer_slots">external command buffer slots</a>. Buffers slots are used to hold external commands that have been read from the <a href="configmain.html#command_file">external command file</a> (by a separate thread) before they are processed by the Nagios daemon. If your Nagios daemon is receiving a lot of passive checks or external commands, you could end up in a situation where the buffers are always full. This results in child processes (external scripts, NSCA daemon, etc.) blocking when they attempt to write to the external command file. I would highly recommend that you graph external command buffer slot usage using MRTG and the nagiostats utility as described <a href="mrtggraphs.html">here</a>, so you understand the typical external command buffer usage of your Nagios installation.<br><br></li>
+
+
+
+<li><b>Optimize hardware for maximum performance</b>. NOTE: Hardware performance shouldn't be an issue unless: 1) you're monitoring thousands of services, 2) you're doing a lot of post-processing of performance data, etc. Your system configuration and your hardware setup are going to directly affect how your operating system performs, so they'll affect how Nagios performs. The most common hardware optimization you can make is with your hard drives. CPU and memory speed are obviously factors that affect performance, but disk access is going to be your biggest bottleneck. Don't store plugins, the status log, etc on slow drives (i.e. old IDE drives or NFS mounts). If you've got them, use UltraSCSI drives or fast IDE drives. An important note for IDE/Linux users is that many Linux installations do not attempt to optimize disk access. If you don't change the disk access parameters (by using a utility like <b>hdparam</b>), you'll loose out on a <b>lot</b> of the speedy features of the new IDE drives.<br><br></li>
+
+
+
+</ol>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Upgrading Nagios</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Upgrading Nagios</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="quickstart.html">Quickstart Installation Guide</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Contents</u></strong><br><br>
+
+<a href="#nagios3x">Upgrading from previous Nagios 3.x releases</a><br>
+
+<a href="#nagios2x">Upgrading from Nagios 2.x</a><br>
+
+<a href="#rpm">Upgrading from an RPM installation</a><br>
+
+</p>
+
+
+
+<p>
+
+<a name="nagios3x"></a>
+
+<strong><u>Upgrading From Previous Nagios 3.x Releases</u></strong>
+
+</p>
+
+
+
+<p>
+
+As newer alpha, beta, and stable releases of Nagios 3.x are released, you should strongly consider upgrading as soon as possible. Newer releases usually contain critical bug fixes, so its important to stay up to date. Assuming you've already installed Nagios from source code as described in the <a href="quickstart.html">quickstart guide</a>, you can install newer versions of Nagios 3.x easily. You don't even need root access to do it, as everything that needed to be done as root was done during the initial install. Here's the upgrade process...
+
+</p>
+
+
+
+<p>
+
+Make sure you have a good backup of your existing Nagios installation and configuration files. If anything goes wrong or doesn't work, this will allow you to rollback to your old version.
+
+</p>
+
+
+
+<p>
+
+Become the nagios user. Debian/Ubuntu users should use <i>sudo -s nagios</i>.
+
+</p>
+
+
+
+<pre>
+
+su -l nagios
+
+</pre>
+
+
+<p>
+Removed the following old HTML files that were used by the web frontend. They have been replaced by PHP equivalents.
+</p>
+
+<pre>
+rm /usr/local/nagios/share/{main,side,index}.html
+</pre>
+
+
+
+<p>
+
+Download the source code tarball of the latest version of Nagios (visit <a href="http://www.nagios.org/download/">http://www.nagios.org/download/</a> for the link to the latest version).
+
+</p>
+
+
+
+<pre>
+
+wget http://osdn.dl.sourceforge.net/sourceforge/nagios/nagios-<i>3.x</i>.tar.gz
+
+</pre>
+
+
+
+<p>
+
+Extract the Nagios source code tarball.
+
+</p>
+
+
+
+<pre>
+
+tar xzf nagios-<i>3.x</i>.tar.gz
+
+cd nagios-<i>3.x</i>
+
+</pre>
+
+
+
+<p>
+
+Run the Nagios configure script, passing the name of the group used to control external command file permissions like so:
+
+</p>
+
+
+
+<pre>
+
+./configure --with-command-group=nagcmd
+
+</pre>
+
+
+
+<p>
+
+Compile the Nagios source code.
+
+</p>
+
+
+
+<pre>
+
+make all
+
+</pre>
+
+
+
+<p>
+
+Install updated binaries, documentation, and web web interface. Your existing configuration files will not be overwritten by this step.
+
+</p>
+
+
+
+<pre>
+
+make install
+
+</pre>
+
+
+
+<p>
+
+Verify your configuration files. Correct any errors shown here before proceeding with the next step.
+
+</p>
+
+
+
+<pre>
+
+/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+Restart Nagios. Debian/Ubuntu users should use <i>/etc/init.d/nagios restart</i>.
+
+</p>
+
+
+
+<pre>
+
+/sbin/service nagios restart
+
+</pre>
+
+
+
+<p>
+
+That's it - you're done!
+
+</p>
+
+
+
+
+
+<p>
+
+<a name="nagios2x"></a>
+
+<strong><u>Upgrading From Nagios 2.x</u></strong>
+
+</p>
+
+
+
+<p>
+
+It shouldn't be too difficult to upgrade from Nagios 2.x to Nagios 3. The upgrade is essentially the same as what is described above for upgrading to newer 3.x releases. You will, however, have to change your configuration files a bit so they work with Nagios 3:
+
+</p>
+
+
+
+<ul>
+
+<li>The old <i>service_reaper_frequency</i> variable in the main config file has been renamed to <a href="configmain.html#check_result_reaper_frequency">check_result_reaper_frequency</a>.</li>
+
+<li>The old <i>$NOTIFICATIONNUMBER$</i> macro has been deprecated in favor of new <a href="macrolist.html#hostnotificationnumber">$HOSTNOTIFICATIONNUMBER$</a> and <a href="macrolist.html#servicenotificationnumber">$SERVICENOTIFICATIONNUMBER$</a> macros.</li>
+
+<li>The old <i>parallelize</i> directive in service definitions is now deprecated and no longer used, as all service checks are run in parallel.</li>
+
+<li>The old <i>aggregate_status_updates</i> option has been removed. All status file updates are now aggregated at a minimum interval of 1 second.</li>
+
+<li>Extended host and extended service definitions have been deprecated. They are still read and processed by Nagios, but it is recommended that you move the directives found in these definitions to your host and service definitions, respectively.</li>
+
+<li>The old <i>downtime_file</i> file variable in the main config file is no longer supported, as scheduled downtime entries are now saved in the <a href="configmain.html#state_retention_file">retention file</a>. To preserve existing downtime entries, stop Nagios 2.x and append the contents of your old downtime file to the retention file.</li>
+
+<li>The old <i>comment_file</i> file variable in the main config file is no longer supported, as comments are now saved in the <a href="configmain.html#state_retention_file">retention file</a>. To preserve existing comments, stop Nagios 2.x and append the contents of your old comment file to the retention file.</li>
+
+</ul>
+
+
+
+<p>
+
+Also make sure to read the "<a href="whatsnew.html">What's New</a>" section of the documentation. It describes all the changes that were made to the Nagios 3 code since the latest stable release of Nagios 2.x. Quite a bit has changed, so make sure you read it over.
+
+</p>
+
+
+
+<p>
+
+<a name="rpm"></a>
+
+<strong><u>Upgrading From an RPM Installation</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you currently have an RPM- or Debian/Ubuntu APT package-based installation of Nagios and you would like to transition to installing Nagios from the official source code distribution, here's the basic process you should follow:
+
+</p>
+
+
+
+<ol>
+
+<li>Stop Nagios</li>
+
+<li>Backup your existing Nagios installation</li>
+
+<ul>
+
+<li>Configuration files</li>
+
+<ul>
+
+<li>Main config file (usually <i>nagios.cfg</i>)</li>
+
+<li>Resource config file (usually <i>resource.cfg</i>)</li>
+
+<li>CGI config file (usually <i>cgi.cfg</i>)</li>
+
+<li>All your object definition files</li>
+
+</ul>
+
+<li>Retention file (usually <i>retention.dat</i>)</li>
+
+<li>Current Nagios log file (usually <i>nagios.log</i>)</li>
+
+<li>Archived Nagios log files</li>
+
+</ul>
+
+<li>Uninstall the original RPM or APT package</li>
+
+<li>Install Nagios from source by following the <a href="quickstart.html">quickstart guide</a></li>
+
+<li>Restore your original Nagios configuration files, retention file, and log files</li>
+
+<li><a href="verifyconfig.html">Verify</a> your configuration and <a href="startstop.html">start</a> Nagios</li>
+
+</ol>
+
+
+
+<p>
+
+Note that different RPMs or APT packages may install Nagios in different ways and in different locations. Make sure you've backed up all your critical Nagios files before removing the original RPM or APT package, so you can revert back if you encounter problems.
+
+</p>
+
+
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Verifying Your Nagios Configuration</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Verifying Your Configuration</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="config.html">Configuration Overview</a>, <a href="startstop.html">Starting and Stopping Nagios</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Verifying Your Configuration</u></strong>
+
+</p>
+
+
+
+<p>
+
+Every time you modify your <a href="config.html">configuration files</a>, you should run a sanity check on them. It is important to do this before you (re)start Nagios, as Nagios will shut down if your configuration contains errors.
+
+</p>
+
+
+
+<p>
+
+In order to verify your configuration, run Nagios with the <b>-v</b> command line option like so:
+
+</p>
+
+
+
+<pre>
+
+/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
+
+</pre>
+
+
+
+<p>
+
+If you've forgotten to enter some critical data or misconfigured things, Nagios will spit out a warning or error message that should point you to the location of the problem. Error messages generally print out the line in the configuration file that seems to be the source of the problem. On errors, Nagios will often exit the pre-flight check and return to the command prompt after printing only the first error that it has encountered. This is done so that one error does not cascade into multiple errors as the remainder of the configuration data is verified. If you get any error messages you'll need to go and edit your configuration files to remedy the problem. Warning messages can <i>generally</i> be safely ignored, since they are only recommendations and not requirements.
+
+</p>
+
+
+
+<p>
+
+Once you've verified your configuration files and fixed any errors you can go ahead and <a href="startstop.html">(re)start Nagios</a>.
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>Volatile Services</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">Volatile Services</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="stalking.html">State Stalking</a>
+
+</p>
+
+
+
+<p>
+
+<strong><u>Introduction</u></strong>
+
+</p>
+
+
+
+<p>
+
+Nagios has the ability to distinguish between "normal" services and "volatile" services. The <i>is_volatile</i> option in each service definition allows you to specify whether a specific service is volatile or not. For most people, the majority of all monitored services will be non-volatile (i.e. "normal"). However, volatile services can be very useful when used properly...
+
+</p>
+
+
+
+<p>
+
+<strong><u>What Are They Useful For?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Volatile services are useful for monitoring...
+
+</p>
+
+
+
+<ul>
+
+<li>Things that automatically reset themselves to an "OK" state each time they are checked
+
+<li>Events such as security alerts which require attention every time there is a problem (and not just the first time)
+
+</ul>
+
+
+
+<p>
+
+<strong><u>What's So Special About Volatile Services?</u></strong>
+
+</p>
+
+
+
+<p>
+
+Volatile services differ from "normal" services in three important ways. <i>Each time</i> they are checked when they are in a <a href="statetypes.html">hard</a> non-OK state, and the check returns a non-OK state (i.e. no state change has occurred)...
+
+</p>
+
+
+
+<ul>
+
+<li>The non-OK service state is logged
+
+<li>Contacts are notified about the problem (if that's <a href="notifications.html">what should be done</a>). Note: Notification intervals are ignored for volatile services.
+
+<li>The <a href="eventhandlers.html">event handler</a> for the service is run (if one has been defined)
+
+</ul>
+
+
+
+<p>
+
+These events normally only occur for services when they are in a non-OK state and a hard state change has just occurred. In other words, they only happen the first time that a service goes into a non-OK state. If future checks of the service result in the same non-OK state, no hard state change occurs and none of the events mentioned take place again.
+
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip: If you are only interested in logging, consider using <a href="stalking.html">stalking</a> options instead.
+
+</p>
+
+
+
+<p>
+
+<strong><u>The Power Of Two</u></strong>
+
+</p>
+
+
+
+<p>
+
+If you combine the features of volatile services and <a href="passivechecks.html">passive service checks</a>, you can do some very useful things. Examples of this include handling SNMP traps, security alerts, etc.
+
+</p>
+
+
+
+<p>
+
+How about an example... Let's say you're running <a href="http://sourceforge.net/projects/sentrytools/">PortSentry</a> to detect port scans on your machine and automatically firewall potential intruders. If you want to let Nagios know about port scans, you could do the following...
+
+</p>
+
+
+
+<p>
+
+<b>Nagios Configuration:</b>
+
+</p>
+
+
+
+<ul>
+
+<li>Create a service definition called <i>Port Scans</i> and associate it with the host that PortSentry is running on.
+
+<li>Set the <i>max_check_attempts</i> directive in the service definition to 1. This will tell Nagios to immediate force the service into a <a href="statetypes.html">hard state</a> when a non-OK state is reported.
+
+<li>Set the <i>active_checks_enabled</i> directive in the service definition to 0. This prevents Nagios from actively checking the service.
+
+<li>Set the <i>passive_checks_enabled</i> directive in the service definition to 1. This enables passive checks for the service.
+
+<li>Set this <i>is_volatile</i> directive in the service definition to 1.</li>
+
+</ul>
+
+
+
+<p>
+
+<b>PortSentry Configuration:</b>
+
+</p>
+
+
+
+<p>
+
+Edit your PortSentry configuration file (portsentry.conf) and define a command for the <i>KILL_RUN_CMD</i> directive as follows:
+
+</p>
+
+<pre>
+
+KILL_RUN_CMD="/usr/local/Nagios/libexec/eventhandlers/submit_check_result host_name 'Port Scans' 2 'Port scan from host $TARGET$ on port $PORT$. Host has been firewalled.'"
+
+</pre>
+
+<p>
+
+Make sure to replace <i>host_name</i> with the short name of the host that the service is associated with.
+
+</p>
+
+
+
+<p>
+
+<b>Port Scan Script:</b>
+
+</p>
+
+
+
+<p>
+
+Create a shell script in the <i>/usr/local/nagios/libexec/eventhandlers</i> directory named <i>submit_check_result</i>. The contents of the shell script should be something similiar to the following...
+
+</p>
+
+
+
+<pre>
+
+ #!/bin/sh
+
+
+
+ # Write a command to the Nagios command file to cause
+
+ # it to process a service check result
+
+
+
+ echocmd="/bin/echo"
+
+
+
+ CommandFile="/usr/local/nagios/var/rw/nagios.cmd"
+
+
+
+ # get the current date/time in seconds since UNIX epoch
+
+ datetime=`date +%s`
+
+
+
+ # create the command line to add to the command file
+
+ cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4"
+
+
+
+ # append the command to the end of the command file
+
+ `$echocmd $cmdline >> $CommandFile`
+
+</pre>
+
+
+
+<p>
+
+What will happen when PortSentry detects a port scan on the machine in the future?
+
+</p>
+
+
+
+<ul>
+
+<li>PortSentry will firewall the host (this is a function of the PortSentry software)
+
+<li>PortSentry will execute the <i>submit_check_result</i> shell script and send a passive check result to Nagios
+
+<li>Nagios will read the external command file and see the passive service check submitted by PortSentry
+
+<li>Nagios will put the <i>Port Scans</i> service in a hard CRITICAL state and send notifications to contacts
+
+</ul>
+
+
+
+<p>
+
+Pretty neat, huh?
+
+</p>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+
+
+<html>
+
+<head>
+
+<title>What's New</title>
+
+
+
+<STYLE type="text/css">
+
+<!--
+
+ .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
+
+ .Default { font-family: verdana,arial,serif; font-size: 8pt; }
+
+-->
+
+</STYLE>
+
+
+
+</head>
+
+
+
+<body bgcolor="#FFFFFF" text="black" class="Default">
+
+
+
+<div align="center">
+
+<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
+
+<h1 class="PageTitle">What's New in Nagios Core 3.x</h1>
+
+</div>
+
+
+
+<hr>
+
+
+
+<p>
+
+<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
+
+<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="knownissues.html">Known Issues</a>
+</p>
+
+
+
+<p>
+
+<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Important: Make sure you read through the documentation and the FAQs at <a href="http://support.nagios.com/">support.nagios.com</a> before sending a question to the mailing lists.
+
+</p>
+
+
+
+
+
+<a name="changelog"></a>
+
+<p>
+
+<strong><u>Change Log</u></strong>
+
+</p>
+
+
+
+<p>
+
+The change log for Nagios can be found online at <a href="http://www.nagios.org/development/history">http://www.nagios.org/development/history</a> or in the <b>Changelog</b> file in the root directory of the source code distribution.
+
+</p>
+
+
+
+
+
+<p>
+
+<strong><u>Changes and New Features</u></strong>
+
+</p>
+
+
+
+<ol>
+
+
+
+<li><font color="red"><b>Documentation</b></font>:<br>
+
+ <ul>
+
+ <li><b>Doc updates</b> - I'm slowly making my way through rewriting most all portions of the documentation. This is going to take a while, as (1) there's a lot of documentation and (2) writing documentation is not my favorite thing in the world. Expect some portions of the docs to be different than others for a while. I hope the changes I'm making will make things clearer/easier for new and seasoned Nagios users alike.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Macros</b>:<br>
+
+ <ul>
+
+ <li><b>New macros</b> - New macros have been added, including: $TEMPPATH$, $LONGHOSTOUTPUT$, $LONGSERVICEOUTPUT$, $HOSTNOTIFICATIONID$, $SERVICENOTIFICATIONID$, $HOSTEVENTID$, $SERVICEEVENTID$, $SERVICEISVOLATILE$, $LASTHOSTEVENTID$, $LASTSERVICEEVENTID$, $HOSTDISPLAYNAME$, $SERVICEDISPLAYNAME$, $MAXHOSTATTEMPTS$, $MAXSERVICEATTEMPTS$, $TOTALHOSTSERVICES$, $TOTALHOSTSERVICESOK$, $TOTALHOSTSERVICESWARNING$, $TOTALHOSTSERVICESUNKNOWN$, $TOTALHOSTSERVICESCRITICAL$, $CONTACTGROUPNAME$, $CONTACTGROUPNAMES$, $CONTACTGROUPALIAS$, $CONTACTGROUPMEMBERS$, $NOTIFICATIONRECIPIENTS$, $NOTIFICATIONISESCALATED$, $NOTIFICATIONAUTHOR$, $NOTIFICATIONAUTHORNAME$, $NOTIFICATIONAUTHORALIAS$, $NOTIFICATIONCOMMENT$, $EVENTSTARTTIME$, $HOSTPROBLEMID$, $LASTHOSTPROBLEMID$, $SERVICEPROBLEMID$, $LASTSERVICEPROBLEMID$, $LASTHOSSTATE$, $LASTHOSTSTATEID$, $LASTSERVICESTATE$, $LASTSERVICESTATEID$. Two special on-demand time macros have also been added: $ISVALIDTIME:$ and $NEXTVALIDTIME:$.</li>
+
+ <li><b>Removed macros</b> - The old $NOTIFICATIONNUMBER$ macro has been deprecated in favor of new $HOSTNOTIFICATIONNUMBER$ and $SERVICENOTIFICATIONNUMBER$ macros.</li>
+
+ <li><b>Changes</b> - The $HOSTNOTES$ and $SERVICENOTES$ macros may now contain macros themselves, just like the $HOSTNOTESURL$, $HOSTACTIONURL$, $SERVICENOTESURL$ and $SERVICEACTIONURL$ macros.</li>
+
+ <li>Macros are normally available as environment variables when check, event handler, notification, and other commands are run. This can be rather CPU intensive in large Nagios installations, so you can disable this behavior with the <a href="configmain.html#enable_environment_macros">enable_environment_macros</a> option.</li>
+
+ <li>Macro information can be found <a href="macros.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Scheduled Downtime</b>:<br>
+
+ <ul>
+
+ <li><a href="downtime.html">Scheduled downtime</a> entries are no longer stored in their own file (previously specified with a <i>downtime_file</i> directive in the main configuration file). Current and retained scheduled downtime entries are now stored in the <a href="configmain.html#status_file">status file</a> and <a href="configmain.html#state_retention_file">retention file</a>, respectively.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Comments</b>:<br>
+
+ <ul>
+
+ <li>Host and service comments are no longer stored in their own file (previously specified with a <i>comment_file</i> directive in the main configuration file). Current and retained comments are now stored in the <a href="configmain.html#status_file">status file</a> and <a href="configmain.html#state_retention_file">retention file</a>, respectively.</li>
+
+ <li>Acknowledgement comments that are marked as non-persistent are now only deleted when the acknowledgement is removed. They were previously automatically deleted when Nagios restarted, which was not ideal.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>State Retention Data</b>:<br>
+
+ <ul>
+
+ <li>Status information for individual contacts is now retained across program restarts.</li>
+
+ <li>Comment and downtime IDs are now retained across program restarts and should be unique unless the retention data is deleted or ignored.</li>
+
+ <li>Added <a href="configmain.html#retained_host_attribute_mask">retained_host_attribute_mask</a> and <a href="configmain.html#retained_service_attribute_mask">retained_service_attribute_mask</a> variables to control what host/service attributes are retained globally across program restarts.</li>
+
+ <li>Added <a href="configmain.html#retained_process_host_attribute_mask">retained_process_host_attribute_mask</a> and <a href="configmain.html#retained_process_service_attribute_mask">retained_process_service_attribute_mask</a> variables to control what process attributes are retained across program restarts.</li>
+
+ <li>Added <a href="configmain.html#retained_contact_host_attribute_mask">retained_contact_host_attribute_mask</a> and <a href="configmain.html#retained_contact_service_attribute_mask">retained_contact_service_attribute_mask</a> variables to control what contact attributes are retained globally across program restarts.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Flap Detection</b>:<br>
+
+ <ul>
+
+ <li>Added <i>flap_detection_options</i> directive to host and service definitions to allow you to specify what host/service states should be used by the flap detection logic (by default all states are used).</li>
+
+ <li>Percent state change and state history are now retained and recorded even when flap detection is disabled.</li>
+
+ <li>Hosts and services are immediately checked for flapping when flap detection is enabled program-wide.</li>
+
+ <li>Hosts and services that are flapping when flap detection is disabled program-wide are now logged.</li>
+
+ <li>More information on flap detection can be found <a href="flapping.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>External Commands</b>:<br>
+
+ <ul>
+
+ <li>Added a new PROCESS_FILE external command to allow processing of external commands found in an external (regular) file. Useful for processing large amounts of passive checks with long output, or for scripting regular commands. More information can be found <a href="http://www.nagios.org/developerinfo/externalcommands/commandinfo.php?command_id=131">here</a>.</li>
+
+ <li>Custom commands may now be submitted to Nagios. Custom command names are prefixed with an underscore and are not processed internally by the Nagios daemon. They may, however, be processed by a loaded NEB module.</li>
+
+ <li>The <a href="configmain.html#check_external_commands">check_external_commands</a> option is now enabled by default, which means Nagios is configured to check for external "commands out of the box". All 2.x and earlier versions of Nagios had this option disabled by default.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Status Data</b>:<br>
+
+ <ul>
+
+ <li>Contact status information (last notification times, notifications enabled/disabled, etc.) is now saved in the <a href="configmain.html#status_file">status</a> and <a href="configmain.html#state_retention_file">retention</a> files, although it is not processed by the CGIs.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Embedded Perl</b>:<br>
+
+ <ul>
+
+ <li>Added new <a href="configmain.html#enable_embedded_perl">enable_embedded_perl</a> and <a href="configmain.html#use_embedded_perl_implicitly">use_embedded_perl_implicitly</a> variables to control use of the embedded Perl interpreter.</li>
+
+ <li>Perl scripts/plugins can now explicitly tell Nagios whether or not they should be run under the embedded Pel interpreter. This is useful if you have troublesome scripts that don't function well under the ePN.</li>
+
+ <li>More information about these new options can be found <a href="embeddedperl.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Adaptive Monitoring</b>:<br>
+
+ <ul>
+
+ <li>The check timeperiod for hosts and services can now be modified on-the-fly with the appropriate external command (CHANGE_HOST_CHECK_TIMEPERIOD or CHANGE_SVC_CHECK_TIMEPERIOD). Look <a href="http://www.nagios.org/developerinfo/externalcommands/commandlist.php?category_id=13">here</a> for available adaptive monitoring commands.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Notifications</b>:<br>
+
+ <ul>
+
+ <li>A <i>first_notification_delay</i> option has been added to host and service definitions to (what else) introduce a delay between when a host/service problem first occurs and when the first problem notification goes out. In previous versions you had to use some mighty config-fu with escalations to accomplish this. Now this feature is available to normal mortals.</li>
+
+ <li>Notifications are now sent out for hosts/services that are flapping when flap detection is disabled on a host- or service-specific basis or on a program-wide basis. The $NOTIFICATIONTYPE$ macro will be set to "FLAPPINGDISABLED" in this situation.</li>
+
+ <li>Notifications can now be sent out when scheduled downtime start, ends, and is cancelled for hosts and services. The $NOTIFICATIONTYPE$ macro will be set to "DOWNTIMESTART", "DOWNTIMEEND", or "DOWNTIMECANCELLED", respectively. In order to receive notifications on scheduled downtime events, specify "s" or "downtime" in your contact, host, and/or service notification options.</li>
+
+ <li>More information on notifications can be found <a href="notifications.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Object Definitions</b>:<br>
+
+ <ul>
+
+ <li>Service dependencies can now be created to easily define "same host" dependencies for different services on one or more hosts. (<a href="objecttricks.html#same_host_dependency">Read more</a>)</li>
+
+ <li>Extended host and service definitions (hostextinfo and serviceextinfo, respectively) have been deprecated. All values that from extended definitions have been merged with host or service definitions, as appropriate. Nagios 3 will continue to read and process older extended information definitions, but will log a warning. Future versions of Nagios (4.x and later) will not support separate extended info definitions.</li>
+
+ <li>New <i>hostgroup_members</i>, <i>servicegroup_members</i>, and <i>contactgroup_members</i> directives have been added to hostgroup, servicegroup, and contactgroups definitions, respectively. This allows you to include hosts, services, or contacts from sub-groups in your group definitions.</li>
+
+ <li>New <i>notes</i>, <i>notes_url</i>, and <i>action_url</i> have been added to hostgroup and servicegroup definition.</li>
+
+ <li>Contact definitions have the new <i>host_notifications_enabled</i>, <i>service_notifications_enabled</i>, and <i>can_submit_commands</i> directives to better control notifications and determine whether or not they can submit commands through the web interface.</li>
+
+ <li>Host and service dependencies now support an optional <i>dependency_period</i> directive. This allows you to limit the times during which dependencies are valid.</li>
+
+ <li>The <i>parallelize</i> directive in service definitions is now deprecated and no longer used. All service checks are run in parallel in Nagios 3.</li>
+
+ <li>There are no longer any inherent limitations on the length of host names or service descriptions.</li>
+
+ <li>Extended regular expressions are now used if you enable the <a href="configmain.html#use_regexp_matching">use_regexp_matching</a> config option. Regular expression matching is only used in certain object definition directives that contain <b>*</b>, <b>?</b>, <b>+</b>, or <b>\.</b>.</li>
+
+ <li>A new <i>initial_state</i> directive has been added to host and service definitions, so you can tell Nagios that a host/service should default to a specific state when Nagios starts, rather than UP or OK (which is still the default).</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Object Inheritance</b>:<br>
+
+ <ul>
+
+ <li>You can now inherit object variables/values from multiple templates by specifying more than one template name in the <i>use</i> directive of object definitions. This can allow for some very powerful (and complex) inheritance setups. (<a href="objectinheritance.html#multiple_templates">Read more</a>)</li>
+
+ <li>Services now inherit contact groups, notification interval, and notification period from their associated host if not otherwise specified. (<a href="objectinheritance.html#implied_inheritance">Read more</a>)</li>
+
+ <li>Host and service escalations now inherit contact groups, notification interval, and escalation timeperiod from their associated host or service if not otherwise specified. (<a href="objectinheritance.html#implied_inheritance">Read more</a>)</li>
+
+ <li>String variables in host, service, and contact definitions can now be prevented from being inherited by specifying a value of "null" (without quotes) for the value of the variable. (<a href="objectinheritance.html#cancel_string">Read more</a>)</li>
+
+ <li>Most string variables in local object definitions can now be appended to the string values that are inherited. This is quite handy in large configurations. (<a href="objectinheritance.html#add_string">Read more</a>)</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Performance Improvements</b>:<br>
+
+ <ul>
+
+ <li>Add ability to precache object config files and exclude circular path detection checks from verification process. This can speed up Nagios start time immensely in large environments! Read more <a href="faststartup.html">here</a>.</li>
+
+ <li>A new <a href="configmain.html#use_large_installation_tweaks">use_large_installation_tweaks</a> option has been added that should improve performance in large Nagios installations. Read more about this <a href="largeinstalltweaks.html">here</a>.</li>
+
+ <li>A number of internal improvements have been made with regards to how Nagios deals with internal data structures and object (e.g. host and service) relationships. These improvements should result in a speedup for larger installations.</li>
+
+ <li>New <a href="configmain.html#external_command_buffer_slots">external_command_buffer_slots</a> option has been added to allow you to more easily scale Nagios in large environments. For best results you should consider using <a href="mrtggraphs.html">MRTG to graph</a> Nagios' usage of buffer slots over time.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Plugin Output</b>:<br>
+
+ <ul>
+
+ <li>Multiline plugin output is now supported for host and service checks. Hooray! The plugin API has been updated to support multiple lines of output in a manner that retains backward compatability with older plugins. Additional lines of output (aside from the first line) are now stored in new $LONGHOSTOUTPUT$ and $LONGSERVICEOUTPUT$ macros.</li>
+
+ <li>The maximum length of plugin output has been increased to 4K (from around 350 bytes in previous versions). This 4K limit has been arbitrarily chosen to protect again runaway plugins that dump back too much data to Nagios.</li>
+
+ <li>More information on the plugins, multiline output, and max plugin output length can be found <a href="pluginapi.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Service Checks</b>:<br>
+
+ <ul>
+
+ <li>Nagios now checks for orphaned service checks by default.</li>
+
+ <li>Added a new <a href="configmain.html#enable_predictive_service_dependency_checks">enable_predictive_service_dependency_checks</a> option to control whether or not Nagios will initiate predictive check of service that are being depended upon (in dependency definitions). Predictive checks help ensure that the dependency logic is as accurate as possible. (<a href="dependencychecks.html">Read more</a>)</li>
+
+ <li>A new cached service check feature has been implemented that can significantly improve performance for many people Instead of executing a plugin to check the status of a service, Nagios can often use a cached service check result instead. More information on this can be found <a href="cachedchecks.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Host Checks</b>:<br>
+
+ <ul>
+
+ <li>Host checks are now run in parallel! Host checks used to be run in a serial fashion, which meant they were a major holdup in terms of performance. No longer! (<a href="hostchecks.html">Read more</a>)</li>
+
+ <li>Host check retries are now performed like service check retries. That is to say, host definitions now have a new <i>retry_interval</i> that specifies how much time to wait before trying the host check again. :-)</li>
+
+ <li>Regularly scheduled host checks now longer hinder performance. In fact, they can help to increase performance with the new cached check logic (see below).</li>
+
+ <li>Added a new <a href="configmain.html#check_for_orphaned_hosts">check_for_orphaned_hosts</a> option to enable checks of orphaned host checks. This is need now that host checks are run in parallel.</li>
+
+ <li>Added a new <a href="configmain.html#enable_predictive_host_dependency_checks">enable_predictive_host_dependency_checks</a> option to control whether or not Nagios will initiate predictive check of hosts that are being depended upon (in dependency definitions). Predictive checks help ensure that the dependency logic is as accurate as possible. (<a href="dependencychecks.html">Read more</a>)</li>
+
+ <li>A new cached host check feature has been implemented that can significantly improve performance for many people Instead of executing a plugin to check the status of a host, Nagios can often use a cached host check result instead. More information on this can be found <a href="cachedchecks.html">here</a>.</li>
+
+ <li>Passive host checks that have a DOWN or UNREACHABLE result can now be automatically translated to their proper state from the point of view of the Nagios instance that receives them. This is very useful in failover and distributed monitoring setups. More information on passive host check state translation can be found <a href="passivestatetranslation.html">here</a>.</li>
+
+ <li>Passive host checks normally put a host into a HARD state. This can now be changed by enabling the <a href="configmain.html#passive_host_checks_are_soft">passive_host_checks_are_soft</a> option.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Freshness checks</b>:<br>
+
+ <ul>
+
+ <li>A new <a href="configmain.html#freshness_threshold_latency">freshness_threshold_latency</a> option has been added to allow to you specify the number of seconds that should be added to any host or service freshness threshold that is automatically calculated by Nagios.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>IPC</b>:<br>
+
+ <ul>
+
+ <li>The IPC mechanism that is used to transfer host/service check results back to the Nagios daemon from (grand)child processes has changed! This should help to reduce load/latency issues related to processing large numbers of passive checks in distributed monitoring environments.</li>
+
+ <li>Check results are now transferred by writing check results to files in directory specified by the <a href="configmain.html#check_result_path">check_result_path</a> option. Files that are older than the <a href="configmain.html#max_check_result_file_age">max_check_result_file_age</a> option will be mercilessly deleted without further processing.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Timeperiods</b>:<br>
+
+ <ul>
+
+ <li>Timeperiods were overdue for a major overhaul and have finally been extended to allow for date exceptions, skip dates (every 3 days), etc! This should help you out when defining notification timeperiods for pager rotations.</li>
+
+ <li>More information on the new timeperiod directives can be found <a href="objectdefinitions.html#timeperiod">here</a> and <a href="timeperiods.html">here</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Event Broker</b>:<br>
+
+ <ul>
+
+ <li>Updated NEB API version</li>
+
+ <li>Modified callback for adaptive program status data</li>
+
+ <li>Added callback for adaptive contact status data</li>
+
+ <li>Added precheck callbacks for hosts and services to allow modules to cancel/override internal host/service checks.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Web Interface</b>:<br>
+
+ <ul>
+
+ <li>The main splash pages of the web interface are now PHP pages. This will require that you install/enable PHP support on your system if it isn't already.</li>
+
+ <li>Hostgroup and servicegroup summaries now show important/unimportant problem breakdowns like the TAC CGI.</li>
+
+ <li>Minor layout changes to host and service detail views in extinfo CGI.</li>
+
+ <li>New check statistics and have been added to the "Performance Info" screen.</li>
+
+ <li>Added <a href="http://www.splunk.com/" target="_blank">Splunk</a> integration options to various CGIs. Integration is controlled by the <a href="configcgi.html#enable_splunk_integration">enable_splunk_integration</a> and <a href="configcgi.html#splunk_url">splunk_url</a> options in the CGI config file.
+
+ <li>Added new <a href="configcgi.html#notes_url_target">notes_url_target</a> and <a href="configcgi.html#action_url_target">action_url_target</a> options to control what frame notes and action URLs are opened in.</li>
+
+ <li>Added new <a href="configcgi.html#lock_author_names">lock_author_names</a> option to prevent alteration of author names when users submit comments, acknowledgements, and scheduled downtime.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Debugging Info</b>:<br>
+
+ <ul>
+
+ <li>The DEBUGx compile options available in the configure script have been removed.</li>
+
+ <li>Debugging information can now be written to a separate debug file, which is automatically rotated when it reaches a user-defined size. This should make debugging problems much easier, as you don't need to recompile Nagios. Full support for writing debugging information to file is being added during the alpha development phase, so it may not be complete when you try it.</li>
+
+ <li>Variables that affect the debug log are <a href="configmain.html#debug_file">debug_file</a>, <a href="configmain.html#debug_level">debug_level</a>, <a href="configmain.html#debug_verbosity">debug_verbosity</a>, and <a href="configmain.html#max_debug_file_size">max_debug_file_size</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Update Checks</b>:<br>
+
+ <ul>
+
+ <li>Nagios will now check approximately once a day to see if a new version is available. This is useful to keep on top of security patches and new releases. Update notices will appear in the web interface.</li>
+
+ <li>Variables that affect the update check are <a href="configmain.html#check_for_updates">check_for_updates</a> and <a href="configmain.html#base_update_check">bare_update_check</a>.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+<li><b>Misc</b>:<br>
+
+ <ul>
+
+ <li><b>Temp path variable</b> - A new <a href="configmain.html#temp_path">temp_path</a> variable has been added to specify a scratch directory that Nagios can use for temporary scratch space.</li>
+
+ <li><b>Unique notification and event ID numbers</b> - A unique ID number is now assigned to each host and service notification. Another unique ID is now assigned to all host and service state changes as well. The unique IDs can be accessed using the following respective macros: $HOSTNOTIFICATIONID$, $SERVICENOTIFICATIONID$, $HOSTEVENTID$, $SERVICEEVENTID$, $LASTHOSTEVENTID$, $LASTSERVICEEVENTID$.</li>
+
+ <li><b>New macros</b> - A few new macros (other than those already mentioned elsewhere above) have been added. They include $HOSTGROUPNAMES$, $SERVICEGROUPNAMES$, $HOSTACKAUTHORNAME$, $HOSTACKAUTHORALIAS$, $SERVICEACKAUTHORNAME$, and $SERVICEACKAUTHORALIAS$.</li>
+
+ <li><b>Reaper frequency</b> - The old <i>service_reaper_frequency</i> variable has been renamed to <a href="configmain.html#check_result_reaper_frequency">check_result_reaper_frequency</a>, as it is now also used to process host check results.</li>
+
+ <li><b>Max reaper time</b> - A new <a href="configmain.html#max_check_result_reaper_time">max_check_result_reaper_time</a> variable has been added to limit the amount of time a single reaper event is allowed to run.</li>
+
+ <li><b>Fractional intervals</b> - Fractional notification and check intervals (e.g. "3.5" minutes) are now supported in host, service, host escalation, and service escalation definitions. </li>
+
+ <li><b>Escaped command arguments</b> - You can now pass bang (!) characters in your command arguments by escaping them with a backslash (\). If you need to include backslashes in your command arguments, they should also be escaped with a backslash.</li>
+
+ <li><b>Multiline system command output</b> - Nagios will now read multiple lines out output from system commands it runs (notification scripts, etc.), up to 4K. This matches the limits on plugin output mentioned earliar. Output from system commands is not directly processed by Nagios, but support for it is there nonetheless.</li>
+
+ <li><b>Better scheduling information</b> - More detailed information is given when Nagios is executed with the -s command line option. This information can be used to help <a href="faststartup.html">reduce</a> the time it takes to start/restart Nagios.</li>
+
+ <li><b>Aggregated status file updates</b> - The old <i>aggregate_status_updates</i> option has been removed. All status file updates are now aggregated at a minimum interval of 1 second.</li>
+
+ <li><b>New performance data file mode</b> - A new "p" option has been added to the <a href="configmain.html#host_perfdata_file_mode">host_perfdata_file_mode</a> and <a href="configmain.html#service_perfdata_file_mode">service_perfdata_file_mode</a> options. This new mode will open the file in non-blocking read/write mode, which is useful for pipes.</li>
+
+ <li><b>Timezone offset</b> - A new <a href="configmain.html#use_timezone">use_timezone</a> option has been added to allow you to run different instances of Nagios in timezones different from the local zone.</li>
+
+ </ul>
+
+</li>
+
+<br>
+
+
+
+</ol>
+
+
+
+<hr>
+
+
+
+</body>
+
+</html>
+
--- /dev/null
+package PB::Nagios::Config;
+
+# $Id$
+# $URL$
+
+=head1 NAME
+
+PB::Nagios::Config
+
+=head1 DESCRIPTION
+
+Perl module for parsing Nagios configuration file
+
+=cut
+
+#---------------------------------------------------------------------------
+
+use strict;
+use 5.10.0;
+use warnings;
+
+use Carp qw(:DEFAULT cluck);
+use Exporter;
+use Fcntl qw(:DEFAULT :flock);
+
+use Text::ParseWords 'parse_line';
+use File::Spec;
+use File::Spec::Functions;
+use Cwd 'abs_path';
+
+our $errstr;
+
+#------------------------------------------------------------------------------------------
+
+use constant DEFAULT_NAGIOS_CONF_DIR => catfile( '', 'etc', 'nagios' );
+
+#------------------------------------------------------------------------------------------
+
+sub new {
+
+ my $class = shift;
+ $class = ref($class) || $class;
+
+ my $self = {
+ _FILE_HANDLE => undef, # holds a reference to an opened cfg file
+ _FILE_NAME => undef, # holds the name of the read configuration file
+ _DATA => {}, # actual key/value pairs are stored in _DATA
+ _ARGS => {}, # holds all key/values passed to new()
+ };
+
+ bless ($self, $class);
+ $self->_init(@_) or return;
+ return $self;
+
+}
+
+#------------------------------------------------------------------------------------------
+
+# initialize the object
+sub _init {
+
+ my $self = shift;
+
+ if ( @_ == 1 ) {
+ return $self->read($_[0]);
+ } elsif ( @_ % 2 ) {
+ croak "new(): Illegal arguments detected";
+ } else {
+ $self->{'_ARGS'} = { @_ };
+ }
+
+ # If filename was passed, call read()
+ if ( exists ($self->{'_ARGS'}->{'filename'}) ) {
+ return $self->read( $self->{'_ARGS'}->{'filename'} );
+ }
+
+ return 1;
+
+}
+
+#------------------------------------------------------------------------------------------
+
+# takes a filename or a file handle and returns a filehandle
+sub _get_fh {
+
+ my ($self, $arg, $mode) = @_;
+
+ unless ( defined $arg ) {
+ croak "_get_fh(): filename is missing";
+ }
+
+ if ( ref($arg) && (ref($arg) eq 'GLOB') ) {
+ return ($arg, 0);
+ }
+
+ unless ( defined $mode ) {
+ $mode = O_RDONLY;
+ }
+
+ unless ( sysopen( FH, $arg, $mode ) ) {
+ $self->error("couldn't open $arg: $!");
+ return undef;
+ }
+
+ return ( \*FH, 1 );
+
+}
+
+
+#------------------------------------------------------------------------------------------
+
+sub error {
+
+ my ($self, $msg) = @_;
+
+ if ( $msg ) {
+ $errstr = $msg;
+ }
+ return $errstr;
+
+}
+
+#------------------------------------------------------------------------------------------
+
+1;
+
+#------------------------------------------------------------------------------------------
+
+__END__
+
+# vim: noai : ts=4 fenc=utf-8 filetype=perl :
projects / my-stuff / nagios.git / commitdiff
