Nagios Core Configuration - service, servicegroup, servicedependency, serviceescalation

In the case that you have followed steps mentioned at installation of the Nagios Core document at this web page the predefined configuration file with service related objects are located at:

/opt/nagios-<VERSION>/etc/objects/localhost.cfg
/opt/nagios-<VERSION>/etc/objects/printer.cfg
/opt/nagios-<VERSION>/etc/objects/switch.cfg
/opt/nagios-<VERSION>/etc/objects/templates.cfg
/opt/nagios-<VERSION>/etc/objects/windows.cfg

Preface

To configure at Nagios Core monitoring of particular application or parameter of OS related to “host” it’s required to use “service” objects.

In general it’s possible to say that “service” object will specify what to monitor on “host” object with help of “command” objects.

service

Description

Nagios Core is using configuration based on object definition. According to this we need to create objects and define relation between.

According to this “service” object is used to define relation between “host” object and “command” object that will provide the monitoring of interesting parameters. As well “service” object need to provide the possibility to send a notification. According to this relation to “contact” object need to be defined as well.

At Nagios Core we can use same “service” configuration for different services until they are related to different “host” objects.

Location

Nagios Core is providing to you already predefined set of “service” objects that is possible to copy and modify to for your node.
Located at (in the case that you have followed the installation of Nagios Core described on this website):
/opt/nagios-<VERSION>/etc/objects/localhost.cfg
/opt/nagios-<VERSION>/etc/objects/printer.cfg
/opt/nagios-<VERSION>/etc/objects/switch.cfg
/opt/nagios-<VERSION>/etc/objects/windows.cfg

Location Customization

In the case that you prefer to use your own configuration file, to store your customized configuration it is possible to define path to your configuration file.

In this case Nagios Core need to know where to search for the customized configuration file.

According to this it is required to update the main Nagios Core configuration file – “nagios.cfg”
It is possible to specify:

cfg_file=/<path>/<to>/<your>/<config>/<file>         # Direct path to you customized configuration file
cfg_dir=/<path>/<to>/<your>/<config>/<dir>           # Path to the directory where to search for the config file.

Official documentation

In most of my documents I’m preventing to copying of the official documentation. On another hand I think at this point it is really handy as I will not reinvent the wheel.

Description:

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.

Definition Format:

define service{
                host_name                         host_name                # Mandatory parameter
                hostgroup_name                    hostgroup_name
                service_description               service_description      # Mandatory parameter
                display_name                      display_name
                parents                           service_descriptions
                hourly_value                      #
                servicegroups                     servicegroup_names
                is_volatile                       [0/1]
                check_command                     command_name             # Mandatory parameter
                initial_state                     [o,w,u,c]
                max_check_attempts                #                        # Mandatory parameter
                check_interval                    #                        # Mandatory parameter
                retry_interval                    #                        # Mandatory parameter
                active_checks_enabled             [0/1]
                passive_checks_enabled            [0/1]
                check_period                      timeperiod_name          # Mandatory parameter
                obsess_over_service|obsess        [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,w,c,u]
                process_perf_data                 [0/1]
                retain_status_information         [0/1]
                retain_nonstatus_information      [0/1]
                notification_interval             #                        # Mandatory parameter
                first_notification_delay          #
                notification_period               timeperiod_name
                notification_options              [w,u,c,r,f,s]
                notifications_enabled             [0/1]
                contacts                          contacts                 # Mandatory parameter
                contact_groups                    contact_groups           # Mandatory parameter
                stalking_options                  [o,w,u,c]
                notes                             note_string
                notes_url                         url
                action_url                        url
                icon_image                        image_file
                icon_image_alt                    alt_string
               }

Directive Descriptions:

host_name: This directive is used to specify the short name(s) of the host(s) that the service "runs" on or is associated with. Multiple hosts should be separated by commas.
hostgroup_name: This directive is used to specify the short name(s) of the hostgroup(s) 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.
service_description;: 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 host_name and service_description directives.
display_name: 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 service_description directive. Note: The current CGIs do not use this option, although future versions of the web interface will.
parents: This directive is used to define a comma-delimited list of short names of the "parent" services for this particular service. Parent services are typically other services that need to be available in order for a check of this service to occur. For example, if a service checks the status of a disk using SSH, the disk check service would have the SSH service as a parent. If the service has no parent services, simply omit the "parents" directive. More complex service dependencies may be specified with service dependency objects.
hourly_value: This directive is used to represent the value of the service to your organization. The value is currently used when determining whether to send notifications to a contact. If the service's hourly value is greater than or equal to the contact's minimum value, the contact will be notified. For example, you could set this value and the minimum value of contacts such that a system administrator would be notified of a disk full event on a development server, but the CIO would only be notified when the company's production ecommerce database was down. The value could also be used as a sort criteria when generating reports or for calculating a good system administrator's bonus. The hourly value defaults to zero.
servicegroups: This directive is used to identify the short name(s) of the servicegroup(s) that the service belongs to. Multiple servicegroups should be separated by commas. This directive may be used as an alternative to using the members directive in servicegroup definitions.
is_volatile: This directive is used to denote whether the service is "volatile". Services are normally not volatile. More information on volatile service and how they differ from normal services can be found here. Value: 0 = service is not volatile, 1 = service is volatile.
check_command: This directive is used to specify the short name of the command 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 service_check_timeout option.
initial_state: 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: o = OK, w = WARNING, u = UNKNOWN, and c = CRITICAL.
max_check_attempts: 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.
check_interval: 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 max_check_attempts number of times. Unless you've changed the interval_length directive from the default value of 60, this number will mean minutes. More information on this value can be found in the check scheduling documentation.
retry_interval: 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 max_check_attempts times without a change in its status, it will revert to being scheduled at its "normal" rate as defined by the check_interval value. Unless you've changed the interval_length directive from the default value of 60, this number will mean minutes. More information on this value can be found in the check scheduling documentation.
active_checks_enabled *: 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).
passive_checks_enabled *: 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).
check_period: This directive is used to specify the short name of the time period during which active checks of this service can be made.
obsess_over_service / obsess *: This directive determines whether or not checks for the service will be "obsessed" over using the ocsp_command.
check_freshness *: This directive is used to determine whether or not freshness checks are enabled for this service. Values: 0 = disable freshness checks, 1 = enable freshness checks (default).
freshness_threshold: 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.
event_handler: This directive is used to specify the short name of the command 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 event handlers 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 event_handler_timeout option.
event_handler_enabled *: 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.
low_flap_threshold: 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 here. If you set this directive to a value of 0, the program-wide value specified by the low_service_flap_threshold directive will be used.
high_flap_threshold: 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 here. If you set this directive to a value of 0, the program-wide value specified by the high_service_flap_threshold directive will be used.
flap_detection_enabled *: This directive is used to determine whether or not flap detection is enabled for this service. More information on flap detection can be found here. Values: 0 = disable service flap detection, 1 = enable service flap detection.
flap_detection_options: This directive is used to determine what service states the flap detection logic will use for this service. Valid options are a combination of one or more of the following: o = OK states, w = WARNING states, c = CRITICAL states, u = UNKNOWN states.
process_perf_data *: 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.
retain_status_information: 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 retain_state_information directive. Value: 0 = disable status information retention, 1 = enable status information retention.
retain_nonstatus_information: 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 retain_state_information directive. Value: 0 = disable non-status information retention, 1 = enable non-status information retention.
notification_interval: This directive is used to define the number of "time units" to wait before re-notifying a contact that this service is still in a non-OK state. Unless you've changed the interval_length directive from the default value of 60, this number will mean minutes. If you set this value to 0, Nagios will not re-notify contacts about problems for this service - only one problem notification will be sent out.
first_notification_delay: 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 interval_length 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.
notification_period: This directive is used to specify the short name of the time period 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.
notification_options: 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: w = send notifications on a WARNING state, u = send notifications on an UNKNOWN state, c = send notifications on a CRITICAL state, r = send notifications on recoveries (OK state), f = send notifications when the service starts and stops flapping, and s = send notifications when scheduled downtime starts and ends. If you specify n (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 w,r 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.
notifications_enabled *: his directive is used to determine whether or not notifications for this service are enabled. Values: 0 = disable service notifications, 1 = enable service notifications.
contacts: This is a list of the short names of the contacts 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 contact groups. You must specify at least one contact or contact group in each service definition.
contact_groups: This is a list of the short names of the contact groups 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.
stalking_options: This directive determines which service states "stalking" is enabled for. Valid options are a combination of one or more of the following: o = stalk on OK states, w = stalk on WARNING states, u = stalk on UNKNOWN states, and c = stalk on CRITICAL states. More information on state stalking can be found here.
notes: 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 extended information CGI (when you are viewing information about the specified service).
notes_url: 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. /cgi-bin/nagios/). This can be very useful if you want to make detailed information on the service, emergency contact methods, etc. available to other support staff.
action_url: 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. /cgi-bin/nagios/).
icon_image: 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 status and extended information CGIs. The image will look best if it is 40×40 pixels in size. Images for services are assumed to be in the logos/ subdirectory in your HTML images directory (i.e. /usr/local/nagios/share/images/logos).
icon_image_alt: This variable is used to define an optional string that is used in the ALT tag of the image specified by the <icon_image> argument. The ALT tag is used in the status, extended information and statusmap CGIs.


servicegroup

Description

In some cases it’s required to provide to our users the possibility to see all “service” related to together.

Nice example is an application that use database and it is providing user interface.

In case like this we can group all relevant “service” objects together even they are running on different “hosts”.

Location Customization

In the case that you prefer to use your own configuration file, to store your customized configuration it is possible to define path to your configuration file.

In this case Nagios Core need to know where to search for the customized configuration file.

According to this it is required to update the main Nagios Core configuration file – “nagios.cfg”
It is possible to specify:

cfg_file=/<path>/<to>/<your>/<config>/<file>         # Direct path to you customized configuration file
cfg_dir=/<path>/<to>/<your>/<config>/<dir>           # Path to the directory where to search for the config file.

Official documentation

In most of my documents I’m preventing to copying of the official documentation. On another hand I think at this point it is really handy as I will not reinvent the wheel.

Description:

A service group definition is used to group one or more services together for simplifying configuration with object tricks or display purposes in the CGIs.

Definition Format:

define servicegroup{
                    servicegroup_name         servicegroup_name              # Mandatory parameter
                    alias                     alias                          # Mandatory parameter
                    members                   services
                    servicegroup_members      servicegroups
                    notes                     note_string
                    notes_url                 url
                    action_url                url
                   }

Directive Descriptions:

servicegroup_name: This directive is used to define a short name used to identify the service group.
alias: 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.
members:
This is a list of the descriptions of services (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 servicegroups directive in service definitions. The format of the member directive is as follows (note that a host name must precede a service name/description): % % members=<host1>,<service1>,<host2>,<service2>,...,<hostn>,<servicen>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.
servicegroup_members 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.
notes: 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 extended information CGI (when you are viewing information about the specified service group).
notes_url: 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. /cgi-bin/nagios/). 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.
action_url: 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. /cgi-bin/nagios/).


servicedependency

Description

In case that you are looking for event correlation to prevent flooding of support team, so that they can focus on the root cause. It’s required to define relation between “service” objects at Nagios Core.

According to this Nagios Core is providing the possibility to use “servicedependeny” object, to define dependency between “service” objects, even they are related to different “host” objects.

With help of this function it's possible to reduce temporary alarms, so that support team can focus on the root cause. With help of this Nagios Core object it’s possible to reduce load on support team and provide better support for your customer.

Location Customization

In the case that you prefer to use your own configuration file, to store your customized configuration it is possible to define path to your configuration file.

In this case Nagios Core need to know where to search for the customized configuration file.

According to this it is required to update the main Nagios Core configuration file – “nagios.cfg”
It is possible to specify:

cfg_file=/<path>/<to>/<your>/<config>/<file>         # Direct path to you customized configuration file
cfg_dir=/<path>/<to>/<your>/<config>/<dir>           # Path to the directory where to search for the config file.

Official documentation

In most of my documents I’m preventing to copying of the official documentation. On another hand I think at this point it is really handy as I will not reinvent the wheel.

Description:

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 here.

Definition Format:

define servicedependency{
                         dependent_host_name             host_name                     # Mandatory parameter
                         dependent_hostgroup_name        hostgroup_name
                         servicegroup_name               servicegroup_name
                         dependent_servicegroup_name     servicegroup_name
                         dependent_service_description   service_description           # Mandatory parameter
                         host_name                       host_name                     # Mandatory parameter
                         hostgroup_name                  hostgroup_name
                         service_description             service_description           # Mandatory parameter
                         inherits_parent                 [0/1]
                         execution_failure_criteria      [o,w,u,c,p,n]
                         notification_failure_criteria   [o,w,u,c,p,n]
                         dependency_period               timeperiod_name
                        }

Directive Descriptions:

dependent_host_name: This directive is used to identify the short name(s) of the host(s) that the dependent service "runs" on or is associated with. Multiple hosts should be separated by commas. Leaving this directive blank can be used to create "same host" dependencies.
dependent_hostgroup_name: This directive is used to specify the short name(s) of the hostgroup(s) that the dependent 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.
servicegroup_name: This directive is used to specify the short name(s) of the servicegroup(s) that will inherit the dependency. Multiple servicegroups should be separated by commas.
dependent_servicegroup_name: This directive is used to specify the short name(s) of the servicegroup(s) that the dependent service "runs" on or is associated with. Multiple servicegroups should be separated by commas.
dependent_service_description: This directive is used to identify the description of the dependent service.
host_name: This directive is used to identify the short name(s) of the host(s) that the service that is being depended upon (also referred to as the master service) "runs" on or is associated with. Multiple hosts should be separated by commas.
hostgroup_name: This directive is used to identify the short name(s) of the hostgroup(s) that the service that is being depended upon (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.
service_description: This directive is used to identify the description of the service that is being depended upon (also referred to as the master service).
inherits_parent: This directive indicates whether or not the dependency inherits dependencies of the service that is being depended upon (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.
execution_failure_criteria: This directive is used to specify the criteria that determine when the dependent service should not be actively checked. If the master service is in one of the failure states we specify, the dependent service will not be actively checked. Valid options are a combination of one or more of the following (multiple options are separated with commas): o = fail on an OK state, w = fail on a WARNING state, u = fail on an UNKNOWN state, c = fail on a CRITICAL state, and p = fail on a pending state (e.g. the service has not yet been checked). If you specify n (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 o,c,u in this field, the dependent service will not be actively checked if the master service is in either an OK, a CRITICAL, or an UNKNOWN state.
notification_failure_criteria: This directive is used to define the criteria that determine when notifications for the dependent service should not be sent out. If the master service is in one of the failure states we specify, notifications for the dependent service will not be sent to contacts. Valid options are a combination of one or more of the following: o = fail on an OK state, w = fail on a WARNING state, u = fail on an UNKNOWN state, c = fail on a CRITICAL state, and p = fail on a pending state (e.g. the service has not yet been checked). If you specify n (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 w in this field, the notifications for the dependent service will not be sent out if the master service is in a WARNING state.
dependency_period: This directive is used to specify the short name of the time period during which this dependency is valid. If this directive is not specified, the dependency is considered to be valid during all times.

serviceescalation

Description

The main idea of “serviceescalaton” object at Nagios Core is to configure automated escalation process for detected issues.

For example it can be used for automated escalation of the issues based on the hierarchy of delivery model.
- 1st detection of the issue, send notification to 1st level support team
- 10th detection of the issue, send notification to 2nd level support team
- 20th detection of the issue, send notification to 3th level support team
- 30th detection of the issue, send notification to Escalation Manager

I know that this idea is nice and it’s possible to automate the business process.

Any way please do not use it in this way.

- In the case that 1st level team has already started investigation, probably they have already contacted relevant vendors.
- After some time the same alarm will be sent to 2nd and later on to 3th level support team.
- This 2nd and 3th level team will need to start the whole investigation from scratch, instead of continue to work on the case with the information that has 1st level support team has already collected.

On another hand serviceesacalation” object is providing us the possibility to automatize fixing of some issues. In this case we can run script that will try to fix the issue, instead of sending notification at 1st detection of the issue. In case that the issue will be still present during next polling period we can sent notification to responsible team.

In this way it's possible to automate some kind of service related issues. Like in the case that we are running an Demon that we can try to start before we'll send “Service Critical” alarm.

Location Customization

In the case that you prefer to use your own configuration file, to store your customized configuration it is possible to define path to your configuration file.

In this case Nagios Core need to know where to search for the customized configuration file.

According to this it is required to update the main Nagios Core configuration file – “nagios.cfg”
It is possible to specify:

cfg_file=/<path>/<to>/<your>/<config>/<file>         # Direct path to you customized configuration file
cfg_dir=/<path>/<to>/<your>/<config>/<dir>           # Path to the directory where to search for the config file.

Official documentation

In most of my documents I’m preventing to copying of the official documentation. On another hand I think at this point it is really handy as I will not reinvent the wheel.

Description:

Service escalations are completely optional and are used to escalate notifications for a particular service. More information on how notification escalations work can be found here.

Definition Format:

define serviceescalation{
                         host_name              host_name             # Mandatory parameter
                         hostgroup_name         hostgroup_name
                         service_description    service_description   # Mandatory parameter
                         contacts               contacts
                         contact_groups         contactgroup_name
                         first_notification     #                     # Mandatory parameter
                         last_notification      #                     # Mandatory parameter
                         notification_interval  #                     # Mandatory parameter
                         escalation_period      timeperiod_name
                         escalation_options     [w,u,c,r]
                        }

Directive Descriptions:

host_name: This directive is used to identify the short name(s) of the host(s) that the service escalation should apply to or is associated with.
hostgroup_name: This directive is used to specify the short name(s) of the hostgroup(s) 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.
service_description: This directive is used to identify the description of the service the escalation should apply to.
first_notification: This directive is a number that identifies the first 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.
last_notification: This directive is a number that identifies the //last// 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).
contacts: This is a list of the //short names// of the [[http://nagios.sourceforge.net/docs/nagioscore/4/en/objectdefinitions.html#contact|contacts]] 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 [[http://nagios.sourceforge.net/docs/nagioscore/4/en/objectdefinitions.html#contactgroup|contact groups]]. You must specify at least one contact or contact group in each service escalation definition.
contact_groups: This directive is used to identify the short name of the contact group 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.
notification_interval: 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 only sent out when 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.
escalation_period: This directive is used to specify the short name of the time period during which this escalation is valid. If this directive is not specified, the escalation is considered to be valid during all times.
escalation_options: 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: r = escalate on an OK (recovery) state, w = escalate on a WARNING state, u = escalate on an UNKNOWN state, and c = escalate on a CRITICAL state. Example: If you specify w in this field, the escalation will only be used if the service is in a WARNING state.

Example

URL's

Navigation
Print/export
QR Code
QR Code wiki:infrastructure_tools:nagios:nagios_core_configuration_-_service_servicegroup_servicedependency_serviceescalation (generated for current page)