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.
Bold directives are required, while the others are optional.
define service{ | |
host_name | *host_name* |
hostgroup_name | hostgroup_name |
service_description | *service_description* |
display_name | display_name |
servicegroups | servicegroup_names |
is_volatile | [0/1] |
check_command | *command_name* |
initial_state | [o,w,u,c] |
max_check_attempts | # |
check_interval | # |
retry_interval | # |
active_checks_enabled | [0/1] |
passive_checks_enabled | [0/1] |
check_period | *timeperiod_name* |
obsess_over_service | [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 | # |
first_notification_delay | # |
notification_period | *timeperiod_name* |
notification_options | [w,u,c,r,f,s] |
notifications_enabled | [0/1] |
contacts | *contacts* |
contact_groups | *contact_groups* |
stalking_options | [o,w,u,c] |
notes | note_string |
notes_url | url |
action_url | url |
icon_image | image_file |
icon_image_alt | alt_string |
poller_tag | poller_tag |
reactionner_tag | reactionner_tag |
duplicate_foreach | $MACRO$ |
service_dependencies | host,service_description |
business_impact | [0/1/2/3/4/5] |
icon_set | [database/disk/network_service/server] |
maintenance_period | timeperiod_name |
host_dependency_enabled | [0/1] |
labels | labels |
business_rule_output_template | template |
business_rule_smart_notifications | [0/1] |
business_rule_downtime_as_ack | [0/1] |
business_rule_host_notification_options | [d,u,r,f,s] |
business_rule_service_notification_options | [w,u,c,r,f,s] |
snapshot_enabled | [0/1] |
snapshot_command | command_name |
snapshot_period | timeperiod_name |
snapshot_criteria | [w,c,u] |
snapshot_interval | # |
trigger_name | trigger_name |
trigger_broker_raise_enabled | [0/1] |
} |
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
poller_tag DMZ
icon_set server
}
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.
This is possibleto define “complex” hostgroup expression with the following operators :
& : it’s use to make an AND betweens groups
: it’s use to make an OR betweens groups! : it’s use to make a NOT of a group or expression
, : it’s use to make a OR, like the | sign.
( and ) : they are use like in all math expressions.
For example the above definition is valid
hostgroup_name=(linux|windows)&!qualification,routers
This service wil be apply on hosts that are in the routers group or (in linux or windows and not in qualification group).
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.
The current CGIs do not use this option, although future versions of the web interface will.
This directive is used to specify the short name of the command that Shinken 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. There is also a command with the reserved name “bp_rule”. It is defined internally and has a special meaning. Unlike other commands it mustn’t be registered in a command definition. It’s purpose is not to execute a plugin but to represent a logical operation on the statuses of other services. It is possible to define logical relationships with the following operators :
& : it’s use to make an AND betweens statuses
: it’s use to make an OR betweens statuses! : it’s use to make a NOT of a status or expression
, : it’s use to make a OR, like the | sign.
( and ) : they are used like in all math expressions
For example the following definition of a business process rule is valid
bp_rule!(websrv1,apache | websrv2,apache) & dbsrv1,oracle
If at least one of the apaches on servers websrv1 and websrv2 is OK and if the oracle database on dbsrv1 is OK then the rule and thus the service is OK
By default Shinken will assume that all services are in OK states when in starts. You can override the initial state for a service by using this directive. Valid options are:
- o = OK
- w = WARNING
- u = UNKNOWN
- c = CRITICAL.
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.
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.
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
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.
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.
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.
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
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.
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
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
- s = send notifications when scheduled downtime starts and ends
- n (none) as an option, no service notifications will be sent out. If you do not specify any notification options, Shinken will assume that you want notifications to be sent out for all possible states
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.
This directive is used to determine whether or not notifications for this service are enabled. Values:
- 0 = disable service notifications
- 1 = enable service notifications.
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
- c = stalk on CRITICAL states
More information on state stalking can be found here.
This variable is used to define the poller_tag of checks from this service. All of theses checks will be taken by pollers that have this value in their poller_tags parameter.
By default there is no poller_tag, so all untaggued pollers can take it.
This variable is used to define the reactionner_tag of notifications_commands from this service. All of theses notifications will be taken by reactionners that have this value in their reactionner_tags parameter.
By default there is no reactionner_tag, so all untaggued reactionners can take it.
define host {
host_name linux-server
...
_partitions var $(/var)$, root $(/)$
_openvpns vpn1 $(tun1)$$(10.8.0.1)$, vpn2 $(tun2)$$(192.168.3.254)$
...
}
define service{
host_name linux-server
service_description disk-$KEY$
check_command check_disk!$VALUE$
...
duplicate_foreach _partitions
}
define service{
host_name linux-server
service_description openvpn-$KEY$-check-interface
check_command check_int!$VALUE1$
...
duplicate_foreach _openvpns
}
define service{
host_name linux-server
service_description openvpn-$KEY$-check-gateway
check_command check_ping!$VALUE2$
...
duplicate_foreach _openvpns
}
This variable is used to define services that this service is dependent of for notifications. It’s a comma separated list of services: host,service_description,host,service_description. For each service a service_dependency will be created with default values (notification_failure_criteria as ‘u,c,w’ and no dependency_period). For more complex failure criteria or dpendency period you must create a service_dependency object, as described in advanced dependency configuraton. The host can be omitted from the configuration, which means that the service dependency is for the same host.
service_dependencies hostA,service_descriptionA,hostB,service_descriptionB
service_dependencies ,service_descriptionA,,service_descriptionB,hostC,service_descriptionC
By default this value is void so there is no linked dependencies. This is typically used to make a service dependent on an agent software, like an NRPE check dependent on the availability of the NRPE agent.