How to configure service templates
Service templates store common object properties used to define multiple services.
Service templates are used to reduce the number of repetitive entries when defining objects. For example, when defining a service you may want to create a new service template first with common properties that may be used in other services. Then, to define a specific service you would apply the properties using a service template. You would define a new host in the same way, starting with a host template and applying the template to the host definition.
GroundWork Monitor provides several host and service templates.
A service configuration is a combination of a service template and a service definition. A service is generic until it has been applied to a specific host. A host, when fully implemented, has a host template, a unique host definition, and services.
Defining a new service template
Tips
- Once a template has been assigned to a service(s), it becomes a stable copy separate from the generic template definition.
- If you Modify the generic template definition the changes will be reflected in the services assigned that template.
- If you want to manage existing services and their template settings, go directly to the service, uninherit the template directives and edit, this will override the template values for that service. The changes will be reflected in the host(s) assigned that service.
- If you want to manage existing host services and their template settings, go directly to the host service, uninherit the template directives and edit, this will override the template values for that host service.
- If you would like to create a new service template based on an existing template use Copy vs. New.
- After all configuration changes you need to perform a commit operation.
- Hovering over the fas fa-question symbol displays a description of each directive and indicates if it is required or optional, these are also outlined in the table below.
From the GroundWork Monitor menu, selecting Configuration > Nagios Monitoring > Services > Service Templates presents the options New, Copy, and Modify. Each of these options opens the Manage Service Template screen. The New option will have no pre-selected directive values, Copy lets you create a new template based on an existing templates properties, and Modify enables the editing of an existing template.
After a service template is defined and saved, it can be applied in one or many service definitions.
| Directive Name | Description/Values |
|---|---|
| Service template name | Name of the service template. |
| Use | If you wish to base this service template on another template, with a few changes, select the service template most suitable as a base for this template. If you do so, note inheritance (the left check box) on directives below. To override a particular base-template value, first uncheck the left check box, then provide a custom value. |
| Active checks enabled | Nagios is capable of monitoring hosts and services in two ways; actively and passively. In most cases you'll use regularly scheduled active checks. Determines whether or not are enabled for this service. Unchecked = disable active service checks, Checked = enable active service checks Active checks Passive checks |
| Passive checks enabled | Determines whether or not passive checks are enabled for this service. Unchecked = disable passive service checks, Checked = enable passive service checks |
| Check period | (Required) Specifies the short name of the time period during which active checks of this service can be made. |
| Normal check interval | (Required) Defines 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_attempts number of times. Unless you've changed the interval_length directive from the default value of 60, this number will mean minutes. |
| Retry check interval | (Required) Defines 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_attempts times without a change in its status, it will revert to being scheduled at its 'normal' rate as defined by the normal_check_interval value. Unless you've changed the interval_length directive from the default value of 60, this number will mean minutes. |
| Max check attempts | (Required) Defines 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 freshness | Determines whether or not freshness checks are enabled for this service. Unchecked = disable freshness checks Checked = enable freshness checks |
| Freshness threshold | Specifies 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. |
| Obsess over service | Determines whether or not Nagios will 'obsess' over service checks results and run the obsessive compulsive service processor command you define. This option is useful for performing distributed monitoring. If you're not doing distributed monitoring, don't enable this option. |
| Flap detection enabled | Determines whether or not flap detection is enabled for this service. Unchecked = disable service flap detection Checked = enable service flap detection |
| Low flap threshold | Specifies the low state change threshold used in flap detection for this service. 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 | Specifies the high state change threshold used in flap detection for this service. 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. |
| Event handler enabled | Determines whether or not the event handler for this service is enabled. Unchecked = disable service event handler Checked = enable service event handler |
| Event handler | Specifies 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). The maximum amount of time that the event handler command can run is controlled by the event_handler_timeout option. |
| Is volatile | Denotes 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 in the Nagios documentation. Unchecked = service is not volatile Checked = service is volatile |
| Stalking options | Determines which service states 'stalking' is enabled for. Valid options are a combination of one or more of the following: Okay checked = stalk on OK states Warning checked = stalk on WARNING states Critical checked = stalk on CRITICAL states Unknown checked = stalk on UNKNOWN states |
| Process perf data | Determines whether or not the processing of performance data is enabled for this service. Unchecked = disable performance data processing Checked = enable performance data processing |
| Notifications enabled | Determines whether or not notifications for this service are enabled. Unchecked = disable service notifications Checked = enable service notifications |
| Notification options | (Required) Determines when notifications for the service should be sent out. Valid options are a combination of one or more of the following: Warning checked = send notifications on a WARNING state Unknown checked = send notifications on an UNKNOWN state Critical checked = send notifications on a CRITICAL state Recovery checked = send notifications on recoveries (OK state) None = No service notifications will be sent out |
| Notification period | (Required) Specifies 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. Time Periods |
| Notification interval | (Required) Defines 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, unless there has been a state change. |
| Contact groups | Lists the short names of the contact groups that should be notified whenever there are problems (or recoveries) with this service. |
| Retain status information | Determines 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. Unchecked = disable status information retention Checked = enable status information retention |
| Retain nonstatus information | Determines 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. Unchecked = disable non-status information retention Checked = enable non-status information retention |
Related articles
-
How to create a new command (Knowledge Base)
-
How to configure services (Knowledge Base)
-
How to configure service groups (Knowledge Base)
-
How to configure host and service dependencies (Knowledge Base)
-
How to configure externals (Knowledge Base)