Table of Contents
Nagios Core Configuration - contact, contactgroup
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 commands objects is located at:
/opt/nagios-<VERSION>/etc/objects/contacts.cfg
Preface
Multi tenancy at Nagios Core is managed at contact and contact group objects. With help of mentioned Nagios Core object is possible to specify who has access to what kind of information.
In the case that you are providing monitoring service for several support teams. Probably you would like to restrict:
- Notification time period when the support team need to receive alarms.
- Visibility of monitored infrastructure on Web GUI of Nagios Core based on the responsibility of the team.
In some cases when your company is providing support to your customers. It is not permitted to share information related to mentioned customer with no one, that has not direct relation to the customer. Even it is someone from the same company working for another account.
contact
Description
Location
Nagios Core is providing to you already predefined set of contact object.
Located at (in the case that you have followed the installation of Nagios Core described on this website): /opt/nagios-<VERSION>/etc/objects/contacts.cfg
define contact{
contact_name nagiosadmin ; Short name of user
use generic-contact ; Inherit default values from generic-contact template (defined above)
alias Nagios Admin ; Full name of user
email nagios@localhost ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ******
}
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 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.
Definition Format:
define contact{
contact_name contact_name # Mandatory parameter
alias alias
contactgroups contactgroup_names
minimum_value #
host_notifications_enabled [0/1] # Mandatory parameter
service_notifications_enabled [0/1] # Mandatory parameter
host_notification_period timeperiod_name # Mandatory parameter
service_notification_period timeperiod_name # Mandatory parameter
host_notification_options [d,u,r,f,s,n] # Mandatory parameter
service_notification_options [w,u,c,r,f,s,n] # Mandatory parameter
host_notification_commands command_name # Mandatory parameter
service_notification_commands command_name # Mandatory parameter
email email_address
pager pager_number or pager_email_gateway
addressx additional_contact_address
can_submit_commands [0/1]
retain_status_information [0/1]
retain_nonstatus_information [0/1]
}
Directive Descriptions:
| contact_name: | This directive is used to define a short name used to identify the contact. It is referenced in contact group definitions. Under the right circumstances, the $CONTACTNAME$ macro will contain this value. |
| alias: | This directive is used to define a longer name or description for the contact. Under the rights circumstances, the $CONTACTALIAS$ macro will contain this value. If not specified, the contact_name will be used as the alias. |
| contactgroups: | This directive is used to identify the short name(s) of the contactgroup(s) 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 members directive in contactgroup definitions. |
| minimum_value: | This directive is used as the value that the host or service hourly value must equal before notification is sent to this contact. The hourly values are intended to represent the value of a host or service to an organization. For example, you could set this value and the hourly value of a host such that a system administrator would be notified when a development server goes down, but the CIO would only be notified when the company's production ecommerce database server was down. The minimum value defaults to zero. |
| host_notifications_enabled: | 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. |
| service_notifications_enabled: | 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. |
| host_notification_period: | This directive is used to specify the short name of the time period 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 time periods for more information on how this works and potential problems that may result from improper use. |
| service_notification_period: | This directive is used to specify the short name of the time period 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 time periods for more information on how this works and potential problems that may result from improper use. |
| host_notification_commands: | This directive is used to define a list of the short names of the commands used to notify the contact of a host 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 notification_timeout option. |
| host_notification_options: | 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: d = notify on DOWN host states, u = notify on UNREACHABLE host states, r = notify on host recoveries (UP states), f = notify when the host starts and stops flapping, and s = send notifications when host or service scheduled downtime starts and ends. If you specify n (none) as an option, the contact will not receive any type of host notifications. |
| service_notification_options: | 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: w = notify on WARNING service states, u = notify on UNKNOWN service states, c = notify on CRITICAL service states, r = notify on service recoveries (OK states), and f = notify when the service starts and stops flapping. If you specify n (none) as an option, the contact will not receive any type of service notifications. |
| service_notification_commands: | This directive is used to define a list of the short names of the commands used to notify the contact of a service 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 notification_timeout option. |
| email: | 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$ macro will contain this value. |
| pager: | 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$ macro will contain this value.</nowiki> |
| addressx: | 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 (address1 through address6). The $CONTACTADDRESSx$ macro will contain this value. |
| can_submit_commands: | This directive is used to determine whether or not the contact can submit external commands to Nagios from the CGIs. Values: 0 = don't allow contact to submit commands, 1 = allow contact to submit commands. |
| retain_status_information: | 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 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 contact 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. |
contactgroup
Description
Location
Nagios Core is providing to you already predefined set of contact object.
Located at (in the case that you have followed the installation of Nagios Core described on this website): /opt/nagios-<VERSION>/etc/objects/contacts.cfg
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members nagiosadmin
}
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 contact group definition is used to group one or more contacts together for the purpose of sending out alert/recovery notifications
Definition Format:
define contactgroup{
contactgroup_name contactgroup_name # Mandatory parameter
alias alias # Mandatory parameter
members contacts
contactgroup_members contactgroups
}
Directive Descriptions:
| contactgroup_name: | This directive is a short name used to identify the contact group. |
| alias: | This directive is used to define a longer name or description used to identify the contact group. |
| members: | This optional directive is used to define a list of the short names of contacts 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 contactgroups directive in contact definitions. |
| contactgroup_members: | 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. |
Example
Multiple notification ways
When you are looking for the possibility to use multiple notification ways, it's handy to use “contact“ and “contactgroup” objects of Nagios Core.
For example in the case that some issue will be detected it's possible to forward this event to another tool and in parallel to run script that will send a mail notification.
Mentioned “contact” objects can be grouped in to one “contactgroup” object that will be assigned to “host” or “service” objects at Nagios Core. In this way we'll create a relation between mentioned “contact” and “host” or “service” objects at Nagios Core.
define contact{
contact_name test_nagiosadmin # 1st Contact
alias Nagios Admin
email test_nagios@localhost
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,f
host_notification_options d,u,f
service_notification_commands service-to-hp_oml # Command that will be called when issue is detected
host_notification_commands host-to-hp_oml # Command that will be called when issue is detected
}
define contact{
contact_name nagiosadmi # 2nd Contact
alias Nagios Admin
email nagios@localhos
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email # Command that will be called when issue is detected
host_notification_commands notify-host-by-email # Command that will be called when issue is detected
}
define contactgroup{
contactgroup_name test_admins # Contact Group
alias Nagios Administrators
members test_nagiosadmin,nagiosadmin # Including this Contacts
}
define host{
host_name test_node.test.com # Host Object
alias test_node
address 10.0.12.1
check_period 24x7
check_interval 5
retry_interval 1
max_check_attempts 1
check_command check-host-alive
notification_period 24x7
notification_interval 0
notification_options d,u,f
contact_groups test_admins # Related Contact Group
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 0
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
notification_period 24x7
_severity critical
_msggrp test
}
define service{
host_name test_node.test.com # Service Object
service_description PING
check_command check_ping!100.0,20%!500.0,60%
max_check_attempts 1
normal_check_interval 5
retry_check_interval 1
active_checks_enabled 1
passive_checks_enabled 1
parallelize_check 1
obsess_over_service 1
check_freshness 0
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 0
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
is_volatile 0
check_period 24x7
normal_check_interval 10
retry_check_interval 2
contact_groups test_admins # Related Contact Group
notification_options w,u,c,f
notification_interval 0
notification_period 24x7
_severity critical
_msggrp test
}
Follow the sun, support model.
In our case we’ll assume that the support team is splatted in to 3 geographical regions (AMS, EMEA, and APAC). Each of this team is providing support for our customer during local office hours (let’s say 8:00 – 18:00).
According to this:
- We’ve 3 sub-teams that are providing together 24/7/365 support to our customer.
- Each team is using different PDL for mail notification.
- Each team is working during different time frame.
08:00-10:00 (local time) - Time for handover between teams
09:00-17:00 (local time) - Nagios Core will send notification to our team
16:00-18:00 (local time) - Time for handover between teams
We’ll configure:
- 3 different “contact” objects that will use 3 different PDL’s for mail notification
- 3 different “timeperiod” objects for the time frame when the notification need to be sent out.
- 1 “contactgroup” object that will be assigned to all our “host” and “service” objects at Nagios Core.
define timeperiod{
timeperiod_name ams_time # AMS working hors (using GMT/UTC time zone)
alias AMS time
sunday 17:00-01:00
monday 17:00-01:00
tuesday 17:00-01:00
wednesday 17:00-01:00
thursday 17:00-01:00
friday 17:00-01:00
saturday 17:00-01:00
}
define timeperiod{
timeperiod_name emea_time # EMEA working hors (using GMT/UTC time zone)
alias EMEA time
sunday 09:00-17:00
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
saturday 09:00-17:00
}
define timeperiod{
timeperiod_name apac_time # APAC working hors (using GMT/UTC time zone)
alias APAC time
sunday 01:00-09:00
monday 01:00-09:00
tuesday 01:00-09:00
wednesday 01:00-09:00
thursday 01:00-09:00
friday 01:00-09:00
saturday 01:00-09:00
}
define contact{
contact_name ams_contact_pdl # 1st Contact
alias AMS Contact PDL
email ams@localhost # AMS PDL mail contact
service_notification_period ams_time # AMS notification period
host_notification_period ams_time # AMS notification period
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email # Command that will be called when issue is detected
host_notification_commands notify-host-by-email # Command that will be called when issue is detected
}
define contact{
contact_name emea_contact_pdl # 2nd Contact
alias EMEA Contact PDL
email emea@localhost # EMEA PDL mail contact
service_notification_period emea_time # EMEA notification period
host_notification_period emea_time # EMEA notification period
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email # Command that will be called when issue is detected
host_notification_commands notify-host-by-email # Command that will be called when issue is detected
}
define contact{
contact_name apac_contact_pdl # 3th Contact
alias APAC Contact PDL
email apac@localhost # APAC PDL mail contact
service_notification_period apac_time # APAC notification period
host_notification_period apac_time # APAC notification period
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email # Command that will be called when issue is detected
host_notification_commands notify-host-by-email # Command that will be called when issue is detected
}
define contactgroup{
contactgroup_name fllow_the_sun_contact # Contact Group
alias Nagios Administrators
members ams_contact_pdl,emea_contact_pdl,apac_contact_pdl # Including this Contacts
}
define host{
host_name test_node.test.com # Host Object
alias test_node
address 10.0.12.1
check_period 24x7
check_interval 5
retry_interval 1
max_check_attempts 1
check_command check-host-alive
notification_period 24x7
notification_interval 0
notification_options d,u,f
contact_groups fllow_the_sun_contact # Related Contact Group
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 0
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
notification_period 24x7
}
define service{
host_name test_node.test.com # Service Object
service_description PING
check_command check_ping!100.0,20%!500.0,60%
max_check_attempts 1
normal_check_interval 5
retry_check_interval 1
active_checks_enabled 1
passive_checks_enabled 1
parallelize_check 1
obsess_over_service 1
check_freshness 0
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 0
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
is_volatile 0
check_period 24x7
normal_check_interval 10
retry_check_interval 2
contact_groups fllow_the_sun_contact # Related Contact Group
notification_options w,u,c,f
notification_interval 0
notification_period 24x7
}
URL's
Nagios Core 3 “contact” documentation: http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html#contact
Nagios Core 4 “contact” documentation: http://nagios.sourceforge.net/docs/nagioscore/4/en/objectdefinitions.html#contact
Nagios Core 3 “contactgroup” documentation: http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html#contactgroup
Nagios Core 4 “contactgroup” documentation: http://nagios.sourceforge.net/docs/nagioscore/4/en/objectdefinitions.html#contactfroup
