Host templates store common object properties used to define multiple hosts. Host templates are used to reduce the number of repetitive entries when defining objects. For example, when defining a host you may want to create a new host template first with common properties that may be used in other hosts. Then, to define a specific host you would apply the properties using a host template. You would define a new service in the same way, starting with a service template and applying the template to the service definition. GroundWork Monitor provides several host and service templates.
Defining a new host template
- Once a template has been assigned to a host(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 hosts assigned that template.
- If you want to manage existing hosts and their template settings, go directly to the host, uninherit the template directives and edit, this will override the template values for that host.
- If you would like to create a new host 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.
To create a new (copy or modify) template, navigate to Configuration > Nagios Monitoring > Hosts > Host Templates > New, which opens the Host Template Properties 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 new host template is defined and saved, it can be applied in one or many host definitions.
Host templates also allow for defining and managing custom object variables.
|Host template name||Name of the host template.|
|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. Unchecked = disable active host checks
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). Active checks are executed at regular intervals, as defined by the check_interval and retry_interval options in your host and service definitions and also on-demand as needed.
|Passive checks enabled|
Determines whether or not passive checks are enabled for this host. Unchecked = disable passive host checks, Checked = enable passive host checks
Passive checks are initiated and performed by external applications/processes and results are submitted to Nagios for processing, where active checks are initiated and performed by Nagios. Passive checks are useful for monitoring services asynchronous in nature and cannot be monitored effectively by polling their status on a regularly scheduled basis and are located behind a firewall and cannot be checked actively from the monitoring host.
|Check command||Specifies the short name of the command to be used to check if the host is up or down. |
Typically, this command would try to ping the host to see if is is 'alive'. The command must return a status of OK (0) or Nagios will assume the host is down.
The maximum amount of time the notification command can run is controlled by the host_check_timeout option. If you leave this argument blank, the host will not be checked, Nagios will always assume the host is up. This is useful if you are monitoring printers or other devices frequently turned off.
Optional, sets the default value. If check command requires arguments, enter the check command with command arguments separated by a ! character.
(Required) Specifies the short name of the time period during which active checks of this host can be made.
Time Periods are lists of times during various days that are considered to be valid times for notifications and service checks. They indicate when host and service checks can be performed, when host and service notifications can be sent out to contacts, when notification escalations can be used, and when dependencies are valid. Time Periods are applied within host, service, contact template and escalation definitions. To set up time periods go to Configuration > Nagios Monitoring > Time Periods.
|Check interval||Defines the number of 'time units' between regularly scheduled checks of the host. |
A value of 0 will disable regularly scheduled host checks (though on-demand host checks will still be possible if active host checks are enabled and a check command is configured). Otherwise, unless you've changed the interval_length directive from the default value of 60, this number will mean minutes.
|Retry interval||Defines 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 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.
|Max check attempts||(Required) Defines the number of times 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 again. 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 check_command option blank.
|Check freshness||Determines whether or not freshness checks are enabled for hosts using this template. The purpose of freshness checking is to ensure host and service checks are being provided passively by external applications on a regular basis.|
Checked = enable freshness checks
|Freshness threshold||Specifies the freshness threshold (in seconds) for hosts using this template. |
If you set this directive to a value of 0, Nagios will determine a freshness threshold to use automatically.
|Obsess over host||Determines whether or not checks for the host will be 'obsessed' over using the ochp_command (defined in Nagios main configuration). |
Checked = enabled
|Flap detection enabled||Determines whether or not flap detection is enabled for hosts using this template. |
Unchecked = disable host flap detection
Checked = enable host flap detection
|Low flap threshold||Specifies the low state change threshold used in flap detection for hosts using this template. |
If you set this directive to a value of 0, the program-wide value specified by the low_host_flap_threshold directive will be used.
|High flap threshold||Specifies the high state change threshold used in flap detection for hosts using this template. |
If you set this directive to a value of 0, the program-wide value specified by the high_host_flap_threshold directive will be used.
|Event handler enabled||Determines whether or not the event handler for hosts using this template is enabled. |
Unchecked = disable host event handler
Checked = enable host event handler
|Event handler||Specifies the short name of the command to run whenever a change in the state of the host is detected (e.g., down or recovery). The maximum amount of time the event handler command can run is controlled by the event_handler_timeout option.|
|Stalking options||Determines which host states 'stalking' is enabled. |
Valid options are a combination of one or more of the following:
Up checked = stalk on UP states
Down checked = stalk on DOWN states
Unreachable checked = stalk on UNREACHABLE states
|Process perf data||Determines whether or not the processing of performance data is enabled for hosts using this template. |
Unchecked = disable performance data processing
Checked = enable performance data processing
|Notifications enabled||Determines whether or not notifications for hosts using this template are enabled. |
Unchecked = disable host notifications
Checked = enable host notifications
|Notification options||(Required) Determines when notifications for the host should be sent out. |
Valid options are a combination of one or more of the following:
Down checked = send notifications on a DOWN state
Unreachable checked = send notifications on an UNREACHABLE state
Recovery checked = send notifications on recoveries (OK state)
None = no host notifications will be sent
Example: If you specify Down and Recovery, notifications will only be sent out when the host goes DOWN and when it recovers from a DOWN state.
|Notification period||(Required) Specifies the short name of the time period during which notifications of events for hosts using this template 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.|
|Notification interval||(Required) Defines the number of 'time units' to wait before re-notifying a contact this server is still down or unreachable.|
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 hosts using this template -- only one problem notification will be sent.
|Contact groups||A list of the short names of the contact groups to be notified whenever there are problems (or recoveries) with this host.|
|Retain status information||Determines 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 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 host 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